BandwagonHost 七機房實測：天津聯通晚間訪問表現
更多語言
更多操作
測試環境與方法
同一台 VPS 依次遷移至 USCA_2、USCA_9、USCA_6、USCA_SJC5、EUNL_9、JPOS_1、JPTY_1。Windows 端對每個實例依序運行 100 次 ICMP Ping、NextTrace 去程、30 秒 iperf3 P1 上傳與下載、30 秒 iperf3 P8 上傳與下載，以及通過 curl 下載 http://VPS-IP:8080/1GB.bin。上传指天津到 VPS，下載指 VPS 到天津；P1 為 1 條連接，P8 為 8 條並行連接。iperf3 數值採用接收端匯總速率，P8 採用 [SUM] receiver，統一為 Mbps。HTTP 數值為日誌中的 speed_download，由 Bytes/s 乘 8 再除以 1,000,000 得到 Mbps。
VPS 端另對天津聯通公網出口執行一次 NextTrace 回程。去程從客戶端私網地址出發，第三跳出現 100.74.64.1，屬於運營商級 NAT 地址段；七份回程均以同一天津公網出口地址為目標，均未在 30 跳內收到目標響應，但都到達天津聯通網內的可見節點。因此，「回程」在本文中準確地指 VPS 到天津聯通公網出口方向的可見路徑，不能據此還原到家庭電腦的最後幾跳。路由中出現的 * 只表示該跳沒有返回探測響應，不能直接解釋為業務丟包。地理位置和運營商名稱來自 NextTrace 標註，個別跳點可能誤標。
下表時間統一按北京時間呈現。Windows 測試從 22:17 持續至 23:25，七個機房依次遷移、依次測試。USCA_2 的回程測試先於 Windows 測試完成，屬於測試安排，之後未重複測量。
| 機房 | VPS IP | Windows 開始—結束 | VPS 回程時間 |
|---|---|---|---|
| USCA_2 | 176.122.132.80 | 22:17:22—22:24:03 | 22:05:33 |
| USCA_9 | 23.106.153.179 | 22:28:28—22:33:51 | 22:28:06 |
| USCA_6 | 199.180.112.107 | 22:37:48—22:43:04 | 22:37:23 |
| USCA_SJC5 | 138.128.196.175 | 22:46:36—22:52:01 | 22:46:28 |
| EUNL_9 | 104.255.64.144 | 22:55:20—23:00:44 | 22:55:08 |
| JPOS_1 | 212.50.251.130 | 23:05:54—23:13:36 | 23:05:28 |
| JPTY_1 | 74.82.223.221 | 23:18:32—23:25:58 | 23:17:54 |
綜合對比
下表的 Ping 為 100 次結果；P1、P8 和 HTTP 均為 Mbps。上/下 分別表示天津→VPS、VPS→天津。
| 機房 | Ping 最低/平均/最高 ms | 丟包 | P1 上/下 | P8 上/下 | HTTP 單線程下載 |
|---|---|---|---|---|---|
| USCA_2 | 182 / 186 / 194 | 2/100（2%） | 49.3 / 45.5 | 50.6 / 221 | 64.73 |
| USCA_9 | 160 / 160 / 161 | 0/100 | 49.4 / 134 | 50.3 / 218 | 140.11 |
| USCA_6 | 156 / 156 / 158 | 0/100 | 49.0 / 127 | 50.7 / 219 | 160.53 |
| USCA_SJC5 | 153 / 153 / 156 | 0/100 | 47.3 / 127 | 50.4 / 222 | 137.86 |
| EUNL_9 | 134 / 136 / 139 | 0/100 | 46.5 / 147 | 50.4 / 212 | 140.75 |
| JPOS_1 | 75 / 106 / 109 | 7/100（7%） | 49.3 / 33.3 | 50.4 / 222 | 49.71 |
| JPTY_1 | 63 / 100 / 103 | 2/100（2%） | 38.2 / 60.6 | 49.0 / 223 | 47.86 |
P8 下載全部落在 212—223 Mbps，與本地 200 Mbps 下行套餐處於同一量級，且略高於標稱值；這些結果可能已接近本地接入的實際可用速率，幾 Mbps 的 P8 名次差不宜解釋為機房優劣。P8 上傳為 49.0—50.7 Mbps，與上行約 50 Mbps 的估計吻合，但套餐上行標稱值尚未核實，也缺少設備與 VPS 限速記錄，不能確認瓶頸位置。相反，P1 下載和 HTTP 單線程差異明顯：USCA_2、日本兩站與其餘四站拉開了距離。兩項單連接測試採用不同協議和時刻，數值不必相等，但可以相互參照。
各機房及去回程分析
USCA_2：去回程均可見聯通 169 路徑，單連接表現偏弱
去程在北京進入 AS4837 聯通 169 骨幹，NextTrace 標註經聖何塞、洛杉磯後進入 AS25820；回程從洛杉磯經聯通 169 的美國節點、北京回到天津，可見節點在天津結束。它的 186 ms 平均 Ping 是七站最高，100 次中丟了 2 次；P1 下載僅 45.5 Mbps，HTTP 為 64.73 Mbps。P8 下載仍達到 221 Mbps，約為 P1 下載的 4.9 倍，說明這一輪測試中並行連接能顯著提高總吞吐，但不代表單連接體驗同樣好。P1 下載的服務端發送匯總記錄 23,754 次重傳，也支持對該輪單連接質量保持謹慎。
USCA_9：零 Ping 丟包，單連接和 HTTP 較均衡
去程可見上海 AS4837→AS9929（CUII）→AS10099，後續數跳不應答，最終到達洛杉磯 AS25820；AS10099 跳被標為香港，但不能僅憑這一處地理標註斷言實際物理繞行。回程可見從洛杉磯經 AS10099、上海與北京的 AS9929，再進入天津聯通。Ping 100 次全部返回，平均 160 ms；P1 下載 134 Mbps，HTTP 140.11 Mbps，P8 下載 218 Mbps。這組結果在美國站中比較穩健，但仍只是該時間段的一次觀察。
USCA_6：本次 HTTP 下載最快
去程可見上海的 AS4837→AS9929，接 AS10099 在美國的節點，最後到洛杉磯 AS25820；回程可見 AS10099→上海、北京 AS9929→天津聯通。Ping 平均 156 ms、0/100 丟包；P1 下載 127 Mbps，HTTP 160.53 Mbps 為七站最高，P8 下載 219 Mbps。HTTP 比 P1 iperf3 高不構成矛盾：兩者伺服器應用、連接行為及測試時刻不同。本次數據適合把它列為美國站單文件下載的優先複測對象。
USCA_SJC5：Ping 稍低，回程可見電信 CN2 再轉聯通
去程可見上海 AS9929 接 AS10099，終點為聖何塞 AS25820；回程則先出現美國的中國電信 AS4134 與 59.43 段 CN2 標記，經過上海、北京後轉入 AS4837 聯通抵達天津。這個回程和其他美國站不同，但不能僅憑「CN2」標記推定用戶體驗一定更好。實測 Ping 平均 153 ms、0/100 丟包；P1 下載 127 Mbps、P8 下載 222 Mbps、HTTP 137.86 Mbps。它的 Ping 略低於 USCA_6、USCA_9，單連接數據則未領先。
EUNL_9：零丟包組中延遲最低，P1 下載最高
去程可見北京聯通 169/CUII，接 AS10099，經 NextTrace 標註的法蘭克福、倫敦節點，最終到阿姆斯特丹 AS3214；回程從阿姆斯特丹經法蘭克福 AS10099、北京 CUII 回到天津。Ping 平均 136 ms、0/100 丟包；P1 下載 147 Mbps 為七站最高，HTTP 140.75 Mbps，P8 下載 212 Mbps。對於本次天津聯通線路，它在延遲、丟包和單連接下載三項之間取得了較好的平衡。雖然目標位於歐洲，卻不能憑地理距離預設它一定慢於美國站；實際路徑與互聯方式更直接地影響這一輪結果。
JPOS_1：平均延遲低，但本次丟包和單連接下載較差
去程可見上海 AS4837 接日本 SoftBank AS17676，終點被標在大阪；回程可見 SoftBank 在上海與聯通 AS4837 交接，後經北京到天津。Ping 平均 106 ms，最低 75 ms、最高 109 ms，但 100 次丟了 7 次。P1 下載 33.3 Mbps、HTTP 49.71 Mbps；P8 下載仍有 222 Mbps。P1 下載的服務端發送匯總記錄 9,568 次重傳。對遠程桌面、遊戲等依賴穩定響應的場景，7% 的單輪 Ping 丟包比低平均延遲更值得警惕；不過一次 100 包樣本不足以判斷它長期如此。
JPTY_1：本次最低平均延遲，但單文件下載未受益
去程可見上海 AS9929→AS10099 東京節點，終點為東京；AS10099 節點到終點之間的跳數未完整顯示，時間從約 51—55 ms 增至約 99—102 ms，不能據此確定缺失段的實際路徑。回程只清楚顯示東京附近 AS25820 與天津聯通節點，中間多跳不響應；其中首跳的地理標註與下一跳時延不一致，不能按標註繪製確切地理路線。Ping 平均 100 ms，為七站最低，但仍有 2/100 丟包；P1 下載 60.6 Mbps，HTTP 47.86 Mbps，為七站最低，P8 下載 223 Mbps。P1 下載的服務端發送匯總記錄 26,633 次重傳。它適合列入低時延需求的候選，卻需要在相同時段重複檢查丟包、單連接與交互體驗。
如何理解重傳、P1/P8 與 HTTP
P1 下載的服務端發送匯總重傳數依次為：USCA_2 23,754、USCA_9 0、USCA_6 4、USCA_SJC5 0、EUNL_9 1,265、JPOS_1 9,568、JPTY_1 26,633。P8 下載的 [SUM] sender 在七站均記錄約 6.9 萬—11.4 萬次重傳。重傳值得關注，但它是 TCP 發送端計數，不能直接當作 Ping 丟包率，也不能僅憑它定位擁塞發生在家庭寬帶、跨境段還是 VPS。Windows 客戶端上傳日誌沒有同樣的重傳列，不宜據此稱上傳「無重傳」。
P8 反映多個連接同時傳輸的總能力；P1 和 HTTP 更接近單連接、單文件使用情形。日本兩站 P8 下載都超過 220 Mbps，卻分別只有 33.3/60.6 Mbps 的 P1 下載和約 50 Mbps 的 HTTP 下載，正說明只看多線程峰值會掩蓋單連接體驗。反過來，HTTP 與 iperf3 的測試應用不同，因此文章不以兩者的數值差直接推斷某個應用「被限速」。
按使用場景選擇
| 使用場景 | 首選 | 備選 | 本次測試依據 |
|---|---|---|---|
| 不限定目標地區的綜合使用 | EUNL_9 | USCA_6 | EUNL_9 平均 Ping 136 ms、0/100 丟包，P1 下載 147 Mbps 為七站最高，HTTP 下載也有 140.75 Mbps。 |
| 美國節點或美西服務 | USCA_6 | USCA_9 | USCA_6 的 HTTP 單線程下載 160.53 Mbps 為七站最高，平均 Ping 156 ms、0/100 丟包；USCA_9 的 P1 下載略高，為 134 Mbps。 |
| 以單文件 HTTP 下載為主 | USCA_6 | EUNL_9 | HTTP 下載分別為 160.53 和 140.75 Mbps；兩站本輪 Ping 均無丟包。 |
| 經 VPS 代理觀看 YouTube 視頻 | USCA_6 | EUNL_9；若需要美國出口則選 USCA_9 | USCA_6 的 HTTP 單線程下載 160.53 Mbps 為七站最高，P1 下載 127 Mbps、0/100 Ping 丟包；EUNL_9 的 HTTP/P1 下載為 140.75/147 Mbps，也為 0/100 丟包。 |
| 以單連接 TCP 下載為主 | EUNL_9 | USCA_9 | iperf3 P1 下載分別為 147 和 134 Mbps，均為 0/100 Ping 丟包；這項選擇依據 P1，而非 P8。 |
| 遠程桌面等重視連續響應的交互 | EUNL_9 | USCA_SJC5 | EUNL_9 是零 Ping 丟包機房中平均延遲最低的；USCA_SJC5 平均 153 ms、0/100 丟包。日本兩站雖更低延遲，卻分別丟了 2% 和 7%。 |
| 必須使用日本節點 | JPTY_1 | JPOS_1 僅作對照 | JPTY_1 平均 Ping 100 ms、丟包 2%、P1 下載 60.6 Mbps；JPOS_1 分別為 106 ms、7%、33.3 Mbps。兩站的 HTTP 下載都只有約 50 Mbps。 |
| 多連接下載 | 不限地區選 EUNL_9；美國選 USCA_6；日本選 JPTY_1 | — | 七站 P8 下載為 212—223 Mbps，已處於本地 200 Mbps 下行套餐量級。選機房時應更多參考目標地區、丟包和單連接表現。 |
| 上傳為主 | USCA_6 | USCA_9 | 兩站本輪 Ping 均為 0/100 丟包；P1 上傳分別為 49.0、49.4 Mbps，P8 上傳分別為 50.7、50.3 Mbps。上傳差異很小，約 50 Mbps 可能接近本地上行能力。 |
對 YouTube 視頻代理，優先選 USCA_6：本次 HTTP 單線程下載最快，Ping 未見丟包，P1 下載也明顯高於 USCA_2 和日本兩站。若更看重單連接 TCP 表現，可選 EUNL_9；若代理出口必須位於美國，備選 USCA_9。JPOS_1 與 JPTY_1 雖然平均延遲較低，但本輪有 7%/2% Ping 丟包，HTTP 下載約 50 Mbps，因此不作為視頻代理的首選。YouTube 官方幫助給出的 4K 參考持續速率約為 20 Mbps；就本次測到的天津聯通與 VPS 之間的 HTTP 下載而言，七站均高於這一參考值，其中 USCA_6 的速率餘量最大。
如果只從七站中選一台供天津聯通這條寬帶日常使用，選 EUNL_9；明確需要美國節點，選 USCA_6；必須用日本節點，選 JPTY_1。USCA_2 和 JPOS_1 不作為本輪綜合首選：前者平均 Ping 186 ms、丟包 2%，P1 下載 45.5 Mbps；後者丟包 7%，P1 下載 33.3 Mbps。對競技遊戲而言，這七站沒有同時呈現足夠低的延遲和可靠的零丟包樣本，不宜根據本輪結果承諾遊戲體驗。
測試局限與結論
這是一台 VPS 順序遷移後的單晚、單地區、單運營商、每機房一輪測試。首站 Windows 測試 22:17 開始，末站 23:25 結束，跨越了晚間網絡狀態可能變化的一小時以上。機房、IP、上游互聯與測試時刻同時變化，不能把全部差異都歸因於機房。100 次 Ping 能揭示當時的明顯丟包，卻不足以描述全天或長期穩定性；單次 30 秒 iperf3 與一次 HTTP 下載也不能代表日常峰谷。回程只追蹤到天津聯通公網出口方向，且所有目標均未響應；NextTrace 的不應答跳、地理標註和 AS 信息需要結合可見證據謹慎解釋。已知本地下行套餐為 200 Mbps，但上行標稱速率、VPS CPU/限速與多時段重複結果仍缺失；約 50 Mbps 的上傳聚集與約 220 Mbps 的 P8 下載聚集尚不能用來確認瓶頸位置。
就這一晚而言，綜合首選是 EUNL_9，美國方向與 YouTube 視頻代理首選 USCA_6，日本節點首選 JPTY_1。USCA_9 與 USCA_SJC5 是美國方向的備選。七站 P8 下載均處於本地 200 Mbps 下行套餐的量級；USCA_2 和日本兩站說明：接近這一量級的多連接吞吐並不保證單連接速度或低丟包。日本站平均延遲最低，但這一輪的丟包與單文件速度使它們無法成為通用首選。最終選擇仍應結合目標業務與後續實際使用表現。