当请求经过CDN、边缘Nginx、API网关，再进入源站Nginx时，客户端地址通常藏在转发头中。攻击者若先塞入伪造的X-Forwarded-For，源站再取最左侧地址，风控会按假地址限流，审计也会记录错误来源。只看到“代理后没有直连IP”并不够，关键是明确每一跳谁有权写入地址，以及应用最终采用了哪个字段。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：blurpath（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先划清代理链信任边界
Nginx最初收到的真实客户端地址只是当前TCP连接的对端地址。CDN接入后，这个对端是CDN节点；进入源站后，对端又变成网关或上游Nginx。X-Forwarded-For、X-Real-IP等头没有天然可信度，客户端可以在进入可信代理之前任意构造。因此，应把代理链信任边界限定为明确列入白名单的代理节点及出口网段，而不是把全部来源地址视为可信。
若使用Nginx的realip模块还原地址，set_real_ip_from只能列出真正承担转发职责的CDN出口或代理网段。把范围写成任意地址，虽然能让模块读取转发头，却也会把外部请求者纳入信任范围，伪造随即生效。边界还要结合转发头的生成规则判断：CDN覆盖旧头、保留旧头并追加当前地址，产生的可信度完全不同；若CDN原样透传客户端提交的头，源站无法仅凭该头区分伪造值和正常值。
沿地址写入链做可验证判断
排查时先列出请求经过的每一层，以及每层看到的直接对端。随后在首个可信入口清理外部携带的转发头，再由受控代理按固定顺序重建。Nginx可通过Nginx地址重写读取指定头，并从右向左寻找第一个不在可信代理范围内的地址；这一过程依赖可信代理列表，而不是依赖地址数量。配置时应核对real_ip_header、real_ip_recursive和上游写入顺序，避免在多级链路中重复信任同一个头。
验证不能只看正常访问。可分别模拟正常CDN链路、客户端伪造左侧地址、未受信任节点插入地址，以及绕过CDN直连源站，并逐层记录直接对端、规范化客户端地址和原始转发头。最终日志应把重写后的日志审计一致性作为基准：统一记录重写后的真实客户端地址，另存直接对端和原始头供追溯，应用、限流与风控也应使用同一规范化结果。若只记录原始X-Forwarded-For，或有的节点取左端、有的节点取右端，即使地址重写正确，审计链路仍会互相矛盾。
按代理链逐跳确定可信地址
真实客户端地址不能简单取 X-Forwarded-For 的首项，也不能无条件相信 X-Real-IP。应先列出代理拓扑和每跳职责，再从入口边缘开始，只信任明确属于己方的代理节点。边缘层覆盖客户端传入的转发头，内部代理按约定追加链路；应用服务不得直接接受公网请求携带的同名头。这样，代理链信任边界 才不会被伪造头扩展。
常见坑是使用过宽的 set_real_ip_from，或多个代理同时覆盖、追加同一字段。修改 Nginx地址重写 前，要确认 remote_addr、proxy_add_x_forwarded_for 和最终记录变量分别代表哪一跳；可开启 real_ip_recursive，但必须与实际链路顺序一致。IPv4、IPv6、CDN及云负载均衡的出口地址应分别核对，不能照搬旧网段。
让访问日志与审计结论一致
地址识别完成后，还要保证入口日志、认证审计、限流、WAF和应用日志采用同一判定结果。建议在入口统一输出可信客户端地址、连接来源地址与请求ID，保留必要的代理链信息供追溯；出现地址冲突或来自非可信节点的转发头时，单独记录安全事件。审计规则应直接引用规范字段，避免登录日志使用一个IP、风控日志又取另一个IP。
可执行检查清单：
- 列出完整代理拓扑，确认每跳出口IP、负责人及允许修改的转发头。
- 仅信任已核实的代理网段，清除“信任所有来源”的错误配置。
- 在边缘层删除客户端伪造头，再由各级代理按统一规则覆盖或追加。
- 核对Nginx重写变量、日志格式及真实地址模块的递归顺序。
- 用直连、伪造头、多级代理、IPv4/IPv6和链路异常场景回归测试。
- 抽查访问日志、认证审计与告警记录，确认客户端IP、请求ID和时间线一致。
上线后应定期复核代理节点和出口网段变更，并把地址判定逻辑纳入配置审计。只有当信任范围可控、转发头来源可证、日志结论一致时，记录下来的客户端地址才可用于日志审计一致性和安全决策。
喜欢 
顶
难过
囧
围观
无聊
