iptables -m hashlimit 本身不提供分布式能力，仅在单机内核维护哈希表与令牌桶；所谓“分布式均权”实为各节点独立部署一致规则（如--hashlimit-mode srcip + accept/drop闭环），实现同一源ip在任意节点均受相同限速约束，兼顾轻量、可靠与兜底防护。
iptables -m hashlimit 本身不提供分布式能力，它只在单台 Linux 主机的内核中维护哈希表与令牌桶，无法跨机器同步状态。所谓“在分布式环境下对每个源 IP 的连接均权”，实际是指：在多台服务器组成的集群前，让每台节点独立、一致、公平地对同一源 IP 进行限速或分流控制，避免某台节点被单 IP 过载，从而实现类“均权”效果。
这不是靠 hashlimit 自身实现“分布式”，而是通过设计粒度 + 链路闭环 + 部署一致性，让各节点行为可预期、不冲突、不漏放。
明确“均权”的真实含义
在分布式场景下，“对每个源 IP 连接均权”通常指：
- 同一客户端 IP 访问集群中任意节点时，都受到相同强度的连接/请求频率限制；
- 不因负载均衡随机落到某台机器就绕过限流（即不能只在入口网关限，后端节点也需兜底）；
- 各节点限流逻辑一致，避免某台宽松、某台严苛导致整体策略失效。
hashlimit 正是为此类“单点兜底+全局语义统一”场景设计的轻量级方案。
按源 IP 独立限速：最简可靠配置
这是最常用、最易落地的均权基础。每台服务器执行完全相同的规则：
iptables -A INPUT -p tcp --dport 8080 -m hashlimit \ --hashlimit-name perip-api \ --hashlimit 10/sec \ --hashlimit-burst 30 \ --hashlimit-mode srcip \ -j ACCEPT iptables -A INPUT -p tcp --dport 8080 -j DROP
-
--hashlimit-mode srcip：确保每个源 IP 单独计数，互不影响； -
--hashlimit 10/sec：长期平均上限为每秒 10 个新建连接（或匹配包）； -
--hashlimit-burst 30：允许短时突发（如页面加载触发多个请求），但不会持续突破； -
必须成对出现：
ACCEPT后紧跟无条件DROP，否则未匹配包会继续走默认策略，限流形同虚设。
所有节点部署相同规则，就自然实现了“同一 IP 在任一节点都受同样约束”，即事实上的连接均权。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
提升一致性：命名与参数需严格统一
hashlimit 的哈希桶由 --hashlimit-name 唯一标识，内核据此创建 /proc/net/ipt_hashlimit/<name></name> 状态文件。若不同节点用了不同 name 或不同 burst 值，会导致：
- 监控指标不可比（比如 A 节点看
perip-api，B 节点看api-limit）； - 运维排查时误判为“某台异常”，实则是配置不一致。
建议：
- 所有节点使用相同
--hashlimit-name（如svc-api-perip）； - 速率和 burst 值通过配置中心统一下发，而非人工写死；
- 定期校验：
ssh nodeX 'cat /proc/net/ipt_hashlimit/svc-api-perip 2>/dev/null | head -5'观察是否都有活跃条目。
避免常见陷阱：哪些做法会破坏“均权”
混用
dstport或dstip作为 mode
例如--hashlimit-mode dstport：同一 IP 访问 8080 和 8081 会进不同桶，看似“分散”，实则失去对 IP 的统一约束，攻击者可轻易绕过。只在负载均衡器上做 hashlimit，后端节点不做
若 LB 未做连接级限流（如用 LVS DR 模式），流量直接透传，后端节点毫无防护，“均权”只剩一层纸。burst 设置过大（如
burst 500）
短时洪峰仍能打满单节点连接数，失去限速意义；建议 burst ≤ rate × 3，兼顾体验与防护。未禁用 conntrack 对 ESTABLISHED 包的影响
hashlimit 默认匹配所有包（包括已建连的 ACK、数据包）。若只想限新连接，应加-m state --state NEW（注意：state模块在较新内核中已被conntrack替代，推荐用-m conntrack --ctstate NEW）。
补充说明：为什么不用“分布式限流中间件”？
Redis + Lua、Sentinel 等方案确实能实现跨节点状态共享，但代价是：
- 引入外部依赖，增加运维复杂度；
- 每次请求多一次网络 RTT，影响延迟敏感接口；
- 故障时可能降级失效，而 hashlimit 是内核态、零依赖、始终在线。
因此，hashlimit 不是“替代分布式限流”，而是“低成本兜底”：它不追求强一致，但保证“绝不放任单 IP 撑爆任一节点”，这对防御扫描、爬虫、简单 CC 已足够有效。
不复杂但容易忽略。
