Hey的User-Agent细节为什么自定义UA后仍会强制拼接hey/0.0.1【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/heyhey 是一款轻量级的HTTP 压测工具ApacheBenchab的现代替代品用于向 Web 服务快速发送大量请求并输出延迟、状态码等统计。不少用户在使用-U或-H参数自定义 User-Agent 后发现实际发出的 UA 末尾总会多出hey/0.0.1。这不是 Bug而是 hey 的刻意设计。本文带你读懂这段拼接逻辑的原理与背后的原因。一、先看现象三种设置方式下的真实 UA用下表快速理解行为差异 使用方式实际发出的 User-Agenthey https://example.com不设置hey/0.0.1hey -H User-Agent: my-agent ...my-agent hey/0.0.1hey -U my-agent ...my-agent hey/0.0.1关键结论无论你用什么方式自定义 UAhey/0.0.1都会被拼在后面无法去掉。二、源码解读拼接逻辑只有短短几行先定位常量定义。在 hey.go 中hey 把自己的版本标识硬编码成了一个常量heyUA hey/0.0.1真正干活的是 hey.go 中的这段逻辑ua : header.Get(User-Agent) if ua { ua heyUA // 没设置 UA → 直接使用 hey/0.0.1 } else { ua heyUA // 设置了 UA → 你的 UA 空格 hey/0.0.1 } header.Set(User-Agent, ua) if *userAgent ! { // -U 参数优先级更高直接覆盖 ua *userAgent heyUA header.Set(User-Agent, ua) }可以看到整个过程就两条规则没设置 UA → 兜底为hey/0.0.1设置了 UA → 永远在末尾追加 hey/0.0.1之后这个 Header 被挂到请求上hey.go由 requester/requester.go 中的makeRequest逐次克隆并发送给服务器——所以每一条压测请求都带着这个签名。三、为什么要强制拼接 hey/0.0.1 这个设计看似不听话实际有三个合理动机压测流量可识别这是最核心的原因。服务器端可以通过 UA 中的hey/0.0.1一眼识别出这是压测流量而非真实用户便于在监控、告警、限流统计中将其排除避免压测数据污染线上指标。符合 UA 规范HTTP 标准允许 User-Agent 由多个产品标识组成如ProductA/1.0 ProductB/2.0。hey 把你的自定义 UA 放在前面、自己的签名放后面两者信息都得以保留是合规且礼貌的做法。默认兜底与文档一致使用-h查看帮助时会明确写着-U User-Agent, defaults to version hey/0.0.1见 hey.go行为与文档完全一致不设 UA 时也不会伪装成空白客户端。四、-U 与 -H 的隐藏交互谁说了算⚠️ 一个容易踩坑的细节-U和-H User-Agent: xxx都能设置 UA但同时使用时最终值由-U决定——因为它在后面执行会整体覆盖掉-H设置的值覆盖逻辑见 hey.go。另外注意README 的示例帮助文本中并没有列出-U参数见 README.md新手很容易忽略它的存在建议直接运行hey -h查看完整选项。五、实战建议针对压测场景的应对方法结合以上机制给出三条实用建议 ✅在监控中剔除压测流量过滤 UA 包含hey/0.0.1的请求即可安全地将压测数据从真实用户指标中分离。想伪装成浏览器绕过 WAF不要指望完全成功——末尾的hey/0.0.1会一直存在很可能成为风控识别压测/爬虫流量的线索之一。必须要纯净的 UAhey 做不到因为hey/0.0.1是写死的常量没有任何参数可以关闭它。如有此类强需求需要改用其他压测工具或自行修改源码。六、总结hey 无论通过-U还是-H设置 UA最终都会强制在末尾拼接hey/0.0.1这是刻意设计让压测流量可被服务端识别与过滤同时符合 UA 多产品标识规范该逻辑集中在 hey.go 几行代码中版本标识常量定义在 hey.go同时使用-U和-H User-Agent: ...时以-U为准【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考