平滑重载后请求超时说明新worker初始化异常，需重点排查reload后几秒内error_log中的ssl handshake timeout、upstream timed out等日志，检查证书权限、ocsp stapling阻塞、ssl_handshake_timeout值及dns解析是否导致新连接池重建。
平滑重载（nginx -s reload）本身不中断已有连接，但若重载后出现请求超时（如 504、SSL handshake timeout、连接拒绝等），说明新 worker 进程在初始化或处理新请求时存在阻塞或配置异常。排查重点不是“reload 是否卡住”，而是“新 worker 启动后能否及时响应新进请求”。
看 error_log 中 reload 后的首波错误时间点
真正的问题往往集中在 reload 完成后的几秒内：
- 执行
grep "reloading" /var/log/nginx/error.log找到 reload 精确时间 - 紧接着用
tail -n 100 /var/log/nginx/error.log | grep -E "(timeout|SSL|50[2-4])"查 reload 后 10 秒内的报错 - 重点关注含
ssl handshake timeout、upstream timed out、connect() failed的日志，且时间戳紧贴 reload 时间——这说明是新 worker 初始化失败，而非旧连接问题
查新 worker 启动时 TLS 握手是否卡住
HTTPS 请求超时最常见于新 worker 首次 TLS 握手阶段：
- 检查证书路径与权限：
ls -l /etc/nginx/ssl/*.pem /etc/nginx/ssl/*.key，确保 nginx worker 用户（如 www-data）可读 - 验证证书有效性：
openssl x509 -in cert.pem -text -noout 2>/dev/null和openssl rsa -in key.key -check -noout 2>/dev/null - 临时禁用 OCSP Stapling：
ssl_stapling off;+ssl_stapling_verify off;，reload 后观察是否恢复；若恢复，说明首次 OCSP 查询阻塞了握手 - 确认
ssl_handshake_timeout值合理（默认 30s），若网络延迟高或 OCSP 响应慢，建议设为 60s
确认 upstream 超时是否因新 worker 重建连接池
如果超时表现为 upstream timed out while connecting to upstream，可能是新 worker 未复用连接池：
- 检查
proxy_pass后端地址是否使用域名：若用了域名，新 worker 会重新做 DNS 解析，无resolver或缓存过期时可能阻塞 - 确认
keepalive连接池配置已启用，例如：upstream backend { server 127.0.0.1:8000; keepalive 32; }，并在 location 中加proxy_http_version 1.1; proxy_set_header Connection ''; - 对比 reload 前后
stub_status的Active connections和Reading/Writing/Waiting分布，若 Waiting 数突增后缓慢回落，说明新 worker 正在重建连接
验证 reload 本身是否瞬时完成且无资源争抢
看似无关，实则影响新 worker 启动效率：
- 执行
time nginx -s reload，正常应在 10–50ms；若超过 200ms，说明 master 进程被阻塞（如磁盘 I/O 高、配置文件过大、resolver 查询卡住） - 用
ss -s观察 total sockets 数量变化：reload 后若 sockets 急剧增长（非业务导致），可能是新 worker 大量新建连接而旧连接未及时释放 - 检查
worker_shutdown_timeout是否设置过短（如 1s），导致旧 worker 强制退出，连接被 RST，客户端感知为“连接重置”
