iptables的hashlimit模块可实现内核态轻量限流，按IP、路径或组合维度构建哈希桶，需合理配置速率、突发值、哈希表大小及过期时间，并注意HTTP匹配限制、规则顺序与持久化问题。
使用 iptables 的 hashlimit 模块可以对 API 请求进行轻量、内核态的限流，适合在无应用层网关（如 Nginx、Envoy）或需底层防护的场景下快速启用基础速率控制。它不依赖用户态进程，开销低，但粒度较粗，需结合业务特征合理配置。
明确限流目标与匹配条件
限流效果取决于能否准确识别“同一类请求”。hashlimit 依据匹配字段（如源 IP、目标端口、请求路径哈希等）构建哈希表，因此必须先确定限流维度：
- 按客户端 IP 限流：适用于防爬、防暴力调用，用
--hashlimit-srcip - 按 API 路径限流：需配合
string模块匹配 HTTP 请求行（如GET /api/v1/user），再用--hashlimit-name区分规则 - 组合维度（如 IP + URI）：需用
--hashlimit-htable-expire延长哈希项存活时间，避免过早淘汰导致误放行
构造带哈希桶的限流规则
hashlimit 的核心是“桶”（bucket）机制：每个匹配键对应一个令牌桶，通过 --hashlimit-above 触发动作。典型命令结构如下：
--hashlimit-name api_get_limit \
--hashlimit-mode srcip,dstport \
--hashlimit-srcmask 32 \
--hashlimit-upto 100/sec \
--hashlimit-burst 50 \
--hashlimit-htable-size 4096 \
--hashlimit-htable-max 8192 \
--hashlimit-htable-expire 300000 \
-j DROP
说明：
-
--hashlimit-mode srcip,dstport表示按源 IP 和目标端口联合哈希（若只限单个 API 端口可省略 dstport） -
--hashlimit-upto 100/sec是平均速率，超过即触发 DROP；--hashlimit-burst允许短时突发 -
--hashlimit-htable-size和--hashlimit-htable-max需根据预估并发请求数设置，避免哈希冲突或内存溢出 -
--hashlimit-htable-expire 300000（单位毫秒）延长哈希项有效期，防止高频请求因哈希项被清理而绕过限制
规避常见陷阱
hashlimit 易用但细节决定成败：
- HTTP 层路径匹配依赖
string模块，仅能匹配数据包载荷前 1500 字节（MTU 限制），HTTPS 流量无法解密匹配，慎用于 TLS 端口 - 规则顺序很重要：必须放在
ESTABLISHED,RELATED规则之后、具体服务规则之前，否则连接状态包可能被误限 - 不支持动态调整阈值，修改需重载规则；建议先用
-j LOG测试命中情况，再切为-j DROP - 哈希表默认存于内存，重启失效；如需持久化，需配合
iptables-save和开机加载脚本
验证与监控哈希表状态
运行中可通过 proc 文件系统查看实时状态：
cat /proc/net/ipt_hashlimit/api_get_limit输出包含当前哈希桶数量、平均桶长、最大桶长等，若 max_bucket_len 持续接近 htable-max，说明哈希表过载，需调大 --hashlimit-htable-max 或优化匹配维度。
也可用 watch -n 1 'cat /proc/net/ipt_hashlimit/api_get_limit | head -5' 实时观察变化趋势。
