搬瓦工 SPECIAL 20G KVM PROMO V5 - 五机房上海电信横评（2026年9月复测）
五个节点的新测数据现已齐备。就这轮上海电信短样本而言，DC6 的下载与抖动表现较好，温哥华 CABC6 的 CPU 跑分最高，SJC5 上传最高但有延迟尖峰；大阪虽然收到回应的 Ping 平均只有98ms，却同时出现43%丢包，不能按平均延迟直接排在首位。
本轮以美国西海岸三个节点横向比较为基础，加入加拿大温哥华和日本大阪，观察北美与日本方向的差异。不混用此前五月的测试成绩，也不把分时单次测量当作长期排名。
五篇单点报告
套餐规格
以下是五个节点共用的套餐官方基线。它们用于说明产品承诺和配置范围，不替代各节点的现场检测结果。
| 项目 | 官方标称 |
|---|---|
| 产品名称 | SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE |
| 服务类型 | VPS - Self-managed |
| 磁盘 | 20 GB SSD，RAID-10 |
| 内存 | 1 GB |
| CPU | 2x Intel Xeon |
| 月流量 | 1000 GB/月 |
| 端口速率 | 2.5 Gigabit |
| 虚拟化 / 面板 | KVM / KiwiVM |
| 可选系统 | CentOS、Debian、Ubuntu、Rocky Linux、AlmaLinux |
| IPv4 / IPv6 | 1 个独立 IPv4；路由 /64 IPv6 子网 |
| 网络接口 | Secondary private network interface |
| 管理方式 | Full root access；严格自主管理 |
| 面板功能 | Instant OS reload、Manual ISO install、即时 rDNS（PTR）更新 |
| 服务功能 | 免费数据中心迁移、免费自动备份、免费快照 |
| 可用性承诺 | 99.95% uptime guarantee |
官方列出的线路位置
- 洛杉矶，China Telecom IDC：China Telecom CN2 GIA；为中国联通提供由中国电信承载的 2.5 Gbps 企业级传输；其他目的地使用 2.5 Gbps 电商优化高级网络；并与 Google 直接互联。
- 日本，Equinix OS1 IDC：SoftBank IP transit，2.5 Gbps；并与 Google 直接互联。
- 套餐还提供 10 个以上 Premium、E-Commerce grade 数据中心，具体可用位置以 KiwiVM 面板实际可用列表为准。
需要区分三种信息：官方通用规格、KiwiVM 当前节点标签、活动实例现场实测。尤其是 CPU 架构、磁盘类型、三网回程和速度，最终都以本次测试记录为准。
测试环境与时间
本地 ISP 为 China Telecom / 上海电信，城市为 Shanghai, China，独立回程终点标注 AS4812。使用 NodeQuality、Sysbench、Geekbench 5、fio、NextTrace、ITDOG、Windows Ping 和 Speedtest-X。
以下为 NodeQuality 各模块记录覆盖的时间，均为2026年、CST（UTC+8），不是持续可用性监控时长；其他截图没有独立时间戳。
| 节点 | NodeQuality 时间范围 |
|---|---|
| DC6 | 09-19 22:51:53—23:04:16 |
| DC9 | 09-19 23:32:57—23:44:21 |
| SJC5 | 09-20 00:09:09—00:20:35 |
| 大阪 | 09-20 23:02:17—23:14:43 |
| 温哥华 | 09-20 23:27:22—23:37:53 |
家宽签约速率、测速并发设置及截图精确时间未提供，不能视为严格同时同条件对照，也不能确认是单线程测速。DC9 的24小时等待要求缺少起算点和迁移时间记录，尚不能确认满足；脚本显示的开机时间不等于迁移时间。
本地网络结果
| 节点 | Ping 最低 / 平均 / 最高 ms | 丢失 / 发送 | 下载 Mbps | 上传 Mbps | Speedtest-X 抖动 ms |
|---|---|---|---|---|---|
| DC6 | 132 / 134 / 147 | 0 / 100 | 215.26 | 75.88 | 0.78 |
| DC9 | 131 / 134 / 158 | 0 / 100 | 132.30 | 68.95 | 6.23 |
| SJC5 | 127 / 133 / 372 | 0 / 100 | 128.32 | 82.21 | 4.19 |
| 温哥华 CABC6 | 159 / 161 / 168 | 0 / 100 | 216.88 | 79.73 | 1.23 |
| 大阪 JPOS1 | 95 / 98 / 109 | 43 / 100 | 23.07 | 0.74 | 555.46 |
大阪的延迟只统计成功回应的57包，不包含43个超时包。 北美四节点的零丢包也仅代表各自100包样本，不能外推为全天稳定。
下载、上传按本地客户端方向理解。Ping 与 Speedtest-X 使用不同测量方法，抖动不是这100包的统计值。NodeQuality 中的 ERROR、接收为0以及高于标称端口的异常读数不用于替代本地速度比较。
美国西海岸：延迟接近，吞吐与波动有差别
DC6、DC9 平均134ms，SJC5 平均133ms，1ms不足以证明城市优势。DC6 下载215.26Mbps，抖动0.78ms，在三个美国节点中表现较好。DC9 下载132.30Mbps，但计算跑分明显高于另外两个美国节点。
SJC5 上传82.21Mbps为五节点最高；不过100包中最高延迟372ms，均值接近并不意味着波动也相同。该节点记录来自凌晨，不能据此判断完整晚高峰表现。
温哥华：CPU突出，延迟高于美国西海岸
CABC6 平均161ms，比三个美国节点高约27—28ms；100包延迟范围159—168ms。下载216.88Mbps与 DC6 的215.26Mbps仅差1.62Mbps，分时单次结果不足以证明谁长期更快。
温哥华在本轮兼具较高 CPU 跑分和较好的短时吞吐；若目标只是降低上海电信交互延迟，美国西海岸三个节点更有优势。
大阪：不能用低延迟掩盖丢包
大阪成功回应的延迟比北美低，但43%丢包、555.46ms测速抖动和0.74Mbps上传共同表明这次上海电信端到端样本表现较差。Ping 单独丢包可能受 ICMP 策略影响，不过本次测速也不理想，不能仅以“ICMP限速”解释所有现象。
这些数据不足以定位故障在家宽、跨境链路、节点还是测速服务，也不能代表日本本地用户体验。现阶段不宜仅凭距离近，就将大阪推荐给对交互连续性敏感的上海电信业务。
回程差异
| 节点 | 电信样本 | 联通样本 | 移动样本 |
|---|---|---|---|
| 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，部分路径经 SoftBank | CMI AS58453，部分路径经 SoftBank |
表格描述的是本次目标与探测协议下的回程，并非节点对所有目的地址的固定策略。
CABC6 面板标有 AMD-F+NVMe、CN2GIA-E、CMIN2、CUP，但本次北京、上海、广州三网 TCP/UDP 样本均被脚本识别为 CN2 GIA，不能用面板标签代替实测。独立回程可见美国出口后回上海的路径。
大阪独立 VPS→本地上海电信回程为 AS25820 → AS2497（IIJ）→ AS4837 → AS4134 → AS4812，不同于公共京沪电信目标的 SoftBank 路径。路由应按目标分别解释，不能给全节点只贴一个运营商标签。个别 IT7 跳点的温哥华地理标注也不能证明流量实际绕行加拿大；中间跳星号不直接等于端到端丢包。
硬件对比
| 节点 | CPU 识别 | Sysbench 单 / 多线程 | Geekbench 5 单 / 多核 | fio SEQ1M/Q1 读 / 写 MB/s |
|---|---|---|---|---|
| DC6 | Intel SierraForest | 811.81 / 1581.28 | 601 / 1143 | 765 / 1062 |
| DC9 | AMD EPYC-Genoa | 3748.27 / 7211.57 | 968 / 1792 | 1578 / 2447 |
| SJC5 | Intel SierraForest | 1019.11 / 2009.08 | 833 / 1571 | 1657 / 1743 |
| CABC6 | AMD EPYC-Genoa | 4499.91 / 8799.76 | 1375 / 2613 | 894 / 2619 |
| JPOS1 | Intel SierraForest | 799.03 / 1558.77 | 589 / 1088 | 996 / 1138 |
CABC6 的两项 CPU 测试均领先，DC9 是美国三个节点中的 CPU 跑分领先者。磁盘则要分读写与队列深度看：CABC6 在此表的顺序写入较高，但顺序读取不是最高，不能概括成全部硬件指标第一。
型号是虚拟机呈现的信息，单次 fio 也不能证明底层物理介质或长期独享性能。高队列深度成绩见单点报告，不与 Q1 混排。
IP 与服务访问补充
新测两节点均为 AS25820 / IT7 Networks。温哥华脚本将 TikTok、Disney+、Netflix、YouTube、Amazon Prime Video、Reddit、ChatGPT 标为加拿大区原生解锁；大阪的 Netflix 为仅原创，Disney+ 和 Reddit 检测受限，其他四项标为日本区原生解锁。
这是脚本检测结果，不代表已经逐一登录或播放验证。两节点不同风险库的结论也不一致：低风险分与 IP2Location 99、IPQS 75并存，不能简单写成“纯净IP”。
使用建议与结论边界
| 需求 | 本轮可优先复测的节点 | 依据与限制 |
|---|---|---|
| 上海电信访问后台、日常交互 | DC6 | 134ms平均、较高下载、较低测速抖动；仍需应用与长时验证 |
| 美国部署兼顾计算性能 | DC9 | 美国三节点中 CPU 跑分较高；等待24小时条件未核实 |
| 加拿大部署兼顾计算性能 | CABC6 | 五节点 CPU 跑分最高，短样本吞吐较好；平均161ms |
| 较关注上传表现 | SJC5 | 本轮上传最高，但出现372ms延迟尖峰 |
| 对丢包敏感的上海电信业务 | 先复测北美四节点，大阪暂缓 | 北美各100包无丢包；大阪43%丢包需排查和重复测试 |
| 面向日本本地用户 | 本轮不作排序 | 上海电信视角不能代替日本本地访问测试 |
五节点数据已经收齐，但没有跨天监控、HTTP成功率、长连接记录或实际 SSH 操作日志，因此不写成已验证的长期使用体验。后续最有价值的是重复晚高峰和非高峰采样，尤其复查大阪丢包与 SJC5 尖峰，而不是给一次跑分排出绝对优劣。