搬瓦工 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 的网络指标更均衡，温哥华硬件成绩最高，大阪连续两晚出现严重丢包。
先说结论
- 上海电信可优先考虑：DC6 / DC9 / SJC5 / CABC6
- 同价选择顺序：先看当前节点负载，再看物理距离
- 本轮网络样本较均衡：洛杉矶 DC6
- 美国算力：洛杉矶 DC9
- 上传优先：圣何塞 SJC5
- 加拿大与高算力：温哥华 CABC6
- 两晚表现不佳，上海电信不作首选：大阪 JPOS1
一、五机房本轮评分
评分口径
9月21日晚又测了一次大阪，丢包仍超过50%，实际使用依旧不理想。这次没有保存新截图和精确包数，因此下表仍用9月20日的完整数据评分；第二晚结果作为补充记录。
这不是搬瓦工官方评分或固定排位，而是面向上海电信用户的本轮短时样本指数。选机时应先看电信回程是否为 CN2 GIA；同价且线路同级，再比较当前节点负载和物理距离：
- 本地网络 60分：丢包、Ping、测速抖动、下载和上传；
- 回程线路 15分：上海电信及三网样本的线路质量与一致性；
- 硬件性能 15分：Sysbench、Geekbench 5 和 fio；
- IP与解锁 10分：属地、风险库结果和服务解锁范围。
网络权重最高，因此“CPU 跑分高”不会自动赢过“连接稳”。大阪的低 Ping 也无法抵消43%丢包和极低上传。
| 档位 | 机房 | 本地网络 | 回程 | 硬件 | 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延迟尖峰影响。
二、测试说明
| 项目 | 本轮记录 |
|---|---|
| 本地 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 的标准差。
| 状态 | 机房 | 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。
三网回程
| 机房 | 电信样本 | 联通样本 | 移动样本 |
|---|---|---|---|
| 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 读写，避免将不同队列深度的峰值混在一起。
| 机房 | 虚拟机呈现的 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 上的检测结果，不是账号登录或实际播放测试。
| 机房 | 脚本定位 | 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 不是同一组地址，不能把两张表直接相减。
| 机房 | 香港 | 东京 | 新加坡 | 纽约 | 法兰克福 |
|---|---|---|---|---|---|
| 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分并不突出，但本地短样本的波动较小。
洛杉矶 DC9：线路够用，硬件更强
平均 Ping 同样134ms、100包无丢包，本地下载132.30Mbps、上传68.95Mbps。CPU识别为 AMD EPYC-Genoa，Geekbench 5 单核968分，明显高于 DC6；联通回程样本可见 AS9929。24小时等待条件的起算点未核实，因此只把这次记录视为该时段样本。
圣何塞 SJC5：上传较高，但有延迟尖峰
平均133ms、100包无丢包，但最高延迟到 372ms。五节点中它的本地上传82.21Mbps最高；三网样本均被识别为 CN2 GIA。测试记录在9月20日凌晨，不能凭这组数据宣布它在所有晚高峰都比洛杉矶稳定。
温哥华 CABC6：硬件最好，物理距离更远
平均161ms、100包无丢包，延迟范围159—168ms；本地下载216.88Mbps、上传79.73Mbps。CPU 的 Sysbench、Geekbench 5 都领先本轮五节点，适合优先考虑加拿大部署并关注计算性能的人继续复测。它到上海比三个美国节点高约27—28ms，不能只看跑分选址。
日本大阪 JPOS1：两晚都不适合我的上海电信
成功回应的 Ping 平均98ms，可是100包只收到57包。Speedtest-X 下载23.07Mbps、上传0.74Mbps、抖动555.46ms。公共京沪电信目标可见 SoftBank，本地上海电信独立回程则经 IIJ、联通 AS4837 再到电信。出现差异时应按目标逐条看路由，不能把地理位置或面板线路名当作实测结论。
每个节点改用一张合并长图，收录 Ping、Speedtest-X、硬件、IP质量和完整三网回程。正文显示顶部缩略卡，点击可在新窗口查看1600px高清长图。
八、这组数据能说明什么
本轮能直接确认的，是四个北美节点在各自100包 Ping 中未丢包，SJC5 出现372ms尖峰，大阪出现43%丢包，同时其本地测速表现较差。没有跨天监控、HTTP 成功率、长连接日志，也没有可核验的 SSH、网页或视频使用记录。 因而这里的“使用建议”是根据延迟、丢包、吞吐、回程和硬件数据推导，不能写成已经亲自验证过的全天使用体验。套餐标称的99.95%可用性承诺同样不属于这次短测的验证结果。
9月21日晚补测反馈丢包仍超过50%，使用感受依旧不佳，说明严重丢包并非只在首次测试中出现。对我这条上海电信线路，大阪 JPOS1 不作日常直连首选。首次 NQ 公共上海电信目标经 SoftBank → 电信163，本地独立回程却经 IIJ → 联通 → 电信；目前无法定位具体故障段，也不能将两晚结果概括为所有软银线路都不适合上海电信。
九、我的选择
| 需求 | 建议 | 依据 |
|---|---|---|
| 上海电信同价选机 | 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 节点里测试当前负载；价格相同，再按物理距离和业务地区决定。大阪连续两晚严重丢包，我这条上海电信线路不会选它做日常直连。。