端口显示监听但连不上需验证三要素：端口真监听、进程存活、nc -zv实测通；注意ss输出PID为空、监听地址为127.0.0.1或::1导致外网不可达，以及OOM Killer和CLOSE_WAIT堆积问题。
端口显示监听但连不上？先确认“真监听”还是“假状态”
很多运维看到 ss -tuln | grep :80 有输出，就默认 Nginx 活着——其实可能只是进程崩溃后内核 socket 还挂着 LISTEN，或者 systemd socket 激活占着坑但服务根本没起来。
- 真正可靠的判断是三者同时成立：端口被监听 + 进程存活 + nc -zv 能通
- 用
nc -zv 127.0.0.1 80实测：返回succeeded!才算真活；失败则大概率是服务卡死、防火墙拦截或 SELinux 拦截 - 特别注意
ss -tulnp输出中 PID 为空的情况：可能是内核模块（如 iptables REDIRECT）、容器隔离、或权限不足（没加sudo）导致看不到进程
查不到占用进程？别只盯 ps aux | grep
ps aux | grep node 找不到进程，不等于端口没被占——Node.js 进程可能已退出，但 socket 还在 TIME_WAIT 状态；或者它根本不是用户态进程（比如 eBPF 程序、systemd socket 单元）。
- 优先用
sudo ss -tulnp | grep :3000查监听源头，看 Local Address 是127.0.0.1:3000还是*:3000——前者外网根本连不上，别怪网络 - 查 systemd socket：运行
systemctl list-sockets | grep :3000，再看对应xxx.socket和xxx.service的状态 - 进 Docker 容器查：宿主机上看不到容器内进程，得用
docker exec -it 容器名 ss -tuln
监听地址写错是最隐蔽的“端口正常但连不通”原因
配置里写了 listen 3000，你以为是 *:3000，结果某些框架（如 Express 默认、Redis 默认）实际绑定的是 127.0.0.1:3000，外网请求直接被拒，连防火墙都懒得拦。
- 检查服务配置文件中的
bind_addr、host、address类参数，别信文档默认值，实测为准 -
ss -tulnp输出第四列（Local Address）必须是*:3000或0.0.0.0:3000才支持外部连接；[::]:3000是 IPv6 全局监听，192.168.1.100:3000只响应该网卡流量 - Node.js 启动时若写
server.listen(3000, '127.0.0.1')，本地 curl 能通，curl 外网 IP 就 Connection refused
端口几分钟后消失？重点查 OOM Killer 和 CLOSE_WAIT
服务启动后监听正常，过几分钟 ss -tuln | grep :3000 就没了——不是代码逻辑问题，就是系统在“悄悄杀你”。
- 立刻执行
dmesg -T | grep -i "killed process"，如果看到类似Out of memory: Kill process 12345 (node)，那就是 OOM Killer 下的手 - 查 CLOSE_WAIT 是否堆积：
ss -tan state close-wait | wc -l，超过几百个基本说明应用没正确关闭 socket，常见于 Python/Node.js 中未 await 或未 .end() 的 HTTP 请求 - 临时缓解可调
/proc/sys/net/ipv4/tcp_tw_reuse，但治本得改代码：Node.js 用http.Agent开 keepAlive，Python requests 用 session 复用连接
最常被忽略的点：监听状态和连通性是两回事，而 ss 只告诉你内核视角的 socket 状态。别跳过 nc -zv 那一步，也别把 127.0.0.1:端口 当成“能对外提供服务”的证据。
