排查 Nginx 问题时，日志往往比现象本身更有价值，但日志开得太细，又会迅速带来磁盘占用和排查噪音。本文围绕 error_log 和 access_log 两个核心指令，按“在哪里改、怎么改、改到什么程度合适”的顺序梳理配置方法，并结合默认值与常见场景，帮助你判断什么时候该开详细日志，什么时候只保留必要记录。

先找到要修改的 Nginx 配置文件

设置日志级别前，先确认当前实例使用的是哪份配置。最常见的主配置文件路径是：

/etc/nginx/nginx.conf

如果你按站点拆分配置，也可能是在站点配置文件里修改，例如：

/etc/nginx/sites-a vailable/your_domain.conf

实际修改时，可以在 http、server 或 location 块中设置日志指令。作用范围不同，生效对象也不同：放在更外层，影响范围更大；放在具体站点或路径块中，则更适合局部排错。

error_log 如何设置日志级别

error_log 用来控制错误日志记录的详细程度。可选级别从低到高依次为：

debug
info
notice
warn
error
crit
alert
emerg

默认级别是 error。如果你需要临时开启更详细的调试信息，可以这样写：

error_log /var/log/nginx/error.log debug;

这条配置表示把错误日志写入 /var/log/nginx/error.log，并使用 debug 级别输出更完整的信息。它适合定位复杂问题，但不适合长时间放在生产环境中持续开启。

access_log 如何设置访问日志格式

与 error_log 不同，access_log 这里主要控制的是访问日志的记录格式。文中给出的可选项包括：

combined
common
small
med
full

默认是 combined。例如：

access_log /var/log/nginx/access.log combined;

这条配置表示把访问日志写入 /var/log/nginx/access.log，并按 combined 格式记录。访问日志通常用于分析请求来源、状态码、访问路径和请求行为，因此格式越完整，后续分析空间越大，但日志体积也可能随之增加。

修改完成后如何让配置生效

编辑完成后，保存配置文件并退出编辑器，然后重新加载 Nginx：

sudo nginx -s reload

执行这条命令后，Nginx 会按新配置重新加载日志设置。这样通常不需要直接重启服务，就能让修改立即生效。

生产环境应该把日志开到什么程度

日志并不是越详细越好。像 debug 这样的级别虽然信息最全，但写入量也最大，持续开启很容易让日志文件快速膨胀。

因此更稳妥的做法是：

• 日常运行保持较低但够用的级别；
• 只有在排错时，才临时提高到更详细的级别；
• 问题定位完成后，及时恢复到常规配置。

对于生产环境，除非正在处理具体故障，否则一般不建议长期使用 debug。核心原则只有一个：记录到足够判断问题即可，不要为了“以防万一”把日志开到最细。