行业资讯 · 发布时间：
高流量清洗服务接入后真实客户端源地址透传验证，不能只看应用日志里有没有一个 IP 字段。清洗节点可能保留客户端源 IP，也可能以自身地址建立到源站的新连接，再通过代理协议或 HTTP 请求头传递原地址。选错方式，日志、访问控制和限速判断都可能指向清洗节点，而不是实际客户端。
先确认流量在哪一层转发
接入前先向服务提供方确认转发模式、支持的协议以及源站需要开放的端口。关键差异在于：源站收到的数据包，其网络层源地址是否仍是客户端地址；如果不是，原地址通过什么格式交付。
- 网络层或传输层透传：清洗后流量转发到源站时保留原始源 IP。源站通常可从连接的对端地址读取客户端地址，但需要正确配置路由和回程路径。若回包绕过清洗路径，可能出现连接不稳定或无法建立。
- 代理转发：清洗节点与源站建立新的连接，源站看到的对端地址是代理节点。HTTP 服务常用 X-Forwarded-For 等请求头传递原地址；其他 TCP 应用可在双方都支持时使用 PROXY protocol。它们是不同格式，不能仅靠在源站开启某个选项就互换。
还要分别核对 TCP、UDP 等实际承载协议。HTTP 请求头只适用于相应的 HTTP 请求，不能用来传递普通 UDP 数据的源地址。TLS 若在清洗节点终止，后端接收的通常是新建连接；若 TLS 透传，则应用层可能看不到清洗节点添加的 HTTP 请求头。具体行为取决于服务的转发设计。
按协议和后端能力选择方式
需要保留网络层源地址时
如果源站程序依赖操作系统提供的对端地址，且服务支持相应的透明转发方式，优先确认网络层透传及回程路由要求。接入方应核实源站是否能从清洗路径收到流量、响应是否沿预期路径返回，并检查中间的 NAT 或防火墙规则是否改写地址。其优势是应用通常无需解析额外字段；限制是网络路由和部署条件更严格。
使用代理头时
对于由反向代理或 Web 服务处理的 HTTP 流量，可使用可信的 X-Forwarded-For 等字段，但源站必须只信任指定的清洗节点或代理地址。若直接采信客户端自行提交的同名请求头，攻击者可能伪造来源。PROXY protocol 则需要转发端和接收端同时支持，并在正确的监听端口启用；未启用的后端可能把协议前缀当作业务数据，造成解析失败。
用可重复的步骤核验真实地址
- 记录接入前的基线：从一台可控外部网络发起请求，记录测试端的公网出口 IP、请求时间、目标协议和端口。避免仅用内网地址测试公网转发。
- 确认清洗服务的转发配置，并在源站核对监听端口、信任代理范围、代理协议设置及回程路由。改动配置后先用低风险测试流量验证。
- 同时查看网络层和应用层证据。可用 tcpdump 在源站网卡抓取测试连接，比较数据包源地址、服务访问日志中的对端地址，以及可信代理头或 PROXY protocol 解出的地址。
- 从至少两个不同出口重复请求，再进行一次不带代理头和一次携带伪造代理头的测试。检查源站是否只接受可信清洗节点提供的地址，并确认客户端提交的字段不会覆盖可信结果。
- 测试 TCP、UDP、TLS 等实际使用的协议，并观察连接建立、日志归属和响应路径。记录抓包时间、目标端口及配置版本，便于问题复现；测试结束后按需要移除临时抓包文件。
抓包中看到清洗节点地址，并不必然代表透传失败：代理模式本来就会建立新连接，此时应检查约定的代理字段及其解析结果。反过来，日志显示客户端 IP，也不能单独证明地址可信，仍需确认该值来自受信代理，而非未经校验的请求内容。
常见问题
问：为什么应用日志里全是清洗节点 IP？
答：可能使用了代理转发，但应用未配置解析代理头或 PROXY protocol；也可能该接入模式本身不传递原地址。先对照服务端配置和抓包结果。
问：设置 X-Forwarded-For 后就能准确识别客户端吗？
答：不能。只有在请求来自可信代理，并按约定解析可信字段时才可靠；外部客户端可能自行构造同名字段。
问：所有协议都能用 HTTP 请求头传地址吗？
答：不能。请求头属于 HTTP 层；普通 TCP 或 UDP 服务需要使用该服务支持的网络层透传或代理协议方案。
因此，高流量清洗服务接入后真实客户端源地址透传验证，应以实际协议、源站收到的连接信息和可信代理配置为依据。先选对透传方式，再用抓包与应用日志交叉核对，才能让访问控制、审计和故障排查使用可信的客户端地址。
