服务器断点续传配置：大文件传输失败不用愁，这几招让你稳如老狗

别让99%的进度毁了你的一天

你肯定遇到过这种糟心事。好不容易下载一个几个G的安装包，或者上传一个超大的视频素材。进度条眼瞅着跑到99%了，突然网抖了一下，或者浏览器崩了。结果呢？一切归零，从头再来。那一刻，是不是想把电脑砸了？

其实，这事儿真不怪网速，多半是你的服务器没配好。今天我就跟你聊聊服务器断点续传配置。这技术说白了，就是给传输过程加个“书签”。断了没关系，下次接着来。搞懂这个，不管是下载还是上传，都能稳如老狗。下面这几招，都是实打实的干货，照着做就能解决问题。

1. 先搞懂原理，别瞎折腾

在动手改配置之前，你得先明白这东西是怎么工作的。别一上来就复制粘贴代码，出了错都不知道找谁。

什么是Range请求？

断点续传的核心，就是HTTP协议里的一个头信息，叫Range。说白了，就是客户端跟服务器打招呼的方式变了。

以前下载文件，客户端说：“老兄，把那个文件给我。”服务器就把整个文件发过来。

有了断点续传，客户端会说：“老兄，我只要这个文件的第100字节到第200字节，前面的我都有了。”服务器一看，懂了，就只发这一小截数据。这就是断点续传的秘密。

服务器怎么响应？

如果服务器支持断点续传，它不会回普通的200 OK。它会回一个状态码，叫206 Partial Content。看到这个206，客户端就知道：“妥了，这服务器懂事，我接着往下存。”

所以，你配置服务器，其实就是教服务器怎么听懂Range，然后怎么正确地回206。

2. Nginx静态文件配置（最常用）

大部分网站服务器都用Nginx。好消息是，Nginx这玩意儿挺智能，它默认就支持断点续传。但默认的配置有时候不够用，特别是你用了反向代理或者做了特殊优化的时候，容易翻车。

第一步：检查默认模块

一般来说，你不需要额外装模块。只要你的Nginx是正规渠道编译安装的，ngx_http_core_module里就带了这功能。你只要别手贱去屏蔽它就行。

怎么验证？不用写代码，用个命令行工具curl就能测。

```bash curl -I -r 0-1023 http://你的域名/test.zip ```

这命令的意思是：只请求文件的前1024个字节。如果返回头里包含HTTP/1.1 206 Partial Content，那就说明你的Nginx已经支持了，不用操心。

第二步：反向代理的坑

很多同学配了Nginx做反向代理，转发给后端的Node.js或者Java。这时候，断点续传往往就失效了。为啥？因为Nginx把Range这个头给“吃”了，没传给后端。

你得在Nginx配置里加这一行：

```nginx proxy_pass http://127.0.0.1:8080; proxy_set_header Range $http_range; proxy_set_header If-Range $http_if_range; ```

加上这两行，Nginx就会乖乖地把客户端的断点请求转发给后端。这地方特别容易踩坑，一定要记下来。

第三步：优化大文件传输

虽然能续传了，但如果文件特别大，传输效率低也不行。你得把Nginx的“零拷贝”技术打开。这能减少CPU拷贝数据的次数，速度飞起。

在http块或者server块里加上：

```nginx sendfile on; tcp_nopush on; ```

sendfile就是让操作系统直接发文件，不经过应用程序内存。tcp_nopush则是优化数据包的发送，减少网络抖动。这两个参数配合断点续传，才是最佳拍档。

3. 代码层面的动态续传（Node.js实战）

有时候，你的文件不是静态放在磁盘上的，可能是动态生成的，或者需要鉴权才能下载。这时候Nginx帮不了你，得自己在代码里实现。我用最流行的Node.js给你举个例子，逻辑都是通的。

解析Range头

客户端发来的Range长这样：bytes=0-1023。你得写个函数，把它拆开，算出从哪读，读到哪。

设置响应头

这是最关键的一步。你必须老老实实地把这几个头写回去，少一个都不行。

• Content-Range: 告诉客户端你发的是哪一段，格式是bytes start-end/total。
• Accept-Ranges: 告诉客户端“我支持断点续传”，值一般写bytes。
• Content-Length: 注意，这里是本次发送的长度，不是文件总长度！

看个具体的代码片段，你就懂了：

```javascript const fs = require('fs'); const path = '你的大文件路径'; app.get('/download', (req, res) => { const stat = fs.statSync(path); const fileSize = stat.size; const range = req.headers.range; if (range) { // 有range头，说明是断点续传 const parts = range.replace(/bytes=/, "").split("-"); const start = parseInt(parts[0], 10); const end = parts[1] ? parseInt(parts[1], 10) : fileSize - 1; const chunksize = (end - start) + 1; const file = fs.createReadStream(path, { start, end }); const head = { 'Content-Range': `bytes ${start}-${end}/${fileSize}`, 'Accept-Ranges': 'bytes', 'Content-Length': chunksize, 'Content-Type': 'video/mp4', }; // 必须写206，不能写200 res.writeHead(206, head); file.pipe(res); } else { // 没有range头，正常下载 const head = { 'Content-Length': fileSize, 'Content-Type': 'video/mp4', }; res.writeHead(200, head); fs.createReadStream(path).pipe(res); } }); ```

这段代码你可以直接拿去改。注意看那个res.writeHead(206)，要是你手滑写成200，客户端就会以为这是新文件，把之前下载的覆盖掉，那就白忙活了。

4. 大文件上传续传（分片上传）

下载好搞，上传续传稍微复杂点。因为HTTP协议里没有现成的“上传断点”指令。现在的做法，基本都是分片上传。

前端怎么切？

前端不是把整个大文件一口气发过来。它把大文件切成很多小块，比如每块5MB。然后一块一块地发。

如果发到第10块断了，前端会记录：“嘿，第10块没发完”。下次用户点“重试”，前端就从第10块开始发。

后端怎么收？

服务器端要做三件事。

第一，存分片。收到一个分片，别急着往最终文件里写。先把它存到一个临时目录里。文件名可以用“原文件名_分片索引”来命名，比如video.mp4_1、video.mp4_2。

第二，校验完整性。前端发完所有分片后，会给服务器发个信号：“我发完了”。服务器这时候去数一下，分片数量对不对。如果文件总共100MB，切成5MB一块，应该有20块。如果只有19块，就告诉前端：“少了一块，重发”。

第三，合并文件。所有分片都齐了，就用代码把它们按顺序拼起来，生成最终的大文件。把临时分片删了，别把服务器硬盘撑爆了。

避坑提醒：并发控制

这里有个大坑。前端别为了快，一次性并发上传100个分片。服务器瞬间接收100个并发写入，IO直接飙满，容易卡死甚至崩溃。

建议前端控制一下并发数，比如用async-pool这种库，同时只传3个或者5个分片。传完一个再补一个。这样服务器压力小，传输也更稳。

赶紧去检查你的服务器

说了这么多，核心就两点。下载续传，主要靠Nginx或者代码里的206状态码；上传续传，主要靠分片和合并逻辑。

别光看着爽，赶紧去自己的服务器上测一下。拿个几十MB的测试文件，下到一半拔网线，再点继续。看能不能接着下。如果能，恭喜你，稳了。如果不能，照着我上面的步骤查查配置。

搞定这个，用户下载你网站上的大资源时，体验绝对提升一个档次。毕竟，没人愿意在99%的地方等死。动手吧！