検索意図からみる三段階：registry → tarball → GitHub と Agent
「Copilot CLI インストール 遅い」「@github/copilot」「npm に copilot が出ない」「Agent タイムアウト」「GitHub API つながらない」という入力はすべて似た体感ながらレイヤが違うことがあります。第一段は registry.npmjs.org とスコープ解決であり、環境側で社内または地域mirror を指していたり、上流欠損のままだけターミナルが読んでいれば画面は中途半端です。続く第二段では tarball とパッケージ資産そのものが Fastly やクラウド配信側の名前へ飛び、ブラウザのキャッシュ済みコンテンツと負荷だけが異なる構成もあります。第三は CLI がログイン状態を維持しながら api.github.com と OAuth／デバイスフローを跨ぐあたりであり、広告ブロッカやゼロトラストだけ一部 URL が落ちていると「ログイン済み」のように見えて永遠に待つ症状になります。この三段を頭に並べれば、一覧に出ているのが npm 系なのか github 系なのかを切ってからルール増分へ進めるので、ログ起点の運用とも相性がよいです。
画面上の読み込みメッセージが進捗に乏しいとき、内部では TCP の再送か TLS ハンドシェイク失敗だけが時間を食べていることが多いです。その意味で単に環境変数を増やすより、一覧に名前が付く状態を先に確保することが重要です。MATCH の出口が直行に読み込まれていたり GEOIP と名前ルールが噛み合っていなくてログの色だけ妙なときは並び順の見直しを忘れず、スニファでドメイン補強するかどうかはテンプレの方針に従ってください。WSL2 と Windows で境界が二重にある場合はゲスト側のプロキシとホスト側 TUN が交互に読みにくくなるので、まず検証コンソールの所在をひとつに寄せます。典型手順へはWSL2 × Git と npm の別稿も参照すると短絡になります。
ブラウザは速いがターミナルの npm と Agent だけ不安定になりやすい理由
多くの OS ではブラウザはシステムプロキシに従う一方で、Node のランタイムはプロキシ解釈と証明書ストア評価が別系統だったり、アップデート順で環境だけが読めない状態が混入します。また企業端末では「ブラウザは許可、CLI は除外」のゼロトラスト構成もまれに見られ、この非対称は HTTPS だけ暗黙につくためデバッグが難航します。Clash のTUN は下位レイヤで送出を拘束するので、npm／Agent／git のどちらを叩いても一覧に同じ名前が載りやすいという意味で強い処方になります。「プロキシを二重にはさむと逆にログが増えて読めなくなる」のは共通の運用論なので、上から積むのではなく TUN で全体をひとつの出口に載せ、そのうえで不足ホストのみルール増分という順が読みやすいです。Gemini CLI と同種の問題意識は 当サイトの Gemini 向け記事 でも共通しており、差は主としてターゲット FQDN です。
名前の前にある事故として DNS も強い論点になります。fake-ip と名前評価の順序や、ウィルス対策によるローカルのフック、別製品の DoH と Mihomo が同時オンになっている状態は、画面上は抽象的なENOTFOUNDや長いタイムアウトのままでも一覧側には IP だけの行が増えるなどの痕跡が残ります。ここだけ切って家のネットワークで再現させるより早いときもあります。また企業環境での透明 HTTPS 検査は証明書の置換とセットでブラウザは信頼ストア済みでも Node は落ちる、という二分が起きがちです。CLI 開発者側で NODE_EXTRA_CA_CERTS を増やすべきではない規程がある場合、そのまま証明書差し替えとは折り合いがつかないのでインフラ相談に回すしかありません。その前提を理解したうえでネットワークの一致は先に済ませるのが得策です。
最初のひと叩き：RULE で TUN を確実にオンにする
具体的なクリック順は製品によりますがポリシーは共通です。RULE（ルール）読み込みでエラーなく起動できることを確認したうえで TUN をオンにし、macOS であれば拡張と権限ダイアログ、Windows であればヘルパーとサービス整合を両面で済ませてください。その後に問題のnpmコマンド（例：npm install -g @github/copilot の再現）だけをひとつに絞って打ち返すと一覧に増えるドメインの幅が読みやすくなります。フル機能の競合VPN と同居していると一覧が多重に見え理由が読めなくなるので検証だけでも切り離す価値があります。Mixed Port と SOCKS のポート番号の取り間違いはシステムプロキシ表示が似ていると紛れるので、「文字列」のコピーではなく構成画面の整数だけをソースにしましょう。GUI で「オン」にもかかわらず OS がブロック一覧に残っているケースがあるため、状態表示は複数ソースで突きあわせるのが安全です。
運用ヒント：いきなり HTTPS_PROXY と TUN とシステムプロキシ三者を強く同時に入れないでください。TUN を先、ダメ押しのみ環境変数を足す順がログを読むうえでも安全側です。NO_PROXY からlocalhost と内網だけを適切に抜いたうえになっているかだけは毎回見ます。
分流はログ優先：npm 周りと GitHub と配信ホスト
固定リストに頼るほどCDNの切り替わりで陳腐化するので、「失敗ログに名前が並んだときだけ増やす」が持続します。よく増える名前には registry.npmjs.org と npmjs.org が含まれ、続いて tarball 実体側のCDN名。GitHub では github.com／api.github.com が核ですが Releases ワークフローならオブジェクト保管向け名前も独立して増えます。@github/copilot のような公式公開パッケージでも内部依存で短い共通サフィックス以外の名前が混ざることがあるので、ログに載った最短共通の DOMAIN-SUFFIX だけで十分なケースがあります。RULE-FINAL や MATCH が意図せず直行に落ちないか色と一覧の並びだけで読むと早期にひっかかります。共通テンプレを見返すなら GEOIP・geosite 総覧記事 を併読すると頭の俯瞰が楽です。
# Sketch: observe logs first, paste only what fails
rules:
- DOMAIN-SUFFIX,npmjs.org,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,github.com,YOUR_PROXY_GROUP
# Add CDN names that appear during tarball pulls
GEOIP だけ運用していた読者でも、CDN が地理と実体感を食い違わせやすく CLI 問題では名前と併記が現実解です。またレート制限により出口ノード側で詰められているときはノード並びやリトライ過多という別次元にも目を向ける必要があります。ルール増加と引き換えに MATCH 評価位置が後ろに押しやられていないか定期的に一覧で確認しましょう。HTTP/3 と QUIC が絡んでいるときは許可セットが別になっている構成もまれにあるため、アプリ側のトグルと Clash の受け側を揃える必要があります。
DNS と Fake-IP：TUN の内外で評価を同期させる
アプリ側の dig 出力と一覧の名前がずれるときは、OS の順序／Mihomo の dns セクション／tun stack の三者を一枚の頭の中の図にします。名前の権威だけは正しいつもりでも評価の当事者が違って Fake-IP の返答と実送信の組が食い違うと静かな失敗だけが増えます。詳細論点はDNS リーク対策ガイドに譲りますが、チェックリスト上は「名前解決の当事者」と「評価の当事者」を一致させられるかだけを先に済ませるのが近道です。また Windows の一部ウィルス対策は名前をフックするため一覧に正しい名前が付いても下流だけ遮られることがあり、この場合ログの読み書きとは別問題です。開発者コンソールの TLS ログと並べられるなら単純な証明書エラーだけ切れることもあります。
npm：registry・strict-ssl・@github スコープの実値チェック
まず npm config get registry と npm config list -l だけでも「いまのシェルの実ソース」になります。@scope:registry が社内だけに向いていたり証明書周りが暗黙の strict-ssl=false になっていると、一覧に正しい名前が出ても下流処理がぶれることがあります。 tarball のリダイレクトチェーンだけ極端に遅く見えるときはリストの並び順にホスト粒度のギャップが残るので一覧を眺めるだけでも推測の幅が増えます。CI で --fetch-timeout を延ばしている例より前に経路を正すほうが再試行ログが単純化します。pnpm／yarn を混在させているワークスペースではロックファイル側のインデックス URL が二重になりやすく、名前とインデックスの両方だけに視野を狭めると運用コストが下がります。
# Minimal probes before escalating
npm config get registry
npm ping
npm view @github/copilot version --json
Copilot が GitHub と同期するワークフローでは GH_TOKEN などの名前もドキュメントに登場しますが、トークンの正しさ以前に名前解決または TLS が落ちないかを一覧で押さえれば切り分けが速くなります。Git LFS と大型バイナリを引くスクリプトが混じるワークスペースでは別のCDN名だけが増えることもあり、そこだけ独立して増分したほうが全体のMATCHを肥大化させなくて済む場合があります。tunnelling を社内許可しない規程がある場合、この節だけ代替策をインフラ窓口に求めるしかありません。
ログイン後の GitHub API と Copilot Agent：三本柱での観察
依存取得成功の直後にだけ止む場合、経路側と認可側を分けてログを読みます。api.github.com の名前が増えなくて証明書警告だけ増えるときは検査プロキシの影響、名前は増えるがレイテンシだけが増えるときは出口ノードの混雑またはレート、この二つのどちらに寄っているかだけでも次の試行コストが変わります。またブラウザで OAuth が途中まで進むワークフローでは広告ブロッカとゼロトラストだけ一部 URL が落ち続け、CLI 側だけ待ち状態に見える構成もまれに見られます。GitHub と連携しないローカルのみのモデル開発なら名前空間自体が異なるので比較の対象を誤らないようにします。並行開発で他社 CLI（例：Claude Code CLI）と混ぜないうえでも、共通するのは「ブラウザとターミナルの経路非対称を TUN で潰してから増分」の一点です。
再現ワークフロー：迷わない並び順
- RULE でプロフィール読み込みとダッシュボードの異常無し。
- Copilot CLI側は再現したい単一コマンドだけを決める（例：グローバル導線の
npm install -g @github/copilotと初回ログイン）。 - TUN オン〜権限チェック済み〜同じシェルから再試行〜一覧増分を読む。
- ログにだけ現れた名前を
DOMAIN-SUFFIX相当で増やし、MATCH 手前評価に残っているか一覧で確認。 - DNS（fake-ip、DoH競合、eBPF/stack）だけ独立して点検。
- npm の registry／
@githubスコープ／.npmrc／環境変数の実値をこのシェルだけで読む。 - 必要最小限だけ
HTTPS_PROXY系へ拡張し、二重トンネルを避ける。
注意：TUN とプロフィール変更が契約または学校規程・社内運用規程と衝突する場合があります。許可されていないときはインフラ窓口の案内のみに従ってください。
よくある質問
ウェブでも npm と GitHub が開けるのに Copilot の npm が止まります。
同上のブラウザと Node の経路／証明書ストア評価差です。TUNでまず名前付き一覧を読める状態へ寄せれば切り分けが早くなります。
ルールを足しても tarball だけ落ち続けます。
CDN のリダイレクトだけ一覧に載っていない／企業証明書でnpmのTLSが不一致、のどちらかを疑って同一セッションで分流とnpm configを見直してください。
ログイン済みにもかかわらず Agent が返りません。
GitHub API と OAuth に絡むURLだけブラウザ分離側でブロックされていないか、レート側でしばられていないかを一覧とHTTP側の状態で分離して観察します。@github/copilot と連動するワークスペース設定も別次元で確認します。
まとめ
GitHub Copilot CLIと@github/copilot、そこから伸びるCopilot Agent利用は検索クエリとも相性が良い題材ですが、詰まりの原因はモデル側以前のregistry・tarball・GitHub APIの縦長連鎖に偏りやすく、ブラウザとの経路非対称とタイムアウトに見えるだけになりがちです。ClashのTUNでターミナル側を拘束し分流ルールへログ起点で反映しDNSとnpmの実値だけを並べれば、体感のほとんどはここで滑らかになります。OpenAI Codex CLIやGemini CLIとも手順は同型で名前空間だけ差し替えれば済むので、クロスプラットフォーム開発の読者にも応用できます。構成画面と一覧ログで詰まりを追う運用への移行をまだの方には、一覧とルール評価を揃えるGUIクライアントが早いので、試すなら 無料で Clash をダウンロード のうえこの記事のワークフローどおり進めてみてください。一方で競合のみの一覧や手書きYAMLだけでの長期運用は疲弊しやすく、ログ付き製品側に寄せるほど再現性も上がります。