401响应必须禁止缓存，因其是每次请求前置鉴权结果，不可复用；需配置Cache-Control: no-store等响应头、排除Authorization入缓存键、确保鉴权插件执行优先于缓存插件。
API网关鉴权失败（401）后直接绕过缓存返回错误，不是“配置缓存策略”，而是**必须阻止缓存介入鉴权流程本身**。因为401是认证层拦截结果，一旦被缓存，后续请求会直接返回旧的401响应，掩盖真实问题，甚至导致凭据修复后仍持续报错。
为什么401不该进缓存
鉴权是每次请求必经的前置校验，不依赖模型、路径或参数内容。网关在解析 Authorization 头、校验 Key 有效性时就已决定是否放行。这个动作本身无状态、不可复用——上一次 401 是因为 Key 过期，下一次可能已刷新；上一次是头格式错误，下一次已修正。缓存它等于把“错误快照”当成事实分发出去。
关键配置点：在网关层禁用 401 响应缓存
不同网关实现略有差异，但核心原则一致：让 401 响应携带明确的缓存拒绝指令，并确保鉴权逻辑在缓存查找之前执行。
-
响应头强制设置：所有鉴权失败响应中，必须包含
Cache-Control: no-store, no-cache, must-revalidate, max-age=0和Pragma: no-cache。部分网关（如 Kong、AWS API Gateway）支持全局响应头注入规则，优先在此处统一配置。 - 缓存键排除鉴权字段：若网关支持自定义缓存键（cache key），确保不把 Authorization 头、Bearer Token 或 API Key 值纳入哈希计算。否则相同 Key 的多次失败请求会被当作同一缓存项反复返回。
-
鉴权插件位置高于缓存插件：在插件执行顺序中，鉴权（authn/authz）模块必须排在缓存（proxy-cache、response-cache）模块之前。例如在 Kong 中，
key-auth或jwt插件需启用在response-cache之前；在自研网关中，须保证 middleware 链中 auth 拦截器先于 cache handler 执行。
验证是否生效的实操方法
别只看文档，用 curl 直测响应头：
- 发起一个注定失败的请求（如传空 Key 或错格式）：
curl -i -X POST https://api.example.com/v1/chat/completions \<br>-H "Authorization: Bearer invalid_key" \<br>-H "Content-Type: application/json" \<br>-d '{"model":"test","messages":[{"role":"user","content":"hi"}]}' - 检查返回响应头中是否存在
Cache-Control且值为no-store或含no-cache；
同时确认没有X-Cache: HIT或类似缓存命中标识。 - 连续发两次同样请求，观察第二次响应的
Date头是否与第一次不同——若相同，说明被缓存了；若不同，说明已绕过。
额外提醒：客户端也别缓存401
前端 SDK、移动端或浏览器侧，对 401 响应做本地缓存（如 Service Worker 拦截并存入 Cache Storage）同样危险。应在 fetch 拦截逻辑中显式排除 401：if (response.status === 401) return response; // 不存入 cache
