Nginx 默认不记录SSI子请求日志，因log_subrequest硬编码为off，需显式配置on才能使SSI、mirror等子请求进入日志流水线，并通过$request_completion等变量区分主子请求。
为什么 log_subrequest 默认不记录 SSI 子请求
Nginx 默认将 SSI（Server Side Include）包含生成的子请求视为内部跳转，不走常规日志模块，log_subrequest off 是硬编码默认值。即使你在 access_log 指令中用了 $request_id 或 $upstream_http_x_request_id，SSI 的 <!--#include file="..."--> 也不会出现在 access log 中——它根本没被 log_handler 处理。
必须显式开启才能让子请求进入日志流水线：
-
log_subrequest on;需放在http、server或location块中，作用域决定生效范围 - 仅影响由 Nginx 自身发起的子请求（SSI、
echo_exec、auth_request、mirror等），不涉及 upstream 的代理请求 - 开启后，每个子请求会独立打一行日志，但
$request_time记录的是该子请求自身耗时，不是父请求总时间
如何区分 SSI 子请求与主请求的日志行
关键靠 $request_length、$request_uri 和自定义变量组合识别。SSI 子请求的 $request_method 固定为 GET，$request_uri 是包含路径（如 /includes/header.html），且 $status 通常为 200，但没有客户端 IP 直连特征。
推荐在 log_format 中加入标识字段：
log_format subreq '[$time_local] $remote_addr - $remote_user [$request_time:$msec] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'subreq=$request_completion';其中 $request_completion 在子请求中为 "."（点），主请求为 "-"（短横），这是最稳定、无需额外模块的区分方式。
- 不要依赖
$connection或$connection_requests区分——它们在子请求中可能复用父连接，不可靠 - 若用
map做更细粒度标记，可基于$request_uri是否匹配/includes/或.shtml$后缀做布尔映射，但注意 map 变量在子请求中可读，需提前定义在http块 - SSI 文件若带查询参数（如
<!--#include file="nav.shtml?theme=dark"-->），$args会被记录，但原始 SSI 指令本身不会解析参数——那是应用层逻辑
mirror 指令产生的子请求日志行为差异
mirror 的子请求和 SSI 不同：它由 mirror 指令触发，目标地址是另一个 location，且默认继承父请求头（可配 mirror_request_body off 控制是否透传 body）。它的日志行为受两重控制：
-
log_subrequest on是前提，否则mirror子请求完全静默 - 子请求的
access_log指令必须显式启用——即使父 location 开了日志，mirror 目标 location 仍需单独配置access_log /path/to/mirror.log;，否则不落盘 -
$upstream_addr和$upstream_response_time在 mirror 子请求中有效，可用于判断镜像服务延迟；但$proxy_add_x_forwarded_for不自动注入，需手动加proxy_set_header
典型陷阱：mirror /mirror-api; 指向一个内部 location，但该 location 若只配了 proxy_pass 却没开 access_log，就看不到任何镜像流量日志，容易误判镜像未触发。
性能与调试注意事项
开启 log_subrequest 后，日志量可能翻倍甚至更高（尤其高嵌套 SSI 页面），磁盘 I/O 和格式化开销会上升，生产环境需权衡。
- 建议仅在 debug 阶段全局开启，上线后改用条件日志：例如
access_log /var/log/nginx/subreq.log subreq if=$log_subreq_flag;，配合map根据请求头或 URI 动态设$log_subreq_flag - SSI 包含深度超过 5 层时，Nginx 默认拒绝（
ssi_max_recursion），此时子请求根本不会生成，日志里也看不到——先检查 error log 中是否有rewrite or internal redirection cycle类报错 -
mirror子请求失败（如 upstream timeout）时，$status记录的是 mirror 子请求自身的响应码（如502），不影响父请求返回，但若想捕获失败，得靠error_log级别调到info或更高，并过滤mirror:关键字
真正难排查的，往往是子请求走了缓存（expires 或 add_header Cache-Control）导致日志里出现 304，却误以为内容没加载——这时要盯紧 $sent_http_cache_control 和 $sent_http_etag 字段。
