同一个城市，机房延迟能差 49ms：海外服务器「同城机房离散度」8 城双轮实测

Meta Description: 2026 年海外服务器同城机房延迟实测：东京 AWS 102ms、Vultr 108ms、Sakura 151ms，同城极差 49ms；8 城市双轮 TCP+ICMP 对比，附识别「2ms 假香港节点」的 anycast 方法与五步选址法。

关键词：海外服务器、同城机房延迟差异、机房选址、东京机房延迟、香港机房延迟、新加坡机房延迟、海外服务器测速方法、光速占比

一、你选的不是「城市」，是城市里的某一台机器

如果你搜过「香港服务器延迟多少」，看到的几乎都是一张城市级表格：香港 30–50 ms、东京 40–60 ms、新加坡 50–80 ms。这类表格有用，但它回答的是「城市之间的平均差距」，而你在下单时真正要做的决定是：在日本这个国家里，我买哪一家的哪一台机器。

这两个问题完全不是一回事。本文用 2026 年 10 月 22 日在一个美国西海岸节点上跑的三轮实测（ICMP 10 包 + TCP 握手 2 次 + tracepath）给出一个反直觉的答案：

• 同一个城市里，两家云厂商可以差 1–15 ms（伦敦 2.3 ms、新加坡 14.7 ms、纽约 8.8 ms）；
• 把本地运营商算进来，东京同一城市内的差距能到 49.3 ms——AWS 东京 102.0 ms，Vultr 东京 107.9 ms，而日本本土老牌 IDC 樱野（Sakura）的官网 151.3 ms；
• 这个「49 ms 的同城差」比「东京 vs 香港」的城市差还大（我们从美西测，香港 151.2 ms、东京 102.0 ms，差 49.2 ms）。换句话说：选错同城的机房，等于把服务器放到了另一个国家。

还有一个更实用的结论：大多数城市之间的真实差距（伦敦 vs 法兰克福 12 ms、东京 vs 首尔 28 ms），和你单次单协议测量的噪声（本次实测 ICMP 与 TCP 的差值在 −9.7 ~ +10.3 ms 之间）是同一量级。 所以「我在服务器上 ping 了一下，A 比 B 快 8 ms，所以选 A」这个推理，在统计上根本不成立。下面把数据、路径证据和一套可复用的自测方法全部摊开。

二、测试环境与口径：怎么保证测的不是噪声

先把「可证伪」的部分说清楚，否则后面的数字没有意义。

2.1 测点与时间

• 测点：38.55.134.58，美国加利福尼亚州圣何塞（San Jose），AS402169 Uscloud Inc，与本站此前多篇实测使用同一台机器，便于横向对照；
• 时间：2026 年 10 月 22 日，三轮测量在两小时内完成，同一台机器、同一出口、无并发任务；
• 口径：每个目标先做 ICMP ping -c 10 -i 0.2，再做 TCP SYN 到 443 端口（连两次取最小值），两轮各重复一次；tracepath 用于取上游路径。

2.2 目标怎么选：三个硬规则

选错目标，后面全白测。本次执行了三条规则：

1. 用机房的官方端点，不用内容站。云厂商的 s3.<region>.amazonaws.com、ec2.<region>.amazonaws.com、Vultr 的 <city>-ping.vultr.com 是机房自己维护的测速主机，落在机房网段内；内容站（门户、电商）大概率挂在 CDN 后面，测到的是边缘节点。
2. 用 IP 和 ASN 核验归属，不信域名里的地名。域名写着 hk 不代表机器在香港——本文第五节会给出两个「域名带 hk、实测 2 ms」的反例。
3. 每个城市至少两家不同 ASN。同一家云的 S3 和 EC2 属于同一个 AS，互证只能证明「这一家没测错」，不能代表「这个城市」。

2.3 两个指标：同城极差与光速占比

• 同城极差 = 同一城市内可测目标的最大值 − 最小值（绝对值 ms 与相对百分比都给）；
• 光速占比（SOL） = 理论下限 ÷ 实测值。理论下限按光纤中光速约 20 万 km/s 折算，近似为「两地大圆距离 ÷ 100 毫秒」。SOL 越低，说明这条路径绕得越远，跟机房本身快不快无关。

2.4 本次测量的局限（必须说明）

• 只有一个测点。本文所有结论都是「从美西看」的结论，不能直接外推到中国大陆用户（第十节专门讲这个陷阱）；
• 香港只有一个 ASN 可测（AWS ap-east-1）。香港多数机房的 IP 同时封 ICMP 和 80/443 探测，本次尝试的 3 个香港 IP 全部无响应，所以香港的「同城离散度」是数据缺口，不是零；
• Linode 的 8 个官方测速点全部不可达（ICMP 与时 TCP 80/443 均超时）。这本身是一个结论：如果你的测速脚本把测速地址写死，三年后它会静默返回空值，而你的表格里只会多出一行空白。

2.5 测量目标清单

表里有两个细节值得先看一眼：「网段注册地」和「机器所在地」是两件事。AWS 把 3.5.x 段注册在美国（ARIN），但这些地址公告在亚太；Vultr 首尔那台的段注册地是日本（APNIC），机器却在首尔。所以 GeoIP 库给出来的「国家」只能当参考——这一点在 海外服务器 IP 的地区到底谁说了算 里用 9 家 GeoIP 厂商交叉验证过。

三、八城同城离散度总表：云厂商之间很整齐，本地运营商很惊喜

先把总表放上来。同一格里的两个数字是「两轮测量」，括号里是 ICMP。

把这张表按「同城极差」重排，结论就很清楚了：

读表要点：第 3、4 名的「极差」在两轮之间从 8.8 ms 掉到 1.1 ms、从 10.2 ms 掉到 1.0 ms。这不是我测错了，而是同城离散度这个概念本身有「时刻依赖」——第七节用 IP 轮换解释它，这是全文最值得记住的一节。

四、东京：同城 49 ms，三条完全不同的国际出口

东京是本次最值得看的城市，因为它是唯一一个「同城差 > 跨城差」的样本。

差距 49.3 ms，相对差 48.3%。这不是「Sakura 的机器慢」——ICMP 155.9 ms 与 TCP 151.3 ms 高度一致，说明瓶颈在网络层，不是服务器的 TCP 栈或负载。同一台机器如果 CPU 满载，你只会看到 TCP 握手变慢而 ICMP 正常；反过来 ICMP 也慢，就是路径问题。

光速占比把原因量化了：从圣何塞到东京的大圆距离 8337 km，理论下限 83.4 ms。AWS 做到了 81.7%，Vultr 77.3%，Sakura 只有 55.3%。同样的物理距离，Sakura 走了一条多绕 26 个百分点的路——大概率是它的国际 transit 与本地的 peer 关系决定的（日本本土 IDC 的传统强项是国内互联，不是跨太平洋直连）。

这件事对选型的意义取决于你的用户在哪：

所以「日本机房延迟低」这句话，只有在你补上「对谁的延迟」和「哪一家」之后才成立。

五、香港：只有一家能测，以及那两个「2 ms 的香港节点」

香港这次是数据缺口，但缺口本身暴露了一个更常见的错误。

我尝试了 5 个「香港」目标，结果分成三类：

那两个 2 ms 是怎么来的？这两个域名返回的是「离你最近的接入点」：hk.tencentcloudapi.com 的解析结果落在腾讯云的全球调度网关上，www.alibabacloud.com 更是直接给了一个注册在美国的地址。它们代表的是「你到这家厂商边缘节点的距离」，而不是「你到香港机房的距离」。

如果你用一个「ping 一下厂商官网」的脚本去比城市，就会得到「香港 2 ms，东京 102 ms」这种荒谬结论，然后兴冲冲买了香港机器，上线发现大陆用户 40 ms、美西用户 150 ms。识别方法很简单：先查 ASN 的网段注册地，再看 PTR，最后才看延迟。 如果延迟低到不符合物理（大圆距离 ÷ 100 都做不到的 1/40），那它一定不是你以为的那台机器。

至于香港真实的同城离散度，本次没有测出来——AWS ap-east-1 的 S3 与 EC2 两台互证在 151.2 / 151.5 ms，非常一致，但只有一家 ASN。要补这个缺口，可行的做法是：申请两台不同商家的 48 小时试用机（阿里云香港、腾讯云香港、本地 IDC 各一台），从你自己的办公网或大陆节点同时 ping，而不是从美西机房。

六、新加坡与首尔：5–9 ms 的「温和离散」

新加坡是本次唯一一个「离散度随轮次变大」的城市：

同城极差从 8.3 ms 扩大到 14.7 ms，全部由 Vultr 那台自己在漂。这类漂移在新加坡很典型：它是东南亚的转口枢纽，跨境流量占比高，同一台机器在不同时段可能被调度到不同的上游（tracepath 显示它经过 141.136.110.158（238 ms 的非对称跳）→ 208.81.84.159（175 ms）→ 45.32.98.222 落地，路径中间存在明显的不对称转发）。

首尔则是本次最整齐的城市：AWS 129.9 / 128.8 ms，Vultr 133.1 / 133.2 ms，两轮极差 3.2–4.4 ms，相对差 2.5–3.4%。这是「同城不同商家，差异可以忽略」的正面样本——如果你的用户主要在韩国，两家随便选，价格和带宽才是决定因素。

把这两座城市放在一起看，得到一个可操作的判断标准：

• 同城极差 < 5 ms：差异小于测量噪声，按价格和带宽选；
• 同城极差 5–15 ms：需要两轮以上重复，确认不是抖动后再决定；
• 同城极差 > 15 ms：说明路径本质不同，必须按「你的用户在哪」来选，不能按城市选。

七、悉尼与纽约：两轮测量为什么会反转

这一节是全文最反常识的部分，也是我建议你在写任何选型报告前先读的一段。

如果我只跑了一轮，就会写出「悉尼选 Vultr 快 7%」「纽约选 AWS 快 13%」这样的结论。两轮跑完，这两句话都不成立。

原因有两个，都跟「你测的到底是哪台机器」有关：

1. AWS 的 S3 端点每次解析到不同 IP。三轮里 s3.ap-southeast-2.amazonaws.com 先后给出 3.5.164.105、3.5.165.165、3.5.164.212，s3.ap-northeast-1 给出 16.15.58.196、16.15.57.193、16.15.56.79。这些 IP 属于不同可用区、不同机柜、不同出口路由器——你测的不是「AWS 悉尼」，而是「AWS 悉尼里恰好被 DNS 分给你的那一台」。同一家厂商内部不同 AZ 相差 1–10 ms 完全正常。
2. 单次 TCP 握手容易撞上瞬时拥塞。纽约 Vultr 第 1 轮 74.1 ms、第 2 轮 63.9 ms，差 10.2 ms；它的 ICMP 均值是 64.4 ms，与第 2 轮吻合，说明第 1 轮那个 74.1 ms 是离群值，不是「Vultr 变快了」。

对应的操作规则很硬：任何小于 10 ms 的同城优劣结论，至少要有 3 轮、跨 1 小时以上的重复测量，并且固定目标 IP 而不是域名。 如果你要固定目标，做法是先把域名解析出的 IP 记下来，后续直接 ping IP；这样你测的才是「同一台机器随时间的变化」，而不是「不同机器之间的差异」。

八、欧洲：伦敦 2 ms、法兰克福 5 ms，同城反而最「整齐」

欧洲的两个城市给出了和亚太相反的答案——同城两家云厂商几乎无差别：

伦敦的极差 2.3–3.6 ms，已经低于本文测得的协议噪声（下一节），可以认为「无差别」。法兰克福的 TCP 极差 4.5 ms 也很小，但它的 ICMP 是 162.4 ms——比自己的 TCP 慢 10.3 ms，是全部样本里协议差最大的一例。

更值得注意的是光速占比：欧洲两城都只有 60–65%，明显低于东京（81.7%）、新加坡（81.6%）、悉尼（81.3%）。从美西到欧洲的大圆距离 8632–9153 km，理论下限 86–92 ms，实测却要 133–148 ms。跨大西洋这一段，从美西出发是「绕」，不是「直」——这也解释了为什么很多做欧洲业务的团队发现「从美西迁到美东，欧洲用户反而变快了」：不是欧洲变近了，是出口换成了走北大西洋的直连。

九、ICMP 与 TCP 测的不是同一件事

把所有节点的 ICMP 均值与同轮 TCP 握手并列，差值分布如下：

结论有三条：

1. 差值在 −9.7 ~ +10.3 ms 之间，平均绝对值约 2.8 ms，方向不一致。这意味着 ICMP 既不系统性偏快也不系统性偏慢，你无法用一个固定偏移去「校正」它。
2. 原因是两种包在设备上的处理优先级不同。ICMP 由路由器控制面响应，很多机房对 ICMP 限速（常见 1 pps 或 10 pps）；TCP SYN 由内核协议栈处理，通常不降级。所以 ICMP 偏慢是常态，但偏快也会发生（纽约 Vultr：ICMP 64.4 < TCP 74.1），此时更可能是 TCP 侧瞬时拥塞。
3. 只用 ping 会漏掉一半机房。本次 8 个 Linode 官方测速点（东京、新加坡、悉尼、弗里蒙特、法兰克福、伦敦、纽瓦克、孟买）在 ICMP 和 TCP 80/443 上全部超时——它们的测速服务已经下线或改了域名。一个写死域名的脚本，会在表格里静默留空，而你不会发现。

所以正确的口径是：ICMP 看趋势，TCP 看真实建连，两个都跑，跑两轮。

十、测点位置决定排名：从美西看，香港比东京慢 49 ms

这是最容易踩、后果最贵的坑。

在美西视角下，香港（151.2 ms）比东京（102.0 ms）慢 49.2 ms；在中国大陆视角下，香港比东京快 5–15 ms。同一个「香港 vs 东京」的问题，因为测点不同，答案的符号都变了。

为什么？因为从美西到亚太的流量大多走跨太平洋主干，香港和东京在主干上的「落点」顺序不同——本文第十一节的 tracepath 会显示，从圣何塞去香港 AWS 和去东京 AWS，走的是同一串上游（64.86.26.36 → 180.87.151.29 → 209.58.61.x），香港只是多一跳。而从中国大陆出发，香港是陆路/短海缆直达，东京要过东海。

这条对选型的直接含义：任何「机房所在地测出来的延迟」都不能用来判断用户体验。 你要么在自己的用户所在地布探针（一台 5 美元的 VPS 就够），要么用第三方 looking glass（各家的公开节点），要么老老实实做 48 小时真实用户 RUM 采样。本站此前那篇 城市对延迟矩阵 用的是公开矩阵的 342 个城市对，本质上也是在解决「你不可能在所有城市布探针」这个问题。

十一、tracepath 实证：同城两家的上游 transit 不一样

延迟差 49 ms，路径上到底差在哪？把三条 tracepath 摊开看（只保留有响应的跳）：

三件事看得很清楚：

1. 东京 AWS 和香港 AWS 共用同一串上游（64.86 → 180.87 → 209.58），香港只是多了 64.86.26.39 和 180.87.180.2 两跳。所以「香港比东京慢 49 ms」不是香港的机房差，而是这段共同主干到了 180.87.x 之后还要再往南拐一次。
2. 东京 Vultr 走的是 NTT 的 129.250.x 网段，与 AWS 的 64.86/180.87/209.58 完全不同的运营商。两家在同一个城市、同一个 RTT 量级，但换一家就是换一条国际出口——这就是同城离散度的物理来源。
3. 新加坡 Vultr 出现了 238.8 ms 的非对称跳（141.136.110.158，asymm 16），下一跳却回落到 175 ms。这种「中间跳比终点还慢」是非对称路由 + ICMP 限速的典型症状，说明这条路径的回程和去程不是同一条，测出来的 RTT 只是一个平均值，不代表任何单向时延。

选机房 = 选上游 transit。 这句话在单城多商家的场景下比任何「城市排行榜」都有用：你在东京换一家供应商，换掉的不是机房地板，而是它接入的那条海缆和它买的那家 transit。

十二、价格与带宽：同城价差 2–3 倍，带宽价差 10 倍

同城离散度不只在延迟上，钱上也一样。下面是 2 核 4 GB 档位的月价区间（按各家官网公开标价、730 小时/月折算，不含税，2026 年 10 月截面）：

注意，这个 2–3 倍是按量价。头部云厂商的 1 年/3 年预留或节省计划能把按量价压到 40–70%，届时价差会收窄到 1.2–1.8 倍——所以「同城换便宜商家」这个动作的收益，取决于你打算用多久，而不是取决于城市。

带宽才是真正的分水岭。把「每 Mbps 国际带宽月成本」换算成每 TB 流量成本（1 Mbps 跑满一个月 = 324 GB）：

这张表解释了为什么「香港机房同城差 5 ms」这件事经常不重要：如果你的业务是视频、下载、备份这类流量敏感型，香港的带宽单价会让你的月账单比延迟优势贵出一个数量级。同城选机房时，先把「每 TB 成本」算出来，再谈那 5 ms。

十三、五步选址法：给一个新城市做机房筛选

把上面的经验固化成流程，任何新城市都能套用：

1. 确定测点，不是机房所在地。测点必须在你用户那一侧（大陆节点、目标市场的 VPS、或第三方 looking glass）。用机房所在地的机器测，得到的排名符号可能是反的（第十节）。
2. 每家选 2 个目标，用 IP 不用域名。先 getent hosts 解析、用 RDAP 查 org 确认归属，然后固定 IP 反复测。域名每次解析到不同 AZ，是第七节那两次反转的根因。
3. 双协议 + 至少两轮，间隔 30 分钟以上。ICMP 看趋势、TCP 建连看真实体验，两者差值可达 ±10 ms，单协议单轮不足以判断 10 ms 级的优劣。
4. 算两个数：同城极差与光速占比。极差 < 5 ms 视为无差别；SOL 低于 70% 说明这条路绕行严重，值得换一家试。
5. 48 小时试用跑真实业务。延迟只是第一层，TLS 握手、首字节、并发连接、丢包重传都要在自己业务形态下验证——这一步能挡掉大部分「测速很好、上线很慢」的坑。

一段可直接改用的探测脚本（在测点机器上跑；把 TARGETS 换成你自己的候选 IP）：

TARGETS="3.5.214.150 43.198.168.124 16.15.58.196 108.61.201.151 163.43.179.80"
for ip in $TARGETS; do
  icmp=$(ping -c 10 -i 0.2 -W 2 -n "$ip" | tail -2 | head -1)
  tcp=$(python3 -c "import socket,time;s=socket.socket();s.settimeout(3);t=time.time();s.connect(('$ip',443));print(round((time.time()-t)*1000,1));s.close()" 2>/dev/null)
  ptr=$(python3 -c "import socket;print(socket.gethostbyaddr('$ip')[0])" 2>/dev/null)
  echo "$ip | $icmp | tcp=${tcp}ms | $ptr"
done

脚本输出的三列正好对应本文的三个判据：ICMP 均值、TCP 建连、PTR 归属。如果 PTR 是 CDN 或云厂商的边缘域名，这一行直接作废——那台机器不在你以为的城市。

十四、场景推荐矩阵

矩阵里最常被忽略的是第六行：同城离散度不只是选型障碍，它同时是容灾资源。同城两家差 5–15 ms，这个量级做 AZ 级主备完全够用，切换时用户几乎无感——比跨城市容灾便宜得多，也比单机房安全得多。

总结与推荐

这篇实测想推翻的是「城市级延迟表就够用」这个假设，具体给了四个可验证的结论：

1. 同城云厂商之间差 1–15 ms，加上本地运营商能到 49 ms（东京）。这个差距已经大于部分跨城市差距，「选城市」之后必须再选一次「选哪家」。
2. 同城离散度的物理来源是上游 transit。tracepath 显示东京 AWS 与东京 Vultr 走的是完全不同的运营商（64.86/180.87/209.58 vs 129.250.x），换一家就是换一条国际出口。
3. 测点位置会翻转排名。香港在美西视角是 151.2 ms（比东京慢 49 ms），在大陆视角是 28–45 ms（比东京快）。用机房所在地的机器测用户体验，是方法论错误。
4. 单次单协议测量的噪声（±10 ms）与多数城市间的真实差距同量级。两轮 + 双协议 + 固定 IP 是下限，不是讲究。

落到行动上：先用第十节的对照表确认你的用户视角，再用第十三节的五步法在候选城市里筛出 2–3 家，最后用 48 小时试用机跑真实业务。 延迟表只能帮你排除明显不合适的城市，同城选哪家这件事，必须自己测。

本文测试数据采集于 2026 年 10 月 22 日（测点：美国西海岸圣何塞 / AS402169 Uscloud（38.55.134.58）；ICMP 为 ping -c 10 -i 0.2，TCP 为到 443 端口连两次取最小值，两轮测量间隔约 40 分钟，另有一轮重复用于校验；ASN 与网段注册地来自 Cloudflare DoH 的 Team Cymru origin.asn.cymru.com 查询，PTR 为反向解析结果；大圆距离按两城市经纬度计算，理论下限按光纤中光速约 20 万 km/s 折算为「距离 ÷ 100」毫秒，短距离下该近似会失真——洛杉矶 493 km 的 50.3% 即为此例；价格与带宽为各家官网公开标价的档位区间，非本文实测，含税前、按 730 小时/月折算。延迟可能因网络环境、测试时间与运营商不同而有所差异，建议购买前用你自己的业务形态进行 48 小时免费测试。

🚀 需要海外服务器？ 通过 6.chengzicloud.cloud 购买，覆盖香港/新加坡/日本/美国等全球区域，测试后满意再付款，30 天无理由退款保障。

相关阅读

• 海外服务器地区选择：全球城市对延迟矩阵实测
• 海外服务器建连往返预算：一次请求要花几个 RTT
• 海外服务器 IP 的「地区」到底谁说了算：GeoIP 数据库分歧实测
• 海外服务器 IP 交叉核验：RDAP、ASN 与 PTR 的反相关现象
• 海外服务器免费套餐与试用额度：地区锁定与配额陷阱

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