如何通过分析 error_log 定位静态资源权限拒绝的根因排查实战-Nginx-PHP中文网

最有效排查403错误是直接分析error_log，但需先确认日志是否启用、调高对应模块级别（如apache设loglevel authz_core:debug，nginx设error_log ... debug）、识别关键模块标识与错误码，并用运行用户模拟访问验证权限及selinux限制。

如何通过分析 error_log 定位静态资源权限拒绝的根因排查实战

直接看 error_log 是最有效的起点，但得知道该盯哪些字段、在哪调日志级别、怎么结合系统上下文读出真实原因。

Apache 和 Nginx 默认日志级别通常不输出 403 的详细路径和拒绝类型。不打开对应模块的 debug 级别，error_log 很可能只写一句 “client denied”，甚至完全沉默。

Apache：加 LogLevel authz_core:debug 或 LogLevel core:debug，重启后重试请求；若用 .htaccess，还要确保 AllowOverride All 生效
Nginx：确保 error_log /var/log/nginx/error.log warn; 至少是 warn 级，部分权限问题（如目录无 x 权限）会在 crit 或 emerg 级别出现，可临时设为 error_log /var/log/nginx/error.log debug;（需编译时带 --with-debug）
Java 应用（如 Tomcat 前置 Apache）：403 若出现在 Apache 的 error_log，说明拦截发生在 Web 服务器层，不是 Java 代码抛出的，别去翻 application.log

真正有用的条目往往带模块名、错误码和具体路径。不要只扫“403”三个数字。

[authz_core:error] ... AH01630: client denied by server configuration → 检查 <directory></directory>、Require 或 .htaccess 规则，不是文件权限问题
[core:error] ... (13)Permission denied: ... because search permissions are missing on a component of the path → 典型路径遍历失败，某个父目录（如 /home/username）缺少执行（x）权限
[core:error] ... (13)Permission denied: ... access to /xxx/xxx.js denied → 文件本身或所在目录无读（r）权限，且运行用户（如 www-data）不是所有者或同组
SELinux is preventing /usr/sbin/httpd from read access on the file xxx → SELinux 上下文不匹配，需 ls -Z 查标签，用 semanage fcontext 修复

日志说“没权限”，就用 Nginx/Apache 实际运行用户去模拟访问，一步到位验证。

查运行用户：ps aux | grep nginx 或 grep "^User\|^user" /etc/httpd/conf/httpd.conf
模拟访问（以 www-data 为例）：sudo -u www-data ls -l /var/www/html/style.css 和 sudo -u www-data ls -ld /var/www /var/www/html
重点看每一级目录是否有 x（进入权），目标文件是否有 r（读取权）；若卡在 /home/alice，而它的权限是 drwx------，那就明确了
SELinux 用户可跑：ausearch -m avc -ts recent | grep httpd，有 denied 就是它

如果 error_log 根本没新内容，可能是日志功能自己瘫了——90% 是权限或路径问题。

检查日志目录归属：ls -ld /var/log/nginx，必须属 Nginx 运行用户（如 www-data:www-data）
父目录缺 x 权限也会导致写入失败，比如 /var/log 权限是 drwxr-x---，而 www-data 不在 root 组，就写不了
Nginx 配置里写的是 error_log logs/error.log？这是相对路径，实际会拼到 Nginx 启动时的工作目录（常是 / 或 /usr/share/nginx），极易写入失败；一律用绝对路径，如 error_log /var/log/nginx/error.log;