iptables hashlimit模块可内核态轻量限流，适合无应用层限流时兜底；需结合IP、端口等特征设计规则，不识别HTTP路径，典型参数含--hashlimit-above、--hashlimit-mode等，生产中须注意规则位置、NAT冲突及不可动态调参。
iptables 的 hashlimit 模块可用于对 API 接口做轻量、内核态的请求频率控制，适合在无应用层限流能力（如 Nginx 或业务代码未接入限流组件）时快速兜底。它不依赖用户态服务，延迟低，但粒度较粗，需结合 IP、端口、请求路径等特征合理设计匹配规则。
明确限流目标与匹配维度
API 限流需先定义“谁”在“什么路径”上“多久内”能发多少次请求。hashlimit 本身不识别 HTTP 路径，需配合其他模块提取特征：
- 若只按客户端 IP 限流：直接用
--src-ip+hashlimit - 若需区分不同接口（如
/loginvs/search）：需在 DNAT 或 TPROXY 前，用string模块匹配 Host 或 URI（仅适用于明文 HTTP），或改用前端代理（如 Nginx）做路径级限流 - 典型组合：对特定端口（如 8080）+ 特定目标 IP（API 服务器）+ 源 IP 做哈希限速，适用于反向代理后端或直连架构
基础语法与关键参数说明
核心命令结构如下（以每分钟最多 30 次请求为例）：
iptables -A INPUT -p tcp --dport 8080 -m hashlimit \--hashlimit-above 30/minute \
--hashlimit-burst 5 \
--hashlimit-mode srcip \
--hashlimit-name api_limit \
--hashlimit-htable-expire 60000 \
-j DROP
各参数含义：
-
--hashlimit-above：超过该速率即触发动作（DROP或REJECT） -
--hashlimit-burst：允许突发请求数（初始窗口容量），避免因瞬时抖动误杀 -
--hashlimit-mode：可选srcip、dstip、srcport、dstport或组合（如srcip,dstport），决定哈希键构成 -
--hashlimit-name：同一规则名共享哈希表，避免重复创建；不同规则必须用不同名 -
--hashlimit-htable-expire：哈希表项空闲超时毫秒数（如 60000 = 60 秒），影响内存占用和状态清理速度
实战建议与常见避坑点
hashlimit 在生产中易因配置不当导致限流失效或误伤：
- 规则位置很重要：必须放在
INPUT链且早于 ACCEPT 规则；若使用了 conntrack 或 state 模块，确保 hashlimit 在--ctstate NEW之后（否则对 ESTABLISHED 包也计数） - 避免哈希冲突：当
--hashlimit-mode srcip且大量用户走同一 NAT 出口（如企业宽带），会把所有用户视为一个源 IP，导致集体被限——此时应叠加端口或加应用层标识 - 不支持动态调整：修改限流阈值需删除旧规则再插入新规则；可用
iptables-save+iptables-restore原子更新 - 监控与验证：用
watch -n1 'cat /proc/net/ip_tables_matches/hashlimit'查看实时哈希表大小和命中次数；用iptables -L -v -n看 DROP 计数增长是否符合预期
补充：与应用层限流的分工建议
hashlimit 不是万能替代方案：
- 适合：防御扫描、暴力登录、简单防刷、资源兜底
- 不适合：精确到用户 Token、按 API Key 分级限流、响应码感知（如只限 401 请求）、动态配额（如 VIP 用户 1000/分钟）
- 推荐组合：Nginx（按 $uri + $remote_user 限流） + iptables hashlimit（全局源 IP 总量兜底） + 应用内滑动窗口（业务逻辑级精准控制）
