DMIT+bugnet 组网六线路测速对比
2026-08-08 · 电信 500M · 同一台 Mac 同一 Wi-Fi · 客户端 Surge（Snell v5 链）
🟢 加粗 = 同指标本轮最佳
先说比的是哪六条线
六条线共用同一批机器，区别只在从哪进、中转几跳、从哪出：
| 线路 | 完整路径 | 跳数 |
|---|---|---|
| DMIT品川直连 | Mac → DMIT品川(191.xxx.xxx.xxx) → 出网 | 1 |
| DMIT品川+bugnet | Mac → DMIT品川 → bugnet西雅图(72.xxx.xxx.xxx) → 出网 | 2 |
| DMIT品川+Zoro家宽 | Mac → DMIT品川 → Zoro日本住宅(123.xxx.xxx.xxx) → 出网 | 2 |
| PO0+RFC直连 | Mac → PO0腾讯云(115.xxx.xxx.xxx) → RFC东京(23.xxx.xxx.xxx) → 出网 | 2 |
| PO0+RFC+Misaka | Mac → PO0 → RFC东京 → Misaka东京(103.xxx.xxx.xxx) → 出网 | 3 |
| PO0+RFC+Zoro家宽 | Mac → PO0 → RFC东京 → Zoro日本住宅 → 出网 | 3 |
其余机器：DMIT 美西 179.xxx.xxx.xxx（仅服务器侧对比用）。
先说清楚：慢的慢在中继，不是机器不行
- 每多一跳中转，就多一段延迟和一层封装开销。看总表就知道：跳数越多 TTFB 越大（1 跳 184ms → 2 跳 205ms → 3 跳 213ms；bugnet 链因落点在西雅图再加一截）。
- 串联链路的带宽上限由最窄一段决定。PO0 入口套餐是 200 Mbps，所以 PO0 系三条线的下载（186/275/207 Mbps）全线被压在这个量级——不是 RFC、Misaka 不行，它们东京本地吞吐 6000+ Mbps（见服务器侧表）。
- "美国 AI 从美国出更快"是错觉。ChatGPT/Claude 都是 Cloudflare 前置，从日本出口命中 CF 东京回源，TTFB 94ms；从西雅图出口反而 366ms。路由质量 > 地理距离。
六线路总表
| 线路 | 可达站点 | TTFB P50 | 单连接下载 | 4连接聚合 | 单流上传 | 4流上传 | UDP 丢包/RTT | codex 中位 |
|---|---|---|---|---|---|---|---|---|
| DMIT品川直连 | 35/36 | 🟢 184.5 ms | 🟢 351.57 | 🟢 590.57 | 22.03 | 🟢 62.42 | 🟢 0.0% / 🟢 140.5 ms | 7.0 s |
| DMIT品川+bugnet | 35/36 | 458.1 ms | 113.6 | 250.51 | 29.51 | 58.26 | 0.0% / 387.7 ms | 6.2 s |
| DMIT品川+Zoro家宽 | 35/36 | 205.3 ms | 304.41 | 349.32 | 31.88 | 51.78 | 0.0% / 153.3 ms | 🟢 6.1 s |
| PO0+RFC直连 | 35/36 | 205.8 ms | 186.48 | 246.34 | 🟢 127.63 | 55.35 | 0.0% / 151.0 ms | 6.3 s |
| PO0+RFC+Misaka | 35/36 | 213.9 ms | 275.31 | 228.81 | 96.06 | 47.8 | 0.0% / 158.2 ms | 7.3 s |
| PO0+RFC+Zoro家宽 | 35/36 | 212.5 ms | 207.34 | 215.49 | 100.04 | 47.25 | 0.0% / 154.3 ms | 7.8 s |
36 站（日本 4 / 美国 20 / 全球 12）×3 请求；下载为 Cloudflare 25MB 样本 ×3 取中位；UDP 为 1.1.1.1/8.8.8.8/9.9.9.9 各 20 次 DNS 查询合并；codex 为 codex-cli 真实 API 调用 ×5 取中位。吞吐单位 Mbps。
六线唯一共同失败站 Noon，是目标站自身兼容性问题（历史报告同样失败），与线路无关。
DMIT品川直连单流上传 22 Mbps 为样本异常（同线 4 流上传 62.4 Mbps），如实记录未剔除。
AI 端点网络分解（TTFB 中位，10 次采样）
纯网络层指标，不含模型推理——"用美国 AI 选哪条线"看这张：
| 线路 | chatgpt.com | claude.ai | api.anthropic.com |
|---|---|---|---|
| DMIT品川直连 | 🟢 94.0 ms | 🟢 96.5 ms | 🟢 90.2 ms |
| DMIT品川+bugnet | 365.7 ms | 361.8 ms | 358.0 ms |
| DMIT品川+Zoro家宽 | 126.8 ms | 117.5 ms | 113.4 ms |
| PO0+RFC直连 | 102.3 ms | 107.0 ms | 101.5 ms |
| PO0+RFC+Misaka | 118.2 ms | 123.1 ms | 108.4 ms |
| PO0+RFC+Zoro家宽 | 119.7 ms | 121.2 ms | 115.5 ms |
codex CLI 真实调用（×5 中位）
| 线路 | 成功率 | 中位耗时 |
|---|---|---|
| DMIT品川直连 | 5/5 | 7.0 s |
| DMIT品川+bugnet | 5/5 | 6.2 s |
| DMIT品川+Zoro家宽 | 5/5 | 🟢 6.1 s |
| PO0+RFC直连 | 5/5 | 6.3 s |
| PO0+RFC+Misaka | 5/5 | 7.3 s |
| PO0+RFC+Zoro家宽 | 5/5 | 7.8 s |
codex 耗时大头是 OpenAI 后端推理（与线路无关），六线 6.1-7.8s 的差距在推理波动范围内——这项只证明六线全通，不用于排名。（排坑：codex 需走 SOCKS5 代理端口，HTTP 代理端口会流式中断。）
关键区段延迟
| 区段 | RTT |
|---|---|
| Mac → DMIT 品川 | ~45 ms |
| Mac → PO0 华东 | 15.7 ms |
| DMIT 品川 ↔ bugnet 西雅图 | 82.4 ms（GSL，与官方标称一致） |
| RFC 东京 ↔ bugnet 西雅图 | 88.7 ms |
打美西专项（GSL 优势验证）
靶子为美西第三方主流端点（不用自家机器，避免同机房失真）：AWS S3 美西两个区域 + KamaTera 洛杉矶 Ookla 测速点（HTTP 定点下载，约 15MB×2 取中位）+ YouTube/X 真实页面加载（OpenCLI 驱动登录态 Chrome）。
S3 美西 TTFB 中位（10 次采样，越小越好）
| 线路 | us-west-1 北加州 | us-west-2 俄勒冈 |
|---|---|---|
| DMIT品川直连 | 433.6 ms | 414.9 ms |
| DMIT美西直连 | 🟢 347.2 ms | 392.4 ms |
| DMIT品川+bugnet（GSL） | 474.0 ms | 🟢 375.4 ms |
| PO0+RFC+Misaka | 453.7 ms | 🟢 366.0 ms |
洛杉矶定点下载（越大越好）
| 线路 | 速度 |
|---|---|
| DMIT品川+bugnet（GSL） | 🟢 190.6 Mbps |
| PO0+RFC+Misaka | 150.8 Mbps |
| DMIT美西直连 | 119.2 Mbps |
| DMIT品川直连 | 85.3 Mbps |
真实页面加载（YouTube / X）
| 线路 | YouTube TTFB / 完全加载 | X TTFB / 完全加载 |
|---|---|---|
| DMIT品川直连 | 276 ms / 2.8 s | 961 ms / 9.0 s（冷缓存） |
| DMIT品川+bugnet | 516 ms / 2.9 s | 🟢 57 ms / 3.7 s |
| PO0+RFC+Misaka | 🟢 227 ms / 🟢 2.2 s | 70 ms / 4.0 s |
| DMIT美西直连 | （打开超时未采到） | 84 ms / 4.4 s |
专项结论：
- 打美西的吞吐冠军是 GSL 链（DMIT品川+bugnet，190.6 Mbps）——比美西 DMIT 直连高 60%，是品川直连的 2.2 倍。GSL 段（日美 82ms）的价值在跨太平洋吞吐场景完全兑现。
- 延迟敏感的美西目标，us-west-2 方向两条中继链（366-375ms）均优于品川直连（415ms）；us-west-1 方向仍是美西直连最快——没有一条线包打所有美西目标。
- 页面级体验：Misaka 链 YouTube 最快（227ms/2.2s）；X 的壳页面各线都在 60-90ms 级（CDN 缓存页），完全加载 3.7-4.4s 与链路档位相符。
服务器侧国际互连（NetQuality，各出口机直测）
在线报告（NetQuality 官方生成）：
- DMIT 品川：https://Report.Check.Place/net/1Q1BETDUS.svg
- DMIT 美西：https://Report.Check.Place/net/2MYMITXOW.svg
- RFC 东京：https://Report.Check.Place/net/3Q2W2NAG0.svg
- Misaka 东京：https://Report.Check.Place/net/38J35GPDM.svg
- bugnet 西雅图：https://Report.Check.Place/net/22VJJMDNU.svg
- Zoro 住宅：https://Report.Check.Place/net/1FJCVNB7X.svg
出口机自身能力，不含"Mac→入口"段。格式：
延迟；发送/接收 Mbps。纽约方向六机全部 ERROR（探测点问题）。
| 城市 | DMIT品川 | DMIT美西 | RFC东京 | Misaka东京 | bugnet西雅图 | Zoro住宅 |
|---|---|---|---|---|---|---|
| 香港 | 🟢 46；470/407 | 151；158/127 | 🟢 46；3065/3965 | 49；3174/1374 | 223；96/84 | 49；425/109 |
| 东京 | 🟢 1；627/603 | 100；242/251 | 🟢 1；6072/7432 | 🟢 1；5669/3377 | 125；197/159 | 🟢 1；475/457 |
| 新加坡 | 🟢 67；379/407 | 230；84/89 | 74；2159/2336 | 78；1750/1355 | 223；99/84 | 92；246/159 |
| 悉尼 | 🟢 102；219/265 | 136；169/145 | 222；282/517 | 140；425/686 | 161；146/128 | 139；168/20 |
| 洛杉矶 | 99；236/296 | 🟢 0；520/479 | 188；850/1031 | 98；1421/629 | 28；232/464 | 99；212/43 |
| 纽约 | — | — | — | — | — | — |
| 法兰克福 | 236；60/46 | 141；142/143 | 279；63/86 | 234；73/95 | 🟢 136；140/147 | 254；67/21 |
| 伦敦 | 236；81/81 | 138；182/148 | 228；397/512 | 223；456/376 | 🟢 125；198/174 | 240；79/65 |
| 阿姆斯特丹 | 252；71/91 | 137；152/121 | 248；797/1032 | 213；453/376 | 🟢 128；176/155 | 244；79/53 |
| 圣保罗 | 262；61/47 | 🟢 166；125/109 | 331；327/492 | 257；355/208 | 170；130/66 | 304；57/14 |
看点：RFC 东京本地吞吐 6072/7432 Mbps 六机最强——再次证明 PO0 系慢在入口套餐；DMIT 美西洛杉矶 0ms 为探测端点同机房。
怎么用
| 需求 | 选哪条 |
|---|---|
| 日常主力（网页/下载/AI） | DMIT品川直连（五项全胜） |
| 要住宅 IP 身份（注册/风控敏感） | DMIT品川+Zoro家宽（只比直连慢 20ms，304 Mbps） |
| 入口容灾（DMIT 挂了） | PO0+RFC 系（腾讯云入口，完全异构） |
| 美西方向 | DMIT品川+bugnet（GSL 82ms 骨干段） |
一句话总结：六条线可用性没差别（35/36 站、UDP 零丢包、codex 全通），差距全在性能；而性能差距几乎全部来自"中继跳数"和"入口套餐带宽"，跟出口机器本身没关系。
仅代表本轮实测，受时段/路由/CDN 落点影响。
