起因
我手上五台机器散在两个大陆：一台在加州的云上，四台在上海。平时它们只是安静地跑着，直到我想起一个无聊的问题——
它们彼此之间，到底有多远？
“距离”这件事在网络上其实有两个答案：物理上的大圆距离，和光速允许的下限。我决定两个都量一遍，再对比一下。
参战名单
| 机器 | 位置 | 角色 |
|---|---|---|
| 云节点 A | 加州圣克拉拉 | WireGuard 枢纽 |
| 云节点 B | 上海 | 阿里云主机 |
| 云节点 C | 上海 | 腾讯云主机（本文的实验平台） |
| 家里的 Mac | 上海 | 日常用 |
| 家里的软路由 | 上海 | 同一间屋，同一个 /24 网段 |
有个细节值得一提：四台“上海”机器，IP 地理库给出的坐标完全相同——都是 31.2222, 121.4581。整个城市被压成了一个点。
实测往返延迟
ICMP，多次取样取平均，单位毫秒：
| | 加州 | 阿里云 | Mac | 软路由 | 腾讯云 |
|---|---|---|---|---|---|
| 加州 | — | 149.9 | 166.4 | 163.3 | 261.7 |
| 阿里云 | 149.9 | — | 13.0 | 11.1 | 6.0 |
| Mac | 166.4 | 13.0 | — | 5.5 | 21.9 |
| 软路由 | 163.3 | 11.1 | 5.5 | — | 17.1 |
| 腾讯云 | 261.7 | 6.0 | 21.9 | 17.1 | — |
第一眼就有个反常：上海到旧金山，云主机反而比家里的宽带宽带慢 57%。
把延迟换算成距离
光在光纤里的速度大约是 2.04×10⁵ km/s（真空光速的 68%）。所以：
光程(km) = 往返延迟(ms) × 102
| 路径 | 延迟 | 物理距离 | 光程 | 绕路系数 |
|---|---|---|---|---|
| 加州 ↔ 阿里云 | 149.9 ms | 9,930 km | 15,290 km | 1.5× |
| 加州 ↔ 软路由 | 163.3 ms | 9,930 km | 16,657 km | 1.7× |
| 加州 ↔ Mac | 166.4 ms | 9,930 km | 16,973 km | 1.7× |
| 加州 ↔ 腾讯云 | 261.7 ms | 9,930 km | 26,693 km | 2.7× |
| 阿里云 ↔ 腾讯云 | 6.0 ms | ~30 km | 612 km | 20× |
| 软路由 ↔ 腾讯云 | 17.1 ms | ~30 km | 1,744 km | 58× |
| Mac ↔ 腾讯云 | 21.9 ms | ~30 km | 2,234 km | 75× |
| Mac ↔ 软路由 | 5.5 ms | ~15 m | 561 km | 37,400× |
四个反直觉的结论
一、ping 一次加州，比光绕地球一圈还慢
光在光纤里绕赤道一圈需要 196.4 ms。而腾讯云到加州的往返是 261.7 ms——多出 33%。
也就是说，包并没有沿着大圆走。这是第一篇留的悬念。
二、同一间屋子里的两台机器，光要跑 561 公里
Mac 和软路由在同一个 /24 网段，物理距离十几米，ping 5.5 ms。按光速换算，这 5.5 毫秒够光跑 561 公里。
那 5.5 ms 全是 Wi-Fi 重传、协议栈、加密和内核调度——跟距离毫无关系。
光速只在长距离（超过 1000 公里）时才主导延迟。
三、“上海”在网络地图上是一片 2,234 公里的区域
四台机器物理上都在上海，最远不过几十公里，但彼此的网络光程从 612 公里到 2,234 公里不等——后者相当于北京到广州。
差异不来自距离，来自跨运营商互联和隧道封装的开销。
四、数据只跑到光速的四分之一
| 路径 | 有效传输速度 | 占真空光速 |
|---|---|---|
| 加州 ↔ 阿里云 | 132,500 km/s | 44.2% |
| 加州 ↔ Mac | 119,400 km/s | 39.8% |
| 加州 ↔ 腾讯云 | 75,900 km/s | 25.3% |
即使最好的一条也只有 44%。光纤本身只有 68% 光速，再打上路由绕行的折扣，就只剩这么多了。
然后我去追了每一跳
延迟只能告诉你“多远”，追路径才能告诉你“为什么”。于是我对着每台机器做了一次 traceroute。
结论比预想的更离谱。
腾讯云的主机出国，走的是中国电信的骨干
腾讯云上海 → 加州，逐跳（已按延迟校正位置）：
容器网关 0.1 ms
腾讯云内网 1.7 ms
腾讯云内网 2.6 ms
──────────────────────────
上海电信 3.7 ms ← 下云了
上海电信城域网 13.1 ms
上海电信 7.9 ms
电信骨干 5.9 ms
═════════ 太平洋 ═════════
Level3 美国 296 ms ⚡ 出境
腾讯云硅谷内网 144.8 ms ← 又回云了
加州枢纽
它先“下云”到上海电信，跨完太平洋再“上云”回腾讯云内网。
而家里的 Mac 走的是同一条电信骨干，出境点是同一台设备：
家里 AP → 上海电信 BRAS → 上海城域 → 电信国际出口 ⚡ → Level3 → 腾讯云硅谷 → 枢纽
“同一家云厂商”在这条路上一点便宜都没占到。
家里两台机器的路径完全重合
Mac 和软路由出国走的是同一条物理路径，连出境跳都一模一样。软路由只比 Mac 多绕了家里三跳（0.4 + 0.6 + 3.4 毫秒），到加州的差距在测量噪声之内。
分流规则的真实效果
同一台软路由，访问两个地方差了 15 倍：
| 目标 | 延迟 | 原因 |
|---|---|---|
| 上海某云 | 10.3 ms | 分流判为国内 → 直连家宽 |
| 加州 | 152 ms | 分流判为国外 → 走隧道 |
不是距离问题，是规则问题。
最有意思的部分：IP 定位库画出了一条虚构路线
我对 19 个公网跳做了地理位置查询，结果明显错误的有 6 个：
| 实际位置 | 定位库说 | 错在哪 |
|---|---|---|
| 上海·电信国际出口 | 北京 | 差 1,100 公里，方向反了 |
| 上海·电信骨干 | 北京 | 同上 |
| 上海·电信 | 北京 | 往返只有 5.2 毫秒，不可能是京沪 |
| 美国·Level3 骨干 | 多伦多，加拿大 | 跨了个大洲 |
| 硅谷·腾讯云内网 | 哥伦布，美国国防部 | 差 3,800 公里 |
| 腾讯云内网 | 伦敦，微软 | 跨了个大洲 |
如果按定位库的结果把真实路径画出来，会变成：
上海 → 北京 → 多伦多 → 哥伦布（美国国防部）→ 白厅 → 硅谷
一条穿越三个国家、还路过了美国国防部的路线。
而真实的路径只有：
上海 → （海底光缆）→ 美国西海岸
为什么错这么多：骨干网的 IP 段整个 AS 注册在总部所在地，但路由器实际分布在全国甚至海外；还有一些是云厂商从别的机构买来的历史 IP 段，WHOIS 里写的还是几十年前的地址。
结论：IP 地理定位对骨干网节点基本不可信。往返延迟才是唯一可靠的位置证据——它至少受光速约束。
全网的三个铰链
把六条路径叠在一起，整个网络只有三个真正的“铰链”：
上海（家） 上海（云）
Mac ──┐ ┌── 腾讯云
软路由 ┴→ 电信 ──┬── │ 阿里云
│ └──
电信国际出口 │ 互联互通
└──┬──┘
══ 太平洋 ══
│
Level3 美国 ← 铰链 ①
│
腾讯云硅谷内网 ← 铰链 ②
│
加州枢纽 ← 铰链 ③
三个铰链决定了全网的国际链路质量。任何一个抖动，家里到云、云到云，全都一起慢。
方法
# 1. 找机器（如果它们都在同一个虚拟网段）
for i in $(seq 1 20); do ping -c1 -W1 10.8.0.$i >/dev/null 2>&1 && echo "10.8.0.$i 活"; done
# 2. 实测延迟
ping -c 20 -W 2 <目标>
# 3. 追路径（macOS 必须用 -I，默认 UDP 模式会被中间设备静默丢弃）
traceroute -I -n -w 2 -q 1 -m 18 <目标>
mtr -n -c 3 -r -m 18 <目标> # Linux 上更稳
# 4. 算
# 大圆距离：haversine，R=6371
# 光程：延迟(ms) × 102
# 绕路系数：光程 ÷ 物理距离
误差说明
-
ICMP 有优先级问题，个别路径可能偏差 ±10%（改 TCP 测会更准）
-
城市内的“约 30 公里”是估算，IP 定位不提供街道级精度
-
云厂商的“上海”节点实际可能在松江或青浦的数据中心，离市区 30 到 60 公里
最后
五台机器物理上分布在上海和加州，最远 9,930 公里。但在网络看来，它们挤在一个直径 2.6 万公里的球面上：上海的四台彼此隔了几百到两千公里，而同一间屋里的两台，光都要跑 561 公里。
物理距离决定光速下限，运营商互联决定你实际拿到多少。
那句老话“距离产生延迟”后面应该补一句：
距离产生延迟的下限，剩下的都是别人的路由策略。