[2022-03] GitHub 加速终极教程

2022-03-28 14:45:43 +08:00
 AllenHua

时常看到 V 站吐嘈 git clone 慢的帖子,本人写了这篇文章,推荐 阅读原文


本文意图解决使用 GitHub 访问( https) 或者 git clone ( https or ssh )慢的问题。在此分享我的方法,我所了解的 GitHub 加速最佳方案。

前提是,你的木弟子应该还行,木弟子越好,GitHub 体验越好

很多文章没有讲全面,只讲了 http proxy ,而没有讲 ssh proxy 。事实上大部分程序员使用 GitHub 都会使用 SSH keys (普通用户可能就不会了),在本机生成 rsa 公私钥(其他的类型还有 dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk),然后把公钥内容拷贝、设置进 GitHub 。

设置 Http Proxy

$ git config --global http.proxy socks5://127.0.0.1:7890

事实上使用 socks5h 更佳,即

$ git config --global http.proxy socks5h://127.0.0.1:7890

h 代表 host ,包括了域名解析,即域名解析也强制走这个 proxy 。另外不需要配置 https.proxy,git 不认的(关于这一点我认识不是很清晰,希望有人解惑)。

推荐使用 socks5 代理,因为 socks5 包含 http(s)。而且 socks5 代理工作在 osi 七层模型中的会话层(第五层),https/http 代理工作在 osi 七层模型的应用层(第七层), socks 代理更加底层。所以就没必要配置 git config --global http.proxy http://127.0.0.1:7890 了。

这样配置的话会使本机所有的 git 服务都走了代理,假如你在良心云上(国内主机)部署了自己的 gitea ,域名 https://gitea.example.com,那么可以只配置 GitHub 的 http proxy ,即

$ git config --global http.https://github.com.proxy socks5://127.0.0.1:7890

设置 SSH Proxy

Linux & macOS

配置文件在用户家目录下的 .ssh/config 其中 nc 程序位于 /usr/bin/nc

$ cat ~/.ssh/config

Host github.com
 Hostname ssh.github.com
 IdentityFile /xxx/.ssh/github_id_rsa
 User git
 Port 443
 ProxyCommand nc -v -x 127.0.0.1:7890 %h %p

nc 就是 netcat ,引用一段描述

netcat is a simple unix utility which reads and writes data across network connections, using TCP or UDP protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities. Netcat, or "nc" as the actual program is named, should have been supplied long ago as another one of those cryptic but standard Unix tools.

译文: netcat 是一个简单的 unix 实用程序,它使用 TCP 或 UDP 协议跨网络连接读取和写入数据。 它被设计成一个可靠的“后端”工具,可以直接使用或由其他程序和脚本轻松驱动。 同时,它还是一个功能丰富的网络调试和探索工具,因为它几乎可以创建您需要的任何类型的连接,并且具有几个有趣的内置功能。Netcat ,或实际程序命名的“nc”,早就应该作为另一种神秘但标准的 Unix 工具提供。

Windows

Win 下与之对应的 netcat 程序是 connect.exe,程序位于 Git 安装路径 C:\Program Files\Git\mingw64\bin,win 下推荐使用 Git Bash ,路径也是 Linux style

$ cat ~/.ssh/config

Host github.com
 Hostname ssh.github.com
 IdentityFile /c/users/xxx/.ssh/github_id_rsa
 User git
 Port 443
 ProxyCommand "C:\Program Files\Git\mingw64\bin\connect.exe" -S 127.0.0.1:7890 %h %p

补充信息

为什么 hostname 是 ssh.github.com,为什么要用 443 端口,ssh 默认不是 22 端口么?

因为有些木弟子对于 22 端口做了限制,要么禁止了,要么有些抽风,这时经常会遇到如下错误

kex_exchange_identification: Connection closed by remote host

所以如果 22 端口不畅就使用 443 ,安全可靠。ps: 22 端口时 hostname 请填 github.com。这部分请扩展阅读 此文

至于网页访问 GitHub ,借助木弟子访问已然是日常,要么浏览器扩展 SwitchyOmega,要么系统代理,要么直接使用 Clash 的分流策略等等。我的习惯还是使用 Switchy Omega 。

这样配置之后 git clone https://github.com/xxx/yyy.git 或者 git clone git@github.com:xxx/yyy.git 以及 git pullgit push 等等操作都很快了,除非科学的工具不行。

难免有误,欢迎大家补充和纠正。

12465 次点击
所在节点    程序员
49 条回复
Huelse
2022-03-28 17:46:40 +08:00
@devcat9 不一定,如果用自建的 dns 服务就可以直连,目前我就是这样访问的
ruixue
2022-03-28 18:06:18 +08:00
@AllenHua #17 楼主你这么做还是有用的,v2ex 如果主帖内容里包含“梯子”或“科学上网”等词,虽然不会发不出去甚至 ban ip ,但是会导致不登录的情况下访问帖子直接跳转首页,改成木弟子就不会了
brust
2022-03-28 18:06:43 +08:00
你都用梯子了,为什么不让 github 走梯子呢
brust
2022-03-28 18:07:24 +08:00
@brust 23
我指的是梯子的 pac 规则增加 github
AllenHua
2022-03-28 18:13:06 +08:00
@wonderfulcxm #20 因为 curl 是纯 http 服务,ssh 有不止于 http 应用层的服务(如上文 http 代理工作在应用层)

SSH 协议框架中最主要的部分是三个协议:

传输层协议( The Transport Layer Protocol ):传输层协议提供服务器认证,数据机密性,信息完整性等的支持。
用户认证协议( The User Authentication Protocol ):用户认证协议为服务器提供客户端的身份鉴别。
连接协议( The Connection Protocol ):连接协议将加密的信息隧道复用成若干个逻辑通道,提供给更高层的应用协议使用。 (摘自维基百科 Secure SHell 词条)

所以 ssh 需要更加底层的代理,你看 nc 和 connect 就是基于 TCP 和 UDP (第四层:传输层)做的一个工具。(手机打字和排版,见谅)
lostberryzz
2022-03-28 18:46:06 +08:00
有些回复看着真是血压高,生怕别人不知道他有个梯子似的。。

楼主的信息还是非常有用的,特别是 443 端口这一点,以前应该没在 V 站上看过,很有用的功能
wonderfulcxm
2022-03-28 18:54:22 +08:00
@AllenHua #25 不是很能信服,首先 cURL 支持的通信协议不止 HTTP ,还有 FTP 、SCP 、Telnet 、HTTP 、HTTPS 等等,别的不说,只说 HTTPS ,HTTPS 并不是一个单独的协议,而是对工作在一加密连接( TLS 或 SSL )上的常规 HTTP 协议。而 TLS 本身就是 传输层安全性协议 Transport Layer Security 的缩写,那它就是传输层的协议。从这点来说 https 也不止是于应用层的服务,这点跟 ssh 好像也没区别。。。
forcecharlie
2022-03-28 19:21:24 +08:00
如果对编程比较熟,可以自己写一个 hook 掉 git ,比如我就写过 tunnelssh https://github.com/balibuild/tunnelssh ,tunnelssh 根据你本机的代理设置自动让 git 走代理,无需修改任何配置,关闭代理同样可以访问。

git tunnel clone git@github.com:balibuild/tunnelssh.git
ysc3839
2022-03-28 19:49:22 +08:00
使用 socks5 代理时请注意,因为 git 使用 curl 请求 http ,而 curl 的 socks5://会使用本地 DNS 进行解析
ysc3839
2022-03-28 19:52:28 +08:00
@ysc3839 要使用 socks5h://才是远程解析
https://curl.se/libcurl/c/CURLOPT_PROXY.html

这也是我推荐使用 http 代理的原因。除此之外 Git Credential Manager 似乎不支持 socks5 代理,不能自动保存密码。以及有许多别的命令行程序是不支持 sock5 代理的,但大多数都支持 http 。
xxb
2022-03-28 20:57:53 +08:00
proxychains4 秒杀一切
AllenHua
2022-03-28 21:02:10 +08:00
@wonderfulcxm #27 确实,是我没有做好准备就回答了。查了下,curl 居然支持这么多协议:有 DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SBMS, SMTP, SMTPS, TELNET 和 TFTP 。但这些应该都是应用层协议…… 至于你说的 “从这点来说 https 也不止是于应用层的服务” 确实有道理。可能是 ssh 建立连接和通讯的过程比起 http 更加依赖应用层以下的网络数据包的封装。
AllenHua
2022-03-28 21:06:06 +08:00
@brust #24 pac 文件依然不能保证 git clone ssh 协议的 git 仓库时能够使用代理。
@forcecharlie #28 感谢
@ysc3839 #30 学习了
Spoience
2022-03-28 22:03:50 +08:00
Clash 的 TUN 模式会很舒服,无需配置其他代理,但是楼主写的确实很详细,收藏了
plko345
2022-03-29 00:16:46 +08:00
请教 OP 一个问题, docker pull 我理解应该走的是 https, 但设置了 https_proxy/http_proxy/all_proxy 却一点用没有, 访问 google.com 是正常的
anubu
2022-03-29 07:59:43 +08:00
@plko345 docker pull 的代理需要设置在 docker daemon 上,可以参考官方文档进行设置。
AllenHua
2022-03-29 09:07:10 +08:00
@Spoience #34 感谢
@plko345 #35 修改文件 /etc/docker/daemon.json 使用 key registry-mirrors 指定一个国内镜像了 docker hub 的 registry ,目的就是从国内服务器拉镜像,更快些。所以 docker pull 不需要 http 或者 socks 代理的,和 Linux Distro 换源原理类似。

```
"registry-mirrors": [
"https://hub-mirror.c.163.com",
"https://mirror.baidubce.com"
]
```

但有些 registry 不再提供服务了,或者变私有了,可参考 https://yeasy.gitbook.io/docker_practice/install/mirror#bu-zai-ti-gong-fu-wu-de-jing-xiang
20210610204811
2022-03-29 09:37:10 +08:00
不知墙为何物。
tkl
2022-03-29 10:05:58 +08:00
这会话层从哪来的???

rfc 里面没这么写

https://datatracker.ietf.org/doc/html/rfc1928

The protocol described here is designed to provide a framework for
client-server applications in both the TCP and UDP domains to
conveniently and securely use the services of a network firewall.
The protocol is conceptually a "shim-layer" between the application
layer and the transport layer, and as such does not provide network-
layer gateway services, such as forwarding of ICMP messages.
AllenHua
2022-03-29 10:26:06 +08:00
@tkl #39 rfc 里这句话说

“该协议在概念上是应用层和传输层之间的“填充层”,因此不提供网络层网关服务,例如转发 ICMP 消息。”

看上去是没有明确表示是表示层(第 6 层)和传输层(第 4 层)之间的第五层,但是这个“填充层” SOCKS 条目的 wikipedia 中有补充是会话层(第 5 层)。见 https://en.wikipedia.org/wiki/SOCKS

SOCKS performs at Layer 5 of the OSI model (the session layer, an intermediate layer between the presentation layer and the transport layer). A SOCKS server accepts incoming client connection on TCP port 1080, as defined in RFC 1928.

所以应该还是有些道理的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/843383

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX