log_subrequest on 会使Nginx记录子请求日志，其核心逻辑在ngx_http_log_handler中判断r->parent是否为空；默认off时直接跳过，开启后使用子请求自身的uri、status等变量独立记录，适用于auth_request、SSI、try_files等场景。
启用 log_subrequest 后，Nginx 会将内部子请求（如 subrequest、auth_request、try_files 触发的内部跳转、SSI 包含等）的访问日志单独记录，但默认不开启——因为子请求共享主请求的连接和上下文，日志混入主请求易造成语义混乱。要真正看清模块间如何协作，得从源码中理解子请求的生命周期与日志注入点。
子请求不是“新连接”，而是共享上下文的轻量级请求对象
Nginx 的子请求（ngx_http_subrequest_t）并非新建 socket 或重走 event loop，而是复用主请求的 ngx_http_request_t 结构体，通过 r->main 指向原始主请求，r->parent 指向发起者，形成父子链。关键点：
- 子请求共用同一连接（
r->connection），但拥有独立的r->uri、r->args、r->headers_in等逻辑字段 - 子请求不触发
ngx_http_init_request，跳过读取请求行/头阶段，直接进入ngx_http_core_run_phases -
log_subrequest的作用，是让ngx_http_log_handler在写日志前检查r->parent != NULL，并据此决定是否输出该条日志
log_subrequest on 如何影响日志写入流程
核心逻辑在 src/http/ngx_http_log_module.c 的 ngx_http_log_handler 中：
- 若配置为
off（默认），函数开头即判断if (r->parent) { return NGX_OK; }，直接跳过日志记录 - 若配置为
on，则继续执行格式化与写入，但注意：子请求的日志使用的是它自己的r->start_time、r->status、r->uri，而非主请求的 - 日志变量如
$request、$status展开时，取的是子请求上下文，因此能真实反映子请求行为（例如auth_request子请求记录的是认证服务返回的 200/401，而非主请求最终状态）
哪些模块会生成被记录的子请求？不只是 subrequest 指令
只要调用 ngx_http_subrequest API，且未显式禁用日志（如设置 r->log->log_level & NGX_LOG_DEBUG_HTTP 不足），就可能被记录。常见来源包括：
-
ngx_http_auth_request_module：每个auth_request指令都会发起一个子请求，用于权限校验 -
ngx_http_ssi_filter_module：生成子请求获取片段内容 -
ngx_http_try_files：当文件不存在时，按顺序尝试 URI 列表，每次 fallback 都是子请求（注意：部分版本中仅最后一条 fallback 是子请求，需结合NGX_HTTP_TRY_FILES宏确认） - 第三方模块如
lua-nginx-module的ngx.location.capture，底层也调用相同 subrequest 接口
调试建议：配合 debug 日志 + 自定义 log_format 看清调用链
单靠 access log 不足以还原父子关系，推荐组合使用：
- 开启
error_log /path/error.log debug_http;，搜索"subrequest: "关键字，可看到类似subrequest: "/auth" ? "u=alice"的 trace - 在
log_format中加入$request_id和自定义变量标识层级：log_format subreq '$request_id [$time_local] "$request" $status $parent_request_id';（需 patch 或用 lua 注入$parent_request_id） - 注意：子请求的
$request_id与主请求不同（Nginx 为每个 request 分配唯一 ID），但可通过r->parent->request_id关联，需模块支持或 debug 日志佐证
