recursive_error_pages仅控制error_page内部错误的10层嵌套处理，超限返回500并记录循环警告；它不处理HTTP重定向，只用于静态资源多级fallback等服务端内部兜底场景。
recursive_error_pages 不是用来处理“HTTP重定向死循环”的，它只控制 error_page 内部错误响应链的嵌套层级，最多允许 10 层递归处理；超限即返回 500 并记录 rewrite or internal redirection cycle 警告。
它真正管什么：error_page 触发后的内部兜底链路
当某个 error_page 指向的 location 执行时又出错（比如返回 404、500，或被 rewrite 触发新错误），Nginx 会尝试再次查找匹配的 error_page 来接管——这就是“递归错误处理”。开启 recursive_error_pages on 后，才允许这种嵌套发生。
- 第 1 层：主请求 /img/logo.png → 404 → 触发
error_page 404 /fallback/logo.png - 第 2 层：
/fallback/logo.pnglocation 中仍 404 → 再次触发error_page 404 /backup/logo.png - 第 3 层：
/backup/logo.pnglocation 返回真实文件或兜底图 → 流程终止，响应 200
整个过程对客户端透明，不改变 URL，也不发送 3xx 响应头。
它完全不管什么：3xx 重定向、return、rewrite redirect
以下行为和 recursive_error_pages 零关系：
-
return 302 https://example.com;—— 客户端跳转，Nginx 不参与后续 -
rewrite ^/old(.*)$ /new$1 redirect;—— 发送 302 响应头，流程立即结束 - 上游 proxy 返回 302 +
proxy_intercept_errors on—— 此时需靠error_page 302 @handle显式拦截并手动处理跳转逻辑
想让 Nginx 自动跟随多次 302（如 OAuth 授权链），必须自己写 error_page 302 @follow_redirect + proxy_pass $upstream_http_location 链路，这不是 recursive_error_pages 在起作用。
安全使用的关键配置要点
仅设 recursive_error_pages on 不生效，还需满足：
- 每个 fallback location 必须能稳定响应：推荐用
try_files $uri =404;或直接root/alias指向静态目录 - 显式启用错误捕获：在对应 location 块中加
recursive_error_pages on（http 块设为 on 是默认值，但 location 可覆盖） - 代理返回的 404 要拦截：若资源由后端返回 404，必须在 proxy location 中设置
proxy_intercept_errors on - 日志监控：设
error_log /path/to/error.log notice;，实时观察是否出现循环警告
如何避免踩进 10 层限制的坑
Nginx 硬编码限制最多 10 层递归，超限直接报错。实用防坑方法：
- 每级 fallback location 结尾加
try_files $uri =404;，确保有明确终点 - 用不同状态码区分层级：第一级返回 404，第二级返回 410，第三级返回 200 兜底图，避免反复匹配同一
error_page - 不要在 fallback location 中无条件
return 404或rewrite ... last，否则极易触达上限 - 需要浏览器地址栏变化？改用
rewrite+if/map判断，而非依赖 error_page 递归
