要让 proxy_no_cache 真正按业务意图工作，关键是构建“可读、可验、不误伤”的信号拦截链：必须与 proxy_cache_bypass 成对出现，所有逻辑统一用 map 转为 0/1 布尔值，默认全为 0，仅对明确标记的请求干预。
要让 proxy_no_cache 真正按业务意图工作，关键不是简单加个变量，而是构建一套“可读、可验、不误伤”的信号拦截链——它必须和 proxy_cache_bypass 成对出现，所有判断逻辑统一用 map 提前转成 0/1 布尔值，默认全为 0，只对明确标记的请求干预。
用 map 统一提取业务信号，避免硬编码陷阱
直接在 proxy_no_cache 里写 $cookie_sessionid 或正则，容易漏判、难维护、易误伤。应把各类业务特征都转为标准化布尔变量：
- 登录态识别：
map $cookie_sessionid $no_cache_by_login { ~. 1; default 0; }（非空即视为已登录） - 角色控制：
map $http_x_user_role $no_cache_by_role { "admin" 1; "editor" 1; default 0; } - 终端区分：
map $http_user_agent $no_cache_by_ua { ~*Mobile 1; ~*WeChat 1; default 0; } - 调试开关：
map $args $no_cache_by_debug { ~debug=1 1; ~nocache=1 1; default 0; } - 敏感路径：
map $request_uri $no_cache_by_path { ~*^/admin/ 1; ~*^/api/v1/profile 1; default 0; }
location 中必须成对启用 bypass 和 no_cache
这两个指令是“读写双拦截”的左右手，缺一不可，且变量列表必须完全一致：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache_bypass $no_cache_by_login $no_cache_by_role $no_cache_by_ua $no_cache_by_debug $no_cache_by_path;→ 请求阶段跳过缓存查找，直连后端 -
proxy_no_cache $no_cache_by_login $no_cache_by_role $no_cache_by_ua $no_cache_by_debug $no_cache_by_path;→ 响应阶段禁止写入缓存，防止敏感内容残留 - Nginx 的触发逻辑是“或”：任一变量值为 1，整条请求就全程脱离缓存链路
守住默认缓存友好性，排除静态与匿名流量
绝大多数请求不该被干扰，缓存策略的底线是“默认走缓存，仅精准绕过”：
- 所有
map的default必须设为 0，这是防误伤的第一道防线 - 不要在
http块中全局写proxy_no_cache $cookie_sessionid，空 Cookie 会被当作非空字符串，导致未登录用户也被绕过 - 为
/static/、/images/、.js、.css等路径单独配location，跳过上述 map 判断，改用expires或proxy_cache_valid管理生命周期
验证是否生效：看响应头 + 日志联动
配置完别只靠猜，用实际请求验证：
- 发起一个带
Cookie: sessionid=abc123的请求，响应头应含X-Cache-Status: BYP或X-Cache: MISS，且无X-Cache: HIT - 检查 Nginx access log，确认该请求没命中缓存（日志中不应出现
cache HIT字样） - 若需灰度控制，可加自定义 header 如
X-Abtest-Flag: on，对应新增map $http_x_abtest_flag $no_cache_by_abtest { "on" 1; default 0; }
