晚高峰访问香港服务器变慢，先区分是“某一处网络访问慢”，还是“不同网络访问同一个服务都慢”；再确认变慢的是连接建立、页面首字节，还是页面加载过程。只有无线网络下异常、只有域名访问异常，以及固定服务器 IP 的延迟与丢包同时升高，分别对应不同的排查分支，不能仅凭一次 Ping 就认定服务器线路拥塞。

优先顺序是：检查本地网络 → 核对 DNS 与实际目标 IP → 对固定 IP 采集平峰、晚高峰 MTR → 判断路径变化与端到端丢包是否相关 → 检查服务器负载和应用响应。MTR 的关键不是寻找“最红的一跳”，而是看异常是否持续影响后续节点及终点，并与真实业务请求相互印证。

先固定测试条件，避免比较不同的访问路径

开始排查前，记录以下信息：

• 测试节点：所在城市、接入运营商、有线或无线、是否经过 VPN 或代理。
• 测试时间：日期、时区、异常开始时间，以及对应的平峰对照时间。
• 测试目标：业务域名、实际连接 IP、业务端口。
• 测试方式：IPv4 或 IPv6、ICMP 或 TCP、探测间隔、每轮样本数。
• 影响范围：哪些用户、页面或接口受影响，是否出现超时、重试。

以下命令适用于已安装相应工具的 Linux 环境，示例统一使用 IPv4。先检查版本与参数支持情况：

mtr --version
mtr --help
curl --version

文中的 192.0.2.10 是文档示例地址，www.example.com 是示例域名，执行前必须替换。命令以只读诊断为主，但会产生少量探测或 HTTP 请求；仅测试有权诊断的目标，不要同时启动大量高频任务。部分 MTR 探测需要管理员权限。

如果域名前有 CDN、负载均衡或代理，域名解析 IP 不一定是香港服务器源站。用户入口和源站应分别测试、分别标记，不能把两者的报告混作同一条路径。

第一处分支：问题是否已经出现在本地或 DNS

本地网关也不稳定，先处理接入侧

查看默认路由，再将实际网关地址填入 Ping 命令：

ip -4 route show default
ping -n -c 30 网关IPv4地址

同时观察是否存在本地上传占满带宽、无线信号波动、代理转发异常。可以在同一设备上改用有线网络复测，或用另一条接入网络访问同一目标作对照。

• 如果本地网关和远端目标同时波动，且换有线后恢复，优先处理本地接入问题。
• 如果只有一个接入网络异常，而其他节点正常，优先调查该节点的接入及后续路径。
• 如果不同网络均异常，再继续检查目标侧及各自路径，不宜直接归因为某一个中间节点。

网关也可能限制 ICMP 回包，因此网关 Ping 丢包本身不是定论；需要结合远端表现、接口统计和接入方式对照。

域名慢，不一定是路由慢

查询域名解析结果，并记录真实 HTTP 连接的目标：

dig www.example.com A +noall +answer +stats

curl -4 -sS -o /dev/null \
  --connect-timeout 5 --max-time 20 \
  -w 'ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/

选择轻量、只读且能代表问题的 URL，避免调用写入接口。上述超时值只是诊断参数，不是性能合格线。

若要绕过 DNS，并保留 HTTPS 所需的域名、Host 和 SNI，可执行：

curl -4 -sS -o /dev/null \
  --resolve www.example.com:443:192.0.2.10 \
  --connect-timeout 5 --max-time 20 \
  -w 'ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/

仅当固定到同一个实际服务 IP后，解析阶段耗时消失且整体响应反复改善，才支持继续调查 DNS。若固定的是另一个 IP，改善也可能来自后端或路径差异。不要直接改用 IP 访问 HTTPS 来比较，否则证书和虚拟主机差异可能干扰结果。

第二处分支：用 MTR 对照晚高峰路径与丢包

MTR 连续发送不同 TTL 的探测包，统计各跳回包的延迟和丢失比例。它显示的是探测往返结果，不是逐段链路的单向时延。

先对固定 IP 采集 ICMP 报告：

date -Is
mtr -4 -n -r -w -c 100 -i 1 192.0.2.10
date -Is

再以实际业务端口进行 TCP 对照，以下以 HTTPS 的 443 端口为例：

date -Is
sudo mtr -4 -n -r -w -T -P 443 -c 100 -i 1 192.0.2.10
date -Is

-n 关闭反向域名解析，便于按 IP 比较；-c 100 表示采集 100 个探测周期，-i 1 指定发送间隔。这是一轮观察样本，不足以覆盖整个晚高峰，建议在异常期间分时复测，并保留平峰对照。

如果 TCP 模式提示权限不足或参数不支持，应先检查本机 MTR 版本与权限；不要为了让报告“全通”而关闭防火墙。中间节点或目标不回应探测时，可以用真实 HTTPS 请求补证。

路由变化要按节点序列比较

比较时固定源节点、目标 IP、IP 协议版本和探测协议，重点观察：

1. 从哪一跳开始，节点 IP 或节点集合出现持续变化。

2. 路径变化后，终点的平均延迟与波动是否同步上升。

3. 同一时段重复采集，变化是否稳定存在。

4. 业务连接耗时、超时或错误率是否同步恶化。

负载均衡可能让探测落在不同分支，ICMP 与 TCP 也可能走出不同结果。因此，单次报告中某一跳 IP 变化，只能说明观察到路径差异，不能直接证明路由切换造成故障。

同样，不能仅凭节点名称、IP 地理定位或跳数增加断定“绕路”。只有路径变化与终点性能恶化在多个样本中持续相关，才形成进一步调查的依据。

如何读懂“丢包从哪里开始”

常见字段中，Loss% 是未收到回应的探测比例，Snt 是发送样本数；Avg 表示平均 RTT，Wrst 表示最差 RTT，StDev 反映波动程度。最差值容易受偶发尖峰影响，不宜单独作为归因依据。

中间跳丢包不等于业务丢包；终点丢包也要排除目标对探测回包的限速。 尤其当中间跳丢失比例明显高于终点时，不能把多出的比例解释成真实转发丢包。

“异常向后延续”只是定位可疑区间的线索。各跳回包可能走不同的返回路径，不能用相邻两跳 RTT 相减，准确计算它们之间的链路延迟。

若服务器和客户端均具备条件，可以从香港服务器向客户端可达地址反向探测。客户端位于 NAT 后或不允许入站探测时，该方法可能不可用；即使获得双向报告，也应分开分析，不能假定去程和回程相同。

网络证据不足时，转查系统与应用

如果晚高峰 MTR 的终点 RTT 大致稳定，而页面仍明显变慢，应检查连接建立之后的等待时间。curl 输出中的时间均为从请求开始累计的值；对于没有重定向的新建 HTTPS 连接，可以粗略拆分为：

• time_connect - time_namelookup：TCP 建连阶段。
• time_appconnect - time_connect：TLS 握手阶段。
• time_starttransfer - time_appconnect：握手完成后至首字节到达的等待。
• time_total - time_starttransfer：响应内容传输阶段。

首字节等待仍包含请求传输、网络往返和服务端处理，不能直接当成应用执行时间；命令行请求也不代表浏览器加载整页资源的耗时。

在服务器上同步查看系统状态：

date -Is
uptime
top -b -n 1
vmstat 1 10
ss -s
ip -s link

这些命令适用于具备常见 procps、iproute2 工具的 Linux，主要用于观察 CPU、运行队列、内存、交换、连接和接口计数。接口丢包计数应看异常窗口内的增量，不能把历史累计值当成当晚故障；vmstat 首行也不应与后续短间隔样本混为一谈。

再对齐同一时间段的访问日志、错误日志及已有应用监控：

• 建连正常，但首字节等待和应用处理时间同时升高：优先查应用排队及依赖响应。
• MTR 稳定，但服务器带宽占用与接口丢弃增量异常：调查服务器出口、限速或队列。
• 只有特定接口慢，轻量请求正常：优先检查该接口的应用处理链。
• 网络丢包与系统压力同时出现：两者可能并存，应分别验证，避免只修其中一项。

按证据修复，并在同一晚高峰验证

定位本地问题后，可先暂停异常占用流量的任务、切换有线连接；确认 DNS 问题后，再调整解析配置，并保留原设置以便恢复。怀疑路径问题时，向服务商提交源节点、目标 IP、时区、平峰与异常时段的 MTR、TCP 对照和业务错误记录，请其进一步核查，而不是只提交一个高丢包中间跳的截图。

若证据指向服务器或应用，配置调整前应保存原配置、明确影响范围并准备回滚。不要把重启服务或修改防火墙当作首轮网络诊断手段。

修复验证必须复用原来的源节点、目标 IP、探测协议和业务 URL，并覆盖相近的晚高峰窗口。检查终点延迟与波动、探测丢包、请求超时、首字节等待和应用错误是否共同改善；不能用“改完后恰好进入平峰”的结果证明恢复。

后续保留轻量业务探测，记录实际连接 IP、连接耗时、首字节等待与错误率，在异常触发时再采集 MTR。这样再次访问香港服务器变慢时，才能分辨是同一路径复发、入口 IP 变化，还是网络正常而应用响应退化。