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 测试完成，属于测试安排，之后未重复测量。

综合对比

下表的 Ping 为 100 次结果；P1、P8 和 HTTP 均为 Mbps。上/下 分别表示天津→VPS、VPS→天津。

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 的测试应用不同，因此文章不以两者的数值差直接推断某个应用“被限速”。

按使用场景选择

以下建议只针对本次天津联通晚间测试；表中的“首选”是依据实测数据作出的直接取舍。

对 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 和日本两站说明：接近这一量级的多连接吞吐并不保证单连接速度或低丢包。日本站平均延迟最低，但这一轮的丢包与单文件速度使它们无法成为通用首选。最终选择仍应结合目标业务与后续实际使用表现。