简介这份PDF文档面向企业级Linux运维人员、Ubuntu系统管理员及具备一定私有镜像搭建经验的技术人员针对封闭内网环境下软件包更新效率低、对外网依赖强的问题给出基于Ubuntu Server 24.04.1的APT内网源完整搭建思路。内容涵盖环境准备、阿里云或清华镜像源配置、apt-mirror参数调优如base_path、nthreads、数据同步与清理、Nginx离线安装及源发布、客户端sources.list.d替换等关键环节并涉及404权限排查与端口安全限制建议。资源包为1个PDF文件大小约894KB结构紧凑便于按章节查阅与实操对照。目前已有2022人学习适合需要在内网中实现高效软件分发、降低公网依赖并保障数据安全的运维场景参考。1. 内网 APT 源到底解决什么问题从一次批量部署翻车说起内网环境下基于 Ubuntu Server 24.04 的 APT 源搭建与配置本质上是把公网软件仓库“搬”进本地机房让几十上百台机器在断网或限速环境里也能正常apt install。我最早接触这个需求是某次给一个隔离网段批量装 40 台 Ubuntu Server 24.04结果apt update全部卡在archive.ubuntu.com超时装一台机器要等十几分钟最后靠一台一台手动挂 ISO 才勉强交付。那次之后我就把内网 APT 源当成标准动作来做。它适合三类人一是机房只有一台能出网的跳板机、其余机器全隔离的运维二是需要固定软件版本、防止上游仓库更新导致环境漂移的交付团队三是带宽紧张、几十台机器同时拉包会把出口打满的场景。核心思路不复杂——用一台能出网的机器把 deb 包和索引同步下来再用 HTTP 服务对内发布客户端把sources.list指过去就行。但真正落地时同步哪些组件、索引怎么签名、客户端怎么配每一步都有坑。2. 选型与同步策略apt-mirror、aptly 还是直接 rsync2.1 三种主流方案的能力边界内网 APT 源不是只有一种做法选错了后面维护会很痛苦。常见做法有三类我按实际用过的感受列一下。方案同步粒度是否保留完整仓库结构适合场景主要代价apt-mirror按组件/架构全量或过滤是和官方镜像一致需要完整 noble/noble-updates/noble-security磁盘占用大首次同步慢aptly按包名/版本精确拉取否自己建仓库只想要固定几个包、做版本快照需要理解 repo/snapshot 概念rsync 直拉目录级是已有上游镜像、只做二次分发依赖上游开放 rsync过滤麻烦如果目标是“让内网机器像用公网一样用 apt”apt-mirror 最省心因为它保留了dists/和pool/的完整结构客户端配置几乎不用改。aptly 更适合做“只同步我关心的包”比如只维护 nginx、docker、几个内部依赖磁盘能省一大截但你要自己处理依赖闭包漏一个依赖就装不上。2.2 用 apt-mirror 同步 noble 仓库的完整配置我一般会在能出网的机器上先建目录再改 apt-mirror 的配置。Ubuntu Server 24.04 的代号是 noble同步时至少覆盖noble、noble-updates、noble-security三个否则安全更新会缺。# 安装 apt-mirrorUbuntu 24.04 仓库里直接有 sudo apt update sudo apt install -y apt-mirror apache2 # 建镜像根目录磁盘最好单独挂一块后面会很大 sudo mkdir -p /srv/apt-mirror sudo chown -R apt-mirror:apt-mirror /srv/apt-mirror配置文件在/etc/apt/mirror.list关键是set base_path和deb行。下面这份是我常用的最小可用版本只同步 amd64省一半空间。# /etc/apt/mirror.list set base_path /srv/apt-mirror set nthreads 20 set _tilde 0 # 只拉 amd64如果内网有 arm 机器再加 arm64 deb-amd64 https://mirrors.tuna.tsinghua.edu.cn/ubuntu noble main restricted universe multiverse deb-amd64 https://mirrors.tuna.tsinghua.edu.cn/ubuntu noble-updates main restricted universe multiverse deb-amd64 https://mirrors.tuna.tsinghua.edu.cn/ubuntu noble-security main restricted universe multiverse # 清理不再需要的包避免磁盘无限涨 clean https://mirrors.tuna.tsinghua.edu.cn/ubuntunthreads设 20 是经验值再高对上游镜像不友好也容易触发限速。_tilde设 0 表示不把~当作特殊字符处理避免某些包名匹配异常。clean行必须和上面的 URL 一致否则旧包不会被回收。2.3 首次同步与定时更新配置好后直接跑同步第一次会很久几十 GB 起步建议放在晚上。# 首次全量同步前台跑方便看进度 sudo -u apt-mirror /usr/bin/apt-mirror # 同步完成后看目录结构确认 dists 和 pool 都在 ls /srv/apt-mirror/mirror/mirrors.tuna.tsinghua.edu.cn/ubuntu/看到dists/和pool/两个目录就对了。之后用 cron 每天凌晨增量同步一次apt-mirror 自己会比对索引只拉新增的包。# 加到 root 的 crontab每天 3 点增量同步 0 3 * * * /usr/bin/apt-mirror /etc/apt/mirror.list /var/log/apt-mirror.log 21增量同步的关键是 apt-mirror 会先拉Release和Packages索引再对比本地已有的 deb 文件所以第二次之后通常几分钟到十几分钟就能跑完。如果发现每次都拉很久先看日志里是不是某个组件索引一直 404多半是上游镜像路径写错了。3. 发布与客户端配置让内网机器真正用上3.1 用 Apache 发布镜像目录同步下来的目录要能被内网访问最省事的是 Apache 直接指向镜像根。Ubuntu 24.04 的 Apache 默认站点在/etc/apache2/sites-available/000-default.conf改DocumentRoot即可。# /etc/apache2/sites-available/000-default.conf VirtualHost *:80 ServerName apt.internal DocumentRoot /srv/apt-mirror/mirror/mirrors.tuna.tsinghua.edu.cn/ubuntu Directory /srv/apt-mirror/mirror/mirrors.tuna.tsinghua.edu.cn/ubuntu Options Indexes FollowSymLinks AllowOverride None Require all granted /Directory # 索引文件不大但 deb 包大开个缓存头减少重复请求 FilesMatch \.(deb|gz|xz)$ Header set Cache-Control public, max-age3600 /FilesMatch /VirtualHost改完sudo a2enmod headers sudo systemctl reload apache2。注意DocumentRoot要指到ubuntu这一层因为客户端配置里写的是http://apt.internal/ noble ...路径要对齐。3.2 客户端 sources.list 的两种写法内网机器的/etc/apt/sources.list.d/下新建一个文件把公网源注释掉或删掉。Ubuntu 24.04 默认用的是 deb822 格式的/etc/apt/sources.list.d/ubuntu.sources两种写法都支持。传统一行式# /etc/apt/sources.list.d/internal.list deb http://apt.internal/ noble main restricted universe multiverse deb http://apt.internal/ noble-updates main restricted universe multiverse deb http://apt.internal/ noble-security main restricted universe multiversedeb822 格式# /etc/apt/sources.list.d/internal.sources Types: deb URIs: http://apt.internal/ Suites: noble noble-updates noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg两种写法效果一样deb822 更清晰推荐新环境用。Signed-By指向系统自带的 Ubuntu 密钥环因为 apt-mirror 同步的是官方签名索引签名链没断不需要自己再签。3.3 验证与常见报错定位配完先sudo apt update看到Hit或Get来自apt.internal就说明通了。如果报NO_PUBKEY说明密钥环没对上检查Signed-By路径如果报404多半是Suites或Components写错去服务器上ls对应目录确认。# 在客户端确认源指向 apt-cache policy | grep apt.internal # 实际装一个包验证 sudo apt install -y curlapt-cache policy能看到优先级和来源如果内网源优先级低于公网源可能还是会走公网。可以在/etc/apt/preferences.d/里给内网源加Pin-Priority: 1001强制优先。4. 避坑与排查同步和发布阶段最容易翻车的 5 个点4.1 磁盘涨到 100% 才发现 clean 没生效现象跑了一周后/srv分区满apt-mirror报写入失败。原因clean行的 URL 和deb行不一致apt-mirror 认为没有需要清理的源。解决确保clean后面的 URL 和deb-amd64完全一致包括协议和路径改完手动跑一次apt-mirror触发清理。4.2 客户端 update 报 Hash Sum mismatch现象apt update提示某个Packages.gz哈希不匹配。原因同步过程中索引和包不同步或者 Apache 开了压缩但文件被截断。解决在服务器上重新跑一次apt-mirror让索引和包对齐检查 Apache 是否对.gz做了额外压缩FilesMatch里不要重复压缩已压缩文件。4.3 内网机器仍然走公网源现象配了内网源但apt install还是慢。原因/etc/apt/sources.list.d/下旧的公网源文件没删APT 会合并所有源。解决把ubuntu.sources或sources.list里的公网条目注释掉只留内网源用apt-cache policy确认优先级。4.4 同步到一半中断下次跑报锁冲突现象apt-mirror提示Unable to lock。原因上次异常退出留下了锁文件或进程。解决ps aux | grep apt-mirror确认没有残留进程删掉/srv/apt-mirror/var/apt-mirror.lock再重新跑。建议 cron 里加flock避免重叠。4.5 只同步了 main装桌面组件时缺包现象apt install某个包提示Unable to locate package。原因mirror.list里只写了main而包在universe或multiverse。解决把restricted universe multiverse补全重新同步对应组件的索引。如果磁盘紧张至少保留main和universe大部分常用包都在这两个里。5. 进阶技巧用 aptly 做版本快照与灰度发布apt-mirror 解决的是“有没有”aptly 解决的是“版本可控”。当交付要求“这批机器必须装 nginx 1.24.0不能是 1.24.1”时apt-mirror 的全量镜像做不到因为上游一更新你同步下来就是新版本。aptly 的思路是只把你需要的包拉进本地仓库打一个 snapshot客户端指向这个 snapshot版本就锁死了。先装 aptly 并建仓库sudo apt install -y aptly aptly repo create -distributionnoble -componentmain internal-noble把需要的包加进去可以从公网源直接拉也可以从 apt-mirror 的 pool 里导# 从公网拉指定包及其依赖 aptly repo add internal-noble nginx1.24.0-1ubuntu1 curl # 建快照快照是只读的版本不会变 aptly snapshot create internal-noble-20240601 from repo internal-noble # 发布快照生成可被 apt 使用的仓库 aptly publish snapshot -distributionnoble internal-noble-20240601发布后 aptly 默认在~/.aptly/public下生成仓库结构用 Apache 或 nginx 指过去即可。客户端配置和前面一样只是 URL 换成 aptly 的发布地址。关键区别是apt-mirror 的源会随上游变aptly 的 snapshot 不会适合做灰度——先发一个 snapshot 给测试机验证没问题再发生产。验证 snapshot 是否锁住版本# 查看快照里的包版本 aptly snapshot show internal-noble-20240601 # 客户端确认拿到的版本 apt-cache policy nginx如果apt-cache policy显示的候选版本和你 snapshot 里的一致说明锁定生效。我一般会保留最近三个 snapshot出问题能快速回滚到上一个。aptly 的坑在于依赖闭包——aptly repo add只拉你指定的包依赖要自己补漏了就在客户端报unmet dependencies。我的习惯是先在测试机apt install --dry-run跑一遍把缺的包名补进repo add再重新打 snapshot。这套组合用下来内网 APT 源就不再是“能装就行”而是变成可控的交付基线。希望帮到你。本文还有配套的精品资源点击获取