redis集群节点通信故障的根本原因是集群总线端口（如16379，即客户端端口+10000）未开放，导致gossip协议心跳、故障检测等控制消息无法传输，节点被标记为fail或noaddr；须同步开放客户端端口与集群总线端口，并检查防火墙、安全组、protected-mode、bind及mtu一致性。
Redis从节点收不到主节点的PING心跳包？先查16379端口通不通
集群节点间根本不是靠6379端口传心跳——那是客户端端口。Redis集群用的是「集群总线」，默认在6379基础上加10000，也就是16379端口。这个端口专用于PING/PONG、故障检测、槽位迁移等控制消息。如果它被防火墙或云安全组拦了，从节点就收不到任何心跳，cluster nodes里直接显示fail或noaddr。
实操建议：
- 在从节点上执行：
telnet 16379（Linux）或Test-NetConnection -Port 16379（Windows PowerShell），看是否能连上 - 检查主节点本机防火墙：
sudo iptables -L INPUT -n | grep 16379；没输出就说明没放行，补一条：sudo iptables -I INPUT -p tcp --dport 16379 -j ACCEPT - 云环境（阿里云/AWS/腾讯云）必须同步检查安全组：入方向规则里，
16379端口要对所有其他集群节点IP开放
ping命令测不出问题，得用redis-cli --intrinsic-latency
ping测的是ICMP，而Redis心跳走的是TCP长连接，中间设备可能放行ICMP但限速甚至丢弃TCP包。你看到ping延迟1ms，redis-cli -c -h info cluster | grep cluster_stats_messages_ping_sent却显示大量超时，就是典型“协议层错位”。
更靠谱的做法是：
- 在从节点机器上跑：
redis-cli -h --intrinsic-latency 5，它会主动发心跳并统计抖动；若出现timeout或平均延迟>50ms，基本锁定TCP链路异常 - 同时对比执行：
ping -c 10；如果ping稳定但--intrinsic-latency频繁超时，问题一定出在6379或16379端口的TCP传输上 - 查内核重传指标：
grep TcpRetransSegs /proc/net/snmp | awk '{print $2}'，持续上升说明链路丢包严重
MTU不一致会让心跳包被分片后丢弃
Redis集群的PING包实际封装在Gossip消息里，单个可达1.5KB以上。若某段网络路径MTU设为1400，而节点系统MTU仍是1500，就会触发IP分片。很多VPC网关、安全组、物理交换机默认禁用分片或直接丢弃分片包，结果就是PING发出去了，PONG永远收不回来。
验证和应对：
- 用
tcpdump抓真实流量：tcpdump -i any 'port 6379 and (tcp[12:1] & 0xf0) > 0x50' -w heartbeat.pcap，Wireshark里过滤tcp.len > 0 and tcp.flags.syn == 0，看是否有IPv4 fragment或TCP segment not captured in full - 检查两端MTU：
ip link show | grep mtu，确保路径上所有节点（含宿主机、容器、VPC网关）MTU一致，建议统一设为1400或1450 - 临时规避：增大
cluster-node-timeout（比如调到30000），给分片重传留出缓冲时间，但这只是掩耳盗铃，根因还得修MTU
protected-mode和bind配置不当也会静默拒绝心跳
即使16379端口通了，protected-mode yes且bind未显式配置非回环地址时，Redis会拒绝来自其他节点的集群握手请求。现象是：新节点加不进集群、重启后无法重连、日志里反复出现Node not reachable或MEET timeout。
关键检查点：
- 确认配置文件中：
protected-mode no，或保留yes但必须配bind为具体内网IP（如bind 192.168.5.10），不能只写127.0.0.1或空着 - 若用Docker或K8s，必须显式设置
cluster-announce-ip和cluster-announce-port，否则节点广播的地址是容器内网IP，外部节点根本连不上 - 改完配置后，别忘了
redis-cli -p 6379 cluster meet 6379手动触发握手，而不是只等自动发现
MEET失败提示——这些细节比调优tcp_fin_timeout更能快速定位。
