数据库连接超时在Nginx错误日志中不显式标注，但表现为connect() failed、upstream timed out while connecting、upstream prematurely closed connection三类关键词；需结合access.log中$upstream_response_time接近proxy_read_timeout、$uri集中于写库接口及$request_id链路追踪，向下关联应用日志与数据库连接池/慢查询确认根因。
数据库连接超时在 Nginx 错误日志里不会直接写“DB timeout”，但会留下几类明确线索：上游连接失败、响应等待超时、后端提前断连。关键不是看有没有“数据库”字样，而是识别这些异常模式并向下追溯。
重点抓三类错误关键词
打开 /var/log/nginx/error.log，用 grep 快速筛选以下内容：
- connect() failed (111: Connection refused)：后端服务（如应用进程）根本没起来，或监听地址/端口配置错误 → 数据库连接池未初始化就崩溃，也可能导致上游无法启动
- upstream timed out (110: Connection timed out) while connecting to upstream：Nginx 尝试连后端时卡住 → 常见于应用启动中、DB 连接池耗尽、网络中间设备拦截 SYN 包
- upstream prematurely closed connection while reading response header：后端处理中途退出 → 很可能是应用在获取数据库连接或执行 SQL 时触发 OOM、被 kill 或主动 abort
配合 access 日志交叉验证
单看 error.log 只能知道“连不上”，要确认是否与数据库有关，必须结合 access.log 中的耗时字段：
- 检查 $upstream_response_time 是否接近或等于 proxy_read_timeout（比如设为 30s，日志里出现 29.987s）→ 表明后端几乎耗尽全部等待时间，极大概率卡在 DB 层
- 若 $request_time 明显大于 $upstream_response_time（如 request_time=35s，upstream_response_time=2s），说明瓶颈不在后端，而在 Nginx 到客户端之间
- 对同一 $uri 统计：高耗时请求集中出现在 /api/order/create、/user/login 等需写库的接口，且伴随 502/504 → 强烈指向数据库连接或事务阻塞
启用 request_id 实现链路追踪
光靠日志字段还不够，得把 Nginx 请求和后端行为串起来：
- 在 Nginx 配置中加入 log_format，确保包含 $request_id；并在 proxy_set_header X-Request-ID $request_id; 透传给后端
- 拿到 error.log 中某条报错的时间和 client IP 后，从 access.log 提取对应 $request_id
- 用该 ID 去查应用日志：搜 “Connection reset”, “timeout acquiring connection”, “HikariPool-1 - Connection is not available” 等关键词，基本就能定位是连接池满、DB 响应慢还是 SQL 死锁
下一步必须查下游指标
Nginx 日志只是告警哨兵，真正根因得看更底层：
- 查数据库连接池监控：HikariCP 的 activeConnections 持续 100%、pendingThreads 不断上涨；Druid 的 WaitCount > 0 且持续增长
- 查数据库自身慢日志：MySQL 的 slow_query_log 是否开启，long_query_time 是否设得太低；PostgreSQL 查 log_min_duration_statement 和 pg_stat_statements
- 查应用 GC 日志或线程 dump：如果发现大量线程卡在 java.sql.Connection 或 mysqli_real_connect 调用栈，就是典型 DB 连接获取阻塞
