どこが詰まりやすいか：Homebrew と GitHub CDN の対応関係

開発者間で「ボトルを落としている途中で固まって見える」という相談は定番です。その多くが、ソースではなくコンパイル済みアーカイブ（ボトル）の取得側にヒントがあります。公式の構成は時代とともに移り変わりますが、体感として問題になりやすいのはオブジェクト保管まわり（例：objects.githubusercontent.com を含む）や、アーカイブの置き場、GitHub が返す CDN ホストへのリダイレクトです。また、補助情報の取得として formula JSON を参照することがあり、その経路でも formulae.brew.sh およびそれにぶら下がる GitHub CDN が混ざります。

ここで重要なのは「brew のコマンドが遅い＝単一ホストだけが悪い」と決めつけず、実際には並列キューが一部だけ極低速で全体が進まなく見える、という視点です。そのため、アプリ側のログでどのドメインへ接続が張られているかを一度見るほうが確実です。Clash 系では接続リストがそのまま教室になります。Clash Verge Rev の入門 でダッシュボードの見方やポート確認を済ませておくと、以降の検証が速くなります。

症状の見わけ：brew が固まっているのか、だけ遅いのか

体感が似ていても、原因は複数です。タイムスタンプより前に Control-C を押していると中身まで見えないので、試験環境としてはひとつの式を指定してログを増やします。開発向け機能に触れるときは自分の権限だけで済ませ、社内規程がある場合は手順書に沿ってください。

運用ヒント：HOMEBREW_NO_AUTO_UPDATE=1 を試しつつ必要最小のサブコマンドで再現させると、更新フェーズか取得フェーズかを分解しやすくなります。恒常運用での無効化は更新忘れにつながる場合があるため、その点だけは頭の隅に置いてください。

並列処理のゆらぎにも注意します。体感が時間帯で変わるなら、その時間帯の DNS ログとセットで確認すると、BGP 側の問題とルール側の問題をある程度は切り離せます。

なぜ「プロキシを入れた」のに効かないのか（ルール優先）

Clash でよく見る構図として、画面上は「オン」にもかかわらず、YAML の RULE セクションの並び順で上流に DIRECT が並び、結果として GitHub 系だけ素通しになっているというものがあります。また、広い定義である GEOIP より前に細かく当てないと、その国向け規則に吸われることもあります。

さらに、プロファイルを複数所持しているときに「いま動いているのはどれか」がズレると、体感は「ときどきだけ直る」になります。Clash Verge Rev では複数構成の切り替えが視覚的に分かりやすいので、ターミナルとブラウザの試験ごとに同じプロファイルへ揃えるのが重要です。rule-providers の更新まわりを触っているときは、その同期タイミングで古いセットが復活しないかもチェックしましょう。

YAML に足すときのひな形（自分のノード名に置換）

以下は説明用途の一例です。REPLACE_WITH_YOUR_SELECTOR を、実際に使いたいグループ／ポリシー名へ置き換えてください。また、自分のセットに競合しない位置へ挿入します（上流に広い規則があると効きません）。

rules:
  - DOMAIN-SUFFIX,github.com,REPLACE_WITH_YOUR_SELECTOR
  - DOMAIN-SUFFIX,githubusercontent.com,REPLACE_WITH_YOUR_SELECTOR
  - DOMAIN-KEYWORD,github,REPLACE_WITH_YOUR_SELECTOR
  - DOMAIN-SUFFIX,ghcr.io,REPLACE_WITH_YOUR_SELECTOR
  - DOMAIN-SUFFIX,brew.sh,REPLACE_WITH_YOUR_SELECTOR
留意：GitHub が返す具体的な CDN ホストは式やレイヤーにより変わります。広すぎる DOMAIN-KEYWORD は意図せぬサイトまで同じ経路へ流れるため、必要最小限へ絞れるならDOMAIN-SUFFIX や DOMAIN 単位での整理を優先してください。

実務ではログに出ているFQDN をその場でルールへ足すアプローチが堅実です。このとき名前解決が fake-ip 側で想定どおりになっているか、DNS クエリだけが迂回していないかも同時に見ます。

TUN が効くタイミングと注意点（macOS 2026 前提）

環境変数で 親シェルの curl は通っても、その起動チェーンにある子プロセスが別設定で動く事例はあります。TUN はレイヤーを上げるほど広く捕まえる代わりに、管理者権限やローカルの VPN／セキュリティ製品との相性問題が増えやすくなります。まずは通常のポートプロキシで十分なときが多く、効かないときの追加手段として順序立てるのが運用でも安全です。TUN に関する専門の整理と照らして、DNS とスタック周りだけは先に読んでから有効化するのがおすすめです。

大学や企業 LAN では、システム拡張の承認より前にインフラ側でフィルタが入ることがあり、その場合ローカルの Clash だけでは無理があることも説明できると冷静に切り分けられます。そのときは許可済みプロキシの窓を使う、など別レイヤーを検討してください。

Terminal 側：HTTPS_PROXY など環境変数で brew と揃える

brew は裏側の取得に curl を広く利用します。そのためブラウザと同じ経路へ寄せるなら、HTTPS_PROXY／http_proxy の両方を揃えるのが定石です。macOS ターミナル環境変数の記事にある export 例へ混在ポート番号だけ合わせ込み、そのまま brew でも試します。

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

混在ポートを一本化しているならポート番号を合わせ、SOCKS と HTTP で混線していないかは必ず自分の構成で確認してください。NO_PROXY に社内またはローカルを入れ過ぎると、そのサフィックスまで直結になり逆にタイムアウトするので、チームでのレビューを推奨します。

ログで「本当に GitHub で止まっているか」を確かめる

Clash で接続一覧を見ながら、同じウィンドウで brew install を再試行すると、イベントの対応関係が掴みやすいです。ログに載らないときは、この時点ですでに名前解決の手前や OS のパケットフィルタに落ちている疑いがあります。逆に接続イベントは進むが速度が異常という場合は、そのノードの帯域・輻輳・ICMP とは別の問題の可能性があります。

GitHub と Microsoft サービスが同時に問題を起こすケースは別途整理されることが多く、モデル関連は GitHub Copilot 向け分流の記事の切り口と組み合わせる読みもできます。

見落ちがちな落とし穴

DNS だけが別経路

パケットは経由しているように見えるのに解決だけ失敗することがあります。fake-ip と実アドレスの差、上流 DNS のポリシー、社内キャプティブへの誘導などをセットで確認します。

複数構成のどれかが古い

GUI で表示されているプロファイル名と実際に注入されている YAML が一致しないと、恒久対応が頭打ちになります。

HTTPS の brew／git と SSH が混線

git のトランスポート種別によりプロキシの当たり方が変わります。HTTPS_PROXY を整えつつ SSH を併用するなら、その前提を分けます。

環境だけの鏡変更に頼り切る

地域により公式が推すミラーと利用規約の整合が異なります。ここでは代替ではなく経路確認の順序だけを伝えています。

よくある質問

ブラウザは早いのに brew だけ遅いのはなぜ？ ブラウザはプロキシ拡張やシステム設定を読み込みやすく、Terminal からの brew は curl／git 側の環境変数や TUN でプロキシ外に残りやすいからです。

formulae.brew.sh はどう扱えばよい？ formula JSON やサイト参照でアクセスすることがあり、CDN 側の名前解決にも依存します。github.com と同様に、期待する経路になるよう DNS とルールの両方から確認してください。

TUN とプロキシ環境変数はどちらを優先すべき？ まず環境変数で再現できるか試し、抜けが残るなら TUN を追加するのが安全です。両方オンでも競合しないよう、fake-ip と除外リストを確認します。

まとめ

Homebrew が「止まったように見える」主因は、しばしば単一ログの読み間違いではなく並列キューの一部だけが GitHub Releases／関連 CDN で極端に遅いことにあります。まずブラウザと Terminal の経路が一致しているかを意識し、Clash でログに出たホスト単位でルールを足すのが最短です。そのうえで抜けが残るときに TUN を足し、親子プロセスの代理が揃うか確認します。広告色の強い単体 VPN だけに頼ると、開発者ツール側の粒度（ドメインベースのログ、YAML の柔軟さ、ポート別の細かな切り替えなど）が足りず、問題のときに原因が視界に現れません。一方で Clash はルールログと構成の両方から通信を読みやすく、brew のような複数フェーズ処理に向いた切り分けがしやすいのが強みです。無料で Clash を入手し、この記事どおりログを見ながら Homebrew を安定させましょう。