cluster-node-timeout应设为实测P95延迟的2～3倍：局域网5000～8000ms，跨机房或K8s不低于12000ms；必须全节点配置一致，仅CONFIG SET不持久，需修改redis.conf并CONFIG REWRITE或重启生效。
cluster-node-timeout 设多少才不容易被抖动误判
设太小，一次丢包就触发 fail?；设太大，真挂了要等很久才发现。关键不是拍脑袋定值，而是看实测延迟再留余量。
- 用
redis-cli -c -h NODE_A -p 6379 cluster nodes观察各节点间ping-sent和pong-recv的时间差，取 P95 最大值 - 局域网环境：P95 延迟 ×2～3 倍，常见设为
5000～8000 - 跨机房或 K8s 环境：不低于
12000，容器网络栈叠加容易放大抖动影响 - 必须所有节点一致，不一致会导致状态同步卡住甚至脑裂
CONFIG SET cluster-node-timeout 生效但重启就失效？
很多人执行了 CONFIG SET cluster-node-timeout 10000，看到 CONFIG GET 返回正确值就以为搞定了——其实只是内存生效，配置文件没动，一重启就回默认 15000，而你的实测 RTT 可能才 80ms，等于容忍不到 2 次丢包就下线。
- 确认当前加载的配置路径：
redis-cli INFO | grep config_file - 修改对应
redis.conf中的cluster-node-timeout行，再执行CONFIG REWRITE（仅对通过CONFIG SET修改过的参数生效） - Docker/K8s 场景要特别注意：entrypoint 脚本可能覆盖挂载的 conf，得进容器验证实际内容
为什么 cluster_stats_messages_received 突降却 ping 得通？
能 ping 通、telnet 通 6379 端口，不代表集群总线（默认 16379）通畅。Gossip 消息走的是独立 TCP 连接，中间设备常悄悄限速或老化连接。
- 用
tcpdump -i any port 16379抓包，看有没有持续的PING/PONG流量 - 检查云厂商安全组、iptables、SELinux 是否对 16379 端口做了连接数限制或 conntrack 老化（常见设为 300 秒，而 Gossip 心跳间隔是秒级）
- 在任意两节点间跑
tcpping -x 100 -p 16379 target_ip，比普通 ping 更贴近真实通信链路
看到 fail? 就马上 redis-cli --cluster fix？
别急。fail? 是主观下线标记，只代表“这个节点暂时没收到响应”，可能是 1 秒内的瞬时抖动。集群会自动重试，很多情况下下一秒就恢复了。盲目 --cluster fix 可能中断正在自愈的连接，反而加重问题。
- 先执行
redis-cli -c -h NODE_IP -p PORT CLUSTER NODES | grep fail，区分fail?和fail（后者才是客观下线，需人工介入） - 如果大量节点同时出现
fail?，但INFO replication显示主从同步正常，优先排查网络层而非节点本身 - 频繁
fail?+cluster_stats_messages_sent高但received低，基本锁定接收端处理不过来（CPU 高、缓冲区溢出或丢包）
真正容易被忽略的是：Gossip 不是“心跳检测”，而是“状态广播+探测”的混合机制。一次 fail? 可能由发送端延迟、接收端卡顿、中间链路丢包中任一环节引发，单看一个指标永远定位不准。必须把 cluster-node-timeout、cluster_stats_messages_*、tcpdump 在 16379 端口的表现三者交叉比对，才能稳住抖动下的主观下线判断。
