日本 ZOUTER PRO
与 SG HostHatch 的逐项实测
判断：适合日本出口与备援，主控迁移应按业务拆分
这台 ZOUTER PRO 的核心价值是日本地区识别、东京低延时、300 GB 容量和备援位置。现有 SG HostHatch 在质数计算、SHA-256 和本轮磁盘随机 I/O 中领先；日本机在本轮压缩和 AES 测试中领先，不能用一个“快几倍”概括所有应用。
广州火山↔日本线路短测及后续 100 次 ICMP 复测都出现约 10% 丢包。这是迁移前需要持续观察的实际问题；中间路由器不回应不能直接当作业务丢包，银行主页或 CDN 延时也不是交易系统延时。
01 · 已购资产与当前状态
| 项目 | 日本 · 东京 ZOUTER PRO | 新加坡 · HostHatch 主控 |
|---|---|---|
| CPU | Intel Xeon Platinum 8272CL，4 vCPU | AMD EPYC 7763，4 vCPU |
| 内存 | 约 11.68 GiB 可见（套餐 12GB） | 约 15.6 GiB 可见（16GB 档） |
| 磁盘 | 300 GiB 虚拟盘 | 约 69.8 GiB 虚拟盘 |
| Swap | 2 GiB（恢复任务时核实已由其他任务配置） | 2 GiB |
| 虚拟化 | KVM | KVM |
| 系统/内核 | Debian 12 / 6.1.0-10-amd64 | 以本轮原始硬件记录为准 |
| IPv4 | 216.23.81.111 | 167.254.241.103 |
| IPv6 | 2a0e:97c0:3f4:1::2058 | 2406:ef80:2:7c4e::1 |
| ASN | AS205548 ZOUTER LIMITED | AS63473 HostHatch |
| 套餐 | JP BGP Global Plus - Debut #14669 | 现有主控，未重新核验账单 |
| 标称带宽 / 配额 | 1000 Mbps / 每周期 1024 GB | 未用历史宣传值作对比 |
| 防护 | 面板标称 5 Gbps；未进行攻击性测试 | 未测试 |
| 续费 | ¥2,594.29/年，约 ¥216.19/月 | 未核验 |
| 到期 / 流量重置 | 2027-09-17 15:18:44 / 2026-10-17 15:18:46 | — |
| 自动续费 / 自动购流 | 续费已开启；自动购流尚未确认 | — |
账务时间沿用供应商面板原文，面板未注明时区。vnStat 是自然月统计，自安装时开始累计；不等于供应商从每月 17 日起计算的账单用量。磁盘的 ROTA 虚拟属性不能证明底层是机械盘或 NVMe。
02 · 硬件与应用性能
| 基准 | 日本 JP | 新加坡 SG | 解释 |
|---|---|---|---|
| sysbench CPU 1线程 / events/s | 423.14 | 1,258.34 | SG / JP = 2.97× |
| sysbench CPU 4线程 / events/s | 1,706.05 | 4,782.35 | SG / JP = 2.80× |
| sysbench 内存写 / MiB/s | 18,529.80 | 19,670.04 | 1MiB重复缓冲，缓存敏感 |
| SHA-256 / GB/s（OpenSSL） | 0.428 | 1.409 | SG 明显领先 |
| AES-256-GCM / GB/s（OpenSSL） | 3.337 | 3.013 | 日本约领先 11% |
| zlib6 压缩 / MiB/s | 208.6 | 165.3 | 日本约领先 26% |
| 顺序写 / MB/s | 1,253.4 | 1,747.2 | 短时256MiB文件 |
| 顺序读 / MB/s | 1,270.9 | 3,226.9 | 短时256MiB文件 |
| 4K随机读 / MB/s | 74.6 | 173.2 | IOPS 18,204 / 42,297 |
| 4K随机写 / MB/s | 74.5 | 147.2 | IOPS 18,196 / 35,949 |
sysbench 1.0.20，质数上限 20000，单线程/4线程各10秒；fio 为256MiB临时文件，direct I/O、libaio、QD8，单项10秒、单作业；SG 使用低调度优先级。短文件仍可能命中宿主缓存，不是长期持续写入性能，也不证明磁盘介质。
OpenSSL 为单线程、16KiB块、每项3秒，工具按CPU时间统计；Python压缩用4MiB重复可压缩缓冲、4秒墙钟，JP Python 3.11.2、SG 3.12.3。编译选项、系统版本、宿主争用和缓存都会影响结果。早先日志的“单核快约24%”不能扩展为总体CPU结论；此处按明确工作负载分别记录。
03 · 全球下载与双向吞吐
HTTPS单连接每节点请求25MB范围，最多100MB/20秒；以下只计成功且实际下载不少于20MB的样本。短传输包含TCP启动、TLS与对端限速，不能代表1Gbps端口的上限。
| 公开下载节点 | 日本机下载 | SG下载 |
|---|---|---|
| Tokyo Vultr | 375.6 Mbps | 29.6 Mbps |
| Singapore Vultr | 未完成 | 320.1 Mbps |
| Los Angeles Vultr | 103.6 Mbps | 83.4 Mbps |
| New Jersey Vultr | 未完成 | 未完成 |
| Frankfurt Vultr | 56.1 Mbps | 91.1 Mbps |
| Sydney Vultr | 126.6 Mbps | 79.5 Mbps |
| Hetzner Germany | 42.2 Mbps | 52.3 Mbps |
iperf3 单连接每方向目标25MB，超时20秒；单位Mbps。“上传”是本机发出，“下载”是本机接收。公共测速服务器可能限速、繁忙或关闭。
| Leaseweb区域 | JP上传 | JP下载 | SG上传 | SG下载 |
|---|---|---|---|---|
| 东京 | 未完成 / 服务端异常 | 未完成 / 服务端异常 | 未完成 / 服务端异常 | 未完成 / 服务端异常 |
| 新加坡 | 未完成 / 服务端异常 | 未完成 / 服务端异常 | 199.2 | 200.1 |
| 香港 | 未完成 / 服务端异常 | 未完成 / 服务端异常 | 193.4 | 未完成 / 服务端异常 |
| 悉尼 | 31.8 | 77.0 | 29.5 | 66.7 |
| 洛杉矶 | 51.6 | 165.3 | 91.8 | 未完成 / 服务端异常 |
| 纽约 | 未完成 / 服务端异常 | 未完成 / 服务端异常 | 61.9 | 未完成 / 服务端异常 |
| 法兰克福 | 15.8 | 88.1 | 93.1 | 100.1 |
| 伦敦 | 未完成 / 服务端异常 | 92.3 | 92.8 | 40.0 |
日本机备用端口补测（50MB单连接）：
| 端点 | 端口 | 方向 | Mbps |
|---|---|---|---|
| speedtest.tyo11.jp.leaseweb.net | 5203 | upload | 124.1 |
| speedtest.tyo11.jp.leaseweb.net | 5203 | download | 111.0 |
| speedtest.sin1.sg.leaseweb.net | 5203 | upload | 369.8 |
| speedtest.sin1.sg.leaseweb.net | 5203 | download | 27.4 |
| speedtest.hkg12.hk.leaseweb.net | 5203 | upload | 302.6 |
| speedtest.hkg12.hk.leaseweb.net | 5203 | download | 413.6 |
主控↔日本机实际SSH传输，关闭压缩、内存零数据、每方向64MiB；包含登录/加密开销，适合参考备份传输，非裸TCP带宽：
| 方向 | Mbps | 耗时秒 |
|---|---|---|
| SG→JP | 139.8 | 3.84 |
| JP→SG | 140.3 | 3.83 |
Cloudflare测速返回403、CacheFly返回小响应，均剔除。没有可靠的优化前速度样本，因此不声称BBR带来某个提速百分比。测试采用有限字节，未运行可能消耗数十GB的不限流测速。
04 · 国际云区域延时
| AWS公开区域端点 | JP TCP中位数 ms | SG TCP中位数 ms | SG−JP（正数为JP更快） |
|---|---|---|---|
| AWS Tokyo | 5.07 | 71.08 | 66.01 |
| AWS Osaka | 13.36 | 77.78 | 64.42 |
| AWS Seoul | 36.73 | 81.61 | 44.88 |
| AWS Singapore | 69.67 | 2.65 | -67.02 |
| AWS Hong Kong | 46.87 | 39.48 | -7.39 |
| AWS Sydney | 162.13 | 240.49 | 78.36 |
| AWS US West | 91.94 | 174.06 | 82.12 |
| AWS US East | 146.48 | 207.53 | 61.05 |
| AWS Frankfurt | 222.94 | 156.75 | -66.19 |
| AWS London | 208.75 | 160.75 | -48.00 |
| AWS Mumbai | 127.14 | 58.43 | -68.71 |
| AWS Sao Paulo | 255.07 | 331.55 | 76.48 |
每端点3次IPv4 TCP/443连接，记录本机DNS解析与连接耗时；不是跨区域内部网络延时或游戏服务器延时。东京/大阪/首尔及美国方向，日本机更近；新加坡/印度/欧洲方向，SG多数更优。
05 · 自有舰队线路、抖动与丢包
| 日本机→对端 | ICMP平均 ms | mdev ms | 丢包（30次） |
|---|---|---|---|
| SG主控 | 67.41 | 0.103 | 0% |
| 广州火山 | 73.88 | 2.256 | 10% |
| 香港Lisa | 45.95 | 0.113 | 3.33333% |
| 东京GreenCloud | 0.65 | 0.050 | 0% |
| 东京ZOUTER旧机 | 0.34 | 0.151 | 0% |
| 洛杉矶HostHatch | 98.62 | 0.157 | 0% |
| 美东布法罗 | 149.10 | 0.150 | 0% |
TCP MTR也已保留原始记录；多条路径的中间TTL应答出现不稳定、交错地址与高丢包，不能据此直接认定业务流量经过每个显示的地址。终点成功率、独立ICMP与业务TCP结果分别解释。本报告没有用中间节点限速来制造“全线路丢包”结论。
06 · 银行、加密币、AI与常用站点
| 站点 | JP TCP ms | SG TCP ms | JP主页HTTP | SG主页HTTP |
|---|---|---|---|---|
| Cloudflare | 1.90 | 2.89 | 200 | 200 |
| 3.66 | 2.94 | 200 | 200 | |
| YouTube | 2.79 | 3.95 | 200 | 200 |
| GitHub | 4.36 | 4.36 | 200 | 200 |
| Microsoft | 2.32 | 12.92 | 200 | 0 |
| Apple | 3.14 | 10.68 | 200 | 200 |
| OpenAI | 2.42 | 2.71 | 403 | 403 |
| Anthropic | 2.79 | 3.10 | 403 | 403 |
| Gemini | 3.19 | 5.13 | 200 | 200 |
| Netflix | 3.13 | 5.92 | 200 | 200 |
| Disney+ | 1.82 | 11.98 | 200 | 200 |
| Prime Video | 3.16 | 2.25 | 200 | 200 |
| Spotify | 70.06 | 1.84 | 200 | 200 |
| TVer | 4.05 | 70.20 | 200 | 200 |
| ABEMA | 68.37 | 1.90 | 200 | 200 |
| DMM | 3.59 | 2.52 | 200 | 200 |
| NHK | 3.96 | 10.45 | 200 | 200 |
| BBC iPlayer | 69.90 | 2.67 | 200 | 200 |
| DBS-SG | 2.44 | 2.38 | 200 | 200 |
| OCBC-SG | 87.22 | 40.36 | 200 | 200 |
| UOB-SG | 151.24 | 5.07 | 200 | 200 |
| HSBC-HK | 3.60 | 2.00 | 200 | 200 |
| BOCHK | 56.92 | 45.48 | 200 | 200 |
| MUFG-JP | 3.34 | 12.84 | 200 | 200 |
| SMBC-JP | 2.19 | 10.20 | 200 | 200 |
| IBKR | 4.74 | 2.20 | 200 | 200 |
| Binance API | 4.13 | 1.78 | 403 | 403 |
| OKX API | 3.20 | 2.56 | 200 | 200 |
| Bybit API | 3.52 | 2.94 | 200 | 200 |
| Coinbase API | 3.02 | 2.28 | 404 | 404 |
| Kraken API | 2.30 | 2.35 | 404 | 404 |
| Bitget API | 3.03 | 2.33 | 404 | 404 |
| Upbit API | 32.86 | 81.90 | 404 | 404 |
| Bitflyer API | 3.07 | 10.84 | 200 | 200 |
银行结果仅代表公开主页与前端/CDN，不代表网银登录、风控、下单或清算；未登录任何金融账号。UOB主页本轮日本约151ms、SG约5ms，东京出口并不会让所有银行都变快。
Binance / OKX / Bybit / Kraken / Coinbase / Bitget / bitFlyer 的公开时间、ping或健康接口，两地都返回正常结果。主页403/404与有效API路径结果分开记录；这不等于账号服务资格、交易权限或撮合延时。
OpenAI API无凭据返回预期401，两地均未见地区拒绝；ChatGPT/Claude网页返回403，不能把CDN trace可达算成登录或实际模型使用通过。Gemini首页可达，未做账号内调用。
07 · 地区识别与媒体限制
| 服务 | 日本机证据 | SG证据 | 结论边界 |
|---|---|---|---|
| IP / Cloudflare | JP / NRT；IPv4和IPv6均通过 | SG / SIN；双栈通过 | 地区识别正常 |
| Netflix | JP，两个非自制标题页含og:video | SG，两个标题页均无og:video | 日本目录探测通过；未登录实播，SG疑似仅自制，非完整定论 |
| YouTube Premium | JP，购买入口标记存在 | SG，购买入口标记存在 | 地区页面可用，未购买/播放 |
| ABEMA | 地区接口200、isoCountryCode=JP | 403 anonymous_ip | 日本地区检查通过，SG被拒 |
| TVer | 播放元数据接口200、project_id存在 | 403 不允许观看 | 日本接口通过；未拉取影片分片 |
| DMM TV | UNAUTHORIZED（需登录） | FOREIGN（海外限制） | 日本未被地区挡住；账号/实际播放未测 |
| Spotify | geoCountry=JP | geoCountry=SG | 地区识别；不是账户可用性保证 |
| TikTok | 页面region=JP | 页面未提取有效地区 | JP页面识别；推荐流/直播未测 |
| Disney+ | 首页200，完整播放授权未验证 | 首页200，完整播放授权未验证 | 不宣称解锁 |
| Prime Video | 首页200 | 首页200 | 不宣称解锁 |
| BBC iPlayer | 媒体接口geolocation错误 | 媒体接口geolocation错误 | 两地均不通过英国地区检查 |
媒体判断参考开源 RegionRestrictionCheck 的端点与识别逻辑，并保留本次响应字段；没有执行它的一键安装脚本。地区探测不是DRM、账号、付费内容和所有片库的完整播放验证。“全球解锁”在此按多个地区/服务逐项检查，不声称单个日本IP解锁所有国家。
08 · 已完成的优化、管理和监控
| 项目 | 验收结果 |
|---|---|
| TCP拥塞控制 | CUBIC → BBR，内核原生模块 |
| 网卡队列 | 保留mq四队列，四个子队列均FQ；default_qdisc=fq |
| TCP缓冲 | 收发自动调整上限32MiB，初始缓冲保持默认 |
| MTU黑洞探测 | tcp_mtu_probing=1 |
| 回滚 | 原sysctl/qdisc有备份，目标机有独立回滚脚本 |
| 长期SSH | 用户明确批准舰队公钥；启用镜像原先关闭的PubkeyAuthentication，独立密钥登录已通过 |
| 资产台账 | 登记套餐、资源、账单、配额、到期与SSH别名 |
| Komari | 新节点硬件/流量持续上报；到日本新机的全舰队ping任务已加 |
| 主页探测 | 香港Lisa与广州火山两视角；主控SG为回退视角，探测历史已入SQLite |
| 流量 | vnStat + 每5分钟舰队采集 + Komari账务备注同步 |
| 四地秒级性能 | 日本加入SG/LA/布法罗性能页，CPU/内存/磁盘/压力/网络持续上报 |
| 当前附加部署 | 其他授权任务已配置2GiB Swap和静态Caddy备援；本任务保留 |
| 内核更新 | 仍为6.1.0-10；未擅自重启已承载备援的机器，版本升级需另行维护窗口 |
BBR配置持久化文件已写入，实时值已核验；本次未用重启验证持久化。参数含义见 Linux内核官方文档。BBR不会缩短物理距离，也不能修复所有线路丢包。
09 · 应用场景与迁移建议
| 场景 | 建议 | 原因 |
|---|---|---|
| 当前AI/自动化主控、Panorama数据库 | 继续由SG承载；日本先备援 | SG现有运行环境完整，质数/SHA/I/O明显更强；日本尚未验证业务链 |
| 静态网站与灾备 | 日本适合，当前已部署静态镜像 | 300GB容量充足；手动切换机制由另一任务维护 |
| 日本媒体/日本公开API | 日本优先验证业务 | 地区接口表现明显好于SG；东京AWS约5ms vs SG约71ms |
| 新加坡银行与SG区域服务 | SG优先 | UOB/AWS SG等端点SG更近；CDN场景差异较小 |
| 美国方向公开API | 可试点日本出口 | AWS US West约92ms vs SG约174ms；吞吐仍须分服务看 |
| 欧洲/印度方向 | 本轮SG更适合 | 区域握手延时与多项吞吐占优 |
| 大流量下载分发 | 谨慎控制配额 | 1Gbps只是端口上限，1024GB周期配额不适合长期跑满 |
| 中国方向可靠业务 | 暂不因本次测试整体迁入 | 广州两轮10% ICMP丢包；须做多时段端到端业务验证 |
| 容量型备份 | 日本可作异地副本 | 300GB约为SG可见虚拟盘4.3倍；注意1024GB流量预算 |
若按十进制1024GB、持续1Gbps计算，单方向理论约2.28小时即可消耗该额度；整月均摊约3.16Mbps。实际计费是否双向累计以供应商规则为准。以后迁移应逐项验证数据恢复、任务调度、数据库与API行为，再决定切换。