应重定义http块顶部的log_format combined以全局生效，加入$request_time字段，并确保access_log未显式指定其他格式；需nginx -t验证后reload，再检查日志末尾是否有响应时间。
在 Nginx 的 http 块中配置全局默认日志格式，核心是使用 log_format 定义格式名称，并确保后续 access_log 指令引用该名称（或不显式指定时依赖默认行为）。Nginx 本身没有“强制覆盖所有 location 的隐式默认格式”，但可通过合理配置实现事实上的全局生效。
定义 log_format 并命名为 combined 或 main
Nginx 内置名为 combined 和 main 的默认格式。如果你希望所有未显式指定 format 的 access_log 都按你的规则输出，最稳妥的方式是重定义 combined（它是 access_log 指令的默认值）：
- 在
http块顶部（早于任何server块）取消注释或新增：
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$request_time"';
这会覆盖 Nginx 自带的 combined 格式，加入响应时间 $request_time，且不影响已有 access_log logs/access.log; 这类无 format 参数的写法。
确保 access_log 使用该格式
全局默认效果依赖于 access_log 的写法习惯：
- 写成
access_log /var/log/nginx/access.log;→ 自动采用combined格式 - 写成
access_log /var/log/nginx/access.log combined;→ 明确指定，更清晰 - 若某处写了
access_log ... custom;，则以该custom为准，不继承全局
避免常见失效陷阱
以下操作会导致你定义的格式不生效：
-
log_format放在server或location块内 → 作用域仅限当前块 - 只改了
log_format却没重启 Nginx（nginx -s reload）→ 配置未加载 -
access_log指令写在http块顶层（而非server内）→ 语法错误，Nginx 启动失败 - 多个
log_format combined ...重复定义 → 后定义者覆盖前定义者，但易引发维护混乱
验证是否生效
修改后执行：
-
nginx -t确认语法正确 -
nginx -s reload重载配置 -
tail -1 /var/log/nginx/access.log查看最新日志行末尾是否出现类似"0.023"的响应时间字段
