log_subrequest指令用于控制是否记录子请求日志，默认off；仅在http或server块中生效，语法为log_subrequest on|off；子请求包括auth_request、echo_exec等内部发起的请求，不包含普通rewrite或return。

在 Nginx 中，log_subrequest 指令用于控制是否将子请求（subrequest）的访问日志写入 access_log。默认情况下，子请求的日志是**不记录**的，这是为了减少日志体积和避免冗余（例如内部重定向、auth_request、echo_exec、proxy_pass 前的 internal rewrite 等触发的子请求）。

log_subrequest 的作用范围与启用方式

该指令仅在 http 块或 server 块中生效，语法为：

log_subrequest on | off;

默认值为 off。要开启子请求日志，需显式设置为 on：

• 放在 http 块中，对全局所有 server 生效；
• 放在某个 server 块中，则只对该虚拟主机生效；
• 不能在 location 块中使用（Nginx 会报错："log_subrequest" directive is not allowed here）。

哪些请求会被视为“子请求”？

子请求是 Nginx 内部发起的、非客户端直接发起的请求，常见场景包括：

• auth_request 指令触发的鉴权子请求（如调用后端鉴权服务）；
• satisfy any 或 satisfy all 配合 allow/deny 与 auth_request 混合使用时的内部校验；
• echo_exec（需 echo 模块）、post_action、try_files 中的内部跳转（部分情况）；
• ngx_http_subrequest API 调用（如第三方模块内部发起）。

注意：普通 rewrite ... last 或 return 301 不产生子请求，而是重定向或内部重写，不触发 log_subrequest 控制逻辑。

开启后日志内容与注意事项

开启 log_subrequest on 后，子请求会像普通请求一样走完整的日志流程，使用当前作用域配置的 log_format 和 access_log。但要注意：

• 子请求的 $request、$uri、$args 等变量反映的是子请求自身信息，不是原始请求；
• 子请求不会触发 log_format 中的 $status 异常标记（如 upstream error），除非它本身失败；
• 高频子请求（如每个请求都带 auth_request）会导致日志量显著增加，建议配合日志轮转与监控；
• 若同时使用多个子请求（如嵌套 auth_request），每一层都会单独记一条日志。

验证是否生效的小技巧

可结合 auth_request 和自定义日志格式快速验证：

• 配置一个简单的鉴权 location（如返回 204）；
• 主 location 使用 auth_request /auth；
• 在 http 块中设置 log_subrequest on 并启用 access_log；
• 访问主接口，观察日志中是否出现 /auth 对应的条目（method 通常为 GET，uri 为 /auth）。

如果看到该条目，说明子请求日志已生效。