如何修复 Nginx 403 Forbidden 错误：完整指南

Nginx 返回 403 Forbidden 表示 Web 服务器已理解请求，但拒绝响应。与 404 Not Found 不同，资源通常是存在的（或至少 Nginx 知道去哪里找），但访问控制、文件系统权限或安全策略阻止了内容的交付，页面永远到不了访客那里。

403 是 Nginx 在新部署、服务器迁移之后，或某次包更新重置了 SELinux 上下文后最常见的问题之一。好消息是：几乎每个 403 都有明确、可定位的原因，而且 Nginx 会在错误日志中记录理由。本指南将讲解 403 的含义、需要排查的根本原因，以及一套能解决绝大多数情况的六步修复流程。

什么是 Nginx 403 Forbidden？

403 Forbidden 属于 4xx 范围的 HTTP 状态码。当 Nginx 被配置为 —— 或被操作系统强制 —— 拒绝访问所请求的资源时，就会返回它，即使请求本身格式正确。用 Nginx 自己的话说，错误日志通常显示 access forbidden by rule 或 directory index of "..." is forbidden。

与 404 的关键区别在于：Nginx 找到了文件或目录，但无权提供服务。因此 403 是权限或策略问题，而不是路由问题。浏览器无法修复它，改动必须发生在服务器上。403 永远不是随机的 —— 它始终是一次明确的拒绝，答案就藏在配置或文件系统里。

常见原因

在动手敲命令之前，先了解几乎每个 Nginx 403 背后的八种根本原因：

• 文件系统权限 —— Nginx worker 用户对文件缺少读取权限，或对某一级父目录缺少执行（搜索）权限。
• 文档根目录错误 —— root 指令指向了一个为空、错误、或并非你部署目标的路径。
• 缺少索引文件 —— index 指令列出了 index.html，但实际只有 index.php，且没有配置回退。
• autoindex 关闭 —— 目录列表被禁用且没有索引文件，Nginx 便返回 403 而不是列出文件。
• deny 指令 —— allow/deny 规则显式屏蔽了客户端 IP。
• IP 或地理位置限制 —— geo 或 map 块、或 WAF 拒绝了请求。
• SELinux 或 AppArmor —— 强制访问控制标签阻止 Nginx 读取文件，即使 Unix 权限看起来正确。
• 符号链接失败 —— disable_symlinks 开启，或符号链接目标位于允许路径之外。

分步修复指南

按顺序完成以下六个步骤。每次改动后，先测试配置并重载 Nginx，再用浏览器检查结果。

步骤 1：验证文档根目录的文件权限

这是最常见的原因。Nginx 以 worker 用户运行（RHEL 上通常是 nginx，Debian/Ubuntu 上是 www-data），它必须能读取从根目录一直到目标文件之间的每个文件，并搜索其中的每个目录。

# 列出 Web 根目录的属主和权限
ls -la /var/www/html

# 追踪路径中每个目录的执行（搜索）权限
namei -l /var/www/html/index.html

# 修复属主（Debian/Ubuntu 用 www-data，RHEL 用 nginx）
chown -R nginx:nginx /var/www/html

# 目录需要 755，文件需要 644
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

如果 namei 显示某个目录对 others 没有 x 权限，Nginx 就无法穿越它，无论文件本身权限如何都会返回 403。

步骤 2：确认文档根目录路径正确

一个拼写错误或迁移遗留的路径就足以产生 403。打开 server 块检查 root 指令，然后确认目录里确实有你的文件。

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public;   # 确认此路径存在
    index index.html index.htm;
}

# 确认路径存在并包含索引文件
ls -la /var/www/example.com/public

如果你最近移动过文件，请记住 root 的值是按字面解析的 —— 末尾斜杠和大小写都很重要。

步骤 3：检查 index 指令与 autoindex

当请求一个目录而不带文件名时，Nginx 会查找 index 指令中列出的文件。如果都不存在，且 autoindex 关闭（默认值），Nginx 就返回 403。

location / {
    index index.html index.htm index.php;
    # autoindex on;   # 仅在需要列出目录内容时取消注释
}

要么在目录中添加匹配的索引文件，要么在你确实需要目录列表时开启 autoindex on;。切勿在敏感目录上开启 autoindex。

步骤 4：审查 allow 与 deny 访问规则

一个显式的 deny all; 或对某 IP 段的 deny，即便权限完美也会产生 403。在配置中搜索这些指令。

# 在整个 Nginx 配置树中查找 allow/deny 规则
grep -RIn "allow\|deny" /etc/nginx/

# 屏蔽除本机以外所有访问的示例
location /admin {
    allow 127.0.0.1;
    deny all;
}

删除或收紧规则以放行合法客户端，然后重载 Nginx。

步骤 5：检查 IP 与地理位置限制

除了简单的 allow/deny，Nginx 还支持 geo 和 map 块，可以对整个地区返回 403。ModSecurity 等 WAF 也能做到同样的事。检查这些块以及它们可能触发的 return 403 语句。

geo $blocked {
    default 0;
    10.0.0.0/8 1;
}

server {
    if ($blocked) { return 403; }
}

如果无法判断是哪条规则在生效，可以临时把 error_log 设为 debug 级别，记录匹配到的值。

步骤 6：解决 SELinux 或 AppArmor 拦截

在 RHEL、CentOS 和 Fedora 上，SELinux 默认处于 enforcing 状态，即使 Unix 权限是 755，也会阻止 Nginx 读取上下文不是 httpd_sys_content_t 的文件。在 Debian 系系统上，AppArmor 可能起到同样的作用。

# SELinux 是否处于 enforcing？
getenforce
sestatus

# 修复文件上下文并允许 Nginx 读取用户内容
restorecon -Rv /var/www/html
setsebool -P httpd_read_user_content on

# 检查 AppArmor（Debian/Ubuntu）
sudo aa-status | grep nginx

修正上下文后，重载 Nginx 并重新测试。SELinux 拒绝也会记录在 /var/log/audit/audit.log 中 —— 见下方的诊断命令。

Nginx 诊断命令

当出现 403 时，以下命令能在几秒内定位原因。请始终先从错误日志入手。

# 1. 读取 Nginx 拒绝请求的确切原因
tail -n 50 /var/log/nginx/error.log

# 2. 重载前测试配置语法
nginx -t

# 3. 不中断活动连接地重载
nginx -s reload

# 4. 检查属主和权限
ls -la /var/www/html
namei -l /var/www/html/index.html

# 5. 修复属主和权限
chown -R nginx:nginx /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# 6. 检查 SELinux 状态和上下文
getenforce
ls -Z /var/www/html
restorecon -Rv /var/www/html

# 7. 搜索最近的 SELinux 拒绝记录
ausearch -m AVC,USER_AVC -ts recent

# 8. 检查 AppArmor 状态及 Nginx 配置模式
sudo aa-status

# 9. 查看 Nginx worker 进程的运行用户
ps -ef | grep nginx | grep -v grep

快速参考表

症状 / 日志信息	根本原因	修复方法
access forbidden by rule	allow/deny 或 geo 块	删除或调整规则；确认客户端 IP 已被放行
directory index of "..." is forbidden	无索引文件且 autoindex 关闭	添加匹配的索引文件或设置 autoindex on;
读取文件时 Permission denied	文件系统权限问题	用 chown/chmod 让 Nginx 用户可读可搜索
仅在 RHEL/CentOS/Fedora 上出现 403	SELinux 上下文不匹配	restorecon -Rv 并 setsebool -P httpd_read_user_content on
符号链接路径出现 403	disable_symlinks 或链接目标错误	设置 disable_symlinks off; 或修正目标属主
迁移后立即出现 403	文档根目录路径错误	修正 root 指令并重载 Nginx
仅特定 IP 出现 403	基于 IP 的 deny 或 geo 规则	调整 geo/allow/deny 规则

常见问题

文件明明存在，为什么还是 403？

因为 Nginx 找到了文件但无权提供服务。三个常见嫌疑是：文件系统权限（Nginx worker 用户无法读取文件或搜索父目录）、SELinux/AppArmor 标签、或显式的 deny 规则。先运行 tail /var/log/nginx/error.log —— 它会说明确切原因。

403 Forbidden 和 404 Not Found 有什么区别？

404 表示 Nginx 根本找不到资源；403 表示 Nginx 找到了但访问被拒绝。如果看到 403，说明路径是对的，应把精力放在权限和访问控制上，而不是路由。

如何开启目录列表而不是看到 403？

在相关 location 块中添加 autoindex on;，并确保目录中没有索引文件（否则会直接提供索引文件）。用 nginx -s reload 重载 Nginx。仅对非敏感内容使用目录列表。

SELinux 真的会在 CentOS 和 RHEL 上导致 403 吗？

是的。SELinux 在 RHEL 系系统上默认为 enforcing，即使 Unix 权限是 755，也会阻止 Nginx 读取上下文不是 httpd_sys_content_t 的文件。运行 getenforce；若返回 Enforcing，则执行 restorecon -Rv /var/www/html 和 setsebool -P httpd_read_user_content on。

总结

Nginx 的 403 Forbidden 始终是一次明确的拒绝，绝不是靠猜。先从错误日志入手 —— 它会告诉你阻断是目录索引问题、权限拒绝，还是访问规则。然后依次排查文件系统权限、文档根目录、index 指令、allow/deny 规则、IP 与地理位置限制，最后是 SELinux 或 AppArmor。一旦底层的权限或策略问题被修正，且 nginx -t && nginx -s reload 成功，403 就会消失，资源将按预期正常提供服务。

相关指南

• 5 分钟修复 Nginx 502 Bad Gateway
• Nginx 504 网关超时：完整修复指南
• 如何修复 404 Not Found 错误：完整指南
• 如何修复 400 Bad Request 错误：完整指南