根本原因是Nginx用当前location的root找/403.html时，该路径下文件不可读或被deny规则拦截；必须单独配置location = /403.html并显式allow all、指定root。
为什么加了 error_page 403 /403.html 却还是显示默认白页？
根本原因不是配置没写，而是 Nginx 在拦截 403 后，会用当前 location 的 root 去找 /403.html。如果该 location 下没有权限访问目标 HTML 文件（比如被 deny all 拦住了），或者 root 路径压根不包含这个文件，就会 fallback 到内置错误页。
常见错误现象：
- 浏览器返回纯白页，控制台看不到 HTML 内容，
curl -I http://x/xxx显示HTTP/1.1 403 Forbidden但没跳转 - 日志里出现
open() "/usr/share/nginx/html/403.html" failed (13: Permission denied) - 手动访问
http://x/403.html也报 403 —— 说明连错误页自己都打不开
location = /403.html 必须显式放行且指定 root
这是最常漏掉的关键步骤：Nginx 处理 error_page 后，会发起一次内部子请求去加载 /403.html。这个请求仍受外层 location / 的 allow/deny 规则约束。所以必须单独为错误页 URI 开一个独立 location 块，并明确允许所有访问 + 指定文件路径。
正确写法示例：
location / {
deny 192.168.2.0/24;
allow all;
error_page 403 /403.html;
}
location = /403.html {
internal; # 可选，禁止外部直接访问（仅限 error_page 触发）
root /usr/share/nginx/html;
allow all;
}注意点：
-
root值是目录，不是完整路径；Nginx 会自动拼接成/usr/share/nginx/html/403.html - 不要写
alias，容易路径错位；alias /path/和root /path行为不同 -
internal是安全加固项：防止用户绕过规则直击/403.html，但不是必需
fastcgi_intercept_errors on 对 403 无效，别乱加
这个指令只影响 FastCGI 后端（如 PHP）返回的错误状态码，比如 PHP 脚本里 header("HTTP/1.1 403 Forbidden")。而 Nginx 自身产生的 403（如 deny、auth_basic 拒绝、目录无索引）完全不受它控制。
所以：
- 在
http块里加fastcgi_intercept_errors on对自定义 403 页面没用 - 反而可能干扰其他 FastCGI 场景，建议删掉或注释
- 真正起作用的是
error_page+ 独立location组合
文件权限和路径必须真实存在
即使配置全对，/403.html 文件本身不可读，照样 fallback。检查三件事：
- 确认文件存在：
ls -l /usr/share/nginx/html/403.html - 确认 Nginx worker 进程用户（查
nginx.conf里的user指令）对该文件有读权限（r） - 确认其所在目录（如
/usr/share/nginx/html）对 Nginx 用户有执行权限（x），否则无法进入目录
快速修复命令（以 nginx 用户为例）：
sudo chown root:nginx /usr/share/nginx/html/403.html sudo chmod 644 /usr/share/nginx/html/403.html sudo chmod 755 /usr/share/nginx/html
最后别忘了重载：sudo nginx -s reload，不是 restart。
最容易被忽略的是：错误页 HTML 里引用的 CSS、图片等资源，如果用了相对路径（如 href="style.css"），它们也会走同样的 location = /403.html 规则——而那个 location 只认 /403.html，不认 /style.css。所以要么把样式内联，要么用 base64 或绝对路径。
