Go Server.MaxHeaderValueCount 怎么挡住重复请求头：限制粒度与兼容检查

网关前面出现一批重复的 Cookie 或自定义请求头时，服务端真正需要回答的不是“请求头总共多大”，而是“同一个字段被拆成了多少个值”。Go 1.27 在 net/http.Server 中增加了 MaxHeaderValueCount，可以把这个边界交给 HTTP 服务端处理；但它只限制单个字段的值数量，不能替代总头部大小、字段名校验或代理层规则。

把 MaxHeaderValueCount 设成一个经过业务回归的正数，再用直连、反向代理和网关三条路径验证；不要把零理解成“关闭限制”。

先确认 MaxHeaderValueCount 约束的是单个字段的值数量

HTTP 允许同名字段出现多次，Go 会把它们表示为一个字段对应的多个值。例如三行 X-Trace-Flag 不是三个不同字段，而是同一个字段的三个值。MaxHeaderValueCount 针对的正是这个数量，和单个值的长度、请求头总字节数是三条不同的限制线。

读源码或查文档时，可以把这一节拆成五个实体：请求头输入、HeaderValues、MaxHeaderValueCount、默认上限、请求拒绝。图中用“请求边界”和“服务端策略”两组框表示它们的关系：输入先形成字段值集合，再由服务端策略决定是否继续交给处理器。

因此，调大这个字段并不能让超长的单个 Cookie 自动合法，也不能解除代理对总请求头大小的限制。排查时先打印字段名和值数量，再分别看长度和总量，结论会比只看“请求头太多”准确。

再用默认值与自定义值区分兼容边界

Go 1.27 的 Server 提供 MaxHeaderValueCount，未设置时由 DefaultMaxHeaderValueCount 提供默认策略。项目代码应明确写出选择理由：如果业务依赖少量重复头，正数上限要覆盖真实协议；如果服务只接受单值字段，也应先盘点框架、代理和客户端的合并方式。

可以把配置状态记录成一张小表，评审时不要只看字段有没有出现：

这节图中的五个实体是 Server配置、DefaultMaxHeaderValueCount、业务上限、代理重复头、响应状态。它们分成“默认行为”和“兼容检查”两组：配置先决定上限，代理带来的重复值再决定是否触发响应边界。

把拒绝路径接到服务日志与客户端检查

超限不是一个适合静默吞掉的结果。客户端侧应记录状态码、目标服务和请求是否经过代理；服务端侧记录字段名的脱敏版本、值数量和请求入口，不要把完整的 Cookie 或授权值写进日志。这样才能区分“单字段值过多”和“整个头部超过字节限制”。

测试用例至少覆盖三种输入：一个普通单值字段、两个合法重复值、超过上限的重复值。验证点不是只看连接有没有断，而是确认客户端获得稳定的错误分类，服务端没有进入业务处理器，代理也没有把多个值偷偷折叠成一个值。

最后做代理链回归而不是只看单次请求

同一条请求从直连服务、反向代理到正式网关，可能经历不同的头部合并规则。回归表可以只保留三列：入口路径、重复字段数量、最终可见结果。若直连被拒绝而代理路径成功，先检查代理是否合并了字段；若两条路径都被拒绝，再确认业务是否真的需要多值表达。

实践中不要为了绕过一次兼容问题把上限设得很大。更稳的处理是：先为协议允许的字段单独做白名单，再给服务设置一个有余量但可解释的正数；上线后观察拒绝计数和客户端错误分类，只有证据显示误伤才调整。

常见问题

MaxHeaderValueCount 限制的是请求头总数吗？

不是。它关注单个字段拥有的多个值；总头部大小、单个字段长度和字段总数仍需用其他配置或代理规则控制。

把字段设置为零是不是就不限制？

不能凭经验这样判断。零的含义要以当前 Go 版本文档和回归结果为准，配置评审中应把它当成需要验证的边界值。

代理已经合并重复头，还要测服务端吗？

要测。代理配置会变化，服务端仍应对直连和绕过代理的请求保持可解释的边界，并在日志中留下不泄露敏感值的诊断信息。

把“字段值数量”“默认上限”“代理合并”和“客户端结果”分开验证，MaxHeaderValueCount 才会成为可维护的服务约束，而不是一个遇到 431 才临时调大的参数。