香港服务器上的网站无法访问，浏览器显示的“打不开”可能对应完全不同的故障：域名没有解析到正确地址、IPv6 入口不可用、80/443 端口被拦截、Web 服务没有监听，或者反向代理已经接收到请求但后端应用返回了 502、504、500 等错误。排查时不能只根据浏览器提示重启服务器或关闭防火墙，否则可能掩盖真正原因并扩大影响范围。

建议按照“现象确认 → DNS → 网络入口 → 端口监听 → 防火墙规则 → Web 服务与反向代理 → 应用状态 → 修复后复测”的顺序进行。先从外部观察低风险信息，再登录香港服务器检查内部状态；每一步记录结果，只有在证据指向明确时才修改配置。

先确认故障范围和具体错误

开始前记录以下信息：

• 故障开始时间以及是否持续发生；
• 访问的完整域名和协议，例如 http://example.com 或 https://example.com；
• 浏览器显示的错误、HTTP 状态码或证书提示；
• 近期是否修改过 DNS、证书、Web 配置、防火墙或安全防护规则；
• 故障是所有访问者都遇到，还是只有某台设备、某个网络出现。

先用原设备重新访问一次，再使用另一台设备或不同网络访问同一域名。结果可以帮助划分范围：

这些现象只是初步线索。例如，连接超时既可能是防火墙丢弃连接，也可能是服务器没有响应；必须结合 DNS 查询、端口测试和服务日志进一步确认。

1. 核对 DNS 是否指向正确的网站入口

先确认域名当前的 A 和 AAAA 记录。Linux、macOS，或已经安装 dig 的环境可以执行：

dig example.com A
dig example.com AAAA

将 example.com 替换为实际域名。Windows PowerShell 可以执行：

Resolve-DnsName example.com

重点查看：

• A 记录是否指向预期的 IPv4 入口；
• AAAA 记录是否指向确实可用的 IPv6 入口；
• 记录名称是否填写正确；
• 域名是否使用了 CDN、负载均衡或其他前置网站入口；
• 当前解析结果是否与网站实际部署架构一致。

如果域名经过 CDN 或其他前置服务，查询结果可能不是香港服务器的公网地址，而是前置入口地址。这种情况下，不能因为解析结果与服务器地址不同就直接判定 DNS 错误，应继续确认“用户到前置入口”和“前置入口到源站”两个连接是否都正常。

如果查询不到记录、返回旧地址，或不同网络查询结果不一致，应回到解析管理平台核对记录类型、主机记录、目标值和启用状态。修改前保存原记录，确认目标地址无误后再调整。DNS 修改后，不同递归 DNS 的缓存更新时间可能不同，不能为了立即生效而频繁来回修改；应从多个网络重复查询并记录结果。

单独验证 IPv4 和 IPv6

域名同时发布 A 和 AAAA 记录时，部分客户端可能优先尝试 IPv6。如果香港服务器的 IPv6 入口、监听或防火墙规则没有配置完整，就可能出现部分用户无法访问、部分用户正常的情况。

可以分别测试：

curl -4 -I --connect-timeout 5 https://example.com/
curl -6 -I --connect-timeout 5 https://example.com/

这里的 -4 和 -6 分别强制使用 IPv4、IPv6，-I 只请求响应头，--connect-timeout 5 用于避免连接阶段长时间等待。

判断方式如下：

• IPv4 成功、IPv6 失败：检查 AAAA 记录、香港服务器的 IPv6 地址、Web 服务 IPv6 监听以及入站规则；
• IPv6 成功、IPv4 失败：检查 A 记录、IPv4 入口和 IPv4 防火墙规则；
• 两者都失败：继续检查入口、端口和服务状态；
• 两者都成功，但浏览器仍异常：继续核对 TLS、虚拟主机、页面资源或应用响应。

不要在没有确认业务需求前直接删除 AAAA 记录。若需要临时调整记录，应保留原值，并在 IPv6 服务修复后重新验证。

2. 从外部确认请求到达了哪个入口

DNS 正确并不代表网站已经可访问。使用 curl 查看连接、TLS 握手和 HTTP 响应过程：

curl -v -o /dev/null --connect-timeout 5 --max-time 15 https://example.com/

该命令适用于常见 Linux、macOS 终端以及安装了 curl 的环境。Windows 中可以使用：

curl.exe -v -o NUL --connect-timeout 5 --max-time 15 https://example.com/

-v 会显示解析、TCP 连接和 TLS 握手过程；--max-time 15 限制本次请求最长执行时间。Windows 使用 curl.exe 可以避免 PowerShell 命令别名造成的参数差异。

重点观察故障发生阶段：

• 能看到解析出的目标地址，但 TCP 连接超时：优先检查网络入口、入站规则或防火墙；
• TCP 连接立即被拒绝：目标地址可达，但对应端口没有服务监听，或入口主动拒绝；
• TLS 握手完成并返回 HTTP 状态码：请求已经到达某个 Web 服务，继续检查站点配置和应用；
• TLS 握手失败：检查证书有效期、域名匹配、证书链、443 监听以及 HTTPS 虚拟主机；
• 返回 502 或 504：前端入口正常接收请求，但到后端应用的连接或响应异常。

如果已经确认香港服务器公网地址，并且维护人员有权访问该服务器，可以用 --resolve 临时指定连接地址，同时保留原域名的 Host 和 TLS SNI：

curl -v -o /dev/null --connect-timeout 5 \
  --resolve example.com:443:203.0.113.10 \
  https://example.com/

将示例域名和地址替换为实际值。该命令只影响当前请求，不会修改 DNS。

• 指定地址访问正常、普通域名访问失败：优先回查 DNS 或前置入口配置；
• 指定地址也失败：继续检查该入口的端口、监听状态和防火墙；
• 指定地址返回的站点与预期不一致：可能命中了错误的虚拟主机、默认站点或错误入口。

3. 从外部测试 80 和 443 端口

网站通常使用 HTTP 的 80 端口或 HTTPS 的 443 端口，实际端口应以站点配置为准。不要只在香港服务器本机访问，因为本机成功只能证明本机路径可用，不能证明公网入口可用。

Linux 或 macOS 中，如果安装了 nc，可以执行：

nc -vz -w 5 example.com 80
nc -vz -w 5 example.com 443

Windows PowerShell 可以执行：

Test-NetConnection example.com -Port 80
Test-NetConnection example.com -Port 443

判断结果：

• 端口连接成功：至少已经建立 TCP 连接，下一步检查 HTTP、TLS、虚拟主机、反向代理和应用响应；
• 端口连接超时：重点检查公网入口、主机防火墙、云平台或服务器管理面板中的入站规则；
• 端口连接被拒绝：目标地址可达，但没有相应服务监听，或服务明确拒绝连接；
• 80 正常、443 失败：检查 HTTPS 服务、证书、443 监听和 443 入站规则；
• 443 正常、浏览器仍提示异常：检查证书域名、证书链、TLS 配置及站点内容。

在香港服务器上查看监听状态

如果使用 Linux 服务器并采用 systemd 管理服务，可以执行：

sudo ss -lntp

查看输出中是否存在 :80、:443 或站点实际使用的端口，并留意监听地址：

• 127.0.0.1:443：通常只接受本机连接，外部客户端不能直接访问；
• 0.0.0.0:443：表示监听所有 IPv4 地址；
• [::]:443：表示监听 IPv6 地址，仍需结合 IPv6 入站规则确认；
• 没有对应端口：检查 Web 服务是否启动、配置是否加载成功以及端口是否被其他程序占用。

不要在未确认站点架构时随意增加监听端口。若网站通过反向代理转发到应用，公网通常只需要 Web 入口监听的端口，应用端口可能只应监听本机地址。

4. 核对主机防火墙和入口规则

当服务已经监听，但外部端口仍然超时，应检查两类规则：

1. 香港服务器本机的防火墙；
2. 主机管理面板、云平台或其他前置安全防护中的入站规则。

先读取当前配置，不要为了测试直接关闭防火墙或清空全部规则。使用哪种命令取决于系统实际采用的规则工具。例如：

sudo ufw status verbose
sudo nft list ruleset

如果命令不存在，应先确认系统使用的是哪一种防火墙管理方式，不要把其他发行版的命令直接套用。

检查以下条件是否一致：

• 80、443 是否被允许；
• 规则作用的网卡是否为当前公网入口；
• 规则是否限制了来源地址；
• IPv4 与 IPv6 是否分别配置；
• 是否存在更早匹配的拒绝规则；
• 前置安全防护是否只允许特定来源访问。

典型判断是：服务器本机访问正常、服务确认正在监听、外部连接持续超时，此时防火墙或入口规则的可能性较高；如果外部端口立即被拒绝，则仍要优先确认服务是否监听，不能仅凭现象修改规则。

防火墙调整属于有影响的操作。变更前应导出或记录现有规则，确认已有 SSH 或管理控制台通道不会被一并阻断，只增加必要端口和必要来源范围。修改后立即从外部网络复测；如果管理连接中断或网站访问恶化，应通过控制台或备份规则恢复原配置。不要把关闭全部防护作为常规排障手段。

5. 检查 Web 服务和反向代理状态

端口可达但页面仍然异常时，登录香港服务器检查实际运行的 Web 服务。以下命令适用于使用 systemd 的 Linux 系统，服务名称必须按实际安装情况核实：

systemctl status nginx --no-pager

如果不确定是否使用 Nginx，可以先查看正在运行的服务：

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

不要假设所有网站都使用 Nginx。若实际使用其他 Web 服务，应替换为对应服务名。查看与故障时间相符的日志，例如：

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

重点关注：

• 配置文件加载失败；
• 端口被其他进程占用；
• 证书文件不存在、权限不足或格式错误；
• 反向代理连接上游失败；
• 工作进程退出或反复重启；
• 请求是否命中了预期域名和站点。

日志时间必须与当前故障时间对应。旧日志只能说明过去发生过问题，不能单独证明当前故障原因。

502、504：检查反向代理到应用的连接

如果网站返回 502 或 504，说明前端 Web 服务通常已经收到了请求，但连接后端应用失败、上游地址错误，或者应用在规定时间内没有返回结果。

先核对反向代理配置中的：

• 上游主机地址；
• 上游端口；
• 通信协议；
• 应用是否仍在运行；
• 应用监听地址是否与代理配置一致。

如果应用配置为本机 127.0.0.1:8080，可以在服务器本机执行：

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

示例端口应替换为配置中的实际上游端口。结果含义如下：

• 连接被拒绝：应用没有监听该端口，或监听地址与配置不一致；
• 请求超时：应用无响应、处理阻塞，或本机规则阻断；
• 返回应用页面或状态码：本机到应用的连接已经建立，应继续检查反向代理转发配置和应用日志；
• 返回的内容不是预期应用：可能连接到了错误端口或错误服务。

这项本机测试只能验证服务器到上游应用的连接，不能代替公网访问验证。若应用要求特定 Host 请求头，还应按应用实际配置补充 Host；不要因为本机返回 404 就立即认定应用进程故障。

修改 Nginx 配置前先做语法验证

如果确认使用 Nginx，修改配置前先备份相关配置文件，并记录变更内容。完成修改后先执行：

sudo nginx -t

只有语法检查通过，才考虑平滑重载：

sudo systemctl reload nginx

如果 nginx -t 失败，不要重载。应根据报错修正配置，或者恢复变更前的备份文件，再次执行 nginx -t。如果重载后网站异常，应恢复最近一次变更，重新做语法检查并复测。

服务名称、配置路径和重载方式可能因安装方式不同而变化，应以本机服务定义为准。不要直接覆盖整份配置，也不要在没有备份和回滚通道的情况下批量修改站点配置。

6. 根据 HTTP 状态码继续定位

当请求已经得到 HTTP 响应时，故障范围通常已经从“网络不可达”缩小到 Web 服务、站点配置或应用层。

403

请求已到达网站服务，但访问规则拒绝了请求。检查：

• 站点访问控制；
• 目录或文件访问规则；
• 默认拒绝配置；
• 前置安全防护策略；
• 是否命中了错误的虚拟主机。

不要为了排查直接递归修改网站目录权限。先从访问日志确认请求命中的站点和路径，再核对实际运行用户、目录用途及权限继承关系。

404

Web 服务正常处理了请求，但没有找到对应路径。检查：

• 域名是否命中了正确站点；
• 网站根目录是否正确；
• URL 路由是否存在；
• 反向代理是否改写了路径；
• 应用是否只支持特定 Host 或入口路径。

如果首页 404、静态文件也异常，优先检查站点根目录和虚拟主机匹配；如果只有某个业务路径 404，应继续查看应用路由和程序日志。

500

请求已经进入应用或 Web 服务，但处理过程中发生内部错误。查看与故障时间对应的 Web 错误日志和应用日志，重点检查配置错误、依赖服务异常、程序启动失败或运行时错误。不要通过删除缓存、数据文件或大范围修改权限来“试修”，这些操作可能造成不可逆影响。

TLS 或证书错误

如果 TCP 443 连接成功，但 TLS 握手失败或浏览器提示证书错误，应核对：

• 证书是否覆盖当前访问域名；
• 证书是否已过期；
• 证书链是否完整；
• HTTPS 虚拟主机是否配置了正确证书；
• 443 监听是否加载了最新配置；
• 反向代理或前置入口是否使用了另一套证书。

证书更换前保存旧证书路径和配置，确认新证书文件权限及格式后再修改，并通过 nginx -t 或实际 Web 服务提供的配置检查命令验证。验证失败时恢复旧配置，不要直接删除旧证书文件。

7. 用结果分支确定下一步

可以按以下分支缩小故障范围：

• DNS 解析错误，但指定入口地址访问正常：核对解析记录、前置入口和缓存状态，修正后从多个网络重新查询。
• DNS 正确，外部端口超时，服务器没有监听：检查 Web 服务状态、配置加载结果和监听端口。
• 服务器已经监听，外部端口仍超时：核对主机防火墙、管理面板入站规则、网卡和地址族。
• 外部端口连通，但 TLS 握手失败：检查证书、域名匹配、证书链和 HTTPS 站点配置。
• 返回 502 或 504：检查反向代理的上游地址、应用进程、应用监听端口和应用日志。
• 返回 403、404 或 500：请求已进入 Web 服务，继续按访问日志、虚拟主机、路径规则和程序日志定位。
• 只有 IPv6 失败：对照 AAAA 记录、IPv6 监听和 IPv6 入站规则，确认修复服务还是调整记录。
• 本机访问正常、外部访问失败：优先检查公网入口和防火墙，不要把本机成功当作公网可用的证明。
• 普通域名访问失败、--resolve 指定地址正常：优先检查 DNS 或前置入口，而不是立即修改应用。

修复后怎样从外到内复测

每次只改变一个明确的故障点，并记录修改时间、修改内容和恢复方式。修复后按以下顺序验证：

1. 重新查询 A、AAAA 记录，确认解析结果符合当前架构；
2. 从至少两个不同网络测试域名访问；
3. 分别测试 80、443 端口；
4. 使用 curl -v 检查完整连接、TLS 和 HTTP 状态；
5. 用浏览器确认地址栏证书、页面内容和静态资源是否正常；
6. 查看 Web 访问日志，确认请求命中了预期域名和站点；
7. 查看错误日志，确认 502、504、500 等错误没有继续增加；
8. 如果使用 CDN 或反向代理，分别验证用户到入口、入口到香港服务器、香港服务器到应用这三段连接。

复测不能只看首页是否打开。HTTPS 网站还要检查证书域名、证书链、页面脚本、样式和图片是否能够加载；反向代理网站还要确认后端接口和登录等实际业务路径。若复测结果与预期不符，应先恢复最近一次变更，再根据新的错误现象重新判断故障层级，而不是连续叠加配置修改。