用Nginx日志定位网站访问问题

网站打开异常时，先看真正处理该请求的站点日志。一个服务器可能有多套站点和多份access_log；只盯着默认日志，容易把其他网站的扫描请求当成自己的故障。本文聚焦Nginx的HTTP请求，不替代系统CPU、内存或网络路径测试。

本文要求已存在可识别的目标站点与配置；新环境可先按Nginx静态站点部署，已有正式环境只核对对应条件，不重复安装或覆盖旧配置。

找到正在使用的日志与时间

date --iso-8601=seconds
sudo nginx -T

在nginx -T输出中定位目标域名的server块及access_log、error_log；未单独设置时可能继承http层路径。Ubuntu发行版常见默认路径是/var/log/nginx/access.log与error.log，但面板和容器不同。整份配置可能含内部地址和路径，不公开完整输出。先确认系统时区，并记录出现问题的准确时间。

只复现一次，再对应查看

在浏览器访问一次具体失败页面，记录完整现象；日志排查时优先按不含敏感查询参数的路径筛选。下面路径和日志文件必须替换为实际值：

sudo tail -n 100 /var/log/nginx/site-a.access.log
sudo tail -n 100 /var/log/nginx/site-a.error.log
sudo grep -F '/example-path' /var/log/nginx/site-a.access.log | tail -n 20

一条访问日志通常包含来源、时间、请求、状态码和响应大小；具体列取决于log_format。404不自动代表域名解析错误，200也不能证明业务结果正确，例如应用可能把错误提示页以200返回。错误日志没有同一请求记录，也不代表请求从未到达；日志级别、应用返回和代理行为都会影响记录。

按状态与报错文字决定下一步

需要耗时字段时才增加专用格式

若默认日志没有耗时，需在两个不同配置上下文分别操作。先通过nginx -T确认/etc/nginx/nginx.conf的http块内包含/etc/nginx/conf.d/*.conf；不符合此结构的面板或容器，按其真实include关系操作，不能盲目新增同名文件。

第一处是http层格式定义。确认文件名尚未用于其他配置后，运行sudo nano /etc/nginx/conf.d/baole-log-format.conf，新建文件中只填写下方log_format，不包裹额外的http或server块：

log_format baole_timing '$remote_addr [$time_iso8601] "$request_method $uri $server_protocol" '
                        'status=$status bytes=$body_bytes_sent rt=$request_time urt=$upstream_response_time';

第二处是目标站点的server层。打开先前找到的目标域名配置文件，例如/etc/nginx/sites-available/site-a.conf，在该域名的server { ... }块内新增下面这一行。不要把它跟着复制进conf.d格式定义文件，否则可能影响其他站点：

access_log /var/log/nginx/site-a.timing.log baole_timing;

两处保存后先检测，再加载；检测失败不执行reload：

sudo nginx -t
sudo systemctl reload nginx

检测成功后reload，再复现同一请求。rt是Nginx记录的请求总耗时，urt是上游响应相关耗时，不能直接把两者相减后认定差值全部是网络延迟；静态请求或未连接上游时urt可能为“-”。此格式用$uri避免记录查询串，但路径本身仍可能有隐私信息，应限制日志读取和保留期限。

整理工单证据与清理临时记录

提供故障时间及时区、目标域名和必要路径、状态码，并将一次复现前后的必要日志文本片段粘贴到工单内容。图片附件仅支持jpg、gif、jpeg、png，原始日志、SQL或ZIP不要直接当附件上传；确需原文件时先通过工单核实官方安全接收方式。遮盖Cookie、令牌、邮箱、客户IP及敏感路径，只保留排查所需部分。不要把完整访问日志放进网站根目录供下载。临时详细日志使用结束后恢复原配置并检测加载，记录磁盘用量与轮转状态，不通过清空全部日志丢弃现场。