I think the problem is 220.127.116.11/14 have bigger IP count than 65535, maybe idk.
You may be exactly correct here. If you are using an IPset of type
hash, it has a maximal number of elements it can store, settable by the
maxelem parameter when creating the IPset... and the default value for
maxelem is 65536. And if you use a hash of type
bitmap, 65536 addresses is the maximum size of the map.
But what are you using the IPset for? If you are simply matching against the whole /14 segment, a hash-based IPset will be much less efficient than a simple network address & mask-based match.
But if you are just setting up an initial set and planning to later selectively knock out specific IP addresses from it, then it would make sense to use an IPset.
Even so, if the number of knocked-out IPs is expected to be relatively small, it might be sensible to invert the sense of whatever you're doing and use a mask-based match as the general rule and the IPset-based match as exceptions to it.
iptables -N maybeAllow81_212
iptables -A maybeAllow81_212 -m set --match-set denyiplist_81_212 src -j DROP
iptables -A maybeAllow81_212 -j ACCEPT
iptables -A INPUT -s 18.104.22.168/14 -j maybeAllow81_212
This way, any traffic that is not coming from within the 22.214.171.124/14 can be processed in the main INPUT chain with essentially just two assembler instructions: one 32-bit AND and one 32-bit comparision. You cannot get much faster than that.
Any traffic from within that segment gets diverted to the
maybeAllow81_212 subchain which will do the hash match (with an inverted, hopefully much smaller set to match against with!) and then allow everyone who doesn't match the set to pass.