搬瓦工 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 節點裡測試當前負載；價格相同，再按物理距離和業務地區決定。大阪連續兩晚嚴重丟包，我這條上海電信線路不會選它做日常直連。。