如果你也被 GitHub 的 clone 速度折磨过那这篇笔记应该是你的菜。这套方案的核心就两个东西一个 GitHub 加速代理服务我用的是 gh-proxy.com再加一条 git 全局配置把所有指向 github.com 的 https 地址自动替换成加速代理地址。以后 clone、fetch、pull 全部自动跑加速链路不用再手动改仓库的 remote url也不会污染本地仓库配置。这套东西适合谁凡是被git clone https://github.com/xxx卡到超时、源码包下载到一半断掉、release 大文件死活拉不下来的开发者都值得花五分钟配上。不需要你懂特别深层的原理照着操作就行但我也会把背后的机制讲清楚这样出了问题你自己能排查。1. 先搞清楚GitHub 下载慢的根因与加速链路1.1 慢在哪儿以及你真正想要的效果GitHub 的代码托管服务器基本上部署在境外国内开发者访问时跨高延迟链路、丢包、带宽被限、DNS 解析不稳定这些因素叠加在一起最直观的表现就是 clone 一个稍大的仓库像被按住了脖子remote: Enumerating objects卡半天或者干脆RPC failed; curl 18 transfer closed with outstanding read data remaining。我在实际工作中遇到过一个比较典型的场景团队里有同事 clone 一个 monorepo 仓库五六十兆的小仓库肉眼可见的慢一旦仓库里有二进制资源或者大文件基本每次都要重试。后来我帮他把加速代理配置上速度快了不是一点半点关键是稳定。你配置这个方案想要的效果很简单平时怎么操作 git 就怎么操作但数据流量自动走更快的链路不需要每次 clone 前手动改地址。注意这个方案只解决 GitHub 下载方向的速度问题不影响你 git 的其他行为也不影响系统全局网络。它只是在 git 这个工具内部做了一层 URL 重写。1.2 gh-proxy.com 的加速原理gh-proxy.com 这类服务的本质是一个公开的 GitHub 加速转发服务。它的工作模式可以理解为你把原本要发给 github.com 的请求先发给 gh-proxy.com由它去 GitHub 那边把数据抓回来再通过更优的链路分发给你。具体到 URL 格式gh-proxy.com 支持的写法通常是在原始 GitHub 地址前面加上代理前缀比如https://gh-proxy.com/https://github.com/octocat/Hello-World.git你可以用生活里的场景类比一下原来你得亲自跨城去一个仓库取货路途远、路上还容易堵车现在你在小区门口设了一个代收点代收点用专用通道把货拉回来你下楼就能拿到。这个代收点就是 gh-proxy.com。这里有个关键点Git 的 clone、fetch、pull 操作走的是 HTTP(S) 协议所以通过 URL 重写把请求改道是完全可行的。直接访问https://github.com/慢但访问https://gh-proxy.com/https://github.com/快那我们就让 git 在操作时自动把前者改写成后者。1.3 为什么选“全局替换 URL”而不是手动改 remote很多人第一反应是clone 的时候把地址里的 github.com 改成 gh-proxy.com 不就行了确实能行但有几个明显问题。第一个问题手动改容易忘。今天记得加前缀明天 clone 新仓库时又忘了每次都要去复制粘贴代理前缀效率低。第二个问题手动修改会把本地仓库的remote.origin.url弄得很乱。你git remote -v看到的是代理地址跟团队文档里的仓库地址对不上后面如果有人想重新拉、想换源容易犯迷糊。第三个问题也是最重要的用 git 自身的 URL 重写机制可以做到无侵入。配置文件里写好规则后你本地仓库的.git/config完全不用动remote.origin.url依然是原始的https://github.com/xxxgit 只是在真正发起请求之前在协议层把地址改写掉。这个设计非常优雅配置全局生效已有仓库和新仓库通通覆盖但你的仓库配置是干净的。所以我推荐的方式是用 git 自带的insteadOf机制做全局 URL 替换一劳永逸。2. 核心机制insteadOf 与 git 全局配置2.1 .gitconfig 三个层级别配错地方git 的配置有三个层级优先级从低到高分别是层级配置文件路径作用范围适用场景system/etc/gitconfig本机所有用户少数管理员统一设置global~/.gitconfig当前用户所有仓库个人常用配置推荐在这里加local.git/config当前仓库单仓库个性化配置我们做“全局加速代理”自然要写到 global 层级也就是~/.gitconfig文件。加--global参数就是操作这个文件。需要提醒一下如果你在某个仓库里执行了git config --local设置了覆盖规则它会优先于 global 层级。所以后文排查“配置不生效”的时候--local是第一个检查对象。2.2 一条核心命令拆解先给结论配置 gh-proxy.com 加速的核心命令是这一条git config --global url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/这条命令的语义是当 git 碰到的远程地址以https://github.com/开头时自动把这一整段前缀替换成https://gh-proxy.com/https://github.com/。我们来拆一下url.xxx.insteadOf yyy是 git 的 URL 重写语法意思是“凡是yyy开头的地址都替换成xxx开头”。前缀匹配是带斜杠的https://github.com/带末尾斜杠匹配https://github.com/octocat/Hello-World.git但不会误伤https://githost.com/之类地址。替换发生的时机是所有需要访问远程仓库的操作执行前包括 clone、fetch、pull。这里有一个容易踩的坑网上很多教程写的是url.https://gh-proxy.com/.insteadOf https://github.com/也就是代理前缀不带后面的原始地址。这个写法在部分加速服务上也能用但 gh-proxy.com 用的是双重地址格式也就是gh-proxy.com/https://github.com/...这样。所以我在实际配置时用的值是https://gh-proxy.com/https://github.com/替换后最终地址是https://gh-proxy.com/https://github.com/octocat/Hello-World.git正好对上代理服务的解析规则。如果你用的加速服务支持的是纯前缀拼接那就按服务商文档调整。判断方法很简单配置完 clone 一个仓库看输出里的地址是什么格式不匹配就换。2.3 方向问题insteadOf 只管拉取push 要单独设计很多人在这一步会掉坑里。insteadOf默认影响的是拉取方向的请求也就是 fetch、pull、clone。但 push 方向怎么办如果只配置了insteadOfpush 的时候 git 默认还是会走原始地址https://github.com/xxx不会走代理。这对我们来说其实是件好事因为 gh-proxy.com 这类加速服务主要解决下载方向的速度并不负责处理 push你也不能指望一个公开代理服务拿到你的写权限。但有个特殊情况如果你在别的配置里用了反向规则或者把insteadOf作用到了 push 方向push 就会试图往代理地址推结果大概率是 404 或者鉴权失败。为了保险起见我建议把 push 方向的规则也显式写清楚push 时把代理前缀还原回 GitHub 原始地址。git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/pushInsteadOf的意思是当 push 操作遇到的地址以https://gh-proxy.com/https://github.com/开头时把它还原成https://github.com/。这样无论拉还是推git 都会走正确的链路拉走代理推走原始地址两条路互不干扰。3. 实操记录配置全局加速代理并验证3.1 配置前准备动手之前建议先确认三件事git --versiongit 版本最好在 2.x 以上版本太老的话url.*.insteadOf的相关行为可能有差异虽然基本语法很早就有了但老版本兼容性不好说。git config --global --list看一眼现有全局配置避免和已有规则冲突。如果~/.gitconfig里已经有其他insteadOf规则先看看前缀是否重叠。cp ~/.gitconfig ~/.gitconfig.bak备份一下配置文件万一配乱了能立刻还原。这个习惯我强烈建议保留尤其是你全局配置里已经有 user.name、user.email、credential.helper 这类关键信息的时候。3.2 写入配置直接执行下面两条命令一次搞定拉取和推送两个方向# 拉取方向https://github.com/ 自动替换为加速代理地址 git config --global url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/ # 推送方向遇到加速代理地址自动还原为 GitHub 原始地址 git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/执行完之后你可以直接打开~/.gitconfig看一眼内容应该是这样的[user] name yourname email youexample.com [url https://gh-proxy.com/https://github.com/] insteadOf https://github.com/ [url https://github.com/] pushInsteadOf https://gh-proxy.com/https://github.com/3.3 验证配置配置文件写好了不代表规则一定生效建议确认一遍git config --global --get-regexp \.insteadOf$输出里应该能看到两行url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/ url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/如果你只想看某个 key用git config --global --get也可以。到这里配置已经生效了。3.4 实测clone、pull、remote -v 三步走配置完最重要的就是实测。找一个 GitHub 仓库试一下git clone https://github.com/octocat/Hello-World.git正常的话clone 过程中会看到类似这样的信息Cloning into Hello-World... remote: Enumerating objects: 10, done. remote: Counting objects: 100% (10/10), done. remote: Compressing objects: 100% (7/7), done. remote: Total 10 (delta 1), reused 5 (delta 0), pack-reused 0 Receiving objects: 100% (10/10), done. Resolving deltas: 100% (1/1), done.这里有一个小细节部分加速服务在 clone 输出里会显示经过重写后的地址比如出现https://gh-proxy.com/https://github.com/octocat/Hello-World.git说明规则确实生效了。如果输出信息里没有明显提示你可以通过另一个方法确认GIT_TRACE1 git fetch origin看调试日志能追踪到 URL 重写的过程。再验证一下本地仓库的 remote 配置有没有被改动cd Hello-World git remote -v正常应该还是origin https://github.com/octocat/Hello-World.git (fetch) origin https://github.com/octocat/Hello-World.git (push)这正是insteadOf的妙处规则配置在全局仓库本身保持干净。你给任何同事看 remote 地址还是官方原址谁也看不出你私底下做了加速。3.5 把配置做成脚本一键切换配置虽然简单但我还是建议你把它写成一个脚本方便以后在“加速/不加速”两个状态之间快速切换。我自己习惯在~/bin/下放一个git-ghproxy-on.sh#!/bin/bash # 开启 GitHub 加速代理 git config --global url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/ git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/ echo gh-proxy.com 加速已开启再写一个关闭脚本git-ghproxy-off.sh#!/bin/bash # 关闭 GitHub 加速代理 git config --global --unset url.https://gh-proxy.com/https://github.com/.insteadOf git config --global --unset url.https://github.com/.pushInsteadOf echo gh-proxy.com 加速已关闭这样如果哪天代理服务不稳定你想先切回直连一条命令搞定不用记住那么长的配置项。4. 常见问题与排查技巧4.1 push 失败或提示没有权限配置完之后 push 报错是大家最常踩的坑之一。最常见的现象是remote: Not Found fatal: repository https://gh-proxy.com/https://github.com/xxx/xxx.git/ not found或者类似 404、403、401 之类的鉴权报错。原因很简单push 请求走了 gh-proxy.com而代理服务没有也不会处理你的 push 请求。解决办法就是前面说的加上pushInsteadOf反向规则让 push 强制走原始地址。git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/如果你加了这个规则依然报错检查一下规则是不是写反了或者 push 时 URL 前缀不是https://gh-proxy.com/https://github.com/而是别的格式。4.2 配了规则却没走代理配置都写了git clone依然慢得跟蜗牛一样看起来像没生效。这时候按顺序排查检查项操作说明仓库内 local 配置是否覆盖git config --local --listlocal 优先级高于 globalremote 地址是否为 https 开头git remote -vssh 地址不走这个规则是否有其他 insteadOf 规则git config --global --get-regexp \.insteadOf$看前缀是否冲突代理服务本身是否可用curl -I https://gh-proxy.com/https://github.com/先确认代理能通特别是第二条很多人克隆仓库用的是 SSH 地址比如gitgithub.com:owner/repo.git这不是 https 前缀insteadOf的规则就不会匹配。如果你想给 SSH 地址也做替换需要额外配置但我个人不建议这么做SSH 的用途主要就是 push而且代理服务一般不对 SSH 协议开放没必要折腾。另外注意一下大小写和末尾斜杠。GitHub 地址大小写其实不敏感但 URL 前缀匹配是大小写敏感的如果地址是HTTPS://GITHUB.COM/规则也不会命中。虽然这种情况平时很少见但了解这个机制能帮你快速定位问题。4.3 clone 报 502 Bad Gateway 之类错误如果你在 git 里配置过本地 HTTP 代理端口比如http.proxy指向127.0.0.1:1572而那个本地服务恰好没启动clone 的时候就会报一堆unexpected status 502 bad gateway或者连接异常。这和insteadOf加速配置是两套东西容易混淆。排查时先看 git 的代理设置git config --global --get http.proxy git config --global --get https.proxy如果有值说明 git 请求试图先经过本地代理而代理端口不可用自然报错。这不是 gh-proxy.com 的问题是本地链路问题。另外一个常见原因是代理服务偶发不稳定。免费公开服务高峰期 502 或超时并不罕见。解决办法是稍后重试或者临时切换回直连。这种时候脚本的价值就体现了一条命令关掉加速业务不受影响。4.4 如何临时绕过或彻底移除配置有时候你可能想临时对比一下加速前后的速度或者 gh-proxy.com 临时抽风想先用直连但不想改配置。有个很干净的技巧用环境变量临时禁用全局配置。GIT_CONFIG_GLOBAL/dev/null git clone https://github.com/octocat/Hello-World.gitGIT_CONFIG_GLOBAL/dev/null意思是让 git 忽略~/.gitconfig用空配置启动。这样就能临时走直连别的行为完全不受影响。如果你确定以后不想再用了移除配置更简单git config --global --unset url.https://gh-proxy.com/https://github.com/.insteadOf git config --global --unset url.https://github.com/.pushInsteadOf删干净之后git config --global --get-regexp \.insteadOf$应该没有任何输出。4.5 问题速查表现象最常见原因解决办法clone 还是慢地址没变remote 是 ssh 地址改成 https 地址或另配 ssh 规则push 404 / 403push 走了代理添加pushInsteadOf还原规则报 502 / 连接失败本地 http.proxy 端口不可用或代理服务不稳定先查http.proxy再考虑切换代理配置了但不起作用local 配置覆盖 / 前缀不匹配检查 local 配置和 URL 前缀想绕过加速临时忽略全局配置用GIT_CONFIG_GLOBAL/dev/null最后再分享一个我实际使用中的体会这个方案最舒服的地方不是速度提升多少倍而是“无感”。配置好之后你不需要记得今天有没有加代理前缀不需要维护一个改了地址的仓库列表git 会在底层自动帮你把事情办好。这套思路不止适用于 gh-proxy.com任何支持双重 URL 格式的同类 GitHub 加速服务都可以用同样的方式接入换服务商时只要把~/.gitconfig里对应的前缀替换掉就行。另外一个小技巧如果你经常 clone 的是大仓库可以把配置和--depth1浅克隆配合使用绝大多数场景下体验会再上一个台阶。我先说这么多剩下的坑你自己踩过就明白了。
GitHub 加速实战：用 gh-proxy 与 git insteadOf 配置彻底解决 clone 慢
如果你也被 GitHub 的 clone 速度折磨过那这篇笔记应该是你的菜。这套方案的核心就两个东西一个 GitHub 加速代理服务我用的是 gh-proxy.com再加一条 git 全局配置把所有指向 github.com 的 https 地址自动替换成加速代理地址。以后 clone、fetch、pull 全部自动跑加速链路不用再手动改仓库的 remote url也不会污染本地仓库配置。这套东西适合谁凡是被git clone https://github.com/xxx卡到超时、源码包下载到一半断掉、release 大文件死活拉不下来的开发者都值得花五分钟配上。不需要你懂特别深层的原理照着操作就行但我也会把背后的机制讲清楚这样出了问题你自己能排查。1. 先搞清楚GitHub 下载慢的根因与加速链路1.1 慢在哪儿以及你真正想要的效果GitHub 的代码托管服务器基本上部署在境外国内开发者访问时跨高延迟链路、丢包、带宽被限、DNS 解析不稳定这些因素叠加在一起最直观的表现就是 clone 一个稍大的仓库像被按住了脖子remote: Enumerating objects卡半天或者干脆RPC failed; curl 18 transfer closed with outstanding read data remaining。我在实际工作中遇到过一个比较典型的场景团队里有同事 clone 一个 monorepo 仓库五六十兆的小仓库肉眼可见的慢一旦仓库里有二进制资源或者大文件基本每次都要重试。后来我帮他把加速代理配置上速度快了不是一点半点关键是稳定。你配置这个方案想要的效果很简单平时怎么操作 git 就怎么操作但数据流量自动走更快的链路不需要每次 clone 前手动改地址。注意这个方案只解决 GitHub 下载方向的速度问题不影响你 git 的其他行为也不影响系统全局网络。它只是在 git 这个工具内部做了一层 URL 重写。1.2 gh-proxy.com 的加速原理gh-proxy.com 这类服务的本质是一个公开的 GitHub 加速转发服务。它的工作模式可以理解为你把原本要发给 github.com 的请求先发给 gh-proxy.com由它去 GitHub 那边把数据抓回来再通过更优的链路分发给你。具体到 URL 格式gh-proxy.com 支持的写法通常是在原始 GitHub 地址前面加上代理前缀比如https://gh-proxy.com/https://github.com/octocat/Hello-World.git你可以用生活里的场景类比一下原来你得亲自跨城去一个仓库取货路途远、路上还容易堵车现在你在小区门口设了一个代收点代收点用专用通道把货拉回来你下楼就能拿到。这个代收点就是 gh-proxy.com。这里有个关键点Git 的 clone、fetch、pull 操作走的是 HTTP(S) 协议所以通过 URL 重写把请求改道是完全可行的。直接访问https://github.com/慢但访问https://gh-proxy.com/https://github.com/快那我们就让 git 在操作时自动把前者改写成后者。1.3 为什么选“全局替换 URL”而不是手动改 remote很多人第一反应是clone 的时候把地址里的 github.com 改成 gh-proxy.com 不就行了确实能行但有几个明显问题。第一个问题手动改容易忘。今天记得加前缀明天 clone 新仓库时又忘了每次都要去复制粘贴代理前缀效率低。第二个问题手动修改会把本地仓库的remote.origin.url弄得很乱。你git remote -v看到的是代理地址跟团队文档里的仓库地址对不上后面如果有人想重新拉、想换源容易犯迷糊。第三个问题也是最重要的用 git 自身的 URL 重写机制可以做到无侵入。配置文件里写好规则后你本地仓库的.git/config完全不用动remote.origin.url依然是原始的https://github.com/xxxgit 只是在真正发起请求之前在协议层把地址改写掉。这个设计非常优雅配置全局生效已有仓库和新仓库通通覆盖但你的仓库配置是干净的。所以我推荐的方式是用 git 自带的insteadOf机制做全局 URL 替换一劳永逸。2. 核心机制insteadOf 与 git 全局配置2.1 .gitconfig 三个层级别配错地方git 的配置有三个层级优先级从低到高分别是层级配置文件路径作用范围适用场景system/etc/gitconfig本机所有用户少数管理员统一设置global~/.gitconfig当前用户所有仓库个人常用配置推荐在这里加local.git/config当前仓库单仓库个性化配置我们做“全局加速代理”自然要写到 global 层级也就是~/.gitconfig文件。加--global参数就是操作这个文件。需要提醒一下如果你在某个仓库里执行了git config --local设置了覆盖规则它会优先于 global 层级。所以后文排查“配置不生效”的时候--local是第一个检查对象。2.2 一条核心命令拆解先给结论配置 gh-proxy.com 加速的核心命令是这一条git config --global url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/这条命令的语义是当 git 碰到的远程地址以https://github.com/开头时自动把这一整段前缀替换成https://gh-proxy.com/https://github.com/。我们来拆一下url.xxx.insteadOf yyy是 git 的 URL 重写语法意思是“凡是yyy开头的地址都替换成xxx开头”。前缀匹配是带斜杠的https://github.com/带末尾斜杠匹配https://github.com/octocat/Hello-World.git但不会误伤https://githost.com/之类地址。替换发生的时机是所有需要访问远程仓库的操作执行前包括 clone、fetch、pull。这里有一个容易踩的坑网上很多教程写的是url.https://gh-proxy.com/.insteadOf https://github.com/也就是代理前缀不带后面的原始地址。这个写法在部分加速服务上也能用但 gh-proxy.com 用的是双重地址格式也就是gh-proxy.com/https://github.com/...这样。所以我在实际配置时用的值是https://gh-proxy.com/https://github.com/替换后最终地址是https://gh-proxy.com/https://github.com/octocat/Hello-World.git正好对上代理服务的解析规则。如果你用的加速服务支持的是纯前缀拼接那就按服务商文档调整。判断方法很简单配置完 clone 一个仓库看输出里的地址是什么格式不匹配就换。2.3 方向问题insteadOf 只管拉取push 要单独设计很多人在这一步会掉坑里。insteadOf默认影响的是拉取方向的请求也就是 fetch、pull、clone。但 push 方向怎么办如果只配置了insteadOfpush 的时候 git 默认还是会走原始地址https://github.com/xxx不会走代理。这对我们来说其实是件好事因为 gh-proxy.com 这类加速服务主要解决下载方向的速度并不负责处理 push你也不能指望一个公开代理服务拿到你的写权限。但有个特殊情况如果你在别的配置里用了反向规则或者把insteadOf作用到了 push 方向push 就会试图往代理地址推结果大概率是 404 或者鉴权失败。为了保险起见我建议把 push 方向的规则也显式写清楚push 时把代理前缀还原回 GitHub 原始地址。git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/pushInsteadOf的意思是当 push 操作遇到的地址以https://gh-proxy.com/https://github.com/开头时把它还原成https://github.com/。这样无论拉还是推git 都会走正确的链路拉走代理推走原始地址两条路互不干扰。3. 实操记录配置全局加速代理并验证3.1 配置前准备动手之前建议先确认三件事git --versiongit 版本最好在 2.x 以上版本太老的话url.*.insteadOf的相关行为可能有差异虽然基本语法很早就有了但老版本兼容性不好说。git config --global --list看一眼现有全局配置避免和已有规则冲突。如果~/.gitconfig里已经有其他insteadOf规则先看看前缀是否重叠。cp ~/.gitconfig ~/.gitconfig.bak备份一下配置文件万一配乱了能立刻还原。这个习惯我强烈建议保留尤其是你全局配置里已经有 user.name、user.email、credential.helper 这类关键信息的时候。3.2 写入配置直接执行下面两条命令一次搞定拉取和推送两个方向# 拉取方向https://github.com/ 自动替换为加速代理地址 git config --global url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/ # 推送方向遇到加速代理地址自动还原为 GitHub 原始地址 git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/执行完之后你可以直接打开~/.gitconfig看一眼内容应该是这样的[user] name yourname email youexample.com [url https://gh-proxy.com/https://github.com/] insteadOf https://github.com/ [url https://github.com/] pushInsteadOf https://gh-proxy.com/https://github.com/3.3 验证配置配置文件写好了不代表规则一定生效建议确认一遍git config --global --get-regexp \.insteadOf$输出里应该能看到两行url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/ url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/如果你只想看某个 key用git config --global --get也可以。到这里配置已经生效了。3.4 实测clone、pull、remote -v 三步走配置完最重要的就是实测。找一个 GitHub 仓库试一下git clone https://github.com/octocat/Hello-World.git正常的话clone 过程中会看到类似这样的信息Cloning into Hello-World... remote: Enumerating objects: 10, done. remote: Counting objects: 100% (10/10), done. remote: Compressing objects: 100% (7/7), done. remote: Total 10 (delta 1), reused 5 (delta 0), pack-reused 0 Receiving objects: 100% (10/10), done. Resolving deltas: 100% (1/1), done.这里有一个小细节部分加速服务在 clone 输出里会显示经过重写后的地址比如出现https://gh-proxy.com/https://github.com/octocat/Hello-World.git说明规则确实生效了。如果输出信息里没有明显提示你可以通过另一个方法确认GIT_TRACE1 git fetch origin看调试日志能追踪到 URL 重写的过程。再验证一下本地仓库的 remote 配置有没有被改动cd Hello-World git remote -v正常应该还是origin https://github.com/octocat/Hello-World.git (fetch) origin https://github.com/octocat/Hello-World.git (push)这正是insteadOf的妙处规则配置在全局仓库本身保持干净。你给任何同事看 remote 地址还是官方原址谁也看不出你私底下做了加速。3.5 把配置做成脚本一键切换配置虽然简单但我还是建议你把它写成一个脚本方便以后在“加速/不加速”两个状态之间快速切换。我自己习惯在~/bin/下放一个git-ghproxy-on.sh#!/bin/bash # 开启 GitHub 加速代理 git config --global url.https://gh-proxy.com/https://github.com/.insteadOf https://github.com/ git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/ echo gh-proxy.com 加速已开启再写一个关闭脚本git-ghproxy-off.sh#!/bin/bash # 关闭 GitHub 加速代理 git config --global --unset url.https://gh-proxy.com/https://github.com/.insteadOf git config --global --unset url.https://github.com/.pushInsteadOf echo gh-proxy.com 加速已关闭这样如果哪天代理服务不稳定你想先切回直连一条命令搞定不用记住那么长的配置项。4. 常见问题与排查技巧4.1 push 失败或提示没有权限配置完之后 push 报错是大家最常踩的坑之一。最常见的现象是remote: Not Found fatal: repository https://gh-proxy.com/https://github.com/xxx/xxx.git/ not found或者类似 404、403、401 之类的鉴权报错。原因很简单push 请求走了 gh-proxy.com而代理服务没有也不会处理你的 push 请求。解决办法就是前面说的加上pushInsteadOf反向规则让 push 强制走原始地址。git config --global url.https://github.com/.pushInsteadOf https://gh-proxy.com/https://github.com/如果你加了这个规则依然报错检查一下规则是不是写反了或者 push 时 URL 前缀不是https://gh-proxy.com/https://github.com/而是别的格式。4.2 配了规则却没走代理配置都写了git clone依然慢得跟蜗牛一样看起来像没生效。这时候按顺序排查检查项操作说明仓库内 local 配置是否覆盖git config --local --listlocal 优先级高于 globalremote 地址是否为 https 开头git remote -vssh 地址不走这个规则是否有其他 insteadOf 规则git config --global --get-regexp \.insteadOf$看前缀是否冲突代理服务本身是否可用curl -I https://gh-proxy.com/https://github.com/先确认代理能通特别是第二条很多人克隆仓库用的是 SSH 地址比如gitgithub.com:owner/repo.git这不是 https 前缀insteadOf的规则就不会匹配。如果你想给 SSH 地址也做替换需要额外配置但我个人不建议这么做SSH 的用途主要就是 push而且代理服务一般不对 SSH 协议开放没必要折腾。另外注意一下大小写和末尾斜杠。GitHub 地址大小写其实不敏感但 URL 前缀匹配是大小写敏感的如果地址是HTTPS://GITHUB.COM/规则也不会命中。虽然这种情况平时很少见但了解这个机制能帮你快速定位问题。4.3 clone 报 502 Bad Gateway 之类错误如果你在 git 里配置过本地 HTTP 代理端口比如http.proxy指向127.0.0.1:1572而那个本地服务恰好没启动clone 的时候就会报一堆unexpected status 502 bad gateway或者连接异常。这和insteadOf加速配置是两套东西容易混淆。排查时先看 git 的代理设置git config --global --get http.proxy git config --global --get https.proxy如果有值说明 git 请求试图先经过本地代理而代理端口不可用自然报错。这不是 gh-proxy.com 的问题是本地链路问题。另外一个常见原因是代理服务偶发不稳定。免费公开服务高峰期 502 或超时并不罕见。解决办法是稍后重试或者临时切换回直连。这种时候脚本的价值就体现了一条命令关掉加速业务不受影响。4.4 如何临时绕过或彻底移除配置有时候你可能想临时对比一下加速前后的速度或者 gh-proxy.com 临时抽风想先用直连但不想改配置。有个很干净的技巧用环境变量临时禁用全局配置。GIT_CONFIG_GLOBAL/dev/null git clone https://github.com/octocat/Hello-World.gitGIT_CONFIG_GLOBAL/dev/null意思是让 git 忽略~/.gitconfig用空配置启动。这样就能临时走直连别的行为完全不受影响。如果你确定以后不想再用了移除配置更简单git config --global --unset url.https://gh-proxy.com/https://github.com/.insteadOf git config --global --unset url.https://github.com/.pushInsteadOf删干净之后git config --global --get-regexp \.insteadOf$应该没有任何输出。4.5 问题速查表现象最常见原因解决办法clone 还是慢地址没变remote 是 ssh 地址改成 https 地址或另配 ssh 规则push 404 / 403push 走了代理添加pushInsteadOf还原规则报 502 / 连接失败本地 http.proxy 端口不可用或代理服务不稳定先查http.proxy再考虑切换代理配置了但不起作用local 配置覆盖 / 前缀不匹配检查 local 配置和 URL 前缀想绕过加速临时忽略全局配置用GIT_CONFIG_GLOBAL/dev/null最后再分享一个我实际使用中的体会这个方案最舒服的地方不是速度提升多少倍而是“无感”。配置好之后你不需要记得今天有没有加代理前缀不需要维护一个改了地址的仓库列表git 会在底层自动帮你把事情办好。这套思路不止适用于 gh-proxy.com任何支持双重 URL 格式的同类 GitHub 加速服务都可以用同样的方式接入换服务商时只要把~/.gitconfig里对应的前缀替换掉就行。另外一个小技巧如果你经常 clone 的是大仓库可以把配置和--depth1浅克隆配合使用绝大多数场景下体验会再上一个台阶。我先说这么多剩下的坑你自己踩过就明白了。
