nginx默认缓存503是因proxy_cache模块将502/503/504纳入缓存范围以应对后端抖动，但易导致故障恢复后仍返回旧错误；可通过proxy_cache_valid 503 0s禁用，配合健康检查与proxy_next_upstream重试机制优化。
这个问题很典型：Nginx在后端服务短暂不可用（比如数据库重启、应用冷启动、网络抖动）时返回503，而它又默认把503响应缓存了——结果后端已恢复，用户却还在刷出“Service Temporarily Unavailable”页面，持续几十秒甚至几分钟。这不是后端真挂了，而是Nginx“记错了”。
为什么Nginx会缓存503？
Nginx的proxy_cache模块默认对部分错误状态码做缓存，包括502、503、504——这是为了防止后端反复抖动时，大量请求直接打穿上游。但它的默认行为没区分“临时抖动”和“真实故障”，一旦缓存命中，就直接返回旧的503响应，不重新转发请求。
关键点在于：proxy_cache_valid 503 指令若被显式或隐式启用，就会生效；即使没写，某些发行版预设配置或第三方模板可能已包含。
如何确认是否真在缓存503？
别猜，看日志和响应头：
- 检查Nginx error.log里是否有类似 "cache miss due to stale response" 或 "cached 503" 的线索
- 用curl访问触发503的URL，看响应头是否含 X-Cache: HIT 或 Age 字段（非零值说明是缓存返回）
- 执行
sudo nginx -T 2>/dev/null | grep -A5 "proxy_cache_valid"，确认配置中是否对503设定了缓存时间
彻底禁用503缓存的配置写法
在对应server或location块中，明确覆盖默认行为：
-
方案一（推荐）：单独禁用503缓存
添加proxy_cache_valid 503 0s;——0s 表示不缓存该状态码 -
方案二：只缓存成功响应
改用精确声明，例如：proxy_cache_valid 200 301 302 10m;，完全不提5xx，Nginx就不会缓存任何错误码 -
方案三：全局控制（谨慎）
在http块中加proxy_cache_valid any 0s;，再逐个放开需要缓存的成功码
配置后务必 sudo nginx -t && sudo systemctl reload nginx，reload比restart更安全，不中断连接。
额外加固：避免误伤正常流量
光禁用缓存还不够，建议同步做两件事：
-
开启健康检查：在upstream里加
health_check interval=5 fails=1 passes=2;，让Nginx主动探测后端存活，而不是等第一次请求失败才踢掉 -
设置超时与重试：在location中加
proxy_next_upstream error timeout http_503;和proxy_next_upstream_tries 3;，让单次503可自动换节点重试，而非立即返回错误
