介绍
Caddy 默认自动设置 下面请求头，不需要手动写：
HostX‑Forwarded‑ForX‑Forwarded‑ProtoX‑Forwarded‑Host
1. Host 请求头
HTTP协议里Host告诉后端：浏览器访问的域名/端口是什么。
场景
用户访问：https://demo.example.com/api/xxx
- 如果没有代理：后端收到
Host: demo.example.com - 如果没有透传Host，Caddy直接转发，后端会收到
Host:127.0.0.1:8080（后端真实监听地址），浏览器访问直接报错。
作用
- 后端做虚拟主机、多域名站点、重定向、cookie域、OAuth回调地址全都依赖原始Host。
- 很多Web框架、SpringBoot、Django、Vue后端、认证服务，会拿Host拼接回调URL。
2. X‑Forwarded‑For（简称 XFF）
记录真实客户端IP地址，格式：
X‑Forwarded‑For: 113.xx.xx.123, 192.168.1.100
- 最左边第一个IP = 原始访问用户公网IP
- 后面每一个是经过的代理/网关IP（多级代理会追加）
作用
- 后端日志打印真实访客IP；
- IP限流、IP黑名单、登录IP记录、风控；
- 如果没有这个头，后端拿到的连接IP永远是 Caddy本机IP（127.0.0.1），看不到真实用户。
3. X‑Forwarded‑Proto
告诉后端：用户浏览器过来是 http 还是 https。
值只有两种：http / https
默认情况
如果用户请求到 Caddy 是 HTTPS → X‑Forwarded‑Proto: https
如果用户请求到 Caddy 是 HTTP → X‑Forwarded‑Proto: http
典型场景
Caddy对外提供HTTPS，Caddy和后端之间走内网HTTP：
用户浏览器 →(HTTPS)→ Caddy →(HTTP)→ 后端服务
后端本身接收的是http连接，后端不知道外面是HTTPS。
作用
- 后端代码、框架判断当前访问是否HTTPS；
- 自动跳转http→https；
- 生成完整跳转URL；
- 安全Cookie的
Secure属性；
例：SpringBoot配置 server.forward‑headers‑strategy=native 就会读取这个头识别HTTPS。
如果没有这个头：后端以为全部请求都是HTTP，会把跳转地址生成http://xxx，浏览器访问就会跳成http不安全地址。
4. X‑Forwarded‑Host
携带浏览器原始请求的域名（和原始Host头内容一模一样）。
为什么有Host还要再来这个？
历史兼容产物。有些老旧框架、中间件不读标准Host，专门读X‑Forwarded‑Host获取对外域名。
作用
- 兼容老Java、PHP、旧应用；
- 在某些上游会重写
Host头的场景下，保留原始对外域名备份。
提示：绝大多数现代业务直接用Host就够，X‑Forwarded‑Host属于兜底兼容。
汇总对比表
| Header | 传递什么信息 | 后端典型用途 |
|---|---|---|
| Host | 用户访问的原始域名 | 回调、cookie、虚拟主机、重定向 |
| X‑Forwarded‑For | 用户真实客户端IP | 日志、IP风控、限流、登录记录 |
| X‑Forwarded‑Proto | 前端是http还是https | 判断HTTPS、URL跳转、Secure Cookie |
| X‑Forwarded‑Host | 原始域名备份 | 老旧框架兼容 |
和Nginx对比
Nginx必须手动写这一堆：
proxy_set_header Host $host;
proxy_set_header X‑Forwarded‑For $proxy_add_x_forwarded_for;
proxy_set_header X‑Forwarded‑Proto $scheme;
proxy_set_header X‑Forwarded‑Host $host;
Caddy reverse_proxy 默认等价上面全部配置，不用写。