Go httputil.ReverseProxy 修改请求目标时如何保留原始 Host

用 Go 写反向代理时，最容易误判的一点是：请求已经被转发到正确的后端，并不代表后端收到的 Host 还是用户访问的域名。httputil.ProxyRequest.SetURL 会改写出站请求的目标，并默认让出站 Host 跟随目标主机。需要保留原始 Host 时，做法是先调用 SetURL，再显式写回 r.In.Host。

为什么 SetURL 后 Host 也跟着变了

先把现象拆成两层：r.Out.URL.Host 是传输目标，决定连接哪个服务；r.Out.Host 是发出的 HTTP Host 字段，常被后端用于虚拟主机、租户或路由判断。两者通常看起来相同，但用途并不相同。

SetURL 的便利之处正在这里：它一次完成 scheme、host、基础路径的目标改写，同时把出站 Host 改成目标 Host。因此目标地址是 internal.service:8080 时，后端看到的 Host 也可能变成这个内部地址，而不是客户端请求的 api.example.com。

Rewrite 中怎样保留原始 Host

最小写法如下。关键顺序不要反过来：先让 SetURL 完成目标路由，再覆盖 Out.Host。代码中的注释说明了每个字段的职责。

rewrite := func(r *httputil.ProxyRequest) {
    // 只改变出站请求的协议、主机和基础路径。
    r.SetURL(target)

    // 保留客户端访问代理时使用的原始 Host，供后端虚拟主机路由使用。
    r.Out.Host = r.In.Host
}

如果直接先写 r.Out.Host = r.In.Host，随后再调用 SetURL，前面的赋值会被 SetURL 的默认行为覆盖。这个顺序问题也是“明明设置了 Host 但后端仍看到内部域名”的常见原因。

Host、X-Forwarded-Host 和目标地址怎么分工

需要把三类信息分别记录，排查时才不会把“请求发到哪里”和“请求代表谁”混为一谈：

若还要补全常见代理头，可以在 Rewrite 中调用 r.SetXForwarded()。它会设置 X-Forwarded-For、X-Forwarded-Host 和 X-Forwarded-Proto，但它不会把 Host 自动改回原始值；保留 Host 仍要单独赋值。

路径、TLS 和安全边界要再检查一次

这个修复只解决 Host 字段语义，不会自动解决所有代理问题。使用 SetURL 时，目标基础路径可能和入站路径拼接；如果不想拼接，应按官方语义直接设置 r.Out.URL。另外，HTTPS 的证书校验和连接目标依赖 URL 与 Transport，保留 Host 不等于修改 TLS 的 SNI。

最后要确认原始 Host 是否可信。若它来自公网请求，就不要把它无条件用于内部授权、回调地址或日志拼接；可以先按允许域名校验，再写入 r.Out.Host。Rewrite 不应修改 r.In，也不要在回调返回后继续使用这个 ProxyRequest。

常见问题

只设置 X-Forwarded-Host 可以吗？

可以作为代理链记录，但不能替代后端需要的 Host。后端代码必须读取哪个字段，应由你的路由和信任边界明确决定。

为什么后端路由仍然不匹配？

先检查是否把 Out.Host 写在 SetURL 前面，再确认后端实际读取的是 Host 还是 X-Forwarded-Host，最后检查目标服务是否要求特定端口。

什么时候不应该保留原始 Host？

当后端只接受内部域名、TLS/网关策略要求目标 Host，或外部 Host 未经过白名单校验时，不要为了“看起来一致”强行保留。

记住一个判断顺序即可：先决定请求要连接的 URL，再决定后端要识别的 Host，最后按信任边界补充转发头。这样修改 ReverseProxy 时，路由目标与请求身份就不会互相覆盖。