海外Linux服务器无法访问网站时，如何检查DNS、端口与Web服务？

网站无法访问时，不要先重启服务或修改防火墙。先确认故障范围，再沿着“域名解析 → 网络入口 → 端口与防火墙 → Web 服务 → 反向代理和应用”的路径逐层检查。每一步都要区分“请求没有到达服务器”“连接被拒绝或超时”“已建立连接但返回错误”这几类结果，才能把问题定位到正确层级。

建议先从一台不在服务器上的设备测试域名和页面，再在服务器本机检查监听端口与服务状态。外部请求超时而本机访问正常，优先检查 DNS、网络入口和防火墙；本机也无法连接，重点检查 Web 服务是否启动、是否监听正确地址和端口，以及应用是否正常响应。下面的命令适用于常见 Linux 发行版，执行前请确认域名、端口和服务名称与当前环境一致。

先确定故障范围

排查前记录四项信息：出问题的域名、访问协议（HTTP 或 HTTPS）、客户端报错或状态码、故障开始时间。再分别从外部客户端和服务器本机发起请求：

curl -I --connect-timeout 5 --max-time 10 http://example.com/
curl -I --connect-timeout 5 --max-time 10 https://example.com/

把 example.com 换成实际域名。-I 只获取响应头，适合初步确认连接和 HTTP 状态；若站点不支持 HEAD 请求，再用下面的方式发送普通 GET 请求：

curl -v --connect-timeout 5 --max-time 10 https://example.com/

常见现象可以先这样分层判断：

检查 DNS 是否指向正确入口

先在外部客户端查询域名解析。以下命令需要安装 dig；若系统没有，可使用 getent 辅助核对。

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
getent ahosts example.com

A 记录返回 IPv4 地址，AAAA 记录返回 IPv6 地址，CNAME 则表示别名指向。将解析结果与当前应使用的服务器公网地址或 CDN 接入地址核对。若域名经过 CDN，解析到 CDN 地址可能是正常现象，此时不能要求 A 记录直接等于源站地址，应继续检查 CDN 到源站的回源目标和端口。

重点留意以下情况：

• A 记录指向旧地址：检查域名解析平台上的记录是否已修改，并确认记录名称没有填错，例如根域名与 www 子域名是两条不同记录。
• AAAA 记录存在但服务器没有可用 IPv6 服务：部分客户端会优先尝试 IPv6，可能出现部分用户访问失败。确认服务器、监听服务和网络入口都支持 IPv6 后再保留该记录；不支持时应由负责 DNS 的人员评估是否移除，避免未核实就修改线上记录。
• 不同查询来源结果不一致：可能涉及递归 DNS 缓存或记录尚未完成更新。核对权威记录和 TTL，并在多个外部网络复查。TTL 是缓存时间参考，不代表所有递归解析器会在同一时刻刷新。
• 只有某个子域名异常：分别查询该子域名的 A、AAAA 和 CNAME，不要用根域名的结果代替。

可指定公共递归解析器作对照，但它只代表该查询路径的回答，不等于全球所有网络的解析结果：

dig @1.1.1.1 +short A example.com
dig @8.8.8.8 +short A example.com

若解析已经指向预期入口，继续测试入口本身。若域名解析结果不正确，先保存查询时间、查询来源、返回记录与 TTL，再由 DNS 管理人员核对并调整；记录变更前保留原值，便于需要时恢复。

检查网络入口和端口连通性

确认目标 IP 和端口后，从外部客户端测试 TCP 连接。网站常见端口是 HTTP 的 80 和 HTTPS 的 443，但实际端口应以站点配置为准。

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

将示例地址替换为实际入口地址。显示连接成功，说明从这台客户端到该地址、该端口的 TCP 握手可建立；这不代表 TLS 证书、Web 配置或应用内容一定正常。超时表示连接未在限定时间内完成，可能是入口策略、路由或防火墙丢弃了流量；“Connection refused”通常表示目标可达但端口没有接受连接，或目标主动拒绝。

若域名解析经过 CDN 或其他反向代理入口，直接测试源站 IP 与测试域名得到的结果可能不同。应分别核实：

1. 客户端能否连接域名当前解析到的入口。
2. 入口能否按配置连接源站地址及源站端口。
3. 源站是否只允许指定入口地址访问，且允许规则包含当前实际回源地址。

在服务器上确认公网接口和路由信息，可使用：

ip -br address
ip route

云主机或托管环境还可能在 Linux 防火墙之外设置网络访问规则。应核对控制台中的入站规则、网络 ACL 或上游安全策略是否允许对应协议、端口和来源地址。不要为了“先试试看”而开放全部入站端口；尽量只放通站点确实需要的端口和来源范围，并记录变更前后的规则。

检查 Linux 是否监听目标端口

在服务器上查看监听状态：

sudo ss -lntp

重点检查目标端口是否出现，以及监听地址是什么。0.0.0.0:80 通常表示监听所有 IPv4 接口，127.0.0.1:80 只接受本机 IPv4 回环连接；[::]:443 常用于 IPv6 监听。具体行为还可能受系统 IPv6 配置影响，不能只凭地址形式推断所有协议都已可用。

也可以按端口过滤：

sudo ss -lntp '( sport = :80 or sport = :443 )'

结果为空时，说明当前没有进程在对应端口监听，继续检查 Web 服务状态和配置。若只监听 127.0.0.1，而外部流量需要直接到达此服务，那么监听地址可能不匹配预期；但在反向代理架构中，应用只监听回环地址也可能是正常设计。先查明请求链路，不要直接改成监听所有接口。

根据发行版和实际服务名称查看状态。以下 nginx 仅为示例，若运行的是 Apache 或其他 Web 服务，应替换为系统中对应的 unit 名称：

sudo systemctl status nginx --no-pager
sudo journalctl -u nginx --since "30 minutes ago" --no-pager

systemctl status 可看到服务是否处于运行状态及近期错误；日志中的配置错误、端口占用或权限问题，常能解释服务为何启动失败。修改配置后，优先执行配置检查再重载，不要在未确认配置有效时反复重启：

sudo nginx -t

只有检查通过且已确认该服务确实使用 Nginx 时，才考虑重载：

sudo systemctl reload nginx

如果重载失败，先查看命令输出和服务日志，不要覆盖配置或删除日志来“清理故障”。涉及线上配置调整时，应先备份相关配置文件，并保留可恢复的原版本；回滚时恢复备份、重新执行配置检查，再按服务支持的方式重载。

核对主机防火墙与上游访问规则

Linux 上的防火墙工具因发行版和部署方式而异。先识别当前正在使用的管理工具，再查看规则；不要同时套用多套命令，也不要在远程连接中直接清空规则。

sudo ufw status verbose
sudo firewall-cmd --state
sudo nft list ruleset

这些命令分别用于查看 UFW、firewalld 和 nftables 状态。系统可能只使用其中一种，也可能由其他组件管理规则；若某个命令不存在或服务未运行，不应据此认定“没有防火墙”。还要核对云平台入站规则、机房边界策略以及反向代理或 CDN 的回源限制。

判断时关注三点：目标端口是否允许入站、来源范围是否覆盖实际客户端或回源地址、IPv4 与 IPv6 是否配置一致。规则存在但来源地址不匹配时，可能表现为部分来源可以访问、部分来源超时。若服务仅供反向代理回源，源站只允许回源地址访问可能是合理的；此时应测试真实回源路径，而不是要求所有公网客户端直接连接源站。

需要修改防火墙时，先保存当前规则或记录当前配置，并确认管理通道不会被一并封锁。只添加必要的端口和来源规则，避免清空规则、关闭整个防火墙或开放全部端口。变更后立即从外部验证；若管理连接中断或网站仍不可达，应使用已确认的回滚方式恢复原规则。具体规则命令与系统版本、工具和现有策略有关，未经核实不要直接复制其他环境的写入命令。

检查 Web 服务、反向代理和应用

端口连通不代表网站已经正常。先在服务器本机向 Web 服务发请求，观察返回码和响应头：

curl -I --connect-timeout 3 --max-time 8 http://127.0.0.1/
curl -k -I --connect-timeout 3 --max-time 8 https://127.0.0.1/

第二条命令中的 -k 会跳过证书校验，只适合用于判断本机 HTTPS 服务是否有响应，不能用于验收证书是否有效。若站点依赖虚拟主机，直接访问 127.0.0.1 可能命中默认站点；可保留正确 Host 名称进行测试：

curl -I --resolve example.com:80:127.0.0.1 http://example.com/
curl -I --resolve example.com:443:127.0.0.1 https://example.com/

--resolve 只对当前 curl 请求指定域名解析地址，不会修改系统 DNS。通过这组测试，如果本机指定域名访问正常，而外部访问失败，问题更可能位于外部入口、解析或访问规则；如果本机也返回错误，继续检查 Web 服务配置、站点映射和上游应用。

若 Web 服务承担反向代理功能，应分开验证“客户端到 Web 服务”和“Web 服务到应用”两段。以 Nginx 日志为例，常见位置包括访问日志和错误日志，但实际路径以配置文件为准。查看近期日志：

sudo journalctl -u nginx --since "30 minutes ago" --no-pager

若配置使用文件日志，可从配置中确认日志路径后再读取，不要假定所有发行版都使用同一目录。常见状态的排查方向如下：

• 502 Bad Gateway：代理已收到请求，但连接上游失败或上游返回了无效响应。检查上游地址、端口、应用进程及本机连通性。
• 504 Gateway Timeout：代理等待上游响应超时。检查应用是否卡住、上游连接是否可达，以及超时设置是否与业务处理时间相符；不要只提高超时值掩盖应用故障。
• 503 Service Unavailable：可能是应用暂不可用、服务池无可用节点或维护规则生效。核对应用服务状态和代理配置。
• 403 或 404：检查站点匹配、Host、访问控制、根目录和路由规则。若只在某个域名或路径出现，重点核对对应虚拟主机或应用路由。
• 证书错误：确认域名与证书覆盖范围一致、证书链完整且有效期正常；同时检查客户端访问的域名是否与证书匹配。

若应用由 systemd 管理，先用实际 unit 名称检查状态和日志：

sudo systemctl status app.service --no-pager
sudo journalctl -u app.service --since "30 minutes ago" --no-pager

app.service 是占位示例，不是所有系统都存在的服务名。找不到 unit 时，先从部署配置、进程管理方式或应用运维文档确认实际名称，不要盲目启动一个猜测出来的服务。若应用监听本机端口，也可通过 ss -lntp 查看进程是否存在，再用 curl 测试该上游地址。日志应重点比对故障时间、请求路径、上游地址和错误类型，避免只凭一条旧日志下结论。

用结果组合定位根因

单项检查往往只能缩小范围，建议把测试结果组合起来看：

表中是排查优先级，不是对根因的保证。比如连接超时既可能来自主机防火墙，也可能来自云平台规则或路由；需要结合服务器是否收到请求继续判断。若具备权限，可在短时间内观察对应端口是否收到外部流量：

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

该命令会显示匹配到的网络包，适合在明确的排查窗口内短暂运行。外部发起访问时，如果服务器完全看不到对应请求，优先回查 DNS 指向、上游入口与外部访问规则；若能看到 SYN 请求但没有后续握手，检查主机规则和监听状态；若握手及 HTTP 请求都到达，则继续从 Web 日志和应用日志定位。抓包可能包含客户端地址等网络信息，留存和分享时应遵循访问权限要求；结束后按 Ctrl+C 停止。

恢复验收与留证

修复后，不要只用服务器本机测试。至少从一个外部网络重新检查域名解析、TCP 连接、HTTP 响应和实际页面；若站点提供 IPv4、IPv6 两种入口，还应分别验证。HTTPS 验收需用真实域名正常访问，不要用跳过证书校验的结果代替证书检查。

可按以下项目逐项确认：

• 域名的 A、AAAA 或 CNAME 与预期入口一致，记录查询时间和使用的查询来源。
• 外部客户端能够连接实际提供服务的端口；不需要开放的端口仍保持关闭。
• 服务器监听地址、端口与部署架构相符，服务状态正常。
• 防火墙、云平台规则和回源限制均覆盖真实请求来源，没有为排障临时遗留过宽规则。
• Web 服务配置检查通过，访问日志能看到验收请求，错误日志没有对应的新故障。
• 反向代理所连接的应用能够响应，页面内容、关键路径及 HTTPS 证书符合预期。
• 从第二个外部网络重复测试，排除单一客户端缓存或网络路径造成的假恢复。

留证时记录故障时间段、测试设备所在网络、DNS 查询结果、目标地址和端口、curl 状态码、ss 监听结果、服务日志片段，以及每次配置变更和回滚点。不要只保存“网站已恢复”的截图；带有时间、目标和命令结果的记录更便于比较复发前后差异。分享日志或抓包前，检查并遮盖不应公开的访问令牌、Cookie、用户数据和内部地址信息。

恢复后可持续关注域名解析是否意外变化、80/443 端口的外部可达性、Web 服务重启记录、502/503/504 错误数量和应用健康状态。若故障再次发生，先对照上次留证确认变化发生在哪一层，再采取针对性处理，避免重复进行高风险的服务重启或防火墙调整。