iptables -m cluster 模块仅实现无状态VIP哈希分发，不提供防火墙策略、访问控制或连接管理功能，无法替代防火墙分流；其本质是PREROUTING链内的CLUSTERIP目标导向机制，依赖组播MAC和二层可达性，无健康检查与状态同步能力。
iptables 的 -m cluster 模块不能实现“无中心防火墙分流”，它也不是为“流量分流”设计的通用负载均衡工具。它的作用非常明确且有限：在多个节点间共享同一个虚拟 IP（VIP），让外部流量基于哈希自动落到某一个节点上，所有节点都监听该 VIP，但仅由哈希决定的那台真正处理连接——这是一种无状态的入站连接分发机制，不是防火墙，也不做策略控制。
下面直接说明它能做什么、怎么用、以及关键限制：
它的真实用途：共享 VIP 的无状态节点集群
- 所有节点绑定相同 VIP（如
192.0.2.100）到本地 dummy 或 loopback 接口 - 所有节点配置相同组播 MAC 地址（必须是组播，如
01:00:5E:00:00:01） - 每个节点运行一条
CLUSTERIP规则，指定自身编号和总节点数 - 客户端发往 VIP 的新连接，内核按哈希（sourceip / sourceip+port / 三元组）分配到某个节点
- 业务进程（如 nginx）直接监听该 VIP:port，无需反向代理
示例命令（4 节点中第 1 台）：
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 泛洪，或配置静态组播转发表，否则非首节点收不到包
- 无健康检查：节点宕机后流量仍会哈希过去，连接失败，需靠上层探测+人工剔除
- 不修改包内容：不 SNAT/DNAT、不改源/目的 IP、不干预连接状态
- 仅限 PREROUTING 链：无法用于转发或出向流量，也不能和 filter 表联动做访问控制
它做不到的事（常见误解）
- 不提供防火墙能力：不能 drop/reject 包，不支持 ipset、geoip、string 等扩展匹配
- 不支持自定义哈希逻辑：无法按真实网卡 MAC 哈希（模块不读取或使用物理 MAC）
- 不做连接保持：同一客户端 IP 的后续连接仍按哈希分配，可能落到不同节点（无 session stickiness）
- 无法实现“某类流量只进节点 A”：这类策略需前置路由设备或每个节点额外配 filter 规则，已超出 cluster 模块职责
替代思路：真需要“无中心分流”，可考虑组合方案
- 若目标是轻量级对外服务分发：用
iptables -t nat -j DNAT --to-destination 192.168.1.10-12:80（配合--state NEW）更直接 - 若需高可用与健康感知：引入 Keepalived + LVS/IPVS，或用 DNS 轮询 + 应用层探活
- 若在 Kubernetes 场景：kube-proxy 的 IPVS 模式才是为大规模 Service 设计的无中心转发方案，cluster 模块并不参与
它不是一个分流工具，而是一个让多节点“假装成一台机器响应 VIP”的协同机制。用对场景，它简洁高效；用错定位，就会陷入不可控的连接失败和策略真空。
