使用 httputil.NewSingleHostReverseProxy 时需自定义 Director 设置 req.URL.Host/Scheme 和 Host 头，手动透传 X-Real-IP、X-Forwarded-For 等关键头，并在 ModifyResponse 中清除 hop-by-hop 头，否则请求头会被过滤或导致 502。
Go 的 httputil.NewSingleHostReverseProxy 怎么用才不丢请求头
直接用 httputil.NewSingleHostReverseProxy 时，常见现象是后端收不到 Authorization、X-Forwarded-For 等头，甚至 Content-Type 被清空。根本原因是 Go 默认只透传有限的“安全头”，其余一律过滤。
必须显式修改 Director 和 ModifyResponse，并补全关键头：
- 在
Director中重写req.URL.Host和req.URL.Scheme，否则后端看到的是 localhost 或 http - 手动复制原始请求头：
req.Header.Set("X-Real-IP", req.RemoteAddr)、req.Header.Set("X-Forwarded-For", req.Header.Get("X-Forwarded-For")) - 在
ModifyResponse中清除Connection、Keep-Alive等 hop-by-hop 头（Go 不自动处理，不删会导致 502） - 若后端依赖
Host头（如多租户路由），需显式设置：req.Header.Set("Host", "api.example.com")
Nginx 作为前置反向代理时，Go 服务如何正确读取真实客户端 IP
Nginx 默认不会把原始 IP 传给后端，Go 里 r.RemoteAddr 拿到的只是 Nginx 的内网地址。必须让 Nginx 主动加头，并在 Go 里信任该头。
在 Nginx 配置中加这两行：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Go 侧不能直接信 X-Forwarded-For —— 它可能被伪造。应结合 trusted proxy list 判断：
- 若 Nginx 和 Go 服务同机或走内网，可硬编码信任
127.0.0.1或192.168.0.0/16 - 用
net.ParseIP解析X-Forwarded-For最右非信任段（即最外层未被篡改的 IP） - 避免用第三方中间件盲目信任全部
X-Forwarded-For，易被绕过
Go 内置反向代理 vs Nginx：什么场景该用哪个
不是“二选一”，而是“谁更靠近流量入口”。Go 代理适合动态路由、鉴权、灰度等需要代码逻辑介入的环节；Nginx 更适合静态资源、TLS 终止、限流、缓存等通用能力。
- 纯 API 聚合（如 BFF 层）：用 Go
httputil，方便注入 JWT 校验、请求重写、fallback 逻辑 - 高并发静态文件 + HTTPS + WAF：Nginx 做第一层，Go 只处理 /api/*
- 调试阶段想快速验证路由逻辑：Go 代理启动快、热重载方便；上线后仍可保留，但 TLS 和负载均衡交给 Nginx
- 注意：Go 的
http.Transport默认连接池大小是 100，大量后端服务时需调大MaxIdleConnsPerHost，否则容易出现dial tcp: lookup xxx: no such host
HTTP/2 支持下，Go 反向代理和 Nginx 的协作陷阱
如果 Nginx 启用了 HTTP/2（listen 443 http2），而 Go 后端只支持 HTTP/1.1，Nginx 会自动降级，通常无感。但反过来——Go 用 http2.ConfigureServer 开了 HTTP/2，Nginx 却没配 http2，就会卡在 ALPN 协商失败，返回空响应。
更隐蔽的问题是 header 大小限制：
- Nginx 默认
large_client_header_buffers是 4k，而 HTTP/2 的 HPACK 编码可能让 header 块膨胀 - Go 的
http.Server默认不限制 header 大小，但 Nginx 若收到超长 header 会直接 400，且不透传错误原因 - 排查时看 Nginx error log 是否有
client sent too large header，而不是盯着 Go 日志
真实部署中，HTTP/2 的协商、header 处理、TLS 握手细节都在 Nginx 层完成，Go 应专注业务逻辑，别试图在它上面做协议卸载。
