接入清洗网络后，源站看到的连接地址往往是清洗节点或代理的地址。要解决“网站接入清洗网络后如何保留访客真实源IP”，关键不是简单读取一个请求头，而是确认流量怎样转发，并且只信任指定的上游设备。否则访客地址可能丢失，也可能被伪造。
先确认清洗网络怎样把请求送到源站
清洗服务常见的转发方式包括反向代理、四层转发和隧道转发。反向代理通常通过 HTTP 请求头传递访客地址；四层设备可能使用 PROXY protocol；部分网络方案则保留原始数据包的源地址。三者所需配置不同，不能只凭“已接入清洗”判断源 IP 会自动保留。
先向服务商确认：转发模式是什么、访客地址放在哪个字段或协议中、源站实际连接来自哪些地址段，以及是否支持 TCP、UDP 等非 HTTP 流量。对 HTTP 网站，常见字段包括 X-Forwarded-For；Cloudflare 代理场景还可使用 CF-Connecting-IP，但具体应以实际链路和服务配置为准。
从入口到日志核对的5项配置
1. 确认并启用正确的转发方式
如果上游发送 PROXY protocol，清洗端和源站监听端都必须启用并匹配版本。只有一端开启，连接就可能失败或被错误解析。若走反向代理，则确认上游确实写入约定的客户端地址字段，而非仅转发未经验证的请求头。
2. 只把可信代理设为地址来源
在 Nginx 等 Web 服务中，配置真实地址解析模块的信任范围，并将 real_ip_header 指向上游实际使用的字段。可信范围应填写清洗节点或负载均衡器的官方地址段，并在地址段变更后及时维护。不要把所有来源都设为可信；否则客户端可自行提交 X-Forwarded-For，伪装成任意地址。
3. 检查应用读取的字段和代理层级
Web 服务器改写了客户端地址，不代表应用、访问日志和限流模块一定使用同一个值。逐项检查框架的代理信任设置、日志格式、审计记录以及按 IP 限制访问的规则。X-Forwarded-For 可能包含多个地址，通常由多个代理依次追加；应用必须按已知代理链解析，不能不加判断地取第一个或最后一个。
4. 用源站防火墙限制直连
如果源站仍接受任意公网连接，攻击者可能绕过清洗入口，直接访问源站并伪造转发头。可在防火墙或云网络访问控制中，只允许清洗网络的出口地址访问网站端口；管理端口另行限制。启用前先确认健康检查、运维入口和其他合法回源也在允许范围内，避免误封造成服务中断。
5. 用请求和日志验证结果
- 记录调整前源站访问日志中的连接对端地址，以及应用识别的客户端地址。
- 从正常访客路径发起请求，核对连接对端是否为清洗节点、解析后的客户端地址是否符合预期。
- 再尝试直接访问源站，并发送自定义转发头；确认直连被拦截，或伪造字段不会被信任。
- 检查错误日志、限流和安全审计记录；分别验证网站实际启用的协议与入口。
若经过多层负载均衡，逐跳确认谁写入、谁追加、谁负责解析。修改后还要检查日志中的地址格式和时区等字段，避免把代理地址误认为访客地址。
常见故障与判断思路
- 所有请求都显示清洗节点地址：上游可能没有传递客户端地址，或源站未配置对应字段。
- 地址偶尔变化或出现代理链：请求经过多级代理，需核对各层的可信范围和解析顺序。
- 切换后请求报错：检查 PROXY protocol 是否两端一致，以及源站监听端口是否匹配。
- 日志地址正常但限流不准：检查应用是否仍读取原始连接地址，而不是可信代理解析后的地址。
常见问题
清洗网络一定能保留访客真实源IP吗？
不一定。取决于转发模式、服务配置和源站是否正确解析；应先确认服务商提供的地址传递方式。
可以直接信任 X-Forwarded-For 吗？
不可以无条件信任。只有请求来自已确认的代理时，才按代理链规则解析该字段。
只配置日志就够了吗？
不够。还要核验应用、限流和安全规则的取值，并限制源站直连，避免绕过清洗入口。
网站接入清洗网络后如何保留访客真实源IP，最先检查什么？
先确认清洗网络的转发模式、传递字段或协议及可信出口范围，再依次核对源站解析、防火墙和应用日志。这样才能让访客地址可用，同时避免信任伪造数据。