服务器上的nginx的日志怎么看？核心答案很简单：默认存放于 /var/log/nginx/ 目录下，分为 access.log（访问日志）和 error.log（错误日志），用 tail、grep、awk 三个命令就能完成 90% 的排查工作。
下面从路径定位、配置解读、实际操作到常见坑位，一步步带你吃透 nginx 日志。
服务器上的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 日志看一眼。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771544.html
