这类问题我又碰上了一次。阿里云 ACK 1.26 集群默认 Service CIDR 是 172.20.0.0/16，公司 IDC 的办公网正好也是这一段，Pod 里访问 ClusterIP 全部超时，从节点上 curl 也一样，换 NodePort 就能通。
第一反应是「kube-proxy 的规则被同网段的路由优先级盖住」，验证下来不成立。
排查方向其实有限，先把可能性排一排。Service CIDR 与 IDC 内网网段重叠，路由把流量送去了办公网；节点路由表里 172.20.0.0/16 指向了物理网关；集群创建时没规划网段，上线后才发现和现有环境冲突。
上来先确认冲突的网段和实际路由
ip route get 172.20.0.10 && kubectl cluster-info dump | grep service-cluster-ip-range再往下看 kube-proxy 有没有生成对应规则
iptables-save | grep 172.20.0新建集群时换一个不冲突的 Service CIDR
kubeadm init --service-cidr 10.96.0.0/12老集群核对所有 Service 地址分布
kubectl get svc -A -o wide改之前先确认了最近有没有人动过配置，避免白查一遍。
改完先别撤，确认这几项。Pod 内 curl ClusterIP 返回正常，ip route get 指向本地 kube-ipvs0 或 iptables 链，不再落到物理网关。
提醒一点。Service CIDR 创建后基本不能改，规划阶段就要和网络团队对齐，Pod CIDR 和 VPC 网段也要一起核对。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。