Go http.Request.WriteProxy 为什么代理请求需要完整 URL

我第一次排查 Go 的 HTTP 代理请求时，最容易困惑的是：同一个 http.Request，为什么直连写出时请求行像 GET /api/items HTTP/1.1，交给代理却应该带上 http://service.example/api/items？答案是请求目标所在的协议边界不同。Request.Write 面向直接连接的 HTTP/1.1 写出，Request.WriteProxy 面向 HTTP 代理，初始请求行使用包含 scheme 和 host 的绝对 URI。

这不是把 URL 重复拼接，也不是把 RequestURI 随手塞进客户端请求。排查时要把三件事分开：URL 描述要访问的目标，Host 决定 Host 头的取值，WriteProxy 决定代理场景下请求行采用绝对 URI。

为什么代理请求行要带完整 URL

直连时，TCP 连接已经指向目标服务器，服务器通常只需要从请求行读取路径和查询串，也就是 origin-form。代理连接则不同：TCP 对端是代理，代理必须从请求目标中知道下一跳的协议和主机，因此请求行使用 absolute-form，把 scheme、host 和路径一起交给代理。

Go 官方文档把 WriteProxy 描述为类似 Request.Write，但会按 HTTP 代理期待的形式写出请求；它会在初始 Request-URI 中包含 scheme 和 host，并且仍会写出 Host 头，Host 取 r.Host，为空时回退到 r.URL.Host。所以“完整 URL”解决的是代理识别目标的问题，“Host 头”解决的是 HTTP 请求头中的主机字段问题，两者相关但不是同一个字段。

这里还有一个很容易混淆的名字：RequestURI 是服务器收到的原始 request-target。Go 文档明确说，客户端请求设置这个字段是错误的；客户端代码应设置 URL，让写出方法根据场景生成请求目标。

从 URL、Host 到请求行，字段怎样分工

代理问题常常不是代理本身坏了，而是构造请求时把服务端请求和客户端请求的字段混用了。下面这个示例把请求写到内存缓冲区中，方便观察两种方法的职责；它是文章中的说明代码，不代表已经连接或抓取了真实代理。

package main

import (
    "bytes"
    "fmt"
    "net/http"
)

func dumpRequest(req *http.Request) error {
    var direct bytes.Buffer
    // Write 用于直接写向目标服务器的 HTTP/1.1 请求。
    if err := req.Write(&direct); err != nil {
        return fmt.Errorf("直连写出失败: %w", err)
    }

    var proxy bytes.Buffer
    // WriteProxy 面向 HTTP 代理，请求行需要携带绝对 URI。
    if err := req.WriteProxy(&proxy); err != nil {
        return fmt.Errorf("代理写出失败: %w", err)
    }

    fmt.Println("直连格式:")
    fmt.Print(direct.String())
    fmt.Println("代理格式:")
    fmt.Print(proxy.String())
    return nil
}

func main() {
    // URL 是客户端请求的目标来源，RequestURI 不应由客户端手工设置。
    req, err := http.NewRequest("GET", "http://service.example/api/items?q=go", nil)
    if err != nil {
        panic(err)
    }
    req.Host = "service.example"

    if err := dumpRequest(req); err != nil {
        panic(err)
    }
}

阅读这段代码时只抓三条线索：URL 提供 scheme、host、path 和 query；Host 可以显式覆盖 Host 头；RequestURI 不参与客户端请求的正常构造。若只想把请求交给真正的代理发送，通常应配置 http.Transport.Proxy 后调用 http.Client.Do，而不是在业务层手写代理请求行。

代理调试时按哪条线索排查

我后来把排查顺序固定成“代理选择—请求对象—写出形式—目标服务”四个边界。先确认 Transport 是否选中了代理，再确认请求的 URL 是绝对地址；如果手工覆盖了 Host，还要确认它是否仍然代表目标服务，而不是代理地址。最后才看代理收到的请求行是否是 absolute-form。

如果代理报“请求目标不完整”，优先检查是否把 Write 当成了 WriteProxy。如果目标服务报告 Host 不对，检查的是 req.Host 与 req.URL.Host 的关系，而不是盲目给路径前面再拼一次协议。若请求通过 http.Client 正常发送，则让标准库 Transport 负责代理协议细节，业务代码只维护正确的 URL 和请求头。

还要注意 RequestURI 的生命周期：它更像服务端读取请求后的原始记录，不是客户端重写请求目标的开关。把它写进客户端请求，既不能稳定地解决代理格式，也会让代码偏离标准库的使用约定。

避免同类问题再次出现

把请求写出逻辑集中在一个小函数里，并在代码评审中明确它是“直连写出”还是“代理写出”。配置代理优先使用 Transport.Proxy；确实需要序列化原始 HTTP/1.1 请求时，再根据对端是目标服务器还是 HTTP 代理选择 Write 或 WriteProxy。

最后可以保留一张不含敏感信息的排查记录：代理是否命中、URL 的 scheme/host 是否存在、Host 头最终取值、写出方法是什么。不要把认证头、Cookie、令牌或完整内部地址写入共享日志。

• 为什么 WriteProxy 要包含 scheme 和 host？因为代理需要从请求目标识别下一跳，HTTP 代理请求行使用 absolute-form。
• 可以直接设置 RequestURI 解决客户端代理请求吗？不建议。RequestURI 属于服务端接收的原始请求目标，客户端应设置 URL。
• Host 和 URL.Host 必须始终相同吗？不一定；Host 可以显式覆盖 Host 头，但应明确这是协议需求，而不是用来替代 URL。