陈易铭作为运维，最头疼的场景之一就是：内网一堆Ubuntu机器等着装软件包，但外网带宽就那么大，几十台机器同时 apt update 的时候，能把出口堵得死死的。更别提某些离线网络环境，机器根本出不去，只能干瞪眼。我实战里的做法是搞一台镜像同步服务器，每天凌晨3点自动去上游拉取Ubuntu源，内网其他机器全部指向它。今天这篇就把这套从同步到发布再到客户端配置的完整链路拆开讲清楚，包含踩坑记录和优化细节。
1. 为什么选择自建同步源而不是直接换源
很多朋友一上来就想到“ubuntu换源”，把 /etc/apt/sources.list 改成阿里云或者清华源就完事了。这个操作在单机或者几台机器的情况下完全够用，速度也确实比官方源快很多。但一旦机器数量上了规模，或者网络环境属于隔离网段，直接换公网源就有几个绕不开的问题。
1.1 多机并发拉取的公网带宽压力
假设你有30台Ubuntu服务器，每台都配了阿里云源。平时还好，但在统一发版或者批量装软件的高峰期，30台机器同时去公网拉同一批 .deb 包，出口带宽瞬间被打满。实际上跑业务的内网流量也被挤占。相同的大版本更新，本地源只需要从公网拉一次，剩下的29台从内网走千兆甚至万兆，体感是完全不同的。
1.2 离线环境的刚性需求
还有一种更极端的场景——物理隔离的机房或者涉密内网，机器根本没有外网访问权限，这时候 “ubuntu挂载iso做本地源” 是很多人的应急方案。用Ubuntu安装ISO挂载出一个只读源，能解决系统安装后的一小部分基础包需求，但ISO里的软件包版本老旧、数量有限，连 docker-ce、nginx 这类常用软件都没有，更别提后续的 apt upgrade 安全更新了。
自建同步源不一样，它是rsync或apt-mirror从上游持续拉取整个仓库结构，包括 main、universe、multiverse 等组件以及对应的安全更新，Pull一次之后，内网就是一个完整且持续更新的软件仓库。
1.3 自建同步源的适用边界
写这篇之前先明确一下，自建同步源不是银弹。如果只是个人开发机或者三五台测试服务器，配一下阿里云源、华为云源，完全没必要折腾一台服务器天天跑同步。自建源更适合下面这些场景，你可以对照一下：
- 内网服务器数量超过10台，且有统一运维管理诉求
- 网络架构中有DMZ区或离线区，需要定期向隔离网段推送软件包
- 对软件包版本有审计需求，需要固定某个时间点的仓库快照
- 出口带宽紧张，希望把重复流量收敛到内网
以上条件满足任意两条，就值得把这套方案落地。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 同步链路设计：上游选择与同步工具选型
整体架构其实很简单：一台有外网访问权限的服务器（同步机），配置定时任务每天凌晨同步Ubuntu官方源或国内镜像源，同步完成的数据存放到本地目录，再通过Nginx或Apache把这个目录以HTTP形式暴露出去，内网其他机器的apt源地址指向这台同步机。
2.1 上游源选哪个更省流量
既然是自己搭源，上游选得不好，每天凌晨的rsync流量会很难看。官方源（archive.ubuntu.com）虽然数据最全，但服务器在欧洲，跨洋同步的稳定性和速度都不理想。国内更推荐下面几个：
| 上游源 | 同步地址 | 特点 |
|---|---|---|
| 阿里云 | rsync://mirrors.aliyun.com/ubuntu/ |
速度快，国内访问延迟低，支持rsync协议 |
| 清华TUNA | rsync://mirrors.tuna.tsinghua.edu.cn/ubuntu/ |
更新频率高，带宽充足，教育网优先 |
| 中科大USTC | rsync://rsync.mirrors.ustc.edu.cn/releases/ |
同步策略较为保守，稳定性好 |
| Ubuntu官方 | rsync://archive.ubuntu.com/ubuntu/ |
数据最完整，但跨洋同步慢 |
我这边之前用的是清华源，后来切了阿里云。原因很实际：阿里云的rsync并发限制没那么严格，凌晨同步的带宽跑得起来，清华源偶尔会遇到连接被重置的情况。另外要注意，如果你需要同步ports（ARM、RISC-V等架构的软件包），上游地址要选对应架构的路径，标题和这里默认讲解amd64架构。
2.2 工具选型：rsync与apt-mirror的取舍
同步工具主流有两个方案，一个是传统的 rsync 直接拉取，另一个是 apt-mirror 工具。很多教程会推荐apt-mirror，但我实际用了两年后，最终更倾向于纯rsync脚本，原因下面展开说。
apt-mirror 的原理是解析源列表里的Packages索引文件，然后根据索引逐个下载 .deb 包。它的好处是灵活，可以只同步某一个组件或者某一个架构。但坑也很明显：索引解析偶尔会因为上游Packages文件更新中的异常而中断，而且apt-mirror的断点续传能力比较弱，一旦同步中途断掉，重新跑的时候容易重复下载大量包。
rsync 是文件级增量同步，它的思路是直接把上游整个 dists 和 pool 目录结构与本地做一个镜像，每次同步只传输有变化的文件。配合 --delete 参数还能自动清理上游已经删除的旧包，长期跑下来目录不会越来越臃肿。对于“每天定时同步”这种场景，rsync的增量特性比apt-mirror的逐包下载效率高很多，尤其是软件包数量上万之后，这个差距非常明显。
所以我的方案是：rsync做主力同步，apt-mirror备用。后面会给出我实际使用的rsync同步脚本，里面有一些非默认参数的取舍，是实战中调优的结果。
2.3 同步目录的空间规划
这一个坑，我最早是没重视的。Ubuntu完整仓库（amd64 + i386 + 源码包）同步下来，体积是逐年膨胀的。以Ubuntu 24.04（Noble）为例，仅amd64架构的二进制包，完整同步一次大约需要500GB到700GB，如果再把源码包一起同步，总量轻松突破1TB。加上我上面要求保留历史版本，pool 目录里同一软件的多版本会同时存在，实际占用空间更大。
规划同步目录时，建议按下面的容量评估方式来：
bash复制# 只同步amd64二进制包（不含