为何针对外部域名设置TCP空闲超时的Istio EnvoyFilter无法生效？

• 初版新结构配置报错的原因：你最开始使用的spec.configPatches结构是Istio 1.6+版本才支持的CRD定义，当前使用的1.2.5版本CRD无法识别这个非标准字段，解析时直接忽略该配置块，校验阶段找不到必填的spec.filters配置项，因此抛出missing filters的校验错误。
• 修改后配置无效果的原因：1.2.5版本的EnvoyFilter生效逻辑要求匹配规则必须精准定位到Envoy实例上真实存在的Listener，你之前的配置仅指定了listenerType: SIDECAR_OUTBOUND和listenerProtocol: TCP，没有指定Listener的实际监听地址、端口，也没有配置filterChain层面的匹配规则，系统无法定位到可注入patch的目标Listener，因此patch操作直接被丢弃，没有任何实际效果。
• 对address匹配项的认知误区：listenerMatch下的address配置是用来匹配Envoy Listener自身的监听地址，不是匹配流量的目的地址。Sidecar的出站TCP监听器是固定监听在0.0.0.0:15001的，所有出站TCP/TLS流量无论访问哪个外部IP、哪个域名，都会走这同一个公共Listener，根本不会为单个外部域名单独创建独立Listener，因此依赖固定IP匹配动态域名的思路本身就不成立。
• 旧版配置缺乏域名维度的匹配能力：之前的配置没有添加filterChain层面的域名匹配规则，就算匹配规则生效，也会给所有出站TCP连接全局应用5s超时，根本做不到仅针对some.app.com生效。

完全可以实现仅对some.app.com的出站连接应用5s空闲超时，不需要依赖固定IP地址，核心逻辑是通过TLS握手阶段的SNI标识做精准匹配，适配IP动态变化的场景。

适配1.2.5版本的正确配置 #

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: tcp-idle-timeout-someapp
spec:
  workloadSelector:
    labels:
      app: mecha-dev
  filters:
    - listenerMatch:
        listenerType: SIDECAR_OUTBOUND
        # 精准匹配sidecar公共出站TCP监听器的实际监听地址与端口
        listenerAddress: 0.0.0.0
        listenerPort: 15001
        # 通过SNI规则匹配目标域名的流量filterChain，动态IP场景下无需固定地址
        filterChainMatch:
          sniHosts:
            - some.app.com
      filterType: NETWORK
      filterName: envoy.tcp_proxy
      # 合并配置到已存在的TcpProxy过滤器，覆盖默认的空闲超时值
      filterConfig:
        idle_timeout: 5s

生效逻辑说明 #

• 配置中的匹配规则没有使用目的IP，而是在filterChain层面通过SNI标识做流量区分：Istio会为所有带SNI的TLS出站流量，在15001的公共出站Listener下生成独立的filterChain，匹配规则为对应的SNI域名。无论some.app.com解析到哪个动态IP，只要客户端发起TLS握手时携带的SNI字段为some.app.com，就会命中这个filterChain，加载配置的5s空闲超时规则。
• 因为是MERGE式的配置注入，不会改动原有TcpProxy的路由、集群等其他配置，仅追加idle_timeout字段，不会对其他域名的流量产生影响。

场景限制 #

如果访问some.app.com的流量是不带TLS、不携带SNI的明文TCP流量，1.2.5版本没有可用于精准识别动态域名的稳定标识，这种场景下无法实现仅针对该域名的超时配置，只能全局配置出站TCP的空闲超时。

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