日本服务器延迟高/SSH连不上/PayPay 回调超时常见问题排查手册

表现：本地 ssh [email protected] 超时，或提示 Connection timed out / Connection refused；VNC/KVM 能进，但外网不通；有时 NTT 能通、KDDI/SoftBank 全不通（单 ISP 故障）。
可能原因：① 22 端口被安全组/云防火墙拦截；② fail2ban/iptables 把本地/中国 ISP 的 CGNAT 出口 IP 拉黑；③ sshd 改端口或崩溃；④ 某一条回程链路（NTT/KDDI/优化回国线）异常导致 100% 丢包。
排查步骤：
1. 本地 nmap -p 22 x.x.x.x，若 filtered → iptables -L -n | grep 22 与云安全组同步检查。
2. fail2ban-client status sshd，若被封则 fail2ban-client set sshd unbanip <出口IP>。
3. VNC 登录后 ss -lntp | grep sshd，未监听则 systemctl restart sshd 并查 journal。
快速修复：先用 VNC 登录，临时清空 INPUT 规则验证；把 SSH 改为 443/2222/8443 并将多个日本运营商（NTT/KDDI/SoftBank/IIJ）的出口段加入白名单；若单一路由故障，切换备用 BGP（NTT ↔ KDDI / BBIX 回程）。

表现：浏览器白屏、TTFB>1s、视频卡顿、Webhook 偶发超时；监控显示丢包率>1%，尤其晚高峰（JST 20:00–24:00）（短视频 + Netflix + Amazon プライム叠加）。
可能原因：① 日本运营商 BGP 抖动；② 国际带宽 95 峰值被打满；③ Nginx/PHP-FPM 连接耗尽；④ DNS 解析走了欧洲/新加坡递归而非日本本地。
排查步骤：
1. 双向 MTR：mtr --tcp --port 443 -r x.x.x.x，重点看最后 2–3 跳（NTT/KDDI/SoftBank/IIJ/BBIX/JPNAP）是否晚高峰丢包严重；特别注意回国是否走公用网绕线。
2. sar -n DEV 1 60 看带宽利用率，若 1Gbps 长期 ≥950Mbps → 带宽堵塞。
3. curl -s http://127.0.0.1/nginx_status 看 active/waiting 是否激增，必要时调大 worker_connections 与 PHP-FPM pm.max_children。
快速修复：① 临时上 CDN 分流静态热点（图片/JS/CSS/MP4），回源带宽下降 40–70%；② 与机房切换临时备用 BGP 主线（如 NTT ↔ KDDI，或开启 CN2/AS9929 优化回国）；③ DNS 切日本本地递归（如 1.1.1.1 / Google 8.8.8.8 / NTT DNS），解析从 80–130ms 降到 <10ms。

表现：每天随机重启 1–2 次，dmesg 出现 OOM / blocked for more than 120s / EXT4 I/O error；或机房邮件提示「电压告警/风扇告警/高温」。
可能原因：① 内存 OOM（大促期间 PHP-FPM 或 Go 服务泄漏）；② SSD/NVMe 坏块导致 I/O 卡死；③ 夏季台风/高温 + 冷却不均导致 CPU/内存降频甚至保护重启；④ 虚拟化宿主机超卖（邻居吵闹）。
排查步骤：
1. journalctl -k -b -1 看上一次关机前内核日志，是否 OOM/MCE/EXT4 I/O error。
2. smartctl -a /dev/sda（NVMe 用 nvme smart-log）看可用预留/Power Cycles/介质错误计数；高温环境要关注 温度传感器 是否 ≥70℃。
3. 独立服务器登录 IPMI/iDRAC/iLO 看 SEL：是否 CPU ERR、DIMM ECC、PSU 告警。
快速修复：① 立即开启 16–32GB swap，swappiness=10；② 要求机房把机器迁移到冷通道温度≤23℃机柜；③ 虚拟化环境热迁移到新宿主机；④ 确认硬件坏件立刻换机并从备份回滚（RPO≤15 分钟）。

表现：用户完成 3DS 或扫码支付后回到商城显示「支払いタイムアウト」；Webhook 回调丢失率 4–10%，对账差异大（尤其是月末和セール期）。
可能原因：① 主站放在新加坡/香港，支付回调强制走海外中转导致跨境抖动；② 回调 IP 没加入 PSP（GMO/EB/SB Payment）白名单或被 WAF 规则拦截；③ 收单机构在夜间/周一维护但未做降级；④ 签名时钟偏差 >60s 被 PSP 拒单。
排查步骤：
1. tcptraceroute api.paypay.ne.jp 443 与 mtr --tcp --port 443 -r 支付网关，确认是否绕路。
2. 在 WAF/日志中搜索支付回调来源 IP 段，确认 4xx/5xx 比例；timedatectl 检查服务器时钟与 NTP。
3. 登录 PSP 管理后台，查看 Webhook Event 失败原因（超时/401/签名错误）。
快速修复：① 把支付回调服务拆到东京本地独立节点，关闭海外中转；② PSP 发布的源 IP 段全量加入白名单并关闭该路径的速率限制；③ 做多通道降级（PayPay 失败自动路由 LINE Pay/JCB）；④ 强制开启 NTP chronyd 并锁定日本标准 NICT ntp.nict.jp。

表现：中国客户完全打不开，手机漫游或海外节点正常；或日本本地某一 ISP 访问极慢（丢包 10–30%），其他 ISP 正常。
可能原因：① 内容/端口策略命中；② SNI/域名黑名单；③ 同段 IP 被牵连；④ 异常出站扫描（SMTP/SYN）被日本 ISP / 云厂商拉黑；⑤ 某运营商对未合规商务站点做 QoS。
排查步骤：
1. 做多点探测（Tokyo/Osaka/Singapore/HK/北京/上海/广州），判断是否「单区/单 ISP」故障。
2. 更换端口 + 自签证书测试 HTTPS，确认是 IP 级还是域名/SNI 级。
3. tcpdump 排查是否有大量 SYN 扫描 / SMTP 异常出站 / 445 攻击流量。
快速修复：① 立即申请新弹性 IP 切解析；若为站群，启用备用 C 段；② 旧 IP 提交工单复核并提供业务合法性材料；③ 长期：东京 + 大阪 + 新加坡三 IP 池热备，DNS 健康检查 30s TTL 自动切换。