前言
最近開源的兩個專案，先是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獲取到網頁資料之後發生的整個代理過程完全在國內，不再適用國際網際網路相關之規定。
原始碼與軟體釋出
原始碼
軟體釋出