nodePort外部访问超时而ClusterIP正常，主因是外部流量无法抵达节点NodePort端口；需检查节点防火墙、安全组、访问IP准确性、kube-proxy状态与模式，以及云环境或宿主机网络策略限制。
NodePort 服务外部访问超时但 ClusterIP 内部正常，通常说明服务在集群内部工作良好，问题出在“节点网络层到服务端口”的链路上。核心原因不是应用或 Service 配置错误，而是外部流量无法顺利抵达 Pod 所在节点的 NodePort 端口。
检查节点防火墙是否放行 NodePort 端口
NodePort 默认范围是 30000–32767，kubernetes 不会自动配置系统防火墙。若节点启用了 firewalld（centos/RHEL）或 ufw（ubuntu），该端口很可能被拦截。
- CentOS/RHEL：运行 sudo firewall-cmd –list-ports 查看是否开放了对应 NodePort（如 30080）；未开放则执行 sudo firewall-cmd –add-port=30080/tcp –permanent && sudo firewall-cmd –reload
- Ubuntu：运行 sudo ufw status，确认状态为 inactive 或已允许该端口；若启用中，用 sudo ufw allow 30080
确认节点 IP 和端口可从外部直接访问
NodePort 必须通过节点的真实 IP（非 127.0.0.1、非内网 VIP、非云厂商控制台显示的“私有 IP”）加端口访问。常见误区：
- 用 localhost:30080 或 127.0.0.1:30080 测试 —— 这走的是本地回环，不经过 kube-proxy，不能代表外部访问效果
- 在云环境（如阿里云、AWS）中，安全组未放行 NodePort 对应端口（TCP 入方向）
- 节点绑定的是内网 IP，但你从公网尝试访问 —— 此时需确保该节点有公网出口，或通过 NAT/SLB 中转
建议在另一台局域网机器上执行：curl -v http://:30080，观察是否连接被拒、超时或返回响应。
验证 kube-proxy 是否正常运行且模式匹配
kube-proxy 负责将 NodePort 请求转发到后端 Pod。若它异常、未启动，或运行在 userspace 模式（已弃用且性能差），可能导致转发失败或不稳定。
- 检查状态：kubectl get pods -n kube-system | grep kube-proxy，确保所有节点上的 kube-proxy Pod 是 Running 状态
- 查日志：kubectl logs -n kube-system
，关注是否有 “can’t bind to port” 或 “no endpoints” 类报错 - 确认模式：ps aux | grep kube-proxy，查看是否含 –proxy-mode=iptables 或 –proxy-mode=ipvs（推荐）；避免 userspace 模式
排查云厂商或宿主机网络策略限制
部分环境存在隐藏限制：