服务器IP能ping通，浏览器访问80或443端口却超时，SSH连接22端口也失败。很多人看到ping成功，就认定网络和服务器都正常，开始反复重装Nginx或SSH。
ping通常测试ICMP回显，网页和SSH使用TCP。ICMP能到达，只说明某条网络路径允许回显，不证明目标TCP端口有服务监听，也不证明防火墙、安全组和NAT允许连接。
排查时从客户端到服务端逐层查：目标端口、监听地址、本机防火墙、云安全组或NAT、应用与TLS。
Windows PowerShell：
Test-NetConnection <服务器IP或域名> -Port 443
Test-NetConnection <服务器IP或域名> -Port 22Linux或macOS：
nc -vz <服务器IP或域名> 443
nc -vz <服务器IP或域名> 22
curl -Iv https://<域名>/只在你有权管理的服务器和端口上测试。不要把本文命令扩展为未授权扫描。
常见结果：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Linux执行：
sudo ss -lntp
sudo ss -lntp | grep -E ':22|:80|:443'重点看监听地址：
-
`127.0.0.1:80`：只有服务器本机能访问。 -
`0.0.0.0:80`：监听所有IPv4接口。 -
`[::]:443`：监听IPv6，是否同时接受IPv4取决于系统和程序设置。 -
查不到端口：服务未启动、启动失败或监听了其他端口。
继续查看服务状态和日志：
sudo systemctl status nginx
sudo journalctl -u nginx --since '30 min ago'将服务名替换为实际服务。不要为了让端口出现就结束未知进程或修改生产配置。
常见工具包括ufw、firewalld和nftables：
sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list ruleset先查看现有规则和默认策略。需要临时放行时，限定协议、端口和来源地址，记录原状态，测试完成后删除临时规则。
不要关闭整套防火墙来证明“是不是防火墙的问题”。服务器可能同时运行数据库、管理端口和内部服务，整体关闭会暴露无关端口。
云服务器即使本机防火墙已放行，云平台安全组或网络ACL仍可能拦截。确认入站规则目标端口、协议、来源地址和绑定实例。
家庭或办公室服务器还要检查：
-
路由器端口映射是否指向正确内网IP和端口。 -
服务器内网IP是否变化。 -
光猫和路由器是否形成双层NAT。 -
宽带是否使用运营商级NAT，导致没有可入站的公网IPv4。 -
IPv6场景是否由IPv6防火墙单独拦截。
端口映射只用于自己管理的服务。管理后台、数据库和远程桌面不应直接暴露在公网，优先使用VPN、零信任访问或受控组网。
TCP连接成功后，浏览器可能出现证书错误、403、404、502或连接被重置。此时网络端口已经不是唯一重点。
继续检查：
-
HTTPS证书名称、有效期和证书链。 -
Nginx或反向代理的Host和SNI配置。 -
后端服务地址、健康状态和超时。 -
SSH用户名、密钥、认证策略和封禁日志。 -
服务是否只允许特定来源或路径。
curl -Iv https://域名/可以保留握手和响应头证据。分享日志前删除Cookie、令牌、内网域名和真实公网IP。
-
客户端测试目标TCP端口，区分成功、拒绝和超时。 -
服务器用`ss -lntp`确认服务和监听地址。 -
查本机防火墙规则，不整体关闭。 -
查云安全组、网络ACL、端口映射和NAT。 -
TCP成功后再查TLS、反向代理、认证和应用日志。 -
修复后从原客户端和外部网络分别复测。 -
删除临时放行，恢复最小权限。
ping成功只是第一条线索。把ICMP、TCP端口和应用协议分开，才能准确判断连接停在哪一层。
