TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
蝦殼是什麼？免費 GitHub 下載加速，瀏覽器測速挑鏡像節點
蝦殼（xiake.pro）是免費的 GitHub 下載加速網站，把鏡像節點網域接在下載網址前面，讓第三方伺服器代抓檔案。它在瀏覽器裡對 32 個節點自動測速、挑延遲最低的用；實測官網本身不代理流量、經鏡像下載的檔案雜湊值與直連一致，但內容把關要靠檢查碼自己來。
用 AI 摘要這篇文章：
GitHub 的檔案抓不下來或抓得太慢的時候，蝦殼（xiake.pro）給的解法很直白：在你的下載網址前面接上另一個網域，讓檔案改由那個網域的伺服器代抓。三個最常見的問題可以先答。它自己不是加速伺服器，官網不代理任何流量，實測把它的網域當前綴去抓檔案，得到的是 404。它真正做的事，是在你的瀏覽器裡對 32 個第三方鏡像節點測速，自動挑延遲最低的那個來產生下載指令。至於經過鏡像的檔案能不能信任，我實測抓下來的檔案與直連 GitHub 的雜湊值完全一致，但這只代表我測的那一次、那一個節點，機制上沒有任何保證，把關要靠自己。
它算哪種加速器？把你的網址前面接上別人家的網域
打開蝦殼首頁，中間一個輸入框，左邊固定顯示目前選中的節點網域，右邊貼上 GitHub 連結，下面三個分頁立刻產生三種指令：Git Clone、wget 或 curl、瀏覽器直接下載。產生的方式就一行：把節點網址放在前面，後面原封不動接上你的 GitHub 網址。
git clone https://gh-proxy.com/https://github.com/sharkdp/fd
wget https://gh-proxy.com/https://github.com/sharkdp/fd/archive/master.zip這招不是蝦殼發明的。所謂 GitHub 加速鏡像，多半是站方架一台反向代理伺服器，收到「代抓這個網址」的請求後，由它去向 GitHub 拿檔案再轉給你。你的連線品質取決於你到那台伺服器的路，與你到 GitHub 的路無關。概念上它跟把大檔先同步到多個免空再讓人挑速度快的那個，是同一個思路的不同端點：一個在分發端做鏡像（例如 Mirrored.to 這類一次同步多個空間的工具），一個在取用端做中繼。
有趣的地方在於蝦殼自己不架代理。它的首頁是一個靜態頁面加一份 JavaScript，我把 GitHub 連結接在 xiake.pro 網域後面實際打了一次，伺服器直接拒絕。頁面上的指令範例雖然寫著 xiake.pro 當前綴，但那只是還沒輸入網址時的佔位文字；真的產生指令時，前綴換成的是 32 個節點裡測速最快的那個網域。這個網站賣的不是頻寬，是挑選。
頁面使用說明寫的支援範圍是：GitHub 檔案、Releases、打包下載（Archive）、Gist，以及 raw.githubusercontent.com 的原始檔；整個專案資料夾直接打包下載則不在支援之列，頁面的三種範例指令給的正好是 git clone 與壓縮檔連結這類替代路線。這是站方的說法，我實測過的是 release 檔與 raw 檔兩種，加上淺層 clone 一次，行為都正常。
整個使用流程不用註冊、不用裝任何東西。打開頁面等它測完速，貼上連結，三個分頁會即時換成套好前綴的指令，每一種旁邊都有複製鈕；按輸入框右邊的下載鈕，則會直接開新分頁走節點網址下載。頁面也提供一次複製全部指令的選項，方便貼進自己的筆記。三種方式各有適合的場景：
| 下載方式 | 適合 | 留意 |
|---|---|---|
| Git Clone | 要整個倉庫的程式碼與歷史 | origin 會保留鏡像前綴，之後 pull 都經過該節點 |
| wget 或 curl | 抓單一 release 檔、raw 原始檔 | 抓完比對檢查碼再使用 |
| 瀏覽器直接下載 | 偶爾抓一個檔、不想開終端機 | 網址列看得到節點網域，斷線續傳視瀏覽器而定 |
用鏡像跑 git clone 有一個要留意的細節：clone 下來的倉庫，origin 遠端網址會原封保留鏡像前綴，之後每次 git pull 都繼續經過那個節點。我用淺層 clone 實測，commits 一致、大小一致，但哪天那個節點死了，pull 就會跟著失敗。解法很簡單，clone 完把遠端換官方網址即可：
git remote set-url origin https://github.com/sharkdp/fd.git換掉遠端之後，這個倉庫就與一般 clone 無異，鏡像只作用於第一次下載的那幾百 MB。
32 個節點現在活著幾個？我把每一個都打了一遍
節點名單寫死在頁面的 script.js 裡，數一數正好 32 個，使用說明寫節點來自網路收集；程式碼註解則說這 32 個是經多輪實測保留、按平均延遲排過序的穩定節點。我用頁面同款的探測方式，在自己的機器上對 32 個節點同時發請求，結果是 26 個有應、6 個逾時；改在瀏覽器裡跑官方頁面那一次，介面顯示的可用節點是 22 個。兩次結果不一樣本身就是重要資訊：這個池子是浮動的，今天活的節點明天不一定在。
延遲的分布相當分散，以下是 2026 年 9 月 22 日我實測的前幾名：
| 節點 | 延遲 |
|---|---|
| gh-proxy.com | 350 ms |
| tvv.tw | 359 ms |
| ghproxy.cxkpro.top | 401 ms |
| gh.927223.xyz | 420 ms |
| gh.b52m.cn（我測到最慢的一個） | 3355 ms |
最快與最慢差了將近十倍。要誠實交代一點：我終端機探測的逾時認定比頁面寬鬆，3355ms 這個節點按頁面自己的 3 秒判死線其實活不下來；被剔除的 6 個則是連一張小圖都擠不出來。這就是為什麼這個工具把力氣花在測速上：與其記住某個「聽說很快」的鏡像，不如每次現場量。
它測速的工程細節值得拆開看。頁面拿微軟 VS Code 倉庫裡一張 70 乘 70 像素的小圖當探針，這張圖只有 338 bytes，32 個節點同時發、誰先傳完誰就是目前最快的候選；驗證方式還多走一步：確認傳的真的是那張 70 乘 70 的圖，用這招擋掉拿追蹤像素或亂塞內容充數的偽裝節點。超過 3 秒沒傳完直接判死，從清單剔除；按下重新檢測，被剔除的節點會重新納入再測一輪。整段邏輯在瀏覽器裡跑完，測出來的延遲就是你這台機器、這個網路當下的真實數字。
選擇節點的方式也算聰明：第一個傳完探針的節點會立刻被選上，你不用等 32 個全部測完就能開始貼連結，其他節點的成績隨後陸續補進清單，最後再依延遲重排。如果全部逾時，頁面會保留原始名單、以第一個節點當預設，起碼介面不會壞掉。這些設計單獨看都是小工夫，疊起來就是「開頁面三秒後拿到一個能用的節點」這個體驗。
對隱私比較敏感的讀者要知道兩件事。測速會對 32 個節點同時發出請求，活著的節點都會看到你的 IP 位址與一次請求紀錄；另外首頁載入了百度統計的腳本，頁面瀏覽行為會被記錄，不想被記可以用瀏覽器的追蹤封鎖功能擋掉。
經過鏡像的檔案，跟 GitHub 上的同一份嗎？
這是整套機制裡最該問的問題，因為測速通過只代表節點能傳一張 338 bytes 的小圖，不代表你要抓的幾十 MB 檔案沒有被動過。探針和本體是兩個不同的請求，中間沒有任何內容比對。
我做了可以直接重現的驗證：挑 fd 這個命令列工具的 v10.2.0 macOS 安裝包（1,301,191 bytes），直連 GitHub 抓一份，經過鏡像節點再抓一份，兩邊比對。MD5 同樣是 8b26c648bec2d46418cb4a943346778d，SHA-256 也逐位元組一致。就這一次抽樣來說，節點傳的是原封不動的檔案。
但要把「這次一致」推成「永遠一致」，機制上沒有支撐。鏡像節點在傳輸路徑上的位置就是中間人：它看得到你請求的完整網址，也做得到把內容換掉再給你。蝦殼對這 32 個節點沒有所有權也沒有稽核能力，頁面上關於節點來源僅交代了一句：來自網路收集整合，並向分享者致謝；程式碼裡同樣找不到任何檢查碼比對的邏輯。還有一個小細節：輸入框的網址檢查其實很寬鬆，只看字串裡有沒有出現 github 這幾個字母，程式裡原本有一套更嚴格的網域規則，但那段被註解掉了。對一般使用影響不大，但別期待它幫你擋下什麼。
這一輪 32 個節點測到 6 個逾時，將近五分之一的死亡率，名單其實持續在換血。名單上沒有交代任何經營者身分，這類公共鏡像一般只能理解為個人或社群用自有頻寬架的服務，沒有服務水準保證，經營者收掉了、流量費付不出來了，節點就消失。這類反向代理為了省自己的頻寬，通常也會快取熱門檔案，你抓到的檔案有機會是節點上暫存的一份，未必是它現場向 GitHub 拿的新一份；多數時候兩者內容相同，但這再次說明內容的最終把關者只能是你。對照著看，蝦殼把「節點會死」這件事處理得比多數同類頁面認真：自動測速剔除、手動重新檢測、每次造訪都重量一遍，勝過放一份半年沒清的死名單。
所以自保動作很明確。要安裝或執行的檔案，抓完先比對官方發布的檢查碼：GitHub 的 release 頁面常常會附 SHA256，本機一行 shasum -a 256 檔名 就能對（Windows 用 PowerShell 的 Get-FileHash）；release 頁面沒附檢查碼的，可以用直連或換一個節點再抓一份，比對兩邊的 MD5，一致才算過。另外，私有倉庫或網址裡帶存取權杖的連結，永遠不要經過這類代理，權杖會原封不動送到節點端，等於把鑰匙交出去。
台灣的網路直接連 GitHub 就很快，那誰需要它
誠實講測試環境：我用的網路直連 GitHub 本來就不慢。同一個 1.3 MB 的 release 檔，直連抓 2.3 秒，經過鏡像節點抓 2.1 秒，差距在誤差邊緣；淺層 clone 同一個倉庫，直連 1.3 秒、經鏡像 2.8 秒，鏡像反而慢了一倍。在我的環境裡，這工具換不到速度，有時還倒貼。
什麼時候它才有感？你所在的網路連 GitHub 特別慢或常常斷線的時候，例如部分校園或企業網路、跨境連線品質起伏的時段，或 raw.githubusercontent.com 這類子網域連不穩的環境。這時多一條經由第三方的路可以繞，32 個節點自動測速，比起自己收集鏡像清單、壞一個再找一個省事得多。如果你的問題是 DNS 層級的解析異常或連不上 GitHub 網域本身，改 hosts 檔把網域指到可用的位置是另一條不經過第三方的路，之前介紹過的 SmartHostsTool 就是做這件事的工具，兩種方法可以搭配著試：hosts 顧 DNS，鏡像顧傳輸，撞牆的原因不同，解法也就不同。
還有一種用法跟速度無關：把它當鏡像節點的健檢面板。32 個節點誰活著、誰延遲低，頁面上一目了然，就算不透過它產生指令，拿來挑一個放進自己的腳本或設定檔也行。節點延遲會依你的網路位置而不同，我的前十名不會等於你的前十名，這點頁面做得誠實：它量的是訪客端到節點的距離。
會執行的檔案先比檢查碼，帶權杖的連結走直連
收斂成一句話：網路環境讓你連 GitHub 很順的話，不需要它；連不順的話，它是一個把「收集節點、測速、挑選」這段雜務做好的免費前端，值得放進書籤，但信任要自己把關。
用的時候守住兩條底線。會執行的檔案（安裝包、二進位工具）抓完務必比對檢查碼，因為整條傳輸路上唯一會驗內容的人是你；帶權杖或私有內容的網址永遠走官方直連。做到這兩條，這個工具的風險就收斂到可以接受的水位。
最後交代身世：蝦殼這個名字底下還經營一個軟體應用商店網站，導覽列上收著 Mac、Windows、Android 的軟體合集，GitHub 加速頁掛在同一個網域下、沿用同一套版型，頁面支援深色模式，從伺服器標頭看 2026 年 9 月下旬仍持續在調整，屬於活著且有在顧的頁面。常在 GitHub 找東西的人，也可以順手看看 SimilarRepos 這類用 AI 推薦相似專案的擴充套件，找倉庫跟抓倉庫配套用。
