接入 Cloudflare 后，日志里出现大量相同 IP，并不一定代表有人刷访问。源站可能记录的是代理节点，而非真正的访客。但修复方式也不是直接相信任意请求中的 CF-Connecting-IP：先确认谁有权提供这个地址，才是配置的关键。
RootGS 技术编辑 · 2026 年 9 月 16 日 · 以 Nginx 反向代理场景为例，适用于有服务器配置权限的维护人员
一、先区分三个地址
- 连接对端地址：与源站建立连接的直接一跳。在 CDN 场景中，经常是 Cloudflare 节点或内部负载均衡器。
- 请求头中的地址：代理转发的访客信息。它可能是正确数据，也可能被直连客户端伪造，取决于链路与验证方式。
- 应用认定的地址：Nginx 或框架经过可信代理规则处理后，用于日志、限流或审计的客户端地址。
一次正确配置，需要让第三个地址来自可信链路，而不是把第二个字段无条件复制过去。否则攻击者可以不断更换请求头中的地址，干扰访问统计、基于 IP 的限制和管理员审计。
二、Nginx 的两个关键设置
set_real_ip_from 指定允许提供替代客户端地址的可信来源；real_ip_header 指定从哪个请求头读取地址。只设置后者而不正确限定前者，不能形成完整信任边界。还应确认当前 Nginx 构建包含 realip 模块。
# 只读检查构建参数，查找 realip 模块
nginx -V 2>&1下面只是结构示例，故意使用文档专用地址，不能直接复制到生产环境。实际 Cloudflare 接入应从官方清单获取当前完整的 IPv4 与 IPv6 网段。
# 示例网段，不是 Cloudflare 的生产 IP 范围
set_real_ip_from 192.0.2.0/24;
real_ip_header CF-Connecting-IP;不要将可信来源配置为 0.0.0.0/0 或 ::/0。也不要从随机教程复制一份年代不明的网段列表后长期不更新。若启用了 Cloudflare 的 Pseudo IPv4 或请求头转换规则，应按实际设置核对 IPv6 地址被保存在什么字段，避免把兼容性地址当成原始 IPv6。
三、多层代理不能只照搬单层配置
如果实际链路是“Cloudflare → 负载均衡器 → Nginx”，Nginx 看见的直接对端是负载均衡器。需要确认中间层只接受经过授权的流量，并正确覆盖或传递相关请求头。简单把内网网段全部标记为可信，可能让同网段其他机器也获得伪造客户端地址的能力。
real_ip_recursive 会影响地址链的解析方式，但它不是“打开就更安全”的通用开关。单值头与 X-Forwarded-For 地址链应分别分析。框架、Web 服务器和负载均衡器也不应各自采用互相冲突的规则。
四、日志要能回答“谁、访问哪个域名、跳到哪里”
只有请求路径的公共日志，事后往往无法确定一次 301 是 HTTP 升级 HTTPS，还是裸域名跳转 www。建议在合适的日志作用域记录以下字段，同时避免写入完整 Cookie、认证头和可能包含令牌的查询参数。
| 字段 | 用途 |
|---|---|
$remote_addr | realip 模块处理后的地址，用于访客统计 |
$realip_remote_addr | 保留被替换前的连接对端，便于追溯代理链路 |
$host、$scheme | 辅助区分虚拟主机与源站所见协议 |
$uri、$status | 记录不含查询参数的路径和响应状态 |
$sent_http_location | 分析重定向目标；启用前应评估 URL 中的敏感参数 |
$time_iso8601 | 保留明确时区，便于跨系统对齐事件 |
注意：在代理回源使用另一种协议时，$scheme 代表源站接收到的协议，不一定等于访客浏览器所用协议。要还原完整外部请求，还需要经可信代理处理的协议信息，不能把未经核验的任意头直接当作事实。
五、用三组请求验收，而不是只看“IP 变了”
- 正常代理访问：从已知网络访问自己的测试页面，比较日志中的访客地址与连接对端，确认二者职责清楚。
- 不可信来源携带同名头：在已授权的测试环境模拟直连，并填写一个文档专用假地址。该假地址不应被系统认定为真实客户端。若源站策略本身禁止直连，连接被拒绝就是预期结果，不必为了测试开放公网源站。
- IPv4 与 IPv6：在具备对应网络条件的客户端分别访问，确认日志和规则都覆盖，不能只验收 IPv4。
修改前保存配置，执行 nginx -t 检查语法，通过后再按维护流程重载。随后查看错误日志、正常页面、管理登录与依赖 IP 的限制是否符合预期。发现异常时恢复上一版已验证配置，不要把“临时信任所有来源”当作修复方案。
六、真实 IP 不等于真实身份
正确记录 IP 是统计和诊断的基础，但 IP 可能共享、变化或经过代理。它不能替代用户认证，也不能单独证明请求来自搜索引擎。识别 Googlebot 时仍应结合官方 IP 范围或正反向 DNS；管理员权限则应依靠身份验证、授权与审计等独立机制。
