Nginx 怎么在 Server 块中配置错误日志输出级别排查底层网络异常-Nginx-PHP中文网

server块中配置的error_log不能捕获底层网络异常（如errno 111/110/113），这类系统级错误只记录在全局error_log中；其真实作用是定位http请求链路中的upstream超时、ssl握手失败等带上下文的错误，并通过独立路径和warn/error级别辅助快速关联全局日志线索。

nginx 怎么在 server 块中配置错误日志输出级别排查底层网络异常

在 server 块中配置错误日志级别，**不能直接捕获底层网络异常（如 errno 111/110/113）**——这类错误由 Nginx 主进程或工作进程在连接上游时触发，属于系统级网络调用失败，**只记录在全局 error_log 中**。但你可以通过 server 块的日志配置，结合上下文定位具体哪条 upstream 请求出问题，并快速关联到全局日志里的网络线索。

server 块 error_log 的真实作用

server 块中的 error_log 指令仅控制该虚拟主机范围内与 HTTP 请求处理强相关的错误，例如：

SSL 握手失败（如证书不匹配、协议版本不兼容）
rewrite 指令执行异常（正则语法错、循环重定向）
限流模块（limit_req）触发的拒绝日志
upstream 超时、重试失败等带明确 upstream 上下文的报错（如 upstream timed out）

它不会覆盖或替代全局 error_log 对 connect()、send() 等系统调用失败的记录。真正出现 Connection refused (111) 或 No route to host (113) 时，必须查 /var/log/nginx/error.log（全局路径），而非某个 server 单独的日志文件。

正确配置 server 块以辅助网络异常排查

虽然不能“抓到底层 errno”，但合理配置可缩小问题范围：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

为每个关键 server 块指定独立 error_log 路径，例如：
error_log /var/log/nginx/example_com_error.log warn;
这样能快速确认是哪个域名的请求触发了上游异常
日志级别设为 warn 或 error：避免 debug 级别淹没关键信息，又能捕获超时、连接失败等带 upstream 地址的提示
确保该 server 块内 proxy_pass 指向的 upstream 名称或地址，在全局 error_log 中能被 grep 到，例如：
upstream api_backend { server 10.0.1.5:8080; }
日志里就会出现 upstream:"http://api_backend/"，方便反向追踪

必须配合全局日志和系统工具

单靠 server 块配置远远不够，需联动以下动作：

立即检查全局 error_log：
grep -E "(Connection refused|timed out|No route to host|reset by peer)" /var/log/nginx/error.log | tail -20
确认对应 upstream 是否可达：
nc -zv 10.0.1.5 8080 或 telnet 10.0.1.5 8080
查 DNS 解析（若 upstream 是域名）：
nslookup api.internal.example.com
检查本机路由和防火墙：
ip route get 10.0.1.5、sudo iptables -L OUTPUT -n