fastcgi_cache_use_stale仅实现缓存兜底，即后端异常时返回过期缓存；真正的容错调度需依赖fastcgi_next_upstream指令配合upstream分组实现重试与节点切换。
在 Nginx 中，fastcgi_cache_use_stale 本身并不实现“后端容错调度”，它只是让 Nginx 在 FastCGI 后端异常时，**继续使用过期缓存响应客户端**，从而提升可用性与用户体验。真正的容错调度（如自动切换上游、重试、降级）需结合 upstream 模块的 proxy_next_upstream 或 fastcgi_next_upstream 等指令协同完成。
fastcgi_cache_use_stale 的作用本质
该指令控制：当缓存已过期，但后端返回错误（500/502/503/504）、超时或繁忙时，是否仍用旧缓存响应请求。它不改变请求转发路径，也不参与上游选择——只是“缓存兜底”，而非“调度切换”。
-
典型配置：
fastcgi_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504; - 若后端 PHP-FPM 崩溃或响应超时，Nginx 不立即报错，而是返回上一次成功的缓存内容（哪怕已过期）
- 适用于读多写少、容忍短暂陈旧数据的场景（如博客首页、商品列表页）
真正实现后端容错调度的关键配置
要让 Nginx 在 FastCGI 后端故障时尝试其他节点或重试，必须依赖 fastcgi_next_upstream 及其相关参数：
-
启用重试机制：
fastcgi_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; -
限制重试次数和范围：
fastcgi_next_upstream_tries 3;、fastcgi_next_upstream_timeout 6s; -
配合 upstream 定义健康节点：使用
server ... max_fails=3 fail_timeout=30s;实现被动健康检查 - 注意：
fastcgi_next_upstream只对当前请求生效，且仅在 fastcgi_pass 指向 upstream 组时才起作用
缓存兜底 + 调度重试的协同逻辑
二者不是替代关系，而是分层容错：先尝试调度重试（换节点或重发），若所有后端都失败，再 fallback 到过期缓存。
- 请求到达 → Nginx 查缓存 → 缓存未命中或已过期 → 尝试 fastcgi_pass 到 upstream
- 后端全部不可用 → 触发
fastcgi_next_upstream但最终失败 → 若启用了fastcgi_cache_use_stale，则返回 stale 缓存 - 若缓存也不存在（首次请求或缓存被清除），才会返回 502/504 等真实错误
实际部署建议
单纯靠 fastcgi_cache_use_stale 无法解决后端单点故障；需组合设计才能构建稳健链路：
- 为 PHP-FPM 部署多个实例，并加入 upstream 分组，避免单点
- 设置合理的
fastcgi_cache_valid和fastcgi_cache_lock，减少穿透压力 - 配合
fastcgi_cache_background_update on;，在后台异步更新过期缓存，不影响前端响应 - 监控
nginx_stub_status或日志中的 upstream response time / retries，验证容错是否生效
