服务器上的nginx日志怎么查看,有哪些实用方法？

服务器上的nginx的日志怎么看？核心答案很简单：默认存放于 /var/log/nginx/ 目录下，分为 access.log（访问日志）和 error.log（错误日志），用 tail、grep、awk 三个命令就能完成 90% 的排查工作。

下面从路径定位、配置解读、实际操作到常见坑位，一步步带你吃透 nginx 日志。

加载中

NGINX如何查看日志？

J

Java个体户

1211--

原视频地址

服务器上的nginx的日志怎么看：先搞清楚日志文件在哪

2026年了,登录服务器第一件事别瞎翻，直接去默认位置找，绝大多数发行版（Ubuntu、Debian、CentOS、Rocky Linux）通过 apt 或 yum 安装的 nginx，日志目录固定在 /var/log/nginx/，进去之后你通常能看到三个东西：

• access.log：记录每一次 HTTP 请求，谁访问了、访问了什么、返回什么状态码
• error.log：记录 nginx 运行时的错误，比如配置语法错误、上游超时、磁盘满
• error.log.1 或 access.log.1：日志轮转后的历史文件，带数字后缀

如果这个目录空空如也,或者你根本找不到 nginx 文件夹，别急着慌，先确认 nginx 进程是否在跑，再执行下面的命令去配置里揪出真实路径。

用配置文件确认日志路径，别靠猜

nginx 的日志路径由配置文件决定，主配置文件通常是 /etc/nginx/nginx.conf，网站配置在 /etc/nginx/conf.d/ 或 /etc/nginx/sites-enabled/ 下面。

# 查看 nginx 主配置中的日志相关指令
grep -E "access_log|error_log" /etc/nginx/nginx.conf

输出结果里如果没有关闭日志的配置（access_log off），就会显示绝对路径，再看单个网站的配置文件：

# 查看默认站点的日志路径
grep -E "access_log|error_log" /etc/nginx/sites-enabled/default

grep 什么都没返回，说明日志路径被定义在 http 块或 server 块之外，可以向上翻配置，或者用下面这个命令一次性列出可能的位置：

# 枚举所有 nginx 相关目录
ls -lh /var/log/nginx/

访问日志和错误日志的分工

搞清楚 access 和 error 的区别，能让你的排查效率提升一大截。

• access.log：每条记录对应一次完整请求，包含客户端 IP、请求时间、请求方法、URI、状态码、响应字节数、User-Agent 等
• error.log：只在出问题时产生记录，upstream 超时、SSL 握手失败、目录权限不足、配置重载失败

说白了,一个负责记流水账，一个负责记病历，日常巡检看 access，系统出故障看 error，这个思路要立住。

nginx日志格式怎么看懂：解码 access.log 里每列的含义

打开 access.log，你会看到一堆密密麻麻的字符串，别被吓到，nginx 日志默认格式叫 combined，每一行按空格拆开是有固定顺序的。

0.0.1 – – [12/Feb/2026:09:18:22 +0800] “GET /api/user HTTP/1.1” 200 532 “https://example.com/home” “Mozilla/5.0 (Windows NT 10.0; Win64; x64)”

按空格和括号拆解：

• 0.0.1：客户端 IP，也就是谁发起的请求
• 第一个 – 是远程登录名，第二个 – 是认证用户，大多时候是占位符
• [12/Feb/2026:09:18:22 +0800]：请求时间，注意是服务器本地时间
• “GET /api/user HTTP/1.1”：请求方式、URI 和 HTTP 协议版本
• 200：状态码，200 正常，404 找不到，500 服务器内部错误
• 532：响应体字节数，不包含响应头
• “https://example.com/home”：来源页面，即用户是从哪个页面跳转过来的
• “Mozilla/5.0…”：客户端 UA，浏览器类型、系统信息都在这

想验证自定义日志格式长什么样,去 nginx.conf 里找 log_format 指令：

grep -A5 "log_format" /etc/nginx/nginx.conf

默认格式长这样：

log_format main  '$remote_addr - $remote_user [$time_local] "$request" '
                 '$status $body_bytes_sent "$http_referer" '
                 '"$http_user_agent"';

如果你想让请求耗时也出现在日志里,可以在 http 块内增加 \$request_time 字段，修改格式后记得重载 nginx 生效。

实操排查：用命令行实时和分析 nginx 日志

理论说完了,接下来说点能直接上手的东西，不管你是刚入门的小白还是运维老手，下面的命令都是高频使用的。

实时盯日志，看到访客进出

调试接口、看是否有爬虫骚扰、观察用户并发行为，用 tail 直接跟日志尾部最方便。

# 实时刷新日志，Ctrl+C 退出
tail -f /var/log/nginx/access.log
# 查看最后 200 行日志
tail -200 /var/log/nginx/access.log

如果你想只盯着某个接口的请求,加个 grep 过滤：

# 筛选 /api/login 接口的实时请求
tail -f /var/log/nginx/access.log | grep "/api/login"

独立服务器或云主机上排查攻击时,这个组合拳能快速揪出异常 IP 的扫描行为。

按状态码统计错误占比

想知道今天网站被 404 了多少次、500 报错有多少，一行 awk 就能统计出来。

# 统计 access.log 中各状态码出现的次数
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

输出效果像是：

 3821 200
  456 304
  128 404
   32 500

看到 500 不是零，就得去 error.log 里翻原因，404 特别多，大概率是图片防盗链或者爬虫在瞎扫路径。

找出访问量最大的 IP

防刷、封禁恶意 IP，需要知道谁在频繁请求。

# 统计访问次数最多的前 20 个 IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

如果某个 IP 的请求量是第二名的几十倍，通知业务方确认下是不是自然流量，不是的话考虑在防火墙层做限制。

分析慢请求，定位性能瓶颈

nginx 日志里没默认记录响应耗时，如果你配置了 \$request_time，可以这样查：

# 列出耗时超过 3 秒的请求 URI
awk '($NF > 3) {print $7, $NF}' /var/log/nginx/access.log | sort -k2 -rn | head -20

后端接口缓慢、数据库查询超时、PHP-FPM 阻塞，都会在 request_time 指标上暴露出来，行业共识认为，超过 70% 的性能毛刺都能从慢请求日志中直接找到线索。

error.log 怎么查：从错误日志定位故障源头

访问日志分析得再透彻,服务器真出问题还是得看错误日志，err 日志的位置和访问日志在同目录，名字叫做 error.log。

常见错误类别和应对方式

打开 error.log，你会遇到下面这几种高频错误：

• connect() failed (111: Connection refused)：nginx 连不上后端服务，PHP-FPM 没启动，或者 9000 端口被占用
• upstream timed out：后端处理请求超时，需要调大 proxy_read_timeout 或优化后端代码
• Permission denied：nginx 工作进程没有权限读取静态文件，常见于用户目录下的网站文件
• SSL_do_handshake() failed：客户端和服务器 SSL 握手失败，可能是证书链不完整或客户端不兼容

查看最后几条错误信息,快速掌握当前状态：

# 查看最近 20 条错误日志
tail -20 /var/log/nginx/error.log
# 持续观察，等复现
tail -f /var/log/nginx/error.log

用 nginx -t 验证配置，配合日志定位语法错误

改了配置导致 nginx 无法重启，这是新手最容易碰到的坑，解决方案是先用测试命令看报错：

/sbin/nginx -t

输出这段信息就说明配置没毛病：

nginx: configuration file /etc/nginx/nginx.conf test is successful

如果失败,nginx 会提示具体是哪个文件哪一行出了问题，此时打开 error.log 对照着看，报错编号和行号都是对应的，我遇到过很多次，用户在 server 块里漏写分号，error.log 直接把 keyword 都给你标出来了，照着改就行。

日志轮转与大日志维护：不重启 nginx 也照常切割

访问量一大,access.log 几天就能攒到几个 GB，磁盘被塞满导致服务异常，这在线上环境是不可接受的，好在系统自带的 logrotate 会自动管理日志文件。

logrotate 默认切割机制

大多数发行版安装 nginx 时，/etc/logrotate.d/nginx 就自动生成了，默认策略是：每天切割一次，保留 14 份历史档案，切割后压缩为 .gz 格式，比如今天的 access.log，明天凌晨变成 access.log.1，后天变成 access.log.2.gz。

手动执行一次轮转：

logrotate -f /etc/logrotate.d/nginx

执行之后检查一下日志目录,确认切割后的文件名和时间戳是否正常。

日志被误删后为什么 nginx 不重新创建

有人手贱删了 access.log，发现 nginx 一直不生成新文件，原因是 nginx 的工作进程依然持有旧文件的句柄，文件被删了句柄没断，写不进去新内容。

解决办法是重载配置,让进程重新打开日志文件：

nginx -s reload

这个操作不会中断服务,可以对线上环境使用，不要用 restart，那会断开所有连接。

日志文件被删了还能恢复吗？安全与隐私保护

访问日志里有真实来访者的 IP、请求参数、UA信息，如果做内容站点，日志里还可能包含用户的搜索词条，近年来，数据安全法对公民隐私信息的收集和使用愈发严格，处理日志时有几个细节值得注意：

• 不要把短期日志文件设置成 777 权限，避免其他用户读取到敏感数据
• 生产环境的 access.log 建议定期清理，保留 7 到 30 天即可满足排查需求
• 如果网站开启了 HTTPS，Post 请求参数在日志里通常不体现，但 GET 参数会完整记录

nginx 官方未提供自动脱敏功能，若业务涉及敏感字段，可以考虑接入第三方日志系统（如 Loki、ELK）做脱敏处理后再落盘。

Q&A：服务器上的nginx的日志怎么看不了怎么办

服务器上的nginx的日志怎么看不了，提示权限不足是为什么

nginx 目录默认只有 root 和 adm 组有读取权限，普通用户执行 tail 会提示 Permission denied，两个办法：一是切换到 root 用户执行 sudo tail -f /var/log/nginx/access.log；二是把当前用户加入 adm 组后重新登录，执行 usermod -aG adm 你的用户名，这样以后就能直接读了。

卸载nginx会删除日志吗

这要分两种情况,如果你用 apt remove nginx，配置文件和日志文件会被保留，方便以后重装；如果用 apt purge nginx，则会连配置文件一并清除，至于 /var/log/nginx 目录下的日志文件，即使 purge 也未必会被删除，因为日志文件属于独立的文件管理范围，多年运维经验告诉我，卸载前先手动备份日志才是稳妥做法。

日志是服务器留给你的最后一份现场记录,从定位文件路径到解析每一列含义，从实时追踪到错误排查，这套方法足够应对日常工作中九成以上的问题，下次遇到接口突然 502，别盯着代码发呆，先打开 nginx 日志看一眼。