Nginx异常捕获：让服务器问题无处可藏

日志里藏着真相

网站突然打不开，接口频繁报502错误，用户开始抱怨。你登录服务器第一件事该做什么？不是重启Nginx，也不是杀进程，而是去看error.log。很多新手遇到问题就慌，其实Nginx早就把异常写进日志了，关键是你得知道怎么“读”。

默认情况下，Nginx会把运行时的异常记录在指定的日志文件中，比如/var/log/nginx/error.log。打开它，你会发现类似这样的内容：

2023/12/05 14:23:10 [error] 1234#0: *567 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.100, server: api.example.com, request: "POST /v1/user/login HTTP/1.1"

这一行信息量不小：连接上游服务被拒绝，客户端IP、请求路径、时间全都有。这就是典型的后端服务挂掉导致的异常，顺着这条线索去查对应的服务状态，往往几分钟就能定位问题。

配置级别异常捕获

除了被动查看日志，还可以主动设置捕获规则。比如你想监控某个location块的异常行为，可以在配置中加入error_page指令：

location /api/ {
    proxy_pass http://backend;
    error_page 502 = @fallback;
}

location @fallback {
    log_not_found off;
    access_log /var/log/nginx/fallback.log;
    return 200 '{"code":502,"msg":"服务暂时不可用"}';
}

这样当后端返回502时，不会直接暴露空白页或默认错误页，而是走自定义逻辑，既提升了用户体验，又方便你在fallback.log里集中分析异常请求。

利用access_log记录细节

很多人只关注error.log，却忽略了access.log也能帮助异常排查。通过在日志格式中加入$request_time、$upstream_status等变量，能快速识别慢请求或上游异常：

log_format detailed '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';

access_log /var/log/nginx/access.log detailed;

当你发现某类API平均响应时间突然飙升，就可以从这里入手，结合time_local和request字段筛选出具体时间段内的请求，进一步缩小排查范围。

信号与调试开关

Nginx本身不支持像Java那样抛出异常堆栈，但可以通过发送信号动态调整日志级别来辅助诊断。比如临时开启debug模式：

kill -USR1 `cat /var/run/nginx.pid`

这会让Nginx重新打开日志文件，常用于日志轮转。而要开启debug，需要编译时启用debug模块，并在配置中添加：

error_log /var/log/nginx/error.log debug;

注意：生产环境慎用debug级别，会产生大量日志，可能影响性能。

常见异常场景应对

“Connection reset by peer”通常意味着客户端主动断开，可能是页面加载超时用户关了浏览器；“Too many open files”则是系统句柄数不足，需要调大ulimit；“No live upstreams”说明健康检查机制已生效，所有节点都被标记为不可用。

把这些高频错误记下来，下次看到就不会手忙脚乱。平时多翻日志，就像医生看体检报告，看得多了自然知道哪里容易出问题。