recursive_error_pages 不防止无限循环，而是触发nginx 10层嵌套限制致500；安全容灾需设计有界fallback链路，配合try_files、状态码区分和proxy_intercept_errors等配置。

recursive_error_pages 本身不解决“无限循环”，它反而可能因配置不当引发循环——准确说，是触发 nginx 内部的 10 层嵌套错误处理限制，最终返回 500 并记录 rewrite or internal redirection cycle。所谓“静态容灾路径的无限循环”，本质是 fallback 链路缺少明确终点。要安全实现多级静态资源容灾，关键不是防止“循环”，而是设计有界、可终止的降级路径。

明确 recursive_error_pages 的作用边界

它只在 error_page 触发后、目标 location 内部再次出错（如 404/500）时，才尝试查找下一级 error_page；全程不涉及 HTTP 重定向，浏览器地址栏不变，响应码取决于最终结果（200 或原始错误码）。它不是 rewrite，也不响应 return 302。

• 仅对内部错误生效：比如 /img/logo.png → 404 → error_page 404 /fallback/logo.png → 该 location 再次 404 → 因开启 recursive_error_pages，继续匹配 error_page 404 /backup/logo.png
• 硬编码上限为 10 层：超限直接 500，不可调，日志级别 notice 可捕获警告
• 与客户端跳转无关：不要用它替代 rewrite redirect，二者机制隔离，不会协同

设置有终点的 fallback 链路

每级 location 必须能稳定响应，避免无条件再抛错误。推荐用 try_files + 明确兜底，确保链路在某一层自然终止。

• 第一级 fallback location：try_files $uri /backup/logo.png =404; —— 找不到就交由下一级
• 第二级 backup location：try_files $uri /static/placeholder.png =404; —— 再找不到就返回固定占位图
• 最后一级必须有真实文件或 return 200：例如 alias /var/www/static/; 或 return 200 "fallback ok";

用状态码区分层级，阻断重复匹配

如果所有 fallback 都返回 404，nginx 可能反复命中同一 error_page 规则，导致隐性循环。改用不同状态码可打破匹配连续性。

• 主 location 返回 404 → 触发 error_page 404 /fallback
• /fallback location 返回 410（Gone）→ 不再匹配 404 的 error_page，但可单独配 error_page 410 /backup;
• /backup location 返回 200 → 流程彻底结束，不再触发任何 error_page

必须配套的关键配置项

只写 recursive_error_pages on; 不生效。需同时满足三项：

• 在每个参与 fallback 的 location 块中显式启用：recursive_error_pages on;（http 块设为 on 是默认，但 location 可覆盖）
• 若容灾资源来自代理后端（如 CDN 或 origin server），对应 proxy_pass location 必须加 proxy_intercept_errors on;，否则 404 不被捕获
• 每个 fallback location 自身不能依赖外部服务或动态逻辑——应纯静态，用 root/alias 或 try_files 指向本地文件系统