access_log采用“同层追加、跨层替换”机制：同一server内多条指令并存，location内配置则完全取代server级配置；server中设access_log off会彻底禁用日志，不可回退。

全局块（http 块）中配置的 access_log 是默认日志策略，仅对未显式声明该指令的 server 块生效；一旦某个 server 块内写了 access_log，就会完全屏蔽 http 块的配置——不是叠加，而是替换。

access_log 属于 Array 类型指令，继承逻辑特殊

它不遵循“子级覆盖父级值”的普通逻辑，而是“同层追加、跨层替换”：

• 在同一个 server 块里写两条 access_log，会同时启用两个日志文件
• 但在其嵌套的 location 块里再写一条 access_log，则 server 级的全部配置失效，只用 location 里这一条
• http 块里的 access_log 只是兜底，只要 server 显式声明，就不再参与任何日志输出

server 块显式关闭日志时，全局配置彻底失效

如果某个 server 块写的是 access_log off;，表示该虚拟主机完全不记录访问日志，此时 http 块中的路径和格式配置不会回退启用，也不会写入任何文件。

Accessibility Review

对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。

下载

• 这种关闭是硬性终止，不是临时跳过
• 若想部分路径禁用日志，应在 location 中用 access_log off;，而不是在 server 层关闭
• 注意：关闭后无法通过上层配置恢复，必须在同级或更内层重新开启

实际配置中常见误判点

很多问题不是写错语法，而是没意识到 access_log 的替换特性：

• 在 server 里配了日志，又在某个 location 里加了一行 access_log，结果发现主日志停了——这是正常行为，不是 bug
• 多个 location 各自配置不同日志路径，它们互不影响，但每个都独立取代了 server 级配置
• 想让某类请求（如图片）不记日志，不能只在 location ~ \.(jpg|png)$ 里关掉，还要确认其他 location 没重复开启，否则可能漏控

推荐的配置习惯

避免意外覆盖，提升可维护性：

• 在 http 块中统一定义精简格式（如去掉 $http_user_agent），并启用缓冲：access_log /var/log/nginx/access.log main buffer=64k flush=5s;
• 各 server 块按需启用，路径按站点命名（如 example.com.access.log），不依赖继承
• 敏感接口（如登录、支付）单独用 location 配置独立日志，并过滤关键字段（用 log_format 自定义字段或配合 map 模块脱敏）
• 调试时用 nginx -t + nginx -T 查看最终生效配置，确认日志路径是否如预期被替换