Requests 响应在代理后面看起来乱码？检查 Brotli 支持
手工复制的 Accept-Encoding:br 可能超出托管 Requests 环境的解码器支持范围。
从两个不同层面比较本机与托管进程：
| 层面 | 问题 |
|---|---|
| Content-Encoding | 客户端能否解压返回的 gzip/deflate/Brotli 字节？ |
| Charset | 解压后的字节如何变成文本？ |
Requests 通常处理 gzip/deflate；Brotli 需要安装并受支持的库。手工复制的 Accept-Encoding 可能声明了 br，而该环境无法解码。选择 UTF-8 文本并不会解压 Brotli。
当有意限制协商时：
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()使用现有的 Session、HTTPS URL 以及所需的请求头/认证。比较两台机器上发出的 Accept-Encoding、收到的 Content-Encoding 与包支持情况；进行转换的中间设备也可能提供过期的元数据。单独的公开页面比较可在允许公共中间商的地方使用 HTTP 代理列表 获取其代理 URL，但不得带入继承的代理凭据、复制的账号请求头或私有正文数据。
其他情况下优先使用正常的客户端协商。Requests 便捷的 content/text 接口会解码受支持的编码，所以不要仅因请求头写了名字就再次解压它们的输出。