curl -v http://host:portDNS、TCP 连接、应用响应分段打印,一眼看出断点。
约 1316 字大约 4 分钟
2026-05-14
“连不上某个端口”是个高频问题,但原因可能在任何一层:域名没解析、网络不通、服务没监听、监听地址不对、防火墙拦了。乱试只会越查越乱。这篇按固定的层次走一遍,原理见 网络排查流程。
按 DNS → 连通 → 端口 → 监听地址 → 防火墙 → 应用 的层次逐步排查端口连不上,并学会从 refused / timeout 反推问题所在层。
curl -v http://host:portDNS、TCP 连接、应用响应分段打印,一眼看出断点。
nc -vz host portrefused = 没人监听,timeout = 网络或防火墙拦了。
ss -lntp服务端跑,确认端口有进程监听、监听的是哪个地址。
sudo ufw status本机防火墙规则;云服务器还要查云安全组。
这是最快的分流。curl 或 nc 的报错直接指向不同的层:
| 报错 | 含义 | 大概率在 |
|---|---|---|
Could not resolve host | 域名没解析出来 | DNS(见下文第①步) |
Connection refused | 包到了目标主机,但那个端口没人监听 | 服务没起、或监听地址不对 |
Connection timed out | 包石沉大海 | 网络不通、或防火墙静默丢包 |
refused 和 timeout 指向的方向几乎相反——一个是“到了但没人接”,一个是“根本没到”。先看清报错,能省一半功夫。
① DNS:用域名连的,先确认域名解析对不对。
dig +short example.com # 解析到的 IP 对不对② 连通性:能不能到达目标主机。
ping <IP> # 通不通
nc -vz <IP> <port> # 端口层面能不能连③ 服务端:在监听吗、监听哪:到服务端机器上确认。
ss -lntp # 那个端口有没有进程在监听这一步最常抓到根因:服务监听在 127.0.0.1:8080,那它从设计上就只接受本机连接,外部当然连不上。要对外,得让它监听 0.0.0.0 或具体网卡 IP(见 IP、端口与协议)。
④ 防火墙:服务在监听、监听地址也对,还连不上——查防火墙。
sudo ufw status # 本机防火墙云服务器还有一层云安全组,在机器之外、由云平台控制。机器内防火墙全放行,外部还是连不上,多半是云安全组没放行——两层都要查(见 防火墙基础)。
⑤ 应用:端口能连上了,但应用返回异常(404/500)——那就不是网络问题,是应用本身,去看应用日志。
只在客户端查经常卡住。养成两侧对照的习惯:
curl -v、nc -vz、dig —— 我走到哪一步断的ss -lntp(在不在监听、监听哪)、防火墙规则、journalctl -u 服务很多问题在客户端怎么查都不明白,到服务端 ss -lntp 一看就真相大白。
排查用只读命令,改防火墙要格外当心
curl、nc、dig、ss、ping 都是只读探测,放心用。真正危险的是排查中“顺手改防火墙”——在你正 SSH 连着的远程机器上动防火墙规则,一条命令就可能把自己锁在门外。要改防火墙:先备份规则、留一个活动会话、确认 SSH 端口已放行(详见 防火墙基础)。改服务的监听地址(127.0.0.1 → 0.0.0.0)等于改变对外暴露面,改前确认该不该对外、有没有鉴权。
| 误区 | 更稳妥的做法 |
|---|---|
| 不看报错就乱试 | 先分清 refused(没人监听)还是 timeout(没到/被拦) |
| 一连不上就怪防火墙 | 先 ss -lntp 确认服务在监听、监听地址对不对 |
| 本机 curl 通就以为外部也通 | 服务可能监听在 127.0.0.1,只对本机 |
| 云服务器只查机器内防火墙 | 云安全组是机器外的另一层,两层都要查 |
版权归属:Shuo Liu