bypass是主动绕过缓存的规则行为，非故障；需先确认日志中$upstream_cache_status真实为bypass值，再核查proxy_cache_bypass规则是否合理匹配业务意图，避免与cache_key冲突。
缓存绕过（Cache Bypass）不是故障，而是明确被规则触发的主动行为。排查重点不在“修复”，而在“确认是否合理”——即：这个请求本该走缓存，还是本就不该？日志中状态异常，通常指向配置逻辑与业务意图不一致。
看日志里是否真有 $upstream_cache_status = BYPASS
必须先确认日志字段真实存在且值为 BYPASS，而不是空、短横（-）或缺失。常见误判来源：
- log_format 里没加
$upstream_cache_status，导致该列为空或错位，误把其他字段当状态 - location 块没启用对应 access_log，或用了默认格式，压根不记录缓存状态
- 请求根本没进 proxy_pass 流程（比如被 rewrite 拦截、返回 404 或 302），$upstream_cache_status 不生效
查触发 bypass 的具体规则
BYPASS 是由 proxy_cache_bypass 指令显式控制的，它检查的是请求头或变量。常见触发条件包括：
-
proxy_cache_bypass $arg_nocache $cookie_nocache;→ 只要 URL 带?nocache=1或 Cookie 含nocache=1，就跳过缓存 -
proxy_cache_bypass $http_pragma $http_authorization;→ 普通浏览器带Pragma: no-cache或含认证头时强制回源 - 自定义变量如
$http_x_no_cache，常用于灰度或内部调试开关
用 curl -I -H "X-No-Cache: 1" https://your.site/path 复现一次，再查日志，就能验证是否是该头导致。
比对缓存 key 和 bypass 条件是否冲突
有时 bypass 看似合理，实则是 key 设计和 bypass 规则打架。例如：
- cache_key 包含了
$arg_utm_source，但 bypass 规则又写了proxy_cache_bypass $arg_utm_source - 结果：只要带 utm 参数，一律 bypass → 缓存形同虚设
- 正确做法：bypass 应只响应真正需要绕过的信号（如调试头、管理接口），而非业务参数
检查响应头是否暴露 bypass 行为
建议在 server 或 location 块加一句：
add_header X-Cache-Status $upstream_cache_status always;
这样用 curl -I 直接看到响应头，无需翻日志。若返回 X-Cache-Status: BYPASS，再结合请求头反推规则；若返回空或 X-Cache-Status: -，说明请求根本没走到 cache 流程，问题在更上层（如 location 匹配、rewrite、return）。
