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

测试时间：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

NB 的跨境段比 Mkcloud 慢几毫秒，但 UDP 行为明显更正常。对 Hy2/QUIC/游戏 UDP 这类场景，不会具有 MK 那种会直接把某个包长窗口打穿的异常。

---

6. 总结

NB 这套链路的主要特点：

1. 上海 IXP 到日本出口的固定 RTT 约 30.5 ms，比 Mkcloud 的 25.6 ms 慢一点，但仍然低。
2. 日本侧出口到 Google Tokyo / NB JP 落地只加 0-3 ms，说明出口和落地都在日本侧，路径不绕远。
3. 两个 87.76.xxx.xxx 落地都在 87.76.xxx.xxx/24 AS206069，IXP 到两者都是约 30.4 ms。
4. 没有发现 UDP 320-530B size-window 黑洞；固定 1 Mbps 下 100-1200B 全部基本可用。
5. 需要注意 eth0 MTU=1378，这类封装链路对大包/PMTU 仍然应该保守配置，Hy2/QUIC 建议继续避免过大的 UDP payload 。

如果只看这次数据，NB 的问题不在 UDP size filter ，而在跨境固定延迟比 Mkcloud 多约 3-4 ms。对日常 Google/YouTube 这类场景，链路行为是正常的。 不过，NB 还在测试阶段，线路尚未完全割接，期待未来的表现吧。

数据来源：本机 ping/curl、远端 mtr/ping/curl、自建 UDP echo 探针、RIPEstat network-info / whois / asn-neighbours API 。