直接用 httputil.newsinglehostreverseproxy 会丢请求头，因其默认过滤敏感头并清空 x-forwarded-for；需重写 director、modifyresponse，显式控制流式响应、负载均衡、健康检查、内存优化及地址配置。
为什么直接用 httputil.NewSingleHostReverseProxy 会丢请求头
因为默认配置下，ReverseProxy 会过滤掉部分敏感请求头（比如 Connection、Keep-Alive、Proxy-Authenticate 等），还会把 X-Forwarded-For 设成空——不是 bug，是安全默认行为。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须重写
Director函数，手动补全X-Forwarded-For和保留原始User-Agent、Accept等头 - 通过
ModifyResponse钩子清理响应头里的Set-Cookie域名或Location跳转地址，否则后端返回的绝对路径会暴露真实服务地址 - 别依赖默认的
FlushInterval，流式响应（如 SSE、gRPC-Web）要显式设为0，否则卡住
如何让 ReverseProxy 支持轮询和健康检查
标准库不带负载均衡逻辑，ReverseProxy 本身只代理单个 *url.URL。轮询得自己维护后端列表 + 状态，并在 Director 里动态选目标。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync/atomic或sync.Mutex保护后端索引计数器，避免并发错乱 - 健康检查不能只靠连接是否成功——要发一个轻量
HEAD /health并校验状态码，失败三次才摘机 - 摘机后别立刻剔除，放进一个带 TTL 的 map 里缓存 30 秒，防止网络抖动误判
- 别在
Director里做同步 HTTP 请求，否则整个代理线程会被堵死；改用异步 goroutine + channel 更新状态
ReverseProxy 转发大文件或长连接时为啥内存暴涨
因为默认使用 io.Copy 流式转发，但底层 buffer 是 32KB，如果后端响应体巨大（比如下载文件），Go runtime 会频繁分配临时 buffer，GC 压力大；更麻烦的是，如果客户端中途断开，而服务端还在发数据，ReverseProxy 不会自动中断后端连接，导致连接堆积。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 给
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 指向的是代理自身，不是你期望的服务实例。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有后端地址统一用 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 抓取。这些不加，出问题只能靠猜。
