本质是路由冲突：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:80vs192.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 和一个动态分配地址，就以为配置没生效，其实压根没传进去。
