多层Nginx反向代理中Vary头需分层治理：边缘层按需添加并归一化，中间层仅透传不修改，接入层显式补全；须统一用always参数、禁用proxy_ignore_headers Vary、确保Vary与proxy_cache_key严格对齐。
多层 Nginx 反向代理级联时，Vary 响应头容易被重复添加、覆盖或透传失控，造成下游缓存（如浏览器、CDN）误判缓存键，引发内容错乱、CORS 失败或缓存命中率骤降。治理核心不是“统一加 Vary”，而是“逐层明确责任、隔离影响、精准透传”。
明确每层 Nginx 的 Vary 职责边界
不能所有层都盲目 add_header Vary；必须按链路角色划分：
- 边缘层（接客户端/CDN）：负责识别真实请求特征（如 Origin、Accept-Language），做归一化（如用 map 合并 UA 为 desktop/mobile），并决定是否需 Vary —— 仅当本层或后端真据此生成不同响应时才加
- 中间网关层（路由/鉴权）：原则上不修改、不新增 Vary；只透传上游已确定的 Vary 头，禁用 proxy_ignore_headers Vary；避免叠加或覆盖
- 接入层（直连后端）：若后端未返回 Vary，且你确认该响应实际依赖某请求头（如 $http_origin），则在此层显式 add_header Vary Origin always；同时确保 proxy_cache_key 已含对应变量
防止 Vary 头重复注入与覆盖
多层配置中常见问题：A 层加了 Vary: Origin，B 层又加一次，导致响应头变成 Vary: Origin, Origin 或被覆盖为 Vary: User-Agent。解决方法：
- 所有 add_header 指令统一加 always 参数（如
add_header Vary "Origin" always;），避免因内部重定向或子请求失效 - 禁用可能干扰的指令：
proxy_ignore_headers Vary;必须删除或注释；它会直接丢弃上游 Vary，造成下游缓存行为不可控 - 用
more_set_headers（需安装 headers-more 模块）替代部分 add_header，支持条件覆盖或清空再设，更可控
确保 Vary 与缓存键严格对齐（跨层级协同）
Vary 告诉缓存“哪些头变了就得换缓存”，而 proxy_cache_key 决定“缓存存在哪”。二者不一致，等于告诉缓存一套、存另一套。
- 若某层决定 Vary: Origin，则其 proxy_cache_key 必须包含
$http_origin；建议用 map 统一空 Origin 为 "null"，避免有/无 Origin 请求缓存分裂 - 中间层若不做缓存，可不配 proxy_cache_key，但必须确保
proxy_pass_request_headers on;，且不篡改原始 Vary - 边缘层若启用缓存，其 cache_key 应融合归一化后变量（如
$device_type），且 add_header Vary 中对应写X-Device-Type，而非原始 UA
验证多层 Vary 状态是否洁净
不只看最终响应头，要分层抓包或查日志确认透传路径：
- 用 curl 加 -v 和多个 Origin 模拟请求，观察响应中 Vary 是否唯一、无重复、值合理
- 在各层 Nginx 的 log_format 中加入
$upstream_http_vary和$sent_http_vary，比对输入 Vary 与输出 Vary 是否一致 - 检查 X-Cache 或自定义缓存标识头：同一 Origin 下多次请求应 HIT；不同 Origin 应各自 HIT（非混用），且无意外 MISS
