在Nginx配置中获取CDN真实IP的核心方案是：利用Nginx内置的ngx_http_realip_module模块，通过解析HTTP请求头（如X-Forwarded-For或自定义头部）来覆盖客户端IP，并配合set_real_ip_from指令信任CDN节点IP段。
当网站接入CDN后,后端服务器看到的源IP不再是访问者的真实IP，而是CDN边缘节点的IP，这导致日志分析、风控拦截、地理位置统计等功能失效，解决这一问题的关键在于让Nginx正确识别并信任CDN传递的原始IP信息。
为什么CDN会隐藏真实IP
CDN的工作原理是将用户请求调度到最近的边缘节点,对于源站而言，它只与CDN节点建立连接，这种架构天然地切断了源站与最终用户之间的直接IP联系，如果不做特殊处理，源站日志中记录的将是成千上万个CDN节点IP，而非全球各地的用户IP。
业内专家指出,这种IP隐藏机制是CDN架构的基础特性，旨在减轻源站负载并隐藏源站真实架构，对于需要精准用户画像的业务场景，如金融风控、广告归因或本地化服务，这种“盲区”是不可接受的，必须通过配置手段，将CDN节点透传的真实IP还原给业务系统。
Nginx配置获取真实IP的标准流程
要实现IP还原,需要在Nginx配置文件中完成模块加载、信任源设置和头部解析三个步骤，以下是具体的实操路径。
第一步：确认模块支持
大多数现代Nginx发行版默认编译了ngx_http_realip_module，你可以通过执行以下命令检查模块是否已安装：
nginx -V 2>&1 | grep -o with-http_realip_module
如果输出包含with-http_realip_module，则说明模块可用，若未安装，需重新编译Nginx并添加--with-http_realip_module参数。
第二步：信任CDN节点IP段
Nginx默认只信任本地回环地址（127.0.0.1），你需要明确告诉Nginx，哪些IP是可信的CDN节点，不同CDN厂商提供的IP段不同，需定期更新。
以阿里云CDN为例,配置示例如下：
set_real_ip_from 8.8.8.8; # 示例IP，实际需替换为CDN提供商提供的完整IP段 set_real_ip_from 1.1.1.1; real_ip_header X-Forwarded-For; real_ip_recursive on;
这里的关键指令是set_real_ip_from，它指定了信任的源IP地址。real_ip_header指定了从哪个HTTP头部获取真实IP。real_ip_recursive on表示递归解析，即从列表最右侧的非信任IP开始向左查找，直到遇到第一个信任IP为止。
第三步：处理自定义头部
部分CDN厂商为了区分流量或防止伪造,会使用自定义头部（如X-Real-IP或True-Client-IP），需将real_ip_header修改为对应的头部名称。
Cloudflare使用CF-Connecting-IP，配置如下：
set_real_ip_from 103.21.244.0/22; # Cloudflare IPv4 set_real_ip_from 103.22.200.0/22; real_ip_header CF-Connecting-IP;
常见CDN厂商配置差异对比
不同CDN厂商在IP透传机制上存在差异,配置时需特别注意，以下表格总结了主流厂商的配置要点。
| CDN厂商 | 推荐头部字段 | 配置建议 | 注意事项 |
|---|---|---|---|
| 阿里云/腾讯云 | X-Forwarded-For | 默认即可 | 需定期更新IP段 |
| Cloudflare | CF-Connecting-IP | 必须指定该头部 | 避免使用XFF，防止伪造 |
| 百度云加速 | X-Real-IP | 指定该头部 | 确保后端应用读取正确 |
| AWS CloudFront | X-Forwarded-For | 默认即可 | 需配置信任源 |
行业共识认为,使用CDN厂商专用的头部字段（如Cloudflare的CF-Connecting-IP）比通用的X-Forwarded-For更安全，因为后者容易被中间代理伪造。
如何防止IP伪造攻击
如果配置不当,攻击者可以通过修改HTTP请求头中的X-Forwarded-For字段伪造真实IP，攻击者可以发送请求头X-Forwarded-For: 192.168.1.1, 10.0.0.1，试图让Nginx认为请求来自内网IP。
为防止此类攻击,必须严格配置set_real_ip_from，只有来自CDN节点IP的请求才会被处理，任何来自非CDN节点且携带伪造头部的请求，Nginx将忽略该头部，保留客户端直连IP（如果存在）或记录为未知。
建议在Nginx前端增加WAF（Web应用防火墙）层，对非法头部进行清洗，拒绝包含X-Forwarded-For但源IP不在CDN段内的请求。
验证配置是否生效的方法
配置完成后,必须验证Nginx是否正确解析了真实IP，以下是几种验证方法。
查看Nginx访问日志
修改Nginx日志格式,将$remote_addr替换为$http_x_forwarded_for或自定义变量。
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
重启Nginx后,访问网站并查看日志，如果日志中显示的是用户真实IP而非CDN节点IP，则配置成功。
使用curl命令测试
通过curl模拟请求,观察响应头或日志输出。
curl -I -H "X-Forwarded-For: 1.2.3.4" http://your-domain.com
如果Nginx配置正确,日志中应记录2.3.4（前提是1.2.3.4在信任列表中，或通过递归解析得到）。
后端应用验证
在后端代码中打印请求的客户端IP,在PHP中查看
$_SERVER['HTTP_X_FORWARDED_FOR']或$_SERVER['REMOTE_ADDR']，确保后端应用读取的是Nginx解析后的IP，而非原始请求头。
常见问题与故障排查
Q&A：Nginx获取真实IP配置详解
Q1: 配置后日志IP仍未变化，可能是什么原因？
A1: 首先检查Nginx配置语法是否正确，执行nginx -t测试，确认CDN节点IP段是否已更新，CDN IP段可能随时间变化，检查Nginx是否重载了配置，执行nginx -s reload，如果仍无效，检查HTTP请求头是否被上游代理（如负载均衡器）修改或清除。
Q2: 是否应该同时信任多个CDN厂商的IP段？
A2: 如果网站同时使用多个CDN或CDN与WAF串联，需要将所有可信节点的IP段都加入set_real_ip_from，先经过Cloudflare，再经过Nginx，需信任Cloudflare IP段，若经过多层代理，需确保每一层都正确传递头部，并在最终Nginx实例中信任所有上游IP。
Q3: 获取真实IP会影响Nginx性能吗？
A3: 解析IP头部的开销极小，通常可以忽略不计，主要性能影响在于IP段的匹配过程，如果信任的IP段数量巨大（如数万条），建议使用CIDR表示法（如21.244.0/22）而非单个IP，以减少配置行数和处理时间，据工信部数据，现代Nginx在处理百万级并发时，IP解析模块的资源消耗低于1%。
总结与最佳实践
获取CDN真实IP并非一劳永逸的配置,而是一个需要持续维护的过程，CDN厂商会不定期更新IP段，管理员需建立定期更新机制，确保set_real_ip_from指令中的IP段保持最新。
安全与便利需平衡,过度信任非CDNIP可能导致安全漏洞，而配置过于复杂则增加运维成本，建议采用分层架构，在边缘层（CDN）完成初步清洗，在核心层（Nginx）进行最终确认。
通过正确配置Nginx的ngx_http_realip_module，企业不仅能恢复日志分析的准确性，还能提升风控系统的精准度，这一配置是构建现代化Web架构的基础环节，值得每一位运维人员深入掌握。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/nginx-cdn%e6%80%8e%e4%b9%88%e8%8e%b7%e5%8f%96%e7%9c%9f%e5%ae%9eip%ef%bc%9fcdn%e9%85%8d%e7%bd%ae%e8%8e%b7%e5%8f%96%e8%ae%bf%e5%ae%a2%e7%9c%9f%e5%ae%9eip/
