WebSocket请求不适用proxy_cache_bypass，因其基于HTTP升级后脱离HTTP生命周期，缓存机制完全不介入；应通过独立location块禁用所有缓存指令并显式关闭proxy_cache、proxy_buffering来确保绕过缓存。
proxy_cache_bypass 本身不适用于 WebSocket 请求，因为 Nginx 的 proxy_cache 系列指令（包括 proxy_cache_bypass）仅对 HTTP/HTTPS 请求生效，而 WebSocket 协议基于 HTTP 升级（Upgrade: websocket），一旦连接升级完成，就脱离 HTTP 生命周期，进入长连接二进制帧通信阶段——此时缓存机制完全不介入。
所以，确保 WebSocket 请求“永远不进入缓存逻辑”的关键，不是配置 proxy_cache_bypass，而是从协议层面阻止缓存模块参与处理。以下是真正有效、符合 Nginx 行为的设计方式：
明确分离 WebSocket 和普通 HTTP 路由
WebSocket 连接必须使用独立的 location 块，并禁用所有缓存相关指令。例如：
# ✅ 正确：专用于 WebSocket 的 location，彻底避开缓存
location /ws/ {
proxy_pass http://backend_ws;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# ⚠️ 关键：不写 proxy_cache、proxy_cache_bypass、proxy_cache_valid 等任何缓存指令
# 同时显式关闭可能隐式触发缓存的行为（如 proxy_buffering）
proxy_buffering off;
proxy_cache off; # 显式关闭（虽非必需，但语义清晰、防误配）
}
避免 WebSocket 路径被普通缓存 location 意外捕获
常见错误是用宽泛的 location / 或 location ~ \.api 匹配了 /ws/ 或 /socket.io/，导致缓存指令被继承：
# ❌ 危险：这个 location 可能覆盖 WebSocket 请求
location / {
proxy_cache my_cache;
proxy_cache_bypass $http_x_refresh;
proxy_pass http://backend;
}
# ✅ 补救：在它之前，用更精确的前缀或正则优先匹配 WebSocket
location ^~ /ws/ { ... } # 前缀匹配优先于 /，且不继承父级缓存
location ~ ^/(socket\.io|engine\.io)/ { ... }
验证 WebSocket 确实绕过缓存逻辑
无需检查 $upstream_cache_status（它对 WebSocket 请求恒为空或未定义），只需确认两点：
- 响应头中没有
X-Cache-Status或X-Cache类字段（说明未执行缓存流程） - Nginx access log 中该请求的
$upstream_cache_status字段为-或空（而非HIT/MISS/BYP） - 使用
curl -i -H "Connection: upgrade" -H "Upgrade: websocket" http://your.site/ws/，响应状态码应为101 Switching Protocols，且无缓存相关 header
补充：为什么不能靠 proxy_cache_bypass $http_upgrade？
有人尝试在通用 location 中加：
proxy_cache_bypass $http_upgrade;
这是无效的。因为：
-
$http_upgrade在 WebSocket 升级请求中值为"websocket"（非空 → 触发 bypass） - 但
proxy_cache_bypass只影响缓存读取行为，不阻止proxy_cache尝试写入响应；而 WebSocket 响应是101状态，Nginx 默认不会缓存 101 响应（即使配置了proxy_cache_valid 101 1m，实际也无效） - 更重要的是：一旦
proxy_cache指令存在，Nginx 会在请求处理早期初始化缓存上下文，带来不必要的开销和潜在干扰（如 buffer 管理冲突）
所以，最干净的做法就是——让 WebSocket 请求根本不经过缓存路径。
不复杂但容易忽略
