Go语言实现HTTP反向代理与负载均衡

本文深入剖析了如何在Go语言中正确实现HTTP反向代理与负载均衡，强调httputil.NewSingleHostReverseProxy作为轻量稳健的起点，重点讲解Director函数的核心作用——统一处理URL重写、Scheme/Host设置、Header修正（如X-Real-IP）及轮询调度逻辑；同时警示常见陷阱：原始请求直传导致的404/重定向异常、并发不安全的轮询计数器、健康检查误放Director内、未自定义Transport引发的连接泄漏与超时雪崩，并给出原子操作轮询、预解析后端URL、合理配置IdleConnTimeout/TLSHandshakeTimeout等实战方案；最后指出真实部署中LB链路对Header的叠加影响、X-Forwarded-For多层解析、日志三要素比对等关键细节——真正难点不在代码本身，而在于理解每一层网络中间件对请求的悄然篡改。

用 httputil.NewSingleHostReverseProxy 快速启动反向代理

Go 标准库的 httputil.NewSingleHostReverseProxy 是最轻量、最稳妥的起点，它已经处理了请求转发、响应透传、Header 修正（比如 X-Forwarded-For）等基础逻辑。别自己从 http.RoundTripper 开始造轮子。

常见错误是直接把原始 *http.Request 原样转发——这会导致 Host 头没改、URL.Scheme 和 URL.Host 混乱，后端服务返回 404 或重定向错乱。

• 必须用 url.Parse("http://backend:8080") 构造 *url.URL，再传给 NewSingleHostReverseProxy
• 代理前要调用 req.URL.Scheme = "http" 和 req.URL.Host = proxy.Director 覆盖后的地址，但更推荐交给 Director 函数统一处理
• 如果后端是 HTTPS，URL.Scheme 必须设为 "https"，否则 RoundTrip 会默认走 HTTP

proxy := httputil.NewSingleHostReverseProxy(u)
proxy.Director = func(req *http.Request) {
    req.URL.Scheme = "http"
    req.URL.Host = "10.0.1.100:8080"
    req.Header.Set("X-Real-IP", realIP(req))
}

实现简单轮询负载均衡：自己写 Director + 后端列表

标准 ReverseProxy 本身不带多后端调度能力，Director 就是你插入调度逻辑的唯一入口。轮询不是靠配置开关，而是靠你维护一个可变的索引或 channel。

容易踩的坑是并发安全：多个请求同时修改全局计数器导致雪崩式打到同一台机器。别用裸 int 变量加锁，优先用 atomic 或预生成轮询序列。

• 后端地址必须提前解析成 *url.URL，避免每次请求都调用 url.Parse（开销大且可能 panic）
• 在 Director 中做健康检查判断？不行——这里要求低延迟，健康探测应异步运行并更新后端状态表
• 如果某台后端临时不可达，RoundTrip 会返回 error，你需要在外层 Handler 捕获并 fallback，Director 本身不处理失败

var backends = []*url.URL{u1, u2, u3}
var cur uint64
proxy.Director = func(req *http.Request) {
    i := atomic.AddUint64(&cur, 1) % uint64(len(backends))
    u := backends[i]
    req.URL.Scheme = u.Scheme
    req.URL.Host = u.Host
    req.URL.Path = u.Path // 注意：通常保留原始 Path，除非要做路径重写
}

超时和连接复用：不设 Transport 就等于裸奔

默认的 http.DefaultTransport 用在代理场景下非常危险：它对后端连接没有限制，也没有合理超时，一次慢请求可能拖垮整个代理进程。

必须自定义 http.Transport 并赋给 ReverseProxy.Transport。重点不是“怎么配”，而是“不配会发生什么”：连接泄漏、TIME_WAIT 爆满、DNS 缓存不更新、TLS 握手卡死。

• MaxIdleConnsPerHost 建议设为 32～100，太小导致频繁建连，太大压垮后端
• IdleConnTimeout 设为 30s，避免长连接空耗资源；TLSHandshakeTimeout 必须设（如 10s），否则 TLS 卡住永不返回
• 不要复用 http.DefaultClient，它的 Transport 是全局共享的，改一处影响所有 HTTP 调用

proxy.Transport = &http.Transport{
    MaxIdleConnsPerHost: 64,
    IdleConnTimeout:     30 * time.Second,
    TLSHandshakeTimeout: 10 * time.Second,
    // 别漏掉这个：防止 DNS 变更不生效
    ForceAttemptHTTP2: true,
}

真实部署时最容易被忽略的细节

本地跑通 ≠ 上线可用。Kubernetes Ingress、Nginx、甚至云厂商 LB 都可能在你之前就改了 Header 或拆包，导致你的 Director 逻辑失效。

比如你在 Director 里靠 req.Header.Get("X-Forwarded-For") 提取客户端 IP，但前面有两层 LB，实际该 Header 已被追加成逗号分隔列表——你直接取第一个就错了。

• 永远用 realIP := strings.TrimSpace(strings.Split(req.Header.Get("X-Forwarded-For"), ",")[0])，而不是直接 Get
• 日志里必须记录 req.RemoteAddr、X-Forwarded-For、最终转发的 URL.Host，三者对不上就要查链路
• HTTP/2 支持需要两端都开启，如果你的后端不支持 h2，代理层强制 ForceAttemptHTTP2: true 会导致连接失败

复杂点不在代码行数，而在你得清楚每一层网络设备在改什么、删什么、加什么 Header。调试时先关掉所有中间件，逐层加回来。

本篇关于《Go语言实现HTTP反向代理与负载均衡》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！