Golang实现简易HTTP反向代理与负载均衡

直接用 httputil.NewSingleHostReverseProxy 会丢请求头，因其默认过滤敏感头并清空 X-Forwarded-For；需重写 Director、ModifyResponse，显式控制流式响应、负载均衡、健康检查、内存优化及地址配置。

为什么直接用 httputil.NewSingleHostReverseProxy 会丢请求头

因为默认配置下，ReverseProxy 会过滤掉部分敏感请求头（比如 Connection、Keep-Alive、Proxy-Authenticate 等），还会把 X-Forwarded-For 设成空——不是 bug，是安全默认行为。

实操建议：

• 必须重写 Director 函数，手动补全 X-Forwarded-For 和保留原始 User-Agent、Accept 等头
• 通过 ModifyResponse 钩子清理响应头里的 Set-Cookie 域名或 Location 跳转地址，否则后端返回的绝对路径会暴露真实服务地址
• 别依赖默认的 FlushInterval，流式响应（如 SSE、gRPC-Web）要显式设为 0，否则卡住

如何让 ReverseProxy 支持轮询和健康检查

标准库不带负载均衡逻辑，ReverseProxy 本身只代理单个 *url.URL。轮询得自己维护后端列表 + 状态，并在 Director 里动态选目标。

实操建议：

• 用 sync/atomic 或 sync.Mutex 保护后端索引计数器，避免并发错乱
• 健康检查不能只靠连接是否成功——要发一个轻量 HEAD /health 并校验状态码，失败三次才摘机
• 摘机后别立刻剔除，放进一个带 TTL 的 map 里缓存 30 秒，防止网络抖动误判
• 别在 Director 里做同步 HTTP 请求，否则整个代理线程会被堵死；改用异步 goroutine + channel 更新状态

ReverseProxy 转发大文件或长连接时为啥内存暴涨

因为默认使用 io.Copy 流式转发，但底层 buffer 是 32KB，如果后端响应体巨大（比如下载文件），Go runtime 会频繁分配临时 buffer，GC 压力大；更麻烦的是，如果客户端中途断开，而服务端还在发数据，ReverseProxy 不会自动中断后端连接，导致连接堆积。

实操建议：

• 给 Director 设置的 req.Host 和 req.URL.Host 必须一致，否则 http.Transport 无法复用连接
• 自定义 http.Transport，设 MaxIdleConnsPerHost = 100，并启用 ForceAttemptHTTP2 = true
• 用 context.WithTimeout 包裹每个代理请求，在 Director 中注入 cancel 函数，客户端断开时主动关后端连接
• 大文件场景下，考虑加一层 io.LimitReader 或提前判断 Content-Length，超限直接 413

为什么本地调试时 localhost:8080 能通，部署到服务器就 502

常见原因是后端地址写死了 localhost，而代理进程运行在容器或另一台机器上，localhost 指向的是代理自身，不是你期望的服务实例。

实操建议：

• 所有后端地址统一用 DNS 名或内网 IP，绝不用 127.0.0.1 或 localhost
• 检查容器网络模式：host 模式下 localhost 才真指宿主机；bridge 模式下必须用 host.docker.internal（Mac/Win）或容器名（Linux）
• 加一行日志：在 Director 里打 fmt.Printf("proxy to %s\n", u.String())，确认实际转发地址是否符合预期
• 用 curl -v http://your-proxy/health 看响应头里的 X-Upstream-Addr（如果你加了这个自定义头），快速定位转发目标

真正难的不是写转发逻辑，而是怎么让每次失败都有迹可循——日志得带请求 ID，超时得区分是 client 还是 upstream，健康检查得能被 Prometheus 抓取。这些不加，出问题只能靠猜。