很多人以为请求发出去就会原样到达服务端，其实每一跳都在核对长度。请求体多一个字节、少一个字节，头里的长度声明对不上，请求就可能被拦在半路，客户端只看到一句 400 报错，根本不知道是长度出了问题。
术语一：Content-Length
Content-Length 是请求头或响应头里的一个字段，用来声明消息体的字节数。它的作用是在传输开始前告诉对方”这包数据有多长”，让对方知道读到哪个字节算结束。日常请求里这个字段由发送方自动计算，很少需要手工干预，但它一旦和实际数据对不上，接收方就有理由直接拒绝。
术语二：分块传输
分块传输用 Transfer-Encoding: chunked 标识，不提前声明总长度，而是把数据切成一块一块，每块前面带上自己的长度。它适合流式输出、动态生成这类无法提前知道总长的内容。分块传输的存在，让”长度”这个概念从一整个数字，变成了一串小数字。
术语三：头尾不一致
头尾不一致指长度声明与实际数据不符，或 Content-Length 与 Transfer-Encoding 同时出现。协议规定后者优先，但很多实现并不规范，不同服务器处理方式也不一样。代理作为中间一跳，如果发现头部声明对不上实际流转的数据，通常会直接返回错误，而不是帮你修正。
代理在这一环做什么
转发型代理一般原样透传请求头和请求体，不主动改动长度。但两类情况会让代理介入：一是连接被复用，代理需要依据长度判断一个请求在哪结束、下一个从哪开始，长度错位会直接拖垮后续请求；二是内容被改写，比如缓存或压缩，改写后长度必须重新计算，漏算就出错。所以长度问题虽然源头常在客户端或服务端，代理链路却往往是第一个暴露问题的地方。
遇到莫名其妙的 400 报错，按下面四条排一遍，多数长度问题都能定位：
- 抓一份原始请求，核对 Content-Length 与实际请求体字节数是否一致
- 确认请求头里没有同时出现 Content-Length 和 Transfer-Encoding
- 关掉中间改写功能（缓存、压缩、重写头）再试一次，看是否恢复
- 换直连对照，如果直连正常而走代理报错，问题就在链路中间
长度声明是协议里最不起眼的字段，却掌管着每一次传输的边界。代理IP的使用也一样——出口只是其中一环，真正的稳定性藏在每一跳的细节里。
一次请求能顺利到达，靠的不是运气，而是每一跳都把边界核对清楚。