Linux 多 IP 配置冲突的排查方法

本质是路由冲突：linux按最长前缀匹配选路，同网段多IP导致出向路径混乱、ARP抑制或邻居表异常，引发ping通但ssh不通、http超时等现象。

为什么 ip addr add 后新 IP 不生效或旧 IP 失联

本质是路由冲突：Linux 内核按最长前缀匹配选路，多个同网段 IP 会导致出向流量路径混乱，甚至触发 ARP 抑制或邻居表异常。常见现象是 ping 通但 SSH 连不上、HTTP 请求超时、curl 返回空响应。

实操建议：

• 执行 ip route get 192.168.1.100（把目标地址换成你实际想访问的同网段地址），看它走的是哪个源 IP —— 这个输出里的 src 值才是当前默认出向地址
• 检查是否误用了 /32 掩码添加地址，例如 ip addr add 192.168.1.10/32 dev eth0；这会让内核认为该地址“只属于本机”，不参与同网段直连通信
• 确认没有重复执行 ip addr flush dev eth0 后只加回部分 IP，遗漏了原本的主 IP

多 IP 共存时 bind() 绑定失败或连接被拒绝

应用层调用 bind() 时指定 INADDR_ANY 或具体 IP，但系统可能因策略路由、rp_filter 或 socket 选项限制拒绝绑定。典型错误是启动 nginx 或 Python http.server 时报 Address already in use，即使 netstat -tlnp 显示端口空闲。

实操建议：

• 查 sysctl net.ipv4.conf.all.rp_filter 和对应网卡的值（如 eth0），设为 0 或 2，避免反向路径过滤丢弃进向包
• 确认应用是否显式绑定了某个 IP（比如 0.0.0.0:80 vs 192.168.1.5:80），多个 IP 下若只监听 0.0.0.0，连接进来时源地址仍可能被策略路由干扰
• 用 ss -tlnp | grep :80 看监听行里显示的本地地址，注意 *:80 表示通配，192.168.1.5:80 表示仅限该 IP

ip rule 和 ip route 配置后依然走错路由

自定义路由表 + 策略规则看似配好了，但实际流量没走预期路径，通常因为规则优先级、匹配条件太宽或未刷新路由缓存。最常踩的坑是忘了加 from 或 to 条件，导致规则对所有包生效，反而破坏基础连通性。

实操建议：

• 用 ip rule show 检查规则顺序，数字越小优先级越高；新增规则默认追加到末尾，很可能被前面的 from all lookup main 截断
• 规则中必须明确写 from 192.168.1.10/32（而非 /24）才能精准匹配某 IP 出向流量；to 字段只影响入向回复路径，别指望它控制发起请求的方向
• 改完规则后执行 ip route flush cache（旧内核）或 ip route flush table local（新内核），否则缓存可能让测试结果滞后

同一网卡多个 IP 在 docker 或 kubernetes 场景下失效

Docker 默认桥接网络和 CNI 插件（如 Calico、Flannel）会接管接口路由和 iptables 规则，原有主机侧的多 IP 配置容易被覆盖或绕过。现象包括容器能访问外网但无法被宿主机多 IP 中的非主 IP 访问，或者 hostNetwork: true 的 Pod 绑定不到指定 IP。

实操建议：

• 查 iptables -t nat -L POSTROUTING -n，看是否有 MASQUERADE 规则把你的多 IP 流量做了 SNAT，掩盖了真实源地址
• Docker 启动时加 --ip-masq=false 并手动配置 ip rule，否则它会强制对非默认路由表做 masquerade
• Kubernetes 中，若用 hostNetwork，Pod 内 netstat -tln 显示监听 0.0.0.0，但外部必须用宿主机主 IP 访问 —— 因为 kube-proxy 的 service IP 转发逻辑默认不感知 secondary IP

真正麻烦的是跨网络命名空间的路由同步问题：容器 netns 里看不到 host 上配置的 secondary IP，除非显式用 ip link set dev vethX netns 或 CNI 插件支持 multi-ip 模式。这点很容易被忽略，一查 ip addr 在容器里只有 127.0.0.1 和一个动态分配地址，就以为配置没生效，其实压根没传进去。