海外服务器延迟只看平均值会选错机房：11 个地区 p50/p95/p99 尾延迟与抖动实测

选地区时盯着平均延迟，等于只看了最快的 50% 用户，而卡顿来自剩下的 5%。2026 年 10 月 29 日 06:02–06:08 UTC，我们从美西圣何塞一台节点（38.55.134.58，AS402169 Uscloud）用同一批参数测了 11 个地区：每地 120 个 ICMP 样本、6 个 AWS 地区的 40 轮交错 TCP/443 握手、3 条 traceroute -T 路径，再把每个地区拆成 min / p50 / p90 / p95 / p99 / max 加相邻抖动共七个口径。结果给出三个与「平均值直觉」相反的结论：离节点最近的洛杉矶中位数只有 11.7 ms，却是 11 个地区里尾部最脏的（p99 76.7 ms、p99/p50 放大 6.56 倍、还丢了 2.5% 的包）；最远的欧洲反而最稳（阿姆斯特丹 p99/p50 只有 1.16、零丢包）；热门的新加坡中位数 176.5 ms 里藏着 15.9 ms 的相邻抖动，是欧洲的 3.4 倍。这篇把每个数字的来源、最容易踩的采样量陷阱（只 ping 10 个包时多伦多的 p95 会被高估 97%）和一套 30 分钟能跑完的自测流程都写清楚。

Meta Description: 2026-10-29 实测 11 地区 120 包 ICMP 分位数与 6 地区 TCP 握手：洛杉矶 p99/p50 达 6.56 倍，欧洲仅 1.16~1.28，附采样量陷阱与自测命令。

关键词：海外服务器、延迟测试、p95、p99、尾延迟、抖动、地区选择、线路对比

一、先把结论摆出来：平均值只是「最快那一半」的成绩单

四个结论，后面的每一节都是它们的证据。

第一，中位数（p50）在 11 个地区里全部接近平均值，看起来毫无风险。11 个地区的 mean/p50 比值只有 1.01 到 1.35，最夸张的洛杉矶也只是 15.80 / 11.70 = 1.35。所以任何用「平均延迟」做出来的排名表，都会得出同一个乐观结论：都还行。

第二，把口径换成 p99，排名立刻分成两档。阿姆斯特丹 1.16、法兰克福 1.26、伦敦 1.28、新泽西 1.30、首尔 1.35、悉尼 1.37 属于「稳」的一档；新加坡 1.53、多伦多 1.78、东京 1.88、芝加哥 2.18 属于「中」；洛杉矶 6.56 单独一档。注意这不是绝对值排序——洛杉矶 p95 只有 39.6 ms，比东京的 123.5 ms 好得多，但它的最差 1% 会摸到 76.7 ms 并附带 2.5% 丢包。

第三，抖动（相邻两次 RTT 的差）和延迟不是一回事，而它更接近体感。新加坡相邻抖动均值 15.87 ms、p95 到 54.1 ms，是欧洲四地（4.06–4.74 ms）的 3.3 到 3.9 倍；东京抖动均值 8.62 ms，但 p95 冲到 65.0 ms，说明它是「平时很稳、偶尔一整段拥塞」的形态，而不是持续抖动。

第四，大多数「选地区」的结论错在采样量，而不是错在看平均值。同一批数据里，只用前 10 个包算 p95 时：多伦多得到 167.0 ms（真实 84.8，高估 97%）、东京得到 191.8 ms（真实 123.4，高估 55%）、洛杉矶只得到 12.2 ms（真实 39.6，低估 69%）。也就是说，用 10 个包既可能把好线路误判成差，也可能把脏线路误判成干净，方向随机。

二、测法说明：为什么是 120 个包、40 轮交错、三条路径

被测端点全部使用 Vultr 的公开测速主机（lax-ca-us-ping、il-us-ping、nj-us-ping、tor-ca-ping、hnd-jp-ping、sel-kor-ping、syd-au-ping、lon-gb-ping、fra-de-ping、ams-nl-ping、sgp-ping，全部已解析验证），因为它们是同一家、同一套命名、同一个「测速专用」定位，横向比较时端点侧的干扰最一致。

ICMP 部分：ping -n -c 120 -i 0.2 -W 2，即每 0.2 秒一个包、总时长约 24 秒、超时 2 秒。选 120 而不是 20，是因为 120 个样本能把 p95 落到「第 6 个最差值」上；而 p99 只有 1.2 个样本，这一点第六节单独讲。

TCP 部分：对 6 个 AWS 区域 S3 端点做 40 轮 TCP/443 握手，按轮交错（每一轮把所有 6 个目标各测一次，再进入下一轮），这样时间相关的外部干扰（同一时刻的拥塞）会均摊到所有地区，而不是让某个地区独占一个「坏时段」。这一点比总样本数更重要。

路径部分：traceroute -T -A -p 443 -q 1 -m 22，TCP SYN 探测加 AS 归属，避免 ICMP 被中间跳限速后一路显示 *。

三条必须写在前面的边界：

• 本文所有数字是「美西节点 → 各地区」的，不是中国大陆用户 → 各地区的延迟。大陆典型参考值是香港 28–45 ms、日本 35–60 ms、新加坡 40–70 ms、美西 140–180 ms，晚高峰上浮 10–20%。
• 分位数只在收到的包上计算，丢包单独统计。洛杉矶丢了 2.5%，它的 p99 是「没丢的那些包里最差的 1%」。
• 分位数对端点的 ICMP 实现敏感。若某台测速主机对 ICMP 做了限速或优先级降级，尾部会被「人为做脏」。本文用 TCP 互证（第十二节），但单点 ICMP 数据不能直接给一条线路定罪。

三、主表：11 个地区的七个口径

单位毫秒。「放大」= p99 ÷ p50；「抖动」= 相邻两个样本 RTT 差值的绝对值的均值（简化版 IPDV）；「尖刺」= 超过 2 倍 p50 的样本个数。

怎么读这张表：

• p50 看「平时快不快」。洛杉矶 11.7 ms、新加坡 176.5 ms，相差 15 倍，这部分是距离决定的，买不到。
• p95 看「一般差的时候有多差」。东京 p95 123.5 比 p50 高出 23.5 ms，新加坡高出 43.6 ms，多伦多高出 11.8 ms，新泽西只高出 11.1 ms。
• p99 看「最差的那 1% 有多糟」。11 个地区里有 6 个的 p99 超过 170 ms，其中 4 个是「绝对延迟本来就在 130 ms 以上」的欧洲和悉尼，另外 2 个是多伦多（130.3）和东京（188.3）。
• 放大倍数看「稳不稳」。北欧四地加首尔、悉尼都在 1.16–1.37，这是「同一路径、同一队列」的典型形态；超过 1.7 就要怀疑路径上有共享瓶颈或端点限速。
• 尖刺数量看「尾部是不是孤立事件」。洛杉矶 120 个包里有 10 个超过 23.4 ms（2 倍 p50），占 8.3%；芝加哥只有 2 个。孤立尖刺可以用重试掩盖，成片尖刺会变成用户可感知的卡顿。

四、发现一：离得最近的机房，尾部最脏

洛杉矶这一行值得单独拆开，因为它同时是「最快」和「最脏」。

中位数 11.7 ms，p90 19.3 ms，看起来完美。但第 91 到 95 百分位跳到 39.6 ms，第 96 到 100 百分位跳到 76.7 ms，最差一个包 154.0 ms——是 p50 的 13.2 倍。同一批 120 个包里还丢了 3 个（2.5%），其中最大连续丢包长度为 1，说明是零散丢包而不是断流。

这组数字有两种解释，必须分开说清：

第一种，端点侧 ICMP 限速。Vultr 的测速主机对 ICMP 通常只做「尽力而为」，控制平面繁忙时会把 echo 请求排队或丢弃。过去我们在欧洲节点上见过 70% 的 ICMP 丢包而 TCP 完好，所以 2.5% 丢包本身不能断定链路差。 第二种，真实队列在接入段。若真是限速，TCP 应该干净得多。但同一时段对 s3.us-west-2.amazonaws.com 做的 40 轮握手给出了 p50 39.2 ms、p90 52.3 ms、p95 56.4 ms、p99 69.4 ms、最大 72.5 ms——尾部同样抬起来了，只是幅度小一些（1.77 倍 vs 6.56 倍）。

两者合起来能得到的稳妥结论是：「最短路径」不等于「最稳路径」。洛杉矶到圣何塞只有 493 公里、理论往返 4.9 ms，但这条短路径上共享的接入设备和队列最多，一旦拥塞，放大的绝对量虽小、相对量却最大。反过来，跨洋长途的每一段都被运营商的流量工程「摊平」了，反而更像一条稳定的管道。

对选型的直接含义：如果你的业务对尾部敏感（实时对战、远程桌面、RTC），不要因为「同城」就默认它稳，同城机房一样要测 p99。 这一点与我们在同城机房之间测到的离散度是一致的：同一座城市里不同机房的差异，可以大于跨城差异。

五、发现二：欧洲「远但稳」，亚洲热门地区「近但抖」

把 11 个地区按「放大倍数」和「抖动」两个维度重排，会看到一条很清晰的地理分界。

三个值得注意的模式：

模式一：绝对延迟越小的地区，放大倍数反而越大。 洛杉矶 6.56、芝加哥 2.18、多伦多 1.78 都在「近距离」一侧；阿姆斯特丹 1.16、伦敦 1.28、法兰克福 1.26 都在「远距离」一侧。原因不神秘：放大倍数是一个相对量，分母（p50）小的时候，同样 30 ms 的排队延迟就能把比值拉到 3 倍以上。所以「放大倍数」不能跨距离直接比较，只能同档比较。

模式二：新加坡是唯一「中位数和抖动同时差」的地区。 176.5 ms 的 p50 已经比理论光速下限高 29%，抖动均值又是欧洲的 3.4 倍。这不是偶发——120 个样本里，相邻差超过 50 ms 的相邻对不止一处，p95 到 54.1 ms。

模式三：东京的抖动是「成段」的。 抖动均值只有 8.62 ms（低于洛杉矶的 8.85），但抖动 p95 高达 65.0 ms。翻译成体感：绝大多数时间它和 p50 一模一样（min 99.9、p50 100.0，说明一半的包就在 100 ms 上下），但每分钟会有几秒整段抬升到 160–220 ms。这种形态对「持续传输」影响小（TCP 会自己缓过来），对「实时交互」影响大（那几秒正好是团战）。

六、发现三：光速占比与「绕路」的真相

把每个地区的 p50 除以理论光速下限（大圆距离 ÷ 100 ms，这是光纤里 20 万公里/秒往返的简化换算），得到「光速占比」。100% 表示包沿直线跑，50% 表示多跑了一倍路程。

（洛杉矶的理论下限只有 4.9 ms，分母太小，光速占比在这个距离上不具可比性，列出仅供完整性。）

同样是 8000 多公里，东京跑到 83.4%，伦敦只有 63.7%。 东京 8337 km / 100.0 ms，伦敦 8632 km / 135.5 ms——距离只差 3.5%，延迟差 35.5 ms，也就是 35%。这 35 ms 不是「东京的机器更好」，而是「到东京的光纤更接近直线、经过的承运商更少」。

traceroute 提供了路径侧的旁证：

• 到东京：第 11 跳就是 tcore1.tv2-tokyo.as6453.net（209.58.61.40，AS6453）108.7 ms，第 18 跳落到 S3 端点 52.219.150.176 107.8 ms。越洋段只出现一家承运商（TATA/AS6453），落地即到，中间没有额外绕行。
• 到新加坡：第 6 跳 216.6.52.164（AS6453）2.1 ms，第 11 跳已经是东京的 tcore1.tv2-tokyo 114.6 ms，到新加坡 16.15.50.243 是 167.9 ms。也就是「圣何塞 → 东京 → 新加坡」两段长途串联。
• 到法兰克福：第 11 跳是伦敦的 tcore2.ldn-london（195.219.16.129）135.1 ms，落地 3.5.139.36 149.4 ms，同样是两段串联。

这里要纠正一个很常见的错觉：「经东京到新加坡」不等于绕路。 圣何塞到新加坡的大圆距离 13647 公里，而「圣何塞→东京 8337 + 东京→新加坡 5320 = 13657 公里」，两者只差 10 公里——这条走廊本来就从日本附近过去。同理，「经伦敦到法兰克福」的 8632 + 640 公里也基本等于 9153 公里的直线。真正吃掉光速占比的不是「绕远」，而是光纤不走直线、每段落地都要过一次交换和排队。

这也解释了为什么新加坡的抖动最大：两段长途串联，任何一段的队列变化都会叠加到最终 RTT 上，而单段路径（东京）只有一次机会变脏。

七、样本量陷阱：10 个包算出来的 p95，误差能到 100%

这是本文最实用的一节，因为它不需要你换机房，只需要你改命令。

同一批数据，我们分别只用前 10、前 20、前 50 个包算 p95，再和全部样本对比：

同一个地区的 p95，用 10 个包和用 120 个包可以差出 97%（多伦多）或 69%（洛杉矶），而且方向不一致：多伦多是被高估（10 个包里恰好有 2 个尖刺），洛杉矶是被低估（前 10 个包恰好都很干净）。

相比之下 p50 稳得多：洛杉矶 10 包 10.3 / 全部 11.7（−12%）、多伦多 74.5 / 73.1（+2%）、新加坡 179.5 / 176.5（+1.7%）、东京 100.0 / 100.0（0%）。这就是「平均值看起来很可靠」的错觉来源——p50 用 10 个包就能估准，p95 用 10 个包等于掷硬币。

实操规则：

• 估 p50：10 个包够（误差 ±10% 量级）。
• 估 p95：至少 60–100 个包。少于 60 个时，你算出来的 p95 实际上是「样本里的第 2 或第 3 大值」，本质是 max 的别名。
• 估 p99：至少 600–1000 个包。120 个包算出的 p99 只能算「观测到的最差值附近的一个点」。

八、p99 的置信度：120 个样本里只有 1.2 个「超过 p99」的点

p99 的定义是「99% 的样本不超过它」。要让这个定义在统计上站得住，样本里得有若干个点真的超过它。用二项分布算一下就明白：

120 个包时，「至少有一个样本超过真实 p99」的概率是 1 − 0.99^120 = 70.1%——也就是说有 30% 的概率，你的 120 包数据里一个超过 p99 的点都没有，这时候算出来的「p99」必然等于最大值，而最大值本身也可能是端点限速造的假象。

所以本文的 p99 列要这样理解：它是「120 个样本的经验最差值」，是一个有用的排名信号，但不是可复现的统计量。 两次跑同样的 120 包，p99 差 30 ms 都属于正常波动；而 p50 两次差 2 ms 就值得查原因了。

这也是为什么我们不建议用「p99 小于多少」写进 SLA 判据——除非你有 1000 个以上样本，并且用同一端点、同一时段、同一包长复现三次。

九、抖动：15.9 ms 的相邻抖动，为什么比 176 ms 的中位数更致命

延迟决定「你等多快」，抖动决定「你要预留多少余量」。业界的通用估算方法（RFC 3550 的 interarrival jitter）是逐包累计相邻到达间隔的偏差；本文用的简化版是「相邻两个 RTT 差值的绝对值的均值」，量级与 RFC 口径接近，但不含时间戳归一化，适合做横向比较。

换算成业务参数：

换句话说，新加坡那条线路的抖动，会通过「抖动缓冲」把 176.5 ms 的中位数实际推到 230–250 ms 的体感延迟——而这个代价在任何「平均延迟对比表」里都看不到。反过来，欧洲四地的 p50 虽然高达 135–146 ms，但它们的抖动小，缓冲只需 20–40 ms，最终体感和 160 ms 左右的抖动型线路接近。

再补一个容易被忽略的点：抖动 p95 比抖动均值更能预测卡顿。东京抖动均值 8.62 ms 看着比洛杉矶（8.85）还好一点，但东京抖动 p95 是 65.0 ms、洛杉矶是 39.9 ms。前者意味着「每分钟有几秒整段抬升」，后者意味着「零散尖刺」。

十、丢包的真实代价：1% 丢包 = 单流 1.4 Mbps

分位数测的是「排队的代价」，丢包测的是「重传的代价」，后者对吞吐的破坏是乘法级的。用 Mathis 公式（BW ≈ 1.22 × MSS ÷ (RTT × √p)，MSS 取 1460 字节）算单流 TCP 的吞吐上限：

读法：

• 固定 100 ms RTT，丢包从 0.01% 涨到 1%，单流吞吐上限从 14.3 Mbps 掉到 1.4 Mbps，差 10 倍。而 RTT 从 100 ms 翻倍到 200 ms，同样条件只掉 2 倍。
• 所以「1% 丢包不算什么」是错的：它比「延迟翻倍」更贵。
• 商家宣传的「100 Mbps 端口」在 150 ms RTT + 1% 丢包下，单流只能跑 0.95 Mbps。端口数字和你能跑到的速率之间，隔着丢包率。
• 洛杉矶那条 2.5% 丢包的线路，按公式在 11.7 ms 下算是 7.7 Mbps 单流上限——绝对值仍不低（因为 RTT 短），但对实时业务是硬伤：丢一个包就是一帧画面或一次输入丢失。

这也是为什么我们在第八节强调「丢包要单独列，不能折进分位数」——分位数只描述收到的包有多慢，丢掉的包是「无限慢」。

十一、尾延迟放大：60 个资源，45% 的页面会踩到慢请求

单机 p95 是 5%，但一次页面加载不是一次请求。若一个页面要串行/并行请求 n 个资源，每个资源有 p 概率落在尾部，那么「至少有一个资源踩到尾部」的概率是 1 − (1 − p)^n：

这就是 Google SRE 里讲的尾延迟放大（tail latency amplification）：1% 的尾部，在 100 个后端调用的扇出下，会变成 63% 的用户请求变慢。 一个典型中文站点首屏 60–80 个请求（HTML、CSS、JS、字体、图片、接口），按 1% 尾部算就是 45–55% 的加载会踩到至少一个慢请求。

对选地区的含义：

• 静态资源多的站点，尾部被 CDN 摊平，看首字节和 p50 就够。
• 接口串行调用的后端（一个请求要等 5 个下游），必须把每个下游的 p95 都压下来，否则一个 2% 尾部的下游就能让整条链路 10% 的请求变慢。
• 单机部署 + 无重试的场景，p99 直接等于用户感知的最差体验，没有缓冲。

十二、TCP 握手分位数：ICMP 不通时怎么测（含香港）

香港的机房普遍屏蔽 ICMP，这件事在过往文章里已经写过；但「ICMP 不通」不等于「不能测」。用 TCP/443 握手计时可以绕开这个限制，代价是数字里包含了一次握手（+1 RTT 量级）和云厂商边缘节点的接入延迟。

三个可直接用的结论：

• 香港比新加坡快 16.1 ms（164.7 vs 180.8），这个差值在 ICMP 表里是看不到的（香港没有 ICMP 数据）。对华南用户，香港的优势通常更大。
• TCP 的 p50 比 ICMP 的 p50 系统性偏高 15–20 ms（东京 116.6 vs 100.0、法兰克福 161.2 vs 146.0）。这不是线路差异，而是口径差异：TCP 握手多一次内核处理与 SYN 队列，且 S3 端点前面有边缘层。两套数字不能混着比。
• n=40 的 p99 没有意义（40 个样本里 p99 只有 0.4 个点），所以这张表只报 p50/p90/p95/max。上一节讲的采样量规则，对 TCP 同样适用。

十三、把分位数翻译成业务阈值

注意这张表是「美西节点视角」，对大陆用户要换成参考值再套阈值（香港 28–45 ms、日本 35–60 ms、新加坡 40–70 ms、美西 140–180 ms）。阈值不变，数字换掉，结论可能整体平移。 比如美西视角下「东京 p95 123.5 对 FPS 超标」，换成华南用户视角的 35–60 ms，东京就会变成达标项。

十四、自测四步：30 分钟拿到你自己线路的 p95 与 p99

第一步，选端点。优先用同一家、同一命名规则的公开测速主机；跨厂商比较时端点侧差异会污染结论。

第二步，跑 120 个包并把时间戳落盘：

for h in hnd-jp-ping.vultr.com sgp-ping.vultr.com lon-gb-ping.vultr.com; do
  ping -n -c 120 -i 0.2 -W 2 "$h" > "/tmp/ping-$h.txt"
done

第三步，算分位数（Python 3 自带 statistics，无需装包）：

python3 -c "
import re,statistics,sys
txt=open(sys.argv[1]).read()
v=[float(x) for x in re.findall(r'time=([0-9.]+) ms',txt)]
v.sort(); n=len(v)
q=lambda p: v[min(n-1,int(round((n-1)*p)))]
print('n=%d min=%.1f p50=%.1f p90=%.1f p95=%.1f p99=%.1f max=%.1f'%(n,v[0],q(.5),q(.9),q(.95),q(.99),v[-1]))
j=[abs(v[i]-v[i-1]) for i in range(1,n)]
print('jitter_mean=%.2f jitter_p95=%.2f'%(statistics.mean(j),sorted(j)[int(.95*len(j))]))
" /tmp/ping-hnd-jp-ping.vultr.com.txt

第四步，做判定：p95 是否落在业务阈值内、p99/p50 是否超过 1.8、有没有丢包、抖动均值是否超过 10 ms。四项里有两项不合格，就换地区或换线路，不要试图用调优掩盖。

补充：如果你的机器上 ping 的包间隔被限制（部分容器只允许 -i 0.2 以上），把 -c 加到 200 补偿；如果端点屏蔽 ICMP，就用 curl -w '%{time_connect}\n' 连打 40 次替代，口径改成 TCP 握手。

十五、价格与尾延迟：为「稳」多付多少

价格表本身说明不了一件更重要的事：同一价位段内的尾部分布可以差 5 倍。 洛杉矶和芝加哥同属美国，价格区间完全重叠（$3–6 / $10–20），但一个 p99/p50 放大 6.56 倍并丢 2.5% 的包，另一个是 2.18 倍、零丢包。也就是说，你付的钱买的是「地区 + 商家」，不是「尾部质量」；尾部质量只能靠测，不能靠价格推断。

如果一定要给「为稳付费」定个锚：欧洲四地的 p50 比东京高 35–46 ms，但放大倍数只有东京的 2/3、抖动只有 1/2。对 RTC 类业务，多花 35 ms 换掉一半的抖动，通常是划算的；对 API 类业务，35 ms 的绝对值增加反而更贵。「稳」在不同业务里价格不同，没有通用答案。

十六、八个避坑

1. 只看平均延迟。11 个地区的 mean/p50 全部在 1.01–1.35 之间，平均延迟对尾部毫无区分度。
2. 只 ping 10 个包就下结论。本文实测误差可达 97%（多伦多）、69%（洛杉矶），且方向随机。
3. 跨距离比较放大倍数。洛杉矶 6.56 倍听着比东京 1.88 倍差，但它的 p95 绝对值 39.6 ms 只有东京的 1/3。
4. 把 ICMP 分位数当线路质量。测速主机的 ICMP 队列优先级低，2.5% 丢包可能就是限速。用 TCP 握手互证。
5. 混用 ICMP 和 TCP 的数字。TCP 系统性偏高 15–20 ms，混着比会得出「某地区更慢」的假结论。
6. 忽略丢包，只看延迟。1% 丢包在 150 ms RTT 下把单流压到 0.95 Mbps，比延迟翻倍严重得多。
7. 以为「同城」就稳。洛杉矶到圣何塞 493 公里，p99/p50 是全场最高。
8. 把 p99 写进 SLA。120 个包的 p99 有 30% 概率一个样本都没超过，不可复现。

十七、地区推荐：按「尾部敏感度」分三档

一句话总结这一档表的用法：先用「敏感度」筛掉不适合的地区，再用「p95 + 抖动 + 丢包」三个指标在同档内排序，最后才看价格。 反过来做（先看价格再测）是最常见的踩坑顺序。

总结

这一轮测出来的核心事实只有一个：延迟是一个分布，而不是一个数字。 11 个地区的 p50 从 11.7 ms 到 176.5 ms，看起来只是「远近不同」；但把同一个分布切开看尾部，结论就变成了「近距离的机房尾部更脏、远距离的长途反而更稳、热门亚洲节点的抖动最大」。

具体到可执行的判断，四条规则足够用：

1. 用 p50 判断「平时快不快」，用 p95 判断「一般差的时候多差」，用 p99/p50 判断「稳不稳」——三个指标不能互相替代。
2. 采样量决定结论的方向：p50 十个包够，p95 要六十个以上，p99 要六百个以上。少于这个量，你测的是运气。
3. 丢包单独算，它比延迟贵：1% 丢包在 150 ms 下把单流压到 0.95 Mbps，比 RTT 翻倍更致命。
4. 价格买不到尾部质量：同价位段内放大倍数可以差 5 倍，只能靠测。

把这四条套到自己的业务上，选地区这件事就从「看谁的平均延迟低」变成「看谁的 p95 落在我的阈值内、抖动够不够小、丢包是不是零」——后者才和用户真正感受到的卡顿对应。

相关阅读

• 海外服务器延迟基线漂移与复测可复现性：同一批端点，21 天后差了多少
• 海外服务器同城机房延迟离散度实测：一座城市里的 10 个机房能差多少
• 海外服务器城市对延迟矩阵：15 个城市两两之间的真实 RTT
• 海外服务器 AS 路径与承运商归属：同一条线路到底走了谁的网络
• 海外服务器带宽延迟积与单流多流实测：为什么 100 Mbps 只能跑 10 Mbps
• 香港 vs 新加坡 vs 日本 vs 美国服务器延迟测速对比：按应用体验阈值选地区

本文测试数据采集于 2026 年 10 月 29 日 06:02–06:08 UTC（测试节点：美国西海岸圣何塞 38.55.134.58，AS402169 Uscloud），具体延迟可能因网络环境、测试时间和运营商不同而有所差异，建议购买前进行 48 小时免费测试。

本文由 6.chengzicloud.cloud 提供，点击访问首页了解更多