502 bad gateway是nginx作为反向代理时上游服务未返回有效响应所致，本质是“上游响应不合格”，而非单纯超时（504）或服务不可用（503）；常见原因包括上游未启动、假死、超时、缓冲区不足、ssl/sni配置错误及缓存绕过逻辑误配等。
缓存绕过本身不会直接导致502，但**错误地配置了缓存绕过逻辑（比如在Nginx或CDN中误写指令），可能让请求被错误路由、转发到不存在的服务、或触发代理层的连接校验失败，最终引发502**。这类问题隐蔽性强，日志里往往只显示“upstream prematurely closed connection”或“no live upstreams”，容易误判为后端挂了。
检查 Nginx 中与缓存绕过相关的配置项
Nginx 常用的缓存绕过指令有 proxy_cache_bypass、proxy_no_cache、add_header 等。若语法写错或条件逻辑冲突，会导致 upstream 解析失败或请求头异常，网关无法完成转发。
-
proxy_cache_bypass 和 proxy_no_cache 的值必须是 0/1 或变量表达式：例如写成
proxy_cache_bypass $cookie_auth "1"是非法的——双引号包裹的字符串不能作为布尔判断依据，Nginx 会静默忽略该行或在 reload 时报错（需用nginx -t验证）；正确写法是proxy_cache_bypass $cookie_auth;或proxy_cache_bypass $arg_nocache; -
add_header 指令不能放在 if 块内：很多用户为“绕过 CDN 缓存”在 location 中加
if ($arg_force = "1") { add_header Cache-Control "no-cache"; }，这在 Nginx 里是不被允许的（语法合法但运行时无效），且可能导致后续 proxy_pass 行为异常；应改用 map 指令预定义变量，再统一控制 -
proxy_set_header 覆盖 Host 后未同步 upstream 名称：例如配置了
proxy_set_header Host "api.internal";，但 upstream 块里没有名为api.internal的 server，Nginx 就找不到目标，直接返回 502
验证 CDN 或网关层的缓存绕过规则是否生效
有些 CDN（如 Cloudflare、阿里云全站加速）支持基于 Query 参数、Header 或 Cookie 的缓存绕过策略。若规则配置错误（比如正则写错、匹配路径遗漏斜杠、大小写敏感未关闭），可能让本该绕过的请求仍走缓存，而缓存中恰好存的是上游 502 响应 —— 此时你看到的“502”其实是缓存回源失败后返回的旧错误页，不是实时错误。
- 用 curl 加 -v 查看响应头中的
X-Cache: HIT或X-Cache-Status: BYPASS，确认是否真绕过了 - 对比带绕过参数（如
?nocache=1）和不带参数的请求，用curl -I分别请求，观察状态码、X-Upstream-Addr是否指向不同后端 IP - 在 CDN 控制台检查规则执行日志，确认匹配动作是否触发，有没有因语法错误（如括号不闭合、引号混用）导致整条规则失效
排查浏览器或本地代理对缓存绕过的干扰
前端开发常在 fetch 请求中加 cache: "no-store" 或手动设置 headers: { "Cache-Control": "no-cache" }，这类行为本身安全，但如果后端网关做了强校验（比如要求所有带 Cache-Control: no-cache 的请求必须携带特定 token），而客户端没传，网关就可能拒绝转发，返回 502。
- 打开浏览器开发者工具 → Network 标签 → 点击一个 502 请求 → 查看 Headers → 确认 Request Headers 中是否有非常规缓存控制字段（如
Pragma: no-cache、X-No-Cache: true） - 用 curl 模拟相同请求头：
curl -H "Cache-Control: no-cache" -H "X-Forwarded-For: 127.0.0.1" https://your-api.com/endpoint，比对是否复现 502 - 检查网关（如 Kong、Traefik）的插件配置，是否存在基于 header 的路由策略或鉴权拦截器，把“绕过缓存”的请求误判为非法请求
