接入防护代理后，源站通常看到的是代理服务器的地址，而不是访问者的地址。要让日志、访问控制和应用程序识别客户端，需要确认代理传递了什么信息，并让源站只信任指定代理。网站接入防护代理后的真实客户端IP还原，不能只靠读取一个请求头；信任边界和代理链配置同样重要。
先弄清真实地址从哪里来
代理与源站建立连接时，源站网络层看到的对端地址属于代理。客户端地址一般由代理写入 HTTP 请求头，例如 X-Forwarded-For、X-Real-IP 或标准化的 Forwarded。不同代理的配置和转发方式可能不同，应以实际请求和代理文档为准。
若请求经过多层代理，X-Forwarded-For 可能包含多个地址，通常按请求经过的顺序排列。列表中的内容并非天然可信：客户端可能在请求中自行提交同名请求头。如果边缘代理不清理或覆盖这些输入，应用就可能读到伪造地址。
按顺序配置，避免信任错误
- 确认代理实际发送的头。在源站临时记录请求头与连接对端地址，观察真实请求；不要仅凭产品默认值推测头名称或排列顺序。
- 限制源站入口。尽量让源站只接受防护代理的连接。至少应在服务器防火墙或云网络规则中限制来源，避免外部用户绕过代理直接访问。
- 只信任代理地址范围。从代理服务的官方配置资料取得当前出口地址段，并维护更新。不要把所有来源地址都设为可信，否则攻击者可以直接伪造转发头。
- 配置 Web 服务器解析方式。Nginx 可使用 realip 模块相关指令，指定可信代理来源、真实地址头，并在多级可信代理场景评估是否启用递归解析。Apache 可通过 mod_remoteip 指定头名称及可信代理。具体指令应按安装版本和代理链核对。
- 验证日志和应用取值。从外部发起正常请求，对照代理日志、源站连接对端和 Web 访问日志。确认应用读取的是服务器解析后的客户端地址，而不是直接接受用户提交的请求头。
不同架构的处理重点
单层代理
只有一层代理时，通常由代理覆盖或规范化转发头，再由源站仅信任该代理。配置简单，但仍需确认代理请求头的行为，并阻止绕过代理直连源站。
多层代理
代理链较长时，应逐层确认哪些节点可控、哪些地址范围可信。服务器解析时从右侧处理可信链，遇到不可信来源便停止，才能避免把客户端伪造的左侧地址误认成真实地址。Nginx 的递归解析选项尤其需要结合链路结构测试，不能仅为“取最左侧”而开启。
常见误区与日志核对
- 直接读取请求头：应用若无条件采用 X-Forwarded-For，客户端就可能伪造来源地址。应先由 Web 服务器在可信代理范围内解析，再让应用使用解析结果。
- 只保留一个地址字段：排查问题时，建议同时记录解析后的客户端地址和底层连接对端。Nginx 可分别检查解析后的地址变量与原始连接地址变量；Apache 启用 mod_remoteip 后，也可在日志中区分客户端地址和连接对端。
- 忽略地址格式：IPv4 与 IPv6 都可能出现；日志、数据库字段和访问控制规则应能容纳两种格式。经过企业出口、移动网络或其他中间网络时，观察到的地址也可能是共享出口地址，并不一定对应个人设备。
因此，网站接入防护代理后的真实客户端IP还原，核心不是寻找一个“万能请求头”，而是核实头的来源、限定可信代理，并通过日志验证解析结果。完成配置后，还应检查代理地址段变更、源站直连路径和应用取值方式，避免安全规则建立在伪造地址上。
常见问题
只配置 X-Real-IP 可以吗？
可以，但前提是代理确实写入该头，且源站只接受可信代理的连接。多层代理场景还需确认它表示哪一跳的地址。
为什么日志里的地址仍然是代理地址？
可能是代理没有发送预期请求头、Web 服务器未启用对应模块，或可信代理范围未配置正确。逐项检查请求头、源站连接来源和解析设置。
修改请求头后，应用还要改吗？
视架构而定。如果应用框架读取 Web 服务器提供的客户端地址，通常应先确认框架的代理信任设置；不要让应用信任来自任意来源的转发头。