灰度发布失败的四大主因：iptables规则顺序错乱致流量不匹配；systemd重启引发服务注册中断；inotifywait因目录缺少x权限导致配置热加载失效；nginx未正确配置real_ip_module致X-Real-IP被覆盖。
灰度发布时流量切分不生效，iptables 规则顺序错乱
Linux 灰度发布依赖精准的流量控制，iptables 是最常用手段之一，但规则顺序直接影响匹配结果。新规则默认追加到链尾，若已有 ACCEPT 或 DROP 规则在前，后续灰度规则根本不会触发。
- 插入规则必须用
-I INPUT 1（或指定序号），而非-A INPUT - 检查当前链顺序：运行
iptables -L INPUT --line-numbers，确认灰度规则是否排在通用策略之前 - 避免混用
iptables和nftables：二者底层不兼容，共存时可能规则被静默忽略 - 生产环境务必先用
--dry-run（如支持）或在测试机验证规则效果，别直接iptables-restore上线
systemd 服务重启导致灰度实例被全量替换
用 systemctl restart 重启灰度服务时，旧进程被杀、新进程启动，中间存在不可控的空白期；若服务注册中心未做健康探针延迟或 deregister 保护，注册列表会短暂清空，流量瞬间打到其他节点——等于绕过灰度。
- 改用滚动更新：先
systemctl start myapp-gray@2启新实例，等就绪再systemctl stop myapp-gray@1 - 确保服务有
ExecStartPre检查端口占用，避免新实例启动失败却已注销老实例 - 注册中心客户端需配置
health-check-interval≥ 30s，且 deregister 延迟（如 Eureka 的eviction-interval-timer-in-ms）大于单次部署耗时
灰度配置热加载失败，inotifywait 监控路径权限不足
很多灰度方案靠监听配置文件变更实现动态切流，但 inotifywait 对监控路径有严格权限要求：不仅需要读取权，还要求对父目录有 execute 权限（即能 cd 进入），否则静默失败，无任何报错。
- 检查路径权限：运行
namei -l /etc/myapp/gray.conf，确认每一级目录都有x权限 - 不要监控软链接目标路径本身，应监控软链接所在目录——
inotifywait不跟随 symlink - 避免监控整个
/etc：inotify 句柄数有限，且易被无关变更干扰；精确到具体配置文件或其所在子目录 - 脚本中加兜底逻辑：每 5 分钟轮询一次
md5sum，防止 inotify 失效后配置长期不更新
灰度日志无法区分真实来源，nginx 透传 X-Real-IP 被覆盖
常见架构是 nginx → 灰度网关 → 后端服务，但若 nginx 配置了 proxy_set_header X-Real-IP $remote_addr 却没处理多层代理，真实客户端 IP 就会被上一跳代理地址覆盖，导致灰度策略（如按 IP 段分流）完全失效。
- 必须启用
real_ip_module，并配set_real_ip_from指定可信代理段（如公司内网 CIDR） - 用
$realip_remote_addr替代$remote_addr传给下游，它才是经过信任链还原后的客户端 IP - 验证是否生效：curl 请求后查看后端 access log 中记录的
X-Real-IP值，对比原始请求源 IP - 注意 Cloudflare 等 CDN 场景：需额外配置
real_ip_header CF-Connecting-IP
