HTTP 代理场景下 X-Forwarded-For、X-Real-IP 和 Forwarded 有什么作用？
简化版
在反向代理、网关、负载均衡之后，后端服务看到的直接客户端往往是代理服务器，而不是真实用户。
X-Forwarded-For、X-Real-IP 和标准化的 Forwarded 头用于传递原始客户端 IP、协议、Host 等信息，帮助后端做日志、限流、鉴权、生成回调链接。
但这些头可以被客户端伪造，后端必须只信任可信代理写入或清洗后的值。
详细版
常见请求链路：
Client -> CDN -> Nginx -> App应用层看到的 TCP 对端可能是 Nginx IP。
代理会补充：
X-Forwarded-For: 203.0.113.10, 10.0.0.2
X-Real-IP: 203.0.113.10
X-Forwarded-Proto: https
X-Forwarded-Host: www.example.comX-Forwarded-For 通常是一个 IP 链，越靠左越接近原始客户端。
Forwarded 是 RFC 标准头，例如：
Forwarded: for=203.0.113.10;proto=https;host=www.example.com使用这些头时要配可信代理列表，否则攻击者可以自己构造头绕过 IP 白名单或限流。
完整版教学
1. 先讲清楚为什么后端拿不到真实 IP
现代 Web 架构里，请求很少直接从浏览器打到应用进程。
常见路径是：
用户 -> CDN -> WAF -> 负载均衡 -> Nginx -> 应用应用进程从 socket 里看到的对端 IP，通常是上一跳代理。
如果业务需要记录用户 IP、按 IP 限流、判断协议是 HTTPS 还是 HTTP，就需要代理把原始信息放进 HTTP 头。
代理头解决的是“经过多层代理后，后端如何知道原始请求信息”的问题。
2. X-Forwarded-For 的语义
X-Forwarded-For 常用于记录客户端和代理链路。
示例：
X-Forwarded-For: 198.51.100.7, 10.0.0.8, 10.0.1.9通常理解为：
198.51.100.7是更接近用户的 IP。10.0.0.8是中间代理。10.0.1.9是更靠近应用的代理。
但不同代理追加规则可能不同，不能脱离网关配置盲目解析。
3. X-Real-IP、Proto、Host 的作用
X-Real-IP 通常只放一个 IP，配置简单。
X-Forwarded-Proto 表示原始请求协议：
X-Forwarded-Proto: https它常影响应用生成绝对 URL、重定向地址、Cookie Secure 判断。
X-Forwarded-Host 表示用户访问的原始 Host。
这些头在服务经过反向代理、TLS 在网关终止时非常常见。
4. Forwarded 是标准化方案
Forwarded 是更标准的头，能统一表达多个代理相关信息。
Forwarded: for=198.51.100.7;proto=https;host=example.com对比表：
| 请求头 | 是否事实标准 | 主要用途 | 示例 |
|---|---|---|---|
| X-Forwarded-For | 常见非标准 | 传客户端和代理 IP 链 | 1.1.1.1, 2.2.2.2 |
| X-Real-IP | 常见非标准 | 传一个真实 IP | 1.1.1.1 |
| X-Forwarded-Proto | 常见非标准 | 传原始协议 | https |
| Forwarded | 标准头 | 统一表达 for/proto/host | for=1.1.1.1;proto=https |
实际工程中 X-Forwarded-* 使用更广。
5. 最大风险是伪造
客户端可以自己带这些头：
X-Forwarded-For: 127.0.0.1如果应用无条件信任，就可能把攻击者识别成内网或白名单用户。
正确做法是：
- 边界代理先清洗外部传入的相关头。
- 只由可信代理重新写入。
- 应用配置可信代理 IP 段。
- 从可信链路中提取真实客户端 IP。
这也是很多框架要配置 trusted proxies 的原因。
6. 典型业务使用点
代理头常用于：
- 访问日志记录真实来源。
- IP 限流和风控。
- 地域判断。
- 生成 HTTPS 回调地址。
- 判断是否需要重定向到 HTTPS。
- 多租户根据 Host 选择站点。
如果这些头解析错，可能造成日志污染、限流绕过、跳转错误、Cookie 安全属性错误。
7. 常见误区与追问
- 误区：X-Forwarded-For 的第一个 IP 永远可信。 如果边界代理不清洗，客户端可以伪造第一个 IP。
- 误区：X-Real-IP 和 X-Forwarded-For 完全等价。 前者通常是单 IP，后者可以表达代理链。
- 误区：应用直接拿请求头做鉴权没问题。 安全决策必须建立在可信代理配置上。
- 追问：为什么 HTTPS 站点后端看到的是 http？ TLS 可能在负载均衡终止，后端连接是内网 HTTP，需要
X-Forwarded-Proto。 - 追问：Forwarded 为什么没有完全替代 X-Forwarded-For？ 历史兼容和代理生态导致非标准头仍然更常见。
- 追问：Nginx 应该怎么处理外部伪造头？ 边界层应覆盖或清洗相关头，只传递可信值。
8. 加强记忆
代理头的口诀是：上一跳看 socket，原始信息看代理头，安全前提看可信代理。
面试里把“作用”和“不可盲信”同时说出来，答案就稳。