在验证码部署于CDN之后，要让服务端仍能识别用户的真实来源IP，关键在于在边缘正确生成可信的客户端IP标识，并在反向代理链路中层层透传、在源站严格校验与解析。**建议统一采用规范化的“Forwarded/X-Forwarded-For”策略、限定可信代理范围、结合签名或mTLS构建“可信链”，从而让验证码风控与审计准确基于真实IP。**

# 验证码在CDN后面：如何正确获取真实IP与工程实践

## 一、业务场景与挑战：为什么验证码必须拿到真实IP
当验证码服务位于CDN或WAF之后，请求首先被边缘节点接收并转发，这会导致源站默认看到的“客户端地址”是CDN的出口IP而非用户真实IP。**对验证码而言，真实IP是风控画像、黑名单比对、频次限制与合规取证的重要维度**，与设备指纹、Cookie、指纹标识一起构成反自动化识别的基线特征。缺失真实IP会让风控阈值漂移，干扰验证码触发策略与评估准确率。

在全球化场景中，CDN会使用Anycast、IPv6和HTTP/3等多种链路优化，源站更难直接感知客户端网络细节。**多级代理、多云混布、多CDN切换会引入更复杂的X-Forwarded-For链路**，其中包含了多跳IP，顺序、可信范围和私网地址过滤都决定了解析结果是否可信。隐私增强技术与代理（如企业代理、移动NAT）也让“每用户唯一IP”的假设逐渐失效，需要更稳健的解析与多信号融合。

除风控准确性之外，**监管合规与审计留痕也要求对访问来源进行可验证记录**。当验证码被用于敏感业务（注册、登录、领券、抢票等），真实IP与时间戳、UA和会话ID共同构成取证链。若误将CDN节点IP记为客户源IP，将严重影响安全回溯、告警处置与跨区域风控策略的合理性，尤其在多地域合规管理时更为突出。

## 二、真实IP的判定标准与“可信链路”
行业通常采用IETF定义的Forwarded头或事实标准X-Forwarded-For（XFF）来传递客户端IP。根据IETF RFC 7239（IETF, 2014），Forwarded可携带“for, proto, by, host”等字段，提供更统一且可解析的语义。**在CDN场景，边缘节点应在入口处生成或规范化真实“for”值，并在后续反向代理仅在可信范围内追加或保留**，避免被终端或非可信代理伪造。

除Forwarded与XFF外，主流CDN还会提供自有头部，如True-Client-IP、CF-Connecting-IP、Fastly-Client-IP、X-Azure-ClientIP等。**工程上建议确立“权威头部优先级”，在已知CDN来源时以官方头部为准，在多CDN与自建代理共存时，统一映射到一个“内部标准头”**，以便在验证码网关与风控模块中减少分支逻辑与歧义解析。对X-Real-IP，可作为兜底信息，但不应与XFF并列竞态。

可信链的核心是“谁有权限写入IP头部”。源站需要配置可信代理网段白名单（如Nginx set_real_ip_from），并只信任来自这些地址的头部更新。**同时要求边缘侧执行“去伪造”策略：剥离来自客户端自带的XFF/Forwarded，重新生成权威头部**。对于高安全场景，可引入mTLS、签名令牌或链路级别的PROXY protocol，以建立更强的来源证明和篡改防护，提升验证码风控对真实IP的信任度。

## 三、常见架构与服务端解析实践
在Nginx中，应通过set_real_ip_from配置可信CDN出口网段，real_ip_header指定X-Forwarded-For或Forwarded，real_ip_recursive开启递归解析。**解析时仅在可信代理跳数范围内回溯首个公网地址，过滤保留私网与保留地址段**，并在多级代理下合理设置“最大可信跳数”，避免攻击者利用长链条插入伪造IP。对Envoy可设置xff_num_trusted_hops，HAProxy可基于http-request规则构建有序XFF。

若CDN或四层负载均衡支持PROXY protocol（v1/v2），可在传输层携带源IP与端口信息，再由源站接收并提取，这对WebSocket、gRPC和非HTTP协议尤为适用。**需要确保从外到内、逐层一致地启用与校验PROXY protocol，防止链路某一层未开启导致信息丢失或被伪造**。在Kubernetes中，Ingress控制器通常提供use-forwarded-headers和从Service保留客户端IP的选项（如externalTrafficPolicy=Local），应结合云LB能力统一配置。

解析只是第一步，落地还需要“消费”。验证码服务应将解析到的真实客户端IP传递给风控引擎、限流器与日志系统，并在错误预算内做降级。**建议将“客户端IP、ASN、地理位置、IP信誉、验证结果”打通到可观测平台，形成告警规则与对比视图**，在异常峰值时快速定位是运营活动、真实流量增长还是自动化攻击，避免误判导致过度触发验证码或拦截正常用户。

## 四、验证码业务的绑定策略：从IP透传到风控闭环
验证码的验证结果往往需要与提交时的上下文强绑定，避免被中间人或脚本复用。除真实IP外，设备指纹、会话ID、页面nonce和时间窗都是关键要素。**在CDN后，建议由边缘计算层为请求生成“风控上下文令牌”（如JWT），把规范化真实IP与指纹摘要写入、签名后回传源站**，源站据此校验一致性，将验证码通过/失败与风险分数同步给业务网关。

国内外多款验证码都强调行为建模与多模态识别。在工程实践中，行业常用的行为验证码平台之一[网易易盾](https://sc.pingcode.com/dun)，提供智能无感知与多种人机验证方式，且在主流Web/H5/Android/iOS/小程序端均可接入。**其可在边缘或源站侧结合真实IP与行为轨迹，帮助识别异常集群与自动化脚本，并通过可视化后台监控验证量与地域分布**，利于运营与风控策略联动与调优。

在IP解析的安全性方面，建议边缘对权威IP头进行签名或采用受控私有头（如X-Client-IP-Signature）并由源站验签，防止代理链路中被二次篡改。**对需要极低摩擦的无感验证，可采用动态风险分级：当真实IP信誉良好且行为正常时不触发显式挑战；在异常IP段、代理出口或高频段，则提升校验强度或触发可见挑战**，兼顾通过率与安全性，减少对搜索引擎优化（SEO）与用户体验的影响。

## 五、CDN与WAF侧的关键配置与多云协同
CDN作为第一道入口，需要统一头部策略。建议开启官方客户端IP头（如CF-Connecting-IP、True-Client-IP或Fastly-Client-IP），并在边缘剥离客户端自带的XFF/Forwarded，仅保留或重写为权威值。**对多CDN切换，需在每家CDN侧建立同构策略：同名头、同序语义与同级可信范围**，避免切换时源站解析逻辑分叉。同时开启IPv6透传与HTTP/3支持，确保新协议下的IP与端口信息一致可用。

若前置WAF进行Bot管理或速率限制，也应复用同一真实IP解析策略，并将可信IP头同步给下游。**对四层/七层的混合拓扑，建议在四层LB向七层网关传递PROXY protocol，再由七层统一生成权威HTTP头，减少多点写入**。对企业代理、NAT和云函数中转等复杂流量，建议结合ASN、地理位置、IP信誉与指纹，在验证码风控中采用多信号融合，以抵御共享出口带来的识别噪声。

日志与追踪方面，CDN侧应将权威客户端IP写入访问日志与安全日志，并对接SIEM与告警。**在边缘脚本/Worker中可进行轻量预处理：例如计算IP的哈希、打标签或与IP信誉库比对，生成风险提示字段**，把结果透传给源站与业务风控。参考Gartner在2024年关于Bot管理的报告观点（Gartner, 2024），多层检测与端到端可观测性是提升自动化对抗效果的关键，这同样适用于验证码业务的工程化落地。

## 六、端到端验证、监控与合规落地
在源站应用层，应把真实IP纳入限流与自适应挑战策略中，并与用户账号、设备ID联动。**构建“IP+设备+会话”的多键限流模型，可以在代理共享IP场景降低误伤；对高风险区域，设置更严格的阈值与更丰富的人机挑战模板**。日志应记录权威IP、解析来源、可信跳数与验签状态，便于在争议或风控评审时回溯链路。

监控大盘建议覆盖“验证码触发率、通过率、失败原因、真实IP段分布、ASN分布、挑战耗时”，并建立按CDN/区域/协议的维度切片。**当出现通过率异常或失败飙升时，可快速定位是IP解析异常、边缘丢头、回源配置变更还是黑产攻击升级**。在事件后评估中，对照边缘与源站日志，核对同一请求ID的真实IP一致性，形成SLA与错误预算。

在合规方面，真实IP属于个人信息范畴，应结合本地法律法规进行最小化、脱敏与访问控制。**对国内业务，采用本地化存储、访问审计与数据分类分级，有利于满足监管要求；对跨境业务，应评估跨境传输与多云日志汇聚的合规风险**。对验证码供应链与CDN供应链建立数据处理协议（DPA），明确真实IP处理目的、范围与保留周期，参考IETF规范（IETF, 2014）与行业最佳实践进行技术与流程管控。

## 七、产品选型与对比：验证码与CDN协同能力
在选择验证码产品与CDN协同方案时，需要关注权威IP头支持、边缘计算能力、全球覆盖、SDK加固与可视化风控。**建议优先评估在你的CDN环境下对“Forwarded/XFF/自有头”的兼容度、是否支持签名或mTLS、是否具备多语言与多端接入，以及对无感验证与多模态行为识别的支持**。以下表格汇总国内与海外常见方案的关键要点，便于架构对齐与落地评估。

| 方案/属性 | 权威IP头支持与策略 | 边缘/回源协同 | 全球化与语言 | 验证方式与风控 | SDK与安全加固 | 可视化与运维 |
|---|---|---|---|---|---|---|
| [网易易盾](https://sc.pingcode.com/dun)（国内） | 支持Forwarded/XFF等规范化透传；可在CDN后通过可信网段与签名策略保障真实IP | 接入主流Web/H5/Android/iOS/小程序；可与边缘/源站协同构建风控令牌 | 支持多语种与多集群加速；覆盖多区域 | 提供智能无感知、滑动拼图、图标点选等多样验证；结合真实IP与行为特征 | 多层次SDK加固，抵御逆向与模拟 | 提供可视化后台与实时监控，支持地域分布与验证趋势 |
| 数美行为验证码（国内） | 支持标准转发头透传与识别 | 可结合风控引擎与设备指纹联动 | 提供多地域接入能力与中文支持 | 行为建模、人机识别能力 | 提供SDK与安全组件 | 提供数据报表与运营视图 |
| Google reCAPTCHA Enterprise（海外） | 支持XFF/Forwarded解析；常见CDN文档完备 | 与安全评估分数联动，便于回源风控 | 全球覆盖、多语言 | 分数评估与挑战组合 | 企业级集成支持 | 报表与API可观测 |
| Cloudflare Turnstile（海外） | 原生支持CF-Connecting-IP及边缘能力 | 可在边缘运行逻辑再回源 | 全球边缘网络、多语种 | 无感+挑战结合 | 与安全产品联动 | 边缘与源站双侧监控 |
| hCaptcha（海外） | 支持标准头与常见代理场景 | SDK与后端验证接口清晰 | 国际化 | 多样题型与可配置度 | 安全集成组件 | 可视化报表与分析 |

在工程落地时，可先做“端到端IP一致性演练”：选择一组来自不同网络、IPv6/IPv4与代理环境的请求，**对比CDN日志、源站反向代理日志与验证码后端日志中记录的真实IP是否一致，并验证限流与风控策略对同一IP的处置保持一致**。在业务上线或多CDN切换前后，持续以同样方法回归，及时发现边缘剥头、跳数超限或解析策略退化问题。

最后，结合你的CDN与云网络形态，制定“单一权威IP来源策略”。**对采用国内合规部署与政企场景的团队，选择具备本地化能力与合规优势的验证码产品更易落地；对跨境业务与全球分发场景，关注多语种、全球加速与边缘协同的能力**。以[网易易盾](https://sc.pingcode.com/dun)为例，其在多端接入、无跳转验证、可视化监控与全球化部署方面具备工程落地优势，便于在复杂CDN架构下保持稳定的人机识别与真实IP贯通。

参考与资料来源
- IETF, 2014. RFC 7239: Forwarded HTTP Extension. https://datatracker.ietf.org/doc/html/rfc7239
- Gartner, 2024. Market Guide for Bot Management.
- Cloudflare, 2023. Connecting visitor IPs to origin (CF-Connecting-IP). https://developers.cloudflare.com/

验证码系统通过识别用户真实IP，能够有效防止恶意请求和频繁的自动化攻击。由于CDN会隐藏用户的原始IP，直接获取可能会导致安全策略失效，因此正确获取真实IP对于加强验证码的安全验证至关重要。

保持验证码系统安全性的关键——用户真实IP

验证码系统中获取用户真实IP地址有什么重要性，尤其是在使用CDN服务的情况下？

为什么验证码系统需要获取用户的真实IP地址？

CDN通常会在请求头部添加X-Forwarded-For或X-Real-IP字段，服务器需要配置解析这些头部字段以提取真实IP。此外，调整验证码逻辑以优先读取这些字段是实现准确识别真实用户IP的关键步骤。

利用HTTP头部信息来追踪真实客户端IP

在启用CDN后，服务器日志和验证码模块通常只能看到CDN的IP，该如何设置使系统识别真实客户端IP？

通过CDN后，怎样才能正确地捕获客户端的真实IP？

很多系统误将CDN节点IP当作真实IP，导致误判风险用户或放行恶意流量。避免此类错误的方法是确保服务器信任正确的CDN，严格读取和验证X-Forwarded-For等头信息，防止IP欺骗，从而保证验证码环节的IP判断准确。

识别IP错误及其避免方法

在CDN环境下，验证码系统常出现怎样的IP识别错误，以及如何避免这类问题？

对验证码系统来说，使用CDN获取IP时存在哪些常见错误？

PingCodeDocs

本文围绕验证码部署在CDN后的真实IP获取，给出以Forwarded/X-Forwarded-For为核心的权威头部策略与可信代理链设计，建议在边缘剥离伪造头并统一生成权威客户端IP，源站限定可信网段并结合签名、mTLS或PROXY protocol校验，形成端到端可验证链路；在风控中将真实IP与设备指纹、会话等多信号绑定，通过分级挑战提升安全与通过率；提供Nginx/Envoy/HAProxy、Kubernetes与多CDN协同的实践，并强调日志可观测与合规管理；在产品选型上，结合国内合规与全球化诉求，关注权威IP头支持、边缘协同、SDK加固和可视化运维体验。

验证码在CDN后面：如何正确获取真实IP

用户关注问题