apt 换源怎么换：9 个镜像实测，官方源慢 1,831 倍

apt 换源就是改源文件里的域名：Debian 12 改 /etc/apt/sources.list，Debian 13 与 Ubuntu 24.04 改 /etc/apt/sources.list.d/ 下的 .sources，改完必须验证 apt 读的是新文件。

apt 换源这件事，是从一台 1 核 1G 的机器开始的

那台机器是 Debian 12，国内机房，1 核 1G。系统装完，第一件事敲 apt update，回车，光标就停在那儿。屏幕上一行 0% [Connecting to deb.debian.org]，一直不动。开 top 看，apt 的 CPU 占用是 0，说明它不是在解压，是在等。

第一次碰到这种情况会以为机器坏了。ping 一下 deb.debian.org，255.531 ms，20 个包里丢了 3 个。换台机器再 ping，还是这个数。

中间试过几个办法。清 apt 缓存、换 DNS、把超时时间调大，全都没用，因为它不是解析失败，是下载不动。真正解决问题的只有换源：把 deb.debian.org 换成国内镜像，同一个文件不再卡在 0%。

文中的吞吐与延迟数字全部来自 2026-10-31 下午的两台探测机；开篇那台 1 核 1G 机器只用于还原场景，没有纳入测量。这篇讲的是换哪家、怎么换、换完怎么确认真的生效、报错了怎么排查。

官方源在中国大陆为什么拉不动

北京那台探测机用 Debian APT-HTTP/1.3 的 UA 去拉 bookworm 的 Packages.xz，文件 8,790,396 字节。4 轮跑完，累计 80.002 秒，只拿到 1,161,721 字节，占整个文件的 13.2%。折算成吞吐是 0.116 Mbps。

80 秒下不到一个 8.4 MiB 文件的五分之一。而 apt update 要拉的不止这一个，main、contrib、non-free 各有一份索引，security 源还有一份。按这个速度，换源之前 apt update 停在下载阶段是必然的，不是偶发。

延迟也解释得通。同一个文件、同一台北京探测机，4 轮里吞吐只有 0.116 Mbps，首字节要等 4.557 秒；换成 ping 去看，广东电信源打官方源 255.531 ms，北京阿里云源 219.409 ms，两个源都是 15.0% 丢包。15.0% 不是抖动，是链路真的在丢包。TCP 在丢包环境里会反复退避重传，吞吐被压到 0.116 Mbps 就不奇怪了。

解决这件事有三条路：给 apt 挂代理、换国内镜像、自己搭一个反向代理。挂代理要长期维护，自己搭更麻烦，换源是成本最低的那条，改两个文件就完事。这也是为什么几乎所有中文教程第一句都是让你换源。

换源解决的是「从哪拿」的问题，解决不了「管道有多粗」的问题。这两件事经常被混在一起，所以有人换完源发现还是慢，就以为换错了。

顺带说一句，换源之前先搞清楚这台机器的出口带宽有多少。源再快，也快不过你的端口。带宽和端口速率的换算写在 带宽与端口速率 那篇里，两个数一起看才有意义。

9 个站点实测：同一个包，差 1,831.5 倍

吞吐只从北京那台机器测，单线程 curl，每站 4 轮、每轮限时 20 秒，取的是累计字节除以累计耗时，不是单轮平均。ping 两个源各打 20 个包。这 9 个站都是换源时会遇到的候选，官方源放在第一行当基准。

这组数字有三个边界要说在前面：一是只测了单个大文件，没测完整 apt update 的总耗时；二是只走 HTTP 单连接，没有覆盖 CDN 边缘命中与多线程并发；三是探测机在国内，机器在美国或欧洲时排序会变。所以这张表回答的是「国内机器从哪家拉得快」，不是「谁家镜像最好」。

这张表怎么读，说三点。

先看吞吐那一列。8 个国内镜像的中位数是 103.227 Mbps，最快 212.457，最慢 3.672。清华和官方源之间是 1,831.5 倍，这个倍数大到没有实感，换成一句人话就是：官方源还在建立连接的时候，清华已经把整个文件传完了。换源这件事的全部收益，基本就在这一列里。

再看首字节。官方源 4.557 秒，网易 163 是 8.548 秒。这两个数字的意思是，请求发出去之后，要等这么久对方才开始给你数据。apt update 卡住的那段时间，很多时候就卡在这一步，跟你的带宽没关系。

最后看单轮区间。清华 4 轮从 129.033 到 426.201，最高一轮是最低一轮的 3.3 倍。所以「测一次就定终身」不成立，换源选站要看多轮，也要接受它自己在波动。换完之后如果某天突然变慢，先重测一轮再决定要不要再换。

延迟低不等于快：5.380 ms 的阿里云只有 8.223 Mbps

阿里云 ping 5.380 ms，吞吐 8.223 Mbps。清华 ping 65.103 ms，吞吐 212.457 Mbps。这两个 ping 都来自广东那台探测机，两个吞吐都来自北京那台，所以是同一测点下的两种指标对比，不是拿广东的延迟去比北京的吞吐。

ping 测的是 ICMP 小包的往返，几十字节，走控制面。apt 下载是 TCP 大包，受窗口大小、丢包率、对端限速、回源链路影响。一个 5 毫秒就能回来的地址，不代表它愿意给你 100 Mbps。

广东源 ping 极差 59.723 ms，从阿里云 5.380 到清华 65.103。北京源极差 33.963 ms，从腾讯 3.212 到南京大学 37.175。这两个差值在换源时参考价值不大，因为你要的是把 8.4 MiB 拉下来，不是发一个包过去再回来。

阿里云那个 8.223 值得单独说。它的首字节只有 0.182 秒，连得上，连得快，就是传得慢。这种表现通常是镜像站对单连接做了限速，或者回源路径上有一跳拥塞。从 ping 上看不出来，只有真拉一个文件才知道。

腾讯 127.224 对阿里云 8.223 是 15.47 倍。两家都是大厂镜像，域名都很好看，差距就在这里。所以「换国内源」不等于「随便换个国内域名」，选哪家是要挑的。

换源之前想自己验一遍，两条命令就够。一条测首字节，curl -o /dev/null -s -w '%{time_starttransfer}\n' <URL>；一条测整体速度，curl -o /dev/null -s -w '%{speed_download}\n' <URL>。两个数都看，别只看后一个，首字节慢的站会让你在 apt update 开头等很久。这套测法在换源前跑一遍，换完再跑一遍，两次结果放在一起才有对比。

Debian 换源：bookworm 和 trixie 是两套写法

先确认代号，别猜：

. /etc/os-release && echo $VERSION_CODENAME

Debian 11 是 bullseye，12 是 bookworm，13 是 trixie。拼错一个字母，apt update 直接 404。

Debian 12 及更早，主文件是 /etc/apt/sources.list，一行一条：

deb http://mirrors.ustc.edu.cn/debian/ bookworm main contrib non-free non-free-firmware
deb http://mirrors.ustc.edu.cn/debian/ bookworm-updates main contrib non-free non-free-firmware
deb http://mirrors.ustc.edu.cn/debian-security/ bookworm-security main contrib non-free non-free-firmware

注意第三条的路径是 /debian-security/，不是 /debian/。不少镜像站把 security 单独挂一个目录，写成一个源就是 404。

Debian 换源出错最多的地方就在这里。main、updates 两条写对了，security 那条写成 /debian/ bookworm-security，apt update 前两条正常、第三条 404，于是有人以为是镜像站缺文件。其实换一家也一样，路径本身就是错的。

non-free-firmware 是 Debian 12 起单独拆出来的组件，老教程里没有。网卡、无线、显卡的固件包在这个组件里，装不上驱动多半是漏了它。Debian 11 上没有这个组件，照抄 12 的写法会报错。

Debian 13 起默认用 DEB822 格式，文件在 /etc/apt/sources.list.d/debian.sources，sources.list 留空或者删掉：

Types: deb
URIs: http://mirrors.ustc.edu.cn/debian/
Suites: trixie trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

四个字段缺一不可：Types、URIs、Suites、Components。Signed-By 指向系统自带的 keyring，删掉这行就是 NO_PUBKEY。段落之间空一行，一个文件里可以写多段，security 单独一段也行。

deb-src 默认不要开。开了 apt update 要把源码索引也拉一遍，时间差不多翻倍，而绝大多数人根本不编译。真要编译再单独加一行。

改之前先备份，这一步没有例外：

cp /etc/apt/sources.list /etc/apt/sources.list.bak-2026-10-31

备份文件名不要以 .list 结尾。apt 会读 /etc/apt/sources.list.d/ 下所有 .list 和 .sources，叫 sources.list.bak 不会被读，叫 sources.bak.list 就会被读进去，然后你平白多了一个坏源。

一行式和 DEB822 混着写会怎样

两种格式可以共存，apt 会把 sources.list 和 sources.list.d/* 全部读进去合并。所以换源时最常见的翻车不是格式写错，是旧的没删干净：新的 .sources 加进去了，老的 sources.list 里还留着官方源，apt update 会同时连两边，慢的那条拖垮整体。

Debian 13 上建议只留一套。用 DEB822 就把 sources.list 清空或者删掉，用一行式就把 .sources 删掉。别两边都留一半。

各家镜像站都提供了现成的片段，清华 TUNA 的 Debian 帮助页 会按你选的代号生成对应的内容，比自己手敲靠谱。复制的时候注意页面上的代号要跟你机器上的对上，它默认给的不一定是你那个版本。

Ubuntu 换源：noble 和 jammy，还有 ports

Ubuntu 24.04 是 noble，22.04 是 jammy，20.04 是 focal。24.04 起配置文件搬到了 /etc/apt/sources.list.d/ubuntu.sources，/etc/apt/sources.list 里只剩一行注释。照着 2020 年的教程改 sources.list，改完 apt update 一切正常，因为读的是另一个文件，你会以为成功了，装包还是慢。这是目前 Ubuntu 换源教程失效最多的一处。

noble 的写法：

Types: deb
URIs: http://mirrors.aliyun.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

security 单独一段：

Types: deb
URIs: http://mirrors.aliyun.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

22.04 还是老写法，一行一条，改 /etc/apt/sources.list：

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-security main restricted universe multiverse

ARM 机器要换路径。ubuntu 和 ubuntu-ports 是两个目录，不是别名。arm64 或 riscv64 上把 URI 写成 /ubuntu/，apt update 会 404，因为那个目录下没有 arm64 的索引。改成 http://mirrors.aliyun.com/ubuntu-ports/ 才对，Suites 和 Components 不用动。

用 sed 批量替换，什么时候会把文件写坏

网上流传的写法是 sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list。这条命令本身没错，只替换域名，路径原样保留。错的是另一类写法，把整段地址一起换掉：s/http:\/\/archive.ubuntu.com\/ubuntu\//http:\/\/mirrors.aliyun.com\/ubuntu\//。在 x86 机器上没问题，在 ARM 机器上不匹配，因为那边的地址是 ports.ubuntu.com/ubuntu-ports。命令跑完没有任何报错，你会以为换好了，apt update 还是连官方源。

还有一类更隐蔽。sed -i 会直接改原文件，改坏了没有回退。加个后缀就能留底：sed -i.bak ...，它会先写一份 .bak 再改。这一条在换源时比省事重要，因为源文件坏了，连恢复用的 apt 都装不了。

换源后 apt update 报错的 4 类原因

按报错原话分类比按「网络问题」「配置问题」分类好用，因为你手上只有一行红字。下面四类覆盖了绝大多数换源后 apt update 报错的情况。

判断顺序有个窍门：看报错里有没有 URL。有 URL 且带 404，是代号或路径；有 URL 但写的是 GPG、signature、NO_PUBKEY，是签名；连 URL 都没解析出来，才是网络层。这个顺序能省掉一半瞎试。

一、代号写错，或者镜像站还没同步这个版本

报错原话：

E: The repository 'http://mirrors.aliyun.com/debian trixie Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

也可能只是一行 404 Not Found。

原因有两种。一是代号拼错，bookworm 写成 bookwork，trixie 少写一个 i。二是代号没错，但镜像站还没同步这个版本。新版本发布头几天，各家同步进度不一样，官方源有、镜像站没有，就是 404。

处理：先 curl -sI http://mirrors.aliyun.com/debian/dists/trixie/Release 看返回码。404 说明这家没有，换一家；200 说明站上有，是你自己写错了。EOL 的版本（比如 Debian 10 buster）官方已经挪走，要指向 archive.debian.org，并且关掉有效期检查，否则会报 Release 文件过期。

二、路径前缀不对

报错原话：

W: Failed to fetch http://mirrors.aliyun.com/ubuntu/dists/noble/InRelease  404  Not Found

原因：镜像站的目录结构不统一。阿里云 Debian 在 /debian/，security 在 /debian-security/；Ubuntu 在 /ubuntu/，ARM 在 /ubuntu-ports/。清华、中科大的目录名大体一致，但也有站把 Debian 再套一层目录。

处理：别凭记忆写路径。打开镜像站首页，进 Debian 或 Ubuntu 目录，看 dists/ 下面有没有你要的代号。有就照抄那一层的完整路径，没有就换站。

三、GPG 签名和密钥

报错原话：

W: GPG error: http://mirrors.ustc.edu.cn/debian bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://mirrors.ustc.edu.cn/debian bookworm InRelease' is not signed.

原因：DEB822 里 Signed-By 那行被删了，或者指向的 keyring 文件不存在，或者从 http 换 https 时把 key 路径一起改掉了。

处理：确认 /usr/share/keyrings/debian-archive-keyring.gpg 在不在，不在就装 debian-archive-keyring。Signed-By 必须指向真实存在的 keyring，不能随手写个路径。换源时如果从 http 改成了 https，keyring 一般不用动，但 ca-certificates 得先装上，否则报的是证书错误，看起来像签名问题。

四、网络层：DNS、IPv6、代理、限流

报错原话：

Could not resolve 'mirrors.tuna.tsinghua.edu.cn'
Failed to fetch http://mirrors.163.com/debian/dists/bookworm/InRelease  Connection timed out
Failed to fetch http://mirrors.aliyun.com/debian/dists/bookworm/InRelease  403  Forbidden

原因有四种。DNS 没配好，容器里常见。机器没有 IPv6 出口但 apt 优先试 AAAA 记录，要等超时才回退。配了 http_proxy 但代理不通。镜像站对单 IP 限流，短时间大量请求就返回 403。

处理：getent hosts mirrors.tuna.tsinghua.edu.cn 看解析；curl -4 强制 IPv4 试一次；env | grep -i proxy 看有没有残留代理；403 就换一家，别跟限流较劲。

403 这一类最容易误判。碰到过一次，报错里只有 403，第一反应是防火墙，把 iptables、安全组、出方向规则全查了一遍，都是通的。最后发现是镜像站对单个 IP 的并发连接有限制，同一时间一边跑 apt update 一边另开窗口 apt install，两个请求撞上了。换一家镜像，问题消失。换源时如果同时开了几个终端在装包，先停一个再试。

一张对照表，出问题先对号：

改坏了怎么退回去

cp /etc/apt/sources.list.bak-2026-10-31 /etc/apt/sources.list，或者把新建的 .sources 文件删掉，恢复原样。恢复完还报错，清一下索引缓存：rm -rf /var/lib/apt/lists/* 再 update。apt 的索引是本地缓存的，坏源留下的残片会让它继续报错。

换源改坏的情况其实不常见，改坏之后不知道自己在哪一步，才常见。所以备份这一步别省，它花的时间是一秒钟。

SSH 还能进，就这些够了。如果连 SSH 都进不去，用商家面板的救援模式或者 VNC 挂进去改，别急着重装。

怎么确认换源真的生效

换源后 apt update 不报错，不代表它读的是你改的那个文件。

第一个办法，看 Get: 和 Hit: 后面的域名。Get: 是真的去下载，Hit: 是命中本地缓存。换源后第一次 update 应该全是 Get:，域名是你写的那家。如果还是 deb.debian.org，说明有别的东西在生效。

第二个办法，让 apt 把 HTTP 请求打出来：

apt-get -o Debug::Acquire::http=true update 2>&1 | grep -i 'connecting\|host:'

它会显示实际连的域名和 IP。换源之后第一次跑这条命令，输出里应该只有你写的那一家。看 IP 归属比看域名可靠，因为有的镜像站会 CNAME 到 CDN。

第三个办法，查残留：

grep -rn "deb.debian.org\|archive.ubuntu.com\|security.ubuntu.com" /etc/apt/

/etc/apt/sources.list.d/ 里经常躺着第三方源，docker、nodesource、宝塔自己的源。主源换完了，这些还在连官方地址，apt update 照样慢。要么一起换，要么注释掉。换源最容易漏的就是这一层，因为它不在你刚才改的那个文件里。

第四个办法，看包从哪来：

apt-cache policy nginx

输出里 origin 那一行会写镜像站域名。这一条最能说明问题，因为它显示的是 apt 眼里这个包的真实来源。

第五个办法，比速度。换源前后各跑一次：

apt-get download nginx

看 /var/cache/apt/archives/ 里落下来的文件用了多久。这比看 apt update 的总时长准，因为 update 里混着解压索引和写数据库的时间。

24.04 上就碰到过一回。照着教程改完 sources.list，apt update 一条报错都没有，速度也正常，以为成了。装包还是慢。grep -rn 一查，/etc/apt/sources.list.d/ubuntu.sources 里还写着 archive.ubuntu.com。apt 读的是那个文件，sources.list 里那几行根本没被读进去，没被读进去的东西当然不会报错。换源失败最安静的一种，就是这个样子。

有三个看起来生效其实没生效的假象：只改了 sources.list，但 24.04 读的是 ubuntu.sources；主源改了，sources.list.d 里的第三方源还连着官方；只改了 deb，deb-src 还指着老地址。

选哪家：按吞吐分三档

212.457、135.759、130.470、127.224、103.227、96.697，这六个是本次测下来能用的档位。清华、华为云、中科大、腾讯云、南京大学、上海交大，换源时从这六个里挑一个，都不会踩坑。

3.672 的网易 163 不建议。它比官方源快，但首字节 8.548 秒，比其他国内镜像慢一个量级。这个站早年口碑不错，现在的表现已经不在第一梯队。

0.116 的官方源不要留。哪怕懒得换，也把它注释掉，否则每次 apt update 都要在它身上耗一遍超时。

换源不是一锤子买卖。镜像站的目录结构改过，限速策略也变过，今天测出 212.457 的站，过半年可能掉下来。换源时留个记录，写清哪天换的、换的哪家、当时首字节和吞吐大概多少，下次觉得慢了好对比，也不至于怀疑到自己头上。

还有一件跟「换国内源更快」相反的事：机器如果在美国西部或者欧洲，换国内镜像要绕回来，路径比直连官方 CDN 长。国内镜像的加速是给国内出口的机器准备的，不是给所有机器准备的。判断方法很简单，换之前先拉一次官方源和候选镜像，看哪个快，一分钟的事，比事后怀疑自己换错了强。

手上还没有机器、想先看看别人测过的，按机房整理的机型测评 里有现成的记录，预算紧的可以先翻 各商家在跑的促销。机器定下来再回来换源，顺序别反，因为源能换，机房换不了。

常见问题

换源后 apt update 还是很慢怎么办

先确认真的生效了，用上面 grep 那一招看有没有残留的官方源。生效了还慢，瓶颈可能在出口带宽、磁盘 IO，或者在解压索引。8.4 MiB 的 Packages.xz 解压要占 CPU，1 核机器上这一步不便宜。换源只保证地址对，不保证快，这两件事得分开查。

Ubuntu 22.04 换源用哪个 codename

jammy。24.04 是 noble，20.04 是 focal。lsb_release -cs 直接给答案，不用记。

换源会不会影响已经装好的软件

不会。换源只改 apt 从哪里下载，不动已经装上的包。apt upgrade 才会动，那是另一件事，做之前想清楚。

换源之后原来的源还能恢复吗

能。改之前 cp 一份就行。没备份也能恢复，官方源地址是固定的，重写一遍即可。恢复完记得把 /var/lib/apt/lists/ 清掉，不然旧索引还会被当成有效数据。

Debian 10 换源一直 404 是怎么回事

buster 已经 EOL，官方把它挪到了 archive.debian.org，普通镜像站也陆续删了。要么指向 archive 并关掉有效期检查，要么升级到 bookworm。换源在这种老版本上帮不了你，得先解决版本本身的问题。

VPS 在国内，还需要换源吗

需要。国内机房连官方源一样要出国，一样丢包，只是比跨境机器好一点。换完收益多少取决于你的出口带宽，这一点比选哪家更关键。换源在这类机器上是稳赚的，因为原来的路本来就不通。

系统层的事理顺了，应用层还有一层。宝塔装不上多半是下载节点的问题，跟 apt 源不是一回事，宝塔面板安装与下载节点 讲的是那一层。想换机器的话，各家入口和付款方式整理在 商家入口。

现在打开终端，敲 grep -rn "deb.debian.org" /etc/apt/，没有输出就说明这次换源是干净的。