nginx 默认不记录未完成处理的请求，因其未进入 log phase；客户端断连（如浏览器取消、弱网中断）导致请求在读取头/体、转发或等待响应时终止，故 access_log 缺失。
当 Nginx 访问日志中出现“本该记录但没记录”的请求，尤其是疑似客户端快速断开（如浏览器取消、移动端网络切换、curl 被 Ctrl+C 中断）导致的日志缺失时，根本原因往往不是日志配置错误，而是 Nginx 默认不记录那些在请求处理完成前就中断的连接 —— 它们压根没走到写日志的阶段。
确认是否真因客户端断连导致日志丢失
Nginx 只对成功进入 log phase 的请求写 access_log。如果请求在读取请求头/体、转发给 upstream、等待响应等任一环节被客户端关闭，且此时 Nginx 尚未开始生成响应或记录日志，该请求就不会出现在 access_log 中。
可结合以下方式交叉验证：
- 开启 error_log debug（临时），搜索
client closed connection、broken pipe、connection reset by peer等关键词，确认是否存在大量主动断连事件 - 检查对应时间点的客户端行为：前端是否频繁 abort XHR/Fetch？App 是否在加载中切后台？curl 是否加了
-m 1或被手动中断？ - 对比
stub_status或nginx -T | grep 'connections'输出中的Active connections和Writing状态突增，可能反映连接堆积后被客户端放弃
启用 $request_length 和 $bytes_sent 辅助判断
默认日志格式不体现请求是否真正被接收或响应是否发出。建议在 log_format 中加入关键变量：
log_format detailed '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'$request_length $bytes_sent "$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time';
重点关注：
- $request_length = 0：Nginx 甚至没收到完整请求行和头，极可能是 TCP 握手后立刻断开（SYN flood 类似行为，但更常见于弱网重试逻辑）
- $bytes_sent > 0 但 $status 为空或为 000：Nginx 发送了响应（哪怕部分），但连接中断导致无法记录最终状态 —— 此时 access_log 仍不会落盘
- $request_time 很小（如 0.000）但 $upstream_response_time 为空：请求未发往后端即中断
用 realip + map 构建“准连接中断”标记（无需改代码）
虽然 Nginx 无法把中断请求写进 access_log，但可通过 error_log + 自定义变量做间接追踪：
- 在 http 块中定义 map，捕获 close 状态：
map $status $log_if_closed {
~^[45] 0; # 4xx/5xx 正常记录
default 1; # 其他情况（含 000）标为需关注
}
- 再配合 error_log 输出上下文（例如记录 IP + 时间 + 请求行片段）：
log_format close_debug '$remote_addr [$time_local] "$request" $status $request_length';
error_log /var/log/nginx/close-debug.log warn;
if ($log_if_closed) {
error_log /var/log/nginx/close-debug.log notice;
# 注意：if 在 location 外不可用，实际需配合 location + log_not_found off 等组合实现
}
更稳妥做法是使用 echo_read_request_body（需 echo 模块）或升级到 Nginx Plus 启用 request tracing；开源版推荐用 lua-nginx-module 在 rewrite_by_lua_block 中检测 ngx.req.socket() 异常。
调整 keepalive 和超时参数降低误判概率
部分“丢失”实为长连接复用下请求被吞或超时丢弃。检查并合理设置：
- client_header_timeout / client_body_timeout：设为 10–30s，避免慢速攻击占用连接，也防止弱网客户端发一半就断却长时间挂起
- keepalive_timeout：不宜过长（如 75s），尤其高并发场景，避免 TIME_WAIT 连接堆积掩盖真实断连
- send_timeout：控制响应发送阶段超时，与后端响应速度匹配，减少因后端卡顿导致的客户端不耐烦断开
修改后用 nginx -t && nginx -s reload 生效，并持续观察 error_log 中断频次变化。
不复杂但容易忽略：Nginx 的 access_log 本质是“成功处理完成的请求快照”，不是“所有抵达 server 的 TCP 包”。抓包（tcpdump）+ error_log + 自定义日志变量三者结合，才能准确定位哪类断连在悄悄吃掉你的日志行。
