Ubuntu 下载速度慢？多线程加速与换源实操指南

Ubuntu 下下载文件慢，这事儿几乎每个人都遇到过。明明家里带宽几百兆，wget 一个几十 MB 的包却跑出几 KB/s 的速度，真能急死人。这个问题多半不是网不行，而是 Ubuntu 默认的下载方式太“老实”——单线程、没断点续传、还偏爱海外源。我花了不少时间折腾过各种提速方案，从换源到多线程下载器再到各种图形化工具，今天把这几年踩过的坑和验证过的方法一次说清楚，不同水平的用户都能在里面找到适合自己的那套方案。

这篇文章覆盖了从命令行工具加速、下载管理器选型、apt/pip/docker 换源到实战案例解析的完整链路，适合被下载速度折磨过的 Ubuntu 用户、刚入坑 Linux 的小白，以及想在服务器上批量拉取大文件的运维朋友。跟着步骤走，大部分场景下能把下载速度提升几倍甚至几十倍。

1. 下载速度瓶颈的本质与提速思路

1.1 为什么 Ubuntu 下载文件这么慢

很多人以为下载慢是宽带不够，其实真相往往出在下面几个环节：

第一，远程服务器的连接限制。 大部分 HTTP 服务器和 CDN 对单个连接都会做限速，比如某些软件源单连接限速 1MB/s。wget 默认只开一个连接，再大的带宽也跑不满。此外服务器所在的地理位置也起决定性作用，访问存放在海外的数据源时，跨洋链路的延迟和丢包都会严重拉低吞吐量。

第二，域名解析和连接协商开销。 每次请求都要进行 DNS 解析、TCP 握手、TLS 加密协商，这些步骤占用的时间在小文件下载中显得尤其明显。如果 DNS 解析本身还要经过层层转发，光是“找到服务器”这一步就能拖上好几秒。

第三，软件源的选择。 Ubuntu 默认配置的 apt 源是官方源，虽然在全球有 CDN 节点，但在某些网络环境下，默认节点并不一定离你最近，或者该节点负载很高。系统更新时 apt 又需要下载大量小文件，每个文件都要建立新的连接，速度感自然就上来了。

第四，下载工具本身的机制。 wget、curl 这类命令行工具默认不开启多线程，它们面向的是“可靠、简单、脚本友好”，而不是“最快”。如果你不做任何参数调整，它们就只会老老实实一个连接跑到底。

1.2 对症下药的提速方法论

搞清楚瓶颈之后，提速的思路就清晰了。我自己给所有下载场景归纳成四类处理方式，基本上覆盖了绝大多数需求：

第一类：换源头。 这是性价比最高的操作。把 apt、pip、npm 的默认源换成响应更快的镜像源，能把每次请求的延迟从几百毫秒降到几十毫秒。下载 Ubuntu ISO、大型开源软件时，也优先找离自己近的镜像站。

第二类：加并发。 用 aria2 这类支持多线程下载的工具，把一个大文件拆成多个分片同时拉取，每个连接各自有独立的限速，整体速度就叠加上去了。简单算笔账：如果服务器单连接限速 1MB/s，开 16 个线程理论上就能到 16MB/s，前提是你的带宽和对方服务器扛得住。

第三类：断点续传与连接复用。 下载大文件最怕中途断掉，断开后又要从头来。支持断点续传的下载器会把已完成的部分保留下来，重连时只拉剩余数据。对于几个 GB 的 ISO 镜像，这个能力能救命。

第四类：图形化下载管理器。 如果你不习惯命令行，或者经常要批量下载几十个文件，uGet、XDM 这类图形工具还提供了队列管理、并行下载、浏览器集成等功能，体验上更接近 Windows 上的 IDM。

code复制下载慢 ≠ 网速慢，本质是“可用带宽没有被充分使用”。

1.3 主流下载工具选型对比

我平时在 Ubuntu 上常用的下载工具有这么几个，各有分工，看场景选用：

2. 命令行工具加速：从 wget 到 aria2 的完整进阶

2.1 wget 和 curl 的正确打开方式

先说说大多数人最常用的 wget。它确实不支持多线程，但有几个参数能让下载过程“不那么难受”。

最常见的是断点续传参数 -c：

bash复制wget -c https://example.com/large-file.iso

如果下载过程中断，加上 -c 可以接着上次的地方继续下载，不需要从头开始。这个参数在实际使用中非常管用，尤其是下载大文件时网络经常抖动。

另一个有用的参数是 --tries 指定重试次数，配合 --timeout 设置超时时间，避免网络卡住后无限等待：

bash复制wget -c --tries=5 --timeout=30 https://example.com/large-file.iso

curl 平时更多被我用来下载小文件或调试接口，它的断点续传参数是 -C -：

bash复制curl -C - -O https://example.com/large-file.iso

但坦白说，wget 和 curl 在下载大文件这件事上都有点“先天不足”，单线程上限卡死了上限。如果你的速度瓶颈来自服务器单连接限速，那再怎么调参数都没用，得上真正支持多线程的工具。

注意：wget 的 -c 只在服务器支持 Range 请求时才有效。如果服务器不支持断点续传，-c 并不会报错，但会重新下载整个文件。

2.2 aria2 安装与配置详解

aria2 是我目前最倚重的下载利器，支持多线程、断点续传、磁力链、Metalink，而且 -x、-s、-k 这三个参数基本能应对所有下载需求。Ubuntu 下安装非常简单：

bash复制sudo apt update
sudo apt install aria2 -y

装好后，最基础的多线程下载命令长这样：

bash复制aria2c -x 16 -s 16 -k 1M 下载地址

拆开看每个参数的含义：

• -x 16：对同一个服务器最多开启 16 个连接。
• -s 16：将文件拆成 16 个分片，每个分片由不同连接下载。
• -k 1M：每个分片的大小为 1MB。超过这个大小后，aria2 会继续拆分新的分片。

为什么这两个参数都要设成 16？从实际经验来讲，16 是一个比较稳妥的数值。-x 和 -s 哪个更关键取决于服务器限制的是连接数还是分片数，两个都设置可以最大程度保证并发能力。但不要盲目调到 64 甚至 128，连接数太多会触发服务器的防护机制，反而被断开。

-k 1M 这个参数容易被忽略，但它的作用非常大。假设文件是 200MB，分片大小是 1MB，aria2 就会生成 200 个分片任务。下载过程中，某个分片如果失败或超时，aria2 只会重新下载那 1MB，不会浪费已经完成的其他分片。分片太小会导致调度开销变大，分片太大会让断点续传时重下的区域变大，1MB 是我验证下来最平衡的取值。

顺手把常用的几个参数也列一下：

bash复制aria2c -x 16 -s 16 -k 1M -c -o myfile.iso 下载地址

• -c：断点续传，所有多线程下载器都建议开启。
• -o：指定输出文件名，避免保存成一串看不懂的乱码。

如果你要一次下载多个文件，把下载地址写到文本文件里，按行分隔，然后通过 -i 指定：

bash复制aria2c -x 8 -s 8 -k 1M -i urls.txt

这样 aria2 会并行处理多个任务，每个任务内部又分多个线程，下载效率比一条一条 wget 高太多了。

2.3 充分利用 aria2 的配置文件

除了命令行参数，aria2 还支持配置文件，适合长期使用的场景。在 ~/.aria2/aria2.conf 写一份通用配置：

code复制# 基础下载参数
continue=true
max-concurrent-downloads=5
split=16
max-connection-per-server=16
min-split-size=1M
file-allocation=falloc

# 日志与错误处理
log-level=warn
max-tries=5
retry-wait=3
timeout=60
connect-timeout=30

配置文件写好后，启动时指定配置即可：

bash复制aria2c --conf-path=/home/用户名/.aria2/aria2.conf 下载地址

这里面 file-allocation=falloc 值得一提。它让 aria2 在下载前就预先分配好文件空间，避免磁盘碎片。对于大文件下载，预分配也可以用一种“占坑”的方式确认磁盘空间足够，免得下载到一半才发现磁盘满了。

2.4 下载大文件时的额外技巧

几个 GB 的文件下载时间很长，需要额外考虑三件事：

磁盘空间要提前确认。 下载前先看目标磁盘剩余空间：

bash复制df -h 下载目录

下载完成后校验文件完整性。 很多镜像站会提供 MD5、SHA256 校验值。下载完成后用 md5sum 或 sha256sum 校验：

bash复制sha256sum ubuntu-22.04.iso

把命令输出的哈希值和官方提供的比对，能确认文件在下载过程中没有损坏。

用 Screen 或 Tmux 保持会话。 如果在 SSH 会话中下载大文件，突然断开会话会导致下载中断。用 screen 或 tmux 让下载进程在后台运行：

bash复制sudo apt install tmux -y
tmux
aria2c -x 16 -s 16 -k 1M 下载地址
# 按下 Ctrl+B，再按 D 退出会话

这样即使断开 SSH，下载也会继续跑，重新连接后 tmux attach 就能回到下载界面。

3. 图形化下载管理器：不想敲命令的舒坦方案

3.1 uGet 与 aria2 的组合拳

如果你不太习惯命令行，或者你要下载的文件比较多但需求不复杂，uGet 是很好的选择。它本身不带多线程下载能力，但通过调用 aria2 来实现并发加速。安装方式：

bash复制sudo apt install uget aria2 -y

打开 uGet 后，在“编辑 - 设置 - 插件”里把默认插件改成 aria2，然后在“设置 - 插件”标签页里确认 aria2 的可执行路径正确（一般是 /usr/bin/aria2c）。配置完成后，uGet 就会把每个下载任务交给 aria2 处理，天然获得多线程加速能力。

uGet 的队列管理能力适合批量场景：把几十个下载地址一次性粘贴进去，设置同时处理 3 到 5 个任务，每个任务 16 线程，剩下的事情它会自己排队处理。这个功能在下载整套依赖包或离线文档时非常顺手。

3.2 XDM 与其他工具的选择

XDM（Xtreme Download Manager）是另一款表现不错的下载管理器，界面类似 Windows 的 IDM，首次启动时会提示安装浏览器插件。安装后，在 Firefox 或 Chrome 里点击下载链接时，浏览器会把下载任务交给 XDM，由它接管进行多线程拉取。

XDM 的优势在于浏览器接管能力强，尤其适合下载网页中嵌入的视频。不过它的资源占用比 uGet 高一些，下载超大文件时内存增长明显，机器配置一般的话劝退。

FlareGet 也有自己的特点，界面更加现代化，还支持从网页抓取批量资源。但在我这几年的实测中，它的稳定性稍逊于 uGet，偶尔会出现假死现象，如果你不追求花哨界面可以考虑。

3.3 浏览器内部下载加速

很多时候我们只是要在浏览器里下载一个不大不小的文件，这时候装个浏览器扩展就够了。Firefox 和 Chrome 上都有 DownThemAll 这类扩展，它可以自动嗅探页面里的下载链接，并支持多线程下载。日常下载几十到几百 MB 的文件，它的加速效果立竿见影。

不过浏览器扩展再方便，也无法和 aria2 这类专用工具比拼极限速度，它的意义在于“不用离开浏览器就能享受多线程”的便利。

提示：如果你在浏览器里下载的文件超过 1GB，建议还是交给 uGet 或 aria2。浏览器自身的下载管理在断点续传和内存管理上不如专业工具可靠，下载到 90% 突然断掉又得重来的体验，谁试谁知道。

4. 从源头加速：软件源与镜像站的正确选择

4.1 apt 软件源更换教程

apt 下载慢的最常见原因是默认源距离远。把软件源换成镜像源是立竿见影的操作。Ubuntu 22.04 及更新版本使用 sources.list 配置文件，路径在 /etc/apt/sources.list，同时 /etc/apt/sources.list.d/ 目录下可能还有第三方源。

更换前先备份：

bash复制sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

然后编辑文件：

bash复制sudo nano /etc/apt/sources.list

Ubuntu 22.04 的原始内容大致是：

code复制deb http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ jammy-security main restricted universe multiverse

你需要把 archive.ubuntu.com 和 security.ubuntu.com 替换成镜像源地址。以阿里云镜像为例：

code复制deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse

保存退出后执行：

bash复制sudo apt update

apt update 会重新读取软件源列表，这个过程就能直观感受到新源的速度差异。镜像源的选择原则是：你所在网络的同一运营商网络内访问最快的站点。如果不知道选哪个，阿里云、清华、中科大这几个是社区验证过稳定性最好的选择。

4.2 pip、npm 与 docker 加速

Python 开发常用的 pip 默认源在海外，安装大包如 PyTorch、TensorFlow 时速度感人。换源方法是在用户目录下创建 ~/.pip/pip.conf：

ini复制[global]
index-url = https://mirrors.aliyun.com/pypi/simple/
trusted-host = mirrors.aliyun.com

如果临时用一次，也可以命令行指定：

bash复制pip install torch --index-url https://mirrors.aliyun.com/pypi/simple/

npm 也有同样的问题，改 registry 地址即可：

bash复制npm config set registry https://registry.npmmirror.com

docker 镜像加速器的配置需要在 /etc/docker/daemon.json 添加 registry-mirrors。修改完成后重启 docker 服务：

bash复制sudo systemctl restart docker

code复制一个容易忽略的小问题：apt 换源后如果报错 “Certificate is not yet valid”，多半是镜像站服务器时间不同步或本地时间不准。先执行 `sudo date -s 当前时间` 或开启时间同步服务，再 `apt update` 就正常了。

4.3 手动下载时优先选择镜像站

除了包管理器的源，手动下载系统镜像或大型软件时也应该养成就近选择镜像站的习惯。

以 Ubuntu 官方 ISO 为例，官方站点 releases.ubuntu.com 会自动把请求重定向到 CDN，但在某些网络环境下速度依然不理想。国内多个高校和云厂商都维护了 Ubuntu 镜像，直接在浏览器或 aria2 中访问这些镜像站的路径，往往能获得比官方 CDN 快得多的速度。

同理，GitHub 上也有很多大体积的 release 文件，直接用 wget 下载经常慢到怀疑人生。这种情况下可以复制下载地址，通过公开的 GitHub 加速下载代理服务来中转，具体方式会在下一部分展开讲。

5. 实战案例：从下载 Ubuntu ISO 到安装 PyTorch

5.1 案例一：用 aria2 下载 Ubuntu 22.04 ISO

目标是从镜像站下载一个约 4GB 的 Ubuntu 22.04 LTS ISO 文件。假设网络环境是 200M 家用宽带，理论下载速度约 25MB/s，但服务器单连接限速 5MB/s。

先用 wget 试试：

bash复制wget https://mirrors.aliyun.com/ubuntu-releases/22.04.3/ubuntu-22.04.3-desktop-amd64.iso

实测速度大概 5MB/s，200M 宽带只用了五分之一。换 aria2 多线程拉取：

bash复制aria2c -x 16 -s 16 -k 1M -d /home/用户名/Downloads -o ubuntu-22.04.3-desktop-amd64.iso https://mirrors.aliyun.com/ubuntu-releases/22.04.3/ubuntu-22.04.3-desktop-amd64.iso

-d 参数指定保存目录，-o 指定文件名。这次速度能跑到 20MB/s 左右，接近带宽上限。整个过程大约 3 分钟，而 wget 需要超过 13 分钟。这只是单连接限速 5MB/s 的假设场景，若限速更严格，多线程带来的提升会更夸张。

下载完成后验证校验值：

bash复制sha256sum ubuntu-22.04.3-desktop-amd64.iso

和官网提供的 SHA256 值比对，确认文件完整性。

5.2 案例二：pip 加速安装 PyTorch

一个训练相关项目需要安装 PyTorch，包含 CUDA 依赖，总大小超过 2GB。在不换源的情况下直接运行：

bash复制pip install torch torchvision torchaudio

实测下载速度只有几百 KB/s，要装十几分钟。换源后：

bash复制pip install torch torchvision torchaudio --index-url https://mirrors.aliyun.com/pypi/simple/

速度提升到 5MB/s 以上，整个安装过程缩短到几分钟。如果 PyTorch 官方推荐用 --extra-index-url 指定的方式，也别忘了同时设置主源为国内镜像，否则部分依赖还是会从海外源拉取。

5.3 案例三：GitHub 仓库与 release 下载加速

GitHub 上大仓库的 git clone 也经常慢。可以尝试以下方式优化：

浅克隆只拉取最新一次提交，大幅减少数据量：

bash复制git clone --depth=1 https://github.com/owner/repo.git

如果后续需要完整历史，再补全即可。对于 release 大文件，很多人会使用公开的 GitHub 加速代理，把原始下载地址填入代理地址对应的格式中。这类公共代理服务的可用性和速度会随时间和网络环境变化，建议通过搜索“GitHub 下载加速”找到当前可用的服务，实测有效后再批量使用。

下载 release 文件时，先用 curl -I 查看文件大小和重定向路径：

bash复制curl -I https://github.com/owner/repo/releases/download/v1.0/file.tar.gz

这样可以提前知道目标文件的实际服务器地址，也方便判断是否需要走加速代理。

6. 常见问题与排查技巧实录

6.1 DNS 解析慢导致下载打不开

症状表现：下载开始前会卡住很久，进度条迟迟不动，但一旦开始跑就速度正常。

排查手段：用 dig 或 nslookup 查看域名解析耗时：

bash复制time nslookup mirrors.aliyun.com

如果解析耗时超过几百毫秒，考虑更换 DNS 服务器。Ubuntu 修改 DNS 有两种方式，桌面版可以在“设置-网络”里修改，服务器版则要编辑 netplan 配置或修改 /etc/resolv.conf。

我自己偏好使用延迟更低的公共 DNS 配合系统自带的解析缓存，能有效减少重复解析的开销。

6.2 断点续传失败

现象是中断后重新执行 aria2c -c，它还是从头开始下载。这种情况大概率是服务器不支持 Range 请求，或者临时文件被清理了。使用 aria2 时注意保留 .aria2 后缀的控制文件，这是断点续传的关键。如果你手动删除了 .aria2 文件，aria2 就不知道之前下到哪，只能重来。

6.3 下载速度上不去的硬件与系统层原因

有时候多线程参数调了、源也换了，速度依然不高。需要检查几个容易被忽略的环节：

磁盘写入速度。 如果你的下载目录在机械硬盘上，且硬盘同时在跑其他读写任务，磁盘 I/O 可能成为瓶颈。用 iotop 查看磁盘 I/O 情况：

bash复制sudo iotop -o

文件系统限制。 默认的 ext4 对大文件支持没问题，但如果用的是某些文件系统或者开了不合理的挂载参数，也会影响顺序写入性能。

老旧网卡或驱动问题。 在 设置-关于 里查看硬件信息，或者跑一下 sudo ethtool eth0 检查网卡协商速率。如果协商速率只有 100Mbps，说明网线或接口有问题。

6.4 常见故障速查表

6.5 几个值得记住的避坑技巧

不要在下载过程中频繁改参数。 aria2 下载到一半修改 -x 或 -s 需要重启任务，反而会打乱已经分配好的分片，浪费进度。参数在启动前设计好，中途不乱动。

下载临时文件和控制文件要放同盘。 aria2 的 .aria2 控制文件和文件本体如果不在同一分区，断电后可能造成文件系统不一致，影响恢复。

用代理加速时注意把代理地址写准确。 很多加速代理只支持 HTTP 协议，不支持 HTTPS 协议，拼接地址时看准格式，否则会直接 404。

写在最后

从日常下载 ISO 到 pip 安装依赖，再到 Git 仓库同步，Ubuntu 下的下载加速本质上就是“多线程 + 换源 + 选对工具”这套组合拳。我个人的习惯是：小文件直接用 wget 或 curl，大文件一律交给 aria2，批量任务用 uGet 排队，包管理器的源第一时间换到镜像站。这套配置我用了两年多，下载体验基本和 Windows 下开下载软件相当。你也不妨先试一个场景，比如明天装个软件前先 apt 换源，再开个 aria2 下个大文件，实测对比一下差距，应该会对“源头堵不如疏”这句话有更深的理解。