md5.pw - 最近更改 [zh]

搬瓦工 Ultra VPS 系列新增新加坡机房，多维度网络测评

Air — Wed, 17 Jun 2026 14:27:32 GMT

←上一版本		2026年6月17日 (三) 07:27的版本
（未显示同一用户的1个中间版本）
第13行：		第13行：
	=== 一、硬件配置与底层性能实测 ===		=== 一、硬件配置与底层性能实测 ===
	新加坡机房不仅继承了 Ultra 系列的性能优势，硬盘 I/O 更是达到了顶级水准。		新加坡机房不仅继承了 Ultra 系列的性能优势，硬盘 I/O 更是达到了顶级水准。

			[[File:Bwhsgp参数性能.png\|855x855px]]

	=== 二、三网网络质量与延迟情况 ===		=== 二、三网网络质量与延迟情况 ===
	为了展现真实的网络情况，我们选取了国际网络较拥挤的晚上 21:15 左右（晚高峰）进行了网络质量和上下行吞吐量的探测，测试结果见下图。		为了展现真实的网络情况，我们选取了国际网络较拥挤的晚上 21:15 左右（晚高峰）进行了网络质量和上下行吞吐量的探测，测试结果见下图。

			[[File:Bwhsgp网络质量.png\|873x873px]]

	==== 1. 晚高峰三网延迟表现 ====		==== 1. 晚高峰三网延迟表现 ====
第26行：		第30行：
	中国联通：延迟偏高。全国联通节点的平均延迟普遍在 110ms - 130ms 之间浮动。		中国联通：延迟偏高。全国联通节点的平均延迟普遍在 110ms - 130ms 之间浮动。

	延迟表现解析：		'''延迟表现解析：'''

	电信和移动用户访问该节点延迟较低，而联通偏高，这与搬瓦工在该机房采取的路由回程策略直接相关（具体分析见下文路由部分）。由于跨网交接需要额外路由跳数，导致联通用户的物理延迟相对增加。		电信和移动用户访问该节点延迟较低，而联通偏高，这与搬瓦工在该机房采取的路由回程策略直接相关（具体分析见下文路由部分）。由于跨网交接需要额外路由跳数，导致联通用户的物理延迟相对增加。

	=== 2. 极限网络吞吐实测 ===		==== 2. 极限网络吞吐实测 ====
	我们通过脚本直接测试了晚高峰时段服务器到国内节点的上行发送速度。		我们通过脚本直接测试了晚高峰时段服务器到国内节点的上行发送速度。

第38行：		第42行：

	=== 三、回程路由深度分析 ===		=== 三、回程路由深度分析 ===
	博主一般在中部地区，所以这里特别测试了河南地区的路由回程情况，目前结果来看，三网均为GIA，与官网的描述存在一些差别，不过GIA的线路质量稳定性会更好一些。		博主一般在中部地区，所以这里特别测试了河南地区的路由回程情况，目前结果来看，三网均为GIA，与官网的描述存在一些差别，不过GIA的线路质量稳定性会更好一些。在路由追踪日志中，起始 IP 被标记为“荷兰（阿姆斯特丹）”。这并非数据包绕路，而是由于搬瓦工将其他地区的 IP 段通过 Anycast 或 BGP 广播分配到了新加坡机房，不会影响网速。可以看到节点间极低的延迟（不足 2ms）即可排除物理绕路可能，请以实际的 AS 网络编号为准。

	河南电信路由解析：		'''河南电信路由解析：'''

	可以看到流量从新加坡机房发出后，直接接入中国电信 CTGNet 跨国骨干网（69.194.x.x），随后直达上海，无缝交接至中国电信 CN2 GIA（59.43）核心节点，最终抵达河南。全程走在电信自家的顶级通道上，延迟极低且 0 丢包。		可以看到流量从新加坡机房发出后，直接接入中国电信 CTGNet 跨国骨干网（69.194.x.x），随后直达上海，无缝交接至中国电信 CN2 GIA（59.43）核心节点，最终抵达河南。全程走在电信自家的顶级通道上，延迟极低且 0 丢包。
第46行：		第50行：
	附图：		附图：

	河南联通路由解析：		[[File:Bwhsgp电信回程.png\|800x800px]]

			'''河南联通路由解析：'''

	可以看到流量从新加坡发出，同样接入 CTGNet 跨国骨干网，并在国内入口端（北京）被强制拉入电信 CN2 GIA（59.43）节点。在跨越最拥堵的国际出口段后，才在北京本地转交回中国联通骨干网（AS4837），最后抵达河南。		可以看到流量从新加坡发出，同样接入 CTGNet 跨国骨干网，并在国内入口端（北京）被强制拉入电信 CN2 GIA（59.43）节点。在跨越最拥堵的国际出口段后，才在北京本地转交回中国联通骨干网（AS4837），最后抵达河南。
第52行：		第58行：
	附图：		附图：

	河南移动路由解析：		[[File:Bwhsgp联通回程.png\|800x800px]]

			'''河南移动路由解析：'''

	移动的回程策略与联通如出一辙。流量未走移动自家的 CMI 出口，而是经由新加坡 CTGNet 直达北京的电信 CN2 GIA（59.43）节点。享受完 VIP 级别的跨国传输后，在北京与中国移动骨干网（AS9808）进行交接，最终回到河南。		移动的回程策略与联通如出一辙。流量未走移动自家的 CMI 出口，而是经由新加坡 CTGNet 直达北京的电信 CN2 GIA（59.43）节点。享受完 VIP 级别的跨国传输后，在北京与中国移动骨干网（AS9808）进行交接，最终回到河南。

	附图：		附图：

			[[File:Bwhsgp移动回程.png\|800x800px]]

	=== 四、三网延迟波动情况 ===		=== 四、三网延迟波动情况 ===
	为了验证该机房在全天候的真实表现，我们在服务器上部署了探针，对河南联通、河南移动和河南电信进行了长达 24 小时的持续 Ping 监控。		为了验证该机房在全天候的真实表现，我们在服务器上部署了探针，对河南联通、河南移动和河南电信进行了长达 24 小时的持续 Ping 监控。

			[[File:Bwhsgp24H延迟.png\|800x800px]]

	从监控图表可以看出，由于回程强制接入电信 CN2 GIA（59.43）专线，三网在 24 小时内的延迟曲线平稳。在晚高峰时段（20:00 - 23:00），未出现大幅度的“延迟突增”或断流现象，丢包率控制良好；信和移动的延迟曲线维持在较低水位（约 60ms-80ms）；联通由于需要跨网交接，延迟曲线平行位于稍高的水位（约 110ms-120ms），但波动幅度与电信/移动保持一致。略逊于之前测试过的 Ultra 系列香港和东京机房。		从监控图表可以看出，由于回程强制接入电信 CN2 GIA（59.43）专线，三网在 24 小时内的延迟曲线平稳。在晚高峰时段（20:00 - 23:00），未出现大幅度的“延迟突增”或断流现象，丢包率控制良好；信和移动的延迟曲线维持在较低水位（约 60ms-80ms）；联通由于需要跨网交接，延迟曲线平行位于稍高的水位（约 110ms-120ms），但波动幅度与电信/移动保持一致。略逊于之前测试过的 Ultra 系列香港和东京机房。
第65行：		第77行：
	=== 五、国际流媒体与 AI 平台解锁情况 ===		=== 五、国际流媒体与 AI 平台解锁情况 ===
	新加坡节点是东南亚流媒体和业务出海的重要位置。脚本测试的解锁情况如下：		新加坡节点是东南亚流媒体和业务出海的重要位置。脚本测试的解锁情况如下：

			[[File:BwhsgpIP质量.png\|920x920px]]


	测试结果解析：		'''测试结果解析：'''

	由于搬瓦工使用了广播 IP，TikTok 的风控机制暂时将其识别为北美（加拿大）区域。但对于多数核心流媒体（奈飞、迪士尼）和 AI 平台（ChatGPT、Claude），系统主要看重实际物理出口，目前已识别为新加坡并解锁了当地原生内容，能够满足正常的区域业务需求。		由于搬瓦工使用了广播 IP，TikTok 的风控机制暂时将其识别为北美（加拿大）区域。但对于多数核心流媒体（奈飞、迪士尼）和 AI 平台（ChatGPT、Claude），系统主要看重实际物理出口，目前已识别为新加坡并解锁了当地原生内容，能够满足正常的区域业务需求。

	=== 六、官方套餐配置与价格对比 ===		=== 六、官方套餐配置与价格对比 ===
	这款新加坡机房以 $49.99/月的起步价，提供了 1.5Gbps 的带宽以及三网强制 CN2 GIA 回程优化（不排除以后会变为三网优化）。		这款新加坡机房以 $49.99/月的起步价，提供了 1.5Gbps 的带宽以及三网强制 CN2 GIA 回程优化（不排除以后会变为三网优化），以下是官网介绍和套餐类型。

			[[File:Bwhsgp套餐展示.png\|800x800px]]

	=== 七、 Ultra 系列新加坡节点选购总结与建议 ===		=== 七、 Ultra 系列新加坡节点选购总结与建议 ===
第79行：		第95行：
	经过实测，这款新加坡 Ultra VPS 的特性总结如下：		经过实测，这款新加坡 Ultra VPS 的特性总结如下：

	三网统一回程策略：虽然联通和移动用户在国内需要跨网交接，但保障了晚高峰的稳定连通性，24 小时延迟曲线表现平稳。		'''三网统一回程策略：''' 虽然联通和移动用户在国内需要跨网交接，但保障了晚高峰的稳定连通性，24 小时延迟曲线表现平稳。

	硬件性能充裕：超过 11GB/s 的硬盘连续读取速度，适合对 I/O 突发要求较高的应用场景（不可长期负载）。		'''硬件性能充裕：''' 超过 11GB/s 的硬盘连续读取速度，适合对 I/O 突发要求较高的应用场景（但不可长期负载）。

	选购建议：如果您的业务面向东南亚地区、需要解锁新加坡原生 AI 与影音服务（TikTok 除外），且对晚高峰网络稳定性有较高要求，这款 $49.99/月的机型具备较强的性价比。		'''选购建议：''' 如果您的业务面向东南亚地区、需要解锁新加坡原生 AI 与影音服务（TikTok 除外），且对晚高峰网络稳定性有较高要求，这款 $49.99/月的机型具备较强的性价比。

	==== 2.官方购买路径 ====		==== 2.官方购买路径 ====
	访问官网：建议直接使用搬瓦工官方运营的国内镜像站进入选购页面（点击直达）：https://bwh81.net/aff.php?aff=30918		'''访问官网：''' 建议直接使用搬瓦工官方运营的国内镜像站进入选购页面（点击直达）：https://bwh81.net/aff.php?aff=30918

	定位套餐：在网页导航栏选择 "VPS Hosting"，找到名称带有 “Ultra VPS” 标签的方案，选择 Singapore 机房与对应配置，点击 "Order Now"。		'''定位套餐：''' 在网页导航栏选择 "VPS Hosting"，找到名称带有 “Ultra VPS” 标签的方案，选择 Singapore 机房与对应配置，点击 "Order Now"。

	确认订单：在购物车界面，确认套餐无误，点击 Checkout 确认订单，如果没有账号，系统会引导您使用邮箱注册。		'''确认订单：''' 在购物车界面，确认套餐无误，点击 Checkout 确认订单，如果没有账号，系统会引导您使用邮箱注册。

	完成支付：订单确认完毕后，会让你确认支付信息，点击 Make payment 可支付，目前支持 Alipay（支付宝）扫码支付。部署完成后，服务器 IP 和 Root 密码将发送至注册邮箱。		'''完成支付：''' 订单确认完毕后，会让你确认支付信息，点击 Make payment 可支付，目前支持 Alipay（支付宝）扫码支付。部署完成后，服务器 IP 和 Root 密码将发送至注册邮箱。
			[[Category:Test category]]

File:Bwhsgp套餐展示.png

Air — Wed, 17 Jun 2026 14:25:04 GMT

Air上传File:Bwhsgp套餐展示.png

新页面

Bwhsgp套餐展示

File:BwhsgpIP质量.png

Air — Wed, 17 Jun 2026 14:23:51 GMT

Air上传File:BwhsgpIP质量.png

新页面

BwhsgpIP质量

File:Bwhsgp24H延迟.png

Air — Wed, 17 Jun 2026 14:23:04 GMT

Air上传File:Bwhsgp24H延迟.png

新页面

Bwhsgp24H延迟

File:Bwhsgp移动回程.png

Air — Wed, 17 Jun 2026 14:20:43 GMT

Air上传File:Bwhsgp移动回程.png

新页面

Bwhsgp移动回程

File:Bwhsgp联通回程.png

Air — Wed, 17 Jun 2026 14:19:22 GMT

Air上传File:Bwhsgp联通回程.png

新页面

Bwhsgp联通回程

File:Bwhsgp电信回程.png

Air — Wed, 17 Jun 2026 14:18:55 GMT

Air上传File:Bwhsgp电信回程.png

新页面

Bwhsgp电信回程

File:Bwhsgp网络质量.png

Air — Wed, 17 Jun 2026 14:17:54 GMT

Air上传File:Bwhsgp网络质量.png

新页面

Bwhsgp网络质量

File:Bwhsgp参数性能.png

Air — Wed, 17 Jun 2026 14:16:57 GMT

Air上传File:Bwhsgp参数性能.png

新页面

Bwhsgp参数性能

搬瓦工 Ultra VPS 系列新增新加坡机房，多维度网络测评

Air — Wed, 17 Jun 2026 14:16:36 GMT

创建页面，内容为“搬瓦工（BandwagonHost）Ultra VPS 系列作为其产品线中的“天花板”，一直以顶级线路和超大带宽著称。近期，Ultra 系列迎来了重磅更新——新增了新加坡（Singapore）机房。作为一个地处亚太核心枢纽的节点，该机房标配 1.5Gbps 超大带宽。官方的线路介绍是接入了 Equinix IX, Google, Cloudflare, RETN, NTT，并且针对中国大陆网络特别优化，标称包含了 China Mobile 和…”

新页面

搬瓦工（BandwagonHost）Ultra VPS 系列作为其产品线中的“天花板”，一直以顶级线路和超大带宽著称。近期，Ultra 系列迎来了重磅更新——新增了新加坡（Singapore）机房。

作为一个地处亚太核心枢纽的节点，该机房标配 1.5Gbps 超大带宽。官方的线路介绍是接入了 Equinix IX, Google, Cloudflare, RETN, NTT，并且针对中国大陆网络特别优化，标称包含了 China Mobile 和 CN2 GIA peering，实际测试目前是三网GIA。

价格方面，新加坡机房和大阪机房一样，基础套餐起步价为 $49.99/月，是 Ultra 系列价格最实惠的机房。

=== 主要测评内容： ===

* 测试机房：搬瓦工 Ultra VPS 系列（新加坡节点）
* 测试内容：硬件基准测试、国内主要节点网络简测、三网回程路由深度分析、流媒体解锁测试、24H延迟检测
* 覆盖网络：河南地区中国联通、中国移动、中国电信

=== 一、硬件配置与底层性能实测 ===
新加坡机房不仅继承了 Ultra 系列的性能优势，硬盘 I/O 更是达到了顶级水准。

=== 二、三网网络质量与延迟情况 ===
为了展现真实的网络情况，我们选取了国际网络较拥挤的晚上 21:15 左右（晚高峰）进行了网络质量和上下行吞吐量的探测，测试结果见下图。

==== 1. 晚高峰三网延迟表现 ====
根据测试数据，三大运营商的延迟呈现出分化：

中国电信：表现优异。全国平均延迟稳定在 65ms - 85ms 之间。其中，广东、海南等南方省份跑出了 45ms 左右的低延迟。

中国移动：表现良好。全国平均延迟在 70ms - 90ms 之间。南方省份表现较佳。

中国联通：延迟偏高。全国联通节点的平均延迟普遍在 110ms - 130ms 之间浮动。

延迟表现解析：

电信和移动用户访问该节点延迟较低，而联通偏高，这与搬瓦工在该机房采取的路由回程策略直接相关（具体分析见下文路由部分）。由于跨网交接需要额外路由跳数，导致联通用户的物理延迟相对增加。

=== 2. 极限网络吞吐实测 ===
我们通过脚本直接测试了晚高峰时段服务器到国内节点的上行发送速度。

电信节点：在对苏州电信和杭州电信节点测速时，发送速度分别达到 1038 Mbps 和 1146 Mbps。在晚高峰拥堵时段依然能跑满千兆带宽。

移动节点：在对苏州移动节点时，发送速度维持在 778 Mbps。移动宽带在晚高峰出海通常易受影响，此时能维持较高吞吐，证明了线路的高保障性。

=== 三、回程路由深度分析 ===
博主一般在中部地区，所以这里特别测试了河南地区的路由回程情况，目前结果来看，三网均为GIA，与官网的描述存在一些差别，不过GIA的线路质量稳定性会更好一些。

河南电信路由解析：

可以看到流量从新加坡机房发出后，直接接入中国电信 CTGNet 跨国骨干网（69.194.x.x），随后直达上海，无缝交接至中国电信 CN2 GIA（59.43）核心节点，最终抵达河南。全程走在电信自家的顶级通道上，延迟极低且 0 丢包。

附图：

河南联通路由解析：

可以看到流量从新加坡发出，同样接入 CTGNet 跨国骨干网，并在国内入口端（北京）被强制拉入电信 CN2 GIA（59.43）节点。在跨越最拥堵的国际出口段后，才在北京本地转交回中国联通骨干网（AS4837），最后抵达河南。

附图：

河南移动路由解析：

移动的回程策略与联通如出一辙。流量未走移动自家的 CMI 出口，而是经由新加坡 CTGNet 直达北京的电信 CN2 GIA（59.43）节点。享受完 VIP 级别的跨国传输后，在北京与中国移动骨干网（AS9808）进行交接，最终回到河南。

附图：

=== 四、三网延迟波动情况 ===
为了验证该机房在全天候的真实表现，我们在服务器上部署了探针，对河南联通、河南移动和河南电信进行了长达 24 小时的持续 Ping 监控。

从监控图表可以看出，由于回程强制接入电信 CN2 GIA（59.43）专线，三网在 24 小时内的延迟曲线平稳。在晚高峰时段（20:00 - 23:00），未出现大幅度的“延迟突增”或断流现象，丢包率控制良好；信和移动的延迟曲线维持在较低水位（约 60ms-80ms）；联通由于需要跨网交接，延迟曲线平行位于稍高的水位（约 110ms-120ms），但波动幅度与电信/移动保持一致。略逊于之前测试过的 Ultra 系列香港和东京机房。

=== 五、国际流媒体与 AI 平台解锁情况 ===
新加坡节点是东南亚流媒体和业务出海的重要位置。脚本测试的解锁情况如下：

测试结果解析：

由于搬瓦工使用了广播 IP，TikTok 的风控机制暂时将其识别为北美（加拿大）区域。但对于多数核心流媒体（奈飞、迪士尼）和 AI 平台（ChatGPT、Claude），系统主要看重实际物理出口，目前已识别为新加坡并解锁了当地原生内容，能够满足正常的区域业务需求。

=== 六、官方套餐配置与价格对比 ===
这款新加坡机房以 $49.99/月的起步价，提供了 1.5Gbps 的带宽以及三网强制 CN2 GIA 回程优化（不排除以后会变为三网优化）。

=== 七、 Ultra 系列新加坡节点选购总结与建议 ===

==== 1.购买建议 ====
经过实测，这款新加坡 Ultra VPS 的特性总结如下：

三网统一回程策略：虽然联通和移动用户在国内需要跨网交接，但保障了晚高峰的稳定连通性，24 小时延迟曲线表现平稳。

硬件性能充裕：超过 11GB/s 的硬盘连续读取速度，适合对 I/O 突发要求较高的应用场景（不可长期负载）。

选购建议：如果您的业务面向东南亚地区、需要解锁新加坡原生 AI 与影音服务（TikTok 除外），且对晚高峰网络稳定性有较高要求，这款 $49.99/月的机型具备较强的性价比。

==== 2.官方购买路径 ====
访问官网：建议直接使用搬瓦工官方运营的国内镜像站进入选购页面（点击直达）：https://bwh81.net/aff.php?aff=30918

定位套餐：在网页导航栏选择 "VPS Hosting"，找到名称带有 “Ultra VPS” 标签的方案，选择 Singapore 机房与对应配置，点击 "Order Now"。

确认订单：在购物车界面，确认套餐无误，点击 Checkout 确认订单，如果没有账号，系统会引导您使用邮箱注册。

完成支付：订单确认完毕后，会让你确认支付信息，点击 Make payment 可支付，目前支持 Alipay（支付宝）扫码支付。部署完成后，服务器 IP 和 Root 密码将发送至注册邮箱。

使用搬瓦工KiwiVM AI助手Amy测评Ultra系列新加坡SG 8机房CN2 GIA VPS并输出测评文章

GWVPSCEPING.COM — Wed, 17 Jun 2026 07:37:02 GMT

@@ 第55行： / 第55行： @@
 |}
-; [[File:Amy.jpg|frameless|707x707px]]
+; [[File:Image-bwg.png|border]]
 此次与Amy的对话录屏视频：<nowiki>https://youtu.be/03GvvzlMSoQ</nowiki>
 如访问不了，也可查看B站视频：<nowiki>https://www.bilibili.com/video/BV1yFj564ECa/</nowiki>
 Amy输出的测评文章正文：

使用搬瓦工KiwiVM AI助手Amy测评Ultra系列新加坡SG 8机房CN2 GIA VPS并输出测评文章

GWVPSCEPING.COM — Tue, 16 Jun 2026 21:02:25 GMT

创建页面，内容为“我们在文章《搬瓦工AI助手[Assistant Amy]使用指南：10个最实用的新手场景，SSH、建站、测速都能直接问》和《搬瓦工KiwiVM AI助手Amy全面升级：支持中文指令，一句话即可安装Docker与管理VPS》就介绍了搬瓦工KiwiVM AI助手Amy，但也只停留在理论介绍阶段，本文以一个测评老登的业务场景为例来实操使用Assistant Amy过程，来看看如何使用搬瓦工KiwiVM AI助手Amy测…”

新页面

我们在文章《搬瓦工AI助手[Assistant Amy]使用指南：10个最实用的新手场景，SSH、建站、测速都能直接问》和《搬瓦工KiwiVM AI助手Amy全面升级：支持中文指令，一句话即可安装Docker与管理VPS》就介绍了搬瓦工KiwiVM AI助手Amy，但也只停留在理论介绍阶段，本文以一个测评老登的业务场景为例来实操使用Assistant Amy过程，来看看如何使用搬瓦工KiwiVM AI助手Amy测评Ultra系列新加坡SG_8机房CN2 GIA VPS并输出测评文章。本文将附上和Amy的对话录屏视频和Amy输出的测评文章供大家参考。

搬瓦工官网：<nowiki>https://bandwagonhost.com/</nowiki>

搬瓦工新加坡SG_8 VPS套餐配置，所有方案均采用 KVM 虚拟化并提供独立 IPv4。
{| class="wikitable"
!CPU
!内存
!SSD硬盘
!月流量
!带宽
!价格
|-
|2核
|2GB
|40GB SSD
|500GB
|1.5Gbps
|49.99美元/月 [https://bandwagonhost.com/order/ultra/Singapore 点此入手]
|-
|4核
|4GB
|80GB SSD
|1TB
|1.5Gbps
|86.99美元/月 [https://bandwagonhost.com/order/ultra/Singapore 点此入手]
|-
|6核
|8GB
|160GB SSD
|2TB
|2.5Gbps
|165.99美元/月 [https://bandwagonhost.com/order/ultra/Singapore 点此入手]
|-
|8核
|16GB
|320GB SSD
|4TB
|2.5Gbps
|329.99美元/月 [https://bandwagonhost.com/order/ultra/Singapore 点此入手]
|-
|10核
|32GB
|640GB SSD
|6TB
|5Gbps
|549.99美元/月 [https://bandwagonhost.com/order/ultra/Singapore 点此入手]
|-
|12核
|64GB
|1TB SSD
|8TB
|5Gbps
|1059.99美元/月 [https://bandwagonhost.com/order/ultra/Singapore 点此入手]
|}

; [[File:Amy.jpg|frameless|707x707px]]
: Assistant Amy在KiwiVM上的位置

此次与Amy的对话录屏视频：<nowiki>https://youtu.be/03GvvzlMSoQ</nowiki>

如访问不了，也可查看B站视频：<nowiki>https://www.bilibili.com/video/BV1yFj564ECa/</nowiki>

Amy输出的测评文章正文：

= BandwagonHost 新加坡 SG_8 VPS 测评：AMD EPYC Genoa、KVM、IPv6、BBR 与综合性能实测 =
本文对一台 BandwagonHost / 搬瓦工新加坡 SG_8 机房 VPS 进行实测，测试内容包括基础配置、CPU、内存、磁盘 I/O、OpenSSL 加密性能、sysbench、UnixBench、IPv4 / IPv6、BBR、Speedtest、回程路由、流媒体与 AI 平台解锁等。

本次测试坚持一个原则：能实测的就给出实测数据，不能从本机直接测出的内容不做杜撰。因此，本文中的路由、Ping、MTR 等结果主要代表 VPS 出站方向表现，不等同于中国大陆用户访问该 VPS 的去程体验。

测试时间：2026-06-16

测试系统：Ubuntu 22.04.5 LTS
----

== 一、套餐配置 ==
{| class="wikitable"
!项目
!配置
|-
|商家
|BandwagonHost / 搬瓦工
|-
|面板
|KiwiVM
|-
|机房
|新加坡 SG_8
|-
|虚拟化
|KVM
|-
|CPU
|6 核 AMD EPYC Genoa
|-
|内存
|8GB
|-
|Swap
|1GB
|-
|硬盘
|160GB
|-
|月流量
|2TB
|-
|IPv4
|1 个
|-
|IPv6
|/64
|-
|系统
|Ubuntu 22.04
|-
|BBR
|已开启
|-
|购买链接
|点击购买
|}
----

== 二、测试环境与基础信息 ==
本次测试机器位于 BandwagonHost 新加坡 SG_8 机房，面板显示为 KVM 虚拟化。
{| class="wikitable"
!项目
!结果
|-
|当前机房
|SG_8
|-
|地理位置
|Singapore
|-
|虚拟化
|KVM
|-
|操作系统
|Ubuntu 22.04.5 LTS
|-
|内核版本
|5.15.0-179-generic
|-
|CPU 型号
|AMD EPYC-Genoa Processor
|-
|CPU 核心
|6 vCPU
|-
|内存
|约 8GB
|-
|Swap
|1GB
|-
|磁盘
|160GB
|-
|根分区
|约 157GB
|-
|IPv4
|185.180.17.112
|-
|IPv6 子网
|2607:8700:360:7b93::/64
|-
|已配置 IPv6
|2607:8700:360:7b93::2
|-
|SSH 端口
|22
|-
|CPU 限速状态
|未限速
|-
|磁盘 I/O 限速状态
|未限速
|}
系统负载较低：
load average: 0.00, 0.14, 0.16
内存情况如下：
Mem: 7.8Gi total, 7.5Gi available
Swap: 1.0Gi total, 0 used
磁盘分区情况：
/dev/sda2 157G mounted on /
----

== 三、CPU 信息 ==
CPU 识别为 AMD EPYC Genoa 系列：
AMD EPYC-Genoa Processor
核心信息如下：
{| class="wikitable"
!项目
!结果
|-
|架构
|x86_64
|-
|核心数
|6
|-
|Thread per core
|1
|-
|L3 Cache
|32 MiB
|-
|AES 指令集
|支持
|-
|SHA-NI
|支持
|-
|AVX2
|支持
|}
lscpu 中可以看到 CPU 支持 AES、AVX、AVX2、SHA-NI 等指令：
aes avx avx2 sha_ni
这类指令对 TLS、代理、VPN、压缩校验、加密传输等场景比较有帮助。

== 三、CPU 信息 ==
CPU 识别为 AMD EPYC Genoa 系列：
AMD EPYC-Genoa Processor
核心信息如下：
{| class="wikitable"
!项目
!结果
|-
|架构
|x86_64
|-
|核心数
|6
|-
|Thread per core
|1
|-
|L3 Cache
|32 MiB
|-
|AES 指令集
|支持
|-
|SHA-NI
|支持
|-
|AVX2
|支持
|}
lscpu 中可以看到 CPU 支持 AES、AVX、AVX2、SHA-NI 等指令：
aes avx avx2 sha_ni
这类指令对 TLS、代理、VPN、压缩校验、加密传输等场景比较有帮助。
----

== 四、sysbench CPU 基础测试 ==
首先使用 sysbench cpu 进行基础 CPU 测试。

测试参数：
sysbench cpu
单线程 / 6 线程
运行 10 秒
测试结果如下：
{| class="wikitable"
!测试项目
!结果
|-
|单线程
|4346.87 events/s
|-
|6 线程
|25591.13 events/s
|}
多线程成绩约为单线程的 5.89x，6 核扩展表现比较正常。
----

== 五、sysbench CPU 扩展测试 ==
进一步使用 sysbench cpu --cpu-max-prime=20000 进行扩展测试。

测试参数：
sysbench cpu --cpu-max-prime=20000
运行时间：15 秒
线程数：1 / 2 / 4 / 6
结果如下：
{| class="wikitable"
!线程数
!events/s
!总事件数
!平均延迟
!95% 延迟
|-
|1 线程
|1677.38
|25162
|0.60 ms
|0.61 ms
|-
|2 线程
|3356.98
|50358
|0.60 ms
|0.61 ms
|-
|4 线程
|6504.94
|97581
|0.61 ms
|0.70 ms
|-
|6 线程
|8833.82
|132518
|0.68 ms
|1.23 ms
|}
从结果看，1 到 2 线程基本接近线性扩展，1 到 6 线程约为 5.27x。满线程下 95% 延迟升至 1.23 ms，属于多线程压力下的正常表现。
----

== 六、OpenSSL 加密性能测试 ==
使用 OpenSSL EVP 模式测试 AES-GCM 与 SHA 性能。

=== AES-128-GCM ===
{| class="wikitable"
!Block
!速度
|-
|16 bytes
|621711.60k
|-
|64 bytes
|1640692.29k
|-
|256 bytes
|3342921.30k
|-
|1024 bytes
|4387683.67k
|-
|8192 bytes
|4910156.46k
|-
|16384 bytes
|4929721.69k
|}

=== AES-256-GCM ===
{| class="wikitable"
!Block
!速度
|-
|16 bytes
|502461.25k
|-
|64 bytes
|1476285.76k
|-
|256 bytes
|3027226.45k
|-
|1024 bytes
|3960716.29k
|-
|8192 bytes
|4478588.25k
|-
|16384 bytes
|4545981.10k
|}

=== SHA256 ===
{| class="wikitable"
!Block
!速度
|-
|16 bytes
|127648.37k
|-
|64 bytes
|395713.28k
|-
|256 bytes
|960671.57k
|-
|1024 bytes
|1512257.19k
|-
|8192 bytes
|1833061.03k
|-
|16384 bytes
|1861227.86k
|}

=== SHA512 ===
{| class="wikitable"
!Block
!速度
|-
|16 bytes
|55162.65k
|-
|64 bytes
|218817.41k
|-
|256 bytes
|436736.00k
|-
|1024 bytes
|702727.17k
|-
|8192 bytes
|843052.37k
|-
|16384 bytes
|869384.19k
|}
AES-GCM 性能较强，说明这颗虚拟 CPU 在加密传输、HTTPS、代理、VPN 等场景下有不错的基础性能。
----

== 七、内存性能测试 ==
使用 sysbench memory 进行内存读写测试。

=== 内存写入测试 ===
sysbench memory
memory-total-size=10G
memory-block-size=1K
memory-oper=write
{| class="wikitable"
!线程数
!写入速度
|-
|1 线程
|6650.09 MiB/s
|-
|2 线程
|4660.06 MiB/s
|-
|4 线程
|5225.49 MiB/s
|-
|6 线程
|5684.44 MiB/s
|}

=== 内存读取测试 ===
sysbench memory
memory-total-size=10G
memory-block-size=1K
memory-oper=read
{| class="wikitable"
!线程数
!读取速度
|-
|1 线程
|7674.82 MiB/s
|-
|2 线程
|11207.51 MiB/s
|-
|4 线程
|19452.35 MiB/s
|-
|6 线程
|24696.43 MiB/s
|}
内存读取随线程增加提升明显，6 线程读取达到 24696.43 MiB/s。写入部分多线程没有线性提升，可能与虚拟化调度、缓存行为和 sysbench 测试模型有关。
----

== 八、线程调度与 Mutex 测试 ==

=== Threads 测试 ===
sysbench threads
thread-yields=1000
thread-locks=8
运行时间：15 秒
{| class="wikitable"
!线程数
!总事件数
!平均延迟
!95% 延迟
|-
|1 线程
|14873
|1.01 ms
|1.89 ms
|-
|2 线程
|27948
|1.07 ms
|1.96 ms
|-
|4 线程
|36367
|1.65 ms
|3.75 ms
|-
|6 线程
|44054
|2.04 ms
|6.21 ms
|}

=== Mutex 测试 ===
sysbench mutex
mutex-num=4096
mutex-locks=50000
mutex-loops=10000
{| class="wikitable"
!线程数
!总耗时
!平均延迟
|-
|1 线程
|0.1412s
|141.12 ms
|-
|2 线程
|0.1495s
|148.46 ms
|-
|4 线程
|0.1695s
|160.99 ms
|-
|6 线程
|0.1908s
|175.29 ms
|}
----

== 九、磁盘基础信息 ==
磁盘识别为 QEMU 虚拟磁盘：
QEMU HARDDISK
{| class="wikitable"
!项目
!结果
|-
|/dev/sda
|160G
|-
|/dev/sda2
|158.6G mounted on /
|}
系统内根分区约为 157GB 可用空间。
----

== 十、磁盘延迟测试 ==
使用 ioping 测试磁盘延迟。

普通 ioping 结果：
min/avg/max/mdev = 270.6 us / 322.8 us / 376.0 us / 27.6 us
快速随机读模式结果：
min/avg/max/mdev = 134.5 us / 140.3 us / 150.1 us / 5.13 us
从延迟看，磁盘响应较快，随机读延迟也比较低。
----

== 十一、fio 磁盘 I/O 测试 ==
使用 fio 进行轻量磁盘 I/O 测试。

测试参数概况：
测试文件大小：512MB
测试时长：每项 20 秒
I/O 模式：direct I/O
{| class="wikitable"
!项目
!结果
|-
|顺序写入
|4144 MiB/s
|-
|顺序读取
|1701 MiB/s
|-
|4K 随机读
|7020 IOPS / 27.4 MiB/s
|-
|4K 随机写
|10.5k IOPS / 40.8 MiB/s
|-
|4K 混合读写，70% 读
|读 5386 IOPS / 写 2305 IOPS
|}
磁盘顺序写入与读取成绩都比较高，4K 随机读写也有不错表现。需要注意的是，本次 fio 为短时间轻量测试，适合作为参考，不代表长时间持续满载下的表现。

测试结束后复查 KiwiVM 状态：
CPU Limited due to overusage: NO
Disk IO Limited due to overusage: NO
未触发 CPU 或磁盘 I/O 限速。

== 十二、BBR 与网络栈状态 ==
本机已开启 BBR，拥塞控制算法和队列算法如下：
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_available_congestion_control = reno cubic bbr
net.core.default_qdisc = fq
相关内核模块已加载：
tcp_bbr
sch_fq
BBR 配置已持久化，重启后仍会保持开启状态。对于 TCP 传输、代理、建站、跨境访问等场景，BBR 可以在一定程度上改善拥塞环境下的传输表现。
----

== 十三、IPv4 / IPv6 配置 ==

=== IPv4 信息 ===
当前 IPv4 地址为：
185.180.17.112
IPv4 网关：
185.180.16.1
接口信息：
185.180.17.112/22

=== IPv6 信息 ===
当前分配的 IPv6 /64 子网为：
2607:8700:360:7b93::/64
系统中配置的 IPv6 地址为：
2607:8700:360:7b93::2
IPv6 通过 SIT 隧道方式接入：
sit1@NONE
local IPv4: 185.180.17.112
remote endpoint: 139.180.140.218
IPv6 默认路由：
default dev sit1
IPv6 服务状态：
ipv6net.service active exited
IPv4 与 IPv6 均已配置完成，SSH 在 IPv4 与 IPv6 上均可访问。
----

== 十四、公网可达性 ==
从外部公网探针检查，IPv4 与 IPv6 均可达。
{| class="wikitable"
!项目
!结果
|-
|IPv4 Ping
|可达，0% 丢包
|-
|IPv4 SSH 22
|可连接
|-
|IPv6 Ping
|可达，0% 丢包
|-
|IPv6 SSH 22
|可连接
|-
|IPv4 PTR
|有 PTR
|-
|IPv6 PTR
|有 PTR
|}
PTR 记录如下：
185.180.17.112 -> 185.180.17.112.16clouds.com
2607:8700:360:7b93::2 -> 2607-8700-0360-7b93-0000-0000-0000-0002.16clouds.com
说明这台机器的 IPv4 / IPv6 基础公网连通性正常。
----

== 十五、VPS 到海外目标延迟 ==
以下测试为 VPS 出站方向，即：
VPS -> 目标
不代表用户访问 VPS 的去程延迟。
{| class="wikitable"
!目标
!丢包
!平均延迟
|-
|网关 185.180.16.1
|0%
|16.821 ms
|-
|Cloudflare 1.1.1.1
|0%
|0.829 ms
|-
|Google DNS 8.8.8.8
|0%
|0.239 ms
|-
|Quad9 9.9.9.9
|0%
|0.385 ms
|-
|IPv6 Cloudflare
|0%
|2.680 ms
|-
|IPv6 Google DNS
|0%
|1.540 ms
|}
可以看到，到新加坡本地的 Google、Cloudflare、Quad9 等目标延迟非常低。
----

== 十六、VPS 到中国大陆方向延迟与丢包 ==
以下测试同样是：
VPS -> 中国大陆目标
也就是 VPS 出站/回程方向，不代表中国大陆用户访问该 VPS 的去程。
{| class="wikitable"
!目标
!说明
!丢包
!平均延迟
|-
|223.5.5.5
|阿里 DNS
|0%
|65.242 ms
|-
|119.29.29.29
|DNSPod
|0%
|45.726 ms
|-
|202.96.209.133
|上海电信 DNS
|0%
|65.589 ms
|-
|202.96.128.86
|广东电信 DNS
|0%
|45.860 ms
|-
|123.125.81.6
|北京联通方向
|0%
|103.031 ms
|-
|211.136.112.200
|上海移动 DNS
|0%
|73.629 ms
|-
|120.196.165.24
|广东移动方向
|0%
|46.107 ms
|-
|114.114.114.114
|114 DNS
|100%
|目标 ICMP 无响应
|-
|210.22.84.3
|上海联通 DNS
|100%
|目标 ICMP 无响应
|}
其中 114.114.114.114 和 210.22.84.3 未响应 ICMP，不一定代表 TCP / UDP 服务不可达，也可能是目标侧限制 ICMP 或中间设备不回包。
----

== 十七、Ookla Speedtest 测速 ==
使用 Ookla Speedtest 进行测速。由于本机 speedtest-cli 可选节点主要集中在新加坡附近，本次成功跑通的是新加坡 MyRepublic 节点。
{| class="wikitable"
!节点
!Ping
!下载
!上传
|-
|Singapore / MyRepublic
|1.064 ms
|20581.06 Mbps
|14648.39 Mbps
|}
这个结果非常高，属于同城多线程测速节点的峰值表现。它更适合作为新加坡本地网络能力参考，不建议直接等同于所有地区、所有时间段的真实访问速度。
----

== 十八、多地区 100MB 下载测速 ==
为了补充 Speedtest 节点不足的问题，另外使用多个地区的公开测试文件进行 100MB 下载测速。

该测试代表：
测试源 -> VPS
也就是 VPS 从这些地区下载文件的速度，不能直接等同于用户访问 VPS 的速度。
{| class="wikitable"
!测试源
!HTTP
!文件大小
!平均速度
!约 Mbps
|-
|Singapore Linode
|200
|100MB
|363.45 MiB/s
|3048.86 Mbps
|-
|Tokyo Linode
|200
|100MB
|31.98 MiB/s
|268.25 Mbps
|-
|Singapore Vultr
|200
|100MB
|38.82 MiB/s
|325.66 Mbps
|-
|Tokyo Vultr
|200
|100MB
|33.78 MiB/s
|283.35 Mbps
|-
|Los Angeles Vultr
|200
|100MB
|14.05 MiB/s
|117.90 Mbps
|-
|London Vultr
|200
|100MB
|15.03 MiB/s
|126.07 Mbps
|-
|Frankfurt Vultr
|200
|100MB
|13.20 MiB/s
|110.75 Mbps
|-
|Sydney Vultr
|200
|100MB
|24.37 MiB/s
|204.44 Mbps
|-
|New Jersey Vultr
|测试失败
| -
| -
| -
|}
从结果看，新加坡本地下载速度最高，东京方向约 268–283 Mbps，欧美方向大约 110–126 Mbps，悉尼约 204 Mbps。
----

== 十九、测速流量消耗与状态 ==
测速前月流量已用约：
1016 MB
测速后月流量已用约：
2979 MB
本轮测速新增消耗约：
1963 MB
也就是约 1.9GB。

测速后复查 VPS 状态：
{| class="wikitable"
!项目
!状态
|-
|VPS
|RUNNING
|-
|CPU 限速
|NO
|-
|磁盘 I/O 限速
|NO
|-
|Nullroute
|无
|-
|Policy violation
|无
|-
|SSH
|正常
|-
|IPv4 / IPv6
|正常
|}

== 十七、回程路由观察 ==

=== 到阿里 DNS 223.5.5.5 ===
MTR 最终目标 0% 丢包，平均延迟约 65 ms。

路由中出现：
SG.SGP.CTGNet
CN.HKG.CTGNet
CTCN2.CN.SHA.CTGNet
59.43.x.x
说明该方向经过 CTGNet / 59.43 段进入中国大陆，路径特征接近电信 CN2 方向。
----

=== 到 DNSPod 119.29.29.29 ===
最终目标 0% 丢包，平均延迟约 45.8 ms。

路径中同样出现：
SG.SGP.CTGNet
CN.HKG.CTGNet
CTCN2.CN.HKG.CTGNet
59.43.x.x
后续进入广东方向。
----

=== 到上海电信 202.96.209.133 ===
最终目标 0% 丢包，平均延迟约 65.6 ms。

路径包含：
CTGNet
CTCN2.CN.SHA.CTGNet
59.43.x.x
101.95.x.x
----

=== 到广东电信 202.96.128.86 ===
最终目标 0% 丢包，平均延迟约 45.9 ms。

路径包含：
CTGNet
CTCN2.CN.HKG.CTGNet
59.43.x.x
202.97.x.x
----

=== 到北京联通 123.125.81.6 ===
最终目标 0% 丢包，平均延迟约 103.1 ms。

路径先经过 CTGNet / 59.43，后续进入联通网络：
219.158.x.x
----

=== 到上海移动 211.136.112.200 ===
最终目标 0% 丢包，平均延迟约 68.5 ms。

路径先经过 CTGNet / 59.43，后续进入移动骨干：
221.183.x.x
----

=== 到广东移动 120.196.165.24 ===
最终目标 0% 丢包，平均延迟约 46.1 ms。

路径同样先经过 CTGNet / 59.43，后续进入移动骨干。
----

=== 关于 MTR 中间节点丢包说明 ===
MTR 中部分中间跳可能显示较高丢包，例如 CTGNet、59.43、221.183 某些节点。但多个最终目标显示 0% 丢包，因此这些中间跳丢包更可能是 ICMP 限速或中间节点不优先响应，不应直接理解为真实业务丢包。
----

== 二十一、流媒体与 AI 平台解锁测试 ==
本次使用两个常见第三方检测脚本交叉参考：
lmc999/RegionRestrictionCheck
1-stream/RegionRestrictionCheck
需要说明的是，流媒体和 AI 平台检测结果会受到平台策略、IP 库、风控系统和检测脚本逻辑影响，结果仅代表测试时间点表现。

测试时间：
2026-06-16 17:32–17:37 UTC
----

== 二十二、IPv4 流媒体解锁结果 ==
IPv4 网络识别：
AS25820 IT7 Networks / IT7 Networks Inc
{| class="wikitable"
!平台 / 项目
!IPv4 结果
|-
|Disney+
|Yes，Region: SG
|-
|Netflix
|Yes，Region: SG
|-
|Netflix Preferred CDN
|Singapore
|-
|YouTube Premium
|Yes，Region: SG
|-
|Amazon Prime Video
|Yes，Region: SG
|-
|Dazn
|Yes，Region: SG
|-
|HBO Max
|Yes，Region: SG
|-
|TVBAnywhere+
|Yes / Region SG
|-
|iQiyi Oversea
|SG / Yes Region SG
|-
|Viu.com
|Yes，Region SG
|-
|TikTok
|Yes，Region SG
|-
|Spotify
|脚本结果不一致（Registration No / Spotify SG）
|-
|Steam Currency
|SGD
|-
|Google Play Store
|Singapore
|-
|Google Search CAPTCHA Free
|Yes
|-
|Bing Region
|SG，Risky
|-
|Apple Region
|SG
|-
|Reddit
|Yes
|-
|Wikipedia Editability
|No / Yes（脚本不一致）
|}
整体来看，IPv4 在多数主流平台中被识别为新加坡区域，Netflix、Disney+、YouTube Premium、Amazon Prime Video、Dazn、HBO Max、TikTok 等均显示可用。
----

== 二十三、IPv4 AI 平台检测结果 ==
{| class="wikitable"
!平台
!IPv4 结果
|-
|ChatGPT
|Yes，Region: SG
|-
|Google Gemini
|Yes，Region: SGP / Singapore
|-
|Claude
|Yes
|-
|Sora
|Yes，Region: SG
|-
|Microsoft Copilot
|No / Region 空
|}
从测试结果看，ChatGPT、Gemini、Claude、Sora 在 IPv4 下均显示可用，区域多为新加坡。
----

== 二十四、IPv6 流媒体解锁结果 ==
IPv6 网络识别：
AS25820 IT7 Networks Inc
{| class="wikitable"
!平台 / 项目
!IPv6 结果
|-
|Disney+
|IPv6 不支持 / Yes SG（脚本冲突）
|-
|Netflix
|Yes，Region: SG
|-
|Netflix Preferred CDN
|Singapore
|-
|YouTube Premium
|Yes，Region: SG
|-
|YouTube CDN
|Singapore
|-
|Google Location
|Singapore
|-
|Google Play / Search
|Singapore / CAPTCHA Free Yes
|-
|Spotify
|SG
|-
|HBO Max
|Yes，Region SG
|-
|Apple Region
|SG
|-
|Steam
|IPv6 不支持
|-
|Reddit
|IPv6 不支持
|}
IPv6 下 Netflix、YouTube Premium、Google、HBO Max 等显示新加坡区域，但部分平台或脚本提示 IPv6 不支持，不一定代表 IPv6 网络不可用。
----

== 二十五、IPv6 AI 平台检测结果 ==
{| class="wikitable"
!平台
!IPv6 结果
|-
|ChatGPT
|Failed / Yes（脚本不一致）
|-
|Google Gemini
|Yes / Singapore
|-
|Claude
|Yes
|-
|Sora
|Yes，Region SG
|-
|Microsoft Copilot
|No
|}
IPv6 下 Gemini、Claude、Sora 显示可用，ChatGPT 结果不一致，仅供参考。
----

== 二十六、地区平台补充观察 ==

=== 新加坡 / 东南亚平台 ===
{| class="wikitable"
!平台
!结果
|-
|meWATCH
|Yes
|-
|CatchPlay+
|Yes，Region SG
|-
|Starhub TV+
|No
|-
|HBO Max
|Yes
|-
|Viu.com
|Yes
|-
|TikTok
|Yes
|-
|Clip TV / MYTV
|Yes
|-
|Galaxy Play / K+
|No
|-
|AIS Play / Vidio / beIN Sports
|No / Fail
|}

=== 港台平台 ===
{| class="wikitable"
!平台
!结果
|-
|KKTV
|No
|-
|MyVideo
|No
|-
|Hami Video
|No
|-
|Bahamut Anime
|No / Failed
|-
|Bilibili Taiwan
|No
|-
|Viu.TV
|No
|-
|MyTVSuper
|No
|-
|Now E
|Failed
|}

=== 日本平台 ===
{| class="wikitable"
!平台
!结果
|-
|DMM / DMM TV
|No
|-
|Abema.TV
|No
|-
|Hulu Japan
|No
|-
|TVer
|Failed
|-
|WOWOW
|No
|-
|D Anime Store
|IPv4 No / IPv6 Yes（冲突）
|-
|Project Sekai
|Yes
|-
|Kancolle
|Failed / Yes（冲突）
|-
|Niconico
|Failed / Yes（冲突）
|}

=== 北美平台 ===
{| class="wikitable"
!平台
!结果
|-
|Hulu
|No
|-
|ESPN+
|No
|-
|Peacock TV
|No
|-
|Paramount+
|No
|-
|Discovery+
|No
|-
|Crunchyroll
|No
|-
|FOX / FXNOW
|Yes
|-
|NBA TV
|Yes
|-
|Sling TV
|Yes / No（冲突）
|-
|Fubo TV
|Yes / Failed
|-
|Pluto TV
|Yes / No
|-
|Directv Stream
|Yes / No
|}

== 二十七、UnixBench 测试 ==
Geekbench 未能生成有效分数后，进一步使用 UnixBench 作为综合性能补充。

UnixBench 版本：
BYTE UNIX Benchmarks Version 6.0.1
测试环境：
6 CPUs in system
Ubuntu 22.04.5 LTS
AMD EPYC-Genoa Processor
最终结果如下：
{| class="wikitable"
!项目
!分数
|-
|1 parallel copy
|1003.2
|-
|6 parallel copies
|5260.6
|}
关键输出：
BYTE UNIX Benchmarks (Version 6.0.1)

6 CPUs in system; running 1 parallel copy of tests
System Benchmarks Index Score: 1003.2

6 CPUs in system; running 6 parallel copies of tests
System Benchmarks Index Score: 5260.6
多核分数约为单副本的 5.24x，与前文 sysbench 多线程扩展结果接近，整体扩展表现正常。

UnixBench 单副本部分分项如下：
{| class="wikitable"
!项目
!结果
!Index
|-
|Dhrystone 2
|50387404.0 lps
|4317.7
|-
|Whetstone
|9204.9 MWIPS
|1673.6
|-
|Execl Throughput
|2628.5 lps
|611.3
|-
|File Copy 1024
|429454.5 KB/s
|1084.5
|-
|File Copy 256
|110195.5 KB/s
|665.8
|-
|File Copy 4096
|1475321.1 KB/s
|2543.7
|-
|Pipe Throughput
|542925.6 lps
|436.4
|-
|Context Switching
|47107.5 lps
|117.8
|-
|Process Creation
|5856.3 lps
|464.8
|-
|Shell Scripts 1 concurrent
|11286.7 lpm
|2662.0
|-
|Shell Scripts 8 concurrent
|4069.5 lpm
|6782.5
|-
|System Call Overhead
|445564.4 lps
|297.0
|}
----

== 二十八、Geekbench 测试说明 ==
本次尝试运行 Geekbench 6.4.0，测试流程已经完整跑完，包括：
Single-Core
Multi-Core
Geekbench 识别到的硬件信息如下：
{| class="wikitable"
!项目
!结果
|-
|Geekbench 版本
|6.4.0
|-
|系统
|Ubuntu 22.04.5 LTS
|-
|内核
|Linux 5.15.0-179-generic
|-
|机型
|Red Hat KVM
|-
|CPU
|AMD EPYC-Genoa Processor
|-
|核心
|1 Processor, 6 Cores
|-
|基础频率
|2.94 GHz
|-
|内存
|7.81 GB
|-
|指令集
|SSE / AES-NI / AVX / AVX2 / SHA-NI
|}
但最终上传到 Geekbench Browser 时失败：
Uploading results to the Geekbench Browser...
unknown error (internal code 35)
进一步检查发现，访问 browser.geekbench.com 时被 Cloudflare Challenge 拦截：
HTTP/2 403
cf-mitigated: challenge
server: cloudflare
因此本次没有生成 Geekbench 公开分数链接，也没有有效本地分数文件。为避免误导，本文不提供 Geekbench 分数。
----

== 二十九、IP 归属与地理库差异 ==

=== ASN / 组织信息 ===
Team Cymru DNS 查询显示：
AS25820
185.180.16.0/22
ipinfo 返回：
AS25820 IT7 Networks Inc
ARIN Whois 显示：
NetRange: 185.180.16.0 - 185.180.19.255
Organization: Cluster Logic Inc
Country: CA / US
IPv6 Whois：
2607:8700::/32
Organization: IT7 Networks Inc
Country: CA

=== 地理位置数据库差异 ===
{| class="wikitable"
!来源
!IPv4 地理结果
|-
|KiwiVM 面板
|Singapore
|-
|ipinfo.io
|Singapore
|-
|ifconfig.co
|United States / Los Angeles
|-
|ARIN Whois
|CA / US 归属信息
|}
{| class="wikitable"
!来源
!IPv6 地理结果
|-
|KiwiVM 面板
|Singapore
|-
|ifconfig.co
|Canada
|}
因此，这段 IP 在不同数据库中的地理位置并不完全统一。更稳妥的说法是：面板与部分 IP 库显示新加坡，但部分第三方数据库仍显示美国或加拿大归属，具体以目标平台识别为准。

=== PTR 记录 ===
185.180.17.112.16clouds.com
2607-8700-0360-7b93-0000-0000-0000-0002.16clouds.com
当前 KiwiVM 自定义 PTR 为空，但上游默认 PTR 存在。
----

== 三十、DNSBL 黑名单简查 ==
{| class="wikitable"
!DNSBL
!结果
|-
|bl.spamcop.net
|未发现列入
|-
|b.barracudacentral.org
|未发现列入
|-
|dnsbl.sorbs.net
|未发现列入
|-
|psbl.surriel.com
|未发现列入
|-
|spam.dnsbl.sorbs.net
|未发现列入
|-
|Spamhaus Zen
|open resolver（无效结果）
|}
Spamhaus 返回：
Error: open resolver
这不是该 IP 被列入黑名单的有效证据，而是 DNS 查询源或解析器被 Spamhaus 限制。因此不计入黑名单结论。
----

== 三十一、系统服务与安全状态 ==
当前没有 failed systemd 服务：
0 loaded units listed.
{| class="wikitable"
!服务
!状态
|-
|ssh
|active running
|-
|ipv6net
|active exited
|-
|networking
|active exited
|-
|chrony
|active running
|-
|qemu-guest-agent
|active running
|}
当前开放端口：
TCP 22 IPv4
TCP 22 IPv6
DNS stub 127.0.0.53
DHCP client UDP 68
chrony localhost UDP 323
防火墙规则：
iptables 默认 ACCEPT
ip6tables 默认 ACCEPT
SSH 配置：
PasswordAuthentication yes
PermitRootLogin yes
Port 22
建议后续安全加固：

# 修改 SSH 端口
# 使用 SSH key 登录
# 关闭 root 密码登录
# 配置基础防火墙
# 安装 fail2ban

== 三十二、宝塔建站适用性分析 ==
本次没有安装宝塔面板，也没有进行宝塔 LNMP / WordPress 实测。原因是宝塔安装会改变当前干净系统环境，并安装 Nginx、PHP、MySQL、面板服务等组件，可能影响纯 VPS 测评结果。

不过从本次实测数据来看，这台机器用于常规建站有比较好的基础条件：
{| class="wikitable"
!项目
!表现
|-
|CPU
|6 核 AMD EPYC Genoa，sysbench 与 UnixBench 表现正常
|-
|内存
|8GB 内存，适合中小型站点、WordPress、轻量数据库
|-
|磁盘
|fio 顺序读写和随机 I/O 表现较好
|-
|网络
|IPv4 / IPv6 均可用，BBR 已开启
|-
|建站环境
|Ubuntu 22.04，适合安装 Nginx、PHP、MySQL、Redis 等组件
|}
如果用于 WordPress、Typecho、Halo、静态站点、API 服务或中小型企业站，硬件性能层面基本足够。

如果后续要专门评估宝塔建站性能，建议单独进行一轮 LNMP / WordPress 实测，包括：

* 宝塔安装后空载内存占用
* Nginx 静态页面 QPS
* PHP-FPM 动态页面性能
* MySQL 简单读写性能
* WordPress 首页并发测试
* 开启缓存前后对比

这样结果会更贴近真实建站场景。
----

== 三十三、测试后状态复查 ==
{| class="wikitable"
!项目
!状态
|-
|VPS
|RUNNING
|-
|CPU 限速
|NO
|-
|磁盘 I/O 限速
|NO
|-
|系统负载
|正常
|-
|SSH
|正常
|-
|IPv4
|正常
|-
|IPv6
|正常
|-
|failed systemd 服务
|0
|-
|Nullroute
|无
|-
|Policy violation
|无
|}
本轮测试未导致 VPS 异常，也未触发 CPU 或磁盘 I/O 限速。
----

== 三十四、适合用途 ==
结合本次测试结果，这台 BandwagonHost 新加坡 SG_8 VPS 比较适合：

* 轻中度建站
* WordPress / Typecho / Halo 等博客程序
* 静态网站
* API / 后端服务
* 轻量数据库
* 代理 / 加密传输类应用
* 需要 IPv6 的服务
* 东南亚、香港、日本、中国大陆部分方向网络应用
* 流媒体和 AI 平台访问测试用途

----

== 三十五、不太适合的用途 ==
不建议仅凭本次测试直接用于以下对稳定性要求很高的场景：

* 对中国大陆晚高峰稳定性极度敏感的业务
* 必须长期稳定“原生新加坡 IP”识别的业务
* 对流媒体长期解锁有硬性保证的用途
* 长时间高强度磁盘写入
* 长时间持续跑满带宽
* 对中国大陆多地去程路由有严格要求的生产业务

----

== 三十六、测试限制说明 ==
本文中的性能数据均来自测试时间点的实测结果。VPS 性能会受到宿主机负载、网络拥塞、测试节点、目标平台策略等因素影响，因此结果可能随时间变化。
本文中的 Ping、MTR、路由测试主要为 VPS -> 目标方向
不等同于中国大陆用户 -> VPS 的去程体验
中国大陆多地去程路由、全国多地真实 Ping、晚高峰表现、长期丢包率等，无法由 VPS 本机直接完整测出，因此本文不对此类项目做绝对结论。
----

== 三十七、综合总结 ==
这台 BandwagonHost 新加坡 SG_8 VPS 整体表现比较均衡。

硬件方面，6 核 AMD EPYC Genoa 的 CPU 性能不错，sysbench 单线程和多线程表现正常，UnixBench 单副本分数 1003.2，6 并发分数 5260.6，多核扩展约 5.24x。OpenSSL AES-GCM 加密性能较强，适合 HTTPS、代理、VPN 和加密传输类应用。

磁盘方面，fio 轻量测试下顺序写入达到 4144 MiB/s，顺序读取 1701 MiB/s，4K 随机写约 10.5k IOPS，磁盘延迟也比较低，适合常规建站和轻中度应用。

网络方面，IPv4 / IPv6 均可用，BBR 已开启。新加坡本地 Speedtest 节点测得下载 20581.06 Mbps、上传 14648.39 Mbps，多地区下载测试中新加坡方向速度最高，日本方向约 268–283 Mbps，欧美方向约 110–126 Mbps。回程路由中到多个中国大陆目标经过 CTGNet / 59.43 段，电信方向表现较好。

流媒体与 AI 平台方面，IPv4 多数检测结果显示为新加坡区域，Netflix、Disney+、YouTube Premium、Amazon Prime Video、Dazn、HBO Max、TikTok、ChatGPT、Gemini、Claude、Sora 等在测试时显示可用。不过这类结果受平台策略和 IP 库影响较大，不代表长期保证。

需要注意的是，该 IP 在不同数据库中的地理位置识别并不完全一致，部分显示新加坡，部分显示美国或加拿大归属。如果业务强依赖目标平台对 IP 地区的识别，需要以目标平台实际识别为准。

总体来看，这台 SG_8 机器适合作为建站、API、轻量数据库、代理、IPv6 服务和东南亚方向网络应用的 VPS。若面向中国大陆用户，建议结合实际访问场景进一步观察晚高峰表现。
----

== 三十八、购买链接 ==
如果你想购买同款套餐，可以通过下面链接查看：

[https://bandwagonhost.com/order/ultra/Singapore BandwagonHost 新加坡 SG_8 套餐购买链接]

本文测试结果仅代表测试时间点表现，VPS 实际体验会受到网络环境、测试时间、宿主机负载和目标平台策略影响。

File:Amy.jpg

GWVPSCEPING.COM — Tue, 16 Jun 2026 21:00:32 GMT

GWVPSCEPING.COM上传File:Amy.jpg

新页面

Amy