根本原因是client-reconfig-script执行时网络上下文缺失、权限不足或IP绑定冲突；它在哨兵进程用户身份下异步触发，不继承shell环境，且新主网卡可能未就绪、VIP绑定权限不足、参数错误导致绑错机器或双主，防火墙/NIC策略还可能拦截VIP流量。
Redis哨兵模式下VIP漂移通信失败，根本原因不是脚本没写对，而是client-reconfig-script执行时网络上下文缺失、权限不足或IP绑定冲突——它在哨兵进程用户身份下异步触发，不继承你的shell环境，也不保证目标网卡已就绪。
client-reconfig-script 执行时网络不可用
哨兵调用脚本的时机非常早：刚选出新主、还没等从节点完成同步，甚至新主的Redis进程都可能刚slaveof no one完。此时：
- 新主Redis服务未必已监听6379端口（尤其启用了
protected-mode yes且未配bind） - 脚本里用
ip addr add绑定VIP，但目标网卡（如eth1）可能尚未UP，或被NetworkManager接管导致冲突 - ARP通告用
arping -A失败，因为内核net.ipv4.conf.all.arp_ignore=1或防火墙拦截了ARP包
VIP脚本运行权限与上下文错位
client-reconfig-script由redis-sentinel进程以配置文件中user字段指定的用户（常为redis）执行，该用户默认无权操作网络设备：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
/sbin/ip和/sbin/arping通常不在redis用户的$PATH中，需写绝对路径 -
ip addr add需要CAP_NET_ADMIN能力，普通用户直接执行会报Operation not permitted - 脚本里硬编码
LOCAL_IP='192.168.56.101'，但容器或云主机中该IP可能属于lo或docker0，非真实业务网卡
哨兵传参错误导致VIP绑到错误机器
client-reconfig-script接收的6个参数中，第6个$6是新主IP，但这个值来自哨兵视角的SENTINEL slaves输出——如果某台哨兵缓存了旧拓扑（比如刚重启、未完成hello同步），它可能把已下线的节点IP当$6传给脚本：
- 脚本误将VIP绑到一台已宕机的机器，物理上无法响应
- 多哨兵同时触发脚本，两台机器都执行
ip addr add，造成VIP双主（ARP混乱、连接随机中断） - 没做幂等判断：脚本重复执行时，
ip addr add会报File exists但不退出，后续arping失败被忽略
防火墙/NIC策略直接拦截VIP流量
即使VIP成功绑定，客户端仍连不上，常见于：
- 云平台（阿里云/腾讯云）禁止非ECS实例主动绑定非分配IP，VIP会被底层丢弃
- 物理机启用
rp_filter=1（反向路径过滤），收到目的为VIP的包但回包路由不匹配，直接drop - iptables规则中
INPUT链未放行VIP的6379端口，或FORWARD链限制了VIP跨网段访问
真正棘手的点在于：这些失败不会出现在哨兵日志里。client-reconfig-script出错只返回非0码，哨兵最多记一条Failed to run client-reconfig-script，而网络层问题得去每台机器查ip addr show、arp -n、tcpdump -i eth1 host $VIP才能定位。别指望脚本里加echo就能看到输出——它被重定向到/dev/null。
