Golang 编写支持动态路由的高性能反向代理系统-Golang-PHP中文网

Director函数必须重写req.URL.Host和req.Host，否则后端因Host头不匹配会404；还需设req.URL.Scheme、透传X-Forwarded-For、删除hop-by-hop头，并定制Transport连接池与超时。

golang 编写支持动态路由的高性能反向代理系统

Director 函数必须重写 req.URL.Host 和 req.Host

默认的 httputil.NewSingleHostReverseProxy 只改 req.URL.Host，但不会同步更新 req.Host 请求头。后端服务（比如 Nginx、Spring Cloud Gateway）若依赖 Host 头做路由或租户识别，就会 404 或返回默认站点。

常见错误现象：前端访问 /api/user 返回 404，但直连后端却正常；或日志里看到后端收到的 Host 是 localhost:3000 而不是你期望的 user-service.internal。

必须在 Director 中显式设置：req.Host = backendURL.Host
如果后端是 HTTPS，还得补上：req.URL.Scheme = "https"
若后端监听 127.0.0.1:8080，就别用 localhost:8080 —— DNS 缓存或 hosts 干扰会导致连接被拒

动态路由匹配要用中间件拦截，不能只靠 http.ServeMux

http.ServeMux 是静态前缀匹配，不支持运行时热更新规则；而真实网关需要按 path、method、header 甚至 JWT claim 做细粒度路由。直接注册 http.HandleFunc("/api/*", ...) 会漏掉 OPTIONS 预检、带 query 的变体，且无法 fallback。

实操建议：用 gin 或 httprouter 做接入层，把路由逻辑下沉到中间件里查表匹配：

维护一个全局 []RouteRule 切片，字段含 Path、Method、ServiceURL、MatchHeader
每次请求进 middleware 后遍历匹配（小规模可线性查，大流量建议用 trie 树或预编译正则）
匹配成功后调用 httputil.NewSingleHostReverseProxy(backendURL)，**不要复用 proxy 实例** —— 每个后端应有独立 Director 和 Transport

Transport 必须定制，否则高并发下 goroutine 泄漏

默认 http.DefaultTransport 没设超时、没控连接数，后端一卡住，代理就堆满 pending request，内存暴涨、goroutine 数破万。这不是代码写错，是 Transport 缺配置。

关键参数必须显式设：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

MaxIdleConns 和 MaxIdleConnsPerHost 建议都设为 100（根据后端实例数调整）
IdleConnTimeout 设为 30 * time.Second，避免空闲连接长期占资源
ResponseHeaderTimeout 控制 header 返回时间，防止后端挂起不发 header
HTTPS 后端加 TLSClientConfig: &tls.Config{InsecureSkipVerify: true}（仅测试环境）

注意：每个 ReverseProxy 实例要配独立 Transport，别共用全局 client —— 不同后端可能需不同超时或证书策略。

X-Forwarded-For 透传要自己拼接，不能直接覆盖

Go 的 ReverseProxy 默认不加 X-Forwarded-For，后端看到的 RemoteAddr 永远是代理本机地址（如 127.0.0.1:54321）。但直接 req.Header.Set("X-Forwarded-For", clientIP) 会丢掉上游已有的链路信息，导致风控或限流失效。

正确做法是在 Director 里做安全拼接：