[测评] 谁才是沪日顶流？ NB 上海前置 + IXP 先锋内测，与 MK 横向大对比

通过以下 Referral 链接购买 DigitalOcean 主机，你将可以帮助 V2EX 持续发展

测试时间：2026-05-23 ，Asia/Singapore 晚高峰。测试环境：Windows 本机开启 Claxx Verge TUN ，远端 IXP 机器通过 114.111.xxx.xxx:3500 SSH 登录。

重点对比三件事：每段 RTT 、BGP/上游形态、UDP 是否存在类似 Mkcloud 那种反向 size-window 黑洞。

1. 架构 + 各段实测延迟

家宽 PC / Claxx Verge TUN
  │
  │  ⓐ 44 ms RTT
  │     ping 211.136.xxx.xxx, 8 包 0% loss
  ▼
NB 上海前置
  - IP: 211.136.xxx.xxx
  - SS 端口: 3599
  - RIPEstat origin: AS24400 / CMNET-V4SHANGHAI

  │
  │  通过 NB 链路进入 IXP
  ▼
NB IXP
  - 外部连接 IP: 114.111.xxx.xxx
  - SSH: 3500
  - 内网 IP: 172.16.xxx.xxx
  - eth0 MTU: 1378

  │
  │  ⓑ 30.4-30.6 ms RTT
  │     IXP -> 172.16.xxx.xxx / 日本网关
  ▼
日本侧出口 / 网关
  - mtr hop1: 172.16.xxx.xxx
  - hop2: 80.249.xxx.xxx, AS216211 CYBERVERSE-BACKBONE

  │
  │  ⓒ 0.1-0.6 ms
  ▼
NB 日本 Hy2 落地
  - 87.76.xxx.xxx
  - 87.76.xxx.xxx
  - RIPEstat: 87.76.xxx.xxx/24, AS206069 CORNSEED

  │
  │  ⓓ 1-3 ms 到 Google Tokyo peer
  ▼
Google Tokyo / gstatic / 8.8.8.8

汇总表：

段	RTT	测法
ⓐ 本机 TUN -> 上海前置 `211.136.xxx.xxx`	44 ms	`ping -n 8`, 0% loss
本机 TUN -> JP4 `87.76.xxx.xxx`	91 ms	`ping -n 8`, 0% loss
本机 TUN -> JP9 `87.76.xxx.xxx`	81 ms	`ping -n 8`, 0% loss
IXP `172.16.xxx.xxx` -> 网关 `172.16.xxx.xxx`	30.5 ms	`mtr -c 20`, 0% loss
IXP -> JP4 `87.76.xxx.xxx`	30.4 ms	`ping -c 8`, 0% loss
IXP -> JP9 `87.76.xxx.xxx`	30.4 ms	`ping -c 8`, 0% loss
IXP -> Google DNS `8.8.8.8`	31.7 ms	`ping -c 8`, 0% loss
IXP -> gstatic `142.250.xxx.xxx`	32.4 ms	`mtr`, 0% loss 到目标

最关键的是 IXP 机器的第一跳：

HOST: nbnet-35
 1. 172.16.xxx.xxx   avg 30.5 ms
 2. 87.76.xxx.xxx    avg 30.6 ms

172.16.xxx.xxx 到默认网关 172.16.xxx.xxx 不是普通同机房 LAN 延迟，而是直接跳了约 30 ms 。结合后面一跳立刻到日本 AS206069 落地，可以判断 NB 的“上海 IXP -> 日本出口”主要固定开销约为 30 ms 。

和 Mkcloud 的 25.6 ms 沪日私线相比，NB 这段慢约 3-4 ms ，但仍然属于上海到东京/日本方向比较低的水平。

2. IXP 到日本出口 mtr

到 NB JP4

HOST: nbnet-35                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    _gateway              0.0%    10   30.4  30.4  30.3  30.8   0.1
 2. AS206069 87.76.xxx.xxx         0.0%    10   30.5  30.6  30.3  30.7   0.2

到 NB JP9

HOST: nbnet-35                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    _gateway              0.0%    10   30.5  30.6  30.3  31.1   0.2
 2. AS206069 87.76.xxx.xxx         0.0%    10   30.8  31.0  30.3  34.0   1.1

两个日本落地的路径非常短：IXP 出去第一跳已经是 30 ms 的跨境/跨区域固定延迟，第二跳就是落地 IP 。JP4 抖动更小，JP9 偶发到 34 ms ，但整体仍稳。

到 Google Tokyo

HOST: nbnet-35                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    _gateway              0.0%    10   30.4  30.4  30.3  30.8   0.1
 2. AS216211 80.249.xxx.xxx        0.0%    10   31.1  31.3  30.9  31.7   0.2
 3. AS???    210.173.xxx.xxx       0.0%    10   31.7  31.6  31.4  31.8   0.1
 4. AS15169  72.14.xxx.xxx         0.0%    10   32.4  31.9  31.6  32.4   0.2
 5. AS15169  Google internal       0.0%    10   32-35 ms
 6. AS15169  Google internal       0.0%    10   32-33 ms
14. AS15169  gstatic               0.0%    10   32.4 ms avg

IXP 到 Google Tokyo 基本就是 30 ms 私线/隧道开销加 1-3 ms 日本侧 peering 。路径里出现 AS216211，后续进 Google AS15169。

3. BGP / 地址归属观察

RIPEstat 查到的结果：

资源	前缀 / ASN	说明
`211.136.xxx.xxx`	`211.136.xxx.xxx/19`, AS24400	Shanghai Mobile / CMNET-V4SHANGHAI
`114.111.xxx.xxx`	`114.111.xxx.xxx/20`, SHIXP	National Shanghai New-Type Internet Exchange Point
`114.111.xxx.xxx/24`	IRR origin AS146762	Shanghai New-type Internet Exchange Point
`80.249.xxx.xxx`	`80.249.xxx.xxx/24`, AS216211	CYBERVERSE-BACKBONE / CYBERVERSE LLC
`87.76.xxx.xxx`	`87.76.xxx.xxx/24`, AS206069	CORNSEED, country JP

AS206069 的 RIPEstat neighbours 显示上游里有：

AS174     Cogent
AS216211  CYBERVERSE-BACKBONE
AS210352

这和 mtr 看到的路径吻合：NB IXP 出日本侧后，先走 AS216211 ，再进入 AS206069 的落地网段。
87.76.xxx.xxx/24 的 whois 里 country 标为 JP ，geofeed 来自 IPXO ；这类地址看起来是租用/托管型地址，不等同于物理绕路。实际 RTT 才是判断位置的关键，这里 IXP 到落地只有 30 ms ，说明物理出口在日本侧。

4. UDP size-window 测试

Mkcloud 的核心问题是：反向 UDP payload 320-530B 几乎 99.9% 丢包，而 300B 和 550B+ 又恢复正常。
这次对 NB 做了同样方向的 size 扫描：本机 TUN 发 UDP 到 IXP 外部口，IXP echo 回本机。

测试方法：

server: 114.111.xxx.xxx:3588 UDP echo
client: Windows 本机，走 Claxx Verge TUN
rate:   1 Mbps
time:   每个 payload 3 秒

固定速率结果：

UDP payload	接收 / 发送	丢包率
100 B	3733 / 3750	0.45%
300 B	1250 / 1250	0%
310 B	1208 / 1209	0.08%
320 B	1168 / 1171	0.26%
400 B	937 / 937	0%
500 B	746 / 750	0.53%
530 B	705 / 707	0.28%
550 B	680 / 681	0.15%
600 B	624 / 625	0.16%
800 B	467 / 468	0.21%
1200 B	310 / 312	0.64%

结论很直接：没有发现 320-530B 的 size-window 黑洞。
310 -> 320B 没有断崖，530 -> 550B 也没有恢复边界，所有测试点都在 0-0.64% 丢包范围内。

另外跑过一轮 burst 扫描，服务端对 100-530B 基本全收，说明正向没有按 size 丢包。burst 下大包 echo 回本机时丢包升高，但固定速率测试消失，因此更像本机/TUN 接收缓冲或瞬时 burst 压力，不是线路上的固定 size filter 。

5. 对比 Mkcloud 的关键差异

项	Mkcloud 沪日	NB 本次
上海 -> 日本固定开销	25.6 ms	30.4-30.6 ms
IXP -> Google Tokyo	约 31-33 ms	31-33 ms
日本落地路径	Mkcloud TK -> IIJ/DDPS	AS216211 -> AS206069
UDP 320-530B 反向黑洞	有，99.9%	未复现，0-0.64%
IXP 网卡 MTU	未记录	1378
本机 URL/HTTP 体感	约 88 ms URL test	curl 显式代理 total 281 ms ，TUN fake-ip total 506 ms