用户访问网站时，请求会从本地 DNS 解析开始，经过客户端到香港服务器的网络路径，再完成 TCP、TLS 建连，最后由 Web 服务、应用及数据库或其他依赖处理。香港服务器搭配CN2线路后出现偶发超时，只能说明部分请求未能在预期时间内完成，不能据此认定线路拥塞；Ping 正常也不能证明 HTTPS 请求正常，因为 ICMP 探测与业务连接可能受到不同处理。

排查应先记录失败请求的时间、入口、目标地址和错误类型，再依次检查访问入口、网络路径、服务器资源和应用处理。优先使用只读命令，并把客户端测试、服务器访问日志和应用日志按时间或请求标识关联。每次依据证据处理一个环节，修复后再用原来的访问条件复测，避免同时修改多项配置而无法确认根因。

先确定故障范围：哪些入口、哪些请求会超时

先记录异常请求的发生时间、访问域名、具体路径、客户端所在网络、错误提示及是否重试成功。然后确认问题范围：

• 同一网络下的多个终端是否都失败？
• 不同网络入口访问同一请求时，结果是否一致？
• 只有某个页面或接口超时，还是多个 HTTPS 请求都受影响？
• 用户访问的是域名还是服务器地址？实际连接的目标 IP 是否符合预期？
• 网站是否经过 CDN 或其他接入层？入口层请求记录与源站日志是否都能取得？

这些信息有助于区分单个客户端或解析结果异常、入口层转发异常、到服务器的网络问题，以及服务器内部处理缓慢。若经过 CDN，应分别核对用户到入口层、入口层到源站两段记录；入口层超时不等于源站网络线路必然异常。

在 Linux 或 macOS 客户端上，可在故障时执行以下只读测试。将域名和路径替换为实际请求：

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s status=%{http_code}\n' \
  --connect-timeout 5 --max-time 20 \
  'https://www.example.com/实际路径'

这条命令会发起一次 HTTPS 请求，不会修改服务器配置。--connect-timeout 和 --max-time 是本次测试的等待上限，不是对网站性能的要求；如业务正常响应时间明显不同，可按测试目的调整。重点记录各阶段耗时、状态码和 remote_ip：

单次成功不能排除偶发问题。应在异常时段多次采样，保留成功和失败请求的时间、目标 IP、状态码与分段耗时；条件允许时，从不同网络入口执行相同测试。若只有一个入口失败，优先核对该入口的解析结果和路径；若多个入口同时失败，且服务器日志出现对应异常请求，则继续检查服务器内部处理。

按时间线检查网络路径与服务器是否收到请求

确认实际连接的目标 IP 后，再检查客户端到该地址的路径。Linux 上已安装 mtr 时可执行：

mtr -rw -c 100 www.example.com

若域名有多个解析地址，应先用 curl 记录的 remote_ip 确认本次请求连接到哪个地址，再针对该地址进行路径测试。也可使用系统已有的 traceroute 或 tracepath。这些工具用于观察路由和探测响应，不足以单独证明业务流量是否丢失：中间节点可能限制探测响应，路由也可能存在回程差异。

某一跳显示丢包，但后续节点和 HTTPS 请求正常，通常不足以判定该跳就是故障点。若异常从某一位置开始并持续影响后续节点，同时同一时段的业务连接也失败，才有更强的关联证据。即便如此，仍要结合服务器端日志和实际请求结果判断，不能仅凭 Ping 或一段路由输出认定香港服务器搭配CN2线路的链路存在故障。

接下来将客户端失败时间与服务器访问日志、入口层记录对齐：

• 客户端超时，服务器没有对应请求：请求可能未到达 Web 服务，也可能落到了其他入口，或因日志未覆盖、时区不一致而无法匹配。先核对目标 IP、入口层记录、服务器时区和日志范围，再判断网络路径。
• 服务器有对应请求，状态码或耗时异常：请求已到达服务端，应继续检查 Web 服务、应用和依赖，不能只归因于客户端到服务器的链路。
• 服务器记录成功且处理时间较短，客户端仍超时：核查响应传输、入口层转发和客户端路径，并确认两端记录属于同一次请求。可用请求 ID、业务流水号或精确时间进行关联。
• 入口层有请求但源站没有对应记录：核对入口层到源站的转发记录、目标地址及超时类型，不能把入口层等待超时直接等同于源站应用超时。

若客户端超时发生在连接建立前，服务端无记录只是一个线索，不是网络故障的充分证据；若请求已进入 Web 服务，则应优先沿服务端耗时继续向内定位。

在故障时段检查服务器资源和服务状态

资源检查应尽量在超时发生时进行。以下命令适用于使用 systemd 的 Linux 系统，均为查询操作：

date -Is
uptime
free -h
vmstat 1 5
df -h
ss -s
ss -lnt

这些结果可用于发现负载、内存、磁盘空间、连接数量和监听端口方面的线索。负载偏高不必然表示 CPU 已耗尽；磁盘空间充足也不表示磁盘读写没有延迟。要结合故障时间查看 CPU、内存、磁盘读写和连接数变化。短时尖峰可能在故障恢复后已经消失，因此当前状态正常不能排除此前发生过资源压力。

确认实际运行的 Web 服务名称后，再读取对应状态和日志。以下以服务名 nginx 为例；如果实际服务名不同，先通过系统服务列表核实，不要直接照搬：

systemctl status nginx --no-pager
journalctl -u nginx --since 'YYYY-MM-DD HH:MM:SS' --until 'YYYY-MM-DD HH:MM:SS' --no-pager

将时间范围替换为故障时段，并确认服务器时区。若日志显示进程重启、工作进程异常退出、连接关闭或资源分配失败，应继续查服务状态与系统资源；若服务运行正常且资源指标没有明显异常，则向应用日志和下游依赖排查。当前的 systemctl status 只能反映当前状态，过去是否发生过短时异常应以对应时段的日志为准。

同时检查业务端口是否监听，以及防火墙或安全策略是否有同期变更。调整防火墙规则会改变实际连接能力；操作前应备份当前规则，确认影响范围并准备回滚方案。没有明确证据时，不要通过放宽所有访问规则来试错。

用请求耗时区分 Web 服务与应用瓶颈

如果 Web 访问日志没有记录请求总耗时、上游响应耗时和状态码，可在评估后补充相关字段。以 Nginx 为例，常见变量包括 $request_time、$upstream_response_time 和 $status。字段含义及可用性应以当前 Nginx 版本和实际配置为准。修改日志格式前应备份配置、检查语法，并确认不会覆盖现有日志格式或影响日志采集；涉及生产变更时，应安排可回滚的操作窗口。

按同一请求进行对照：

如果字段缺失，不要把缺失值当作零耗时；不同请求、入口和时间段的数据也不能直接横向比较。应使用请求 ID、时间戳或业务流水号关联访问日志与应用日志。若慢请求集中在同一接口，先查该接口涉及的数据库查询和下游调用；多个接口同时变慢时，再检查共享资源或公共依赖。

形成根因判断：让时间、请求和日志能够互相印证

一次可复核的故障记录，应至少包含客户端测试结果、目标 IP、服务器访问日志、应用日志及故障时段的资源指标。根因判断要回答三个问题：异常发生在哪个环节，有哪些直接证据指向该环节，修复后相同条件下是否恢复。

例如，客户端连接阶段失败、服务器没有对应请求，且同一时间多个入口的后续路径测试与业务连接均出现异常，网络路径问题的可能性会上升；如果请求已进入 Web 服务，访问日志显示等待上游时间增加，应用日志又记录数据库连接等待，则应优先处理应用或数据库侧瓶颈。这些是证据组合的判断方式，不代表所有此类超时都有相同根因。

时间戳必须统一核对：确认客户端和服务器记录的时区，检查日志是否轮转、是否包含对应入口，并优先用请求 ID 等标识关联同一请求。缺少服务端记录时，不能仅凭“没有日志”断定请求未到达；服务端响应较快时，也不能仅凭这一项排除客户端到服务器之间的传输问题。

针对已定位环节修复，并按原条件复测

修复范围应与证据对应，不要直接更换整条链路或同时修改多项配置：

• 证据指向解析或入口配置：修正对应记录或转发目标，核对不同客户端解析结果和实际连接地址。变更前记录原配置并准备恢复方式。
• 证据指向网络路径：整理故障时间、目标地址、路由采样、客户端错误和服务器是否收到请求等材料，交由相应网络维护方核查。不要只提交单次 Ping 结果作为故障结论。
• 证据指向 Web 服务、应用或数据库：依据请求耗时和日志定位具体等待点。修改配置或相关数据前先备份，确认影响范围、验证方式和回滚步骤。
• 证据指向入口层与源站之间的转发：分别对照入口层请求记录和源站日志，先确认超时发生在哪一段，再调整对应配置。

复测时保持故障时的域名、请求路径、客户端入口和协议一致，并记录每次测试的时间与目标 IP：

1. 重新采集 DNS、连接、TLS、首字节和总耗时，确认原先异常的阶段是否恢复。
2. 对照服务端访问日志和应用日志，确认请求已到达、状态码符合预期，服务端处理耗时没有异常增加。
3. 从多个入口重复测试，并覆盖此前容易出现故障的业务时段。连续成功只说明测试期间未复现，不能保证以后绝不会发生。
4. 若问题再次出现，先保留失败请求时间、目标 IP、错误信息及对应服务器日志，再决定是否回滚或继续调整；不要先清理日志、重启服务或同时修改多项配置。

后续可为关键请求保留分段耗时和请求标识，并持续观察应用错误率、上游等待时间及资源变化。再次出现偶发超时时，按客户端入口、网络路径、服务器资源、应用依赖的顺序复测：先确认请求是否到达，再判断服务端在哪一步耗时增加，最后验证对应修复是否改善同一请求条件下的结果。