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 中转就是跑不满。大文件传输慢绝大多数情况不是玄学而是某个具体环节被卡住了——限速设置、并发上限、任务线程或者上游存储本身。先诊断再动手调参之前先搞清楚瓶颈在哪一步否则改完参数毫无变化还以为配置没生效。三个快速判断方法查限速设置。登录 AList 管理面板进入设置 → 流量分组看四个速度项客户端上传/下载速度、服务端上传/下载速度。默认值-1表示不限速一旦填了正数单位是 KiB/s大文件会被人为压速。很多人慢的根因就在这里。对比直链速度。从 AList 拿到某个文件的直链或直接用网盘 App 测速如果直链本身就只有 1MB/s瓶颈在上游存储改 AList 配置没用。看进程资源占用。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。批量操作慢的时候把相关任务加到 35{ tasks: { upload: { workers: 3 }, transfer: { workers: 3 } } }单个大文件不会因为线程多而变快但几十个文件的批量任务整体耗时会明显下降。把临时目录放到快的盘上避免磁盘拖后腿temp_dir是 AList 存放临时文件的位置internal/bootstrap/config.go启动时会创建并读取。如果它落在机械盘或快满的盘上涉及中转的传输离线下载、压缩上传会被磁盘 IO 拖慢。改成一个 SSD 上的独立目录即可。深入调优篇本地存储让 AList 和文件待在快的盘上存储目录直接放 SSDWebDAV 场景下 AList 只是流式转发读盘速度就是传输速度的上限⚠️ 常见误区把temp_dir和本地存储目录塞进同一个快满的容器卷空间耗尽后上传直接失败提前给临时目录留够余量。云盘类存储阿里云盘 / 115 / OneDrive 等瓶颈大多在上游服务端下载速度限制max_server_download_speed务必保持-1它卡的是 AList 从网盘拉数据的速率误设后大文件必慢直链加速依赖各驱动的实现可参考 README_cn.md 里各存储的说明优先用直链 CDN 的方式加速而不是硬堆并发⚠️ 网盘的会员速率上限是物理天花板AList 配置再优化也不会超过直链速度。部署侧容器与反代的配合Docker 部署可参考仓库里的 Dockerfile 和docker-compose.yml调整资源限制去掉过低的mem_limitNginx 反代转发大文件时proxy_read_timeout要放宽否则空闲一会儿连接就被掐断表现为传着传着断流开启 HTTP/2面板其他分组有enable_h2c相关选项可改善多连接下的吞吐稳定性。验证与持续监控用 5 步做一次前后对比数据说话选一个 1GB 左右的测试文件路径固定用curl -o /dev/null -w %{speed_download} url记录优化前的下载速度跑 3 次取平均只改一项配置重启或保存设置同一条命令再测 3 次记录差值决定是保留还是回滚。持续监控两个轻量手段就够docker stats或top盯 CPU/内存趋势以及config.json中log分组开启日志写文件出问题时按时间回溯。如果某项指标比如 CPU 空闲但速度慢优化后没改善回到先诊断一节重新定位——很可能瓶颈在上一节没覆盖的环节比如上游存储或反代。常见问题 / 避坑清单Q大文件传到一半断流重头开始先查反代超时和temp_dir剩余空间再查日志里是 408/502 还是连接 reset。前者改反代超时后者多为上游存储主动断开属于上游限流只能放缓速度或错峰。Q我明明没设置限速为什么还是慢确认面板流量分组四项都是-1。另外注意区分客户端限速管浏览器/客户端这一端服务端限速管 AList 与存储之间两端的瓶颈不是一回事。Qmax_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/8/31 13:01:01 · 阅读 1.2k AList 大文件传输提速完整指南：从瓶颈诊断到效果验证
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 中转就是跑不满。大文件传输慢绝大多数情况不是玄学而是某个具体环节被卡住了——限速设置、并发上限、任务线程或者上游存储本身。先诊断再动手调参之前先搞清楚瓶颈在哪一步否则改完参数毫无变化还以为配置没生效。三个快速判断方法查限速设置。登录 AList 管理面板进入设置 → 流量分组看四个速度项客户端上传/下载速度、服务端上传/下载速度。默认值-1表示不限速一旦填了正数单位是 KiB/s大文件会被人为压速。很多人慢的根因就在这里。对比直链速度。从 AList 拿到某个文件的直链或直接用网盘 App 测速如果直链本身就只有 1MB/s瓶颈在上游存储改 AList 配置没用。看进程资源占用。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。批量操作慢的时候把相关任务加到 35{ tasks: { upload: { workers: 3 }, transfer: { workers: 3 } } }单个大文件不会因为线程多而变快但几十个文件的批量任务整体耗时会明显下降。把临时目录放到快的盘上避免磁盘拖后腿temp_dir是 AList 存放临时文件的位置internal/bootstrap/config.go启动时会创建并读取。如果它落在机械盘或快满的盘上涉及中转的传输离线下载、压缩上传会被磁盘 IO 拖慢。改成一个 SSD 上的独立目录即可。深入调优篇本地存储让 AList 和文件待在快的盘上存储目录直接放 SSDWebDAV 场景下 AList 只是流式转发读盘速度就是传输速度的上限⚠️ 常见误区把temp_dir和本地存储目录塞进同一个快满的容器卷空间耗尽后上传直接失败提前给临时目录留够余量。云盘类存储阿里云盘 / 115 / OneDrive 等瓶颈大多在上游服务端下载速度限制max_server_download_speed务必保持-1它卡的是 AList 从网盘拉数据的速率误设后大文件必慢直链加速依赖各驱动的实现可参考 README_cn.md 里各存储的说明优先用直链 CDN 的方式加速而不是硬堆并发⚠️ 网盘的会员速率上限是物理天花板AList 配置再优化也不会超过直链速度。部署侧容器与反代的配合Docker 部署可参考仓库里的 Dockerfile 和docker-compose.yml调整资源限制去掉过低的mem_limitNginx 反代转发大文件时proxy_read_timeout要放宽否则空闲一会儿连接就被掐断表现为传着传着断流开启 HTTP/2面板其他分组有enable_h2c相关选项可改善多连接下的吞吐稳定性。验证与持续监控用 5 步做一次前后对比数据说话选一个 1GB 左右的测试文件路径固定用curl -o /dev/null -w %{speed_download} url记录优化前的下载速度跑 3 次取平均只改一项配置重启或保存设置同一条命令再测 3 次记录差值决定是保留还是回滚。持续监控两个轻量手段就够docker stats或top盯 CPU/内存趋势以及config.json中log分组开启日志写文件出问题时按时间回溯。如果某项指标比如 CPU 空闲但速度慢优化后没改善回到先诊断一节重新定位——很可能瓶颈在上一节没覆盖的环节比如上游存储或反代。常见问题 / 避坑清单Q大文件传到一半断流重头开始先查反代超时和temp_dir剩余空间再查日志里是 408/502 还是连接 reset。前者改反代超时后者多为上游存储主动断开属于上游限流只能放缓速度或错峰。Q我明明没设置限速为什么还是慢确认面板流量分组四项都是-1。另外注意区分客户端限速管浏览器/客户端这一端服务端限速管 AList 与存储之间两端的瓶颈不是一回事。Qmax_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考