线上链路常见为CDN→负载均衡→Nginx→应用。此时Nginx日志里的remote_addr可能只是内网代理地址，X-Forwarded-For又混有访客自填值与上游追加值。登录审计可能把代理当客户，风控也会重复计算访客；攻击者轮换伪造头后，同一请求便出现多个“来源IP”。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：iprocket（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
Nginx最初只能从TCP连接取得直连对端。代理收到请求后，通常把刚看到的来源地址追加到X-Forwarded-For末尾，所以该字段是一串路径，不是单个可信结论。访客若预先发送X-Forwarded-For: 1.1.1.1，边缘代理继续追加后，左侧仍是访客可控的伪造值。
Forwarded头依据RFC 7239，以for参数表示来源。它更规范，却不自动更可信：规范只定义表达方式，不验证发送者。若CDN覆盖X-Forwarded-For，链路可能只剩一个地址；若两套头并存，要先厘清各层代理的清洗规则，不能看到for就优先采用，也不能盲取XFF最左值。
可信代理边界应由Nginx直连的对端地址定义，例如负载均衡固定节点或受控网段，并配合real_ip_header、set_real_ip_from与real_ip_recursive。收到请求后，先确认TCP对端在信任列表，再从服务端一侧向左解析，跳过已声明的CDN出口和负载均衡节点，取第一个合法且不可信的IP作为访客候选。边界外的头无权改写remote_addr；内部节点还应丢弃客户端传入的同名头再追加。
落地时只信任明确地址或专用CIDR，不要放开0.0.0.0/0、整个云厂商网段或任意共享出口。Forwarded解析器要区分带引号IPv6、端口和obfuscated标识；无法得到真实IP时应拒绝该字段，异常格式更不能猜测。日志应同时保存直连对端、可信代理、原始头、最终IP和校验结果，失败时回退到直连对端并告警。联调可用ServLlama观察出口及代理链的地址表现，但生产规则仍以实际配置为准。
在只信任明确配置的代理节点后，不能把 X-Forwarded-For 首项直接当作客户端 IP。典型链路里，每级代理通常把看到的上一跳追加到末尾，最左侧因而最容易被伪造。可靠做法是从连接对端开始，沿 X-Forwarded-For 从右向左回溯：确认 TCP 对端属于可信代理后，逐项移除可信代理地址，首个非可信地址才是候选来源 IP。CDN、负载均衡器和网关职责不同，剥离层数必须按真实拓扑定义，不能把“私网地址”整体视为可信。Forwarded 头按 RFC 7239 表达，例如 for=192.0.2.1，其值还可能是带端口的 IPv6、unknown 或混淆标识，多个代理元素以逗号分隔。它与 X-Forwarded-For 并存时，应固定优先级和冲突策略，并用合规语法解析，不能粗暴拼接两份头。
来源 IP 防伪造的关键是封住绕过路径。业务端口应禁止公网直连，只允许 CDN、入口负载均衡器或固定网段访问；来自非可信对端的 X-Forwarded-For、Forwarded 一律丢弃，由入口重写的头才可读取。多层代理还要校验链路长度及每一跳是否落在可信 CIDR 内，并统一 IPv4 映射 IPv6、端口和 IPv6 zone id 的表示。常见坑包括：仅取首项，让攻击者任意指定 IP；信任全部私网，让内网攻击者伪造；CDN 返回多值却未声明格式；代理网段已变更但旧规则仍在；日志、限流和风控采用不同算法；把原始头纳入缓存键造成用户串号。
上线前检查清单：①画出真实代理拓扑，标明每跳新增或重写哪个头；②用 CIDR 白名单锁定可信代理，并阻断业务服务直连；③确定唯一来源 IP 算法、头部优先级、异常处理和最大跳数；④补充自动化用例，覆盖直连伪造、可信代理追加、恶意多值、IPv6、缺失及畸形头；⑤日志同时记录原始头、连接对端和最终判定值，对冲突及超长链路告警；⑥定期复核代理网段、CDN 配置和解析规则。这样才能让结果既可追溯，又不受请求头中的任意字符串左右。
