详细讲解 Nginx 中的 access.log 和 error.log 这两个核心日志文件。

它们是理解服务器运行状况、排查问题、分析流量和性能调优的关键。

核心摘要

特性 access.log (访问日志) error.log (错误日志)
​​记录内容​​ 所有客户端访问请求的记录 Nginx 服务运行时的​​事件​​和​​错误​​信息
​​日志级别​​ 不适用（记录所有成功和失败的请求） debug, info, notice, ​​warn​​, ​​error​​, crit, alert, emerg
​​主要用途​​ 流量分析、行为分析、安全审计、性能监控 ​​故障排查​​、调试配置、监控服务器健康状态
​​默认路径​​ /var/log/nginx/access.log /var/log/nginx/error.log
​​格式​​ 可高度自定义（使用 log_format 指令） 相对固定，包含时间、级别、消息内容等

1. access.log (访问日志)

访问日志记录了每一个向 Nginx 服务器发起的客户端请求。通过分析它，你可以知道谁在什么时候访问了什么内容，以及结果如何。

默认日志格式

Nginx 的默认访问日志格式通常被称为 ​​“组合日志格式” (Combined Log Format)​​。一条典型的记录看起来像这样：

192.168.1.100 - - [12/Sep/2023:10:25:30 +0800] "GET /images/logo.png HTTP/1.1" 200 1845 "https://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36"
字段解析：
  1. ​​192.168.1.100​​：客户端的 IP 地址。
  2. ​​-​​：由 identd 协议确定的用户身份（通常为破折号 -，因为此协议已不再使用）。
  3. ​​-​​：HTTP 认证的用户名（如果请求需要认证，否则为 -）。
  4. ​​[12/Sep/2023:10:25:30 +0800]​​：请求的时间戳，包括时区。
  5. ​​"GET /images/logo.png HTTP/1.1"​​：请求行，包括​​请求方法​​ (GET)、​​请求的URI​​ (/images/logo.png) 和​​协议版本​​ (HTTP/1.1)。
  6. ​​200​​：HTTP ​​状态码​​。这是最重要的字段之一。
    • 2xx：成功（如 200 OK）
    • 3xx：重定向（如 301 Moved Permanently, 304 Not Modified）
    • 4xx：客户端错误（如 ​​404 Not Found​​, 403 Forbidden）
    • 5xx：服务器错误（如 ​​502 Bad Gateway​​, 504 Gateway Timeout, 500 Internal Server Error）
  7. ​​1845​​：服务器返回给客户端的​​响应体大小​​（字节数），不包括响应头。
  8. ​​"https://example.com/"​​：​​Referer​​ 请求头，表示用户是从哪个页面链接过来的。
  9. ​​"Mozilla/5.0 ..."​​：​​User-Agent​​ 请求头，表示客户使用的浏览器、操作系统和设备信息。
自定义日志格式

你可以在 Nginx 配置文件中使用 log_format 指令定义自己的格式。例如，添加一个记录请求处理时间的格式非常有用：

# 在 http {} 块中定义一种名为 'main' 的日志格式
http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      '$request_time $upstream_response_time';

    # 在 server {} 或 location {} 块中使用这种格式
    server {
        access_log  /var/log/nginx/access.log  main;
        ...
    }
}
  • ​​$request_time​​：处理请求所花费的总时间（秒），从读取客户端第一个字节到发送完响应最后一个字节。
  • ​​$upstream_response_time​​：Nginx 向后端服务器（如 PHP-FPM, Tomcat）发起请求到接收完响应所花费的时间。对于诊断后端性能问题至关重要。
  • ​​$http_x_forwarded_for​​：当服务器位于负载均衡器或CDN之后时，这个头通常包含客户端的真实IP。

2. error.log (错误日志)

错误日志记录了 Nginx 服务运行时遇到的各种事件和问题，从调试信息到严重错误。它的详细程度由设置的日志级别决定。

日志级别 (从低到高)
  • debug：最详细的调试信息，通常只在开发或深度排查时使用。
  • info：一般信息性消息。
  • notice：正常但值得注意的事件。
  • warn：警告信息，可能的问题，但不会影响服务。
  • error：处理请求时遇到的错误（如连接上游服务器失败）。
  • crit：临界错误，需要立即关注。
  • alert：需要立即采取行动的严重错误。
  • emerg：系统不可用的紧急错误。
常见错误信息示例

  1. ​​权限被拒绝 (Permission denied)​​

    2023/09/12 10:25:30 [error] 12345#0: *100 open() "/var/www/html/secret.txt" failed (13: Permission denied), client: 192.168.1.100, server: example.com, request: "GET /secret.txt HTTP/1.1", host: "example.com"
    • ​​原因​​：Nginx worker 进程（通常是 www-data 或 nginx 用户）没有读取该文件的权限。

  2. ​​文件不存在 (No such file or directory)​​

    2023/09/12 10:26:15 [error] 12345#0: *101 open() "/var/www/html/missing.jpg" failed (2: No such file or directory), client: 192.168.1.100, server: example.com, request: "GET /missing.jpg HTTP/1.1", host: "example.com"
    • ​​原因​​：请求的文件在服务器上不存在。这通常会在 access.log 中产生一个 404 状态码。

  3. ​​无法连接到上游服务 (Connection refused to upstream)​​

    2023/09/12 10:27:00 [error] 12345#0: *102 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.100, server: example.com, request: "GET /api/ HTTP/1.1", upstream: "http://127.0.0.1:8080/api/", host: "example.com"
    • ​​原因​​：Nginx 无法连接到配置的后端服务器（如 Tomcat, Node.js, PHP-FPM）。可能原因是后端服务没有启动或监听端口错误。这通常会在 access.log 中产生一个 502 或 504 状态码。

  4. ​​上游响应超时 (Upstream timed out)​​

    2023/09/12 10:28:30 [error] 12345#0: *103 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.100, server: example.com, request: "GET /slow-query/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "example.com"
    • ​​原因​​：后端服务器处理请求时间过长，超过了 Nginx 配置的 proxy_read_timeout 或 fastcgi_read_timeout 值。

  5. ​​配置错误​​

    2023/09/12 09:00:00 [emerg] 12345#0: unknown directive "stubstaus" in /etc/nginx/conf.d/status.conf:1
    • ​​原因​​：Nginx 配置文件中有语法错误或使用了未知指令。通常在重载或重启 Nginx 时出现，会导致 Nginx 启动失败。

管理与最佳实践

  1. ​​日志轮转 (Log Rotation)​​
    日志文件会不断增长，需要定期切割和归档。Linux 系统通常使用 logrotate 工具来管理，Nginx 安装后通常会自带一个配置文件 (/etc/logrotate.d/nginx)。它会自动按天或按周切割日志，并压缩旧文件。

  2. ​​调试技巧​​

    • ​​实时查看日志​​：使用 tail 命令。 
      # 实时查看访问日志
tail -f /var/log/nginx/access.log

# 实时查看错误日志
tail -f /var/log/nginx/error.log

# 实时查看错误日志，并过滤出 ‘error’ 级别的记录
tail -f /var/log/nginx/error.log | grep -i error
    • ​​关联分析​​：当在 access.log 中发现一个 502 错误时，立即去查看同一时间点的 error.log，通常能找到对应的详细错误信息。

  3. ​​性能考虑​​
    在高流量网站下，记录过多信息（如完整的 User-Agent）或使用 debug 级别可能会影响磁盘 I/O 和性能。应根据实际需求定制日志格式和级别。

总结来说，access.log 是你了解​​谁来了​​和​​干了什么​​的窗口，而 error.log 则是你了解​​服务器哪里不舒服​​的诊断报告。两者结合使用，是管理和维护一个健康 Nginx 服务器的必备技能。

# nginx # 运维
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

AI动漫角色生成技术全解析

技术背景与现状 动漫角色生成的技术分类（GAN、Diffusion Models等）当前主流工具与框架（Stable Diffusion、NovelAI等）行业应用案例（游戏、影视、插画设计） 比赛核心技术与难点 角色一致性保持（多角度、多姿态生成）细节控制（服饰、发型、色彩风格）数据需求与版权问题（训练集构建） 参赛方案设计要点 模型选型与微调策略（LoRA、ControlNet等轻量级适配）提

avatar 2048 AI社区

Murati的thinking machines的论文到底讲了什么

这几周比较忙，也没看啥也没写啥（主要在打街霸6的天梯），但是这个论文我扫了一眼还是有价值的，所以给大家解读一下这个论文：https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/其实对于这个解决了什么问题，没那么抽象比如让gpu算一个浮点数，基本算几次可能结果都不一样。浮点数最后影响了概率，概率分布和采样影

avatar 2048 AI社区

AI安全评估的5个常见错误，提示工程架构师必避免

内部系统信息：API密钥、数据库密码、服务器IP；公司政策：隐私政策、安全规则、员工福利；技术操作：服务器配置、数据库操作、代码部署。哪些内容是绝对不能回答的？（比如违法请求、隐私信息）；哪些内容是需要限制的？（比如代码生成、外部链接）；哪些场景是高风险的？（比如多轮对话、隐式攻击）。AI安全评估不是“走流程”，而是站在攻击者的角度，用对抗性思维找漏洞。本文讲的5个错误，本质上都是**“评估视角太

avatar 2048 AI社区