WZE测评 做欧洲业务、欧洲落地、或者要给亚洲用户一个欧洲出口，绕不开一个问题：从亚洲哪里出去到欧洲最快、最稳？ 这篇用本站 8 台亚洲机器实测到法兰克福/荷兰的延迟、路由和吞吐，结论可能反直觉：最快的不是日本、韩国，而是香港和马来西亚。
测试时间：2026-10-26 20:1x–20:3x（一次性实测，非长期监控）；香港三台的数据与 香港到欧洲线路实测 同批。
先给结论（按到法兰克福延迟排序）
| 节点 | 地区 | 法兰克福 | 荷兰 | 荷兰 HDD | 上行 | 下行 | 一句话 |
|---|---|---|---|---|---|---|---|
| vps.cat HK-D4 | 香港 | 152 ms | 166 | 166 | 27 Mbps | 58 Mbps | 路径最快，但端口只有 30M |
| evoxt 马来西亚 Pre | 东南亚 | 155 ms | 167 | 159 | 151 Mbps | 117 Mbps | 综合最优：又快又能跑量 |
| DMIT HKG.AN5.EB | 香港 | 188 ms | 182 | 181 | 136 Mbps | 159 Mbps | 延迟中等、带宽最好 |
| 华纳云 香港三区 | 香港 | 194 ms | 200 | 202 | 1.6 Mbps | 1.8 Mbps | 延迟还行，吞吐灾难 |
| evoxt 韩国（首尔） | 韩国 | 222 ms | 245 | 222 | 61 Mbps | 71 Mbps | 中等 |
| GreenCloud 6666 JP | 日本 | 238 ms | 226 | 225 | 88 Mbps | 115 Mbps | 延迟偏高、带宽尚可 |
| 荫云 韩国双ISP | 韩国 | 250 ms | 269 | 299 | 40 Mbps | 41 Mbps | 延迟/带宽都一般 |
| justg 东京 | 日本 | 257 ms | 240 | 232 | 43 Mbps | 50 Mbps | 最慢的一台 |
三个结论：
- 到欧洲最近的两个入口是香港和马来西亚（152–155ms），比日本（238–257ms）快 80–100ms。
- 延迟和带宽不一定同向：DMIT 香港 188ms 但能跑 136/159 Mbps；华纳云 194ms 却只有 1.6/1.8 Mbps；马来西亚 155ms + 151/117 Mbps 是唯一两项都靠前的。
- 日本、韩国到欧洲普遍 220–260ms，因为它们到欧洲的流量经常绕美国或走容量更紧的线；它们到美西反而只要 99–147ms（见下文对比）。
图一：到法兰克福的延迟
- 香港 vps.cat（152）和马来西亚 evoxt（155）在第一梯队；
- DMIT 香港 188、华纳云 194 在第二梯队；
- 韩国 222–250、日本 238–257 在第三梯队——比第一梯队多 70–100ms。
图二：上行 / 下行吞吐（同一目的地法兰克福）
测法：iperf3，法兰克福起服务端，2 条流 × 80M 上限、3 秒（所以数字是下限，打满说明还能更高）。
| 节点 | 上行 | 下行 | 解读 |
|---|---|---|---|
| DMIT 香港 | 136 | 159 | 1G 口，跨欧亚能跑满测试上限 |
| 马来西亚 | 151 | 117 | 上行打满，HE.net 西欧路径质量好 |
| 日本 GreenCloud | 88 | 115 | 中等 |
| 韩国 evoxt | 61 | 71 | 中等偏下 |
| justg 东京 | 43 | 50 | 偏低 |
| 荫云 韩国 | 40 | 41 | 偏低 |
| vps.cat 香港 | 27 | 58 | 被自身 30M 端口限制（不是路径问题） |
| 华纳云 香港 | 1.6 | 1.8 | 路径/整形问题，重传数百次 |
图三：延迟 × 吞吐（谁才是「又快又能跑」）
左上角最好。马来西亚 evoxt 和 DMIT 香港在左上区域；vps.cat 因为端口小被压在下方；华纳云在最底部——延迟看着不差，一上量就掉到 1.6 Mbps。
路由：三条典型的亚洲 → 欧洲路径
| 起点 | 去程（实测 ASN） | 回程（法兰克福侧回看） | 备注 |
|---|---|---|---|
| 马来西亚 evoxt | HE.net（AS6939）吉隆坡 → 新加坡 → 马赛 → 法兰克福 | 法兰克福 → Cloudflare（AS13335）→ 亚洲 | 一路向西，不经美国，155ms 的来源 |
| 日本 GreenCloud | 东京 xTom（AS3258）→ NTT/JPNIC → 欧洲 | 法兰克福 → 伦敦 → GSL（AS7578，美国方向）→ 日本 | 回程绕美国，238ms |
| 日本 justg | 东京 NTT（AS2914）→ Tata（巴黎） | 法兰克福 → 伦敦 → Tata（巴黎）→ 日本 | 257ms，路径最绕 |
| 韩国 evoxt | 首尔 SK Broadband（AS9318）→ HE.net → 欧洲 | 法兰克福 → HE.net（AS6939）→ 韩国 | 221ms |
| 韩国 荫云 | 首尔 moack（AS138195）→ PCCW（AS3491）/ Tata（AS6453）→ 欧洲 | 法兰克福 → Tata → PCCW → 韩国 | 250ms，回程最长 |
| 香港 vps.cat | Cloudie（AS9232）→ Zenlayer（AS932）→ RETN（AS9002）→ xTom | xTom → RETN → Zenlayer → 香港 | 152ms，最优 |
几个可以记住的判断：
- 「向西直飞」比「向东绕美国」快：马来西亚走 HE.net 经新加坡—马赛进欧洲，155ms；日本回程绕 GSL（美国方向）就要 238ms+。
- 韩国/日本到欧洲不占地理优势：它们离美西更近（99–147ms），到欧洲反而要绕半个地球。
- 香港看上游：同样在香港，Cloudie/RETN 那条 152ms，电信 CTE 194ms，差 42ms。
怎么选（欧洲业务 + 亚洲入口）
| 需求 | 建议 |
|---|---|
| 要欧洲出口、亚洲入口、还要跑量 | 马来西亚 evoxt（155ms + 151/117 Mbps）或 DMIT 香港（188ms + 136/159 Mbps） |
| 只要延迟最低 | 香港 vps.cat（152ms，注意 30M 端口）或马来西亚（155ms） |
| 日本/韩国用户访问欧洲 | 本地机即可，但要知道到欧洲 220–260ms 是正常值 |
| 欧洲用户访问亚洲 | 反过来同理：选离用户近的一端，不要为了"亚洲"绕远 |
| 大流量/备份 | 先测吞吐，别看延迟就下单（本文就有 1.6 Mbps 的反例） |
自己怎么复测
# 延迟（20 包）
ping -c 20 <欧洲目标IP>
# 路由（认 ASN，看向西还是向东）
nexttrace -T <欧洲目标IP>
# 吞吐（欧洲起服务端；亚洲客户端测，注意流量）
# 欧洲：iperf3 -s -p 5201
# 亚洲：iperf3 -c <欧洲IP> -p 5201 -P 2 -b 80M -t 3 -f m
# 反向加 -R
本站复测脚本：tools/measure-hk-eu.sh（香港侧矩阵）、本页数据由 tools/make-asia-eu-charts.py 生成。
口径与声明
- 所有数字为 2026-10-26 20:1x–20:3x 一次性实测；跨境路由会随运营商调度变化，以你实测时点为准。
- 延迟：ICMP 20 包平均；吞吐：iperf3 2 流 × 80M 上限、3 秒，数值为下限（打满 160 只说明"至少 160"）。
- 路由为单次 nexttrace 快照；部分节点屏蔽 TTL，路径由反向探测还原（法兰克福 → 亚洲）。
- 机器链接：vps.cat HK-D4 · DMIT HKG.AN5.EB · 华纳云 香港三区 · evoxt 马来西亚 · GreenCloud 6666 JP · justg 东京 · evoxt 韩国 · 荫云 韩国双ISP · v.ps 法兰克福
- 本站不代售、不编数；测不了的项目写「未测」，原始输出留档在服务端。