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.com，release下载最终则指向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.top | clone、release、raw均可用，日常首选 |
| GitHub文件下载加速 | github.moeyy.xyz | 浏览器直接改URL下载release包 |
| 高校仓库镜像 | gitclone.com | 大仓库clone，按需缓存，支持指定分支 |
| 代码托管镜像入口 | hub.gitmirror.com | 网页文件下载，适合应急 |
| 清华软件源 | mirrors.tuna.tsinghua.edu.cn | Linux软件包、Anaconda、PyPI等 |
| 中科大软件源 | mirrors.ustc.edu.cn | Homebrew、PyPI、操作系统包等 |
| 阿里云开源镜像 | mirrors.aliyun.com | pip、npm、Maven、系统ISO |
| npm专用镜像 | 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 --depth=1 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.xyz |
| Python依赖安装 | 清华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 --depth=1 --single-branch --branch main https://ghfast.top/https://github.com/git/git.git--depth=1只拉最新一次提交，不拉历史，数据量会小一个数量级--single-branch只拉指定分支，不下载其他分支的引用--branch main明确告诉git要哪个分支，避免默认分支判断浪费时间
如果要拉一个仓库但只需要其中某个子目录，还可以配合--filter=blob: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。
REPO="gin-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/git@master/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_ENDPOINT=https://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 git@github.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。这时候不要反复重试同一个命令，大概率还是同一结果。我的处理顺序是：先按Ctrl+C断掉当前进程，换个镜像站重试；如果还是不行，就加--depth=1做浅克隆，减少传输量；如果仓库非常大，再考虑用gitclone.com这类专门做仓库缓存的站点。
另外一个很容易被忽略的点是，有些镜像站对单次连接时长有限制，大文件传输超过一定时间会被掐断。遇到这种情况可以分段拉取，或者用git fetch结合断点续传去补齐，别指望一个长长的clone命令从头到底不中断。稳定性的突破口在于把大任务拆小，而不是赌网络。
5.3 HTTPS证书报错怎么办
使用镜像站时偶尔会看到SSL certificate problem或者self-signed certificate的报错。大多数原因是镜像站的证书配置没做好，而不是你的系统有问题。遇到这个报错，我建议直接换一个镜像站，不值得为一个站点关闭SSL校验。
如果你很清楚风险，且只用于临时下载一个公开文件，可以用一行命令跳过证书校验：
GIT_SSL_NO_VERIFY=true 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校验，确认缓存没坏、文件没被改，这样才能既享受加速的便利，又不把风险留给自己。
