本手册用于站点出现异常时的快速定位：先按错误码判断故障层，再用日志确认具体原因，最后按处理与升级流程收口。目标是在 15 分钟内给出“已恢复”或“已升级”的明确结论。

一、适用范围

• 适用：站点返回 4xx、5xx，页面空白、响应超时等可观测故障；已有 Nginx、应用与数据库日志；单人值班可执行基础操作。
• 不适用：数据被误删或篡改的取证场景，应先隔离现场再处理；DDoS 攻击中的流量清洗；代码缺陷导致的业务逻辑错误定位。

二、准备工作

项目	要求	检查方法
服务器访问	可 SSH 登录并 sudo	ssh deploy@203.0.113.10 可进入
日志权限	可读 nginx 与应用日志	sudo tail -n 5 /var/log/nginx/error.log
服务清单	已知 nginx、应用、数据库的服务名	systemctl list-units --type=service
监控入口	可查看检测状态与告警记录	打开监控平台的检测页面
联系清单	后端、运维、负责人的联系方式	值班表可查
变更记录	可查最近一次发布与配置变更	git log 或发布记录

注意事项：

• 先确认影响面再动手：单页面异常与全站异常的处置优先级不同。
• 任何重启、回滚操作前先记录当前状态与时间，便于事后复盘。

三、操作步骤

本节拆成三个子步骤，建议按顺序执行；每一步完成后先确认结果，再进入下一步。

3.1 常见错误码速查

按错误码把故障归到 Nginx、应用或数据库层，缩小区间。详见 3.1 常见错误码速查。

3.2 日志定位方法

在确定的服务层内找到对应日志文件并定位首条错误。详见 3.2 日志定位方法。

3.3 处理与升级步骤

按止血优先原则处理，达到条件即升级并完成交接。详见 3.3 处理与升级步骤。

四、验证方法

1. 执行 curl -sSI https://example.com，预期返回 200，响应头 server 为 nginx。
2. 执行 systemctl is-active nginx 与 systemctl is-active axis-api，预期均为 active。
3. 执行 sudo tail -n 50 /var/log/nginx/error.log，预期无新增 upstream 相关错误。
4. 监控平台检测状态回到正常，且收到恢复通知。

五、常见问题

现象	可能原因	处理方式
502 持续出现	后端进程崩溃或端口未监听	ss -lntp 确认端口，查看应用日志与 OOM 记录
504 偶发	后端慢查询或外部依赖超时	查看慢日志，临时提高代理读超时
页面 200 但内容空白	静态资源 404 或前端脚本报错	浏览器控制台查 404，核对发布目录与指纹
全站 403	目录权限或 WAF 规则变更	namei -l 核对权限，检查 WAF 拦截记录
证书错误	证书过期或链不完整	openssl s_client 查到期日与证书段数

六、回滚与注意事项

• 回滚：优先回滚最近一次变更，软链指回上一版本或还原配置备份，回滚后立即验证核心页面。
• 注意：不要在未保留现场的情况下重启全部服务，重启会清除内存中的错误堆栈。
• 注意：对外通报只陈述已确认的事实与影响范围，不推测原因。

上一页3.3 缓存刷新方法

下一页3.1 常见错误码速查