fastcgi_cache_use_stale的触发条件包括http_500-504、timeout、error和updating，其中http_500-504最可信，timeout对应fastcgi_read_timeout超时，error慎用以防误判，updating需配合background_update开启。
fastcgi_cache_use_stale 不是“让缓存一直可用”的开关，而是定义在哪些后端异常场景下，允许 Nginx 返回一个已过期但本地仍存在的缓存响应——前提是这个缓存必须真实存在、键稳定、且曾被成功写入。
真正起效的触发条件有哪些
该指令只在 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使用，后台刷新时可先返旧内容 - 避免写
error timeout而不加其他限制——高并发下易误判，放大雪崩风险
缓存必须“存得住”，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 ($request_uri ~* "/wp-admin/|/wp-login.php|/admin/") { set $skip_cache 1; } - 跳过带查询参数的请求：
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 timeout
这些值需权衡：设太短会误判健康请求；设太长则 stale 失去意义。建议从 3–8 秒区间起步，结合监控调整。
