2026年9月24日 (四) 01:38 Uxh666

2026-09-24T01:38:19Z

Uxh666：创建页面，内容为“== 测试环境与方法 == 同一台 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 数值采用接…”

2026-09-24T01:32:44Z

创建页面，内容为“== 测试环境与方法 == 同一台 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 下载 <nowiki>http://VPS-IP:8080/1GB.bin。上传指天津到</nowiki> VPS，下载指 VPS 到天津；P1 为 1 条连接，P8 为 8 条并行连接。iperf3 数值采用接…”

新页面

== 测试环境与方法 ==
同一台 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 下载 <nowiki>http://VPS-IP:8080/1GB.bin。上传指天津到</nowiki> 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 测试完成，属于测试安排，之后未重复测量。
{| class="wikitable"
!机房
!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
|}
[[File:EwdnLBUP5seL4tlYcFbyubfDl4Yacxp9.png|thumb|280x280px]]

== 综合对比 ==
下表的 Ping 为 100 次结果；P1、P8 和 HTTP 均为 Mbps。上/下分别表示天津→VPS、VPS→天津。
{| class="wikitable"
!机房
!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
|}
[[File:ChqXU3R19dnJfpLHmHgzHpXbmZXE2hQY.png|thumb]]
[[File:LKwkJqEnAGii6EDVEaPEsNa4YZ2Gsaxu.png|thumb]]
[[File:Yiw0sPEfZ0NqDbDsUkbndag9FVBJVPwQ.png|thumb]]
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 的测试应用不同，因此文章不以两者的数值差直接推断某个应用“被限速”。

== 按使用场景选择 ==
{| class="wikitable"
!使用场景
!首选
!备选
!本次测试依据
|-
|不限定目标地区的综合使用
|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 和日本两站说明：接近这一量级的多连接吞吐并不保证单连接速度或低丢包。日本站平均延迟最低，但这一轮的丢包与单文件速度使它们无法成为通用首选。最终选择仍应结合目标业务与后续实际使用表现。

BandwagonHost 七机房实测：天津联通晚间访问表现 - 版本历史

2026年9月24日 (四) 01:38 Uxh666