前言

最近开源的两个项目，先是FastGithub，旨在解决访问github抽风的问题。然后开发HttpMouse项目，基于yarp的http公网反向代理到内网的服务端与客户端库，在开发HttpMouse的这段时间里，把YARP玩得彻底遛遛了，于是打算把YARP也用到FastGithub项目中，以彻底解决github抽风的问题。

原理

• 修改本机的dns服务指向FastGithub自身
• 解析匹配的域名为FastGithub自身的ip
• 请求不受污染的dns服务(dnscrypt-proxy)获取域名的ip
• 使用得到的ip进行无或有SNI的https反向代理

1.0.2版本的FastGithub，基于https测速来选择github的最佳ip，但https连接时，在一些网络环境下会表现为“连接被重置”。在摸索出“一种https连接到github且连接不被重置”的办法之后，决定让FastGithub充当一个https反向代理服务器，用于接收浏览器的请求，然后把请求转发给github，这里又用上了YARP了。

实现

dns解析

FastGithub把自己实现一个dns服务器，当浏览器访问github.com时，会向dns服务器解析github.com的ip，这时返回127.0.0.1。其实这个与修改host文件，让github.com解析为127.0.0.1效果是一样的，只是dns的方式更灵活：FastGithub开启，ip就为127.0.0.1，关闭后ip自动从备用dns获取。

https证书

FastGithub使用自颁发CA证书，为github.com颁发证书，用于与浏览器客户端的https请求与响应。证书的动态生成过程，与Filder是完全一样的，而且都需要在用户电脑将自颁发的CA安装到信任根证书目录。

无污染dns

dns协议由于没有加密数据，又是无连接的udp，所以数据被伪造非常简单，我们可以在本机运行dnscrypt-proxy，从dnscrypt-proxy解析域名的准确的ip，使用这个ip来做后续的请求转发连接目标。

https请求转发

使用“假证书”解密浏览器发给github的数据之后，将数据重新组装为github请求数据，发送到由dnscrypt-proxy解析到的ip的github服务器，同时把收到响应输出给浏览器，这个过程使用YARP，YARP = asp.netcore + HttpClient。FastGithub与github之间的连接，不会受到tcp连接重置的问题。

与Filder比较

FastGithub与Filder的行为非常相似，运行环境也相似，不同点在于Filder使用正向代理，配置系统或浏览器的代理服务器指向Filder，从而使请求数据经过Filder，而FastGithub是使用反向代理，配置系统的dns让符合相关域名的解析为本机ip，从而从而使请求数据经过FastGithub。

安全性说明

FastGithub生成自签名CA证书，要求安装到个人电脑上。但这个CA证书是FastGithub为每台不同计算机生成的，保存在CACert文件夹下的{计算机}.cer，就算是他人恶意将他自己生成好的CA证书打包捆绑再发型给别人，也因为无法知道别人的计算机名而不会使用他生成的CA证书，从而确保用户信任的这个CA证书不是他人生成的。

合法性说明

《国际联网暂行规定》第六条规定：“计算机信息网络直接进行国际联网，必须使用邮电部国家公用电信网提供的国际出入口信道。任何单位和个人不得自行建立或者使用其他信道进行国际联网。”

FastGithub本地代理使用的都是“公用电信网提供的国际出入口信道”，从国外的Github服务器到国内用户电脑的流量，使用的是正常流量通道，其间未对流量进行任何额外加密（仅有网页原有的TLS加密，用户和代理人并不掌握该TLS密钥，区别于VPN的流量加密），而FastGithub获取到网页数据之后发生的整个代理过程完全在国内，不再适用国际互联网相关之规定。

源代码与软件发布

源代码

github上的FastGithub

软件发布

gitee上的FastGithub