Kubernetes Nginx Ingress 如何向后端服务有效传递Token？

两个独立的问题叠加，直接导致了透传失效：

• Nginx核心层默认丢弃所有带下划线的请求头
  Nginx全局默认配置为underscores_in_headers off，所有名称带下划线的请求头会在连接接收的最底层被直接丢弃，根本不会进入Ingress的后续请求处理流程。access_token恰好带了下划线，直接触发了这个默认丢弃规则——和你在Ingress层加的任何透传注解都没有关系，请求头在到达Ingress配置逻辑前就已经被删掉了。这也完美匹配你之前的测试结果：不带下划线的自定义请求头都能正常透传，只有换成access_token这个带下划线的头时才会失效。
• 配置的注解完全适配错了使用场景
  nginx.ingress.kubernetes.io/auth-response-headers的设计目标是，当Ingress对接外部鉴权流程时，把鉴权服务返回的自定义响应头透传给后端，从来不是用来透传客户端直接发送的原始请求头的。用这个注解做客户端请求头透传，从设计逻辑上就不会生效。

你之前的认知没有问题：不带特殊规则的普通自定义请求头，Nginx Ingress默认全量透传，根本不需要在全局ConfigMap里逐字段罗列做透传白名单。失效纯粹是踩了下划线头的默认过滤坑。

完全满足「不修改全局ConfigMap配置、由开发者自行在所属Ingress资源上维护规则」的要求，可二选一执行：

方案1：单Ingress维度放开下划线头接收权限 #

给需要透传access_token的对应Ingress资源增加如下注解，仅对当前Ingress绑定的路由域名单独开启下划线头接收，完全不改动全局默认规则：

nginx.ingress.kubernetes.io/server-snippet: |
  underscores_in_headers on;

该配置仅作用于当前Ingress的服务路由范围，不会影响其他路由的默认头过滤规则，也不会带来全局开启下划线头可能引发的请求头伪造风险。配置生效后，access_token会被Nginx正常接收，作为普通自定义头按照默认透传规则直接发送到后端，不需要额外添加透传注解。

方案2：调整请求头名称规避Nginx默认规则 #

将团队统一使用的access_token请求头名称替换为不带下划线的格式，比如调整为AccessToken或access-token。这类无下划线的请求头完全符合Nginx默认透传规则，不需要修改任何Ingress注解、也不需要改动全局配置，即可实现全链路正常透传。

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