nodeport访问失败时，端口层面检查关键在于验证流量链路：先确认iptables/ipvs规则是否存在，再排查防火墙拦截、端口占用及外部连通性，任一环节中断均导致访问失败。
NodePort访问失败，端口层面的检查是关键一环。它不是简单看“端口有没有监听”，而是要确认流量能否真正抵达、被拦截、再转发到后端——整个链路中任何一环卡住，都会表现为“访问不到”。
查端口是否在节点上“可见”
NodePort不依赖进程主动监听（尤其在iptables/ipvs模式下），所以netstat -tuln 或 ss -tuln 查不到监听记录，不等于异常。重点应验证规则是否存在：
- iptables 模式：运行
sudo iptables -t nat -L KUBE-NODEPORTS -nv | grep :<nodeport></nodeport>，看是否有匹配规则 - ipvs 模式：运行
sudo ipvsadm -ln | grep :<nodeport></nodeport>，确认有对应虚拟服务和真实服务器条目 - 若两条命令都无输出，说明 kube-proxy 未生成规则——需检查其日志、模式配置及内核模块（如 ip_vs）是否加载
查端口是否被系统防火墙拦截
即使 Kubernetes 规则就绪，宿主机防火墙仍会先于 iptables nat 表生效，直接丢包：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- firewalld（RHEL/CentOS）：
sudo firewall-cmd --list-ports看 30000–32767 是否开放；未开则执行sudo firewall-cmd --add-port=<port>/tcp --permanent && sudo firewall-cmd --reload</port> - ufw（Ubuntu）：
sudo ufw status确认状态为 inactive，或已明确允许该端口 - 注意：云环境还需同步检查安全组/NACL，它们在网络入口处比系统防火墙更前置
查端口是否被其他进程占用或冲突
虽然 NodePort 不需要 bind，但若某进程已占用了目标端口（尤其是 userspace 模式 kube-proxy 或某些调试工具），可能干扰转发逻辑：
- 用
sudo lsof -i :<nodeport></nodeport>或sudo ss -tulpn | grep :<nodeport></nodeport>查占用进程 - 常见冲突源：残留的 nginx、httpd、旧版 kube-proxy、或手动启动的测试服务
- 若发现占用，终止对应进程后重启 kube-proxy Pod，强制重建规则
查端口是否能从外部实际连通
规则存在、防火墙放行，不代表网络可达。需跳出集群内部，模拟真实访问路径：
- 从另一台机器（非本节点）执行：
telnet <node-ip><nodeport></nodeport></node-ip>或nc -zv <node-ip><nodeport></nodeport></node-ip> - 若连接超时：大概率是网络层阻断（安全组、路由、NAT）
- 若连接被拒（Connection refused）：说明端口开放但无服务响应——此时应倒查 kube-proxy 是否运行、Endpoints 是否为空、Pod 是否真在 targetPort 上监听
