HTTP/2 与请求走私：为什么前端看不到

同一个请求，前端只看到一条，后端却解析出两条。原因不在加密，也不在抓包工具——两套解析器对"请求到哪结束"判断不一致。

现象：前端一条，后端两条

前端（指前置代理/边缘节点，不是浏览器）抓包、重放、看响应都正常，可后端日志里多出一条记录，或者响应串到了别人的请求上。前端复现不了，因为边界是在它之后被重新划的。

前端看到的是自己发出的一条，后端看到的是自己解析出的两条。 中间那层重新划过边界，前端自然对不上。

HTTP/2 是二进制帧：一条流由 HEADERS 帧和若干 DATA 帧组成，body 到哪结束由帧长度和 END_STREAM 决定，不靠头里的数字。

HTTP/1.1 是文本行加头部：body 长度由 Content-Length 或 chunked 编码决定。

边缘节点终结 H2、回源用 H1.1，就必须做一次"翻译"：把帧重组成报文，把伪首部 :method、:path、:authority 转成请求行与 Host，并决定用 Content-Length 还是 chunked 把 body 边界告诉后端。

翻译就是产生歧义的地方：帧边界是事实，Content-Length 或 chunk 边界是翻译器重新写出来的。写的时候用帧的实际长度，还是用客户端声明的值——这一步决定了后端读到哪里停。

H2 规范本身禁止连接级头：Transfer-Encoding 在 H2 里根本不该出现；TE 头只允许 trailers 这一个值。规范拦得住"正常客户端"，拦不住"翻译器转发时不校验"。

H1.1 有两套定长机制，取哪一套就是边界。

TEXT

# 抽象示意，只描述冲突结构，不可直接用于攻击
Content-Length: <声明值>
Transfer-Encoding: chunked

规范的处理顺序是：两者同时出现，按 TE 读，并视作可疑请求。问题在于规范的顺序不等于实现的顺序。

组合	前端按什么切	后端按什么切	剩下的字节
CL.TE	按 `Content-Length`	按 chunked	被后端当成下一条请求的开头
TE.CL	按 chunked	按 `Content-Length`	同上
H2 降级	按帧长度	按翻译出的 CL/TE	同上

三种组合的共同点：两边都读到了"合法"的边界，只是不是同一条边界。 剩下那段字节不会消失，它成为下一个请求的前缀——这就是为什么后端会多出一条记录。

排查顺序按"是否降级、是否多级代理、后端是否宽容"三步走。**先确认有没有 H2→H1.1 这一跳。**没有降级，链路就少一半。

统一解析器：边缘与源站用同一套实现、同一严格模式。混用厂商栈是最常见的根因。
拒绝歧义请求：同时出现 CL 与 TE 直接 400；多个 CL 值不一致 400；CL 与实际 body 长度不一致 400；H2 里出现 Transfer-Encoding 直接拒，TE 非 trailers 也拒。
禁用不必要降级：内部链路固定一种协议版本；必须降级时，翻译器只用帧长度生成 CL，丢弃客户端声明的值。
日志比对：同一 request id 在边缘和源站各留一条，比对头集合与 body 长度。不一致就是信号，不用等出事。

BASH

# 看协商到的是 H2 还是降级，以及响应头集合
curl --http2 -v 127.0.0.1
# 同一 URL 的 H1.1 对照
curl -v 127.0.0.1
# 网关日志里按 request id 找两行，核对长度与头
grep 1234 /var/log/gateway.log

H1.1 那条是基线：同一请求在两种协议下头集合不同，差异处就是翻译器动手的地方。

链路视角见攻击链路；解析器实现差异见组件解析；抓包与日志工具怎么用见工具底层。

走私是边界理解不一致，不是加密问题。 TLS 保证的是它覆盖的那一段传输没被改，不保证两个解析器对同一串字节得出同一个结论。

本文仅用于安全学习与授权环境下的测试。文中所有示例均为本地或授权靶场环境，不构成对任何真实系统的测试指引。

仅限授权测试，严禁非法滥用。