去年双十一前一天晚上十一点半，一个做跨境电商的客户电话打过来，声音都是颤的——他放在东京机房的商城页面，国内用户打开直接卡住不动，curl 一看延迟飙到 380ms，丢包率 12%。一查，上游 NTT 的 BGP 路由在晚高峰被挤爆了，他买的那条所谓"优质线路"根本就是个普通 transit，跟其他几百个客户共享出口。
这种事在日本服务器圈子里太常见了。地理上看着近，上海到东京直线距离也就 1800 公里，但网络距离跟物理距离完全是两码事。你租的机器在哪个机房、接的哪家上游、IP 段干不干净、带宽是不是超售的——这四个问题没搞清楚，租用日本服务器基本就是开盲盒。
日本线路的水到底有多深
先说最要命的：上游线路。日本机房的上游就那么几家大的——NTT（ASN 2914）、IIJ（AS2497）、软银（AS17676）、KDDI（AS2516）。听着都是大厂，但回国方向的表现天差地别。
NTT 是全球最大的 transit 提供商没错，但它的回国路由在晚高峰（北京时间 20:00-23:00）经常绕道。你 traceroute 一看，好家伙，数据包从东京出发，先跑到洛杉矶，再从洛杉矶回上海。本来 40ms 能到的事儿，硬生生给你绕成 120ms+。这不是 NTT 的锅，是它的 BGP 策略在亚太区域 peering 做得不够细，transit 客户优先级排在后面。
IIJ 相对来说好一些，它跟中国电信、中国联通有直连 peering，回国路由大部分时候走的是东京→上海/广州的直连。但 IIJ 的带宽池子没 NTT 大，碰到突发流量（比如日本那边搞什么大型直播活动），出口一样会堵。
软银（以前叫 BBTEC）走的是另一套路子，它跟中国联通的互联做得还行，但跟电信的互联就差点意思。你要是用户群体以联通为主，软银线路还能凑合；电信用户多的话，晚高峰照样卡得你怀疑人生。
再说 IP 段的问题。日本机房的 IP 段来源很杂，有些是从 JPNIC 申请的干净段，有些是从别的 ISP 手里倒腾过来的二手段。二手段最大的麻烦是什么？可能之前被拿去发过垃圾邮件、跑过乱七八糟的东西，结果你的 IP 一上线就在各种黑名单里躺着。邮件发不出去、API 调不通、CDN 回源被拒——这些破事全是 IP 段不干净闹的。
带宽超售就更隐蔽了。销售跟你说"100M 独享"，你信了。但实际上机房给整层楼 50 个客户共享的也就是一条 10G 的上游。算一下，10G ÷ 50 = 200M，看着够是吧？但晚高峰大家都跑满的时候，你那条"100M 独享"能跑到 30M 就烧高香了。怎么验证？后面给命令。
四家上游实测数据摊开看
以下数据是过去半年在不同时段用 MTR 和 iperf3 跑出来的均值，测试源是上海电信/联通家宽，目标是东京都内三个主流机房。别拿这个当绝对标准，但量级上的落差是实打实的：
| 上游线路 | 晚高峰延迟 | 丢包率 | 超售比（估） | 适合跑什么 |
|---|---|---|---|---|
| NTT (AS2914) | 65-120ms（绕道时 150+） | 2%-6% | 1:4 到 1:8 | 对延迟不敏感的后台任务、数据同步 |
| IIJ (AS2497) | 42-75ms | 0.3%-2% | 1:2 到 1:3 | 中日企业互联、API 对接 |
| 软银 (AS17676) | 50-90ms | 1%-4% | 1:3 到 1:5 | 联通用户为主的游戏、视频分发 |
| CN2 转接（经港/沪） | 32-55ms | 0.1%-0.8% | 1:1 到 1:2 | 高要求业务、金融级 API、实时交易 |
（表里 CN2 转接那行，严格来说不算"日本原生线路"，是走香港或者上海中转再回日本的。但很多客户要的就是这个效果，放进来做个参照。）
拿到机器之后别急着部署业务，先跑一轮诊断。下面这套命令我每次接手新机器都要过一遍，五分钟的事，能帮你省后面好几天的排障时间：
# 晚高峰跑 MTR，100 轮取均值，看丢包和延迟分布
mtr -r -c 100 -n 你的日本机器IP
TCP 握手延迟 + TLS 握手延迟，排除机房内部网络问题
curl -o /dev/null -s -w "TCP连接: %{time_connect}s\nTLS: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n" https://你的日本机器IP
查 IP 段归属、AS 号、路由对象
whois 你的日本机器IP | grep -iE "netname|orgname|route|origin|descr"
带宽实测（需要两端都装 iperf3）
iperf3 -c 你的日本机器IP -t 30 -P 4
跑完 mtr 重点看最后三跳的 Loss% 和 Avg 列。中间某一跳 Loss 突然飙到 10% 以上，大概率是那个出口的拥塞。最后一跳（你的机器）Loss 正常但 Avg 延迟很高，问题多半在机房内部交换或者你的系统配置上——这时候去查 net.ipv4.tcp_window_scaling 和 net.core.rmem_max 这两个内核参数，很多时候默认值太小，大带宽根本跑不满。
这几种情况别碰日本机房
把丑话说前头，日本服务器不是万金油，下面这几种情况你硬往上放就是给自己找不痛快：
- 用户群体 90% 以上在国内、且对延迟敏感到 50ms 以内才能接受的——老老实实放国内或者用香港 CN2 GIA，日本线路再快也快不过物理距离
- 跑金融级实时交易、毫秒级竞价的——日本到国内的延迟波动在晚高峰能到 15-20ms，这个晃法对交易类业务是致命的
- 需要大带宽（500M 以上）跑视频分发或者下载的——日本机房的大带宽价格贵得离谱，同样预算在国内能拿到 3 倍的量
- 业务涉及国内合规审查、需要 ICP 备案的——海外服务器备不了案，这条没什么好商量的
反过来说，日本机房真正适合的是什么？面向日本本土用户的业务、中日之间的企业级 API 对接（走 IIJ 直连）、对延迟不太敏感但需要亚太区域都能管到的后台任务、以及做日本市场电商和 SaaS 的团队。这些用法下，日本服务器的性价比和稳定性是实打实的。
选服务商的时候多留个心眼。有些小商家拿个日本 VPS 转手就卖，上游线路、IP 段来源、超售比一概说不清楚。像 StrataServer 这种在日本有自己的机房资源和线路对接的，至少你能拿到真实的 AS 号和路由信息，出了问题找得到人。别贪便宜买个来路不明的"日本服务器"，到时候 IP 被墙了、带宽缩水了，客服都联系不上。
关于写这些的人：在东京秋叶原附近的 IDC 机房蹲了七年，专门做中日跨境线路对接和 peering 运维，NTT 和 IIJ 的 NOC 电话打到能背下来。回国后在 HostLoc 和 V2EX 上混了几年，现在给几家做跨境电商和日本市场 SaaS 的公司做网络运维外包。写东西不修边幅，但数据都是真跑出来的。
采购日本服务器之前，先把上面那套 mtr 和 whois 命令跑一遍再签字。线路没验过、IP 段没查过就掏钱，跟闭眼过马路没区别。StrataServer 日本机房支持先测后付，拿个测试 IP 跑一整晚晚高峰数据，比看十篇测评都管用。