2026年1月我又把GitHub镜像站清单从头到尾验了一遍。之所以年年要做这件事是因为“GitHub打不开”“clone卡在一半”“release下到99%失败”这些声音在开发群里从来没断过。尤其是国内做项目部署拉开源代码、下载编译产物几乎是每天的固定动作而GitHub原始访问链路慢起来真的能把人逼疯。这篇文章就是我持续维护的镜像站实操笔记不搞玄学不堆概念直接把实测可用的镜像站、URL替换规则、clone和release下载的标准姿势以及部署场景里的接入方法都写出来给日常写代码、部署服务、折腾AI模型的人参考。1. 为什么要用GitHub镜像站先搞清楚卡在哪里1.1 GitHub访问慢的三个关键节点普通用户感知的“GitHub打不开”其实要拆成三件事来看网页浏览、git clone/pull、release文件下载。网页走的是github.com代码传输走的是codeload.github.com实际传大文件时还会跳转到objects.githubusercontent.comrelease下载最终则指向release-assets.githubusercontent.com。这三条链路各自独立镜像站对它们的处理方式也不一样。在长期实践中你会发现网页偶尔打不开往往是DNS解析波动刷新几遍就恢复了真正痛的是代码clone和release下载因为这两个动作要持续建立大量连接并传输大文件一旦国际出口拥塞就会出现“Receiving objects卡在40%”然后超时断开的经典情况。理解了这一点就能明白镜像站为什么值得用它把最重的下载环节换成了国内服务器来完成你拿数据时不再需要跨越慢速链路。1.2 镜像站到底做了什么GitHub镜像站从实现机制上大体分三类。第一类是同步缓存型比如高校和云厂商搭的源镜像定时从GitHub拉取目标仓库的完整代码你访问的是它硬盘上的副本速度自然快很多。第二类是URL改写转发型它并不提前同步内容而是收到你的请求后临时去GitHub把数据拉回来再返回给你同时在本机或CDN层做一份缓存体现在操作上就是“在原始URL前面加一段镜像站域名”。第三类是CDN加速型专门针对release文件、raw文件这类静态资源做内容分发命中缓存后下载速度非常可观。这三类没有绝对优劣关键看场景。想要clone一个大型开源仓库同步缓存型最合适因为它可能已经提前把仓库拉好了偶尔下载一个几十MB的release包URL改写转发型更方便不用等同步频繁读取文档里的raw文件则适合走CDN类的入口。我在表格后面会专门把场景和镜像站对应起来避免拿起一个方案就往所有问题上套。1.3 官方源和镜像站怎么配合我的建议始终是“官方源为主镜像站为辅”。镜像站解决的是“拉不下来”和“太慢”的问题但镜像站毕竟是第三方提供的数据未必实时完全一致也未必长期存在。所以在大部分开发场景里正确姿态是能用官方源正常完成的操作优先用官方源一旦遇到速度不可接受或反复失败立刻切换到镜像站把网络峰值的阵痛绕过去。这样既不会因为过度依赖镜像导致团队协作出问题也能在关键时刻保住效率。这也是为什么我特别反对“一上来就把整个git全局配置换成镜像站”的做法。镜像站适合救急不适合长期所有流量都走它。真遇到持续性访问困难再考虑把这些站写进项目级配置而不是全局配置至少别影响日常push和内部仓库。2. 2026年1月实测可用的镜像站清单与选型2.1 直接能用的镜像站列表下面这张表是2026年1月我逐个体检过的常用入口覆盖clone、release、raw、软件源四类场景。需要提前声明免费镜像站很多是开发者用个人资源维护随时存在调整可能所以这个清单我会持续更新但你在阅读时如果发现某个站点状态变化请以5.1的切换方法为准。类型入口适用场景GitHub通用下载加速ghfast.topclone、release、raw均可用日常首选GitHub文件下载加速github.moeyy.xyz浏览器直接改URL下载release包高校仓库镜像gitclone.com大仓库clone按需缓存支持指定分支代码托管镜像入口hub.gitmirror.com网页文件下载适合应急清华软件源mirrors.tuna.tsinghua.edu.cnLinux软件包、Anaconda、PyPI等中科大软件源mirrors.ustc.edu.cnHomebrew、PyPI、操作系统包等阿里云开源镜像mirrors.aliyun.compip、npm、Maven、系统ISOnpm专用镜像registry.npmmirror.com前端依赖安装部署必备这里再补一句很多人会把“软件源镜像”和“GitHub镜像”混为一谈。清华、中科大、阿里云的软件源镜像主要服务的是PyPI、npm、apt、yum、Anaconda这类包管理器它们并不直接proxide一个git仓库。但它们同样是国内加速体系里非常重要的一环尤其是部署项目时真正花时间的往往不是clone项目代码而是装依赖。所以我把它们放在同一张清单里使用时要分清边界。2.2 如何快速验证镜像站还在不在免费的镜像站最大的问题就是“今天能用明天可能挂”。每次用之前花十几秒做个体检比下载到一半失败再补救省心得多。我常用的验证方法分三步浏览器先看首页能否打开然后看SSL证书是否正常最后用一个小仓库实测clone速度。命令行里可以这样快速验证curl -I -m 5 https://ghfast.top git clone --depth1 https://ghfast.top/https://github.com/octocat/Hello-World.git /tmp/test-clone第一条命令看HTTP返回码是否为200第二条命令用最小仓库测真实clone链路。整个过程在十秒以内。如果curl超时或者clone失败就换下一个候选站点。另外我还会定期检查release文件下载是否正常毕竟clone通道正常不代表release通道正常不少镜像站对这两种请求是分开处理的。2.3 按场景选择镜像方案选型原则很简单下载单个release文件优先使用通用下载加速clone完整仓库优先使用gitclone.com安装依赖优先使用软件源拉Docker镜像优先容器镜像加速。把场景和入口对应上就不会出现“用GitHub镜像站去加速pip安装”这种错位操作。使用场景首选方案备选方案git clone 开源项目通用下载加速URL改写gitclone.com下载release包通用下载加速github.moeyy.xyzPython依赖安装清华PyPI镜像阿里云PyPI镜像Node依赖安装npmmirror无Linux系统ISO下载清华/中科大镜像阿里云镜像拉取Docker镜像云厂商容器镜像加速器第三方公开加速地址读取raw文件jsDelivr CDN通用下载加速raw路径实际使用中还有个经验同一个镜像站在不同网络运营商下表现可能差异很大。你在电信网络下觉得A站好用到了联通或移动网络下可能B站更顺。所以不要死守一个站平时多测两家心里有数到用的时候才不会抓瞎。3. 镜像站实操从clone、release到raw的完整用法3.1 URL改写规则记住这一条就够市面上绝大多数GitHub镜像站都兼容“前缀替换”的用法就是在原始https://github.com/...前面直接拼接镜像站域名。比如原始clone地址是git clone https://github.com/git/git.git换成镜像站后git clone https://ghfast.top/https://github.com/git/git.git下载release压缩包也是同一个逻辑。原地址如果是wget https://github.com/octocat/Hello-World/archive/refs/heads/master.zip改写后wget https://ghfast.top/https://github.com/octocat/Hello-World/archive/refs/heads/master.zip这个方法通用性最强几乎不需要记忆额外的参数只要把镜像域名往原始URL前面一放就行。不过要提醒一句有些镜像站只支持github.com开头的地址不支持raw.githubusercontent.com和objects.githubusercontent.com遇到这种情况就要看3.4里的raw处理办法。3.2 大仓库clone的3个关键参数像Linux内核、Flutter、Kubernetes这类巨型仓库直接用git clone拉全量历史非常痛苦。镜像站虽快但如果第一个请求没命中缓存它自己也要回源拉一遍时间并不会缩短多少。更聪明的做法是减少需要传输的数据量。我常用的三个参数和含义如下git clone --depth1 --single-branch --branch main https://ghfast.top/https://github.com/git/git.git--depth1只拉最新一次提交不拉历史数据量会小一个数量级--single-branch只拉指定分支不下载其他分支的引用--branch main明确告诉git要哪个分支避免默认分支判断浪费时间如果要拉一个仓库但只需要其中某个子目录还可以配合--filterblob:none做稀疏检出这里不展开但实际部署项目时浅克隆已经能解决绝大多数问题。等到需要完整历史时再用git fetch --unshallow补全也比一开始硬拉要稳得多。3.3 release下载的两种高效姿势release文件是Docker安装包、二进制工具、模型部署包的主要来源也是GitHub国内访问的重灾区。除了手动在浏览器里改URL之外我推荐两种命令行做法。第一种是直接拼接适合临时下载wget https://ghfast.top/https://github.com/gin-gonic/gin/releases/download/v1.10.0/gin.zip第二种是利用GitHub API先解析出最新版本的下载地址再套镜像前缀。GitHub的release API地址是https://api.github.com/repos/{owner}/{repo}/releases/latest返回的JSON里有tag_name和assets字段。很多脚本部署时可以先拿最新版本号再拼出真正的下载URL避免手写版本导致404。REPOgin-gonic/gin TAG$(curl -s https://api.github.com/repos/$REPO/releases/latest | grep tag_name | cut -d -f4) echo 最新版本: $TAG wget https://ghfast.top/https://github.com/$REPO/releases/download/$TAG/gin.zip这里有个注意点GitHub API不带token时速率限制是60次每小时正常情况下够用但如果你在CI里大量调用建议申请一个token放到环境变量里把限制提升到5000次每小时。不要在命令行里直接暴露token更不要把它写进镜像站URL。3.4 raw文件与CDN入口的特殊处理readme里的图片、配置文件模板、脚本文件很多都挂在raw.githubusercontent.com这个域名下它和github.com是两套系统前缀替换的规则需要单独处理。通用的做法是换成wget https://ghfast.top/https://raw.githubusercontent.com/git/git/master/README.md如果只是想快速读一个文件我更推荐用jsDelivr的CDN入口它本身就是为这类场景设计的curl -L https://cdn.jsdelivr.net/gh/git/gitmaster/README.mdjsDelivr的规则是https://cdn.jsdelivr.net/gh/用户名/仓库名分支或标签/文件路径。它做了全球CDN分发国内多数情况下访问速度不错而且对GitHub仓库没有特别严格的流量限制很多博客主题的静态资源都靠它在撑。遇到raw文件下载慢先试这条路通常比镜像站回源还要快。3.5 把镜像配置写进git全局配置的利与弊如果你希望clone所有GitHub仓库时都自动走镜像可以通过git config设定URL替换规则git config --global url.https://ghfast.top/https://github.com/.insteadOf https://github.com/这样以后再执行git clone https://github.com/...时git会自动把开头替换成镜像地址不需要手动改URL。这个配置只对https协议生效SSH不受影响内部自建GitLab也不受影响因为它只精确匹配github.com这个前缀。但必须说清楚风险这个配置一旦开着push操作也会尝试走镜像站而绝大多数镜像站不支持push结果就是push失败。我第一次全局配置时就被这个坑过后来学乖了只在明确要拉代码的终端会话里临时用或者配置到项目级而不是全局级。真要全局配置建议只保留clone和fetch的场景push之前手动把remote改回官方地址。4. 部署与下载场景实战镜像站怎么帮上忙4.1 前端项目Node依赖与主题clone前端部署的第一步就是装依赖。刚拉下来的项目执行npm install如果npm源还是默认的registry.npmjs.org很容易卡在reify阶段。解决办法是先把npm registry切到国内镜像npm config set registry https://registry.npmmirror.com npm config get registry这一步做完大部分依赖安装的痛点就解决了。剩下的麻烦主要来自通过npm install github:user/repo安装的GitHub依赖以及很多项目模板本身是从GitHub仓库拉取的。这时候就要靠前面提到的镜像站来兜底手动clone后放到本地目录安装或者临时设置git的insteadOf规则。我自己在部署Hexo博客时也是这套组合拳镜像站拉主题模板nppm镜像装依赖最后生成静态文件再推送到GitHub Pages。单独依赖任何一个环节都不会有太好的体验组合起来才能顺畅跑完整个流程。4.2 AI大模型本地部署从工具链到权重文件2025年下半年开始身边越来越多人在折腾本地部署大模型比如DeepSeek、Qwen还有各种开源模型的Ollama方案。这个流程里和GitHub镜像站强相关的有两处一处是安装部署工具和推理框架另一处是拉取模型权重文件。部署工具方面像Ollama安装脚本、Dify项目源码、各种开源推理框架的二进制发布通常都托管在GitHub release上。直接下载可能有压力套一层镜像站前缀是标准动作git clone https://ghfast.top/https://github.com/langgenius/dify.git模型权重这块要特别说明一下大模型权重很少放在GitHub上而是托管在HuggingFace或ModelScope。国内访问HuggingFace也一样慢所以需要另一套镜像方案。我用得比较多的是设置环境变量export HF_ENDPOINThttps://hf-mirror.com这样HuggingFace相关的下载请求会自动走镜像节点。如果你用ModelScope国内访问本身已经很快不需要额外处理。很多新手把“本地部署大模型”理解为从GitHub硬拉几个GB的文件方向就搞偏了先分清工具链和权重文件的下载来源能少走很多弯路。4.3 博客部署Hexo到GitHub Pages的完整链路Hexo部署到GitHub Pages是非常典型的一个场景也是我博客折腾了最久的一条链路。整个流程是本地生成静态页面然后通过hexo d把生成结果推送到用户名.github.io这个仓库。生成页面和推送是分离的两步镜像站主要作用在第一步和依赖安装环节。新建博客时hexo init会从GitHub拉取hexo-starter模板。网络不好时这步会卡很长时间。我通常改成手动操作git clone https://ghfast.top/https://github.com/hexojs/hexo-starter.git blog cd blog npm install主题安装同理NexT主题仓库比较大走镜像站克隆几秒钟就能完成git clone https://ghfast.top/https://github.com/next-theme/hexo-theme-next.git themes/next但最后一步hexo d推送只能走GitHub原生通道镜像站帮不上忙。如果push慢我建议把remote改成SSH协议git remote set-url origin gitgithub.com:用户名/用户名.github.io.gitGitHub的SSH在大多数网络环境下比HTTPS稳定这里分享的是官方支持的22端口或443端口SSH连接方式必要时可以配合~/.ssh/config里的Host github.com条目调整端口。总之clone和依赖走镜像push走原生通道是这个场景下最合理的分工。4.4 Docker部署与容器镜像加速GitHub镜像站还能间接加速Docker部署因为很多项目最终要构建镜像而构建过程中会从GitHub拉源码。但更直接的问题是Docker Hub本身在国内也经常拉不动所以部署Docker服务时还需要单独配置容器镜像加速器。在/etc/docker/daemon.json里加入registry-mirrors配置{ registry-mirrors: [ https://docker.m.daocloud.io ] }然后重启Docker服务sudo systemctl restart docker需要解释的是这一步骤解决的是Docker镜像拉取问题和GitHub镜像站是两条独立赛道。但两者在部署中常常一起出现镜像里构建依赖要从GitHub下载镜像本身要从镜像加速器拉取源码要clone到本地。每个环节都有自己对应的加速方案把它们挨个配置好才会得到一个流畅的部署体验。我测试过很多第三方Docker镜像加速地址它们和GitHub镜像站一样变化快建议以云厂商控制台提供的个人专属加速地址为准公开地址失效就及时换。5. 常见问题与排查技巧实录5.1 镜像站突然打不开怎么快速切换镜像站失效是最常见的问题不需要慌张按顺序排查即可。先用浏览器访问首页如果首页能开但clone失败说明站点活着但git通道有问题如果首页直接超时基本可以判断这个站暂时不可用。看证书是否过期也很关键有些镜像站域名还在但SSL证书已经过期浏览器会直接拦截。我的习惯是每周末花三分钟做一轮健康检查维护一份本地脚本把候选镜像站域名放在数组里逐个curl。脚本核心其实就是2.2里的两条命令再套一层循环。一旦发现某个站挂掉立刻从清单里摘掉补上新发现的备选站。靠这个习惯我在部署高峰期基本没被镜像站失效卡过颈部。5.2 clone到一半卡死怎么处理clone卡死通常表现为“Receiving objects”进度条长时间不动或者直接报fatal: early EOF。这时候不要反复重试同一个命令大概率还是同一结果。我的处理顺序是先按CtrlC断掉当前进程换个镜像站重试如果还是不行就加--depth1做浅克隆减少传输量如果仓库非常大再考虑用gitclone.com这类专门做仓库缓存的站点。另外一个很容易被忽略的点是有些镜像站对单次连接时长有限制大文件传输超过一定时间会被掐断。遇到这种情况可以分段拉取或者用git fetch结合断点续传去补齐别指望一个长长的clone命令从头到底不中断。稳定性的突破口在于把大任务拆小而不是赌网络。5.3 HTTPS证书报错怎么办使用镜像站时偶尔会看到SSL certificate problem或者self-signed certificate的报错。大多数原因是镜像站的证书配置没做好而不是你的系统有问题。遇到这个报错我建议直接换一个镜像站不值得为一个站点关闭SSL校验。如果你很清楚风险且只用于临时下载一个公开文件可以用一行命令跳过证书校验GIT_SSL_NO_VERIFYtrue git clone https://ghfast.top/https://github.com/octocat/Hello-World.git但千万注意这会同时跳过了数据完整性和身份验证理论上存在被中间人替换文件的风险。所以我只推荐在应急场景用一次下载完成后用官方发布的sha256校验文件做一次完整性比对确认没问题再继续用。5.4 缓存数据不同步怎么判断镜像站缓存的数据不一定是实时的。同步缓存型镜像站通常有自己的更新周期短的几小时长的可能几天URL改写转发型虽然有缓存但也会根据过期策略淘汰。你在镜像站上clone到旧代码不代表官方仓库没更新。判断方法很简单git ls-remote https://github.com/用户名/仓库名.git HEAD git ls-remote https://ghfast.top/https://github.com/用户名/仓库名.git HEAD两条命令分别输出官方源和镜像源的HEAD提交哈希如果不一样就说明镜像缓存还没跟上。对时效性要求高的场景比如排查线上bug需要最新代码就不要依赖镜像站等网络状况好的时段直接拉官方源。如果你的目的是部署某个稳定版本镜像站的滞后一般不影响。5.5 push走了镜像怎么办这是配置了全局insteadOf之后最容易踩的坑。现象是push时提示认证失败或者直接报错因为镜像站根本不接收push请求。排查命令如下git remote -v git config --list | grep insteadOf如果发现remote或者git配置里的URL已经被改写成镜像地址马上改回官方地址git remote set-url origin https://github.com/用户名/仓库名.git git config --global --unset url.https://ghfast.top/https://github.com/.insteadOf我的建议是clone时用镜像push前把remote切回官方。这套习惯形成之后基本不会再被镜像站坑到。记住镜像站是单向加速通道它帮你把数据“拿进来”很快但“送出去”这件事它做不了。5.6 安全红线不能碰最后必须强调安全边界。镜像站虽然是开源社区常用的加速手段但它本质上是第三方服务使用时有几条红线不要在镜像站页面上登录你的GitHub账号不要通过镜像站执行任何涉及token、私钥、云平台密钥的操作不要下载你无法核对来源的二进制文件后直接运行。公共仓库和公开release文件可以放心用镜像站因为内容本身是公开的即使被截获也没有太多敏感价值。但企业内部代码、私有仓库、带敏感信息的产物一定走官方源或者内网自建git服务图快吃大亏的案例我见过不少。下载大文件后养成校验哈希的习惯既是对自己负责也是排查镜像站缓存损坏的有效手段。最后再分享一个我的个人习惯我把这套镜像站域名做成了一个shell函数放在本地每次感觉某个站不对劲就自动切换。镜像站这个东西本质上就是一个不断变化的生态与其指望某个地址永久有效不如把验证方法记牢。下载大文件时保留原始URL用镜像下载成功后顺手做一次sha256校验确认缓存没坏、文件没被改这样才能既享受加速的便利又不把风险留给自己。
