VPS 端口不通怎么排查：双源实测拆开四层拦截

VPS 端口不通怎么排查，先记住一条判据：端口通不通只认 curl -v 输出里有没有 Connected to ... port ... 这一行，TCP 三次握手建没建成全看它；curl 退出码管的是这趟请求走没走完，不是端口开没开。端口不通分四层，服务没监听、系统防火墙、云安全组、出站策略。还有个常被漏掉的变量：换个探测源，同一个目标可能给出相反答案。这次广东电信与北京阿里云对同一 smtp.qq.com:25 各跑三轮，前者 3/3 建连、后者 0/3，结论正好反过来。

两台探测源是自有生产机，不是拿来卖的样机，得分开记。cn-probe-1 是 103.39.226.31，中国广东电信 AS4816 单线；cn-probe-2 是 8.140.30.240，中国北京阿里云 AS37963 BGP 多线。表 1 那组出站 TCP 建连采于 2026-11-10 09:12:42，命令是 curl -4 -v -sS -o /dev/null --connect-timeout 4 --max-time 8 -w '__CURL__%{http_code}|%{time_connect}|%{remote_ip}' <目标>，每个目标连跑 3 轮；表 2 那组公共 NTP 的 ICMP 采于 2026-11-10 09:09:46，命令是 ping -c 20 -i 0.2 -W 2。两台机器全程只读，没改过任何一行配置。查端口不通先得有把能信的尺子：只认 curl -v 输出里有没有 Connected to ... port ... 这一行，其余字段一律不作为依据，原始回显逐条落在下面两张表里。

端口不通分四层，换个地方测可能得到相反答案

端口不通不是一种病，是四层里某一层把包挡了：服务没监听、系统防火墙、云安全组、出站策略。多数教程教你怎么一层层往下查，这次要多一层意思：换个探测源，同一个目标可能给出相反答案。所以碰上端口不通先别急着改规则，先看你是从哪台机器、朝哪个方向测的，方向搞反了，四层排查全白做。

表 1 是这次最值钱的一张，6 个目标、两台源、每个目标 3 轮出站 TCP 建连，把端口不通拆到某一层的判据只有一个，看 curl -v 有没有打印 Connected to ... port ...。

表 1　出站端口 TCP 建连双源对照（实测，3 轮）

采集标注：命令 curl -4 -v -sS -o /dev/null --connect-timeout 4 --max-time 8 -w '__CURL__%{http_code}|%{time_connect}|%{remote_ip}' <目标>，cn-probe-1（中国广东电信 AS4816 单线 103.39.226.31）与 cn-probe-2（中国北京阿里云 AS37963 BGP 多线 8.140.30.240）各对每个目标连跑 3 轮，2026-11-10 09:12:42 采集。time_connect 单位秒，exit 为 curl 退出码原样照抄。判据只看 Connected to ... port ... 这一行。

广东电信源 smtp.qq.com:25 的 curl -v 原始输出，三轮都打了 Connected。

北京阿里云源同一目标，三轮都只有 Trying、没有 Connected。

先读第一行。smtp.qq.com:25 广东三轮都出现 Connected，time_connect 分别是 0.038495、0.008662、0.019954 秒，退出码却是 8；北京三轮只有 Trying 183.47.102.176... 和 Trying 121.14.22.61... 两行，一次 Connected 都没有，退出码 7。同一个出站端口，换源结论反过来，这就是表 1 最该被记住的一格。判断端口不通与否，得连探测源一起写进结论里。

再横着看 465、587、22。要判这三个目标算不算端口不通，同样只看 Connected 那行，别看退出码。广东这三个目标都 3/3 Connected、exit 8；北京 465、587 也是 3/3 Connected，只是退出码成了 55，github.com:22 两源都 3/3 Connected、exit 35。exit 8、35、55 没有一个是"连不上"，它们分别卡在协议应答、TLS 握手、发送数据这些 TCP 建连之后的环节。用 curl 去敲一个 SMTP 口或 SSH 口，本来就不该指望它把 HTTP 那套业务跑完，可这不影响三次握手已经成功。拿 curl 退出码当端口探测结果，会把这些明明通了的端口全记成不通，方向正好搞反。变量和退出码各自管什么，curl 官方手册里逐条列着退出码含义，7、28 确实属于没连上，8、35、55 则都在建连之后。

www.tkvps.com:443 两源 3/3 HTTP 200 是个基准，说明采集那会儿两台机器网络都正常、curl 也能正常把业务跑完，不是机器本身掉线才测出上面那些差异。少了这一格，端口不通的结论就容易赖到机器掉线上。

gmail-smtp-in.l.google.com:25 是另一半证据，也是端口不通最容易被一句话带过的地方。广东 1/3 建连，第 1 轮 exit 0、收到 SMTP 214 应答，建连时间 0.214682 秒，后两轮变成 Timeout was reached、exit 28；北京 0/3，三轮全是 Connection timed out after 4001 ms、exit 28。同一个目标，一个源偶尔能连、一个源一次没连上。广东那次建连为什么后两轮又超时，手上只有 3 轮，我判断不了，不硬给解释，照实写"1/3"就行。

判断端口通不通，只认 Connected to ... port ... 那一行。我第一次把这张表贴出来的时候，盯着广东 25 那行 exit 8 愣了一下，差点也把它归进失败那堆，往下翻到 Connected 原文才回过神。这类误判太常见，把端口不通的锅扣到退出码上，比扣到防火墙上还冤，因为 curl 的退出码是给"这趟请求成没成"设计的，不是给"这个端口开没开"设计的。这回翻到的端口不通排查教程，四层模型、命令、判别表都讲得挺全，篇幅从几百字到几千字的都有，但本次检索范围内未见真实双源对照数据，也就是没有一组"两个中国大陆出口 × 一组端口 × 原始 TCP 建连结果"的对照表。也因为这样，表 1 每个数字都标了源、时间、命令，能一条条对回原始回显。

症状对原因：一张判定表

四层听着抽象，落到报错词上就具体了。表 3 把常见症状、抓包看到的东西、最可能挡在哪一层、先动哪一步摆在一起。

表 3　症状 → 原因 → 四层判定表

ping 通但端口不通那一栏最常被误用，ICMP 回包和 TCP 握手根本是两码事。把这张表存下来，下回端口不通先对着症状找层，比从头翻命令快。还有一层容易混：域名先没解析对，表现也是连不上，那是另一条线，DNS 解析慢怎么排查 那篇专门讲这个，别和端口不通搅在一起。

是服务端没监听，还是你这边连不上

四层里前三层都在服务端，第四层和"你从哪测"有关。把这两头先分开，能省掉一半冤枉工。端口不通查半天还定不了性，多半就是没分这两头。服务端那侧的问题，换十台机器来测都一样；客户端这侧的问题，换一台机器结果就变。表 1 里 smtp.qq.com:25 广东 3/3、北京 0/3，就是后一种。

要把端口不通这么来回换着测，手上得有台自己说了算、随时能复跑的机器，按线路和时段归过的评测与历史读数 那页可以拿来对着挑，重点看有没有换出口、换线路做对照的余地。

服务端这侧：ss -lntp 看监听地址

一条命令先看服务在不在、绑在哪：

ss -lntp

0.0.0.0:8080 或 [::]:8080 是对所有地址都听，127.0.0.1:8080 只在本机回环上听，外部来连一律 refused。见过一个 Node 服务绑在 127.0.0.1:3000，开发机上 curl localhost:3000 秒回，客户那边浏览器一直转圈，防火墙翻了半天没毛病，ss -lntp 里那行 127.0.0.1:3000 摆着呢。改成 0.0.0.0 监听，这事就结了。本地能连、别人连不上，是端口不通里最容易被误判成防火墙的一种，先怀疑监听地址，别一上来就改防火墙。

进程起不来有时也不是配置写错，是机器自己喘不上气。负载高怎么排查 和 磁盘满了怎么清 是这时候该翻的两篇，磁盘写满导致服务启动失败，表象也是端口不通。

客户端这侧：双源对照怎么读

同源、同目标、只换出口，结果变了，锅就不在服务端配置，这类端口不通得往链路上算。表 1 里 smtp.qq.com:25 广东能连，说明目标端口本身开着、对端服务也在听，北京连不上只能往链路和出口策略上找，而不是回头去改 smtp.qq.com 那台机器的什么设置。分清服务端和客户端这件事，光讲方法论不够，得有第二双眼睛，这次的第二双眼睛就是表 1 那两列。

换条路之后要量延迟，看 延迟怎么测才准；要弄清出站走的是哪条路，翻 去程路由怎么查；包一大就卡住、小包又正常，顺手核一下 路径 MTU 怎么查怎么设。这三样都不改端口规则，却能解释一部分"端口时通时不通"。

VPS 端口不通怎么排查：服务压根没在听

refused 和 timeout 不是一回事，端口不通先分这两种再谈别的。refused 是目标主机回了 RST，明确告诉你这个端口没人接；timeout 是包石沉大海，多半在半路被丢了。前者基本锁定服务监听这一层，是四层里最好查的一种端口不通，因为它有句明确的拒答。

服务没在听导致的端口不通，查的方向就那几个：进程还在不在，ss -lntp 里有没有那一行，日志里有没有启动失败，端口是不是被别的进程先占了（ss -lntp | grep :端口 看是谁占着）。跑容器的还得看端口映射，-p 127.0.0.1:8080:80 这种只 publish 到回环的写法，跟前面那个绑 127.0.0.1 的 Node 服务是一个毛病，从外面看就是端口不通。

这层修起来也最直接：把进程拉起来、把监听地址改对、把占用的进程挪开，改完 ss -lntp 复核一眼，再去外部跑一次探测，确认端口不通是不是真没了。要是本机 curl 127.0.0.1:端口 已经能回，就别再在这一层耗了，往下走。

系统防火墙拦了：抓包有 SYN，等不来 SYN-ACK

外网 timeout，在服务端抓包能看到客户端的 SYN 进来了、却没有 SYN-ACK 出去，多半是系统防火墙把包丢了，这是端口不通里最常见的一层。这一层的工具就那几套，先只读地看现状：

ufw status verbose
firewall-cmd --list-all
iptables -L -n -v

放行时最容易漏的是生效方式：firewalld 不加 --permanent 重启就没，加完还得 --reload；ufw 的 allow 要确认规则真的启用了；iptables 讲究顺序，一条靠前的 DROP 能把后面所有 ACCEPT 全盖掉。改完别凭感觉，用 ss 和抓包各看一眼，端口不通还在不在，一眼的事。

判这类端口不通，服务端抓包用这条，视角要站对：

tcpdump -ni any host <客户端IP> and port <端口>

看得见 SYN 进、等不来 SYN-ACK 出，包是在这台机器里被拦的，往 ufw、firewalld、iptables 上找；连 SYN 都抓不到，说明包压根没到网卡，那得往上一层去。改完规则立刻测仍不通，十有八九是没 reload、规则顺序不对，或者旧的长连接还挂着，等一下再复跑。表 3 里第二行和第三行的分界，就靠这一眼抓包，端口不通卡在哪一层也就定了。

云安全组没放行：抓包连 SYN 都看不到

安全组在实例外面，包进不来，服务端 tcpdump 一条 SYN 都抓不到，这是跟上一层最直的分界。端口不通查到 SYN 都看不见，基本就该转到这一层了。站内此前少有专门讲这层的，这里多写两句。

给一台新机器开 8080 面板那次我记到现在：ufw allow 8080 敲了，firewall-cmd --permanent --add-port=8080/tcp 加了，--reload 也跑了，ss -lntp 里 nginx 明明白白听着 0.0.0.0:8080，本机 curl 127.0.0.1:8080 秒回。可外网 telnet 公网IP 8080 一直超时。一下午全耗在防火墙上，末了才发现控制台安全组入站规则压根没加 8080。这类端口不通最冤，改的全是没拦包的那几层。系统防火墙改得越勤，越想不起去看控制台那一层。

安全组这层值钱的不是命令，是端口不通时该挨个问的四个必查字段：绑定对象，规则是不是真绑在这台实例、这块网卡上；方向，只配了入站、出站没管，或者反过来；优先级，有没有一条更靠前的 deny 把放行盖了；源地址，是不是只放行了某个网段而不是 0.0.0.0/0。四项挨个过一遍，比反复 ufw reload 有用。端口不通查到这里，基本就剩控制台这一处没看了。

买机器时能不能在控制台自助放行安全组、规则改完多久生效，各家差别不小，主机商与线路资料 那页按这个维度归过一遍。排障前先确认自己有这个权限，省得像上面那样白忙一下午。

出站 25 被封：发信方向最容易被搞反

前三层说的都是别人连进来，第四层反过来，是你的机器连出去，端口不通的方向到这里整个调了个头。收信是别人连你的 25，属入站；发信是你的机器连对方的 25，属出站。不少云厂商默认封掉出站 25 防垃圾邮件，这跟入站放行没半点关系，也是端口不通里最容易被搞反方向的一层。

站点注册确认邮件发不出去那回，Postfix 日志里一行 connect to gmail-smtp-in.l.google.com:25: Connection timed out，队列堆了一屏，看着又是一桩端口不通。运维把入站 25、465、587 全放行了一遍，规则加了三四条，邮件照样不动。方向反了：发信是出站连对方 25，入站放行管的是别人连进来。真要做的是换 587 提交口配好认证，或用 465 隐式 TLS，再不行走邮件推送 API、或者找商家提工单申请解封出站 25。反复改入站规则，一下午又没了。

表 1 里这层端口不通的证据很齐：smtp.qq.com:25 广东 3/3 建连、北京 0/3，gmail-smtp-in.l.google.com:25 广东 1/3、北京 0/3，可同一批目标里 465、587、22、443 两源都 3/3 建连。被卡的是 25 这个出站方向，不是这台机器连不上外网，也不是对面服务全挂了。那几格一次没建连的，只说明该目标在当前源未建连，不反推对面机器宕机或商家服务不可用，端口不通归到哪一层得有原始回显撑着。

换源结论会反转，也不止端口不通这一组。表 2 是同一时段另一组只读探测的旁证，ping -c 20 -i 0.2 -W 2，2026-11-10 09:09:46 采集，两台源各对每个目标发 20 包。

表 2　公共 NTP 主机双源 ICMP 旁证（实测）

ntp1.aliyun.com 广东 24.187 ms 比北京 27.234 ms 快，换到 ntp.aliyun.com 又成了广东 39.294 ms 慢过北京 11.568 ms，方向跟端口那组一样会翻。time.google.com 两个源都未收到 ICMP 回应，这里只记这一个事实，不往服务不可用上猜。端口不通那组也一样，结论都得连着源一起写。这组完整数据留给时间同步那篇，本篇只借它说明换源会反转，不铺开。

VPS 25 端口被封 这类端口不通，落到动作上就三样：换 587 或 465 提交口、配好 SMTP 认证、走邮件推送 API 或提工单。别再回头改入站规则了。

一套能抄的排查顺序：从 ss 走到控制台

顺序比工具重要，端口不通尤其怕一上来就改错层。按离服务最近的一层往离你最近的一层查，别一上来就动安全组。装环境换源、解析域名、放行端口是三件不同的事，卡在哪一步得分清，把下载源换成国内镜像 解决的是下载慢，不是端口不通。

ss -lntp
curl -v 127.0.0.1:<端口>
nc -zv <公网IP> <端口>
tcpdump -ni any port <端口>

一步一判，别中途换尺子，端口不通最忌这个：

1. ss -lntp：服务在不在、绑的是 0.0.0.0 还是 127.0.0.1。
2. 本机 curl -v 127.0.0.1:端口 或 nc -zv 127.0.0.1 端口：本机能不能连，先把服务层排除掉。
3. 换一台外部机器 nc -zv 公网IP 端口，有条件的用 tcping：本机通、外部不通，进第二、第三层。再换个出口把第 3 步重跑一次，就是表 1 那个思路。
4. 服务端 tcpdump -ni any port 端口：看 SYN 进没进、SYN-ACK 出没出，分开第二层和第三层。
5. 控制台安全组：绑定对象、方向、优先级、源地址四项过一遍，改完等生效再复测。

每一步都盯着同一个判据：有没有 Connected to ... port ...，或者抓包里有没有 SYN。别半路换成"curl 退出码是几"或"ping 通不通"，端口不通的判据一换，前几步就白跑了。表 1 那批数据之所以能拿来对照，就是因为 6 个目标、两台源、每源 18 次运行合计 36 次 curl，用的是同一把尺子。真碰到本机通、别人不通，别急着下结论，先问一句对方是从哪台机器测的。

常见问题

ping 通但端口不通，算不算矛盾？

不算。ICMP 回包和 TCP 握手是两码事，ping 只说明那台主机对 ICMP 有回应，跟某个端口开没开没关系。按表 3 往第二、第三层查，别拿 ping 的结果给端口判死刑。端口不通还得靠 Connected 那行定。

为什么我测和别人测不一样？

表 1 就是答案，端口不通这种事本来就带探测源。同一个 smtp.qq.com:25，广东电信 3/3 建连、北京阿里云 0/3，服务端是同一个，差别在出口。换源结论会翻，别把一台机器的结果当通用结论发给别人，也别因为自己这边通就断定对方配置错了。

改完规则立刻测，怎么还是不通？

多半是没 --permanent、没 --reload，或者 iptables 规则顺序被前面的 DROP 盖了；安全组那边生效也有一点延迟，旧的长连接还可能挂着没断。等一下再用 ss 和 tcpdump 复核一遍，比反复改规则管用。端口不通没走，多半是改的那层根本没生效。

25 换 587 行不行？

行，出站 25 被封时这是最省事的一条。587 提交口配好认证，或改 465 隐式 TLS，再不行走邮件推送 API、找商家提工单。表 1 里 465、587 两源都 3/3 建连，就是这条路的依据。别再反复改入站规则。

只有两个源，够不够下结论？

够回答"会不会因为换源而反转"，不够给任何别的运营商或地域下普遍结论。两个源是这次的全部，别的出口没测就不推断。表 1 里那些一次没建连的格子，只说该目标在当前源未建连，不反推对面机器宕机、也不反推商家服务不可用。两个源的端口不通对照只够说明会不会反转。

端口通了，返回 502 或空响应，算不算没查完？

四层算查完了，这类已经不算端口不通，TCP 已经建连，剩下是应用或上游的事。表 1 里 smtp.qq.com:465 北京 exit 55、github.com:22 两源 exit 35，都是建连之后的应用层结果，别再回头改防火墙。拿 Connected 那行判完，就往应用日志去。

数据边界与口径说明

只有两个源：cn-probe-1 中国广东电信 AS4816 单线 103.39.226.31，cn-probe-2 中国北京阿里云 AS37963 BGP 多线 8.140.30.240，别的运营商和地域这次没测，端口不通的结论也只在这两个源内成立。表 1 采于 2026-11-10 09:12:42，命令 curl -4 -v -sS -o /dev/null --connect-timeout 4 --max-time 8 -w '__CURL__%{http_code}|%{time_connect}|%{remote_ip}' <目标>，每个目标连跑 3 轮，判据只看 Connected to ... port ...，time_connect 单位秒，exit 原样照抄；表 2 采于 09:09:46，命令 ping -c 20 -i 0.2 -W 2。两台源全程只读，没改过任何配置，所以改前改后两批数据这次没有，"放行之后提升多少"这类对比一个字都不给。手上也没有商家真机，CPU、磁盘、UnixBench、带宽跑分、流媒体解锁这些一项没测，不写。表 2 那组只作换源反转的旁证，完整数据留给时间同步那篇。

VPS 端口不通怎么排查，说到底是把两件事拆开：先认准 Connected to ... port ... 这一行判 TCP 建没建连，再按四层定位挡在哪；碰上本机通、别人不通，就换第二个出口复跑一次，别只信一台机器的答案。端口不通查到头靠的还是原始回显，不是感觉。表 1 那 36 次运行里，广东 25 端口 3/3 建连、北京 0/3，就是这条顺序最直接的理由。

机器到手之后，能自己核的几格先核完，剩下的等跑一遍再说。挑机器那阵子，把 在售套餐与优惠 和这份顺序摆一起看，比收藏十张"一键排查清单"有用。我习惯把表 1 那两列贴进工单模板，客户说端口不通时先问一句"你从哪台机器测的"，往往比先翻防火墙省事。