查看“︁搬瓦工 SPECIAL 20G KVM PROMO V5 五机房横评：谁更适合上海电信？”︁的源代码

同一款搬瓦工 '''SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE'''，在 KiwiVM 里换个机房，可能连 CPU、回程线路和实际体验都一起换掉。

2026年9月，我从'''中国上海电信'''依次测试了洛杉矶 DC6、洛杉矶 DC9、圣何塞 SJC5、温哥华 CABC6 和日本大阪 JPOS1。四个北美节点的电信样本都走 CN2 GIA，因此都可以作为上海电信的优先候选。本轮 DC6 的网络指标更均衡，温哥华硬件成绩最高，大阪连续两晚出现严重丢包。

<blockquote>
'''先说结论'''

* 上海电信可优先考虑：'''DC6 / DC9 / SJC5 / CABC6'''
* 同价选择顺序：'''先看当前节点负载，再看物理距离'''
* 本轮网络样本较均衡：'''洛杉矶 DC6'''
* 美国算力：'''洛杉矶 DC9'''
* 上传优先：'''圣何塞 SJC5'''
* 加拿大与高算力：'''温哥华 CABC6'''
* 两晚表现不佳，上海电信不作首选：'''大阪 JPOS1'''
</blockquote>

----

== 一、五机房本轮评分 ==

=== 评分口径 ===

9月21日晚又测了一次大阪，丢包仍超过50%，实际使用依旧不理想。这次没有保存新截图和精确包数，因此下表仍用9月20日的完整数据评分；第二晚结果作为补充记录。

这不是搬瓦工官方评分或固定排位，而是面向'''上海电信用户'''的本轮短时样本指数。选机时应先看电信回程是否为 CN2 GIA；同价且线路同级，再比较当前节点负载和物理距离：

* '''本地网络 60分'''：丢包、Ping、测速抖动、下载和上传；
* '''回程线路 15分'''：上海电信及三网样本的线路质量与一致性；
* '''硬件性能 15分'''：Sysbench、Geekbench 5 和 fio；
* '''IP与解锁 10分'''：属地、风险库结果和服务解锁范围。

网络权重最高，因此“CPU 跑分高”不会自动赢过“连接稳”。大阪的低 Ping 也无法抵消43%丢包和极低上传。

{| class="wikitable"
|-
! 档位
! 机房
! 本地网络
! 回程
! 硬件
! IP与解锁
! 样本分
! 本轮观察
|-
| CN2 GIA优先池
| 洛杉矶 DC6
| 57/60
| 15/15
| 7/15
| 9/10
| '''88'''
| 本轮网络样本较均衡
|-
| CN2 GIA优先池
| 洛杉矶 DC9
| 48/60
| 14/15
| 13/15
| 8/10
| '''83'''
| 美国节点中算力较高
|-
| CN2 GIA优先池
| 温哥华 CABC6
| 45/60
| 14/15
| 15/15
| 9/10
| '''83'''
| 五节点中硬件成绩最高
|-
| CN2 GIA优先池
| 圣何塞 SJC5
| 47/60
| 15/15
| 11/15
| 9/10
| '''82'''
| 本轮上传最高
|-
| 暂缓
| 大阪 JPOS1
| 10/60
| 6/15
| 6/15
| 4/10
| '''26'''
| 两晚严重丢包
|}

本轮星级：DC6 ⭐⭐⭐⭐⭐；DC9、CABC6、SJC5 ⭐⭐⭐⭐☆；JPOS1 ⭐☆☆☆☆。

分数只用于快速阅读，不代表长期 SLA，也不应把四个 CN2 GIA 节点排成永久名次。节点负载会变化，单次测速和跑分只能提供当时的负载线索；同价时可以先迁移测试当前负载，再按物理距离和业务地区选择。DC9 与温哥华同为83分，但定位不同：前者适合需要美国位置和算力的用户，后者适合加拿大位置及更强 CPU。SJC5 只低1分，主要受372ms延迟尖峰影响。

== 二、测试说明 ==

{| class="wikitable"
|-
! 项目
! 本轮记录
|-
| 本地 ISP / 城市
| China Telecom，Shanghai, China（上海电信）
|-
| 回程终点
| 独立路由追踪标注 AS4812
|-
| 套餐
| SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE
|-
| 官方规格
| 2核、1GB内存、20GB RAID-10 SSD、1000GB/月、2.5Gbps端口
|-
| 测试工具
| NodeQuality、Sysbench、Geekbench 5、fio、NextTrace、ITDOG、Windows Ping、Speedtest-X
|-
| 测试日期
| 2026年9月19日晚至20日晚，北京时间
|-
| 五个机房
| USCA_6、USCA_9、USCA_SJC5、CABC_6、JPOS_1
|}

DC6 的 NodeQuality 记录始于 '''9月19日22:51'''，SJC5 是 '''9月20日00:09'''，大阪是 '''9月20日23:02'''，温哥华是 '''23:27'''。五个节点是分时测试，其中部分已经过了23:00；本文不把它们都称为严格同一晚高峰。各截图也没有统一精确时间戳，家宽签约速率和 Speedtest-X 并发设置未提供。

套餐支持在 KiwiVM 中迁移数据中心；面板当前可迁位置以实例实际显示为准。东京 JPTY_1 和迪拜 AEDXB_1 不在这轮五节点里，不能把别人的北京移动成绩混进本次上海电信数据。

== 三、延迟、丢包和速度 ==

大阪此表为9月20日首次测试；9月21日晚复测反馈的“超过50%”单独记录，未与首次100包合并。

下表的 Ping 来自本地 Windows 100包统计；下载和上传来自本地 Speedtest-X，方向按本地客户端计算。抖动是 Speedtest-X 自己的结果，不能当作这100个 Ping 的标准差。

{| class="wikitable"
|-
! 状态
! 机房
! Ping 最低 / 平均 / 最高
! 丢包
! 下载 / 上传
! 测速抖动
! 本轮观察
|-
| 🟢
| 洛杉矶 DC6
| 132 / 134 / 147ms
| 0/100
| 215.26 / 75.88Mbps
| 0.78ms
| 下载高、短样本波动小
|-
| 🟢
| 洛杉矶 DC9
| 131 / 134 / 158ms
| 0/100
| 132.30 / 68.95Mbps
| 6.23ms
| 延迟接近DC6，抖动略高
|-
| 🟡
| 圣何塞 SJC5
| 127 / 133 / 372ms
| 0/100
| 128.32 / 82.21Mbps
| 4.19ms
| 上传最高，出现延迟尖峰
|-
| 🟢
| 温哥华 CABC6
| 159 / 161 / 168ms
| 0/100
| 216.88 / 79.73Mbps
| 1.23ms
| 吞吐亮眼，延迟高于美西
|-
| 🔴
| 大阪 JPOS1
| 95 / 98 / 109ms*
| 43/100
| 23.07 / 0.74Mbps
| 555.46ms
| Ping数字漂亮，连通表现失守
|}

''*大阪 Ping 均值只包含'''57个收到回复的包'''，其余43包超时。北美四节点的零丢包也仅代表各自这100包，不等于全天零丢包。216.88 与215.26Mbps之间只有1.62Mbps差距，分时单次测速不适合拿来宣称温哥华长期快于 DC6。''

=== 三网回程 ===

{| class="wikitable"
|-
! 机房
! 电信样本
! 联通样本
! 移动样本
|-
| DC6
| CN2 GIA
| CN2 GIA
| CMIN2
|-
| DC9
| CN2 GIA
| AS10099 / AS9929
| CMIN2
|-
| SJC5
| CN2 GIA
| CN2 GIA
| CN2 GIA
|-
| CABC6
| CN2 GIA
| CN2 GIA
| CN2 GIA
|-
| JPOS1
| 公共京沪目标经 SoftBank；本地上海目标经 IIJ、AS4837 转电信
| 可见 AS4837，部分路径经 SoftBank
| CMI AS58453，部分路径经 SoftBank
|}

这是本轮目标地址和探测协议下的'''回程'''；不能据此推断去程或所有目的地都走同一路。温哥华面板标有 CMIN2、CUP，但本轮三网样本都被脚本识别为 CN2 GIA。大阪公共目标和本地目标的结果不同，给整台 VPS 只贴“SoftBank”或“IIJ”标签都会漏掉一部分事实。

== 四、硬件差异 ==

五台实例都识别到2核、约1GB内存、脚本显示约19G磁盘空间；CPU 型号和跑分却拉开了距离。下面的 fio 统一取 '''SEQ1M/Q1''' 读写，避免将不同队列深度的峰值混在一起。

{| class="wikitable"
|-
! 机房
! 虚拟机呈现的 CPU
! Sysbench 单 / 多线程
! Geekbench 5 单 / 多核
! fio 顺序读 / 写
|-
| DC6
| Intel SierraForest
| 811.81 / 1581.28
| 601 / 1143
| 765 / 1062MB/s
|-
| DC9
| AMD EPYC-Genoa
| 3748.27 / 7211.57
| 968 / 1792
| 1578 / 2447MB/s
|-
| SJC5
| Intel SierraForest
| 1019.11 / 2009.08
| 833 / 1571
| 1657 / 1743MB/s
|-
| CABC6
| AMD EPYC-Genoa
| 4499.91 / 8799.76
| 1375 / 2613
| 894 / 2619MB/s
|-
| JPOS1
| Intel SierraForest
| 799.03 / 1558.77
| 589 / 1088
| 996 / 1138MB/s
|}

温哥华的 Sysbench 和 Geekbench 5 都是五个节点中最高，多核 Geekbench 5 为2613分。需要加拿大位置并且看重 CPU 时，可以优先考虑。

温哥华的两套 CPU 测试在五节点中最高；DC9 是三个美国节点里的 CPU 跑分领先者。顺序读取的单队列成绩却是 SJC5 最高，硬件没有一个可以概括全部指标的“总冠军”。虚拟机 CPU 名称和 fio 成绩不能单独证明宿主机配置或底层磁盘类型。

== 五、IP质量与服务解锁 ==

五个样本的网络组织均为 '''IT7 Networks / AS25820'''。下表为 NodeQuality 脚本在本轮 IP 上的检测结果，不是账号登录或实际播放测试。

{| class="wikitable"
|-
! 机房
! 脚本定位
! Scamalytics / IPQS
! Netflix
! Disney+
! ChatGPT
|-
| DC6
| 美国
| 3 / 未给出
| 美国区原生
| 美国区原生
| 美国区原生
|-
| DC9
| 美国
| 6 / 87（存在风险）
| 美国区原生
| 美国区原生
| 美国区原生
|-
| SJC5
| 美国
| 6 / 未给出
| 美国区原生
| 美国区原生
| 美国区原生
|-
| CABC6
| 加拿大
| 6 / 75（可疑IP）
| 加拿大区原生
| 加拿大区原生
| 加拿大区原生
|-
| JPOS1
| 日本
| 0 / 75（可疑IP）
| 仅自制内容
| 屏蔽
| 日本区原生
|}

DC6、DC9、SJC5、温哥华的 TikTok、YouTube、Amazon Prime Video、Reddit 等项目在脚本中也显示属地原生解锁；大阪的 Reddit 显示屏蔽。

大阪的 Scamalytics 是0，但 Netflix 仅支持自制内容，Disney+ 与 Reddit 被屏蔽。风险分低不代表服务解锁更完整。

不同风险库对同一 IP 的判断有分歧，例如几个样本的 IP2Location 都给出99的高风险分，不能用某一项低分断言 IP“纯净”。

== 六、国际互联 ==

以下是五份 NodeQuality 测试中“国际互连”模块的'''目标节点延迟'''，单位 ms。测试目标和上海家宽 Ping 不是同一组地址，不能把两张表直接相减。

{| class="wikitable"
|-
! 机房
! 香港
! 东京
! 新加坡
! 纽约
! 法兰克福
|-
| DC6
| 139
| 103
| 163
| 57
| 140
|-
| DC9
| 229
| 107
| 229
| 64
| 147
|-
| SJC5
| 240
| 104
| 235
| 70
| 150
|-
| CABC6
| 238
| 132
| 220
| 60
| 141
|-
| JPOS1
| 273
| 9
| 251
| 162
| 262
|}

大阪到东京目标仅9ms，但到香港目标是273ms，说明“日本机房”并不意味着对所有亚洲目标都快。国际互联模块还有吞吐和重传字段，部分记录为 ERROR 或明显异常；这里仅对照其延迟列，不用异常吞吐推断持续带宽。面向海外用户的业务还需要从目标地区真实客户端再测。

== 七、逐个说说 ==

=== 洛杉矶 DC6：本轮网络表现较均衡 ===

上海电信100包平均134ms、最高147ms、无丢包；本地下载215.26Mbps，测速抖动0.78ms。电信、联通样本走 CN2 GIA，移动走 CMIN2。它在本轮更像一个网络侧基准：CPU单核601分并不突出，但本地短样本的波动较小。

[[File:DC6_20260922.jpg]]

=== 洛杉矶 DC9：线路够用，硬件更强 ===

平均 Ping 同样134ms、100包无丢包，本地下载132.30Mbps、上传68.95Mbps。CPU识别为 AMD EPYC-Genoa，Geekbench 5 单核968分，明显高于 DC6；联通回程样本可见 AS9929。'''24小时等待条件的起算点未核实'''，因此只把这次记录视为该时段样本。

[[File:DC9_20260922.jpg]]

=== 圣何塞 SJC5：上传较高，但有延迟尖峰 ===

平均133ms、100包无丢包，但最高延迟到 '''372ms'''。五节点中它的本地上传82.21Mbps最高；三网样本均被识别为 CN2 GIA。测试记录在9月20日凌晨，不能凭这组数据宣布它在所有晚高峰都比洛杉矶稳定。

[[File:SJC5_20260922.jpg]]

=== 温哥华 CABC6：硬件最好，物理距离更远 ===

平均161ms、100包无丢包，延迟范围159—168ms；本地下载216.88Mbps、上传79.73Mbps。CPU 的 Sysbench、Geekbench 5 都领先本轮五节点，适合优先考虑加拿大部署并关注计算性能的人继续复测。它到上海比三个美国节点高约27—28ms，不能只看跑分选址。

[[File:CABC6_20260922.jpg]]

=== 日本大阪 JPOS1：两晚都不适合我的上海电信 ===

成功回应的 Ping 平均98ms，可是100包只收到57包。Speedtest-X 下载23.07Mbps、上传0.74Mbps、抖动555.46ms。公共京沪电信目标可见 SoftBank，本地上海电信独立回程则经 IIJ、联通 AS4837 再到电信。出现差异时应按目标逐条看路由，不能把地理位置或面板线路名当作实测结论。

[[File:JPOS1_20260922.webp]]

每个节点改用一张合并长图，收录 Ping、Speedtest-X、硬件、IP质量和完整三网回程。正文显示顶部缩略卡，点击可在新窗口查看1600px高清长图。

== 八、这组数据能说明什么 ==

本轮能直接确认的，是四个北美节点在各自100包 Ping 中未丢包，SJC5 出现372ms尖峰，大阪出现43%丢包，同时其本地测速表现较差。'''没有跨天监控、HTTP 成功率、长连接日志，也没有可核验的 SSH、网页或视频使用记录。''' 因而这里的“使用建议”是根据延迟、丢包、吞吐、回程和硬件数据推导，不能写成已经亲自验证过的全天使用体验。套餐标称的99.95%可用性承诺同样不属于这次短测的验证结果。

9月21日晚补测反馈丢包仍超过50%，使用感受依旧不佳，说明严重丢包并非只在首次测试中出现。对我这条上海电信线路，大阪 JPOS1 不作日常直连首选。首次 NQ 公共上海电信目标经 SoftBank → 电信163，本地独立回程却经 IIJ → 联通 → 电信；目前无法定位具体故障段，也不能将两晚结果概括为所有软银线路都不适合上海电信。

== 九、我的选择 ==

{| class="wikitable"
|-
! 需求
! 建议
! 依据
|-
| 上海电信同价选机
| '''DC6 / DC9 / SJC5 / CABC6'''
| 电信样本均为CN2 GIA；先看当前负载，再看物理距离
|-
| 本轮样本参考
| '''DC6'''
| 134ms平均、0/100丢包，下载和抖动表现均衡
|-
| 美国算力
| '''先选 DC9'''
| 美国节点中 CPU 跑分最高，联通样本可见AS9929
|-
| 上传优先
| '''先测 SJC5'''
| 上传82.21Mbps居首，但要复查372ms尖峰
|-
| 加拿大业务
| '''先选 CABC6'''
| 加拿大区检测、CPU全场最高，上海平均161ms
|-
| 日本低延迟
| '''大阪不作本地直连首选'''
| 首晚43%丢包，次晚反馈超过50%；两晚表现均不佳
|}

最后的选机顺序只能针对'''上海电信、这台实例和本轮时间'''。如果你的接入网是联通或移动，或业务主要面向日本、加拿大用户，应从相应的真实客户端重新测；脚本三网回程只能提供线路线索，不能代替当地用户体验。

我的选择是先在 '''DC6 / DC9 / SJC5 / CABC6''' 这几个 CN2 GIA 节点里测试当前负载；价格相同，再按物理距离和业务地区决定。大阪连续两晚严重丢包，我这条上海电信线路不会选它做日常直连。。

----