我之前也碰到过完全一样的情况，大概率是中间代理层（比如CDN、WAF或者组件自身的头部规则）在搞鬼——Cache-Tag这个头名刚好命中了某些自动规范化或过滤的逻辑，导致短横线被自动移除，而类似X-Cache-Tag这类带前缀的头不在规则范围内，所以能正常生效。

下面针对HAProxy和Nginx分别给出具体的排查和解决办法：

HAProxy 解决方案 #

1. 升级到稳定版
   某些旧版本的HAProxy对带短横线的自定义响应头处理存在bug，建议升级到最新的稳定版（比如2.8+），很多这类兼容性问题在新版本里已经修复。

2. 改用set-header替代add-header
add-header是追加头部，优先级较低，容易被其他规则覆盖。换成set-header强制设置，能绕过部分自动修改逻辑：

   http-response set-header "Cache-Tag" "html" if { hdr_sub(content-type) -i html }
   

3. 排查其他配置或模块干扰
   检查HAProxy的frontend、backend是否有其他头部处理规则（比如http-response del-header），或者是否加载了第三方模块（如WAF模块）在自动清理头部，这类模块可能会把Cache-Tag误判为需要过滤的头。

Nginx 解决方案 #

1. 使用more_set_headers指令
   原生的add-header优先级较低，如果被其他规则覆盖，建议使用ngx_http_headers_more_module模块的more_set_headers指令，它的头部操作优先级更高，不会被默认规则干扰：

   # 全局或server/location块内配置
   more_set_headers "Cache-Tag: html";
   # 带条件判断的版本
   if ($content_type ~* html) {
       more_set_headers "Cache-Tag: html";
   }
   

   注意：这个模块默认不包含在Nginx官方包中，需要编译时添加--add-module=path/to/headers-more-nginx-module，或者使用预编译的包含该模块的发行版（比如OpenResty）。

2. 排查头部覆盖或隐藏规则
   检查Nginx配置中是否存在proxy_hide_header Cache-Tag这类指令，或者上游服务器是否主动隐藏了这个头；另外，某些安全模块（如ModSecurity）也可能会过滤自定义头，需要在规则中放行Cache-Tag。

通用排查步骤 #

1. 直接验证后端服务
   用curl -I直接访问后端应用服务器，确认后端本身没有返回或修改Cache-Tag头，排除后端的问题。

2. 开启头部调试日志

   • HAProxy：在frontend或backend中添加capture response header Cache-Tag len 100，然后在日志格式中引用%hrl来查看捕获的响应头，确认HAProxy是否正确生成了Cache-Tag。
   • Nginx：在log_format中添加$sent_http_cache_tag，查看日志里是否有这个字段的值，判断Nginx是否成功发送了该头。

3. 检查上层代理/CDN
   如果你的服务前面还有CDN（比如Cloudflare、阿里云CDN），很多CDN会对自定义头进行过滤，需要在CDN控制台的“HTTP头部设置”中添加允许Cache-Tag头通过的规则，或者直接配置CDN返回这个头。

内容的提问来源于stack exchange，提问作者Ryan