如果内网有大量的相同Linux操作系统，并且通过批量管理或者类似的手段在一定时间内同时安装相同的软件包，使用互联网镜像站可能会产生比较大的互联网传输，对提供开源镜像站的机构产生一定的负担，而此类类似的安装需求，在本地借助nginx反向代理缓存这部分静态内容。一个简单的思路分享，配置文件也比较简单，小修改下就可以适合http分发的各种安装源了。
proxy_cache_path /tmp/ levels=1:2 use_temp_path=off keys_zone=centosrpm:10m max_size=10g inactive=2h;
server {
listen 80;
server_name centos.mirrors.local;
access_log rpm.log main;
error_log rpm.err.log;
location / {
proxy_cache centosrpm;
proxy_pass https://mirrors.example./centos/;
}
}
一些可能的场景
- IPv6流量免费，而部分服务器只有v4网络，或者部分服务器限制公网请求
- 公共的开源镜像站速度比较缓慢。通过本地提供缓存提升大量安装的成功率，速度，可靠性
- 避免大量相似的请求开源镜像站，导致公网IP地址被镜像站屏蔽而无法访问站点
相对于通过Rsync或者reposync构建完整的镜像，不需要占用比较多的磁盘空间，消耗大量网络带宽资源。以CentOS 7为例。如果同步整个CentOS 7 目录“/centos/”，大约需要占用接近 500 GiB硬盘空间，初次同步的过程需要消耗接近 500 G的网络下行带宽，提供Rsync的开源镜像站往往是高校性质的，尽量还是让这些带宽更有意义一些吧。而互联网巨头们提供的镜像站普遍限速 100KB/s ~ 1MB/s 不等，甚至更容易出现限制请求，别提用reposync构建完整的镜像，哪怕是正常安装，也可能会短时间的出现 403 之类的错误，导致安装失败。比如某源就明文禁止用递归之类的方式下载建立自己的源。
而且即使只同步必要的os,updates,extras目录用于软件安装，也需要同步接近 70 G的内容。正常安装软件可能只需要访问一小部分文件，同步完整的目录只是增加不必要的互联网开销罢了。
提供的配置文件可以作为短时间大量重复安装相同软件的情况下提供本地缓存性质的安装源。如果需要长期运行，还有一些优化空间。例如访问的iso、deb、rpm之类的文件在几天到几年的时间范围内不会有变化，顶多版本切换后被删除，而描述的repodata类似的目录随时可能更新。可以给整个缓存指定一个比较长的缓存时间例如 10 天，然后给repodata路径单独指定一个较短的缓存时间例如2个小时，例如一些发行版建议镜像站与上游同步的频率为一天6次。或者反过来为特定后缀的 URI 提供超长缓存周期，例如指定文件夹路径，或者指定文件后缀名，而其他文件只缓存较短的事件。
在另外一种场景，如果安装源不提供自动化使用，软件更新完全通过手工进行，同样也可以每次启动前清空缓存。目前Linux发行版的国内用户应该是新的高峰，个人经验互联网巨头们的开源镜像站基本限速，高校除了清华v4被完全占满，部分带宽较大的高校镜像站点速度不错，而部分高校站点本来就是校外几乎不可用的状态，为了更好的体验，在局域网搭建一个缓存是我更常用的一个方案。