WZE测评 有些需求是「香港落地 + 欧洲出口」：亚洲用户要访问欧洲业务、欧洲业务要在亚洲有入口、或者拿香港当跳板。这篇不讲理论，用三台香港机器 -> 两台欧洲机器的实测，把延迟、路由、吞吐三个维度摆出来——结论可能和你想的不一样：同为香港到欧洲，延迟差 40ms，吞吐能差 40 倍。
测试时间：2026-10-26 19:30–19:55（一次性实测，非长期监控）。
先给结论
| 香港机器 | 到法兰克福 | 到荷兰 | 一句话 |
|---|---|---|---|
| vps.cat HK-D4 | 152 ms | 166 ms | Cloudie ↔ Zenlayer ↔ RETN，最快、抖动最小 |
| DMIT HKG.AN5.EB | 188 ms | 182 ms | 走 Tata/NTT 绕行，中等 |
| 华纳云 香港三区 | 194 ms | 200 ms | 电信 CTE 路径，延迟还行，吞吐只有 2–4Mbps |
三个关键结论：
- 香港→欧洲正常 RTT 是 150–200ms，比香港→美西（约 143–147ms）多 20–50ms，这是物理距离决定的。
- 路径差异比距离差异更大：同样到法兰克福，最快的 152ms、最慢的 194ms，差 42ms（27%）。
- 延迟好看 ≠ 速度快：华纳云那台延迟 194ms 只比最快的多 27%，但 iperf3 吞吐只有 3.8 Mbps，反向 2.5 Mbps，重传 500+ 次——大流量场景基本不可用。
测试方法
| 项 | 说明 |
|---|---|
| 香港三台 | vps.cat HK-D4（Cloudie）、DMIT HKG.AN5.EB（AS906）、华纳云 香港三区（udc.hk） |
| 欧洲两台 | v.ps 法兰克福 FRA EPYC Gutsy（xTom，AS3214）、LiteServer 荷兰（AS60404） |
| 延迟 | ICMP，每目标 20 包，取平均 RTT |
| 路由 | nexttrace（ASN 逐跳）；部分节点屏蔽 TTL，用「欧洲 -> 香港」反向确认 |
| 吞吐 | iperf3，法兰克福起服务端，香港节点发起；DMIT 用 2 流 × 80M 限速打满，华纳云用 4 流不限速 |
| 复测脚本 | tools/measure-hk-eu.sh（延迟矩阵 + 反向路由） |
图一：延迟（香港 → 欧洲 vs 美西参考）
怎么读：
- 美西参考组（最右）三台都是 143–147ms，几乎一样——香港到美西的路径成熟、差异小。
- 欧洲组开始分化：法兰克福 152 / 188 / 194，荷兰 166 / 182 / 200。
- vps.cat 的欧洲路径明显更优：152ms，比另外两台少 36–42ms。这不是它机器快，是它的上游（Cloudie → Zenlayer → RETN）走了一条更直的欧洲路径。
- 所有方向 0% 丢包，抖动都 <1ms（vps.cat 到法兰克福 mdev 0.03ms，DMIT 0.03ms，华纳云 1.4ms）。
图二：三条路径差在哪
路径 A（vps.cat，152ms）
香港 Cloudie (AS9232) → Zenlayer (AS932) → RETN (AS9002) → xTom 法兰克福 (AS3214)
欧洲侧 RETN 直接进 xTom，中间没有绕美国/绕日韩；这是 152ms 的来源。注意：这台的正向 traceroute 被运营商屏蔽了 TTL（只能看到最后一跳），上面路径是从法兰克福反向测出来的。
路径 B（DMIT HK，188ms）
香港 DMIT (AS906) → 中转（隐藏）→ Tata (AS6453) / NTT (AS2914) → xTom 法兰克福
走的是传统 Tier-1 中转，中间有绕行，比 A 多 36ms。
路径 C（华纳云，194ms）
香港 udc.hk (AS140227) → 中国电信 CN2/CTE (AS4809) → 法兰克福 CTE (AS4809) → xTom
去程走电信 CTE（欧洲方向），回程（法兰克福 → 香港）走的是 GSL（AS7578）绕雅加达方向。延迟不是最差，但这条路对大数据不友好，见下一张图。
图三：吞吐——延迟差 27%，速度差 40 倍
| 方向 | 实测 | 说明 |
|---|---|---|
| DMIT HK → 法兰克福 | 160 Mbps | 2 流各 80M 限速被打满，说明路径 ≥160M（1G 口 + 188ms RTT 的 BDP 完全够） |
| 法兰克福 → DMIT HK | 160 Mbps | 双向对称，跨欧亚跑满 |
| 法兰克福 → vps.cat HK | 83 Mbps | 受 vps.cat 自身端口/线路限制 |
| vps.cat HK → 法兰克福 | 28 Mbps | 它的 30M 端口打满，不是路径问题 |
| 华纳云 HK → 法兰克福 | 3.8 Mbps | 4 流不限速，重传 542 次 |
| 法兰克福 → 华纳云 HK | 2.5 Mbps | 反向同样差，重传 96 次 |
这张图才是重点：同样是「香港→法兰克福」：
- DMIT 能跑 160 Mbps，说明欧亚之间的大带宽路径是存在的；
- vps.cat 受自身 30M 端口限制（28M 打满），属于机器出口瓶颈；
- 华纳云只有 2–4 Mbps 且大量重传，属于路径质量/整形问题——延迟测试（小包 20 个）看不出来，一上大流量就露馅。
什么时候该用「香港中转欧洲」
| 场景 | 建议 |
|---|---|
| 亚洲用户访问欧洲服务（网页/API），对延迟不敏感 | ✅ 可以，150–200ms 是正常水平，选路径好的（如 Cloudie/RETN 那条） |
| 需要欧洲 IP 做落地，但机器入口放香港 | ✅ 合理，但注意数据要走两段，吞吐取决于香港出口 |
| 跨境大流量 / 备份 / 视频 | ⚠️ 必须先测吞吐，别看延迟就下单（本文那台 2Mbps 就是例子） |
| 对延迟敏感（游戏、实时音视频） | ❌ 香港到欧洲 150ms+ 来回 300ms，不适合 |
| 欧洲用户访问欧洲 | ❌ 直接买欧洲本地机，香港中转纯属绕路 |
自己怎么复测
# 1) 延迟：从你的香港机器打欧洲目标，20 包
ping -c 20 <欧洲IP>
# 2) 路由：认 ASN，看有没有绕美国/绕新加坡
nexttrace -T <欧洲IP>
# 3) 吞吐：欧洲起服务端，香港测（注意流量，先小后大）
# 欧洲：iperf3 -s -p 5201
# 香港：iperf3 -c <欧洲IP> -p 5201 -P 2 -b 80M -t 6 -f m
# 反向加 -R
本站的完整复测脚本：tools/measure-hk-eu.sh（延迟矩阵 + 反向路由，吞吐命令在脚本末尾注释里）。
口径与声明
- 所有数字为 2026-10-26 19:30–19:55 一次性实测，不是长期监控；跨境路径会随运营商调度变化，结论以你实测时点为准。
- 延迟：ICMP 20 包平均，未做 TCP 层修正；吞吐：iperf3，DMIT 侧限速 2×80M（因此 160M 是下限，不是上限）。
- 路由：单次 traceroute/nexttrace 快照；部分节点屏蔽 TTL，路径由反向探测还原。
- 测试机器：vps.cat HK-D4 · DMIT HKG.AN5.EB · 华纳云 香港三区 · v.ps 法兰克福 · LiteServer 荷兰
- 本站不代售、不编数；测不了的项目写「未测」，原始输出留档在服务端。