企业官网建设流程全解析

AList 大文件传输提速完整指南：从瓶颈诊断到效果验证

【免费下载链接】alist🗂️A file list/WebDAV program that supports multiple storages, powered by Gin and Solidjs. / 一个支持多存储的文件列表/WebDAV程序，使用 Gin 和 Solidjs。项目地址: https://gitcode.com/GitHub_Trending/al/alist

用 AList 挂 WebDAV 给同事传一个 2GB 的视频，对方那边速度长期卡在 1MB/s；自己下载云盘里的备份包，传到一半中断，重头再来。更常见的是：明明带宽是千兆的，AList 中转就是跑不满。大文件传输慢，绝大多数情况不是玄学，而是某个具体环节被卡住了——限速设置、并发上限、任务线程，或者上游存储本身。

先诊断，再动手

调参之前先搞清楚瓶颈在哪一步，否则改完参数毫无变化，还以为配置没生效。三个快速判断方法：

1. 查限速设置。登录 AList 管理面板，进入"设置 → 流量"分组，看四个速度项：客户端上传/下载速度、服务端上传/下载速度。默认值-1表示不限速；一旦填了正数，单位是 KiB/s，大文件会被人为压速。很多人慢的根因就在这里。
2. 对比直链速度。从 AList 拿到某个文件的直链（或直接用网盘 App 测速），如果直链本身就只有 1MB/s，瓶颈在上游存储，改 AList 配置没用。
3. 看进程资源占用。Docker 部署执行docker stats -n 1，裸部署用top找 alist 进程。CPU 或内存长期贴顶，说明是机器扛不住；资源空闲但速度慢，说明在排队或等待——大概率是并发/限速问题。

快速见效篇

按改动成本从低到高排，每一项改完立即可测。

解除流量限速，恢复大文件全速传输

四个限速项基于令牌桶实现（internal/stream/limit.go里的RateLimitReader就是干这个的），一旦设置，每次读写都要按速率"扣令牌"。确认不需要限速后，把四项都改回-1，设置页保存即生效，无需重启。改完之后，之前被压到几百 KB 的传输速度会立刻回到带宽上限。

调高请求并发上限，减少排队等待

max_concurrency控制 AList 对上游存储的并发请求数，默认 64。多用户同时访问、或批量任务跑起来后，请求会在这里排队。在data/config.json中调整（改完重启服务）：

{ "max_concurrency": 128 // 仅展示核心配置 }

注意不是越大越好，超过上游网盘的承受能力会触发限流或 429 错误，建议 64 起按倍增加。

提高任务线程数，加速批量上传和转存

tasks配置里每类任务（下载、转存、上传、复制等）都有workers线程数，默认 1。批量操作慢的时候，把相关任务加到 3～5：

{ "tasks": { "upload": { "workers": 3 }, "transfer": { "workers": 3 } } }

单个大文件不会因为线程多而变快，但几十个文件的批量任务整体耗时会明显下降。

把临时目录放到快的盘上，避免磁盘拖后腿

temp_dir是 AList 存放临时文件的位置（internal/bootstrap/config.go启动时会创建并读取）。如果它落在机械盘或快满的盘上，涉及中转的传输（离线下载、压缩上传）会被磁盘 IO 拖慢。改成一个 SSD 上的独立目录即可。

深入调优篇

本地存储：让 AList 和文件待在快的盘上

• 存储目录直接放 SSD，WebDAV 场景下 AList 只是流式转发，读盘速度就是传输速度的上限；
• ⚠️ 常见误区：把temp_dir和本地存储目录塞进同一个快满的容器卷，空间耗尽后上传直接失败，提前给临时目录留够余量。

云盘类存储（阿里云盘 / 115 / OneDrive 等）：瓶颈大多在上游

• 服务端下载速度限制（max_server_download_speed）务必保持-1，它卡的是 AList 从网盘拉数据的速率，误设后大文件必慢；
• 直链加速依赖各驱动的实现，可参考 README_cn.md 里各存储的说明，优先用直链 + CDN 的方式加速，而不是硬堆并发；
• ⚠️ 网盘的会员速率上限是物理天花板，AList 配置再优化也不会超过直链速度。

部署侧：容器与反代的配合

• Docker 部署可参考仓库里的 Dockerfile 和docker-compose.yml调整资源限制，去掉过低的mem_limit；
• Nginx 反代转发大文件时，proxy_read_timeout要放宽，否则空闲一会儿连接就被掐断，表现为"传着传着断流"；
• 开启 HTTP/2（面板"其他"分组有enable_h2c相关选项）可改善多连接下的吞吐稳定性。

验证与持续监控

用 5 步做一次前后对比，数据说话：

1. 选一个 1GB 左右的测试文件，路径固定；
2. 用curl -o /dev/null -w "%{speed_download}" <url>记录优化前的下载速度，跑 3 次取平均；
3. 只改一项配置，重启或保存设置；
4. 同一条命令再测 3 次；
5. 记录差值，决定是保留还是回滚。

持续监控两个轻量手段就够：docker stats（或top）盯 CPU/内存趋势，以及config.json中log分组开启日志写文件，出问题时按时间回溯。如果某项指标（比如 CPU 空闲但速度慢）优化后没改善，回到"先诊断"一节重新定位——很可能瓶颈在上一节没覆盖的环节，比如上游存储或反代。

常见问题 / 避坑清单

Q：大文件传到一半断流，重头开始？先查反代超时和temp_dir剩余空间；再查日志里是 408/502 还是连接 reset。前者改反代超时，后者多为上游存储主动断开，属于上游限流，只能放缓速度或错峰。

Q：我明明没设置限速，为什么还是慢？确认面板"流量"分组四项都是-1。另外注意区分：客户端限速管浏览器/客户端这一端，服务端限速管 AList 与存储之间，两端的瓶颈不是一回事。

Q：max_concurrency调到 1024 不行吗？不建议。上游网盘普遍有并发限制，调太高会换来批量 429 和封禁风险。64→128→256 逐步加，以"不出现限流错误"为界。

Q：改了 config.json 没生效？config.json里的项需要重启进程；面板"设置"页的项大多热更新。两边别混着改，以重启后config.json的实际内容为准。

Q：本地存储的 AList 为什么比直接挂载还慢？检查是否开启了不必要的限速、反代是否走了压缩/缓冲。AList 的 local 驱动是流式转发，正常情况应与直读盘速度接近，差太多就是配置问题。

收尾

一句话总结：AList 大文件提速的正确姿势是"先测直链定位瓶颈，再按限速 → 并发 → 线程的顺序逐项调，最后用前后对比验证"。更完整的配置项说明可查阅 README_cn.md，有想法也欢迎参考 CONTRIBUTING.md 参与项目改进。欢迎在评论区贴出你的前后对比数据，一起看看还有哪些坑。

【免费下载链接】alist🗂️A file list/WebDAV program that supports multiple storages, powered by Gin and Solidjs. / 一个支持多存储的文件列表/WebDAV程序，使用 Gin 和 Solidjs。项目地址: https://gitcode.com/GitHub_Trending/al/alist