应显式配置http.Transport，设MaxIdleConns、MaxIdleConnsPerHost为100～200，IdleConnTimeout=30s、TLSHandshakeTimeout=10s；通过Director透传Host和X-Forwarded-For；负载均衡交由DNS或服务发现层；避免在ModifyResponse中直接http.Error。
Go net/http ReverseProxy 怎么正确设置 Transport 避免连接泄漏
不配 Transport 的 ReverseProxy 在高并发下会快速耗尽文件描述符，现象是请求卡住、dial tcp: lookup failed 或 too many open files 错误。
根本原因是默认的 http.DefaultTransport 复用连接但没设上限，后端服务响应慢或超时时，空闲连接堆积，TCP 连接长期 hang 在 ESTABLISHED 或 CLOSE_WAIT 状态。
- 必须显式构造
http.Transport，设置MaxIdleConns（全局最大空闲连接数）、MaxIdleConnsPerHost（每 host 限制），建议都设为 100～200 - 务必设置
IdleConnTimeout（如 30s）和TLSHandshakeTimeout（如 10s），否则 idle 连接永不释放 - 如果后端有健康检查或短连接场景，可把
ForceAttemptHTTP2设为false，避免 HTTP/2 流复用干扰连接管理
tr := &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
}如何让 ReverseProxy 透传原始 Host 和真实客户端 IP
默认 ReverseProxy 会改写 Host 头为后端地址，并丢弃 X-Forwarded-For，导致下游服务无法识别来源或做限流鉴权。
关键在重写 Director 函数 —— 它决定请求怎么转发，所有头透传逻辑必须在这里处理。
立即学习“go语言免费学习笔记（深入）”；
- 保留原始
Host：直接赋值req.Host = req.Header.Get("Host")，不要用url.Host - 追加真实客户端 IP：检查
X-Real-IP或X-Forwarded-For，取最左非私有地址（注意防御伪造，需结合RemoteAddr白名单校验） - 补全
X-Forwarded-Proto和X-Forwarded-Host，否则下游 HTTPS 判断或生成绝对 URL 会出错
proxy.Director = func(req *http.Request) {
req.URL.Scheme = "http"
req.URL.Host = backendURL.Host
req.Host = req.Header.Get("Host") // ← 关键
if clientIP := realIPFromRequest(req); clientIP != "" {
if old := req.Header.Get("X-Forwarded-For"); old != "" {
req.Header.Set("X-Forwarded-For", old+", "+clientIP)
} else {
req.Header.Set("X-Forwarded-For", clientIP)
}
}
}Go API 网关里要不要自己实现负载均衡？
不用。标准库 ReverseProxy 本身不带 LB 能力，但硬编码轮询或随机选后端极易出错，且无法感知节点健康状态。
更稳妥的做法是把 LB 下沉到 DNS 或服务发现层，或用轻量级第三方包，而不是在 Director 里手写调度逻辑。
- 优先走
SRV记录 +net.Resolver动态解析，配合定期刷新，天然支持权重与健康探测 - 若需软负载，用
google.golang.org/grpc/xds/internal/balancer的简化版轮询策略即可，别碰一致性哈希——它对后端扩缩容敏感，且 Go 生态缺乏成熟 ring 实现 - 绝对避免在
Director中调用阻塞 IO（比如查 etcd），会拖垮整个代理 goroutine
为什么 http.Error 和自定义错误响应容易破坏 ReverseProxy 流程
在 ReverseProxy 的 ModifyResponse 或中间件中直接调用 http.Error，会导致响应体被提前写出，后续 ReverseProxy.ServeHTTP 再写就会 panic：http: multiple response.WriteHeader calls。
真正需要拦截并返回错误时，必须中断代理流程，且确保底层 ResponseWriter 没被写过任何字节。
- 判断是否已写响应：检查
w.Header().Get("Content-Length")是否为空，或用httptest.ResponseRecorder包装 writer 做测试 - 安全拦截方式：在
Director或前置 handler 中判断条件，满足则直接 return，不调proxy.ServeHTTP - 若必须在
ModifyResponse中拒绝，应先读空resp.Body，再调resp.Body.Close()，最后用新 writer 写错误
反向代理真正的复杂点不在转发逻辑，而在连接生命周期、头字段语义、错误传播路径这三处边界——它们不报错，但会让流量静默丢失或行为漂移。
