499 状态码无法通过 $request_completion 变量精准识别，因其在 499 场景下常为 ok；应结合 $status=499、$bytes_sent=0 及极小 $request_time 等变量综合判断。
直接通过 $request_completion 变量无法精准标记因用户关闭网页导致的 499 状态码，因为它在 Nginx 中并不反映连接中断原因，而仅表示请求是否“正常完成”。499 是 Nginx 自定义状态码（客户端主动关闭连接），但 $request_completion 在 499 场景下仍为 ok，而非 failed —— 这是常见误解的根源。
理解 $request_completion 的真实行为
$request_completion 是一个只读变量，取值只有两个：ok 或空字符串（不是 failed）。它仅在请求被完整读取并响应头已发送后才为 ok；若请求体未读完、连接提前断开、或响应未发出，该变量为空。但关键点在于：499 发生时，Nginx 往往已发出响应头（哪怕只是部分），因此 $request_completion 常为 ok，不能作为 499 的判据。
真正可靠识别 499 的日志方案
要精准标记 499（尤其是区分于超时或服务端错误），应依赖 Nginx 原生状态码和连接相关变量组合判断：
- 直接使用
$status：499 状态码本身已在 access log 中记录，无需额外推断 - 结合
$connection_requests和$bytes_sent：499 通常伴随$bytes_sent = 0（未发送任何响应体）或极小值 - 配合
$request_time与$upstream_response_time：若$request_time很小（如 $upstream_response_time 为空或极短，更倾向用户快速中断 - 启用
log_format显式包含关键字段：log_format detailed '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '$request_time $upstream_response_time "$http_user_agent" ' 'req_body_bytes:$request_length;
避免误用 $request_completion 的典型场景
以下做法不可靠，需规避：
- 在 log_format 中写
$request_completion并期望它为failed来标识 499 —— 它永远不会是failed - 用
if ($request_completion != "ok") { ... }拦截 499 请求 —— 此条件几乎不触发，且 if 在 location 中限制多、易出错 - 将
$request_completion与$status联合用于“是否成功”统计 —— 499 下$request_completion常为ok，会污染成功率指标
补充建议：增强 499 归因能力
若需进一步区分 499 是否由前端主动取消（如 JS abort()、页面跳转、关闭标签页），可：
- 前端在发起请求时添加唯一 trace_id，并在 abort 时上报（需业务层配合）
- 后端服务（如 proxy_pass 目标）记录上游收到请求但未返回的时间点，与 Nginx 499 日志按时间+trace_id 关联
- 利用 Nginx 的
map指令预标记潜在高风险路径：map $status $is_client_abort { 499 1; default 0; }然后在 log_format 中使用$is_client_abort
