nginx日志配置怎么做？nginx日志格式怎么自定义，日志切割方法

nginx日志配置不是简单打开 access_log 开关，而是需要围绕可观测性、安全性、成本三个维度做整体设计，合理的做法是：用 JSON 格式输出结构化日志，按业务维度拆分文件并设置切割周期，用日志服务做集中归档与告警，同时对敏感字段做脱敏，这样可以将故障定位时间缩短一半以上，同时避免磁盘被日志写满导致核心服务异常。

日志格式：为可解析而配置

默认的 combined 格式字段有限，缺少耗时和上游信息，很难做性能分析，建议自定义 log_format，至少包含以下字段：

• 时间字段：$time_local，统一所有日志时间基准。
• 请求字段：$request_method、$request_uri、$server_protocol。
• 状态字段：$status、$body_bytes_sent。
• 性能字段：$request_time、$upstream_response_time，用于定位后端慢请求。
• 来源字段：$http_referer、$http_user_agent，用于分析访问来源。

推荐直接使用 JSON 格式输出，

log_format json_log escape=json '{"time":"$time_local","remote_addr":"$remote_addr","method":"$request_method","uri":"$request_uri","status":$status,"request_time":$request_time,"upstream_time":"$upstream_response_time"}';

JSON 格式的好处是日志采集器无需写复杂正则，检索、统计和告警效率更高，需要特别提醒的是，

不要在 JSON 格式中记录 Cookie、Authorization 等敏感信息，否则一旦日志泄露，账号安全会直接受影响。

访问日志与错误日志分离

很多服务器把 access_log 和 error_log 混写在同一个目录，排查问题时很难快速定位，建议明确分离：

access_log /var/log/nginx/access.log json_log;
error_log  /var/log/nginx/error.log warn;

error_log 级别不要在生产环境使用 debug，会大量消耗磁盘 IO，严重影响 Nginx 性能。推荐使用 warn 或 error，排障时可在单个 location 区域内临时开启更高日志级别，排查结束立即关闭，这是更稳妥的做法。

日志切割：定时轮转避免磁盘写满

日志文件会不断增长,单文件过大会导致检索缓慢，也容易占满磁盘。使用 logrotate 是最简单成熟的方案，示例配置如下：

/var/log/nginx/.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 644 www-data www-data
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

这段配置按天切割,保留 7 天，压缩旧日志，并通过 USR1 信号通知 Nginx 重新打开日志文件。注意：必须使用信号让 Nginx 重新打开文件，否则日志会继续写入被删除的旧 inode 中。

日志分析：从被动查错到主动预警

只把日志存下来还不够,要从中提取业务价值，小型业务可以在服务器上使用 GoAccess 快速查看实时流量；中大型业务建议将 Nginx 日志接入集中式日志平台，将访问状态、响应耗时、客户端分布统一展示，并配置以下告警：

• 5xx 状态码突增，如 5 分钟内错误率超过 3%。
• 单一 IP 请求频率超过阈值，可能为攻击行为。
• 平均响应时间超过 2 秒时触发通知。

这样日志就从“事故后的黑匣子”变成了“故障前的报警器”。

安全与隐私脱敏

Nginx 日志可能包含用户真实 IP、URL 参数中的敏感数据，直接存明文存在合规风险，建议：

• 在 log_format 中省略 Cookie、授权头等字段。
• 使用 map 对手机号、身份证等敏感参数做打码处理。
• 在日志文件层级设置独立用户和权限,禁止普通用户读取。
• 归档到内部日志系统后,定时清理超出保存周期的数据。

安全配置不只影响合规，也决定日志系统能否长期稳定运行。

酷番云经验案例：日志上云，稳定持久

我们曾处理过一个托管在酷番云的高流量电商客户，初始把所有 Nginx 日志写在系统盘，结果不到一个月系统盘被 20GB 日志占满，导致数据库备份失败，业务出现间歇性不可用，我们的处理方案是：

• 将日志目录迁移到酷番云数据盘,并保留原路径软链接，避免 Nginx 重载失败。



• 接入酷番云日志服务,安装日志采集 Agent，自动解析 Nginx JSON 字段。
• 配置按访问量和 5xx 状态码的实时告警，日志统一留存 180 天。
• 将超过 30 天的冷日志自动归档到酷番云对象存储，降低存储成本。

改造完成后,客户故障定位时间从小时级降到分钟级，磁盘告警彻底清零。把日志视为核心数据资产，而不是可丢弃的临时文件，是稳定运维的分水岭。

相关问答

Nginx 日志里很多请求没有 User-Agent，是攻击吗？

不一定是攻击,健康检查、curl 脚本、老版本 WebSocket 客户端都可能不发送 User-Agent，建议先关联来源 IP、请求路径和频率判断，如果出现高频访问大量敏感路径，应在 WAF 或 Nginx 层直接拦截，而不是等日志落盘后再清洗。

Nginx 开启 access_log 后性能下降明显，如何处理？

先确认日志写入盘是否为机械盘,如果条件允许，优先将日志目录放到 SSD 数据盘，其次精简 log_format 字段，去掉无用维度，还可以使用缓冲写入参数降低 IO 次数，

access_log /var/log/nginx/access.log json_log buffer=32k flush=5s;

该配置表示每攒够 32KB 或间隔 5 秒写一次盘，对高并发场景有明显优化效果。

看完这篇 nginx 日志配置，你是否也遇到过日志过大导致磁盘爆满的经历？欢迎在评论区分享你的处理办法，或者把你想了解的 Nginx 问题告诉我，我来帮你拆解。