Fiber 本身不提供反向代理能力，需手动集成 httputil.ReverseProxy 并精细配置 Director、Transport、X-Forwarded 头等关键项，否则易引发 502、连接泄漏、头丢失等问题。
Fiber 本身不是反向代理库，它不提供类似 httputil.ReverseProxy 的内置能力。想用 Fiber 做反向代理，你得自己集成标准库的 httputil.ReverseProxy，并手动处理关键细节——否则极易出现 502、连接堆积、头丢失、超时失控等问题。
下面聚焦真正落地时必须面对的几个实操点。
Director 必须重写 req.URL.Scheme、Host 和 Path
只传 backendURL 给 NewSingleHostReverseProxy 不够，Director 函数漏掉任意一项都会导致请求发错地方。
-
req.URL.Scheme必须显式设为"https"（如果后端是 HTTPS），否则默认仍是"http"，结果就是连接被拒绝或 TLS 握手失败 -
req.URL.Host必须设成后端地址（如"api.example.com:443"），不能依赖构造时的target—— 否则请求会发到本地 loopback 或空 host -
req.URL.Path推荐用singleJoiningSlash拼接，避免双斜杠或路径截断：req.URL.Path = singleJoiningSlash(backendURL.Path, req.URL.Path)
Fiber 中嵌入 ReverseProxy 要绕过中间件生命周期
Fiber 的中间件执行顺序和 http.Handler 不完全一致；直接把 proxy.ServeHTTP 放进 ctx.Next() 后面，会导致日志、超时、Body 解析等中间件干扰代理流。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
ctx.Fasthttp.Response.BodyWriter()+fasthttp底层适配，或更稳妥地：在 Fiber 路由 handler 里直接调用proxy.ServeHTTP，且确保前面没其他中间件读取ctx.Request().Body() - 不要对代理路由启用
BodyParser或Logger（除非你明确重写了日志输出逻辑）——它们会提前 consume body 或修改 header - 若需鉴权，应在
Director之前完成，并把 token 注入req.Header.Set("Authorization", ...)，而不是靠中间件改 request body
流控不能只靠 Fiber 的 RateLimit 中间件
fiber.RateLimit 只限制请求数，对大文件下载、长连接 streaming、后端 hang 住等场景完全无效。真正的流控要落在 Transport 层和连接维度。
- 必须配置自定义
http.Transport：至少设MaxIdleConnsPerHost: 100和IdleConnTimeout: 30 * time.Second，否则高并发下很快耗尽 fd -
ReadTimeout是关键：它能中断正在读响应体的连接，防止 goroutine 泄漏；ResponseHeaderTimeout控制等待响应头的时间，避免卡死在 handshake 阶段 - 不要用
context.WithTimeout包裹proxy.ServeHTTP调用——它只管 handler 执行，不中断底层 TCP 流；超时必须由Transport触发
X-Forwarded-* 头必须手动补全，且注意覆盖 vs 追加
httputil.ReverseProxy 默认不加任何 X-Forwarded- 头，下游服务拿不到真实客户端 IP 或协议信息。
-
X-Forwarded-For应用Add（不是Set），因为可能已有上游 Nginx 添加的链路；解析req.RemoteAddr并过滤私有 IP 后追加 -
X-Forwarded-Proto根据req.TLS != nil判断设为"https"或"http" -
X-Forwarded-Host直接设为req.Host；但要注意：如果 Fiber 前面还有一层 CDN 或 LB，req.Host可能已被改写，此时应从X-Forwarded-Host读取并验证可信来源
Fiber 作为胶水层挺好，但它不接管代理的底层连接生命周期。所有超时、复用、头注入、错误传播都得你亲手钉在 http.Transport 和 Director 上——漏掉任一环，上线后就会在流量高峰时静默崩掉。
