Nginx负载均衡本身不产生403错误，真正原因在于location拦截规则、error_page联动不当或后端返回状态未正确处理；需确保拦截逻辑与自定义403页放行配置协同，且页面内容安全无泄露。
Nginx 负载均衡本身不会直接产生 403 错误——它只是把请求转发给后端服务器。所谓“被负载均衡策略拒绝的非法客户端”，实际是指：在 upstream 或 proxy 层面，因健康检查失败、连接超时、后端不可达等原因触发了 proxy_next_upstream 重试机制后仍无可用节点，最终由 Nginx 主动返回 403（或更常见的是 503）；或者，你在 location 中主动用 deny/if/auth_basic 等规则拦截了请求，再配合负载均衡使用。
但注意：如果你的目标是 对不满足访问条件的客户端统一返回自定义 403 页面（而非默认白页或暴露信息的错误页），核心不在 upstream 配置，而在 server 或 location 块中拦截逻辑 + error_page 的正确联动。下面分三块说清楚：
确保拦截规则生效且不阻断错误页自身
Nginx 处理 error_page 403 /403.html 时，会发起一次内部子请求去加载 /403.html。这个子请求仍受当前 location 权限规则约束。
所以若你在主 location 里写了 deny all;，又没单独放行 /403.html，就会导致错误页也打不开，最终回退到内置白页。
正确做法是：
- 在主 location 中配置拦截逻辑（如 IP 拒绝、Referer 过滤等）并声明
error_page 403 /403.html; - 单独添加一个精确匹配的 location 块，显式允许访问错误页，并指定文件路径：
location = /403.html {
internal; # 仅允许内部跳转，禁止用户直接访问
root /usr/share/nginx/html;
allow all;
}让负载均衡场景下的拦截更可控
真正和负载均衡强相关的 403 场景，通常是：你用 if 或 map 结合 $upstream_http_* 或 $status 做二次判断，比如后端返回了特定响应头表示“拒绝授权”，你希望 Nginx 捕获后转为 403 并显示自定义页。
这时需配合：
- 后端服务在拒绝时返回明确状态码（如 403）或带标识响应头（如
X-Auth-Status: forbidden） - Nginx 用
proxy_intercept_errors on;（仅对 FastCGI 有效，对普通 proxy 不起作用）不行 → 改用proxy_redirect或map提取状态：
map $upstream_status $forbidden_flag {
403 1;
default 0;
}
server {
location / {
proxy_pass http://backend;
proxy_intercept_errors off; # 不要开，它不处理 proxy 返回的 403
error_page 403 /403.html;
}
}但更稳妥的做法是：把权限控制逻辑前置到 Nginx 层（如 geo、map + deny），而不是依赖后端返回 403。这样 error_page 才能稳定生效。
自定义页面本身要安全、无泄露
即使返回 403，也要避免暴露服务器版本、路径结构或调试信息：
- 关闭版本号：在 http 或 server 块中加
server_tokens off; - 确保
/403.html文件内容简洁，不含 Nginx 版本、系统路径、URI 回显等敏感字段 - 防止被爬虫或探测直接访问该页：
location = /403.html { internal; }已足够，无需额外deny all - 若需统一隐藏路径存在性（比如
/.git应返回 404 而非 403），改用return 404;替代deny，从根本上切断探测反馈
不复杂但容易忽略
