VPS.Town 🏷️ 【内测】HKG-A5p 建站初体 🐔

测试日期：2026-10-02（UTC+8）｜系统：Debian 12｜虚拟化：KVM
测试原则：裸机空载起测；fio 使用 direct=1；关键短测重复 3 次取中位数。

结论

KG-A5p 是一台硬件强力的香港大配置 VPS：12 核持续满载稳定、480G 盘能长期维持约 4 万 4K 随机写 IOPS，Nginx、Redis 和 PostgreSQL 容器性能都很充足；但大陆方向路由差异大，电信样本绕美。它适合作为香港区域的多站点、容器宿主机、缓存和数据库节点，但关键业务仍应在多时段线路复测后再部署。

1. 套餐、实例与系统支持

截图与实例中确认到的主要规格：

控制面板可选 Windows、Rocky、Debian、CentOS、Ubuntu；截图中 Debian 12.0 为免费镜像。是否包含许可证、具体小版本及 Windows 授权方式，应在重装前再次以面板为准。

2. 测试环境与方法

• 测试前负载接近 0，内存占用约 730 MiB，无既有业务容器。
• CPU：sysbench、Geekbench 6、7-Zip、OpenSSL、stress-ng。
• 内存：sysbench 1/12 线程及 mbw 4GiB。
• 磁盘：fio direct IO、1M/4K、QD1/QD32、50/50 混合读写和 10 分钟持续写。
• 建站与容器：原生 Nginx、Docker Nginx、PostgreSQL 16、Redis 7。
• 网络：固定文件下载、公共 DNS、三网代表目标出站 MTR、HTTP 可达性和 SMTP TCP 端口。
• 所有三网路由结果都是“香港主机出站”，不等于大陆用户访问该机的回程线路。

3. CPU：多核完整，持续负载稳定

Geekbench 6 的在线结果可在 Geekbench Browser 复核。

10 分钟满载

• 第 1 分钟：5,526.61 events/s；第 10 分钟：5,530.67 events/s。
• 首尾变化 +0.07%，监测到的最高 CPU steal 为 0%。
• 结论：测试时段内没有可见的 CPU 配额收紧、降频或宿主机争抢。

4. 内存：读取扩展强，写入扩展有限

mbw 4GiB、3 轮结果为 MEMCPY 5,712.96 MiB/s、DUMB 4,640.79 MiB/s、MCBLOCK 6,046.69 MiB/s。不同工具实现不可横向直接比较，但都没有出现异常低速。系统没有 Swap，生产环境应为数据库和容器设置内存上限，并配置适量 swap/zram 作为最后缓冲。

5. 磁盘：低延迟、稳态强，是整机最亮眼部分

基础 fio 使用 2 GiB 测试文件、direct=1、libaio，每项 30 秒、3 次中位数。

补充结果：ioping 平均 110.6 µs；1 GiB dd direct 顺序写 971 MB/s。

不同块大小的 50/50 混合读写

在 QD64、50/50 randrw、3 次中位数下：4K 读写各约 40.6k IOPS；64K–1M 的双向吞吐均稳定在约 1.22 GB/s。大块写入 p99 在 1M 场景达到 54.3 ms，说明高队列混合写的尾延迟仍需在数据库场景中关注。

10 分钟持续随机写

• 前 30 秒：41,338 IOPS；末 30 秒：40,004 IOPS。
• 全程最低：39,532 IOPS；首尾下降约 3.2%。
• 没有出现缓存或突发额度耗尽后的断崖式下跌，稳态非常接近初始性能。

6. 建站、容器与数据库

图中单位混合展示：Nginx/Redis 为 req/s，PostgreSQL 为 TPS，适合观察数量级，不用于服务间直接排名。

Nginx

Docker 场景相对原生吞吐低约 19.2%，但两者都远高于一般 CMS 或 API 的实际需求。公网 TTFB 曾在 0.90–3.32 秒间波动，瓶颈更可能来自线路或公网调度，而非本机 Web 栈。

PostgreSQL 16

pgbench scale=50、32 客户端、12 线程、30 秒读写事务：

• 13,487.70 TPS，平均延迟 2.367 ms。
• 完成 404,921 笔事务，失败 0。
• 官方 Alpine 镜像冷拉取 8.25 秒，容器返回 486 ms，再约 1.47 秒就绪。

Redis 7.4

50 客户端、pipeline 16、100,000 请求：GET 1,075,269 req/s，SET 970,874 req/s，INCR 980,392 req/s；容器空闲内存约 9.34 MiB。此结果是高 pipeline 的吞吐上限，不等同于互联网单请求延迟。

结论：适合运行 Docker Compose、多站点、反向代理、缓存、队列和中等强度数据库。生产数据库仍需独立数据卷、备份、资源限制和恢复演练。

7. 国际网络：节点间差异明显

Cloudflare 20MB 上传曾达到 44.74 MB/s（约 358 Mbps）。这说明“端口标称 3000Mbps”不代表到任意目标都能跑满，实际受对端、路由、拥塞和单连接能力影响。新加坡下载反而最慢，且早前样本出现超时，值得在不同时段复测。

8. 大陆三网出站路由

以下只代表测试时刻从香港主机到目标的单向路径：

中间路由器的高“丢包”常由 ICMP 限速引起；只有目标端持续丢包才可直接判断业务丢包。本次结果足以说明三网体验不会一致，但不足以替代大陆多地、三网、晚高峰的入站回程测试。

9. IP、平台与邮件端口

IP / ASN

• 公网 IPv4：84.*.*.*.*（已脱敏）；多个回显服务一致。
• 地理：香港；RIPEstat 对齐到已公告的 84.*.*.*.0/24。
• ASN：AS213404，YstronTek Networks / Suzhou Yesong Information Technology Co., Ltd.
• Cloudflare 普通 trace 为 HKG / HK。ChatGPT trace 曾显示不同的服务侧出口地址，因此只把它视为该平台链路特征，不改变本机公网 IP 判断。

DNSBL 快速抽样中，SpamCop、Barracuda、SORBS 没有返回列名；Spamhaus 返回 127.255.255.254，这是公共 DNS 查询策略/错误码，不能据此判定 IP 已列入或完全干净。IP 信誉会随时间变化，发信业务应使用正式信誉服务和实际投递测试。

平台 HTTP 可达性（不是完整解锁测试）

SMTP TCP 端口

• Gmail：25 / 465 / 587 均可建立 TCP。
• Microsoft 365：25 / 587 可建立 TCP，465 超时或被阻断。

端口可连接不代表 IP 有良好发信信誉，也不代表目标接受未授权投递。

10. 综合评分与适用人群

适合：香港/国际向多站点、Docker 多服务、缓存、数据库、CI runner、需要较强本地 IO 的应用。
需要验证后再用：面向大陆用户的站点、晚高峰敏感业务、依赖特定流媒体/AI 平台的代理出口。
不适合直接承担：没有异地容灾的唯一关键节点，以及要求优质大陆三网回程的业务。

11. 测试后的状态与局限

• 临时 Nginx、PostgreSQL、Redis 测试容器均已停止/删除；管理端口信息不在公开报告中披露。
• Docker 环境与测试工具保留；约 1.8GB 的 Geekbench 官方压缩包/解压目录在保存成绩与 SHA-256 后已清理，原始文本、CSV、JSON 和日志另行归档。
• 磁盘测试文件小于主机内存，但启用了 direct IO，并用 10 分钟持续随机写验证稳态。
• Web/数据库均为本机基准，不等同于真实 CMS、业务逻辑与生产调优结果。
• 网络测试是一个时点的少量样本；线路和 IP 信誉都可能随时间变化。
• 没有大陆多地入站 Looking Glass，因此不能把出站 MTR 写成“回程线路”。
• 未进行破坏性测试、DDoS 测试、真实邮件投递、付费平台登录或内容播放。

综合判断：如果价格合理，KG-A5p 的硬件资源和磁盘表现很有吸引力。

12. NQ/TCP

https://paste.spiritlhl.net/#/show/dWV5x.txt
https://nodequality.com/r/k5cjetn90uDDK77TgzvhaSBGmY9Dfdgb
https://tcpquality.ibsgss.uk/r/r-BPiKLypa