Linux端口不通怎么排查？服务监听、Docker映射与防火墙检查教程

在 Linux 服务器上部署网站、管理面板或 Docker 应用时，经常会遇到一种情况：程序显示已经启动，浏览器却始终打不开页面。

有时提示“连接被拒绝”，有时一直等待后超时。造成这些现象的原因可能在服务监听、容器端口映射、系统防火墙，也可能在云平台安全组或网络路径上。

排查时，可以按照“服务是否监听、本机能否访问、外部请求能否到达”的顺序逐步缩小范围。

本文以 TCP 8080 端口上的 HTTP 服务为例。请将示例端口替换为实际端口；UDP 服务需要使用对应协议的测试方法。

一、先确认服务有没有监听端口

在服务器上执行：

sudo ss -lntp 'sport = :8080'

参数含义：

• -l：只显示监听状态的套接字。
• -n：直接显示数字地址和端口。
• -t：查看 TCP。
• -p：显示关联进程。

对于直接运行在宿主机上的服务，如果没有监听记录，应先检查程序是否正常启动、端口是否配置正确，以及启动日志中是否存在报错。

如果应用运行在 Docker 容器中，还需要检查后面的端口映射，不能只凭宿主机 ss 没有输出就判断服务未启动。

监听地址同样重要

找到端口之后，要继续查看它监听在哪个地址上。

如果程序只监听 127.0.0.1:8080，直接访问“服务器公网 IP:8080”通常无法连接。

不过，如果网站通过同一台服务器上的 Nginx 反向代理访问这个后端，监听回环地址可能正是预期配置。此时应该检查对外的 80、443 端口和反向代理配置。

二、在服务器本机测试HTTP服务

确认监听情况后，在服务器上执行：

curl --noproxy '*' -v \
  --connect-timeout 5 \
  --max-time 10 \
  http://127.0.0.1:8080/ \
  -o /dev/null

这条命令会显示连接过程和响应头，最多等待 10 秒，并跳过代理环境变量的影响。

如果程序只绑定了某个具体的网卡 IP，应将 127.0.0.1 替换为那个地址。

根据输出判断问题发生在哪一步

收到 HTTP 错误码，说明已经与某个 HTTP 服务完成了通信。 如果请求经过 CDN 或反向代理，这个响应也可能由中间层返回，需要进一步确认响应来自哪里。

这里的 curl 命令针对 HTTP 服务。测试 HTTPS 时应使用正确的 https:// 地址；SSH、数据库及游戏服务则应使用相应客户端或协议工具。

三、从外部网络测试同一个端口

本机测试通过后，再从自己的电脑或另一台服务器发起请求。

下面的 203.0.113.10 是文档示例地址，请替换成服务器真实公网 IP：

curl --noproxy '*' -v \
  --connect-timeout 5 \
  --max-time 10 \
  http://203.0.113.10:8080/ \
  -o /dev/null

如果本机能够访问，外部访问失败，可以重点检查：

1. 服务是否只监听回环地址。
2. Docker 是否发布了正确的宿主机端口。
3. 系统防火墙和云端安全组是否允许访问。
4. 公网 IP 或 NAT 映射是否指向这台服务器。

注意，服务器访问自己的公网 IP，不能完全代替外部网络测试。部分网络环境存在 NAT 回流限制，可能出现外部能够访问、服务器访问自身公网 IP 却失败的情况。

四、Docker容器运行正常，为什么端口仍然不通？

容器显示 Up，只能说明容器正在运行。还需要确认应用已经准备好，以及端口是否正确发布。

进入项目的 Compose 文件所在目录，执行：

docker compose ps -a

假设服务名为 web，容器内应用使用 TCP 80 端口，可以继续查看映射：

docker compose port web 80

查看最近的应用日志：

docker compose logs --since=10m --tail=100 web

请将 web 和 80 替换成实际的服务名与容器端口。

分清宿主机端口与容器端口

例如，看到下面这样的映射：

0.0.0.0:8080->80/tcp

表示外部访问宿主机的 8080 端口，再由 Docker 转发到容器的 80 端口。

如果显示：

127.0.0.1:8080->80/tcp

则该映射绑定在宿主机回环地址上，适用于宿主机上的反向代理访问。

在常见的 bridge 网络模式下，如果只有：

80/tcp

通常只是声明了容器端口，没有显示发布到宿主机的映射。镜像中的 EXPOSE 也不会自动完成公网端口发布。

容器内部也要检查监听地址

即使映射正确，容器内的应用如果只监听容器自己的 127.0.0.1，也可能无法接收经容器网卡转入的请求。

此时需要根据应用文档，检查它是否监听了容器网卡地址或适当的通配地址。

另外，Docker 可以通过 NAT 规则完成端口转发，并不一定依赖宿主机上的用户态监听进程。因此，检查容器端口时，应结合 Docker 映射、应用日志和实际请求结果判断。

五、检查系统防火墙和云端安全组

端口监听、应用响应和 Docker 映射都正常后，再检查访问控制规则。

使用UFW的服务器

查看状态及规则：

sudo ufw status verbose
sudo ufw status numbered

对于已经启用 UFW、且确实需要允许指定客户端访问的宿主机服务，可以添加针对性规则。

下面的 198.51.100.10 是示例客户端地址，使用前需要替换：

sudo ufw allow proto tcp \
  from 198.51.100.10 \
  to any port 8080

这条规则允许指定来源访问 TCP 8080。

如果 UFW 显示未启用，也不能据此认定服务器不存在其他过滤规则，还可能有 nftables、其他管理工具或云端防火墙参与处理。

使用firewalld的服务器

先查看正在使用的区域：

sudo firewall-cmd --get-active-zones

再检查对应区域的配置。下面以 public 为例，应替换成实际区域：

sudo firewall-cmd --zone=public --list-all

检查时需要同时查看已允许的服务、端口及其他规则。修改规则后，还要区分运行时配置和永久配置，避免重启后设置失效。

云端规则也需要检查

如果服务器平台提供安全组或云防火墙，应确认规则绑定到了正确的实例或网卡，并核对：

• 协议是否为 TCP。
• 目标端口是否为实际对外访问的端口。
• 来源地址是否覆盖当前客户端公网 IP。

对于 8080:80 这样的 Docker 映射，外部请求访问的是宿主机 8080，云端规则应围绕对外端口检查。

Docker 发布端口还存在一个容易忽略的问题：容器流量可能绕过 UFW 常规规则。 因此，不能仅凭 UFW 的允许或拒绝记录判断容器端口是否开放，应结合 Docker 转发规则和云端访问控制一起确认。

六、仍然无法定位时，用tcpdump确认请求是否到达

如果本机访问正常、外部访问失败，而且暂时看不出规则问题，可以在服务器上进行一次短时间抓包：

sudo timeout 20 tcpdump \
  -i any \
  -nn \
  -c 30 \
  'tcp port 8080'

命令会在运行约 20 秒或捕获 30 个匹配数据包后结束。

抓包期间，从外部客户端重新访问一次该端口，观察这次连接对应的数据包。

在 tcpdump 输出中，Flags [S] 通常表示 SYN，Flags [S.] 表示 SYN-ACK。判断时要结合报文方向和同一条连接，不能只看某一种标记出现了多少次。

抓不到请求，并不能直接断定是运营商封端口；抓到握手，也不能证明应用已经正常工作。抓包的作用，是帮助确认请求走到了哪一步。

七、修复后如何确认已经恢复？

修改配置后，使用原来的客户端、目标地址和端口重新测试，保持测试条件一致。

先确认外部连接能建立，再确认 HTTP 状态和返回内容符合预期，最后查看应用日志，确认请求到达了正确的服务。

如果实际使用的是域名和 HTTPS，还应通过真实域名再次访问，验证 DNS、证书和反向代理这一整条访问路径。直接访问 IP 成功，只能说明对应 IP 和端口的测试通过。