Go 的 http.Client 允许伪造多数请求头，但 Host、Content-Length 等字段受限制：Host 需通过 req.Host 设置，Content-Length 由 Go 自动计算，Connection 等由 Transport 管理，手动设置可能被忽略或引发 panic。
Go 的 http.Client 默认不会阻止 Header 伪造
Go 的标准库 http.Client 允许你自由设置任意请求头，包括那些通常由服务器或底层协议控制的字段（比如 Host、Content-Length、Connection）。这不是 bug，是设计选择：它把责任交给了使用者。但这也意味着，如果你直接写 req.Header.Set("Host", "evil.com")，请求真会发出去——而很多服务端没做校验，就信了。
常见错误现象：net/http: invalid header field name "Host" 这类报错其实只在极少数非法字符时触发，正常伪造几乎不拦；更隐蔽的问题是服务端信任了伪造的 X-Forwarded-For 或 X-Real-IP 做权限判断，结果绕过限制。
- 使用场景：爬虫伪装、内部服务间可信调用、灰盒测试
- 注意
Host字段要通过req.URL.Host或req.Host设置，直接塞进Header会被忽略（Go 会覆盖） - 某些代理或网关（如 Nginx）默认剥离或重写
Host，伪造后未必生效，得看链路终点是否透传
哪些 Header 在 Go 里被自动过滤或强制覆盖
Go 的 http.Transport 和 http.Request 内部有一组“受限头”，它们要么被忽略，要么由运行时强制写入。比如你手动设 Content-Length，但 body 是 nil 或未指定长度，Go 会清掉它；又比如 Transfer-Encoding，一旦设了 chunked，Go 就不允许再设 Content-Length，否则发请求时 panic。
- 典型被拦截字段：
Host（需走req.Host）、Content-Length（自动计算）、Connection（由 Transport 管理）、Accept-Encoding（自动加gzip除非显式禁用） - 检查方法：打印
req.Header后再调用client.Do(req)，对比实际发出的抓包（如 Wireshark 或 mitmproxy），别信日志里的Header输出 - 兼容性影响：老版本 Go（Upgrade 头处理宽松，新版本更严格，升级后原来能发的 WebSocket 升级头可能失败
防御端如何识别 Go 客户端伪造的请求
服务端不能只靠某个 Header 判断真假，得组合验证。Go 发出的请求有指纹特征：比如默认 User-Agent 是 Go-http-client/1.1 或 /2.0；HTTP/2 请求没有 Connection: keep-alive；TLS 握手参数（如 ALPN、支持的密钥交换）也和浏览器差异明显。
立即学习“go语言免费学习笔记（深入）”；
- 简单有效手段：检查
User-Agent是否为Go-http-client/*，再结合Accept（Go 默认不带*/*，常为空或只写application/json） - 更可靠方式：服务端记录 TLS ClientHello 的
signature_algorithms扩展，Go 默认只支持ecdsa_secp256r1_sha256等有限几种，而 Chrome/Firefox 支持十余种 - 注意：有些 Go 程序会改
Client.UserAgent，所以单靠 UA 不够；但若同时伪造了Accept、Sec-Fetch-*等浏览器专属头，反而露馅（Go 标准库根本不发这些）
安全请求设计：绕过伪造陷阱的实用做法
如果你是客户端开发者，想让请求既合规又可控，关键不是“怎么伪造得更像”，而是“怎么让服务端没法误判”。核心思路是：用标准行为建立信任，用额外字段传递业务意图，而不是污染协议层头。
- 不要碰
Host、Content-Length、Connection—— 它们属于传输层，交给 Go 自己管 - 业务标识统一走自定义头，比如
X-Request-ID、X-Service-Name，并在服务端白名单校验其格式和签名 - 需要身份透传时，优先用 TLS 证书双向认证，比任何 Header 都可靠；次选是用
Authorization: Bearer+ JWT，Payload 里放 issuer 和 scope - 调试阶段务必用
httputil.DumpRequestOut抓原始字节，别只看req.Headermap，Go 很多逻辑发生在序列化瞬间
Header 伪造本身很简单，难的是伪造之后整条链路是否还稳定、是否被中间设备截断、服务端是否真按你以为的方式解析。越想绕过，越要先搞清每个环节真正依赖什么字段——而不是堆砌更多伪造头。
