GitHub clone 太慢？配置 gh-proxy.com 中转前缀自动加速

最开始让我动念头写这篇的，是又一次深夜拉开源仓库失败。进度条走到 98%，然后一行 RPC failed; curl 18 HTTP/2 stream 0 not retryable 打回原形。这种事碰多了，你自然会去找各种让 GitHub 访问变得顺畅的方法。后来我把 gh-proxy.com 这类中转前缀接到 Git 的 insteadOf 规则里，让所有 https://github.com/ 开头的地址在 Git 解析时自动换成加速前缀，clone 公开仓库基本没再折磨过我。

这篇文章不聊安装，也不讲 Git 基础命令，专门针对“git 配置 gh-proxy.com 中转前缀，自动替换 url”这个场景。会先拆一下 GitHub clone 慢在哪里，再说清楚这种加速网关的原理和边界，然后给完整的配置、验证、报错排查和撤销方法。无论你是刚接触 Git 的新手，还是被 clone 折磨过几次的开发者，照着操作基本都能跑通。

1. GitHub 仓库拉不动，先搞清楚慢在哪一环

很多人 GitHub 访问不顺，第一反应是换网络、找加速脚本，但这些动作多半没有对症下药。想彻底搞明白，得先把一次 clone 拆开看。

1.1 clone 不是“下载一个文件”，而是一连串网络请求

Git clone 一个仓库，表面上看是拉一个压缩包，实际上要经历这样几个环节：

1. DNS 解析：把 github.com 解析成服务器 IP；
2. TCP 连接加上 TLS 握手：和远程服务器商量好加密通道；
3. Git smart HTTP 协议交互：客户端先询问远端有哪些分支、对象，服务端再返回打包数据；
4. 持续传输对象：小仓库还好，大仓库会有几十万甚至上百万个对象需要传输和校验。

任何一环网络质量差，都可能让整个过程前功尽弃。所以你会看到各种奇怪的报错，比如：

• RPC failed; curl 18 HTTP/2 stream 0 not retryable
• early EOF
• Connection reset by peer
• unexpected disconnect while reading sideband packet

这些报错经常在进度条最后阶段出现，不是因为仓库有问题，而是长时间的数