宝塔查看网站日志：定位404与500错误
网站出错时，先找到同一次请求在日志里的记录，再决定改哪里。本文适用于宝塔 Linux 面板管理的 Nginx 网站，重点解决“日志在哪里看、哪一行与报错有关”。已经看到明确的 502、504，可接着查看Nginx 与 PHP-FPM 排查。
先记下一个可以复查的请求
记录出错的域名、路径、请求方法、出现时间和页面提示。浏览器开发者工具的“网络”面板可以查看具体请求的状态码；只截一张“页面无法打开”，很难判断是网页、接口还是图片出了问题。
选择一个不会写入数据的页面或检查地址，复现一次即可。支付、发信、删除和订单接口不要为了找日志反复点击。URL 中带 token、签名或个人信息的，自己核对时保留，发给他人前先脱敏。
在目标站点里打开两类日志
- 进入宝塔“网站”，按实际域名找到站点，打开该站点的设置。
- 选择“网站日志”，查看“响应日志”和“错误日志”。部分版本把前者称为访问日志，名称略有差别。
- 在刚才记录的时间附近，查找对应路径与请求方法，再核对状态码。
响应日志主要回答“这个请求有没有到达、返回了什么状态”；错误日志用于查看 Web 服务记录的具体原因。应用自己生成的 500，不一定把完整异常写进 Nginx 错误日志，还要继续查看 PHP 或应用日志。
日志字段示意，使用保留地址和演示请求，不是真实客户日志。实际字段顺序由站点的日志格式决定。
例如浏览器报错时间是 18:10，日志里的时区却是 +0000，应先把时间换算到同一时区再查。浏览器经过代理、CDN 或负载均衡时，日志里的来源地址也可能是代理地址，不一定是你电脑的公网 IP。
找到记录后，按状态继续往下查
| 同一次请求的结果 | 下一步看哪里 |
|---|---|
| 404 | 核对访问路径、大小写、网站目录和应用路由。错误日志若显示文件不存在，先确认该请求本来应该找文件，还是应转交应用路由。 |
| 403 | 检查目标目录能否读取、是否有首页文件，以及站点访问规则。参照Nginx 403 排查逐项定位。 |
| 500 | 结合错误日志和应用日志找本次异常。PHP 报错、依赖失败或重写循环等原因不同，不能仅凭状态码确定原因。 |
| 502、504 | 查看对应上游、连接拒绝或超时信息，再检查后端服务。 |
| 页面200，功能仍失败 | 继续查浏览器里真正失败的接口、脚本或图片请求。首页成功不能代表整项操作成功。 |
一行日志里出现 upstream、文件路径或端口时，先确认它属于哪个服务，再检查那个位置。不要看到“Permission denied”就给整个网站设成 777，也不要只根据一个客户端地址认定对方在攻击。
页面报错，却没有新日志
先确认打开的是正确站点、正确服务器，以及包含本次请求的日志文件。面板有时只显示最近一部分内容；日志轮转后，较早的请求可能已经进入历史文件。常见日志目录是 /www/wwwlogs，实际路径以该站点配置里的 access_log和error_log为准。
确认路径后，可以通过 SSH 只读查看末尾内容。以下路径是占位示例，替换为刚刚核对的真实文件：
sudo tail -n 100 -- '/实际路径/站点访问日志.log'
sudo tail -n 100 -- '/实际路径/站点错误日志.log'如果站点原本关闭了访问日志，可在站点的“网站目录”中检查“写访问日志”选项，按需要开启后再发起一次安全请求。开启只能记录后续请求，不会补出之前的记录。Nginx 自定义规则还可能单独关闭某些路径的记录；配置了日志缓冲时，写入也可能延迟，要结合实际配置判断。
另一种情况是请求根本没有到源站：浏览器或 CDN 直接返回了缓存、域名指向另一台机器，或错误由前面的代理生成。此时应检查实际入口与响应头，不要先重启这台服务器。响应头也只能提供线索，不能单独证明整条请求路径。
把有用的证据留下，再验证修复结果
保存出错前后的一小段日志，附上域名、请求路径、时间与时区、状态码，以及对应改动。错误堆栈中的账号、口令、访问令牌和客户资料应遮盖，保留能定位问题的时间、模块与错误类型，方法见日志脱敏说明。
修复后重新访问同一个安全路径，确认状态与响应内容符合预期，再完成实际使用功能的检查。日志没有新增错误只是一个信号，不能代替页面、接口和业务结果的验证。需要进一步筛选大日志时，继续看用 Nginx 日志定位网站访问问题。