深圳访问香港服务器时，Ping 显示几毫秒或十几毫秒，只能说明 ICMP 数据包在测试时刻往返较快。一次真实的网站访问还需要经过 DNS 解析、TCP 建连、TLS 握手、服务器处理和内容下载，其中任何一个阶段出现等待，都会形成“Ping 很低，但实际访问仍然卡顿”的现象。

一组针对香港公开测试节点的 Globalping 对照数据，可以更直观地说明这种差异。

Globalping 实测：低 Ping 不等于完整访问耗时低

测试条件

• 测试工具：Globalping
• 测试时间：2026 年 9 月 1 日 15:12—15:16，UTC+8
• 测试位置：Globalping 标记为深圳的探针
• 测试目标：123.176.101.27
• 对应域名：hk03.layerstack.com
• 目标位置：LayerStack HongKong03 公共 Looking Glass 测试节点
• 测试类型：ICMP Ping、ICMP MTR、HTTPS HEAD
• IP版本：IPv4

LayerStack 的公开测试页面将 123.176.101.27 标记为 HongKong03 测试 IPv4。

为了减少探针变化带来的误差，后续 MTR 和 HTTP 测试复用了第一次 Ping 测量所选择的三台探针。Globalping API 支持通过已有测量 ID 复用同一组探针。

这是一组用于解释网络机制的公开目标测试，不代表所有香港服务器，也不能替代发生卡顿时对实际业务域名和源站 IP 的测量。

Ping 测试结果

每个探针连续发送 16 个 ICMP 数据包：

三组结果都没有丢包，延迟波动也不明显。如果只看其中的 AS4134 探针，平均 RTT 约为 14.5 毫秒，可以得出“深圳到该香港节点基础网络延迟较低”的有限结论。

但即使目标地址和城市相同，不同网络的平均 RTT 仍然分别约为 14.5、42.4 和 38.7 毫秒。这说明“服务器在香港、测试点在深圳”不足以推导固定延迟，探针所在网络和实际路由同样重要。

另一轮覆盖五个深圳探针的测试中，平均 RTT 从 14.574 毫秒到 131.710 毫秒不等，所有探针在该轮测试中均为 0% 丢包。

这组结果不能说明某条线路长期优劣，但可以证明：地理位置相同，不等于网络路径和访问表现相同。

同一探针的 HTTPS 请求用了多久？

随后使用相同三台深圳探针，对 https://hk03.layerstack.com/ 连续执行三轮 HTTPS HEAD 请求。三轮均解析到与 Ping 相同的 123.176.101.27，HTTP 状态码均为 200。

最典型的是 AS17962 探针。它的 Ping 平均 RTT 为 42.425 毫秒，但第一次 HTTPS 请求总耗时达到 2013 毫秒。进一步拆分后可以看到：

第一次请求慢的主要原因不是香港服务器的 ICMP RTT，而是 DNS 解析耗费了 1810 毫秒。随后两次 DNS 分别只用了 10 毫秒和 1 毫秒，总耗时也随之恢复到 195 毫秒和 186 毫秒。

这就是低 Ping 与偶发卡顿可以同时存在的具体例子：Ping 测试绕过了域名解析阶段，所以 DNS 异常不会反映在 Ping IP 的结果中。

另外两个探针也呈现相同规律。AS4134 的 Ping 平均只有 14.548 毫秒，但完整 HTTPS HEAD 请求分别用了 192、95 和 79 毫秒；AS45090 则分别用了 210、124 和119毫秒。低 RTT 是快速访问的有利条件，但不是完整请求耗时。

MTR 进一步说明了什么？

同一组探针的 ICMP MTR 最终目标结果如下：

MTR 中部分中间节点出现不响应或较高的显示丢包，但这些异常没有持续到最终目标。此时不能直接认定中间节点发生了真实转发丢包，因为路由设备可能限制或忽略 ICMP 响应。

Globalping 的 MTR 结果会提供各跳的延迟、丢包和标准差等数据，但判断网络故障时仍应观察异常是否延续至最终目标。

本次 MTR 最终目标没有出现丢包，因此这组测试不能证明实际卡顿由丢包造成。它能够支持的结论是：不同深圳网络到同一香港目标存在明显路径差异，同时基础 ICMP 表现正常也不能排除 DNS、HTTPS或业务层问题。

为什么 Ping 很低，实际访问却可能更慢？

Ping 只测 ICMP 往返

Ping 通常发送 ICMP Echo Request，再根据 Echo Reply 计算 RTT。RFC 792 定义了这两类 ICMP 消息。

它不包含：

• 域名解析；
• TCP或QUIC建连；
• TLS加密协商；
• HTTP请求处理；
• 数据库查询；
• 页面资源下载；
• JavaScript执行和浏览器渲染。

因此，Ping 十几毫秒不能直接理解为“网页十几毫秒打开”。

DNS可能形成偶发长等待

本次实测中，AS17962 探针第一次 DNS 解析用了 1810 毫秒，而后两次只有 10 毫秒和1毫秒。

这种问题可能来自：

• 本地递归解析器响应异常；
• 缓存未命中；
• DNS上游暂时缓慢；
• 域名包含多级CNAME；
• IPv4和IPv6解析或连接尝试差异；
• 客户端网络的DNS配置异常。

如果用户直接 Ping 服务器 IP，DNS 阶段完全不会参与测试，也就无法暴露这类问题。

TCP和TLS会继续增加等待

网页访问并不是收到一个 ICMP 回包就结束。HTTPS 通常还需要建立连接并完成 TLS 协商。

在 AS4134 探针的三轮测试中，Ping 平均 RTT 为14.548毫秒，但 TLS 阶段分别用了62、59和57毫秒。AS17962 的 TLS 阶段则分别用了102、92和92毫秒。

这些结果并不表示 TLS 存在故障，而是说明完整 HTTPS 请求天然包含 Ping 没有测量的步骤。网络往返、加密协商、代理设备和服务端处理都会累积到最终耗时中。

低延迟不等于高吞吐

Ping 数据包很小，而图片、程序文件和视频需要持续传输大量数据。即使 Ping 很低，以下问题仍可能导致内容下载缓慢：

• 共享出口拥塞；
• 端口限速或单连接限速；
• 实际可用带宽不足；
• TCP重传；
• CDN回源缓慢；
• 大量并发连接争抢资源。

TCP检测到丢包后可能触发重传和拥塞控制，降低发送窗口；重传超时也会增加额外等待。

因此，低 RTT 不能代替下载测试，也不能证明服务器提供了足够的持续吞吐。

TTFB可能暴露服务器内部瓶颈

如果 DNS、TCP和TLS都正常，但等待首字节的时间很长，排查重点应转向：

• CPU负载；
• 内存与Swap；
• 磁盘I/O；
• PHP-FPM或应用线程池；
• 数据库慢查询；
• Redis或缓存服务；
• 第三方API；
• WAF与反向代理；
• 应用内部锁等待。

Ping 只到达服务器网络接口附近，不会执行数据库查询或业务逻辑。网络层正常，应用层仍然可以很慢。

HTTP HEAD正常，也不等于页面完全加载正常

本次 Globalping 使用的是 HEAD 请求，只测量连接、握手和响应头，不下载完整页面内容，所以各轮结果中的下载阶段均为0毫秒。

真实浏览器还可能继续请求：

• 图片；
• CSS；
• JavaScript；
• 字体；
• 广告与统计脚本；
• 验证码；
• 第三方接口。

因此，这组 Evidence 用于证明“Ping与HTTPS请求不是同一指标”，不能证明该测试网站的完整页面加载性能。判断真实访问卡顿，还需要执行HTTP GET、浏览器瀑布图和静态资源下载测试。

如何排查自己的香港服务器？

1. 保证测试目标一致

同时记录：

• 业务域名；
• 域名解析到的A和AAAA记录；
• 浏览器实际连接IP；
• 香港源站IP；
• 是否经过CDN、WAF或负载均衡。

如果 Ping 的是源站IP，而浏览器访问的是CDN节点，两组结果不能直接比较。

2. 使用同一探针组合测试

针对实际目标，在 Globalping 中从深圳不同网络执行：

• ICMP Ping；
• ICMP MTR；
• TCP Ping 443；
• HTTPS HEAD；
• HTTPS GET；
• DNS查询。

尽量复用相同探针，避免因为探针变化把两条不同网络路径误认为同一次对照测试。

3. 不要只测一次

至少分别记录：

• 正常时段；
• 实际卡顿时段；
• 工作日和非工作日；
• 不同运营商；
• 首次请求和重复请求。

本次实测中，同一个探针的 HTTPS 总耗时可以从第一次的2013毫秒降至后续的195和186毫秒。只测后两次，就可能错过前一次DNS长等待；只测第一次，也可能把瞬时异常错误解释成长期状态。

4. 根据阶段定位问题

深圳到香港服务器的低 Ping 只能说明基础 RTT 具备一定优势。实际访问是否流畅，需要把 DNS、TCP、TLS、TTFB、内容下载和页面渲染分别测量。只要其中一个阶段偶发增加一到两秒，用户就会感受到卡顿，而平均 Ping 仍然可能保持在十几毫秒。