网站无法打开时，如何按DNS解析、端口防火墙和应用状态排查云服务器

“云服务器配置越高，网站打开就一定越快吗？”不一定。更高的计算资源只能在请求已经到达服务器、端口正常监听、反向代理和应用能够处理请求时改善承载能力，无法解决域名解析错误、云平台入站规则未放行、主机防火墙拦截或应用根本没有启动等问题。

网站无法打开时，应按照“域名解析 → 云端网络入口 → 端口监听 → 防火墙 → 反向代理 → 应用状态”的顺序排查。这个顺序由外到内，能够避免一开始就重启服务或调整配置，把原本清晰的故障变得更复杂。下面命令以 Linux 云服务器和域名 example.com 为例，实际操作时请替换为自己的域名、IP 地址和端口。

一、排查前先确定故障边界

开始前准备以下信息：

• 故障域名及其预期的公网 IPv4、IPv6 地址。
• 网站实际使用的端口，通常是 HTTP 的 80 和 HTTPS 的 443。
• 云平台控制台的访问权限，包括公网 IP、入站规则、安全组或网络访问控制配置。
• 服务器控制台、SSH 或其他运维入口。
• 反向代理服务名称、应用服务名称和应用监听端口。
• 最近修改过的 DNS、云端网络规则、防火墙、反向代理或应用配置。

不要在尚未定位原因时直接执行重启、清空防火墙规则或批量修改配置。先记录当前状态，便于后续恢复和对比。

浏览器提示信息通常可以帮助缩小范围：

二、第一步：检查 DNS 是否指向正确入口

1. 查询 A 和 AAAA 记录

在 Linux 或 macOS 的外部测试机器上执行：

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

Windows 可以使用：

nslookup -type=A example.com
nslookup -type=AAAA example.com

重点观察以下结果：

• 没有返回 A 或 AAAA 记录：域名没有解析到地址，先检查 DNS 管理平台中的记录是否存在、记录名是否正确。
• 返回了旧公网 IP：DNS 记录与当前云服务器不一致，应核对公网 IP 是否发生过变更。
• A 记录正确，但 AAAA 记录指向没有配置 IPv6 的地址：部分客户端会优先尝试 IPv6，导致网站表现为间歇性无法打开。应确认 IPv6 入口确实已配置；如果不使用该记录，应在确认影响范围后处理错误的 AAAA 记录。
• 返回 CNAME 或多个地址：继续确认 CNAME 的最终解析结果，以及每个目标是否都能正常提供网站。

如果怀疑本地 DNS 缓存或某个递归 DNS 返回了旧结果，可以分别查询不同递归 DNS：

dig example.com A
dig @<递归DNS服务器地址> example.com A

<递归DNS服务器地址> 应替换为实际要核对的 DNS 服务器地址，不要直接把示例当成生产配置。多个查询结果不一致时，先确认权威 DNS 中的实际记录，再判断是否只是缓存尚未更新。

2. 绕过 DNS，直接验证网站入口

DNS 正常与否可以通过 curl --resolve 分离判断。该命令只改变本次请求的解析结果，不会修改系统 DNS。

图示对应原文命令：curl --resolve。

在外部测试机器上执行：

curl -v --connect-timeout 5 --max-time 15 \
  --resolve example.com:80:203.0.113.10 \
  http://example.com/

HTTPS 测试：

curl -vk --connect-timeout 5 --max-time 15 \
  --resolve example.com:443:203.0.113.10 \
  https://example.com/

其中 203.0.113.10 是文档示例地址，请替换为实际公网 IP。--resolve 仍然使用 example.com 作为请求主机名，因此可以同时检查虚拟主机和 HTTPS 的 SNI 配置。HTTPS 命令中的 -k 只用于诊断阶段临时忽略证书校验，不能作为正式访问方式。

结果判断如下：

• 直接指定 IP 后可以返回页面，而正常访问失败：重点回到 DNS、CNAME、AAAA 或前置接入配置。
• 直接指定 IP 仍然超时：DNS 通常不是主要原因，继续检查云端网络入口、端口和防火墙。
• 能建立 HTTPS 连接但出现证书错误：网络入口已基本连通，应检查证书、域名匹配和 443 虚拟主机配置。
• 返回 404、403、502 或 504：说明请求已经到达某个 Web 服务，排查重点转向反向代理和应用。

三、第二步：核对云服务器的网络入口

DNS 返回正确 IP，并不代表该地址一定允许网站流量进入。先在云平台控制台核对：

1. 域名解析到的公网 IP 是否仍绑定在目标云服务器或正确的公网接入资源上。
2. 入站规则是否允许网站使用的 TCP 端口。
3. 规则的协议、端口范围和来源范围是否符合网站访问需求。
4. 如果网站确实使用 IPv6，IPv6 地址、入站规则和服务器监听是否同时配置。
5. 如果域名经过负载均衡或 CDN 等前置接入，回源地址、回源端口是否与服务器实际监听一致。

只检查服务器内部的 ip addr 不能证明公网 IP 已经正确绑定，因为云服务器内部通常只能看到网卡地址，公网映射可能由云平台完成。公网 IP 归属应以云平台控制台和外部连接测试为准。

从一台不在目标服务器上的测试机器检查 TCP 端口：

nc -vz -w 5 203.0.113.10 80
nc -vz -w 5 203.0.113.10 443

Windows PowerShell 可使用：

Test-NetConnection 203.0.113.10 -Port 80
Test-NetConnection 203.0.113.10 -Port 443

这些命令只应针对自己管理或获得授权的服务器执行。

不同结果的含义：

• 连接超时：可能是云平台入站规则、网络访问控制、主机防火墙或公网地址映射问题。
• Connection refused：通常说明请求已经到达主机，但该端口没有监听服务，或者主机主动拒绝。
• TCP 连接成功，随后返回 HTTP 响应：网络入口和端口基本正常，应继续检查反向代理和应用。
• 80 正常、443 失败：优先检查 443 入站规则、HTTPS 服务监听和 TLS 配置。
• 443 正常、80 被跳转到 HTTPS：如果 HTTPS 最终可用，这通常是正常的重定向，不应把 80 的跳转误判为故障。

ping 失败不能单独证明网站不可达，因为云平台或主机可能禁止 ICMP。网站排查应以 TCP 端口和 HTTP/HTTPS 请求结果为准。

四、第三步：确认服务器是否监听正确端口

登录 Linux 服务器后，使用只读命令查看监听状态：

sudo ss -lntp

也可以筛选常见网站端口：

sudo ss -lntp | grep -E ':(80|443|8080|8443)\b'

不同发行版中 ss 通常由系统工具包提供；如果命令不存在，应先确认系统环境，不要直接安装或替换网络工具。

重点看监听地址：

• 0.0.0.0:80：表示监听所有 IPv4 地址。
• [::]:443：表示监听 IPv6，是否同时接受 IPv4 取决于系统参数和服务配置。
• 127.0.0.1:8080：只允许本机访问，适合作为反向代理的后端端口，不能直接作为公网入口。
• 没有 80 或 443 的监听记录：前端 Web 服务没有启动、配置失败，或者实际使用了其他端口。

如果应用采用“反向代理监听 80/443，应用监听 8080/其他端口”的结构，分别测试前端和后端：

curl -v --connect-timeout 3 http://127.0.0.1/
curl -v --connect-timeout 3 http://127.0.0.1:8080/health

如果没有 /health 路径，可以替换成应用已知的本地健康检查路径。对于虚拟主机，还应带上正确的主机名：

curl -v --connect-timeout 3 \
  -H 'Host: example.com' \
  http://127.0.0.1/

判断方式如下：

• 本机访问后端端口失败：先检查应用进程、应用配置和应用日志。
• 本机后端正常，但访问 127.0.0.1 的前端失败：检查反向代理配置和前端服务状态。
• 本机前端正常，外部访问超时：重点回到云端入站规则和主机防火墙。
• 本机和外部都能返回页面，但浏览器仍失败：检查 DNS、HTTPS 证书、主机名匹配和浏览器实际访问的地址。

五、第四步：分别检查云端规则和主机防火墙

防火墙至少有两层：云平台入站控制和服务器操作系统防火墙。两层中任意一层未放行，外部请求都可能超时。

1. 读取主机防火墙状态

先确认系统中使用了哪一种防火墙工具：

command -v ufw
command -v firewall-cmd
command -v nft
command -v iptables

Ubuntu、Debian 等系统如果使用 UFW，可执行：

sudo ufw status verbose

使用 firewalld 的系统可执行：

sudo firewall-cmd --state
sudo firewall-cmd --list-all

使用 nftables 的系统可执行：

sudo nft list ruleset

如果系统仍使用 iptables 兼容规则，可查看：

sudo iptables -S

不要仅看到防火墙服务处于运行状态就认为端口一定放行，还要核对规则中的端口、协议、来源范围和默认策略。公网网站通常只需要按照实际业务策略开放前端端口，不应因为后端应用使用了 8080、3000 等端口，就直接把这些端口全部暴露到公网。

2. 修改规则前的风险控制

防火墙调整会立即影响访问，尤其是通过 SSH 远程操作时。执行变更前应：

• 记录当前规则输出，至少保存 ufw status numbered、firewall-cmd --list-all 或 nft list ruleset 的结果。
• 确认拥有云平台控制台或带外控制台，避免 SSH 被误拦截后无法进入服务器。
• 只修改必要端口和来源范围，不执行 flush、清空全部规则等高风险操作。
• 规划回滚方式，并确认新增规则的名称或编号。

例如，在明确网站需要公开提供 HTTP/HTTPS 服务、且使用 UFW 的前提下，可以按策略放行 80 和 443：

sudo ufw status numbered
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

这是有影响范围的配置变更。回滚时应根据变更后的编号删除刚新增的规则，并再次核对状态：

sudo ufw status numbered
sudo ufw delete <新增规则编号>
sudo ufw status numbered

使用 firewalld 时，变更前应保存当前区域配置。确认策略允许后，可使用服务名称放行：

sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

回滚新增规则：

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --permanent --remove-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

上述操作只适用于确实由 firewalld 管理规则的系统。不要把 UFW、firewalld、nftables 的命令混用，也不要在不了解当前规则来源时直接覆盖整套防火墙配置。

六、第五步：检查反向代理是否能连接应用

如果服务器使用 Nginx 等反向代理，前端端口正常并不代表后端应用可用。先检查配置语法和服务状态。以下命令仅适用于已安装且服务名确实为 nginx 的环境：

sudo nginx -t
sudo systemctl status nginx --no-pager

nginx -t 返回配置测试成功，才适合考虑重新加载配置。查看完整配置时要注意其中可能包含口令、密钥或内部地址，不要直接公开粘贴：

sudo nginx -T 2>/dev/null | grep -E 'listen|server_name|proxy_pass|access_log|error_log'

重点核对：

• listen 是否包含实际使用的 80、443 端口。
• server_name 是否包含用户访问的域名。
• HTTPS 站点是否配置了正确证书和密钥。
• proxy_pass 指向的地址和端口，是否与应用实际监听一致。
• 反向代理访问后端时使用的协议是否正确，例如后端是 HTTP 还是 HTTPS。

可以通过本机请求模拟前端转发：

curl -v --connect-timeout 5 \
  -H 'Host: example.com' \
  http://127.0.0.1/

HTTPS 虚拟主机可使用：

curl -vk --connect-timeout 5 \
  --resolve example.com:443:127.0.0.1 \
  https://example.com/

常见状态码的含义：

• 502 Bad Gateway：反向代理已经收到请求，但连接不上后端，常见原因是应用停止、端口写错、监听地址不匹配。
• 504 Gateway Timeout：后端连接或处理超过等待时间，应检查应用处理过程及其依赖服务。
• 404 Not Found：可能是站点匹配错误、路径配置错误，或者应用本身没有该路由。
• 403 Forbidden：可能是目录权限、访问控制或应用权限策略问题。
• TLS 握手失败：重点检查 443 监听、证书文件、证书权限、域名匹配和 HTTPS 虚拟主机，不要只重启应用。

查看 Nginx 日志：

sudo journalctl -u nginx -n 100 --no-pager

如果 Web 服务不是 Nginx，应使用实际服务提供的配置检查命令和日志位置，不要直接套用 Nginx 命令。

七、第六步：确认应用进程和资源状态

确认应用服务名称后，再查看服务状态。服务名不确定时先列出已运行的服务，不要凭名称猜测：

systemctl list-units --type=service --state=running

查看具体服务：

sudo systemctl status <应用服务名> --no-pager
sudo journalctl -u <应用服务名> -n 100 --no-pager

如果应用已停止，应先从日志确认停止原因，再决定启动或恢复。直接反复重启可能暂时恢复页面，却掩盖配置错误、端口冲突、依赖失败或进程被系统终止等根因。

当网站已能连接但响应明显变慢时，再查看基本资源状态：

uptime
free -h
df -h
top -b -n 1 | head -n 20

可重点关注：

• 磁盘空间是否已满，特别是日志所在文件系统。
• 内存不足是否导致应用被系统终止。
• 应用进程是否持续占用异常资源。
• 系统负载是否持续升高，并且与故障时间一致。

Linux 内核日志可用于确认是否发生过内存不足终止：

sudo journalctl -k -b | grep -iE 'oom|out of memory|killed process'

更高的云服务器配置不能修复错误 DNS、关闭的 443 端口或未启动的应用。只有在 DNS、入口、端口和服务链路均正常，并且确认资源消耗是瓶颈时，提升配置才可能改善处理能力；变更前仍应以监控和日志中的实际现象为依据。

八、根据结果快速定位

九、修复后的验收与回滚

修复后不要只以浏览器能打开一次作为完成标准，至少完成以下检查：

1. 从外部测试机器重新查询 A、AAAA 或 CNAME，确认结果指向预期入口。
2. 分别测试 80 和 443 的 TCP 连接。
3. 使用正常域名执行 HTTP/HTTPS 请求，确认返回符合业务预期的状态码。
4. 对 HTTPS 检查证书是否匹配访问域名，不能只依赖 -k 忽略错误。
5. 查看反向代理访问日志，确认请求已经到达正确站点。
6. 查看应用日志，确认请求已被正确处理，没有持续出现 502、504 或应用异常。
7. 如果配置了 AAAA，分别验证 IPv4 和 IPv6 访问结果。
8. 连续进行几次访问，确认不是偶发成功。

如果修复后出现新的异常，应只回滚本次变更，不要清空全部配置：

• DNS：恢复修改前的记录值，并记录恢复时间；缓存中的旧结果需要结合实际查询结果判断。
• 云端网络规则：删除本次新增或修改的规则，保留原有业务规则。
• 主机防火墙：根据变更前保存的规则恢复，不执行无差别清空。
• 反向代理：恢复经过备份的配置文件，先执行 nginx -t，通过后再 reload。
• 应用：恢复到变更前已知可用的应用版本或配置，并重新检查监听端口和日志。

如果需要修改 Nginx 配置，建议先在服务器本地备份配置目录：

sudo tar -C /etc -czf /root/nginx-config-backup-$(date +%Y%m%d%H%M%S).tar.gz nginx

备份文件可能包含敏感配置，应限制访问权限并妥善保管。恢复时必须确认备份文件来源和内容，再执行配置测试；不要未经核对直接覆盖当前配置。

当 DNS、网络入口、端口、防火墙、反向代理和应用状态逐层验证通过后，网站才算真正恢复。服务器配置高低应放在故障已经排除之后，再根据实际资源指标评估是否需要调整，而不是把“配置更高”当成网站一定能打开或一定更快的依据。