fastcgi_cache_use_stale不是兜底开关，而是仅在nginx与php-fpm通信失败时复用已存在过期缓存，有效触发条件为http_500-504、timeout、error和updating，且须配合cache_path、稳定key、5xx缓存规则及请求过滤才能生效。
fastcgi_cache_use_stale 不是让缓存“永远可用”的兜底开关，而是当 PHP-FPM 出现特定异常时，允许 Nginx 返回一个已过期但本地仍存在的缓存响应——前提是这个缓存真实存在、key 稳定、且曾被成功写入。
真正起效的触发场景只有四类
该指令只在 Nginx 与 PHP-FPM 通信失败或超时时介入，不是缓存一过期就自动启用：
- http_500、http_502、http_503、http_504：PHP-FPM 明确返回服务端错误，最可信，推荐必配
-
timeout：对应
fastcgi_read_timeout触发（读响应超时），是缩短用户等待“死区”的关键条件 - error：仅限连接被拒绝、重置或 upstream 地址无法解析等底层故障，慎用以防误判
-
updating：必须配合
fastcgi_cache_background_update on使用，后台刷新时可先返回旧内容
缓存必须“存得住”，stale 才有东西可返
stale 不生成缓存，只复用已有内容。若缓存从未存入，或 key 总在变，stale 就完全失效：
- 在
http块中声明缓存区：fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=phpcache:100m inactive=30m use_temp_path=off; - 缓存 key 必须剔除动态字段：
fastcgi_cache_key "$scheme$request_method$host$request_uri";（禁用时间戳、用户 ID、随机参数） -
fastcgi_cache_valid必须覆盖 5xx 响应：fastcgi_cache_valid 500 502 503 504 1m;，否则错误响应根本不进缓存，stale 永远无数据可用
跳过不该缓存的请求，防止 stale 返回错内容
未过滤的登录页、带参数 URL 或含 Cookie 的请求，会污染缓存，导致 stale 返回他人页面或空响应：
- 拦截查询字符串：
if ($query_string != "") { set $skip_cache 1; } - 拦截登录态 Cookie：
if ($http_cookie ~* "wordpress_logged_in|comment_author|wp-postpass") { set $skip_cache 1; } - 在 location 中绑定：
fastcgi_cache_bypass $skip_cache;和fastcgi_no_cache $skip_cache;
配合 timeout 参数控制“死区”长度
决定用户是否等到超时才触发 stale 的，是 fastcgi 超时系列参数：
-
fastcgi_connect_timeout 3s：建立连接超时，反映 PHP-FPM 进程挂死或负载过高 -
fastcgi_send_timeout 5s：发送请求体超时，防写阻塞 -
fastcgi_read_timeout 8s：最关键——从 PHP-FPM 读取完整响应的总时长，超时即触发 stale
