代理IP访问乱码或长度不对？Content-Encoding与分块响应排查

通过代理IP访问接口或网页时，常见症状包括中文乱码、响应被截断、客户端提示 Content-Length 不匹配，或者同一个 URL 直连正常、代理访问异常。这类问题不一定是代理改变了正文，更常见的原因是压缩协商、分块传输和客户端解压的边界没有对齐。

先把“看到的文本”和“收到的字节”分开

在自有接口或已获授权的目标上，先保存响应头和原始响应，不要把包含账号、Cookie 或业务数据的内容上传到第三方：

curl -sS -D /tmp/headers.txt -o /tmp/body.bin   --proxy http://user:password@proxy.example:port   https://api.example.test/health
sed -n '1,60p' /tmp/headers.txt
file /tmp/body.bin

命令中的主机、凭据和路径都是占位符。重点记录 Content-Encoding、Content-Length、Transfer-Encoding、Vary 和响应状态。不要用文本编辑器直接打开可能经过压缩的二进制响应。

Content-Encoding和Transfer-Encoding不是一回事

Content-Encoding：描述正文是否经过 gzip、br 等内容压缩，解压后才是应用看到的正文。
Transfer-Encoding：描述消息如何在链路上传输，例如 HTTP/1.1 的 chunked 分块。
Content-Length：表示特定消息形态的长度；经过中间层解压或重新编码后，原长度不能继续沿用。

代理或网关如果解压了正文，却保留旧的 Content-Encoding: gzip，客户端就可能再次解压而报错；如果重新拼接了分块，却错误保留 Transfer-Encoding: chunked，也可能出现截断或协议错误。

用curl的自动解压做对照

curl -v --proxy http://user:password@proxy.example:port   --compressed https://api.example.test/health -o /tmp/decoded.txt
curl -v --proxy http://user:password@proxy.example:port   -H 'Accept-Encoding: identity' https://api.example.test/health -o /tmp/plain.txt

第一条让 curl 根据响应头处理常见压缩，第二条请求服务返回未压缩内容。两次测试必须固定 URL、请求方法、认证范围和代理节点；如果只有压缩版本异常，再检查代理链或网关是否修改了压缩头，而不是立即更换出口 IP。

检查客户端是否重复解压

很多 HTTP 库会自动处理 gzip 或 br。若业务代码又手动调用解压函数，就会出现“解压数据无效”；反过来，库被设置为不自动解压而代码直接按 UTF-8 读取压缩字节，也会显示乱码。记录客户端版本、自动解压开关和最终交给业务层的字节数，避免只看浏览器开发者工具。

定位代理链是否重写响应

在自己管理的代理或网关上，对比入口收到的响应头、出口转发的响应头和客户端最终看到的响应头。重点观察 Content-Encoding、Content-Length、Transfer-Encoding 是否成组变化。若代理只建立 CONNECT 隧道，通常不应重写隧道内的 HTTPS 正文；若存在 HTTP 明文转发、缓存或压缩模块，则要查对应配置和日志。