什么是回环现象
在 TKE 集群中，iptables 或 IPVS 模式下，访问本集群内网 Ingress 会出现4秒延时或不通。IPVS 模式下，集群内访问本集群 LoadBalancer 类型的内网 Service 出现完全不通，或者连通不稳定。
回环现象场景速查
1. 快速判断
通过下表判断连接访问是否受到回环现象的影响：
集群场景 | 是否有回环风险 | 需要处理吗 |
超级节点 + 内网 CLB + CLB Service | 无风险 | 无需处理 |
iptables 模式 + 内网 CLB + CLB Service | 无风险 | 无需处理 |
使用 Service 名称或 ClusterIP 访问 Service | 无风险 | 无需处理 |
公网 CLB + CLB Service / CLB Ingress | 无风险 | 无需处理 |
普通节点/原生节点 + IPVS 模式 + 内网 CLB + CLB Service + 访问 LoadBalancer IP | 有风险 | 需要处理 |
内网 CLB + CLB Ingress + 访问 LoadBalancer IP | 有风险 | 需要处理 |
说明：
为什么集群内用 Service 名称访问没有回环风险？
使用 Service 名称（如
my-svc.default.svc.cluster.local）或 ClusterIP 时，流量在集群内直接转发到目标 Pod，不经过 CLB，因此不存在回环问题。2. IPVS 模式下不同节点类型对 CLB Service 的默认行为
CLB 类型 | 节点类型 | 默认是否拦截 CLB VIP | 回环风险 | 说明 |
内网 CLB | 普通节点 | 不拦截（流量走 CLB） | 有风险 | 默认不在集群内拦截 CLB VIP，流量经过 CLB 转发，同节点时可能回环。 |
内网 CLB | 原生节点 | 不拦截（流量走 CLB） | 有风险 | 行为与普通节点一致。 |
内网 CLB | 超级节点 | 拦截（流量集群内闭环） | 无风险 | 默认在集群内拦截 CLB VIP，流量直接转发到目标 Pod，不经过 CLB。 |
公网 CLB | - | - | 无风险 | - |
说明：
什么是“拦截 CLB VIP”？
当 Pod 访问 CLB VIP 时，集群网络组件在本节点直接将 VIP 转换为后端 Pod IP，流量在集群内完成转发，不需要经过 CLB。这样就避免了 CLB 将流量转发回同节点的问题。
3. 四层场景（Service）速查
场景 | 流量路径 | 回环风险 | 解决方案 |
普通节点/原生节点 + 内网 CLB + IPVS | 经过 CLB | 有回环风险 | |
普通节点/原生节点 + 内网 CLB + IPVS + 已启用集群内转发 | 集群内闭环，不经过 CLB | 无 | 已解决 |
普通节点/原生节点 + 内网 CLB + IPVS + CLB 已开启 SNAT | 经过 CLB | 无 | 已解决 |
超级节点 | 集群内闭环，不经过 CLB | 无 | 无需处理 |
iptables 模式 | 集群内闭环，不经过 CLB | 无 | 无需处理 |
4. 七层场景（Ingress）速查
场景 | 流量路径 | 回环风险 | 解决方案 |
内网 CLB + CLB 未开启 SNAT | 经过 CLB | 有回环风险 | |
内网 CLB + CLB 已开启 SNAT | 经过 CLB | 无 | 已解决 |
注意：
七层回环只能通过 CLB 开启 SNAT 解决，集群内转发方案不适用于七层场景。
解决方案
方案一：集群内转发
适用场景：普通节点/原生节点 + 内网 CLB + IPVS + 4 层 Service
原理：通过添加 annotation，让集群网络组件在节点上拦截对 CLB VIP 的访问，将流量在集群内直接转发到目标 Pod，不再经过外部 CLB，从根本上避免回环。
配置方法：
apiVersion: v1kind: Servicemetadata:name: my-serviceannotations:# 启用集群内转发，避免流量走 CLBservice.cloud.tencent.com/prevent-loopback: "true"spec:type: LoadBalancerselector:app: my-appports:- port: 80targetPort: 8080
注意事项：
启用后，流量不再经过 CLB，因此无法使用 CLB 的能力。
健康探测 IP 会自动改为 100.64 网段，无需额外配置。
对存量长连接无影响，存量连接继续走 CLB；新建连接走集群内转发。
在 TKE Kubernetes Revision 版本历史 检查 kube-proxy 版本，确认版本“支持把 LB 地址绑定到 IPVS 网卡”。
方案二：Service 开启 CLB 4 层监听器 SNAT
适用场景：普通节点/原生节点 + 内网 CLB + IPVS + 4 层 Service + 需要流量经过 CLB
原理：在 CLB 侧开启 SNAT 后，CLB 转发请求到后端时会将源 IP 替换为 CLB 自身 IP。这样后端 Pod 回包时目标地址是 CLB IP，回包必须经过 CLB，不会在节点内部回环。
配置方法：
1. 申请白名单，通过 提交工单 申请开通：
CLB 4 层 SNAT 能力
2. 配置 SNAT：
通过 TkeServiceConfig 配置
spec.loadBalancer.l4Listeners.snatEnable: "true" ，开启 CLB 4 层监听器的 SNAT 功能。注意事项：
TCP 协议可以通过 Proxy Protocol 获取真实客户端 IP。
UDP 协议无法获取真实源 IP。
方案一与方案二对比（四层回环）
维度 | 集群内转发（拦截 CLB VIP） | CLB 开启 SNAT |
原理 | 在节点上拦截 CLB VIP，流量集群内闭环 | CLB 替换源 IP，使回包必须经过 CLB |
流量是否经过 CLB | 不经过 | 经过 |
回环风险 | 无 | 无 |
CLB 高级能力 | 不可用（流量不经过 CLB） | 可用 |
获取真实源 IP | 可以获取 | TCP 可通过 Proxy Protocol 获取，UDP 无法获取 |
方案三：七层 Ingress 开启 CLB SNAT
适用场景：内网 CLB + 7 层 Ingress
原理：在 CLB 侧开启 SNAT 后，CLB 转发请求到后端时会将源 IP 替换为 CLB 自身 IP。这样后端 Pod 回包时目标地址是 CLB IP，回包必须经过 CLB，不会在节点内部回环。
配置方法：
1. 申请白名单，通过 提交工单 申请开通：
CLB 7 层 SNAT 能力
Keep Alive 能力
2. 配置 SNAT：
当 ingress-controller 版本大于等于 v2.9.0 时，通过 TkeServiceConfig 配置
spec.loadBalancer.l7Listeners.snatEnable: "true" ，开启 CLB 7 层监听器的 SNAT 功能。当 ingress-controller 版本小于 v2.9.0 时，通过 TkeServiceConfig 配置
spec.loadBalancer.l7Listeners.keepaliveEnable: 1 ，开启 CLB 7 层监听器的 SNAT 功能。注意事项：
开启后，需从
X-Forwarded-For HTTP Header 获取真实源 IP。注意节点配置放通 LoadBalancer IP 网段的访问。
常见问题
Q1: 为什么超级节点下 Service 没有回环问题？
超级节点默认会在集群内拦截 Service 关联 CLB 的 VIP，流量直接转发到目标 Pod，不经过 CLB，因此不存在回环问题。
Q2: 为什么 iptables 模式下 Service 没有回环问题？
iptables 模式下，数据包在路由之前就完成了目标地址转换，流量直接在集群内闭环转发到目标 Pod，不经过 CLB，因此不存在回环问题。
Q3: 添加 service.cloud.tencent.com/prevent-loopback: "true" annotation 后对现有业务有影响吗？
存量长连接：不受影响，继续走 CLB。原因是 conntrack 条目已存在，优先匹配，沿用原路径。
新建连接：改为集群内转发，不走 CLB。原因是新 SYN 包走路由决策，命中 local 表，被 IPVS 拦截。
