server块中配置的error_log不能捕获底层网络异常（如errno 111/110/113），这类系统级错误只记录在全局error_log中；其真实作用是定位HTTP请求链路中的upstream超时、SSL握手失败等带上下文的错误，并通过独立路径和warn/error级别辅助快速关联全局日志线索。
在 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”，但合理配置可缩小问题范围：
- 为每个关键 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
一个典型排查链路示例
假设你在 server 块看到：2026/07/29 14:20:11 [error] 12345#67890: *1234 upstream timed out (110: Connection timed out) while connecting to upstream...
下一步不是调高 server 日志级别，而是：
- 去全局 error.log 查同一时间戳附近是否还有
connect() failed (111)—— 若有，说明 upstream 根本没监听 - 用
ss -tlnp | grep :8080看目标端口是否真在监听，且 bind 地址是0.0.0.0而非127.0.0.1 - 若用 Docker/K8s，再查容器网络命名空间或 CNI 插件状态
