Istio VirtualService请求头覆盖不生效问题咨询

首先得说，你的理解完全没问题——Istio VirtualService里的request.set字段确实是用来覆盖已有请求头的，当客户端发送test: hello时，后端应该收到test: true才对。从你提供的tcpdump结果来看，added: header成功添加、响应头foo也被移除了，唯独test头没被覆盖，这说明头操作的逻辑部分生效，但set规则没被正确执行。

接下来咱们一步步排查可能的原因：

1. 检查VirtualService配置的正确性 #

首先确认你的request.set是不是放在了正确的位置——必须在对应路由规则的headers.request下，而且格式要准确。比如正确的配置应该是这样的：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: server-vs
spec:
  hosts:
    - server
  http:
    - route:
        - destination:
            host: server
      headers:
        request:
          set:
            test: "true"  # 这里是覆盖操作
          add:
            added: "header"  # 这里是添加操作
        response:
          remove:
            - foo  # 移除响应头

要注意：

• set和add都属于request下的同级子字段，不要把set嵌套在add里或者位置错乱
• 字符串值要加引号（比如"true"），避免YAML解析时出现意外问题

2. 确认配置是否已正确应用到Envoy #

有时候配置kubectl apply后，Istio的Sidecar可能没及时刷新配置，你可以用istioctl命令直接检查Sidecar的路由规则：

istioctl proxy-config routes <你的后端Pod名称> -n <命名空间> -o yaml

在输出结果里找到对应路由的headers部分，看看是否存在request_set: {"test": "true"}。如果没有，说明配置没被正确注入，可能需要重启Pod或者检查Istio控制平面的日志，确认是否有配置同步失败的情况。

3. 排查是否有其他Istio资源干扰 #

如果你的集群里还有其他Istio资源，这些资源的头操作优先级可能覆盖VirtualService的配置：

• 检查Gateway的配置，看看是否有针对test头的修改规则
• 检查是否有自定义的EnvoyFilter修改了请求头处理逻辑
• 检查AuthorizationPolicy是否附带了头操作规则

4. 检查Istio版本兼容性 #

某些旧版本的Istio（比如1.8及更早）存在头覆盖的已知bug，如果你用的是旧版本，建议升级到1.10+的稳定版本，或者查看对应版本的Release Notes确认是否有相关修复。

快速验证方法 #

你可以直接在Sidecar容器内发起请求，绕过客户端的请求头，看看后端是否能收到正确的test头：

kubectl exec -it <你的Sidecar Pod名称> -c istio-proxy -- curl -H "test: hello" http://server

然后查看后端日志或者再次抓包，确认头是否被正常覆盖。

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