iptables -m cluster 仅实现无状态VIP哈希分发，不提供防火墙策略、访问控制或连接管理功能，无法替代防火墙分流；其本质是PREROUTING链内的CLUSTERIP目标导向机制，依赖组播MAC和二层可达性，无健康检查与状态同步能力。
直接用 iptables -m cluster 实现“无中心防火墙分流”在技术上不可行。cluster 模块本质是**无状态节点集群的入站负载分发机制**，不处理防火墙策略，也不提供“分流”控制逻辑，更无法替代防火墙功能。
cluster 模块的真实定位与能力边界
它仅用于在多个物理/虚拟节点间共享同一个虚拟 IP（VIP）和组播 MAC 地址，让外部流量基于哈希自动落到某一个节点——所有节点都监听同一 VIP，但内核根据哈希决定由谁真正处理该连接。关键点：
- 只工作在 PREROUTING 链，且必须配合 -j CLUSTERIP target
- 哈希依据只能是 sourceip、sourceip+sourceport 或三元组（含 destport），不支持自定义硬件 MAC 哈希，也不读取或修改真实网卡 MAC
- 不改变包内容、不 SNAT/DNAT、不记录连接状态、不干预 FORWARD/OUTPUT 流程
- 没有“防火墙”语义：它不 drop/accept/reject 包，只是把包导向本机协议栈的某个实例
所谓“无中心分流”的实际落地方式
若目标是让多台服务器以相同 VIP 对外提供服务，并由客户端连接自然分散（如 HTTP 短连接），可按如下结构部署：
- 所有节点配置相同 VIP（如 192.0.2.100）绑定到本地 dummy 接口或 loopback，同时配置相同的群集 MAC（必须为组播地址，如 01:00:5E:00:00:01）
- 加载 CLUSTERIP 规则（每个节点执行一次）：
iptables -t nat -A PREROUTING -d 192.0.2.100 -p tcp --dport 80 -m cluster --cluster-total-nodes 4 --cluster-local-node 1 --cluster-hash-init 0xdeadbeef --cluster-mode sourceip -j CLUSTERIP - 确保交换机允许该组播 MAC 泛洪（或配置静态组播转发表），否则流量无法到达非首节点
- 业务进程（如 nginx）直接监听 192.0.2.100:80，无需反向代理或额外负载均衡器
为什么不能当“防火墙分流”用
cluster 模块不具备策略决策能力：
- 它不检查源 IP 是否合法、不识别攻击特征、不匹配端口范围以外的字段
- 无法与 ipset、string、geoip 等扩展联动做访问控制
- 无法对已建立连接做动态限速或重定向（hashlimit、CONNMARK 等需另配）
- 若想实现“某类流量只进节点 A”，必须靠前置路由设备或在每个节点上叠加 filter 表规则——这已脱离 cluster 本身能力
大规模部署的关键约束
真正影响规模的是底层机制限制，而非配置复杂度：
- 所有节点必须二层可达，且共享广播域；跨子网需 IGMP 路由支持，实际运维难度陡增
- 哈希碰撞会导致连接倾斜，total-nodes 值变更会重哈希，引发大量连接中断
- 无健康检查：故障节点仍接收哈希命中流量，需依赖应用层心跳+外部探测+脚本自动清理 iptables 规则
- 连接跟踪（conntrack）仍按单节点维护，NAT/状态检测类业务无法共享会话表
