为什么iptables字符串匹配规则对X-Forwarded-For请求头不生效？

• 核心原因是iptables的string模块默认开启大小写敏感匹配，而tcpdump的ASCII输出会自动将HTTP头字段名转为小写展示，实际Cloudflare发送的X-Forwarded-For头是大小写混合格式（首字母大写），你规则中写的全小写x-forwarded-for和实际流量中的字段名不一致，所以匹配失败。而Cloudflare专属的cf-connecting-ip头本身就是全小写格式，和你规则中的字符串完全一致，所以可以正常匹配。
• 次要可能原因：如果请求经过多层代理，X-Forwarded-For头会携带多个IP地址（格式为X-Forwarded-For: 客户端IP, 第一层代理IP, 第二层代理IP），你规则中完全匹配x-forwarded-for: 216.244.66.205的格式会因为后面有多余IP内容匹配失败。
• 边缘可能原因：服务器网卡开启了GRO/TSO等TCP大包卸载功能，多个TCP段被合并后字符串匹配出现偏移，导致匹配失败。

1. 给iptables规则添加--icase参数开启大小写不敏感匹配，同时限定80端口的TCP流量减少不必要的匹配损耗，修改后的规则如下：

iptables -I INPUT -p tcp --dport 80 -m string --string "x-forwarded-for: 216.244.66.205" --algo bm --to 65535 --icase -j DROP

2. 如果存在XFF头多IP的场景，可以适当缩短匹配字符串，只匹配固定特征，避免多余内容影响匹配：

iptables -I INPUT -p tcp --dport 80 -m string --string "Forwarded-For: 216.244.66.205" --algo bm --to 65535 --icase -j DROP

3. 如果上述规则仍然不生效，可以临时关闭网卡的大包卸载功能验证，命令如下（将eth0替换为你实际的公网网卡名）：

ethtool -K eth0 gro off tso off

注意：关闭大包卸载会一定程度提升CPU占用，验证完成后如果不需要可以执行ethtool -K eth0 gro on tso on恢复配置。

• 该方案仅适用于Cloudflare/HAProxy到服务器的明文HTTP流量，HTTPS加密流量无法通过iptables字符串匹配识别请求头内容。
• 生产环境建议优先在Cloudflare安全规则、HAProxy访问控制层面做IP封禁，性能和准确性都高于iptables匹配HTTP头的方案。

内容的提问来源于stack exchange，提问作者Ajaib Singh