首先用基础网络工具做初步判断:从本地或外部节点执行 ping、traceroute(或tracert)检测连通性和路由;使用 curl -I 或 telnet 测试服务端口(如80/443/22)。
如果 ping 无响应但端口有响应,可能是 ICMP 被防火墙阻断而服务仍在;如果端口也连不上,尝试从多个不同线路(国内、海外、APAC)回连确认是否区域性中断。若都不可达,进入下一步检查机房控制台或远程管理卡(IPMI、iLO)判断主机状态。
若确认宕机且能访问远程管理,先尝试软重启或通过控制台查看系统日志;若无法访问控制台,可请求机房工程师重启主机或切换到备份节点以实现业务临时上线。
使用 mtr 或 ping -c 监测丢包与延迟,定位是到达日本机房前的网络环节还是机房内部。检查带宽使用情况(iftop、nload)、连接数(netstat、ss)以及是否有流量突增或 DDoS 攻击痕迹。
同时确认服务器的网络接口、交换机和路由器是否存在错误计数或队列拥堵,检查机房公告是否有链路维护或上游运营商问题。
短期内可启用 CDN(日本节点)、流量清洗或临时限流;对内优化 TCP 参数、关闭不必要的持久连接或增加带宽;必要时将流量切换到备援机房或容灾节点。
首先查看应用日志(Nginx、Apache、Tomcat、应用日志)和系统日志(/var/log/messages、dmesg),确认是否为应用崩溃、资源耗尽(CPU、内存、文件句柄)或依赖服务(数据库、缓存)故障。
使用 top、htop、free、iostat、vmstat 检查主机资源,使用 strace 或 gdb 辅助定位进程卡顿。对分布式系统,检查依赖链路和第三方 API 是否超时。
可先重启问题服务、清理缓存或回滚最近部署;若为数据库瓶颈,切换只读/主从角色或临时限流;对无法快速修复的 bug,回退到稳定版本并在回退后做根因分析。
使用 dig 或 nslookup 检查权威 DNS 和各地解析结果,确认 A/AAAA/CNAME 记录是否正确,TTL 是否改变后未生效。排查是否被错误的 CDN/负载均衡配置覆盖或被缓存的旧记录影响。
同时检查域名注册和 DNS 服务商控制台,确认域名未被暂停或解析被恶意改写。若使用海外 DNS,考虑日本本地解析节点的差异。
快速恢复方法:
可临时修改本地 /etc/hosts 以验证修复方案、降低 TTL 并修正 DNS 记录,必要时联系 DNS 服务商加急刷新解析或切换到备用解析服务。
检查磁盘使用(df -h)、inode(df -i)和 SMART 状态(smartctl)。若磁盘满会导致应用异常或无法写日志,引发服务崩溃。还需查看 RAID 状态、硬盘错误计数和系统是否报告 I/O 错误。
若为内存泄漏或进程占满,查看 core dump、进程内存峰值并重启服务;对硬盘故障,尽快从快照或备份恢复数据并替换故障盘。
快速恢复方法:
清理日志与临时文件、扩容磁盘或挂载新盘并迁移数据;启用故障磁盘的自动替换与备份恢复策略,必要时从快照恢复到健康节点以尽快恢复业务。
