直接用 http.ServeHTTP 转发请求会出错，因后端需已解析且上下文完整的请求，而代理中原始请求的 Host、Path、Hop-by-Hop Header 未清理，导致 404 或空响应；正确做法是构造新 *http.Request，重写 URL/Host、过滤 Connection 等头，并按需配置 TLS。
为什么直接用 http.ServeHTTP 转发请求会出错？
常见错误是把客户端 *http.Request 直接传给后端服务的 http.ServeHTTP，结果返回 404 或空响应。这是因为 http.ServeHTTP 期望处理的是「已解析的、带完整上下文的入站请求」，而代理中拿到的请求可能 Host、URL.Path、Header（如 Connection、Transfer-Encoding）未清理，导致后端无法识别或拒绝处理。
正确做法是构造一个新的 *http.Request，显式设置 URL、Host 和关键 Header，并禁用某些代理不应当透传的字段：
-
req.URL.Scheme和req.URL.Host必须重写为后端地址（如"http://127.0.0.1:8080"） - 手动设置
req.Host = "backend.example.com"，否则后端可能收不到 Host 头 - 删除
Connection、Keep-Alive、Proxy-Authenticate等 hop-by-hop 头（Go 不自动处理，需手动过滤） - 若后端是 HTTPS，需用
http.Transport配置 TLS，不能只改 URL Scheme
如何支持 CONNECT 方法实现 HTTPS 代理？
浏览器访问 HTTPS 站点前会先发 CONNECT google.com:443 请求，此时服务器不能返回 HTTP 响应体，而要升级为隧道——即建立 TCP 层直连，并将客户端与后端连接双向拷贝数据。
关键点不在 HTTP 处理逻辑里，而在 http.HandlerFunc 中判断方法并接管连接：
立即学习“go语言免费学习笔记（深入）”；
- 检测
req.Method == "CONNECT"，立即返回http.StatusOK响应头"200 Connection established" - 调用
hijack := w.(http.Hijacker).Hijack()获取底层net.Conn - 用
net.Dial("tcp", req.Host)连后端，然后启动两个io.Copy协程双向转发原始字节流 - 注意：必须关闭超时控制（
conn.SetDeadline(time.Time{})），否则io.Copy可能被中断
漏掉 Hijacker 类型断言或未正确关闭任一连接，会导致连接泄漏或浏览器卡死。
怎样避免代理自身成为性能瓶颈？
默认 http.DefaultTransport 的连接池参数过于保守，高并发下容易耗尽文件描述符或卡在 DNS 解析。真实代理服务必须定制 http.Transport：
-
MaxIdleConns: 100、MaxIdleConnsPerHost: 100防止连接复用不足 -
IdleConnTimeout: 30 * time.Second避免长连接堆积 -
TLSClientConfig: &tls.Config{InsecureSkipVerify: true}（仅测试用；生产环境需配置证书验证） - 对后端域名做 DNS 缓存（可用
github.com/miekg/dns或net.Resolver配合sync.Map实现）
没调大 MaxIdleConnsPerHost 时，同一后端的并发请求会被串行化，延迟陡增——这不是代码逻辑问题，而是 Transport 默认限制。
为什么有些请求转发后 Cookie 或 Referer 异常丢失？
不是所有 Header 都会自动透传。Go 的 http.Request.Header 在转发时默认只保留标准字段，且部分字段（如 Cookie）在跨域或重写 Host 后可能被客户端或中间件丢弃。
解决方案是显式复制白名单 Header：
- 保留
Cookie、Referer、User-Agent、Accept*、Content-Type等业务关键头 - 避免复制
Origin（可能触发 CORS 拦截）或Authorization（除非明确需要透传） - 如果后端是不同域名，
Cookie的Domain属性可能不匹配，需用中间件重写Set-Cookie头中的Domain=字段
最易忽略的是：当 req.URL.Path 被重写（例如从 /api/v1/ 代理到 /），而前端又依赖路径生成相对 URL，会导致资源加载失败——这不属于 Header 问题，但现象相似。
