$request_completion 并非 nginx 官方变量，未在源码定义或文档中存在，可能是对 $status、$bytes_sent 等变量的误解；实际可通过 $status（000 表示中断）、$bytes_sent、$request_time 等组合判断请求完成度。
$request_completion 并不是 Nginx 官方变量，它并不存在于 Nginx 的内置变量列表中。Nginx 官方文档中没有 $request_completion 这个变量，因此无法直接用它来分析请求完整度。
为什么找不到 $request_completion？
Nginx 的内置变量（如 $status、$request_time、$bytes_sent 等）都经过明确定义和导出，用于日志、条件判断或响应头设置。而 $request_completion 既未被源码定义，也未在任何稳定版本中实现——它可能是误传、混淆（比如与某些第三方模块或监控系统自定义字段混淆），或对 $sent_http_content_length、$bytes_sent 等变量的误解。
真正可用的请求完成度相关指标
虽然没有“完成度”变量，但可通过组合现有变量间接判断请求是否被完整处理：
- $status：HTTP 状态码。2xx/3xx 表示正常完成；4xx/5xx 表示客户端错误或服务端失败；000 表示连接中断（如客户端提前断开），这是最常用的“非完整请求”信号。
-
$bytes_sent：已发送给客户端的字节数。若为 0 且
$status为 000，大概率是请求未发出响应即断连。 -
$request_time：请求处理总耗时（秒，精度毫秒）。极短时间（如 0.000）+
$status=000可辅助判断快速中断。 - $connection_requests：当前连接已处理请求数。结合连接生命周期，可辅助识别异常中断模式。
如何在日志中识别“不完整请求”
在 log_format 中加入关键字段，便于后分析：
log_format incomplete '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'$request_time "$http_referer" "$http_user_agent" '
'upstream_status=$upstream_status upstream_response_time=$upstream_response_time';
然后通过日志分析工具（如 awk、grep、ELK 或 Grafana Loki）筛选 $status=000 的记录：
awk '$9 == "000" {print}' access.log- 统计比例：
awk '{n++; if($9=="000") m++} END {print "incomplete:", m/n*100 "%"}' access.log
更进一步：用 map 模块标记完成状态
可借助 map 指令将 $status 映射为语义化标签：
map $status $completion_flag {
default "completed";
000 "aborted";
499 "client_closed";
500 "server_error";
}
再将其写入日志或响应头，便于下游系统识别：
- 日志中添加
$completion_flag - 返回头中加
add_header X-Request-Status $completion_flag;
不复杂但容易忽略：所谓“请求完整度”，本质是观察响应是否成功发出。盯住 $status 和 $bytes_sent，比虚构一个变量更可靠。
