macOS 上 Homebrew 更新與安裝總逾時？Clash 分流 formula、Bottle CDN 與 GHCR 實測（2026）

1. brew 不是單一網址：formula、Bottle、GHCR 與 GitHub CDN 怎麼串

對大多數開發者來說，brew install openssl這種指令的心理模型是「連到某一個 Homebrew 伺服器抓東西」。但實際上，brew會在多個步驟間切換不同的網域名稱與 CDN 出口：要先確認公式版本與相依性，再決定是否使用預編譯 Bottle；若選擇 Bottle，安裝程式會向對應的 registry 或發行資產位置請求簽章資訊、manifest、壓縮包。這條鏈路上最常見的流量目的地包含ghcr.io（容器／套件 Registry）、github.com（網頁與 API）、以及各式各樣落在 *.githubusercontent.com底下的原始檔、release 資產、重新導向後的真正檔案位址。

這種多段式請求對分流設計非常敏感：第一段成功只代表索引或 API 尚可，不等於第二段下載 Bottle 的二進位會走同一個節點品質與路由策略。許多人會把問題誤認為「DNS 壞掉」，是因為終端機錯誤訊息常常只顯示某一個 hostname 連線逾時；但若你在 Clash 連線紀錄裡對照，會發現那是某一張 CDN 或 GHCR 邊緣節點在你的網路環境下往返時間過長或被中途重置，並不是 macOS 內建解析器本身無法解析 AAAA／A 紀錄。換句話說，你要處理的是出口一致性與頻寬路徑，而不是單純「換一組公開 DNS」就能結束的故事。

另一個常在論壇被忽略的細節是tap 與第三方公式來源：某些組織會維護自有 tap，clone／更新動作會指向github.com上的另一組 repo；這會讓「我已經把 ghcr.io 走強國際線」仍然不夠——因為git 傳輸本身仍可能在 github.com 或其他託管網域上卡住。因此在規劃規則時，請把開發者情境下的 GitHub 家族網域視為一整張互通的地圖，而不是只盯著某一個brew.sh主域。

2. 典型症狀：哪種卡住很像 DNS、其實是出口策略

使用者真實搜尋時常會下關鍵詞組合像是「brew 卡住」「brew update 很慢」「homebrew ghcr timeout」這類長尾語句；對應到現場症狀，最常見的有三種：①brew update能在較短時間結束或看似正常，但brew install在某個套件的 Bottle 階段長時間無進度；②反覆出現curl／openssl TLS handshake相關的錯誤訊息，讓人以為憑證壞掉；③公司網路環境透明攔截 HTTPS，使得只有瀏覽器信任企業根憑證，終端機行程卻仍使用預設信任庫。

這三種都可以先用同一套排查順序過濾：先看brew 行程是否真的進入本機 mixed-port（連線紀錄有沒有對應連線）；再看命中規則名稱是否與你預設為「開發者／國際線」的策略組一致；最後再看該策略組節點對github.com或ghcr.io的連線是否穩定。若你連第一步都看不到連線，問題往往在HTTP_PROXY／HTTPS_PROXY沒設或設錯埠，或是某些 shell 插件把你的請求導向別的代理埠。這類現象與 npm／pnpm 環境代理與分流文章描述的「終端繞過 GUI 系統代理」非常類似，只是套件管理器換成 brew。

相反地，如果你在紀錄裡看得到連線且規則命中正確，但仍長時間卡在Downloading，那就要開始懷疑節點頻寬、對端 CDN 節點壅塞或被動限速——這時候更值得調整url-test／fallback策略組配置，而非繼續堆DOMAIN-KEYWORD規則。若你需要複習策略組測速語意，可延伸閱讀 url-test／fallback 穩定性專文。

3. 實務上最常需要一起打包的分流網域清單（示意）

下面的網域集合並非官方永久固定清單：Homebrew 上游會調整發行策略，CDN 供應鏈也可能演進；但它的價值在於給你一張「九成情境夠用」的起點，你可以再用第八節的 verbose 輸出把它調得更精準。一般會建議同一組開發者策略組至少涵蓋：ghcr.io（GHCR）、github.com（含 API）、以及githubusercontent.com這類使用者內容網域後綴——因為 Bottle／release 資產常有多次 HTTP 302／CDN 重新導向，最終落地的 hostname 不一定永遠是你印象中那一個。

公式索引方面，官方站點／API 相關網域（例如formulae.brew.sh這類文件或 JSON API）也值得與前述 GitHub 家族對齊同一策略組，以避免「讀得到公式描述、抓不到對應 Bottle」的分裂感。若你的訂閱規則集本身已經有大而化之的 GitHub 規則，請務必檢查它是否在更早的位置把流量送去你不想走的 MATCH；這種問題只能靠規則順序與覆寫檔優先級修正，而不是再加一段看似正確卻永遠排不到的條目。

# Example — replace policy group label with yours
rules:
  - DOMAIN-SUFFIX,company.internal,DIRECT
  - DOMAIN-SUFFIX,ghcr.io,🔰 Dev-Proxy
  - DOMAIN-SUFFIX,github.com,🔰 Dev-Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,🔰 Dev-Proxy
  - DOMAIN-SUFFIX,brew.sh,🔰 Dev-Proxy

若你擔心DOMAIN-SUFFIX,github.com過於寬鬆，可以在熟悉連線紀錄後改用更細的 DOMAIN／PROCESS 規則；但對一般個人開發工作站而言，過窄規則更容易在遇到重新導向鏈時漏網，反而造成更難排查的間歇性逾時。

4. macOS 終端對齊：HTTP_PROXY、HTTPS_PROXY 與系統代理邊界

macOS 上的系統代理設定並不總會自動套用到 Terminal.app／iTerm2／Warp裡的每一個子行程；許多使用者只在 GUI 開了系統 HTTP 代理，結果brew仍在直接連線，連線紀錄裡當然看不到預期的規則命中。對大多數Clash mixed-port場景，仍然推薦你在當前 shell session 明確匯出HTTPS_PROXY=http://127.0.0.1:PORT（以及對應的 HTTP_PROXY），並同步小寫變數，以降低某些函式庫只吃其中一種命名的機率。

NO_PROXY建議列入localhost、127.0.0.1，以及你希望強制直連的公司內網資源或可信區域 Bottle 鏡像主機名；這麼做可避免開發套件流量無謂繞一圈再回到內網。另一方面，請不要把 GHCR 或 GitHub 任意塞進 NO_PROXY，除非你真的確認該 hostname 在內網鏡像後完全不會再跳回國際 CDN——否則你會親手製造「規則看似正確卻一直連線失敗」的矛盾現場。

# Session-only; point to local Clash mixed-port
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=$HTTP_PROXY https_proxy=$HTTPS_PROXY
brew update

5. Clash／mihomo：規則順序、策略組與「別被 MATCH 提早送走」

規則由上而下第一次命中即止，這句話老生常談，但在 brew 場景特別致命：許多訂閱檔在中段就放了一條GEOIP 或過寬的 DOMAIN-KEYWORD，會把你的githubusercontent.com請求提前送去直連或另一組中繼策略，後面你再新增的GHCR 精準規則根本碰不到這條連線。遇到這種情況時，請優先用覆寫檔／prepend 規則（依你所用的 GUI 客戶端而定）把開發者網域組放到訂閱規則之前，並用連線紀錄確認規則名稱真的換成你期望的那一條。

另一個常見誤區，是誤以為PROCESS-NAME規則一定優於 DOMAIN 規則——實際優先級仍以設定檔中的順序為準；此外 brew 會fork 子行程呼叫curl或其他工具下載檔案，過度依賴 PROCESS 規則反而容易漏匹配。對大多數使用者，仍以DOMAIN-SUFFIX／DOMAIN包住 ghcr／GitHub／usercontent／brew.sh會較省心。

若你尚未匯入任何訂閱，可先完成 訂閱匯入教學建立基礎策略組，再把本文第三節的網域條目貼進你自己的開發者策略組底下做驗證；這比憑空手寫MATCH更符合長期維護節奏。

6. DNS、Fake-IP、Sniffer：怎麼讀連線紀錄才不誤判

mihomo核心下的DNS 模式會直接影響「規則看到的對象究竟是網域名稱還是 IP」。當你啟用Fake-IP時，終端程式可能在 TLS 之前就拿到了看似奇怪的區段位址；若未開啟或不信任 Sniffer 補全校驗，HTTPS 流量的規則匹配就可能長時間停留在IP 規則／MATCH那一側，使你誤以為 GHCR「無法連線」。這類問題與其盲目調整brew自身，不如回到 DNS／Fake-IP 路由基礎重新對齊。

對DoH／DoT亦有類似提醒：某些 ISP 或企業會對加密 DNS 做攔截或降級，使你在 YAML 裡精心配置的 resolver 根本沒有生效，現場會呈現為「偶發解析很慢／AAAA 優先走向錯出口」。這時請同步核對macOS 系統網路設定與Clash DNS 區塊是否互相打架；亦可延伸閱讀 DoH on macOS中的對齊思路。

當你把連線紀錄中的 Host／SNI／規則命中列三者對齊後，會發現許多所謂「brew 壞掉」其實只是規則語意與解析視角不一致；這也是為什麼我們強調觀測優於猜測。

7. brew 環境變數：BOTTLE_DOMAIN、API 與除錯開關（保守用法）

Homebrew 提供多種環境變數來調整 Bottle 來源、GitHub API endpoint、curl 超時與 verbose 診斷資訊；這些開關在企業鏡像站或離線構建環境非常有用，但若只想「家用機順利裝套件」，請優先把代理與規則對齊，再考慮調整這些變數——否則很容易把問題從網路層轉移到組態漂移，日後更難對同伴解釋為何只有你電腦裝得起來。

若你確定要使用HOMEBREW_BOTTLE_DOMAIN類鏡像，請務必在規則裡單獨為鏡像 hostname 決策出口，並保留對仍會跳回 GitHub／GHCR的後綴規則；同時請記錄你當時使用的鏡像版本與時間點，以便上游調整後能快速回溯。對一般使用者，我只建議在你能讀懂 verbose 輸出的前提下逐步開啟這些選項。

GitHub API 速率議題有時會表現為無預警失敗或長時間等待；若你常在 CI／自動化環境批次跑 brew，請確保TOKEN／認證配置符合上游指引——這方面語意接近本站 Git／GitHub HTTPS文章的「憑證走代理」討論，只是把場景換成套件倉庫 API。

8. 驗證：brew verbose、curl 探測與連線清單三方對照

建議你把排查固定成三條時間線對照：①終端機跑brew update -v或brew install -v時輸出的URL／hostname；②挑選其中一兩個可疑網域，用curl -I或最小 GET 探測確認TLS／HTTP是否在同一組代理環境下穩定；③在 Clash／Verge／FlClash 連線面板確認對應連線命中哪條規則與策略組。這個方法能把「沒進代理」「進錯組」「進對組但節點太差」三件事快速分叉。

若 verbose 輸出顯示長時間停在某一個 tarball／bottle digest下載階段，請不要第一時間調整 brew 內部 concurrency；先把連線紀錄裡的對端 hostname記錄下來，回頭核對第三節清單是否涵蓋。若反覆遇到大型檔案中途斷線，可以再結合fallback策略組找更適合下載型流量的節點——這與影音 CDN 類問題的心智類似，可參考 YouTube／Google Video CDN文中的「長連線」觀察方式。

# Inspect which URLs brew touches
brew update -v
brew install wget -v

9. 常見問題 FAQ