平时在 Ubuntu 上下载几十 MB、几百 MB 的文件,其实浏览器就够用了。
但如果开始折腾 Linux、虚拟机、Kubernetes,情况很快就不一样了。
Ubuntu ISO、Windows ISO、各种虚拟机镜像、CUDA 安装包、离线安装包……动不动就是几 GB。
我之前就碰到过一个很现实的问题:
同样的网络,Ubuntu 浏览器下载一个系统 ISO,速度却慢得让人怀疑人生。
于是开始研究 Ubuntu 上到底有哪些比较好用的下载工具。
浏览器、wget、curl、aria2、BT、qBittorrent,以及各种 GUI 下载器都折腾了一圈。
最后有点出乎我的意料:
现在我下载大文件,很多时候还是会打开迅雷。
这听起来可能不太“Linux”。
但折腾一圈以后,我越来越觉得:
工具最终还是拿来解决问题的。
能稳定、快速地把几个 GB 的文件下载下来,比“这个方案够不够 Geek”更重要。
当然,这并不是说迅雷就是 Ubuntu 上最好的下载工具。
不同场景其实适合完全不同的方案。
这篇就把这次折腾过程中搞明白的一些东西整理下来。
一、首先要搞明白:下载慢,不一定是 Ubuntu 的问题
第一次遇到这种情况,很容易产生一个判断:
Windows 下载挺快,为什么 Ubuntu 下载这么慢?
但实际上,操作系统往往不是决定下载速度的主要因素。
一条典型的 HTTP 下载链路大概是:
我的电脑 │ │ Internet ▼ 运营商网络 │ ▼ 骨干网 / 国际出口 │ ▼ CDN / 下载服务器 │ ▼ 目标文件这里任何一个环节都可能成为瓶颈。
比如:
下载服务器本身限速;
CDN 节点离我比较远;
国际链路质量不好;
单个 TCP 连接速度不高;
服务器对单 IP 限速;
某条网络路由质量不好;
下载源本身负载很高。
所以:
浏览器只有 500 KB/s,并不能证明我的宽带只有 500 KB/s。
它只能说明:
“我到这个服务器的这条下载路径,目前只有这么快。”
这两个概念差别非常大。
二、最简单:浏览器直接下载
最开始当然还是 Chrome 或 Firefox。
点击 Ubuntu ISO:
Download然后浏览器开始下载。
最大的优点就是简单。
不用安装任何软件,也不用学习命令。
但下载几 GB 的 ISO 时,问题就出来了。
如果当前服务器给我的单连接速度比较低:
500 KB/s浏览器可能就真的一直:
500 KB/s 500 KB/s 480 KB/s 520 KB/s ……一个 6 GB 的 ISO:
6 GB ÷ 0.5 MB/s ≈ 3.3 小时这时候就很折磨人了。
而且浏览器毕竟主要是浏览器,下载管理只是其中一个功能。
所以我开始研究 Linux 世界里更传统的下载工具。
三、Linux 老朋友:wget
Linux 用户第一个想到的一般就是:
wget URL如果文件比较大,我一般会加断点续传:
wget -c URL这当然很好用。
尤其是在:
Ubuntu Server;
SSH 远程服务器;
自动化脚本;
没有桌面环境;
这些情况下,wget几乎是必备工具。
但这里有一个我以前也容易产生的误解:
wget 是专业下载工具,所以 wget 应该比浏览器快。
其实不一定。
如果:
浏览器 ↓ 服务器 A和:
wget ↓ 服务器 A本质上走的还是同一个服务器、同一条网络路径。
那么:
浏览器:500 KB/s wget:550 KB/s这种结果非常正常。
换成 wget 并不会凭空创造带宽。
所以 wget 最大的优势其实是:
稳定、简单、适合命令行和自动化。
而不是:
一定能加速。
四、curl 也很好,但定位和 wget 类似
另外一个 Linux 用户几乎肯定会碰到的工具就是:
curl下载文件可以:
curl -L -O URL断点续传:
curl -L -C - -O URLcurl 很强。
甚至从协议处理、API 调试、HTTP 请求这些角度看,它比单纯下载文件的作用大得多。
但是:
curl 也不是所谓的“下载加速器”。
如果瓶颈来自服务器、路由或者单连接速度,那么单纯:
Chrome → wget → curl换来换去,改善通常不会特别大。
这时候真正开始改变下载方式的工具出现了:
aria2。
五、aria2:Linux 下载工具里的“性能派”
aria2 是我认为 Linux 用户非常值得认识的一个下载工具。
安装:
sudo apt install aria2普通下载:
aria2c URL但 aria2 真正有意思的是:
分段、多连接、多来源下载。
例如:
aria2c -x 8 -s 8 URL简单理解,就是尝试把一个大文件拆成多块:
文件 ┌──────┬──────┬──────┬──────┐ │ Part1│ Part2│ Part3│ Part4│ └──────┴──────┴──────┴──────┘ ↑ ↑ ↑ ↑ 连接1 连接2 连接3 连接4最后再拼成完整文件。
aria2 官方文档也明确支持 HTTP(S)、FTP、SFTP、BitTorrent 和 Metalink,并支持 segmented downloading 和多个来源同时下载。
这时候就可能出现:
单连接: 500 KB/s 8 个连接: 500 KB/s × 若干连接最后总速度可能达到:
2 MB/s 5 MB/s 甚至更高当然,不应该简单理解成:
8 个连接 = 8 倍速度因为最终仍然受到:
服务器带宽 网络带宽 服务器限速策略 本地宽带 TCP 状态等很多因素限制。
六、为什么 aria2 有时还是救不了?
这是我觉得很值得讲的一点。
很多人看到:
aria2c -x 16 -s 16以后会产生一种感觉:
那我把连接数调大,不就一定快了吗?
不是。
举个例子。
假设服务器限制:
每个 TCP 连接最大 500 KB/s那么多连接很有用:
连接1 500 KB/s 连接2 500 KB/s 连接3 500 KB/s 连接4 500 KB/s总速度可能明显提高。
但如果服务器限制的是:
这个 IP 总共只能 1 MB/s那你开:
1 个连接 8 个连接 16 个连接可能最后都是:
≈ 1 MB/s还有一种更麻烦的情况:
服务器本身离我太远,或者网络路径就不好。
那么 aria2 即使开很多连接,本质上仍然是在:
我的电脑 ↓ 同一条糟糕的网络路径 ↓ 同一个服务器这个时候,多线程并不能从根本上解决问题。
而这正是迅雷和普通 HTTP 多线程下载器最大的区别之一。
七、Linux ISO 其实还有一个非常好的办法:BT
如果我要下载的是 Ubuntu ISO,其实还有一个方法经常被忽略:
BitTorrent。
Ubuntu 官方本身就提供 Torrent 下载,而且明确说明 BT 有时可以为大文件提供更高的速度和更可靠的下载体验。
这其实非常合理。
普通 HTTP 是:
┌─────────────┐ 我的电脑 ───→ │ Ubuntu Server│ └─────────────┘只有一个主要来源。
BT 则可能变成:
Peer A │ Peer B ───── 我的电脑 ───── Peer C │ Peer D │ Web Seed你不是从一个服务器拿完整文件。
而是:
A 给我一部分 B 给我一部分 C 给我一部分 D 再给我一部分最后拼起来。
这对于 Ubuntu ISO 这种:
文件大;
下载人数多;
官方长期做种;
用户节点多;
的资源特别合适。
八、qBittorrent:我很推荐保留的 BT 客户端
Linux 下如果经常使用 BT,我比较推荐 qBittorrent。
Ubuntu 官方源就有:
sudo apt install qbittorrent它同时也提供 AppImage、Flatpak 等 Linux 版本。
界面也比较传统:
添加 Torrent 添加 Magnet 选择目录 开始下载没有太大的学习成本。
所以如果资源本身有优质 Torrent:
我反而更愿意用 qBittorrent,而不是非得用迅雷。
尤其是:
Ubuntu ISO Debian ISO Linux Mint ISO 大型开源项目镜像这种东西。
BT 本身就是非常合适的分发方式。
九、那为什么最后我反而还是经常打开迅雷?
折腾到这里,其实已经有很多工具了:
浏览器 wget curl aria2 qBittorrent从 Linux 用户角度看,似乎已经够用了。
但实际使用一段时间以后,我发现:
碰到一个下载很慢的大文件时,我还是经常直接打开迅雷。
原因很简单:
省事。
比如我拿到:
https://xxxx/xxxx.iso浏览器只有:
600 KB/s我当然可以开始研究:
服务器支不支持 Range? aria2 开多少线程? 有没有镜像? 有没有 torrent? 国内有没有镜像站?但有时候我只是想:
把这个文件下载下来。
于是复制地址。
打开迅雷。
新建任务。
粘贴。
下载。
这就是一种非常现实的需求。
十、关键问题:为什么迅雷有时候会明显更快?
这也是我这次折腾以后最想弄明白的东西。
很多人会把迅雷理解成:
一个类似 aria2 的多线程下载器。
其实不完全是。
迅雷真正有意思的地方,是它长期使用的一套思路:
P2SP
也就是:
Peer to Server & Peer迅雷自己的开放平台目前仍然把 P2SP 作为其下载加速的重要技术,并称它可以在大文件和高并发下载中利用多个通道和服务器改善下载效率。
十一、普通 HTTP、aria2 和迅雷到底差在哪里?
用一个简单的图理解。
普通 HTTP 下载
我的电脑 │ │ ▼ Server A如果 Server A 给我的速度是:
500 KB/s那基本就只能接受。
aria2 多连接
┌── Connection 1 ──┐ ├── Connection 2 ──┤ 我的电脑 ─┼── Connection 3 ──┼→ Server A └── Connection 4 ──┘优点:
同一个服务器开多个连接。
如果服务器允许,就可能把速度堆起来。
但核心还是:
Server A迅雷的思路
理论上更接近:
┌── 原始服务器 │ ├── 其他可用服务器 │ 我的电脑 ── 迅雷 ───┼── CDN / 缓存资源 │ ├── P2P Peer A │ ├── P2P Peer B │ └── 其他可用资源重点变成:
不一定只盯着你复制过来的那个服务器。
这才是本质区别。
十二、举个非常容易理解的例子
假设我要下载:
ubuntu.iso原始地址:
Server A我这里连 Server A:
500 KB/s那么 wget 可能就是:
500 KB/s浏览器:
500 KB/saria2 开多个线程之后:
1.5 MB/s已经不错了。
但如果迅雷能够找到同一个资源的其他数据来源,例如:
Server A 500 KB/s 其他来源 1 MB/s Peer A 300 KB/s Peer B 800 KB/s 缓存节点 2 MB/s它理论上就可以同时利用其中多个来源。
总速度自然可能明显高于:
只访问 Server A这不是突破了我的宽带速度。
而是:
换了一种获取数据的方式。
十三、所以迅雷并没有让“网速”变快
这点需要特别强调。
假设我的宽带最大下载速度:
100 Mbps换算一下:
100 ÷ 8 ≈ 12.5 MB/s那么:
wget:500 KB/s 迅雷:10 MB/s并不意味着:
迅雷把我的 100 Mbps 宽带变成了更高速的宽带。
真正发生的更可能是:
wget: 某一个下载源只能给我 500 KB/s 迅雷: 通过多个来源,把我的 100 Mbps 带宽尽量吃满所以更准确的说法应该是:
迅雷更擅长利用现有带宽。
而不是:
迅雷创造了额外带宽。
十四、另一个关键:资源越热门,迅雷往往越有优势
这一点其实也很好理解。
假设有一个非常冷门的文件:
abcdef-test-20260831-private-build.tar.gz全世界可能就一个服务器有。
那迅雷再厉害,也只能:
迅雷 ↓ 唯一服务器它没有其他来源可以找。
但如果这是:
Ubuntu ISO Windows ISO 热门软件 驱动 游戏安装包大量用户都下载过。
那么同一份资源可能已经存在于:
多个服务器 缓存 CDN P2P 网络 其他节点这种情况下,P2SP 的优势才更容易体现出来。
所以你会发现一个很有意思的现象:
迅雷并不是所有文件都快,而是某些热门大文件特别容易快。
这其实很符合它的工作原理。
十五、那么迅雷怎么知道“两个地址其实是同一个文件”?
这里涉及下载系统非常重要的一个概念:
资源识别。
例如两个网站:
A.com/ubuntu.iso B.com/download/linux.isoURL 完全不一样。
但是文件内容可能一模一样。
下载系统可以结合:
文件大小 Hash 分块 Hash 资源特征 已有资源数据库等信息识别:
这实际上是同一份内容。
于是下载的时候就不必局限于:
A.com而可以尝试:
A.com + B.com + 其他拥有相同数据的来源至于迅雷当前客户端内部具体采用哪些算法、缓存和调度策略,这是它的闭源实现,我们没有必要把无法验证的细节猜得太具体。
理解核心思想就够了:
普通下载器主要知道“这个 URL”;而拥有资源网络的下载系统还可能知道“这个文件”。
这两者能力是不一样的。
十六、那 aria2 能不能做到类似的事?
能做到一部分。
aria2 本身就支持:
多来源 HTTP FTP BitTorrent Metalink例如同一个文件有两个镜像:
aria2c URL1 URL2aria2 就可以利用多个来源。
它甚至可以结合 HTTP 和 BitTorrent 下载同一资源。aria2 官方文档对此有明确说明。
问题在于:
你得知道这些来源在哪里。
也就是说:
aria2: 我告诉你 URL1 我告诉你 URL2 我告诉你 Torrent ↓ aria2 帮我高效下载而迅雷最大的价值之一是:
我只告诉它一个资源 ↓ 它自己的资源系统再尝试寻找其他可用来源所以二者其实不是简单的:
aria2 vs 迅雷而是:
高性能下载客户端 vs 客户端 + 资源发现/调度网络十七、这也是为什么我最后还是经常用迅雷
折腾完这些以后,我的选择反而变得简单了。
场景一:普通小文件
直接:
Chrome / Firefox没有必要打开专门的下载器。
场景二:服务器、脚本、自动化
直接:
wget或者:
curl它们在 Linux 世界里的价值完全不可替代。
场景三:知道 HTTP 地址,而且想多线程下载
用:
aria2它轻量、强大、开源。
场景四:官方提供 Torrent
我会优先考虑:
qBittorrent尤其是 Linux ISO。
Ubuntu 官方本身就提供 BT 下载,没有必要非从某个很慢的 HTTP 节点死磕。
场景五:就是一个很慢的大文件地址
这种时候:
我现在很多时候会直接丢进迅雷试一下。
如果迅雷也只有:
500 KB/s说明这个资源可能本身就没有什么可加速的空间。
但如果:
浏览器:500 KB/s 迅雷:5 MB/s那就不用再折腾了。
让它下。
十八、Ubuntu 怎么安装迅雷?
我现在使用的是:
Flatpak 版迅雷
如果已经配置了 Flathub,可以直接:
flatpak install flathub com.xunlei.Thunder启动:
flatpak run com.xunlei.Thunder查看信息:
flatpak info com.xunlei.Thunder以后更新:
flatpak update就可以了。
但这里有一个需要特别说明的地方。
截至 2026 年 8 月,Flathub 上的 Thunder 页面显示版本仍然是:
1.0.0.1而且 Flathub 明确注明:
这是社区提供的软件包,并没有经过迅雷官方验证、关联或支持。
当前 Flathub Manifest 实际上是从麒麟软件源获取迅雷 Linux 的.deb,再封装成 Flatpak。
而迅雷目前官方网站的主要桌面下载入口则列出了:
Windows Mac NAS并没有像 Windows、Mac 一样 prominently 提供当前 Linux 桌面客户端下载。
所以严格来说:
我现在使用的是社区维护的 Flatpak 包,而不是迅雷官方当前重点维护的 Linux 发行渠道。
这一点还是应该说明白。
十九、为什么我还是选择 Flatpak?
既然它本质上也是老 Linux 迅雷,那为什么不直接找.deb?
我的考虑很简单:
第一,安装简单
flatpak install flathub com.xunlei.Thunder搞定。
第二,卸载干净
flatpak uninstall com.xunlei.Thunder不需要自己研究老.deb往系统里放了哪些依赖。
第三,隔离性更好
尤其这种:
闭源 版本比较老 不是 Ubuntu 官方源的软件,我反而更愿意让它跑在 Flatpak 沙箱里面。
从 Flathub 当前 Manifest 看,迅雷主要被授予网络、X11、声音、下载目录等权限,其中下载文件访问默认指向 XDG Downloads。
所以:
这种应用我觉得 Flatpak 反而是比较合适的安装方式。
二十、迅雷当然可以直接粘贴下载地址
这个也没有问题。
打开迅雷:
新建任务然后把:
HTTP / HTTPS 地址直接粘贴进去即可。
它也支持:
HTTP BitTorrent MagnetFlathub 的应用说明同样明确列出了这些协议。
这也是我最常用的方式。
浏览器发现速度特别慢:
Ctrl + C 下载链接 ↓ 迅雷 ↓ 新建任务 ↓ Ctrl + V看看速度。
如果明显提升:
继续下。
如果没有提升:
再考虑 BT、镜像站或者其他下载源。
非常简单。
二十一、需要专门安装“迅雷浏览器插件”吗?
我个人现在觉得没必要。
至少我的使用习惯里:
发现大文件下载慢 ↓ 复制链接 ↓ 迅雷新建任务已经足够。
我不太喜欢为了偶尔一个下载需求,让浏览器额外长期运行很多插件。
而且手动复制链接还有一个好处:
什么时候让迅雷接管,由我自己决定。
几十 MB 的文件:
Chrome几个 GB 而且很慢:
迅雷比较清晰。
二十二、Flatpak 版有个小问题:下载目录权限
Flatpak 是沙箱应用。
当前 Flathub Manifest 给迅雷的文件访问权限主要包括:
xdg-download也就是用户的 Downloads 目录。
所以如果你平时就下载到:
~/Downloads通常没什么问题。
但如果希望把大文件放到:
另外一块硬盘 NAS 挂载目录 自定义 /data就有可能碰到 Flatpak 文件权限问题。
这种时候可以用 Flatseal 图形化调整权限,也可以根据实际目录使用 Flatpak override。
例如假设专门有:
/data/download可以给它增加这个目录的访问权限。
这也是 Flatpak 版和普通.deb版比较明显的区别之一。
二十三、迅雷也不是万能的
写到这里,很容易让人觉得:
那以后全部迅雷不就完了?
其实完全不是。
我自己用下来,至少有几个场景它并没有优势。
1. 冷门资源
只有一个服务器有。
迅雷找不到额外来源。
那么:
迅雷速度 ≈ wget很正常。
2. 内网、公司文件、临时文件
比如:
公司内部 HTTP Server 自己搭的 NAS 临时生成的 Build全球根本没人下载过。
自然谈不上什么 P2P、缓存、多来源。
这时候:
wget curl aria2反而更加直接。
3. 有非常好的官方镜像
例如 Ubuntu ISO。
如果我找到国内速度非常好的镜像:
10 MB/s已经跑满宽带了。
那再打开迅雷没有任何意义。
4. Torrent 本身资源非常健康
例如热门 Linux ISO:
qBittorrent:11 MB/s已经接近带宽极限。
这种情况下 BT 就很好。
二十四、还有一个不能忽略的问题:隐私和闭源
迅雷毕竟是闭源商业软件。
而:
wget curl aria2 qBittorrent都是开源工具。
从可审计性、Linux 原生程度、服务器环境、自动化能力来看,开源工具显然更符合传统 Linux 使用习惯。
而且 P2P/P2SP 类下载机制天然可能涉及:
资源识别 Peer 通信 网络上传 资源调度因此如果下载的是:
公司内部文件 私人文件 带鉴权的敏感资源我不会把它随手扔进第三方商业下载器。
这类内容:
wget、curl 或浏览器直连反而更合适。
我的迅雷使用场景主要还是:
公开 ISO 公开软件包 大型公开文件 普通下载资源二十五、最终我的 Ubuntu 下载工具组合
折腾一圈以后,我没有找到一个所谓:
“Ubuntu 最好的下载器”。
反而形成了一套组合。
| 场景 | 我的选择 |
|---|---|
| 普通网页小文件 | Chrome / Firefox |
| SSH / Server | wget |
| API / 脚本 | curl |
| HTTP 多线程 | aria2 |
| Torrent / Magnet | qBittorrent |
| Ubuntu ISO | 官方镜像 / BT 优先 |
| 普通方法下载大文件特别慢 | 迅雷试一下 |
| 私有、敏感文件 | 浏览器 / wget / curl |
所以最后的结论并不是:
迅雷打败了所有 Linux 下载器。
而是:
不同工具解决的是不同问题。
二十六、为什么折腾一圈,我最后还是用回了迅雷?
可能有人会觉得:
都用 Linux 了 为什么还用迅雷?但现在我其实不太纠结这个问题。
Linux 给我的最大价值之一,本来就是:
选择。
喜欢命令行:
wget curl aria2喜欢开源 BT:
qBittorrent碰到一个几 GB 的大文件,HTTP 只有几百 KB/s:
迅雷哪个能最快解决问题,就用哪个。
以前我可能更容易追求:
“Linux 下应该用什么最正统?”
现在我的想法反而是:
软件最终是工具,不是信仰。
尤其当一个:
6 GB 8 GB 10 GB的 ISO 摆在面前。
浏览器告诉我:
剩余时间:3 小时而换一个工具以后变成:
剩余时间:12 分钟这个时候:
我选择那 12 分钟。
总结
这次因为 Ubuntu 下载系统 ISO 太慢,我把 Linux 下常见的几种下载方式重新研究了一遍。
最终可以简单归纳成:
浏览器 ↓ 简单方便 wget / curl ↓ Linux 基础工具,稳定、适合自动化 aria2 ↓ 多连接、多来源、高性能 qBittorrent ↓ BT / Magnet,非常适合 Linux ISO 迅雷 ↓ P2SP + 资源网络 某些公开热门大文件上可能明显更快真正让我改变认识的一点是:
下载器的速度,不只是“线程多不多”。
更重要的问题其实是:
数据从哪里来?
如果所有工具都只能从:
Server A下载,那么大家的上限不会差得特别离谱。
如果一个下载系统能够从:
Server A Server B 缓存 CDN Peer 其他相同资源同时获得数据,那才有机会真正拉开差距。
这也解释了为什么有时候:
wget:500 KB/s aria2:1.5 MB/s 迅雷:8 MB/s而换一个冷门文件:
wget:500 KB/s aria2:600 KB/s 迅雷:500 KB/s这种情况同样可能发生。
所以现在在 Ubuntu 上下载东西,我已经不再执着于某一个工具。
我的原则很简单:
小文件随便下,大文件选合适的协议;官方有 BT 就优先 BT,HTTP 太慢就试 aria2,还是不行就扔进迅雷看看。
最终目的只有一个:
别让下载一个 ISO,浪费掉几个小时。
这大概就是我折腾了一圈 Ubuntu 下载工具以后,留下来的最终答案。