做开发这些年我发现一个特别常见的现象明明源码在GitHub上放得好好的可一到关键时候clone个仓库慢得像蜗牛爬发布包里动辄几百MB的依赖资源下载到一半还给你断连。尤其是一个团队里几个人同时拉同一份代码简直是在浪费生命。后来我索性把常用的GitHub资源做成了一套GitHub镜像站团队内部、个人电脑、CI流程全都往这个通道上走速度快了不少带宽也省下来了。这篇文章不纸上谈兵直接把我自己搭的一套镜像站方案完整拆开怎么选型、怎么配转发、怎么加缓存、怎么让它在实际下载中真的又快又稳踩过的坑也会一并写出来。无论你是刚接触GitHub的新手还是负责团队基础设施的工程师按着这篇文章的思路往下走基本都能落地。1. 先想清楚镜像站到底解决什么问题1.1 三个最痛的场景先说最常见的情况。项目拉到后期大家基本都被三类事情卡过时间。一是大文件与发布包下载。GitHub Releases里放了不少二进制包、安装包、模型文件动不动几百MB。这些文件不走Git协议全是HTTP流式下载如果链路质量一般速度会忽高忽低。我之前碰到过一个内网团队每次部署都要从Releases里拉一个600多MB的软件包十几个人排队下载一整天都在等。二是团队重复拉取。三五个开发每天反复clone同一个仓库每个人的机器都各自向GitHub发起一次完整请求。同一个仓库同一条网络链路同一个文件被几十次重复下载时间和带宽全浪费了。更无奈的是这种浪费没有上限新同事入职第一天就要把整套仓库克隆一遍。三是CI/CD构建机需要拉源码。构建机每次构建都要重新从GitHub拉仓库如果构建节点多同一个源码包会在很短时间内被多个节点同时请求构建排队时间肉眼可见地涨。构建失败重试时仓库又要重新拉一遍。镜像站的价值就是把“每个人独立从GitHub拉取”变成“先从就近镜像拉镜像服务器自己负责和GitHub保持同步”。把原本各走各路的请求折叠成一个共享出口在资源密集型研发场景里非常划算。这就好比你家里给每个房间都单独接了水管水量自然紧张不如先在小区入口修一个蓄水池大家从这个池子里取水水源压力就小很多。1.2 三种形态怎么选成熟一点的团队往往不止做一种镜像但我建议你先从最低成本的开始。大致有这三类加速下载型以转发加缓存为主核心是缓存静态文件。部署简单适合个人或团队内部。Git clone类操作也能覆盖但需要把raw域名也一起处理。仓库备份型把某个开源仓库定期同步到自己的托管平台比如Gitee、自建GitLab等平时就用自己的仓库地址clone。可靠性高但同步存在一定延迟。企业缓存型类似本地Git缓存服务粒度更细支持仓库级缓存和认证适合构建机多的团队。部署成本高一点。我把它们放在一起做了个对比。形态适用场景优点注意点加速下载型转发缓存个人、小团队轻量使用部署快、代码量少、缓存命中后提升明显需要域名和SSL防滥用策略要跟上仓库备份型同步至Gitee、GitLab开源项目维护、需要稳定源码不依赖GitHub链路实时速度可靠不是实时同步镜像仓库别当工作仓库企业缓存型本地Git缓存服务CI/CD构建集群、多人协作仓库仓库级缓存命中率高认证可做在内部需要维护较复杂的服务我最终实践下来最出效果的是“加速下载型”加一层“仓库备份”的组合。前者解决重文件下载后者解决日常clone源码。这两种都不难下面重点讲。1.3 选型决策回看早期我也做过一个过度设计一开始就想上一套企业级Git缓存系统结果配置了两个星期团队成员还是习惯用原始地址。后来我调整了策略先用一个最简单的Nginx转发跑起来观察一周访问日志发现流量集中在Releases下载和少量仓库的clone这才明确优化方向。如果你刚接触这个领域建议也别一上来就追求完美。先抓主要矛盾能下载、能缓存、速度起来就够了。2. 核心细节与关键选型2.1 域名、证书与解析顺序镜像站必须绑定一个正式的域名。IP直连不是不行但涉及SSL证书和SNI时非常麻烦。我用的是自己名下的二级域名给镜像站单独开一个子域例如mirror.example.com同时给raw下载另开一个raw-mirror.example.com。域名解析先做好把两个子域都指向服务器的公网IP等解析生效后再去申请证书。证书这块直接用Lets Encrypt免费证书三个月自动续期配合certbot的定时任务就能无感运行。申请证书时注意可以用DNS-01或HTTP-01但多域名证书要用-D配合。我习惯给两个子域签一张SAN证书这样管理起来省事。这里有一个非常隐蔽的细节GitHub的仓库页和raw下载是不同域名。如果只转发github.com那么你在页面上点“Download ZIP”时跳转链接可能指向codeload.github.com这又是一层。所以在规划阶段就把镜像域名的“影子域名”想好一个主域名对github.com一个raw域名对raw.githubusercontent.com必要时再加一个codeload域名对codeload.github.com。否则配置到一半发现缺域名来回补配置很容易漏。2.2 转发工具选型Nginx还是Caddy这类需求最主流的方案是Nginx配置语法大家都熟缓存模块也完善。Caddy的优点是自动申请和续期证书少写不少基础代码但它在细粒度缓存策略上不如Nginx直观。我最后选了Nginx。如果你不想自己维护证书可以在Nginx前面再套一层Caddy让Caddy只负责终止TLS和转发但那种组合更多余。直接Nginx加上certbot简洁可靠。我的取舍逻辑很简单镜像站是长期运行的基础设施Nginx更稳、排查手段更多。特别是proxy_cache机制Nginx的命中状态能直接在响应头里看。Caddy虽然能配http.cache但生态和文档还是差一截。2.3 缓存策略设计缓存是镜像站的核心做得不好就只是“转发”没有速度优势。我把缓存对象分成三类Releases包、zip/tar包等大文件这些是静态的内容基本不变可以放心缓存缓存时间设置长一些比如7天。仓库页面HTML需要看到更新所以缓存时间要短比如几十秒或直接关闭HTML缓存。如果你只是给内部拉代码我建议干脆不缓存仓库首页那些HTML避免看到旧版本。raw源文件、API响应适中缓存1到10分钟之间避免过于频繁地穿透到源站。在Nginx里我用proxy_cache_path定义一个共享缓存目录再按不同location设定proxy_cache_valid。具体参数在第3章的配置里会看到。这里先提一个坑千万别把动态路径和静态文件放在同一个缓存层级里否则一个带认证的请求被缓存下来之后所有人拿到的都是过期内容。2.4 动态请求与静态请求的分离我在生产上见过不止一次翻车现场把GitHub页面完整转发到内网镜像结果页面上的HTML被长期缓存README永远是三天前的。为什么因为页面HTML里包含大量的动态元素比如“Star数”“最近提交时间”它们每次请求都可能不同。镜像站真正回报率高的是那些“不变资源”Release压缩包、仓库内静态文件、raw文件。所以我在设计时就做了切割转发github.com的配置里对HTML几乎不做长缓存对Release下载路径做出长达7天的缓存。这样既不会误导用户又能在重负载时保住下载通道的速度。这个思想也可以推广到其他任何“缓存型镜像”项目不只是GitHub镜像站。2.5 安全与防滥用镜像站一旦用起来很容易被搜索引擎或同事扩散出去变成公共下载站。流量暴涨是小问题源站可能因此限制你的IP那才是大问题。我的建议能内网就内网开放到公网至少要做访问频率限制限速条目也要配置避免单用户把带宽吃满。可以在header里加一个“只允许指定Referer”的单级限制但别只依赖header因为命令行下载工具根本不带Referer。下面这些防护点我会在配置里逐个落地limit_conn限制单IP并发连接数。limit_req限制请求频率。limit_rate对下载速度做上限。配合Nginx的access_log做流量统计。3. 从零动手加速下载型镜像站实操3.1 准备工作一台能正常访问GitHub的服务器这个是前提。如果只在内网使用2核2G就够如果要服务更多同事或CI节点建议4核8G起。域名提前规划好并完成DNS解析。系统用Ubuntu或Debian都可以下面以Ubuntu 20.04为例。磁盘建议单独挂一个数据盘给缓存目录因为缓存文件增长非常快。我第一次只用系统盘两周后就报警了。apt update apt install -y nginx nginx-extras certbot python3-certbot-nginx curl wgetnginx-extras是可选但多了一些headers和缓存相关的扩展建议装上。certbot用于申请证书初学者建议直接用它绑定的Nginx插件一条命令完成证书和Nginx配置改写。3.2 准备证书先用certbot把证书申请好。假设域名为mirror.example.com和raw-mirror.example.comcertbot certonly --webroot -w /var/www/html \ -d mirror.example.com -d raw-mirror.example.com成功后证书会放在/etc/letsencrypt/live/目录下。如果你不想手动配webroot也可以直接运行certbot run -a standalone -d mirror.example.com -d raw-mirror.example.com但standalone模式要求暂时停掉Nginx或者先停掉80端口占用。我习惯用webroot方式不影响在线服务。3.3 转发配置核心server块下面是我实际用的核心配置去掉无关冗余后是这个样子proxy_cache_path /data/cache levels1:2 keys_zonegithub_cache:10m max_size20g inactive7d use_temp_pathoff; limit_conn_zone $binary_remote_addr zoneconcurrent:10m; limit_req_zone $binary_remote_addr zonereq:10m rate5r/s; server { listen 443 ssl http2; server_name mirror.example.com; ssl_certificate /etc/letsencrypt/live/mirror.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/mirror.example.com/privkey.pem; # 正常页面入口对HTML短缓存 location / { proxy_pass https://github.com; proxy_set_header Host github.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_ssl_server_name on; proxy_ssl_name github.com; proxy_set_header Accept-Encoding ; proxy_cache github_cache; proxy_cache_valid 200 301 30s; proxy_cache_key $host$scheme$request_uri; add_header X-Cache-Status $upstream_cache_status; limit_req zonereq burst10 nodelay; } # Release大文件走长缓存 location ~* \.(zip|tar|gz|tgz|exe|dmg|pkg|deb|rpm|jar|whl|bin)$ { proxy_pass https://github.com; proxy_set_header Host github.com; proxy_set_header X-Real-IP $remote_addr; proxy_ssl_server_name on; proxy_ssl_name github.com; proxy_set_header Accept-Encoding ; proxy_cache github_cache; proxy_cache_valid 200 301 7d; proxy_cache_key $host$scheme$request_uri; add_header X-Cache-Status $upstream_cache_status; limit_conn concurrent 5; limit_rate 100m; } }有几个细节要重点解释。第一proxy_pass指向https://github.com后客户端看到的URL还是mirror.example.com/xxx。但页面里如果硬编码了github.com绝对路径浏览器会直接请求原始域名绕开镜像。这也是为什么我建议镜像站只负责下载路径不去转发完整页面。第二proxy_set_header Accept-Encoding 的作用是关闭上游压缩。Nginx缓存的是上游返回的原始字节如果源站根据客户端的不同Accept-Encoding返回不同内容缓存键就会分裂。关掉压缩后缓存命中率一下就上来了。第三add_header X-Cache-Status让响应头里带上缓存命中状态。我习惯在所有缓存配置里都加上这个头排查问题太方便了一个curl -I就能知道是命中还是穿透。3.4 raw下载加速服务配置git clone时从GitHub拉大对象走的主要是raw.githubusercontent.com或codeload.github.com。给raw做一个独立子域配置思路一样server { listen 443 ssl http2; server_name raw-mirror.example.com; ssl_certificate /etc/letsencrypt/live/mirror.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/mirror.example.com/privkey.pem; location / { proxy_pass https://raw.githubusercontent.com; proxy_set_header Host raw.githubusercontent.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_ssl_server_name on; proxy_ssl_name raw.githubusercontent.com; proxy_set_header Accept-Encoding ; proxy_cache github_cache; proxy_cache_valid 200 301 24h; proxy_cache_key $host$scheme$request_uri; add_header X-Cache-Status $upstream_cache_status; } }如果你愿意深度定制还可以把仓库页和raw内容合并到同一个子域用不同路径区分比如/mirror/raw/。但这样会牵扯到Git内部把URL写进.git/config改动成本高。我最终选了子域方案直观、清晰、维护成本低。3.5 用户侧使用方式镜像站搭好之后日常使用很简单。浏览器下载Release包时把下载URL里的github.com替换成mirror.example.com即可。举个例子原地址是https://github.com/owner/repo/releases/download/v1.0/pkg.tar.gz改成https://mirror.example.com/owner/repo/releases/download/v1.0/pkg.tar.gz请求就会落到镜像站。首次请求穿透到GitHub并缓存之后所有人命中的都是镜像本地文件。git clone时修改仓库的remote地址。可以一条命令切换到镜像git remote set-url origin https://raw-mirror.example.com/owner/repo.git团队内部可以把这条命令写成一个config脚本一键切换。也有人在.gitconfig里用url替换规则把github.com统一映射到镜像地址这个方案最省事git config --global url.https://raw-mirror.example.com/.insteadOf https://github.com/这样一来所有git命令里的github.com都被替换为镜像地址团队成员无感就用了。3.6 缓存清理与数据维护缓存目录是/data/cache。跑几周后几十GB很正常。我写了一个每天凌晨跑的cron脚本清理7天未访问的缓存文件find /data/cache -type f -mtime 7 -delete执行前建议先看看目录大小du -sh /data/cacheproxy_cache_path里已经有inactive7d和max_size20gNginx自己也会做回收但cron是双保险。另外清理缓存并不会影响命中率因为Nginx会重新请求源站并把最新内容写回缓存。3.7 与CI/CD构建机的联动如果团队有CI/CD环境镜像站接入的价值更大。以Jenkins为例可以在构建脚本里把下载GitHub依赖的URL统一替换成镜像地址。也可以用环境变量管理让构建脚本从配置中心读取镜像前缀。GitHub Actions如果想用这个镜像需要在自建的runner上配置而不是在云端runner上因为云端runner天然就在GitHub内部路线再用镜像反而是绕远。这里我分享一个真实做法我自己的构建节点所有pip、npm安装都走内部PyPI/npm缓存只有源码包下载走GitHub镜像站。源码包路径通过替换规则统一改写构建脚本几乎不用改。3.8 自动化部署脚本参考如果不想手动执行那么多命令把整个过程写成一个脚本也是可以的。下面是一个简化的思路#!/bin/bash set -e DOMAINmirror.example.com RAW_DOMAINraw-mirror.example.com CACHE_DIR/data/cache apt update apt install -y nginx nginx-extras certbot python3-certbot-nginx mkdir -p $CACHE_DIR # 写入上面两段Nginx配置后执行 nginx -t systemctl reload nginx # 申请证书 certbot certonly --webroot -w /var/www/html -d $DOMAIN -d $RAW_DOMAIN # 配置自动续期 echo 0 3 * * * root certbot renew --quiet /etc/crontab # 配置缓存清理 echo 5 4 * * * root find $CACHE_DIR -type f -mtime 7 -delete /etc/crontab脚本看起来简单但实际落地时最关键的是Nginx配置文件的完整性以及certbot的webroot路径要对。生产环境我建议一步步执行脚本只做备份和重复部署用别第一次就在生产服务器上直接跑。4. 常见问题与排查技巧实录4.1 502 Bad Gateway现象是访问镜像站时直接报502。排查顺序先curl -I https://mirror.example.com/再直接在服务器上curl -I https://github.com确认源站通。如果是转发配置问题多半是域名解析失败。Nginx转发到https时上游域名必须能解析可以在nginx.conf的http块里加resolver 8.8.8.8 114.114.114.114 valid30s ipv6off;同时把proxy_pass里的域名解析提前避免每次请求都重新解析。另一种常见原因上游SSL握手失败此时一定要保证proxy_ssl_server_name on;否则SNI不携带目标域名GitHub会找不到对应虚拟主机。4.2 证书或Host头问题如果你的镜像站访问时出现证书错误多半是Nginx在向GitHub发起上游连接时没有正确携带SNI或Host头。除了proxy_ssl_server_name on;有时候还需要显式设置proxy_ssl_name github.com;。Host头也同样要用proxy_set_header Host github.com;。如果忘记这两项表现是报错诡异的SSL错误、或者返回GitHub的404页面。这类问题最容易发生在debug阶段因为浏览器看到的镜像是自己的域名证书校验是通过的但后端连接到GitHub时用的是默认的逻辑导致SNI不对。4.3 缓存不命中或命中率低可以加add_header X-Cache-Status然后观察响应头。如果总是MISS说明缓存键和请求路径不匹配。常见原因有两个一个是带了动态cookie或query串导致缓存键变化另一个是Accept-Encoding不同导致缓存键分裂。cookie问题可以通过proxy_cache_key只取URI解决但我不建议忽略cookie否则可能泄漏认证信息自己的内网镜像可以把认证相关的路径排除掉。真正让命中率下降的往往是Accept-Encoding我上面已经提过记得关掉压缩。还有一个容易被忽略的点如果源站返回302跳转Nginx默认不缓存302而GitHub某些Release下载会先302到CDN。需要给302也设置一个合理的缓存时间比如proxy_cache_valid 302 10s或者直接让用户跟随跳转。4.4 前端页面资源加载不全如果你把github.com整个页面转发到自己的镜像域名页面里的脚本、样式、图片却还是github.com的绝对地址浏览器会被CSP和混合内容策略拦截。这是转发GitHub这种重前端站点的固有问题没有一劳永逸的解法。我身边常见的做法是镜像站只管静态文件和Release大文件页面访问还是直接用GitHub本身。既绕开麻烦又保住下载加速的核心诉求。如果想要完整保存一个GitHub页面的快照可以用wget镜像整站但那是另一套逻辑这里不展开。4.5 日志监控与性能观测镜像站跑起来之后不能只看“能不能用”还要知道“有没有效”。我在nginx.conf里自定义了一个日志格式把上游缓存状态也记进去log_format cache_log $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $request_time $upstream_cache_status $http_referer; access_log /var/log/nginx/access.log cache_log;然后可以用一条awk统计命中率awk {print $8} /var/log/nginx/access.log | sort | uniq -c这里的$8对应upstream_cache_status如果HIT占比超过80%说明缓存策略是健康的。如果MISS很多就去查是不是被大量未命中的query串打穿。4.6 常见问题速查表现象可能原因处理方式502 Bad GatewayDNS解析失败、源站不可达检查resolver、proxy_ssl_server_name证书不匹配SNI或Host头未指定proxy_ssl_name、proxy_set_header Host静态文件404proxy_pass路径拼接错误检查location和proxy_pass是否带URI页面资源错乱绝对路径指向github.com仅转发下载路径不转发完整页面缓存命中率低Accept-Encoding、动态query关闭上游压缩固定缓存键磁盘空间暴涨缓存过多设置max_size、定期cron清理5. 写在最后的一点体会这套镜像站跑了大半年我最有体感的不是数字上速度快了多少倍而是“流量可控”和“资源可复用”这两个点。其实方案本身不复杂难就难在你要清楚自己到底想解决哪一类问题是偶尔下载一个包还是团队频繁合作。如果只是临时拉一次没必要折腾但如果是长期项目花一个晚上把缓存、限速、监控都配好后面省下来的时间绝对不止这个数。最后再提醒一句缓存目录一定要勤看磁盘被打满的教训我踩过一次。某次凌晨收到磁盘报警爬起来清了两小时缓存那经历真不想来第二遍。如果你也在维护类似的镜像服务欢迎交流各自的缓存策略和防滥用经验。 
长河君 · 2026/9/29 15:50:08 · 阅读 1.2k GitHub镜像站搭建指南：用Nginx缓存加速源码与Release下载
做开发这些年我发现一个特别常见的现象明明源码在GitHub上放得好好的可一到关键时候clone个仓库慢得像蜗牛爬发布包里动辄几百MB的依赖资源下载到一半还给你断连。尤其是一个团队里几个人同时拉同一份代码简直是在浪费生命。后来我索性把常用的GitHub资源做成了一套GitHub镜像站团队内部、个人电脑、CI流程全都往这个通道上走速度快了不少带宽也省下来了。这篇文章不纸上谈兵直接把我自己搭的一套镜像站方案完整拆开怎么选型、怎么配转发、怎么加缓存、怎么让它在实际下载中真的又快又稳踩过的坑也会一并写出来。无论你是刚接触GitHub的新手还是负责团队基础设施的工程师按着这篇文章的思路往下走基本都能落地。1. 先想清楚镜像站到底解决什么问题1.1 三个最痛的场景先说最常见的情况。项目拉到后期大家基本都被三类事情卡过时间。一是大文件与发布包下载。GitHub Releases里放了不少二进制包、安装包、模型文件动不动几百MB。这些文件不走Git协议全是HTTP流式下载如果链路质量一般速度会忽高忽低。我之前碰到过一个内网团队每次部署都要从Releases里拉一个600多MB的软件包十几个人排队下载一整天都在等。二是团队重复拉取。三五个开发每天反复clone同一个仓库每个人的机器都各自向GitHub发起一次完整请求。同一个仓库同一条网络链路同一个文件被几十次重复下载时间和带宽全浪费了。更无奈的是这种浪费没有上限新同事入职第一天就要把整套仓库克隆一遍。三是CI/CD构建机需要拉源码。构建机每次构建都要重新从GitHub拉仓库如果构建节点多同一个源码包会在很短时间内被多个节点同时请求构建排队时间肉眼可见地涨。构建失败重试时仓库又要重新拉一遍。镜像站的价值就是把“每个人独立从GitHub拉取”变成“先从就近镜像拉镜像服务器自己负责和GitHub保持同步”。把原本各走各路的请求折叠成一个共享出口在资源密集型研发场景里非常划算。这就好比你家里给每个房间都单独接了水管水量自然紧张不如先在小区入口修一个蓄水池大家从这个池子里取水水源压力就小很多。1.2 三种形态怎么选成熟一点的团队往往不止做一种镜像但我建议你先从最低成本的开始。大致有这三类加速下载型以转发加缓存为主核心是缓存静态文件。部署简单适合个人或团队内部。Git clone类操作也能覆盖但需要把raw域名也一起处理。仓库备份型把某个开源仓库定期同步到自己的托管平台比如Gitee、自建GitLab等平时就用自己的仓库地址clone。可靠性高但同步存在一定延迟。企业缓存型类似本地Git缓存服务粒度更细支持仓库级缓存和认证适合构建机多的团队。部署成本高一点。我把它们放在一起做了个对比。形态适用场景优点注意点加速下载型转发缓存个人、小团队轻量使用部署快、代码量少、缓存命中后提升明显需要域名和SSL防滥用策略要跟上仓库备份型同步至Gitee、GitLab开源项目维护、需要稳定源码不依赖GitHub链路实时速度可靠不是实时同步镜像仓库别当工作仓库企业缓存型本地Git缓存服务CI/CD构建集群、多人协作仓库仓库级缓存命中率高认证可做在内部需要维护较复杂的服务我最终实践下来最出效果的是“加速下载型”加一层“仓库备份”的组合。前者解决重文件下载后者解决日常clone源码。这两种都不难下面重点讲。1.3 选型决策回看早期我也做过一个过度设计一开始就想上一套企业级Git缓存系统结果配置了两个星期团队成员还是习惯用原始地址。后来我调整了策略先用一个最简单的Nginx转发跑起来观察一周访问日志发现流量集中在Releases下载和少量仓库的clone这才明确优化方向。如果你刚接触这个领域建议也别一上来就追求完美。先抓主要矛盾能下载、能缓存、速度起来就够了。2. 核心细节与关键选型2.1 域名、证书与解析顺序镜像站必须绑定一个正式的域名。IP直连不是不行但涉及SSL证书和SNI时非常麻烦。我用的是自己名下的二级域名给镜像站单独开一个子域例如mirror.example.com同时给raw下载另开一个raw-mirror.example.com。域名解析先做好把两个子域都指向服务器的公网IP等解析生效后再去申请证书。证书这块直接用Lets Encrypt免费证书三个月自动续期配合certbot的定时任务就能无感运行。申请证书时注意可以用DNS-01或HTTP-01但多域名证书要用-D配合。我习惯给两个子域签一张SAN证书这样管理起来省事。这里有一个非常隐蔽的细节GitHub的仓库页和raw下载是不同域名。如果只转发github.com那么你在页面上点“Download ZIP”时跳转链接可能指向codeload.github.com这又是一层。所以在规划阶段就把镜像域名的“影子域名”想好一个主域名对github.com一个raw域名对raw.githubusercontent.com必要时再加一个codeload域名对codeload.github.com。否则配置到一半发现缺域名来回补配置很容易漏。2.2 转发工具选型Nginx还是Caddy这类需求最主流的方案是Nginx配置语法大家都熟缓存模块也完善。Caddy的优点是自动申请和续期证书少写不少基础代码但它在细粒度缓存策略上不如Nginx直观。我最后选了Nginx。如果你不想自己维护证书可以在Nginx前面再套一层Caddy让Caddy只负责终止TLS和转发但那种组合更多余。直接Nginx加上certbot简洁可靠。我的取舍逻辑很简单镜像站是长期运行的基础设施Nginx更稳、排查手段更多。特别是proxy_cache机制Nginx的命中状态能直接在响应头里看。Caddy虽然能配http.cache但生态和文档还是差一截。2.3 缓存策略设计缓存是镜像站的核心做得不好就只是“转发”没有速度优势。我把缓存对象分成三类Releases包、zip/tar包等大文件这些是静态的内容基本不变可以放心缓存缓存时间设置长一些比如7天。仓库页面HTML需要看到更新所以缓存时间要短比如几十秒或直接关闭HTML缓存。如果你只是给内部拉代码我建议干脆不缓存仓库首页那些HTML避免看到旧版本。raw源文件、API响应适中缓存1到10分钟之间避免过于频繁地穿透到源站。在Nginx里我用proxy_cache_path定义一个共享缓存目录再按不同location设定proxy_cache_valid。具体参数在第3章的配置里会看到。这里先提一个坑千万别把动态路径和静态文件放在同一个缓存层级里否则一个带认证的请求被缓存下来之后所有人拿到的都是过期内容。2.4 动态请求与静态请求的分离我在生产上见过不止一次翻车现场把GitHub页面完整转发到内网镜像结果页面上的HTML被长期缓存README永远是三天前的。为什么因为页面HTML里包含大量的动态元素比如“Star数”“最近提交时间”它们每次请求都可能不同。镜像站真正回报率高的是那些“不变资源”Release压缩包、仓库内静态文件、raw文件。所以我在设计时就做了切割转发github.com的配置里对HTML几乎不做长缓存对Release下载路径做出长达7天的缓存。这样既不会误导用户又能在重负载时保住下载通道的速度。这个思想也可以推广到其他任何“缓存型镜像”项目不只是GitHub镜像站。2.5 安全与防滥用镜像站一旦用起来很容易被搜索引擎或同事扩散出去变成公共下载站。流量暴涨是小问题源站可能因此限制你的IP那才是大问题。我的建议能内网就内网开放到公网至少要做访问频率限制限速条目也要配置避免单用户把带宽吃满。可以在header里加一个“只允许指定Referer”的单级限制但别只依赖header因为命令行下载工具根本不带Referer。下面这些防护点我会在配置里逐个落地limit_conn限制单IP并发连接数。limit_req限制请求频率。limit_rate对下载速度做上限。配合Nginx的access_log做流量统计。3. 从零动手加速下载型镜像站实操3.1 准备工作一台能正常访问GitHub的服务器这个是前提。如果只在内网使用2核2G就够如果要服务更多同事或CI节点建议4核8G起。域名提前规划好并完成DNS解析。系统用Ubuntu或Debian都可以下面以Ubuntu 20.04为例。磁盘建议单独挂一个数据盘给缓存目录因为缓存文件增长非常快。我第一次只用系统盘两周后就报警了。apt update apt install -y nginx nginx-extras certbot python3-certbot-nginx curl wgetnginx-extras是可选但多了一些headers和缓存相关的扩展建议装上。certbot用于申请证书初学者建议直接用它绑定的Nginx插件一条命令完成证书和Nginx配置改写。3.2 准备证书先用certbot把证书申请好。假设域名为mirror.example.com和raw-mirror.example.comcertbot certonly --webroot -w /var/www/html \ -d mirror.example.com -d raw-mirror.example.com成功后证书会放在/etc/letsencrypt/live/目录下。如果你不想手动配webroot也可以直接运行certbot run -a standalone -d mirror.example.com -d raw-mirror.example.com但standalone模式要求暂时停掉Nginx或者先停掉80端口占用。我习惯用webroot方式不影响在线服务。3.3 转发配置核心server块下面是我实际用的核心配置去掉无关冗余后是这个样子proxy_cache_path /data/cache levels1:2 keys_zonegithub_cache:10m max_size20g inactive7d use_temp_pathoff; limit_conn_zone $binary_remote_addr zoneconcurrent:10m; limit_req_zone $binary_remote_addr zonereq:10m rate5r/s; server { listen 443 ssl http2; server_name mirror.example.com; ssl_certificate /etc/letsencrypt/live/mirror.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/mirror.example.com/privkey.pem; # 正常页面入口对HTML短缓存 location / { proxy_pass https://github.com; proxy_set_header Host github.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_ssl_server_name on; proxy_ssl_name github.com; proxy_set_header Accept-Encoding ; proxy_cache github_cache; proxy_cache_valid 200 301 30s; proxy_cache_key $host$scheme$request_uri; add_header X-Cache-Status $upstream_cache_status; limit_req zonereq burst10 nodelay; } # Release大文件走长缓存 location ~* \.(zip|tar|gz|tgz|exe|dmg|pkg|deb|rpm|jar|whl|bin)$ { proxy_pass https://github.com; proxy_set_header Host github.com; proxy_set_header X-Real-IP $remote_addr; proxy_ssl_server_name on; proxy_ssl_name github.com; proxy_set_header Accept-Encoding ; proxy_cache github_cache; proxy_cache_valid 200 301 7d; proxy_cache_key $host$scheme$request_uri; add_header X-Cache-Status $upstream_cache_status; limit_conn concurrent 5; limit_rate 100m; } }有几个细节要重点解释。第一proxy_pass指向https://github.com后客户端看到的URL还是mirror.example.com/xxx。但页面里如果硬编码了github.com绝对路径浏览器会直接请求原始域名绕开镜像。这也是为什么我建议镜像站只负责下载路径不去转发完整页面。第二proxy_set_header Accept-Encoding 的作用是关闭上游压缩。Nginx缓存的是上游返回的原始字节如果源站根据客户端的不同Accept-Encoding返回不同内容缓存键就会分裂。关掉压缩后缓存命中率一下就上来了。第三add_header X-Cache-Status让响应头里带上缓存命中状态。我习惯在所有缓存配置里都加上这个头排查问题太方便了一个curl -I就能知道是命中还是穿透。3.4 raw下载加速服务配置git clone时从GitHub拉大对象走的主要是raw.githubusercontent.com或codeload.github.com。给raw做一个独立子域配置思路一样server { listen 443 ssl http2; server_name raw-mirror.example.com; ssl_certificate /etc/letsencrypt/live/mirror.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/mirror.example.com/privkey.pem; location / { proxy_pass https://raw.githubusercontent.com; proxy_set_header Host raw.githubusercontent.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_ssl_server_name on; proxy_ssl_name raw.githubusercontent.com; proxy_set_header Accept-Encoding ; proxy_cache github_cache; proxy_cache_valid 200 301 24h; proxy_cache_key $host$scheme$request_uri; add_header X-Cache-Status $upstream_cache_status; } }如果你愿意深度定制还可以把仓库页和raw内容合并到同一个子域用不同路径区分比如/mirror/raw/。但这样会牵扯到Git内部把URL写进.git/config改动成本高。我最终选了子域方案直观、清晰、维护成本低。3.5 用户侧使用方式镜像站搭好之后日常使用很简单。浏览器下载Release包时把下载URL里的github.com替换成mirror.example.com即可。举个例子原地址是https://github.com/owner/repo/releases/download/v1.0/pkg.tar.gz改成https://mirror.example.com/owner/repo/releases/download/v1.0/pkg.tar.gz请求就会落到镜像站。首次请求穿透到GitHub并缓存之后所有人命中的都是镜像本地文件。git clone时修改仓库的remote地址。可以一条命令切换到镜像git remote set-url origin https://raw-mirror.example.com/owner/repo.git团队内部可以把这条命令写成一个config脚本一键切换。也有人在.gitconfig里用url替换规则把github.com统一映射到镜像地址这个方案最省事git config --global url.https://raw-mirror.example.com/.insteadOf https://github.com/这样一来所有git命令里的github.com都被替换为镜像地址团队成员无感就用了。3.6 缓存清理与数据维护缓存目录是/data/cache。跑几周后几十GB很正常。我写了一个每天凌晨跑的cron脚本清理7天未访问的缓存文件find /data/cache -type f -mtime 7 -delete执行前建议先看看目录大小du -sh /data/cacheproxy_cache_path里已经有inactive7d和max_size20gNginx自己也会做回收但cron是双保险。另外清理缓存并不会影响命中率因为Nginx会重新请求源站并把最新内容写回缓存。3.7 与CI/CD构建机的联动如果团队有CI/CD环境镜像站接入的价值更大。以Jenkins为例可以在构建脚本里把下载GitHub依赖的URL统一替换成镜像地址。也可以用环境变量管理让构建脚本从配置中心读取镜像前缀。GitHub Actions如果想用这个镜像需要在自建的runner上配置而不是在云端runner上因为云端runner天然就在GitHub内部路线再用镜像反而是绕远。这里我分享一个真实做法我自己的构建节点所有pip、npm安装都走内部PyPI/npm缓存只有源码包下载走GitHub镜像站。源码包路径通过替换规则统一改写构建脚本几乎不用改。3.8 自动化部署脚本参考如果不想手动执行那么多命令把整个过程写成一个脚本也是可以的。下面是一个简化的思路#!/bin/bash set -e DOMAINmirror.example.com RAW_DOMAINraw-mirror.example.com CACHE_DIR/data/cache apt update apt install -y nginx nginx-extras certbot python3-certbot-nginx mkdir -p $CACHE_DIR # 写入上面两段Nginx配置后执行 nginx -t systemctl reload nginx # 申请证书 certbot certonly --webroot -w /var/www/html -d $DOMAIN -d $RAW_DOMAIN # 配置自动续期 echo 0 3 * * * root certbot renew --quiet /etc/crontab # 配置缓存清理 echo 5 4 * * * root find $CACHE_DIR -type f -mtime 7 -delete /etc/crontab脚本看起来简单但实际落地时最关键的是Nginx配置文件的完整性以及certbot的webroot路径要对。生产环境我建议一步步执行脚本只做备份和重复部署用别第一次就在生产服务器上直接跑。4. 常见问题与排查技巧实录4.1 502 Bad Gateway现象是访问镜像站时直接报502。排查顺序先curl -I https://mirror.example.com/再直接在服务器上curl -I https://github.com确认源站通。如果是转发配置问题多半是域名解析失败。Nginx转发到https时上游域名必须能解析可以在nginx.conf的http块里加resolver 8.8.8.8 114.114.114.114 valid30s ipv6off;同时把proxy_pass里的域名解析提前避免每次请求都重新解析。另一种常见原因上游SSL握手失败此时一定要保证proxy_ssl_server_name on;否则SNI不携带目标域名GitHub会找不到对应虚拟主机。4.2 证书或Host头问题如果你的镜像站访问时出现证书错误多半是Nginx在向GitHub发起上游连接时没有正确携带SNI或Host头。除了proxy_ssl_server_name on;有时候还需要显式设置proxy_ssl_name github.com;。Host头也同样要用proxy_set_header Host github.com;。如果忘记这两项表现是报错诡异的SSL错误、或者返回GitHub的404页面。这类问题最容易发生在debug阶段因为浏览器看到的镜像是自己的域名证书校验是通过的但后端连接到GitHub时用的是默认的逻辑导致SNI不对。4.3 缓存不命中或命中率低可以加add_header X-Cache-Status然后观察响应头。如果总是MISS说明缓存键和请求路径不匹配。常见原因有两个一个是带了动态cookie或query串导致缓存键变化另一个是Accept-Encoding不同导致缓存键分裂。cookie问题可以通过proxy_cache_key只取URI解决但我不建议忽略cookie否则可能泄漏认证信息自己的内网镜像可以把认证相关的路径排除掉。真正让命中率下降的往往是Accept-Encoding我上面已经提过记得关掉压缩。还有一个容易被忽略的点如果源站返回302跳转Nginx默认不缓存302而GitHub某些Release下载会先302到CDN。需要给302也设置一个合理的缓存时间比如proxy_cache_valid 302 10s或者直接让用户跟随跳转。4.4 前端页面资源加载不全如果你把github.com整个页面转发到自己的镜像域名页面里的脚本、样式、图片却还是github.com的绝对地址浏览器会被CSP和混合内容策略拦截。这是转发GitHub这种重前端站点的固有问题没有一劳永逸的解法。我身边常见的做法是镜像站只管静态文件和Release大文件页面访问还是直接用GitHub本身。既绕开麻烦又保住下载加速的核心诉求。如果想要完整保存一个GitHub页面的快照可以用wget镜像整站但那是另一套逻辑这里不展开。4.5 日志监控与性能观测镜像站跑起来之后不能只看“能不能用”还要知道“有没有效”。我在nginx.conf里自定义了一个日志格式把上游缓存状态也记进去log_format cache_log $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $request_time $upstream_cache_status $http_referer; access_log /var/log/nginx/access.log cache_log;然后可以用一条awk统计命中率awk {print $8} /var/log/nginx/access.log | sort | uniq -c这里的$8对应upstream_cache_status如果HIT占比超过80%说明缓存策略是健康的。如果MISS很多就去查是不是被大量未命中的query串打穿。4.6 常见问题速查表现象可能原因处理方式502 Bad GatewayDNS解析失败、源站不可达检查resolver、proxy_ssl_server_name证书不匹配SNI或Host头未指定proxy_ssl_name、proxy_set_header Host静态文件404proxy_pass路径拼接错误检查location和proxy_pass是否带URI页面资源错乱绝对路径指向github.com仅转发下载路径不转发完整页面缓存命中率低Accept-Encoding、动态query关闭上游压缩固定缓存键磁盘空间暴涨缓存过多设置max_size、定期cron清理5. 写在最后的一点体会这套镜像站跑了大半年我最有体感的不是数字上速度快了多少倍而是“流量可控”和“资源可复用”这两个点。其实方案本身不复杂难就难在你要清楚自己到底想解决哪一类问题是偶尔下载一个包还是团队频繁合作。如果只是临时拉一次没必要折腾但如果是长期项目花一个晚上把缓存、限速、监控都配好后面省下来的时间绝对不止这个数。最后再提醒一句缓存目录一定要勤看磁盘被打满的教训我踩过一次。某次凌晨收到磁盘报警爬起来清了两小时缓存那经历真不想来第二遍。如果你也在维护类似的镜像服务欢迎交流各自的缓存策略和防滥用经验。