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]]

搬瓦工 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

MediaWiki:Requestaccount-bio/en

Admin — Thu, 28 May 2026 03:05:53 GMT

创建页面，内容为“For verification, please include your Telegram account -OR- BandwagonHost account e-mail:”

新页面

For verification, please include your Telegram account -OR- BandwagonHost account e-mail:

MediaWiki:Requestaccount-bio

Admin — Thu, 28 May 2026 03:05:29 GMT

创建页面，内容为“For verification, please include your Telegram account -OR- BandwagonHost account e-mail:”

新页面

For verification, please include your Telegram account -OR- BandwagonHost account e-mail:

MediaWiki:Common.css

Admin — Thu, 28 May 2026 03:04:24 GMT

Improves readability.

←上一版本		2026年5月27日 (三) 20:04的版本
第4行：		第4行：
	max-width: 100%;		max-width: 100%;
	height: auto;		height: auto;
			}

			#wpBio,
			#wpNewBio,
			.mw-confirmaccount-type-0,
			.mw-confirmaccount-body-0 {
			background-color: transparent !important;
	}		}

AI助手Amy，不懂Linux也能轻松管理搬瓦工VPS

Bwh91.com — Fri, 22 May 2026 03:17:14 GMT

←上一版本		2026年5月21日 (四) 20:17的版本
第163行：		第163行：

	'''Amy 适合哪些用户？'''		'''Amy 适合哪些用户？'''
			[[File:20260521-bwh-amy-intro12.png]]
	~~\| 用户类型 \| Amy 能帮你做什么 \|~~
	\|---~~\|---\|~~
	~~\| 刚买第一台 VPS 的新手 \| 买完不知道下一步，让 Amy 做安全基线检查 \|~~
	~~\| 会用但记不住命令的用户 \| 用中文描述需求，她来跑命令 \|~~
	~~\| 服务器出了问题要排查 \| 直接问 Amy，她自己跑诊断返回结论 \|~~
	~~\| 磁盘空间小的机型（如 Minibox） \| 让 Amy 帮你做日志清理和限制配置 \|~~
	~~\| 忘记 root 密码无法登录 \| Amy 帮你通过 KiwiVM 重置 \|~~
	~~\| 想定期做安全检查的用户 \| 周期性让 Amy 做一次安全审计 \|~~

	'''总结'''		'''总结'''

File:20260521-bwh-amy-intro12.png

Bwh91.com — Fri, 22 May 2026 03:16:54 GMT

Bwh91.com上传File:20260521-bwh-amy-intro12.png

新页面

bwh91.com

AI助手Amy，不懂Linux也能轻松管理搬瓦工VPS

Bwh91.com — Fri, 22 May 2026 03:15:14 GMT

←上一版本		2026年5月21日 (四) 20:15的版本
第179行：		第179行：

	教程来自搬瓦工交流群：[https://t.me/bwh81 搬瓦工交流群]		教程来自搬瓦工交流群：[https://t.me/bwh81 搬瓦工交流群]
	[[~~index.php?title=~~Category:200 KiwiVM 简介 — KiwiVM Introduction]]		[[Category:200 KiwiVM 简介 — KiwiVM Introduction]]

搬瓦工 E-Commerce 套餐 VPS（CN2GIA）全机房测试「附广东电信实测」

Liam — Wed, 20 May 2026 00:11:00 GMT

←上一版本		2026年5月19日 (二) 17:11的版本
第22行：		第22行：

	👉[https://bwh81.net/aff.php?aff=76910&pid=87 套餐直达] 、📂[https://www.xiaoge.org/tags/bandwagonhost 更多搬瓦工教程、内容]		👉[https://bwh81.net/aff.php?aff=76910&pid=87 套餐直达] 、📂[https://www.xiaoge.org/tags/bandwagonhost 更多搬瓦工教程、内容]
			[[Category:Test category]]

搬瓦工 V5 ECOMMERCE 套餐 15 大机房上海电信终极横评：谁是真“夯”，谁是“偏科生”？

Musazu — Tue, 19 May 2026 16:18:33 GMT

←上一版本		2026年5月19日 (二) 09:18的版本
（未显示同一用户的1个中间版本）
第65行：		第65行：

	👉 [https://bandwagonhost.com/ref/promo-20g-v5 点击此处直达查看 / 购买：SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE (支持支付宝/银联)]		👉 [https://bandwagonhost.com/ref/promo-20g-v5 点击此处直达查看 / 购买：SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE (支持支付宝/银联)]



			[[Category:Test category]]

搬瓦工 V5 ECOMMERCE 套餐 15 大机房上海电信终极横评：谁是真“夯”，谁是“偏科生”？

Musazu — Tue, 19 May 2026 16:16:59 GMT

创建页面，内容为“在接连爆肝刷完了搬瓦工（Bandwagon Host） '''SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE''' 套餐（$49.99/季度）全部 15 个机房的测试脚本后，后台的数据已经堆成了山。同一个套餐，同样的价格，在 KiwiVM 面板里轻轻一点切换机房，底层的 CPU 架构（从老至强到顶级 AMD Genoa）、回程路由、晚高峰丢包率简直是天壤之别。为了给大家一个最直观的选机参考，我以'…”

新页面

在接连爆肝刷完了搬瓦工（Bandwagon Host） '''SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE''' 套餐（$49.99/季度）全部 15 个机房的测试脚本后，后台的数据已经堆成了山。

同一个套餐，同样的价格，在 KiwiVM 面板里轻轻一点切换机房，底层的 CPU 架构（从老至强到顶级 AMD Genoa）、回程路由、晚高峰丢包率简直是天壤之别。

为了给大家一个最直观的选机参考，我以'''“上海电信晚高峰直连”'''为回国体验基准，结合 NQ (NodeQuality) 跑分与 NextTrace 路由抓取，把这 15 个机房分为四个真实的体验梯队：'''夯、人上人、NPC、偏科生'''。
----

== 🥇 T0 级别：夯 (Hang) ==
'''评级说明'''：稳如老狗，全天候 0% 丢包。自带 CN2 GIA / CMIN2 / AS9929 顶级物理外挂，闭眼切这几个机房，体验绝对是真“夯”。

这几个机房是本套餐面向国内直连的绝对回本利器。无论物理距离在美西、美东还是欧洲，只要带了顶级回国优化线，上海电信晚高峰的丢包率被死死按在 '''0%'''。

* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 洛杉矶 DC6 节点实测报告|洛杉矶 DC6 (USCA_6)]]：老牌神盘，CN2 GIA + CMIN2 护航，延迟 131ms，各方面毫无波澜，稳。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 洛杉矶 DC9 节点实测报告|洛杉矶 DC9 (USCA_9)]]：'''强烈推荐！''' 硬件切到了顶配的 AMD Genoa，单核跑分破 3500，配合 CN2 GIA，既有线路又有算力，夯中之夯。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 圣何塞 SJC5 节点实测报告|圣何塞 (USCA_SJC5)]]：惊艳的三网强制 CN2 GIA 机房！上海电信延迟压到 134ms，抖动仅 1.33ms，建站秒开的极品。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 加拿大温哥华 CABC6 节点实测报告|温哥华优化版 (CABC_6)]]：加拿大原生 IP 叠加三网全线 CN2 GIA 回国，AMD Genoa 满血 3.19GHz，0% 丢包，稀缺资源。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 纽约 NY8 节点实测报告|纽约优化版 (USNY_8)]]：虽然远在美东，但回程走联通 AS9929+CMIN2+CN2GIA。硬生生把跨美洲大陆的延迟优化到 0 丢包，技术含金量极高。

----

== 🥈 T1 级别：人上人 ==
'''评级说明'''：物理距离的绝对碾压，哪怕晚高峰有丢包，延迟也能让你体验到“人上人”的快感。

* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 日本大阪 JPOS1 节点实测报告|日本大阪软银 (JPOS_1)]]

:* '''上榜理由'''：东亚极近距离的物理作弊器。上海电信直连平均延迟仅 '''88ms'''（如果是联通更是能低至 40ms+）。虽然没有 CN2 GIA，晚高峰受限于公网会有 16% 左右的断续丢包，但在低延迟的加持下，SSH 敲代码和网页响应的体感依然属于人上人级别。

----

== 🥉 T2 级别：NPC ==
'''评级说明'''：毫无存在感，食之无味弃之可惜。硬件中规中矩，走普通直连路由。属于不用心疼，用了也毫无惊喜的背景板。

这几个机房没有回国精品网加持。在上海电信晚高峰环境下，延迟大多在 150ms-180ms 之间，伴随 3% - 18% 不等的丢包率。通常只用来做特定原生 IP 落地或短时间备用。

* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 洛杉矶 DC8 ZNET 节点实测报告|洛杉矶 DC8 ZNET (USCA_8)]]：普通 163 骨干网，晚高峰丢包 18%，老 Intel Cascadelake 架构，纯 NPC 表现。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 洛杉矶 DC2 AO 节点实测报告|洛杉矶 DC2 AO (USCA_2)]]：硬件是新的 AMD Genoa，但网络依然是常规 Arelion 直连，晚高峰丢包 14%，可惜了这身好皮囊。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 弗里蒙特 FMT 节点实测报告|弗里蒙特 (USCA_FMT)]]：HE (AS6939) 线路，北美常规直连，丢包 3%，无功无过。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 加拿大温哥华 CABC1 节点实测报告|温哥华普通版 (CABC_1)]]：最大的价值是加拿大原生 IP 全绿解锁，网络本身晚高峰抖动极大（Jitter 破 700ms）。

----

== 🛠️ T3 级别：偏科生 (出海专供) ==
'''评级说明'''：针对'''中国大陆回国优化线路'''而言，这几个节点由于没有精品直连专线防护，在晚高峰直连公网时容易出现长时延与高丢包，表现出长距离跨境公网的天然特质。

'''海外落地定位'''：如果你是'''完全面向海外用户'''（做外贸独立站、TikTok 跨国矩阵、海外 API 采集、区域化本土业务），这些机房反而是隐藏的极品。

由于国内直连党流量几乎全数汇聚在美西优化节点（如 DC6/DC9），这些非优化冷门机房的'''底层母鸡负载极低、基本没有恶邻居抢占资源'''。配合顶级 AMD Genoa 算力和极为纯净的属地原生 IP 画像，在本地化出海落地上具备更高的性能稳定性和功能价值。

* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 荷兰阿姆斯特丹 EUNL9 节点实测报告|荷兰阿姆斯特丹优化版 (EUNL_9)]]：走 CTGNet/AS9929 跨洲高级调优，晚高峰仍有 7% 的断续丢包。但拥有纯正荷兰原生 IP 且涵盖 Disney+ 完整解锁。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 荷兰阿姆斯特丹 EUNL2 节点实测报告|荷兰阿姆斯特丹普通版 (EUNL_2)]]：上海电信直连丢包 15%，但拥有纯正荷兰原生 IP，欧洲本土业务落地神器。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 新泽西 USNJ 节点实测报告|新泽西 (USNJ)]]：美东常规直连，晚高峰丢包 7%。但流媒体及 ChatGPT 全绿解锁，美东业务低负载神机。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 纽约 NY6 节点实测报告|纽约普通版 (USNY_6)]]：跑分狂魔！AMD Genoa 磁盘狂飙，受限于公网长途拥堵晚高峰丢包 13%。适合重度北美数据爬取、编译。
* [[搬瓦工 SPECIAL 20G KVM PROMO V5 - 阿联酋迪拜 AEDXB1 节点实测报告|阿联酋迪拜 (AEDXB_1)]]：中东机房，回国路由绕行。但拥有稀缺的迪拜原生 IP，中东土豪区跨境电商必选。

----

== 💡 终极购买与使用建议 ==
搬瓦工这套 '''SPECIAL 20G KVM PROMO V5 ECOMMERCE 套餐''' 的最大魅力，就在于你可以随时在后台根据业务需求在 15 个机房中反复横跳。

'''一句话总结选机策略'''：

# '''盲选建站/重度回国直连'''：秒切 '''USCA_9 (DC9)''' 或 '''USCA_SJC5 (圣何塞)'''，享受 AMD Genoa 与 CN2 GIA 的无脑满血组合。
# '''联通用户/低延迟控'''：果断驻扎 '''JPOS_1 (大阪软银)'''，物理距离才是王道。
# '''纯出海业务/区域流媒体落地'''：避开拥挤的优化区，选择 '''T3 偏科生机房（如迪拜、温哥华、新泽西）'''，享受极低负载、超强硬件和纯正属地原生 IP 带来的清静体验。

👉 [https://bandwagonhost.com/ref/promo-20g-v5 点击此处直达查看 / 购买：SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE (支持支付宝/银联)]

File:CABC 6 NQ IPQuality.webp

Musazu — Tue, 19 May 2026 15:57:12 GMT

Musazu上传File:CABC 6 NQ IPQuality.webp

新页面

Musazu — Tue, 19 May 2026 15:39:51 GMT

新页面

__NOTOC__
近期测试了一台搬瓦工（Bandwagon Host）的套餐实例。

'''测试套餐名称'''：SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE

'''计费周期'''：$49.99 USD / 季度

根据官方提供的产品信息，该套餐的基础配置如下：
* '''核心硬件'''：2x Intel Xeon CPU / 1 GB RAM / 20 GB SSD (RAID-10)
* '''网络规格'''：1000 GB 月流量 / 2.5 Gbps 峰值带宽
* '''机房支持'''：支持在 10+ 个数据中心之间免费无缝迁移（包含洛杉矶 CN2 GIA、日本软银 Equinix OS1 等）。
* '''附加特性'''：免费自动备份、免费快照。

本次测试选择的机房为 '''EUNL_9 (EU: Amsterdam, Netherlands DC9 (China Unicom Premium))'''。本地测试环境采用“上海电信”宽带，以反映真实的连通性。

== 01. 硬件信息与磁盘 I/O ==

基于 NodeQuality 脚本的检测结果如下：

* '''CPU'''：识别为 '''Intel Xeon Processor (Cascadelake)''' 架构。Sysbench 测试'''单线程得分 687.33，多线程得分 1321.36'''。整体释放表现平稳。
* '''磁盘 I/O'''：通过 Fio 工具规则测试，'''1M 顺序读取达到了 1309 MB/s'''，顺序写入达到 1136 MB/s（在并行极限测试下，大文件顺序读取可达 4440 MB/s）。4K 随机读写速度在 11-16 MB/s 左右。底层存储阵列运行状态稳定。

== 02. 网络连通性与回程路由 ==

官方标称该节点提供优质线路。通过 NextTrace 追踪了三网的回程路由节点：

* '''电信'''：回程流量经过 xTom 荷兰阿姆斯特丹本地控制点后拉往德国法兰克福。随后，全线强制并入专属的 '''CTGNet / CN2 GIA''' 精品骨干网优化直连回国。
* '''联通'''：回程流量强制借道 '''AS10099 (联通国际精品网) 连通中国联通顶级精品网 AS9929''' 直连回国。
* '''移动'''：回程流量经过德国法兰克福控制点，并入移动高级专线 '''AS58807 (CMIN2)''' 直连回国。

[[File:EUNL_9_NextTrace.webp|center|thumb|800px|NextTrace测试]]

在连通性与延迟稳定性方面，提取了以下两组数据：

# '''全国 Ping 测试 (ITDOG)'''：在三网全高级优化线（AS9929 + CMIN2 + CN2GIA）的底座调配下，彻底打破了传统欧洲直连长途丢包断流的硬伤。大盘大面积呈现平稳的浅绿色，延迟稳定在 150ms - 220ms 之间，整体表现正常。

[[File:EUNL_9_ITDog.webp|center|thumb|800px|ITDog测试]]

# '''延迟连通性测试 (本地 Ping / 监控)'''：在上海电信环境下进行连续 200 次 Ping 测试，平均延迟维持在 242ms 附近，最低 238ms。受限于跨洲公网骨干网络长途负荷，单次测试录得 '''27% 的断续丢包率'''。

[[File:EUNL_9_Ping.webp|center|thumb|800px|本地Ping测试]]

在 Speedtest-X 单线程测速中，测试下载速度约为 3.82 Mbps，上传 76.08 Mbps（上传限制释放充分）。得益于高级优化线的稳定保护，抖动（Jitter）紧紧缩死在 '''2.58 ms''' 的极平缓区间。满足长连接稳定性需求。

[[File:EUNL_9_SpeedTest.webp|center|thumb|800px|SpeedTest测试]]

== 03. IP 风险值与流媒体解锁 ==

IP 归属地为荷兰阿姆盛特丹 (xTom GmbH)。在 ipapi 数据库中风险积分为 0.05%（极低风险），AbuseIPDB 欺诈得分为 0，网络信誉极佳。

根据区域解锁脚本的测试结果，当前 IP 提供了无可挑剔的全绿原生解锁表现，'''支持原生访问荷兰区 Netflix、Disney+、TikTok'''，同时支持正常访问 ChatGPT 服务。

== 04. 总结 ==

结合官方套餐规格与实际测试数据，该实例在荷兰阿姆斯特丹 EUNL9 精品优化节点的主要表现如下：

# '''极具含金量的跨洲高级路由'''：回程强制借道 CTGNet、AS9929 以及 CMIN2 顶级优化线的策略，确保了全天候极低的丢包率与平稳的抖动表现。
# '''出色的本土原生 IP 属性'''：全绿且涵盖 Disney+ 的完整原生解锁能力，赋予了该节点极高的欧洲本土落地价值。
# '''附加价值'''：套餐内包含的自动备份、快照以及多机房免费切换功能，降低了后期的维护成本。

整体而言，该套餐提供的硬件参数与实际网络表现相符，其绝佳的跨洲零丢包控制极其适合对网络高稳定性交互、欧洲本土独立站运维或区域流媒体落地业务有严格要求的部署环境。

----

== 附录：测试数据源截图 ==

=== 💻 基本信息 ===
[[File:EUNL_9_NQ_BaseInfo.webp|center|thumb|800px|基本信息]]

=== 🎬 IP质量 ===
[[File:EUNL_9_NQ_IPQuality.webp|center|thumb|800px|IP质量]]

=== 🌐 网络质量 ===
[[File:EUNL_9_NQ_NetQuality.webp|center|thumb|800px|网络质量]]

=== 📍 回程路由 ===
[[File:EUNL_9_NQ_NetTrace.webp|center|thumb|800px|回程路由]]

[[Category:Test category]]