$upstream_cache_status 为 bypass 表明 bypass 触发，但需四层交叉验证：配置中 bypass 条件变量须非空且不等于"0"；请求参数、header、cookie 值格式须准确；bypass 指令须与 cache 指令同 location；响应头和日志需外显确认；并排除 proxy_no_cache 等干扰。
确认 $upstream_cache_status 值为 BYPASS，说明请求确实触发了 proxy_cache_bypass 或 fastcgi_cache_bypass，但仅看到这个值还不够——得验证它是否按预期生效、有没有被意外覆盖或干扰。排查需从配置、请求、响应和日志四个层面交叉印证。
检查 bypass 条件是否真实满足
变量值必须非空且不等于 "0"（字符串 0）才触发 bypass。常见误判点：
-
$arg_nocache：请求带?nocache（无等号）时值为空，不触发；要写成?nocache=1或用map预处理 -
$http_x_bypass_cache：Header 名自动转小写下划线，X-Bypass-Cache→$http_x_bypass_cache，大小写或拼写错误会导致变量始终为空 -
$cookie_dev_mode：Cookie 值需是dev_mode=1，若设为dev_mode=true或含空格（如dev_mode= 1），Nginx 会视为空或非法值
确认 bypass 指令与缓存指令共存于同一 location
单独写 proxy_cache_bypass 无效。必须确保：
- 所在
location块中已启用proxy_cache（或fastcgi_cache） - 没有被更高优先级的
location或if块覆盖或跳过该配置块 - 未在
server或http级别误写 bypass 指令（Nginx 忽略）
验证响应头与日志是否一致
仅靠 $upstream_cache_status 是内部变量，需外显才能可靠观察：
- 在对应 location 中加：
add_header X-Cache-Status $upstream_cache_status;，用curl -I查响应头是否为X-Cache-Status: BYPASS - 配置日志格式包含该变量，例如：
log_format cache '$remote_addr "$request" $upstream_cache_status $status';，再查 access log 是否稳定输出BYPASS - 对比普通请求（无 bypass 条件）是否返回
HIT或MISS，排除全局 bypass 导致所有请求失效
排除 proxy_no_cache / fastcgi_no_cache 干扰
如果只配了 bypass 却没配对应的 proxy_no_cache，响应仍可能被缓存，后续请求可能命中脏数据——但这不影响当前请求的 BYPASS 状态。不过，若误将 bypass 变量也用于 no_cache，而该变量在某些场景下恒为真（比如 $cookie_sessionid 在登录态下总存在），就可能导致所有用户请求都 bypass，掩盖真实问题。建议检查两者变量是否严格一致、逻辑是否对齐。
