背景
对于同一个文件,通过接口来获取二进制文件流的时候,线上部署环境是ok的,可以正常下载,但是本地的vite
proxy
代理 对于同一个文件展示不同的效果 会直接拒绝访问 报错信息为
js
(failed)
net::ERR_INVALID_HTTP_RESPONSE

解决办法 代理中增加二进制处理配置信息 configure
原理
Vite 增加代理配置之所以能解决二进制流的问题,核心原因在于代理服务器对二进制响应的处理方式。
问题根源:Vite 代理的默认行为与二进制流的冲突
Vite 的代理功能基于http-proxy
库实现,其默认配置会对响应做一些 "优化处理",比如:
-
自动添加或修改
Content-Length
响应头 -
可能对响应内容进行字符编码转换
-
处理分块传输(chunked)时的格式转换
这些处理对普通 JSON / 文本响应没问题,但对二进制流(如文件、图片、PDF 等) 会造成严重问题:
- 二进制数据被误当作文本处理导致编码错误
Content-Length
计算错误引发浏览器解析失败(ERR_INVALID_HTTP_RESPONSE
)- 二进制数据被截断或修改,导致文件损坏
配置生效的关键原因
js
configure: (proxy, options) => {
proxy.on('proxyRes', (proxyRes, req, res) => {
// 检测二进制流类型的响应
if (proxyRes.headers['content-type'] &&
(proxyRes.headers['content-type'].includes('application/octet-stream') ||
proxyRes.headers['content-type'].includes('application/pdf') ||
proxyRes.headers['content-type'].includes('image/'))) {
// 删除Content-Length头
delete proxyRes.headers['content-length'];
}
});
}
这段配置的作用是:
-
识别二进制响应 :通过
Content-Type
判断是否为二进制流(文件、图片等) -
移除
Content-Length
头:- 二进制流的长度计算非常严格,代理自动添加的
Content-Length
可能与实际内容长度不匹配 - 浏览器发现
Content-Length
与实际接收的字节数不符时,会判定为无效响应 - 删除该头后,浏览器会根据实际接收的数据流来处理,避免校验失败
- 二进制流的长度计算非常严格,代理自动添加的
额外说明
对于二进制流,正确的传输方式通常是:
-
使用
Transfer-Encoding: chunked
分块传输(无需Content-Length
) -
保持原始二进制编码(不做任何字符转换)
Vite 的默认代理配置没有针对二进制流做特殊处理,而我们的自定义配置正是修复了这个问题,让二进制数据能够原封不动地从后端传输到前端,从而与线上环境保持一致的行为。
有些文件可以成功,有些不可以的原因 文件大小触发不同传输模式
- 小文件 :后端可能使用
Content-Length
固定长度传输,且代理计算的长度恰好正确,因此能正常加载。 - 大文件 :后端通常使用
Transfer-Encoding: chunked
分块传输(不包含Content-Length
),但代理可能强行添加了错误的Content-Length
,导致浏览器接收时长度不匹配,直接报错。