阿里云代金券充值 阿里云 ACK Pod 无法获取正确的 Client IP（源 IP 被 SNAT 替换）配置修复

阿里云 ACK Pod 无法获取正确的 Client IP，最常见的情况不是应用代码写错，而是请求在进入集群的过程中被 Service、Ingress、负载均衡或代理层做了 SNAT，最后到 Pod 里只剩节点 IP、SLB IP 或代理出口 IP。要修复这类问题，先别急着改业务代码，先把流量路径摸清楚，再决定是改 Kubernetes 服务配置，还是改入口代理配置。

阿里云 ACK Pod 无法获取正确的 Client IP：先判断是哪一层做了 SNAT

很多人一上来就盯着应用日志里的 remote_addr，其实真正要先看的是请求从哪里进来。只要中间经过了会转发流量的入口，源 IP 就可能被替换。

• 如果外部流量先到 CLB、NLB、ALB 或 Ingress，再转到 Pod，先看负载均衡和代理是否保留了原始地址。
• 如果 Service 走的是默认转发模式，跨节点转发时经常会看到节点 IP 代替真实客户端 IP。
• 如果前面还有 CDN、WAF、API 网关，Pod 里看到的往往只是上一跳出口地址，不是最初访问者地址。

三种最常见的表现

最实用的修复顺序

1. 先确认流量入口。是直接打到 Service，还是先经过 Ingress、CLB、NLB、WAF 或网关。
2. 如果是 Kubernetes Service 对外暴露，优先把 Service 的外部流量保留源地址配置打开，常见做法是设置 externalTrafficPolicy: Local。
3. 如果前面有 Ingress 或反向代理，不要只看网络层，要同时确认代理是否把真实客户端地址写进了 X-Forwarded-For、X-Real-IP 或代理协议。
4. 如果应用程序直接读取的是 socket 连接地址，而不是代理头，就算负载均衡已经保留了地址，日志里也可能还是不对，应用侧需要按实际链路读取真实来源字段。
5. 改完后别只做一次访问测试，最好用不同入口、不同节点、不同终端各测一次，确认不会只在单节点或单路径下生效。

如果你的业务只是普通内部调用，未必需要强行保留 Client IP；但如果涉及登录风控、黑名单、地域限制、审计留痕、限流策略，保留源 IP 基本就是刚需。

哪些业务场景必须先修这个问题

• 登录、验证码、短信触发、接口防刷：没有真实 IP，很难做频率控制和异常识别。
• 支付、下单、交易回调：风控通常要结合来源地址判断异常访问。
• 企业内网系统、审计系统：需要保留访问者来源，便于追查操作链路。
• 按地域放行或封禁：如果只看到代理 IP，地域判断会直接失真。
• 白名单接口：很多内部系统会把固定来源 IP 写进白名单，SNAT 后会误判成非法访问。

修复前先把账号、资源和费用问题排掉

实际操作里，很多团队不是技术方案不会改，而是账号侧、资源侧卡住了，导致配置改一半就停了。这个部分经常被忽略。

• 账号购买和开通：如果是新账号，先确认是个人账号还是企业账号；企业场景一般建议尽早完成企业认证，后面申请配额、开通资源、找工单支持会少很多阻塞。
• 实名认证和企业认证：未完成认证时，部分网络资源申请、权限开通、白名单处理会受限，排障节奏会被拖慢。
• 充值续费和支付方式：修改负载均衡、创建额外入口、扩容节点都可能触发计费，余额不足或支付方式不可用时，常见情况是资源创建成功一半又失败。
• 风控审核：跨境支付、国际卡、异常登录环境、频繁开通和释放资源，可能触发审核；如果要赶上线，最好提前处理，不要等到生产切流当天再补资料。
• 资源限制：CLB、NLB、EIP、证书、节点数、弹性公网带宽、Ingress 实例数都可能有配额；如果你计划用 externalTrafficPolicy: Local，还要确认各节点上的 Pod 分布是否够均匀，避免部分节点无后端导致流量打空。
• 成本控制：为了保留源 IP 额外加一层入口并不一定划算。测试环境可以先用最小化方案验证，生产再决定是否需要独立 LB、独立公网入口、日志采集和审计组件，避免为了一个排障点引入长期费用。

常见错误

• 阿里云代金券充值 只改应用代码，不改入口配置，结果日志还是拿到代理地址。
• 只在一个 Service 上改成 Local，但前面还有 Ingress 没配透传，最后还是看不到真实来源。
• 把测试环境和生产环境的入口链路混为一谈，测试能看到真实 IP，生产却经过了更多代理层。
• 阿里云代金券充值 没有检查节点和 Pod 分布，结果开启本地保留后，部分节点因为没有后端而出现访问不均。
• 忽略费用和配额，配置做到一半才发现没有可用资源或审批没过。

FAQ

Pod 里看到的是 CLB 的 IP，是不是一定要改成 Local

不一定。先看你的业务是否真的依赖真实客户端 IP。如果只是普通内部服务，看到上游代理地址也能接受，就没必要强行改；如果要做风控、审计或白名单，就要把链路改到能保留源地址的位置。

改了 externalTrafficPolicy: Local 还是不对，问题通常在哪

常见原因是前面还有 Ingress、WAF、CDN 或网关，真正的源地址在更前一层就已经被替换了；也有一些应用读取错了字段，只看 socket 连接地址，不看代理头。

生产环境改这个配置会不会影响现网

会有影响，尤其是节点上没有后端 Pod 的时候，流量分布会和默认模式不一样。建议先在低峰期、小流量路径上验证，再逐步放量。

如果账号还没完成企业认证，能不能先做验证

阿里云代金券充值 可以先在测试环境验证思路，但如果后续要开更多网络资源、做正式切流或处理支持工单，企业认证和支付方式最好提前准备好，不然会卡在账号侧。

最后怎么判断要不要现在就改

如果你的业务有风控、审计、白名单、地域访问控制、黑名单或接口限流，这个问题通常应该优先处理；如果只是内部调用，且当前链路已经有别的方式记录来源，那可以先放到后续优化。判断标准很简单：只要真实来源会影响业务决策，就不要让 SNAT 把它吞掉。