简介面向企业级Linux运维与IT管理人员这份PDF指南系统讲解在Ubuntu Server 24.04.1上搭建内网APT源的完整流程内容涵盖环境准备、阿里云/清华镜像源选择、apt-mirror同步机制、Nginx发布服务以及客户端源替换能够直接解决封闭网络下软件更新与部署效率低的痛点。资源包为单个PDF文件大小仅894KB适合作为运维手册随时查阅。指南从mirror.list的base_path、nthreads等核心参数配置讲起逐步演示apt-mirror同步、clean.sh清理以及Nginx离线安装、软连接创建和404权限排查等要点帮助读者避开常见坑点。完成发布后客户端只需修改sources.list.d中的源地址即可切换到内网源不再依赖公网既能提升更新效率也有利于敏感数据的安全管控满足定制化交付需求。文档思路还可复用于pip、yum等其他内网镜像源搭建目前已有2026人学习下载适合需要保障数据安全、提升隔离环境运维效率的团队参考。1. 内网 APT 源搭建为什么 Ubuntu 24.04 的下一台机器要绕过公网内网装个包最烦的不是 apt 报错而是报错之后你才意识到公网根本不通。某实验室的十几台 Ubuntu Server 24.04 就是这种状态有的机器要装编译环境有的机器要补安全更新全靠运维拿移动硬盘来回拷贝 deb装一个软件依赖链能断三次。把 APT 源搬进内网用一台有公网权限的机器同步上游镜像再通过 Nginx 发布成局域网地址客户端把 sources 改成内网 IP整个更新链路就闭环了。这个方案不挑网络规模几台到几百台都适用前提是按 Ubuntu 24.04 的 noble 仓库和 deb822 源格式来搭。下面这份搭建过程每一步都是可以直接照着敲的。2. 同步前的选型与安装上游源怎么选、ARM64 怎么处理、apt-mirror 参数怎么设2.1 上游镜像站选型阿里源、中科大源与 Tuna 帮助页的取舍内网 APT 源的根子是上游公网源选错上游源后面所有同步和发布都跟着返工。项目里给出了三条主流路径阿里云源、中科大源、Tuna 镜像站。三者的仓库结构基本一致都提供 noble 的 main、restricted、universe、multiverse 四个组件差别主要体现在协议、速度和帮助文档的完整度。选择上游源时我一般优先看三条第一是否支持 https 同步公网环境下明文 http 同步 Packages 索引容易被中间人篡改第二组件是否覆盖 security、updates、backports、proposed 这几个发行版通道第三镜像站本身有没有提供 Ubuntu 24.04 对应的帮助页方便核对 codename 和架构。Tuna 的 ubuntu 帮助页和 ubuntu-ports 帮助页写得最规范ARM64 环境下基本靠它来对照参数。上游源配置文件中主机名协议适用场景阿里源mirrors.aliyun.comhttps国内同步速度快项目默认主选中科大源mirrors.ustc.edu.cnhttp/https与阿里源二选一作为备用Tuna 源mirrors.tuna.tsinghua.edu.cnhttps帮助文档最完整适合查架构参数实际部署中我只保留一个主源加一个干净条目不把三个源全塞进 mirror.list。原因很简单apt-mirror 是按 upstream 主机名分目录存储的混用多个源会导致 disk 占用翻倍而且 clean.sh 执行时容易误删另一套源的文件。项目正文里阿里源和中科大源明确标注了「二选一」这就是经验之谈——同步源只要一个另一个留着做故障转移就够了。2.2 架构匹配AMD64 走 ubuntu 仓库ARM64 必须走 ubuntu-portsUbuntu 24.04.1 的 noble 仓库在架构上是分家的。AMD64 的二进制索引放在常规 ubuntu 仓库里而 ARM64、riscv64 等非主流架构的包统一放在 ubuntu-ports 仓库。这一点在 Tuna 镜像站的帮助页里区分得很清楚/help/ubuntu/对应 AMD64 的源/help/ubuntu-ports/对应 ARM64 的源。如果内网同时存在 AMD64 和 ARM64 两种客户端最容易犯的错是在 mirror.list 里只配一个 ubuntu 源然后发现 ARM64 机器 apt update 报「架构不支持」。这是因为常规 ubuntu 仓库的 binary-arm64 索引根本不存在。最省心的做法是拆成两个 mirror.list 分别同步一份给 AMD64指向常规 ubuntu 仓库一份给 ARM64指向 ubuntu-ports 仓库存储路径用不同的 base_path 隔离。后面章节的配置以 AMD64 为主线ARM64 只需把 URL 主机名换成 ubuntu-ports 对应地址其余参数完全一致。2.3 安装 apt-mirror 并校准 mirror.list 参数在有公网权限的同步机上先安装工具再改配置apt-get update apt-get install -y apt-mirror vim /etc/apt/mirror.list安装后系统会生成一份默认配置注释里包含了所有可用参数。项目正文用的是一份精简后的配置把它整理成可直接落地的版本############# config ############# set base_path /var/spool/apt-mirror set mirror_path $base_path/mirror set skel_path $base_path/skel set var_path $base_path/var set cleanscript $var_path/clean.sh set defaultarch amd64 set nthreads 20 set _tilde 0 ############# end config ########### deb https://mirrors.aliyun.com/ubuntu noble main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu noble-security main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu noble-updates main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu noble-proposed main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu noble-backports main restricted universe multiverse clean https://mirrors.aliyun.com/ubuntu配置里有几个参数值得单独说。base_path是镜像存储根目录默认 8GB 左右的空间只够存索引完整同步含 pool 包通常会到几十 GB同步前先df -h确认磁盘余量。nthreads是下载线程数不是 CPU 线程数同步瓶颈在上游带宽20 是带宽和上游限流之间的平衡点调到 100 以上容易被镜像站断开连接。_tilde 0表示文件名中的~不做百分号转义保持 0 即可改动了反而可能让部分软件包文件名和索引对不上。deb 行里的noble是 Ubuntu 24.04 的 codename从 security 到 backports 五条对应五个发行版通道一般主用前三条就够了proposed 是预发布包日常内网源不建议全量同步体积大且不稳定。clean条目必须和同步源完全一致这条规则在后面 clean.sh 部分会再次出现。3. 执行同步与目录验收apt-mirror 首次运行到 clean.sh 的完整闭环3.1 执行首次同步前台命令、日志定位与断点处理配置写完后执行同步命令本身很简单sudo apt-mirror首次同步会把 noble 五个通道的索引和二进制包全部拉下来耗时取决于网络带宽。项目正文里这一步直接前台执行我建议在终端会话容易断开的场景下用 nohup 挂后台sudo nohup apt-mirror /var/spool/apt-mirror/var/sync.log 21 apt-mirror 自己的运行日志在$base_path/var/apt-mirror.log也就是/var/spool/apt-mirror/var/apt-mirror.log同步过程中遇到连接超时、磁盘写满都能在这里看到具体是哪条 URL 出的问题。网络中断导致的同步失败不用慌apt-mirror 是逐文件镜像重跑一次会自动跳过已存在的文件这一点比重新拷 U 盘省心得多。同步完成的标志是终端出现apt-mirror has finished同时 sync.log 里不再有新的下载记录。此时不要急着发布先用du -sh /var/spool/apt-mirror/mirror看一下实际体积再检查目录结构是否完整。3.2 clean.sh 的作用与执行时机为什么同步完还要手动清理apt-mirror 同步完成前终端会提示类似Run /var/spool/apt-mirror/var/clean.sh for this purpose的信息这一步很容易被忽略。clean.sh 的作用是清理上游已经删除的旧版本软件包它的判断依据是 mirror.list 里的 clean 条目。如果不清洗内网源的体积会随着每次增量同步持续膨胀几个月后磁盘会被大量废弃版本占满。执行方式cd /var/spool/apt-mirror/var ./clean.sh这里有一个我在真实环境里踩过的坑clean 条目必须和同步源指向同一个仓库。如果同步用的是阿里源clean 行却写成中科大源clean.sh 会拿中科大源的索引去比对本地阿里源的文件把阿里源比中科大源多出来的包全部当成「废弃文件」删掉。所以 clean 行要么不写要写就必须和 deb 行同源。项目正文里同步配置用阿里源、clean 条目用中科大源实际落地时建议统一成同一个源。3.3 发布前目录验收确认 Release 文件与 Packages 索引就位clean.sh 执行完后在$base_path/mirror下会生成以上游主机名命名的目录典型结构是/var/spool/apt-mirror/mirror/mirrors.aliyun.com/ubuntu/下面挂着 dists 和 pool 两个核心目录。dists 存仓库索引pool 存实际的 deb 软件包。发布前做三个快速检查避免上线后客户端反复报错ls /var/spool/apt-mirror/mirror/mirrors.aliyun.com/ubuntu/dists/noble/ ls /var/spool/apt-mirror/mirror/mirrors.aliyun.com/ubuntu/dists/noble/main/binary-amd64/Packages.gz du -sh /var/spool/apt-mirror/mirror/mirrors.aliyun.com/ubuntu第一条命令确认 noble 的 Release 文件和各组件目录存在第二条确认 AMD64 架构的 Packages 索引真正落盘apt update 时依赖的就是这个文件第三条看总大小判断同步是否完整。如果binary-amd64目录缺失多半是 mirror.list 里set defaultarch amd64没生效客户端配置好源后 update 会直接 404。目录验收没有问题再进入 Nginx 发布环节。4. Nginx 1.24.0 离线发布deb 批量安装、软链接与 autoindex 配置4.1 离线安装 Nginx 1.24.0依赖包清单与批量 dpkg 技巧内网同步机上往往不允许直接连公网 apt 源Nginx 需要走离线安装。项目正文用的是 Ubuntu 官方仓库里的 Nginx 1.24.0 版本对应 2ubuntu7.1 构建号依赖关系比源码编译简单得多。需要的 deb 包一共八个libgeoip1t64_1.6.12-11.1build1_amd64.deb libnginx-mod-http-geoip_1.24.0-2ubuntu7.1_amd64.deb libnginx-mod-http-image-filter_1.24.0-2ubuntu7.1_amd64.deb libnginx-mod-http-xslt-filter_1.24.0-2ubuntu7.1_amd64.deb libnginx-mod-mail_1.24.0-2ubuntu7.1_amd64.deb libnginx-mod-stream_1.24.0-2ubuntu7.1_amd64.deb nginx_1.24.0-2ubuntu7.1_amd64.deb nginx-common_1.24.0-2ubuntu7.1_all.deb把这些文件放在同一个目录下批量安装mkdir -p /root/nginxsetup # 将上述 deb 包上传到 /root/nginxsetup 目录 dpkg -i /root/nginxsetup/*.debdpkg 批量安装时会先统一解析所有 deb 的依赖关系再逐个展开配置所以只要八个包齐全通常不会出现「先装主包、依赖未就绪」的顺序问题。如果 dpkg 仍然报缺依赖比如libssl3或libpcre2版本不满足用apt --fix-broken install补一次或者从外网机用apt-get download补对应基础库。安装完成后启动服务systemctl start nginx systemctl enable nginx启动后先systemctl status nginx确认 active 状态再curl -I http://127.0.0.1看是否返回 200。注意项目正文提到的「新建 nginx 用户」只在源码编译安装时需要apt 离线包安装会自动创建 nginx 服务账号这一步不需要手工干预。4.2 发布目录与软链接mirror 目录映射到 Web 根路径apt-mirror 同步出来的仓库不在 Nginx 默认的 Web 根目录下直接用 root 参数指向/var/spool/apt-mirror会让配置变得很丑而且该目录层级默认对 Nginx 用户不可读。项目正文的做法是在 Web 根目录建软链接这是发布环节最省事的方案ln -s /var/spool/apt-mirror/mirror/mirrors.aliyun.com /var/www/mirror链接建好后访问路径就是http://服务器IP/mirror/ubuntu/dists/noble/...。注意软链接的源路径里是mirrors.aliyun.com带字母 s因为 apt-mirror 是按 mirror.list 里 deb 行的完整主机名建目录的少写一个 s 链接就指向不存在的路径。如果/var/www/mirror下没有出现ubuntu目录先ls检查链接源路径是否正确。链路权限是这个模块的高频故障点。/var/spool、/var/spool/apt-mirror默认权限可能是 700Nginx 的 www-data 用户没有进入权限访问时会返回 403。执行下面命令把上层目录的进入权限放开chmod ox /var/spool /var/spool/apt-mirror chmod -R orX /var/spool/apt-mirror/mirror/mirrors.aliyun.com第一行给上层目录加执行权限第二行给镜像目录加递归读权限。orX中的大写 X 目录才会加执行位普通文件只加读位不会破坏包的权限结构。4.3 修改 default 站点配置autoindex 与 root 重定向Ubuntu 24.04 的 Nginx 默认站点配置在/etc/nginx/sites-enabled/default这里做两处修改root 指向/var/www开启 autoindex 目录列表。完整配置片段server { listen 80 default_server; listen [::]:80 default_server; root /var/www; index index.html; autoindex on; location / { try_files $uri $uri/ 404; } }保存后重载配置nginx -t systemctl restart nginxroot /var/www是为了让/mirror软链接落在 Web 可访问范围内autoindex on不是 apt 客户端必需的功能apt 请求的是具体文件路径但有了目录列表浏览器打开http://服务器IP/mirror/ubuntu/dists/能直接看到 noble 目录人工验收发布结果非常直观。nginx -t是改配置后必做的语法检查配置有误时 systemctl restart 会失败先跑这一句能少走弯路。重启后浏览器访问出现目录列表说明发布链路已经通了接下来就是客户端的接入。5. 避坑指南内网源上线前最容易翻车的五个细节5.1 客户端 apt update 报 404 NotFound现象客户端把源改成内网地址后执行apt update部分条目返回 404软件列表拉取不完整。原因404 的本质是请求的索引路径在内网源上不存在。常见有两种情况一是同步时只抓了 main 组件客户端配置里却启用了 universe、multiverse对应索引自然缺失二是set defaultarch amd64没有生效导致 dists 下缺少 binary-amd64 目录。解决先登录内网源服务器确认/var/spool/apt-mirror/mirror/mirrors.aliyun.com/ubuntu/dists/noble/下存在main/binary-amd64/Packages.gz再核对客户端源配置里的组件列表去掉不存在的组件条目。配置里保留 main、restricted、universe、multiverse 四个组件前提是同步时也把它们全部列入 deb 行。5.2 客户端报 NO_PUBKEY 或签名验证失败现象apt update 提示The following signatures couldnt be verified because the public key is not available: NO_PUBKEY ...更新直接中止。原因内网机器没有导入 Ubuntu 官方源的签名公钥。正常情况下客户端从 Ubuntu 官方源拉取时系统自带的 ubuntu-keyring 包已经包含了官方公钥但如果内网机器是从精简镜像安装的或者 keyring 被清理过就会缺签名。解决从任意一台能正常访问 Ubuntu 官方源的机器上拷贝/etc/apt/trusted.gpg.d/目录下的 ubuntu-keyring 文件到内网客户端对应目录重启 apt update。不要手动从公网下载公钥内网机器访问不了公网拷贝 keyring 文件是最可控的方式。5.3 浏览器访问返回 403 Forbidden现象Nginx 启动正常但访问http://服务器IP/mirror/返回 403Nginx 错误日志里有 permission denied。原因403 不是 Nginx 配置错误而是 www-data 用户对镜像目录的上层路径没有执行权限。/var/spool层目录权限过严导致 Nginx 无法进入链接指向的物理目录。解决执行chmod ox /var/spool /var/spool/apt-mirror对 mirror 目录做chmod -R orX。检查软链接是否完整ls -l /var/www/mirror确认目标路径真实存在。权限调整后不需要重启 Nginx刷新页面即可验证。5.4 离线安装 Nginx 时 dpkg 报依赖错误现象执行dpkg -i /root/nginxsetup/*.deb后输出大量dependency problemsNginx 主包安装失败。原因离线 deb 包不完整或者内网系统缺少 Nginx 运行所需的底层库比如 libssl3 版本过低、libpcre2 未安装。项目正文给出的八个 deb 只覆盖 Nginx 自身及其模块依赖基础运行库需要系统本身满足。解决先执行apt-get update看内网机是否已有可用的本地源如果有直接apt-get -f install自动补依赖。如果没有用外网机apt-get download按报错提示补齐缺失库重新放回 nginxsetup 目录再执行批量安装。依赖错误会一次性列出多个缺失包逐个补齐即可。5.5 软链接指向错误mirror 与 mirrors 之差现象软链接建好后访问/mirror/ubuntu/一直 404服务器上ls /var/www/mirror显示空目录。原因apt-mirror 生成的目录名是 mirror.list 中 deb 行的完整主机名。阿里源的完整主机名是mirrors.aliyun.com带字母 s而手工输入路径时经常写成mirror.aliyun.com少一个 s 链接就指向不存在的路径目录自然为空。项目正文里两种写法混用实际落盘目录以ls -l /var/spool/apt-mirror/mirror/的输出为准。解决执行ls /var/spool/apt-mirror/mirror/查看真实目录名用输出结果重新创建软链接删除错误的链接再建一次。这个检查最好放在同步完成后立即做避免发布时再排查。6. 客户端接入与完整性验证ubuntu.sources 改 IP 后还要做这两件事Ubuntu 24.04 的客户端源配置已经从旧的/etc/apt/sources.list迁移到了 deb822 格式的/etc/apt/sources.list.d/ubuntu.sources直接改 sources.list 在本版本上不生效。登录内网客户端先备份再替换sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak sudo sed -i s#https://mirrors.aliyun.com/ubuntu#http://内网服务器IP/mirror/ubuntu#g /etc/apt/sources.list.d/ubuntu.sources sudo apt updatesed 的分隔符用#而不是/是为了避免 URL 里的斜杠把命令拆碎。替换时注意 URL 路径是/mirror/ubuntu对应 Nginx 软链接的路径结构。apt update 执行后观察输出是否全部命中内网源地址出现Hit表示索引拉取成功出现404就回到上一章的 5.1 排查。update 通过后做一次完整性验证会更稳妥。推荐用apt-get download拉取一个常用包比如apt-get download htop然后计算校验值apt-get download htop sha256sum htop_*.deb再到内网源服务器上对 pool 目录里同名文件执行 sha256sum两边结果一致说明二进制包在同步和传输过程中没有损坏。这个验证能过滤掉大部分「索引能拉到但包装不上」的玄学问题。从那以后我每次搭内网源都强制走一遍完整链路同步、clean.sh、目录验收、Nginx 发布、客户端 update、单包下载校验六步缺一不可。尤其是 clean.sh第一次搭源时偷懒跳过三个月后磁盘被旧版本塞满客户端 update 越来越慢最后只能推倒重来。这套流程走一遍后续维护几乎不用再操心希望帮到你。本文还有配套的精品资源点击获取