应用实践｜Nginx 日志详细解析

Nginx 日志概述

日志是服务器运维、问题排查、用户行为分析的核心依据。不同服务器（如 Nginx、Apache、Tomcat）的日志格式虽有差异，但核心逻辑均围绕 “记录请求与响应关键信息” 展开。本文将以 Nginx 日志为核心，从格式定义、字段解析、日志类型、实战场景等维度进行全面解析。Nginx 日志是服务器运行与业务运维的 “核心仪表盘”，其重要性贯穿于技术保障与业务优化的全流程。

Nginx 日志核心解析

Nginx 日志分为两类：访问日志（Access Log） 和 错误日志（Error Log），在主配置文件nginx.conf或虚拟主机配置 /etc/nginx/conf.d/nginx.conf定义。首先得找到nginx的所在位置，然后根据其配置信息找到日志信息。

1. 访问日志（Access Log）

访问日志是最常用的日志类型，记录 “谁在什么时间、用什么方式、访问了什么资源、服务器如何响应” 等信息，需先通过 log_format 定义格式，再通过 access_log 指定日志存储路径。说人话就是定义访问日志的路径、格式和缓冲区大小，记录所有用户请求。

（1）默认日志格式与自定义格式

Nginx 有一个默认的简单格式（无需显式定义），但生产环境中通常会自定义更详细的格式（如包含请求体大小、响应时间、用户代理等）。

自定义详细格式样例

# 定义 main_detail 格式（换行仅为可读性，实际配置可写为一行）
log_format main_detail
    '$remote_addr - $remote_user [$time_local] '                # 客户端基础信息 + 请求时间
    '"$request" $status $body_bytes_sent '                     # 请求核心信息 + 响应状态与大小
    '"$http_referer" "$http_user_agent" '                      # 来源页 + 客户端设备特征
    '$request_time $upstream_response_time '                   # 性能指标：总耗时 + 上游服务耗时
    '$http_x_forwarded_for $scheme $server_name '              # 代理场景真实IP + 协议 + 站点域名
    '$request_method $request_uri';                            # 单独拆分请求方法与请求路径

# 启用该格式（全局生效或绑定到具体 server 块），全局生效（在 http 块中配置）
access_log /var/log/nginx/access.log main_detail;

# 或仅对某站点生效（在 server 块中配置，优先级高于全局）
server {
    listen 80;
    server_name example.com;
    access_log /var/log/nginx/example.com-access.log main_detail;  # 站点专属日志文件
    # 其他站点配置...
}

（2）核心字段解析（按自定义格式顺序）

自定义格式中的 $变量名 是 Nginx 内置变量，对应日志中的具体值，下表为高频字段的详细解释：

（3）HTTP 响应状态码含义（核心排查依据）

$status 字段的状态码直接反映请求结果，常见状态码分类如下：

• 2xx（成功）：请求正常处理
  • 200 OK：请求成功（最常见）
  • 206 Partial Content：断点续传（如视频分片下载）
• 3xx（重定向）：请求需进一步处理
  • 301 Moved Permanently：永久重定向（如 HTTP 跳 HTTPS）
  • 302 Found：临时重定向
  • 304 Not Modified：缓存命中（客户端使用本地缓存，无需重新下载）
• 4xx（客户端错误）：请求存在问题，服务器无法处理
  • 400 Bad Request：请求参数错误（如格式非法）
  • 401 Unauthorized：需 HTTP 认证（未登录或令牌失效）
  • 403 Forbidden：服务器拒绝访问（如权限不足、IP 黑名单）
  • 404 Not Found：请求的资源不存在（URL 错误或文件删除）
  • 405 Method Not Allowed：请求方法不支持（如用 GET 访问仅允许 POST 的接口）
• 5xx（服务器错误）：服务器处理请求时出错
  • 500 Internal Server Error：服务器内部未知错误（如代码 BUG）
  • 502 Bad Gateway：Nginx 无法连接上游服务（如 Tomcat 宕机、端口错误）
  • 503 Service Unavailable：服务器暂时不可用（如过载、维护）
  • 504 Gateway Timeout：Nginx 等待上游服务响应超时（如上游服务处理过慢）

2. 错误日志（Error Log）

错误日志记录 Nginx 自身运行错误（如配置错误、连接失败）或请求处理中的异常（如无法连接上游服务），格式无需自定义，由 Nginx 自动生成，核心配置为 error_log。

（1）配置示例

# 格式：error_log 日志路径 日志级别;
error_log /var/log/nginx/error.log warn;

（2）日志级别（从低到高，包含关系）

日志级别决定记录的错误详细程度，生产环境推荐 warn 或 error（避免日志过大），调试时用 debug（需 Nginx 编译时开启 debug 模块）：

（3）错误日志示例与解析

2025/08/31 19:35:00 [error] 1234#0: *567 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.100, server: example.com, request: "GET /api/data HTTP/1.1", upstream: "http://127.0.0.1:8080/api/data", host: "sfasfasf.com"

• 核心信息拆解：
  1. 时间：2025/08/31 19:35:00
  2. 级别：[error]
  3. 进程 ID：1234#0（#0 为线程 ID）
  4. 连接 ID：*567（Nginx 内部标识该请求的连接）
  5. 错误原因：connect() failed (111: Connection refused)（连接上游服务被拒绝）
  6. 客户端信息：client: 192.168.1.100
  7. 请求信息：request: "GET /api/data HTTP/1.1"
  8. 上游服务：upstream: "http://127.0.0.1:8080/api/data"（目标上游服务地址）

其他常见服务器日志对比

除 Nginx 外，Apache（HTTP Server）和 Tomcat（Java 应用服务器）的日志格式与 Nginx 相似，但存在细节差异，下表对比核心信息：

日志实战之常见场景排查示例

了解日志解析后，需结合实际场景定位问题，以下是我常遇到的高频场景以及排查思路：

场景 1

用户反馈 “页面打不开，显示 502”

1. 查看 Nginx 访问日志：确认 $status 为 502，$upstream_response_time 为 -（表示未连接到上游）。
2. 查看 Nginx 错误日志：搜索关键词 502 或 Connection refused，若日志显示 connect() failed (111: Connection refused) while connecting to upstream，说明 Nginx 无法连接上游服务（如 Tomcat）。
3. 验证上游服务：执行 telnet 127.0.0.1 8080（假设上游端口为 8080），若提示 “连接拒绝”，则上游服务（Tomcat）未启动，需重启 Tomcat 并查看 catalina.out 日志定位启动失败原因（如端口被占用、配置错误）。

场景 2

网站访问速度慢，排查瓶颈

1. 查看 Nginx 访问日志：重点关注 $request_time（总时间）和 $upstream_response_time（上游时间）。
   • 若 $upstream_response_time 较大（如 >1s）：瓶颈在上游服务（如 Tomcat 处理慢），需查看 Tomcat 应用日志（如 SQL 执行慢、代码逻辑耗时）。
   • 若 $upstream_response_time 小（如 <0.1s），但 $request_time 大：瓶颈在 Nginx 或网络，需检查 Nginx 配置（如是否开启 gzip、缓存）或客户端网络（如 $remote_addr 来自海外，需考虑 CDN 加速）。

场景 3

发现 “大量 403 错误，来自同一 IP”

1. 查看 Nginx 访问日志：筛选 $status=403 且 $remote_addr=192.168.1.200 的请求，确认请求的 URL（如 /admin/login）。
2. 分析原因：
   • 若 URL 为管理后台：可能是该 IP 无访问权限（如 Nginx 配置了 allow 192.168.1.0/24; deny all;，而 192.168.1.200 不在允许列表）。
   • 若 URL 为普通资源：可能是文件权限不足（如 Nginx 运行用户 nginx 无读取 /var/www/html/xxx.jpg 的权限），需执行 chmod 644 /var/www/html/xxx.jpg 修正权限。

日志管理

日志会持续生成，若不管理会导致磁盘占满，同时原始日志查询效率低，避免日志膨胀与提高查询效率，需配合以下工具优化。

日志切割：使用 logrotate（Linux 自带工具）按天 / 按大小切割日志，避免单个日志文件过大。示例配置（/etc/logrotate.d/nginx）如下：

/var/log/nginx/*.log {
daily               # 按天切割
rotate 7            # 保留7天日志
compress            # 压缩旧日志（gzip）
delaycompress       # 延迟压缩（保留当天日志不压缩）
missingok           # 日志文件不存在时不报错
notifempty          # 空日志不切割
create 0640 nginx nginx  # 新建日志文件的权限和所有者
}

日志分析工具：对于大规模日志（如日活百万级网站），需使用 ELK Stack（Elasticsearch + Logstash + Kibana）或 Grafana Loki 等工具，实现日志的收集、存储、检索和可视化（如按状态码统计请求量、按 IP 统计访问次数）。

总结

日志是服务器的 “黑盒记录仪”，核心在于下面三个点：

1. 理解格式： Nginx/Apache/Tomcat 日志的核心字段含义，尤其是 $status（状态码）、$request_time（响应时间）、错误原因描述。
2. 关联场景：将日志字段与实际问题结合（如 502 对应上游故障、慢响应对应 $upstream_response_time ）。
3. 规范管理：通过切割、分析工具保障日志可用性，避免成为 “磁盘杀手”。