proxy_cache_use_stale 不能防止前端假死，因其仅在回源失败后返回过期缓存，不控制总时延；真正限制重试总耗时的是 proxy_next_upstream_timeout，需配合 proxy_next_upstream 使用并合理设值。
proxy_cache_use_stale 本身不控制重试总时延，也不能直接防止前端假死。它只决定“在回源失败或超时时，是否允许返回已过期的缓存内容”。真正限制重试总耗时、避免用户长时间等待的，是 proxy_next_upstream_timeout。
为什么 proxy_cache_use_stale 不能解决前端假死
它不干预请求发起过程，也不中断等待；只在 Nginx 已确定无法获取新鲜响应（比如超时或收到 502）后，提供一个“降级兜底选项”——前提是本地有可用的过期缓存。如果缓存不存在、未命中、或根本没配缓存链路，Nginx 仍会卡在回源环节，直到 proxy_read_timeout 或 proxy_next_upstream_timeout 触发终止。
真正控制总时延的关键：proxy_next_upstream_timeout
这个指令定义了从第一次请求发出起，整个重试流程（含连接、切换 upstream、读响应头等所有环节）允许消耗的最大时间。超时即刻返回 502/504，不再等待。
- 必须配合 proxy_next_upstream 使用，例如：
proxy_next_upstream error timeout http_502; - 推荐值参考：设为 10s–15s，略高于单次 proxy_read_timeout（如 5s）× 重试次数（如 2 次），留出切换和开销余量
- 它与 proxy_read_timeout 并存：后者管单次读头时长，前者管全局重试生命周期
让前端不假死的组合策略
单纯靠超时不够，需叠加快速响应能力：
- 启用 proxy_cache_use_stale http_502 http_503 http_504; —— 确保后端明确报错时能立刻返 stale 缓存（毫秒级）
- 务必配置 proxy_cache_valid 502 503 504 1m; —— 否则错误响应进不了缓存，stale 就无内容可返
- 加 add_header X-Cache $upstream_cache_status; —— 前端可通过该 header 区分是 fresh、stale 还是 miss，自主决定是否展示加载态或降级 UI
- 配合 proxy_cache_background_update on; —— 返回 stale 的同时后台悄悄拉新，下一次请求大概率就是 fresh
验证是否真防住了假死
停掉上游服务后，用 curl 或浏览器发起请求，检查三点：
- 响应状态码是 200（不是 502/504），且响应头含
X-Cache: STALE - 响应体内容与故障前完全一致
- 响应耗时稳定在 20–100ms 区间，远低于你设的 proxy_read_timeout（如 5s）或 proxy_next_upstream_timeout（如 10s）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
