高防代理透传访客真实IP的配置与隐私边界，关键不只是让后端“看见”一个地址，还要确认地址由谁提供、后端信任哪些代理，以及日志保存多久。配置得当，运维人员能区分访客来源并排查异常；信任链设置错误，则可能让客户端伪造地址，或使个人信息被不必要地记录。
先分清两种透传方式
常见的七层代理会通过请求头传递源地址，例如 X-Forwarded-For 或 X-Real-IP。它适用于代理能够解析并转发应用请求的场景。要注意，请求头本身可以由访客提交；后端不能看到一个地址就直接认定它真实，必须只接受指定代理写入或整理后的字段。
四层转发可使用 PROXY protocol，在连接层附带来源信息。它适合代理与后端都支持该协议的场景，但后端监听端口必须按协议配置。若普通连接误发到该端口，可能无法正常处理，因此需隔离端口并限制来源。
签约和上线前比较五项成本
- 流量与请求计费：核对计费按带宽峰值、流量、连接数还是请求量计算。高峰明显但持续时间短的业务，与流量均匀的业务，适合的计费方式可能不同；确认是否另计回源流量。
- 地址与协议兼容：确认代理出口地址是否固定、变更如何通知，以及产品是否支持所需的请求头或 PROXY protocol。出口地址经常变化，会增加信任列表维护成本。
- 日志范围与留存：问清代理和源站分别记录哪些字段、保存期限、可访问角色及删除方式。真实源地址具有识别和关联个人活动的风险，不应因排障方便而无限期留存。
- 接入与迁移成本：评估源站是否要改监听端口、应用是否读取代理头、测试和回滚需要多少操作。仅需应用层识别地址时，使用受信代理头通常改动较少；需要连接层传递时，协议适配和端口隔离要求更高。
- 防护与运维边界：检查源站能否限制为仅代理地址访问，并确认代理故障、地址变更和规则误配时的告警及回退办法。若源站仍可被公网直接访问，访客可能绕过代理，透传链也更难核验。
按顺序配置并验证
- 从代理服务配置中取得官方提供的出口地址范围及透传协议说明；不要自行猜测地址，也不要把所有来源都设为可信。
- 选择一种与代理实际能力一致的方式。七层接入时，后端只信任指定代理发来的源地址头；若使用 Nginx，可通过 set_real_ip_from 指定可信代理，并按代理实际发送的字段设置 real_ip_header。四层接入则按其文档启用 PROXY protocol，并让监听端口仅接受代理连接。
- 在网络层限制源站入口，只允许代理出口访问相应服务端口。同步检查应用、反向代理和审计日志使用的是恢复后的访客地址，还是代理连接地址，避免字段含义混淆。
- 从代理入口和受控测试环境分别发起请求，核对后端记录的地址；再尝试提交伪造的 X-Forwarded-For 值，确认它不会被当作可信来源。测试通过后再切换正式流量，并保留回滚路径。
把隐私边界写进配置管理
高防代理透传访客真实IP的配置与隐私边界应同时落实在技术和管理上：只向确有排障、风控或访问控制需要的系统开放地址字段；日志按目的设置访问权限和保留期限；不把完整地址复制到无关分析数据中。具体留存时间应结合业务目的、适用规则和内部制度确定，不能用一个通用天数替代评估。
上线验收至少记录三件事：可信代理地址范围、真实地址取值字段、日志保存与访问规则。代理地址变化、配置更新或业务用途改变时，复核这三项。这样既能保持地址链路可验证，也能减少源站暴露和不必要的数据留存。
常见问题
访客自己带了 X-Forwarded-For，后端还能信吗？
不能仅凭字段名称信任。应由可信代理清理、覆盖或按约定整理该字段，后端只接受来自可信代理连接的数据。
七层请求头和 PROXY protocol 可以同时启用吗？
技术上取决于代理与后端实现，但一般应先确认产品的传递规则，避免地址来源不一致。没有明确需求时，选一种并完成端到端验证更易排错。
源站需要公开访问吗？
如果服务设计允许，应限制源站仅接受代理出口连接。否则访客可能绕过代理直连，防护与地址识别都可能出现缺口。
真实IP日志要保存多久？
按排障或业务目的、适用要求和内部制度确定，并限制访问及定期清理；不应默认永久保存。