应用部署在香港服务器的 NVMe 硬盘上，并不意味着应用端口一定能从公网访问。NVMe 硬盘主要影响文件读写、启动过程和日志处理；TCP/UDP 端口是否连通，取决于应用进程是否启动、监听地址和端口是否正确、服务器本机防火墙是否放行、云平台安全组是否允许，以及公网地址到服务器之间是否存在 NAT、端口转发或代理。

因此，遇到“端口无法访问”时，不要先反复重启应用，也不要立即把防火墙和安全组全部放开。更稳妥的顺序是：先确认访问地址、端口和协议，再从外部测试连接；随后检查应用监听状态与绑定地址，接着检查本机防火墙、安全组和 NAT，最后用抓包和跨网络验证确定数据包停在哪一层。每一步都应结合结果判断下一步，而不是只执行命令。

先判断故障发生在哪一段链路

一次公网访问通常经过以下路径：

客户端
  ↓
公网 IP 或域名解析
  ↓
安全组、云防火墙或入口策略
  ↓
NAT、端口转发或负载均衡
  ↓
香港服务器网卡
  ↓
服务器本机防火墙
  ↓
应用监听地址与端口
  ↓
应用进程

任意一层配置错误，都可能表现为“端口打不开”，但错误现象通常不同：

• Connection refused（连接被拒绝）：目标地址通常可达，但端口没有进程监听，或某一层策略主动拒绝。
• Timeout（连接超时）：更常见于安全组、本机防火墙、NAT、路由、公网地址或入口策略错误。
• TCP 可以连接，但页面或接口报错：网络层大概率已经打通，应继续检查 HTTP、HTTPS、TLS、Host、认证、反向代理和应用日志。
• 服务器本机可以访问，外网无法访问：重点查看监听地址、本机防火墙、安全组和 NAT。
• 直接访问 IP 正常，域名访问失败：优先检查 DNS、AAAA 记录、IPv6 和代理配置，不要先修改应用端口。

NVMe 硬盘通常不是端口无法访问的直接原因。只有在磁盘故障导致应用没有启动、配置文件读取失败、日志或运行目录无法写入、进程频繁退出时，存储问题才可能间接造成端口不可用。需要通过服务状态、应用日志和磁盘相关错误建立证据，不能仅凭“应用使用了 Nvme硬盘”判断网络故障来源。

第一步：确认公网地址、端口和协议

开始排查前，先记录实际访问目标：

• 使用的是域名还是公网 IP；
• 端口号是否与应用配置一致；
• 应用使用 TCP 还是 UDP；
• 香港服务器是否有多个公网 IP、内网 IP 或网卡；
• 公网入口是否经过 CDN、反向代理、负载均衡或端口转发；
• 客户端是否优先使用 IPv6。

如果使用域名，先确认解析结果。Linux 或 macOS 可以执行：

dig +short example.com
dig example.com A
dig example.com AAAA

没有 dig 时，可以使用：

getent ahosts example.com

若域名同时存在 A 和 AAAA 记录，客户端可能优先尝试 IPv6。此时应分别验证：

curl -4 -v http://example.com:8080/
curl -6 -v http://example.com:8080/

其中 8080 只是示例，必须替换为实际端口。若 IPv4 成功而 IPv6 超时，故障范围通常包括 IPv6 地址、路由、监听、防火墙或安全组，而不是 NVMe 硬盘。

随后从客户端测试 TCP 建连：

nc -vz -w 5 SERVER_IP PORT

例如：

nc -vz -w 5 203.0.113.10 8080

也可以使用：

timeout 5 bash -c '

这些命令只验证 TCP 建连，不能证明 HTTP 或其他应用协议正常。HTTP 服务还应进一步执行：

curl -v --connect-timeout 5 http://203.0.113.10:8080/

HTTPS 服务可以执行：

curl -vk --connect-timeout 5 https://example.com:8443/

-k 会跳过证书校验，只适合临时定位连通性，不能作为长期生产配置。

第二步：在服务器上确认应用是否监听

登录香港服务器后，先查看监听端口和关联进程：

sudo ss -lntup

参数含义如下：

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

只检查某个端口时：

sudo ss -lntup | grep ':8080'

也可以使用 lsof：

sudo lsof -nP -iTCP:8080 -sTCP:LISTEN

不同发行版可能没有默认安装 lsof，通常应优先使用 ss。

根据监听地址判断应用绑定问题

假设应用端口是 8080，如果看到：

LISTEN 0  128  127.0.0.1:8080  0.0.0.0:*  users:(("app",pid=1234,fd=8))

这表示应用只监听本机回环地址。服务器内部访问 127.0.0.1:8080 可能正常，但来自公网的请求无法直接到达。若应用设计为只由 Nginx 或其他本机反向代理调用，这种配置可能是合理的；若应用需要直接接受外部连接，则应按应用文档调整为服务器内网地址或 0.0.0.0。

如果看到：

LISTEN 0  128  0.0.0.0:8080  0.0.0.0:*  users:(("app",pid=1234,fd=8))

说明应用监听所有 IPv4 地址。应用绑定层面通常允许外部连接，但还需要检查本机防火墙、安全组和 NAT。

如果看到：

LISTEN 0  128  [::]:8080  [::]:*  users:(("app",pid=1234,fd=8))

说明应用监听 IPv6 通配地址。是否同时接受 IPv4 连接，取决于操作系统的 IPv6 socket 配置，不能只凭这一行断定 IPv4 也可用，应分别用 IPv4 和 IPv6 测试。

如果没有监听记录，应检查：

• 应用进程是否启动；
• 应用是否启动后立即退出；
• 配置文件中的端口是否写错；
• 端口是否被其他进程占用；
• 是否存在权限、依赖、配置语法或磁盘读写错误。

使用 systemd 管理服务时，可以执行：

sudo systemctl status app.service --no-pager
sudo journalctl -u app.service -n 100 --no-pager

app.service 必须替换为实际服务名，不要直接猜测。可以先搜索：

systemctl list-units --type=service | grep -i app

如果应用运行在 Docker 中，还要区分“容器内监听”和“宿主机端口发布”：

docker ps
docker port CONTAINER_NAME
docker logs --tail 100 CONTAINER_NAME

容器内监听 127.0.0.1 时，可能无法按预期通过容器网络访问；宿主机也必须存在正确的端口发布规则。修改 Compose 或容器配置前，应先备份当前配置，避免覆盖后无法回滚。

第三步：核对应用绑定配置并安全地重载

应用配置中常见的监听字段类似：

host = 127.0.0.1
port = 8080

127.0.0.1 通常只允许本机访问。若应用需要被其他主机直接访问，应根据应用支持情况绑定服务器实际内网地址或 0.0.0.0。但管理后台、数据库、缓存和内部接口不应为了排障而长期监听所有地址。

可以按以下原则处理：

1. 只由本机反向代理调用的应用，可以保留 127.0.0.1，仅开放代理对外提供的端口。

2. 需要被其他主机直接访问的应用，应绑定合适的内网地址或通配地址。

3. 服务器有多个网卡或多个地址时，应确认监听的是实际接收流量的地址。

4. 修改绑定地址或端口后，必须重新加载或重启应用，再用 ss 确认结果。

修改前先备份配置：

sudo cp /path/to/app.conf /path/to/app.conf.bak

路径和文件名必须替换为实际值。优先使用应用自身的配置检查命令；如果没有该命令，应先查看启动日志，再执行重启：

sudo systemctl restart app.service
sudo systemctl status app.service --no-pager

如果重启后端口仍未监听，应立即查看：

sudo journalctl -u app.service -n 100 --no-pager

回滚时恢复备份并重启：

sudo cp /path/to/app.conf.bak /path/to/app.conf
sudo systemctl restart app.service

第四步：检查服务器本机防火墙

确认应用已经监听后，再查看本机防火墙。常见管理工具包括 ufw、firewalld 和 nftables。不要在不了解现有规则的情况下同时修改多个工具，否则可能出现临时规则、持久化规则和实际生效规则不一致。

UFW

查看规则：

sudo ufw status numbered

临时验证时，优先限制为当前客户端公网 IP：

sudo ufw allow from CLIENT_IP to any port 8080 proto tcp

只有确实需要对公网提供服务时，才考虑：

sudo ufw allow 8080/tcp

开放公网端口会扩大暴露范围。验证完成后，查看规则编号并删除临时规则：

sudo ufw status numbered
sudo ufw delete RULE_NUMBER

firewalld

查看活动区域和规则：

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

临时放行 TCP 端口：

sudo firewall-cmd --add-port=8080/tcp

确认需要永久保留后，再写入持久配置：

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

仅用于测试且不希望保留时，可以删除运行时规则：

sudo firewall-cmd --remove-port=8080/tcp

回滚永久规则：

sudo firewall-cmd --permanent --remove-port=8080/tcp
sudo firewall-cmd --reload

nftables

先只读查看现有规则：

sudo nft list ruleset

修改前保存规则集：

sudo nft list ruleset > ~/nftables-backup-$(date +%F-%H%M%S).conf

如果系统通过发行版服务或配置文件管理 nftables，应沿用原有管理方式。不要在不了解规则结构时直接清空、重置或覆盖整个规则集；这可能影响其他已开放服务。旧环境也可能使用 iptables：

sudo iptables -t nat -S
sudo iptables -S

第五步：核对安全组、云防火墙和 NAT

本机防火墙放行，不代表云平台入口已放行。安全组、云防火墙、网络 ACL 或实例级入站规则可能在数据包到达服务器前就将其丢弃。

检查安全组或云侧入站规则时，至少确认：

• 入站方向是否包含目标端口；
• 协议是否匹配，TCP 和 UDP 不能混用；
• 来源是否包含实际客户端公网 IP；
• 规则是否绑定到正确的实例或网卡；
• 是否存在优先级更高的拒绝规则；
• 修改是否已经保存并生效；
• IPv4 与 IPv6 是否分别配置。

例如应用使用 TCP 8080，但安全组只放行 UDP 8080，TCP 客户端仍然无法建立连接。若规则只允许办公出口 IP，而当前测试来自家庭宽带，也会表现为超时。

排障时不要无条件将所有端口对所有来源开放。更安全的临时规则是：

协议：TCP
端口：8080
来源：当前客户端公网 IP/32

/32 表示单个 IPv4 地址。客户端公网 IP 可能因网络切换而变化，测试前应重新确认。规则验证完成后，应删除临时的宽泛放行。

如果公网 IP 不直接绑定在香港服务器网卡上，还要检查网关、端口映射、负载均衡或代理入口：

• 公网端口与服务器内网端口是否一致；
• 转发目标是否仍是当前内网 IP；
• 是否只配置了 IPv4，而客户端实际访问 IPv6；
• 负载均衡健康检查端口是否与应用端口一致；
• 入口是否只转发 TCP，而应用实际使用 UDP；
• 转发后的目标服务器本机防火墙是否放行；
• 反向代理是否绑定到正确网卡和端口。

服务器存在 NAT 规则时，可以查看：

sudo nft list ruleset

旧环境也可以查看：

sudo iptables -t nat -S
sudo iptables -S

最好同时从入口设备和目标服务器两端核对：公网端口收到连接后，是否确实转发到预期内网 IP 和端口。只读查看通常风险较低，但不要直接执行清空、重置或覆盖操作。

第六步：用本机访问和抓包定位数据包

先在服务器本机测试回环地址和内网地址：

curl -v http://127.0.0.1:8080/
curl -v http://SERVER_PRIVATE_IP:8080/

结果可以这样理解：

• 回环地址成功、内网地址失败：重点检查应用绑定地址或本机防火墙。
• 两者都成功、外网失败：应用通常已经正常工作，应转向本机防火墙、安全组、NAT 或公网入口。
• 本机也失败：不要继续排查安全组，先回到应用状态、监听端口和协议配置。

当各项配置看起来正确但外部仍无法连接，可以抓取指定端口：

sudo tcpdump -ni any 'tcp port 8080'

然后从外部客户端发起一次连接：

• 完全看不到客户端 SYN：请求尚未到达服务器，重点检查 DNS、公网 IP、NAT、安全组、云防火墙或上游入口。
• 能看到 SYN，但服务器没有回应：可能是本机防火墙丢弃、监听地址不匹配或路由异常。
• 看到 SYN 和 SYN-ACK，但连接仍失败：检查回程路径、客户端防火墙、NAT 状态和安全策略。
• 三次握手成功，随后应用返回错误：端口连通性基本正常，应转向应用协议和应用日志。

抓包只用于定位，不会自动修复规则。命令结束后按 Ctrl+C 停止；抓包内容可能包含连接信息，保存或分享前应注意敏感数据。

按现象选择修复方向

修复后按由内到外的顺序验证

修改配置后，不要只以“浏览器能打开”作为唯一判断。建议依次验证：

1. 确认应用进程仍在运行。

2. 执行 ss -lntup，确认端口、协议和监听地址正确。

3. 在服务器本机通过回环地址或内网地址访问。

4. 从不同网络位置测试外部 TCP 建连。

5. 使用实际协议验证，例如 curl、应用客户端或相应的 UDP 工具。

6. 查看应用日志，确认请求已经到达并被正常处理。

7. 使用域名时，分别验证 IPv4、IPv6、TLS 证书和代理入口。

8. 删除排障期间临时增加的宽泛防火墙或安全组规则。

HTTP 服务可以这样验证：

# 服务器本机
curl -v --connect-timeout 5 http://127.0.0.1:8080/

# 外部客户端
curl -v --connect-timeout 5 http://SERVER_PUBLIC_IP:8080/

如果需要排除 DNS 影响，可以使用 --resolve 临时指定域名与 IP 的对应关系：

curl -v --resolve example.com:8080:203.0.113.10 \
  http://example.com:8080/

该命令不会修改公共 DNS，适合判断“域名解析错误”还是“目标服务器端口错误”。其中域名、端口和 IP 必须替换为实际值。

端口排查只能确认网络连接和应用入口是否正常，不能替代应用安全评估。管理后台、数据库、缓存和内部服务不应因为排障方便而长期暴露公网；如果服务只供本机反向代理使用，监听 127.0.0.1 反而可能是合理设计。

当 ss 确认监听正确、本机访问正常、抓包能看到外部请求，而应用仍返回错误时，问题已经从端口连通性转向应用配置或协议处理。反之，如果抓包完全看不到外部请求，应回到公网地址、DNS、安全组、NAT 和入口策略逐层核对。这样可以明确故障究竟停在应用绑定、服务器防火墙，还是云侧网络配置。