美国服务器延迟高/SSH连不上/Stripe 回调超时常见问题排查手册

表现：本地 ssh [email protected] 超时，或提示 Connection timed out / Connection refused；VNC/KVM 能进，但外网不通；有时 Comcast 能通、ATT/CenturyLink 全不通（单 ISP 故障）。
可能原因：① 22 端口被安全组/云防火墙拦截；② fail2ban/iptables 把国内/本地 ISP 的 CGNAT 出口 IP 拉黑；③ sshd 改端口或崩溃；④ 某一条回程链路（优化回国线/ATT/Lumen）异常导致 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 并将多个运营商（Lumen/ATT/Comcast/CenturyLink）的出口段加入白名单；若单一路由故障，切换备用 BGP（Lumen ↔ ATT/HE 回程）。

表现：浏览器白屏、TTFB>1s、视频卡顿、Webhook 偶发超时；监控显示丢包率>1%，尤其晚高峰（UTC 00:00–04:00，即美东 19–23 点）。
可能原因：① 美国运营商 BGP 抖动/维修；② 国际带宽 95 峰值被打满；③ Nginx/PHP-FPM 连接耗尽；④ DNS 解析走了欧洲/亚洲递归而非美国本地。
排查步骤：
1. 双向 MTR：mtr --tcp --port 443 -r x.x.x.x，重点看最后 2–3 跳（Lumen/ATT/CenturyLink/Comcast/Cogent/Zayo）是否晚高峰丢包严重；特别注意回国是否走 HE/Telia 绕线。
2. sar -n DEV 1 60 看带宽利用率，若 1Gbps 长期 ≥900Mbps → 带宽堵塞。
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 主线（如 Lumen ↔ ATT，或开启 CN2/AS9929 优化回国）；③ DNS 切美国本地递归（如 1.1.1.1 / Google 8.8.8.8 / ATT DNS），解析从 80–150ms 降到 <15ms。

表现：每天随机重启 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 回调丢失率 3–9%，对账差异大（尤其是黑五/网一）。
可能原因：① 主站放在欧洲/亚洲，支付回调强制走欧洲中转导致跨境抖动；② 回调 IP 没加入 Stripe/PayPal 的 webhook 白名单（或被 WAF 规则拦截）；③ 收单机构在晚间/周末维护但未做降级；④ 签名时钟偏差 >60s 被 Stripe 拒单。
排查步骤：
1. tcptraceroute api.stripe.com 443 与 mtr --tcp --port 443 -r 支付网关，确认是否绕路。
2. 在 WAF/日志中搜索 Stripe/PayPal 回调来源 IP 段，确认 4xx/5xx 比例；timedatectl 检查服务器时钟与 NTP。
3. 登录 Stripe Dashboard → Webhook Events，查看失败原因（超时/401/签名错误）。
快速修复：① 把支付回调服务拆到美国本地独立节点，关闭欧洲/亚洲中转；② Stripe/PayPal 发布的 webhook 源 IP 段全量加入白名单并关闭该路径的速率限制；③ 做多通道降级（Stripe 失败自动路由 Adyen/Braintree，或 Klarna ↔ Afterpay）；④ 强制开启 NTP chronyd 并锁定北美时钟源（time.nist.gov / time.apple.com）。

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