recursive_error_pages 不支持循环重定向，仅允许 error_page 内部错误触发最多10层嵌套错误处理；超限返回500并记录日志，与HTTP重定向无关。
nginx 的 recursive_error_pages 指令**不支持真正的循环重定向**，它的作用是允许在 error_page 处理过程中**再次触发 error_page**（即嵌套处理），但 nginx 有内置保护机制防止无限循环。
recursive_error_pages 的真实行为
该指令开启后，当某个 error_page 指向的 location 内部又产生错误（如返回 404、500 或被 rewrite 触发新错误），nginx 会尝试再次查找匹配的 error_page 进行处理——这叫“递归错误处理”，不是用户可控的任意跳转循环。
- 默认值为
off：error_page 处理完后若内部再出错，直接返回原始错误响应（如 500） - 设为
on后，最多允许 10 层嵌套 error_page 处理（硬编码限制，不可配置） - 超过 10 层时，nginx 会终止处理，返回
500 Internal Server Error，并在 error log 中记录rewrite or internal redirection cycle
它不是用来做重定向循环的
recursive_error_pages on 常被误解为“支持反复跳转”，但它只对 error_page + location 内部错误生效，和 return 302、rewrite ... redirect 等 HTTP 重定向无关。后者由客户端执行，不受此指令控制。
- 想实现多次跳转？用多个
return 302或rewrite，但需自行避免循环（比如加条件判断） - 想在错误处理中尝试备选资源？可用
error_page 404 /fallback.html;，再在/fallback.htmllocation 里设error_page 404 /backup.html;—— 这才是 recursive_error_pages 的典型用途
如何安全使用 recursive_error_pages
启用前务必确认 error_page 链路有明确终点，否则容易触发 10 层限制报错。
- 避免 location 内无条件触发新错误（例如始终 return 404）
- 在 fallback location 中加入
try_files或静态内容兜底，减少二次出错可能 - 配合日志检查：
error_log /path/to/error.log notice;可捕获循环警告
替代方案：需要可控跳转时用 rewrite + break
如果目标是按规则多次内部重写（非错误场景），应使用 rewrite 指令配合 last/break，并用 if 或 map 控制流程，而非依赖 error_page 递归。
-
last：重写后重新匹配 location，可能再次进入 rewrite 流程（需小心设计终止条件） -
break：重写后不再匹配，适合单次替换 - 永远不要用
rewrite ... redirect配合 recursive_error_pages —— 它们属于不同机制，不会联动
