この記事で分かること

2026 年現在、エディタ統合の Copilot に加えて、ターミナル Agentとして動く GitHub Copilot CLI（検索語としては Copilot CLI と並びやすい）を CI やローカルシェルから呼ぶ開発フローが増えています。現場では「ブラウザや IDE のGitHub連携は動くのに、CLI だけが長時間待ってから切れる」「Microsoft ログインやデバイスコードまわりが不安定」「GitHub API への最初のハンドシェイクでハングする」といった報告が増え、検索クエリにも「タイムアウト」「DNS」「HTTPS_PROXY」がセットで現れやすくなっています。

本稿はデスクトップ向け Mihomo／Clash Meta 系 GUI のひとつである Clash Verge Rev を前提に、(1) 分流ルール（Rule）で GitHub と Microsoft／Azure 周辺ドメインを意図したノードへ送る、(2) シェルや子プロセスへ HTTPS_PROXY／HTTP_PROXY／NO_PROXY をどう渡すか、(3) fake-ip や Split DNS と組み合わさったときの切り分け——を一続きで整理します。ホワイトリストはサービス側のアップデートで変わりうるため、Verge Rev のログと curl による実測を最優先してください。ほかの AI CLI とプロキシの組み合わせはCodex CLI 向け記事やClaude Code 向け記事とも補い合えます。Clash Verge Rev チュートリアルで触れたポリシー名やログタブの見方もそのまま再利用できます。

検索意図と症状の対応表

Copilot CLI は認証後も短期間に複数ホストへ HTTPS を張り直すため、経路がわずかにズレるだけでユーザー体感では「総タイムアウト」に見えやすいです。検索語と現場症状を対応させると切り分けが早くなります。

  • ログイン完了までが極端に遅い／途中で切断：Microsoft ログインやデバイス認証まわりが DIRECT のまま残り、国境付近で TLS が詰まっている、あるいは企業プロキシが CONNECT を製限しているケース。
  • コード補助よりもメタデータ取得で詰まる：GitHub API（api.github.com など）へのレートやモデル情報取得が別経路になり、ブラウザの REST と結果が食い違うケース。
  • DNS は返るが接続だけがタイムアウト：Split DNS がブラウザだけ別キャッシュを見ている、IPv6 と IPv4 が分裂している、など名前解決と実経路の不一致。
  • 成功と失敗が交互に出る（フラッピング）：複数ターミナルが別々の RC ファイルを読んでおり HTTPS_PROXY が片方だけ空、別ランタイムが環境変数を無視している——など状態の二重化。

いずれも「ネットワーク全体が完全に不通」よりも、HTTPS クライアントが期待したプロキシチェーンに乗っていない比率が高く、Clash Verge Rev のログで一行ずつ追えることは説明責任のある運用では大きな利点になります。

ブラウザとターミナルで経路が割れる理由

同じマシンでも、Electron ベースの UI と Copilot CLI が内部で起こすプロセスでは、参照するプロキシ設定が一致しないことがあります。GUI は OS のシステムプロキシやブランド固有のチャネルを先に見る一方、CLI の HTTP スタックは HTTPS_PROXY と NO_PROXY に強く依存します。

このズレは「CLI だけがETIMEDOUTになる」「ブラウザで確認した PAT と別物に見える」などの報告として現れやすいです。まず Shell で env | grep -i proxy を確認し、続けて Verge Rev のログと突き合わせれば、原因が分流不足か環境変数欠落かを早く二分できます。

分流ルールで押さえるべきレイヤー

分流ルールは、社内 Git や決済ドメインを DIRECT に残しつつ、外向きの GitHub API と Microsoft の認証ホストだけを意図したアウトバウンドへ送る第一選択です。YAML の順序とログを突き合わせれば、「どのホストがどのポリシーへ落ちたか」をテキストで説明できます。

  • ホスト単位で載せる：広すぎる DOMAIN-KEYWORD は誤爆しやすいので、ログに出た実名を DOMAIN で足す運用が安全です。
  • MATCH より上へ置く：後勝ちになっていると CLI の短命コネクションだけ別ポリシーへ滑りやすくなります。
  • 社内向け例外は明示：SSO や社内パッケージレジストリは NO_PROXY と Rule の両面で除外するとループや二重プロキシを避けられます。

TUN は環境変数を無視するバイナリでも一度 Mihomo 側へ引き込める強力な手段ですが、ゼロトラスト VPN や別製品の仮想 NIC と競合しやすいです。実務的には、(1) Rule とシステムプロキシで足りるか試す、(2) 特定バイナリだけ問題なら限定的に TUN、(3) 常時フル TUN は最後の手段、の順が安全です。

HTTPS_PROXY を軸にしたターミナル向け環境変数

Copilot CLI を cron、direnv、CI、ローカルシェルから叩く場合、GUI よりも環境変数の比重が大きくなります。典型的には次を揃えます。

  • HTTPS_PROXY：HTTPS への CONNECT が主用途なら最優先。
  • HTTP_PROXY：リダイレクト先行の HTTP フェーズで参照されます。
  • ALL_PROXY：単一変数しか読まないツールへの保険（無視されることもあります）。
  • NO_PROXY：localhost、127.0.0.1、社内 SSO を除外し、ローカルのデバイスコード待受とのループを防ぎます。

値は多くの場合 http://127.0.0.1:<mixed-port> で足り、TLS は CONNECT でトンネルします。書き場所の例は ~/.zshrc、~/.bashrc、リポジトリの .envrc、あるいは検証時のみのコマンド前置き HTTPS_PROXY=... copilot … です（ポートは各自のプロファイルに合わせて読み替え）。統合ターミナルが「ログインシェルではない」構成だと変数が読み込まれないこともあるため、実際に CLI を動かしたプロセスへ変数が渡っているかを疑うのがポイントです。

ルールへ載せるホストはログ実測を優先

固定リストは保守コストが高く、サービス側変更で簡単に陳腐化します。検索で繰り返し見かける型としては次を出発点にし、実名はログで上書きしてください。

  • GitHub 本体と REST：github.com、api.github.com、ごくまれに関連 CDN／アセット。
  • Microsoft 認証とポータル周辺：login.microsoftonline.com、場合により Entra／Azure Portal に関連するホスト。
  • モデル／テレメトリなど追加ホスト：製品アップデートで増えることがあり、エラー直後の一行ログから拾うのが最短です。

GitHub Copilot CLI のエラーメッセージに出るホスト名は、事前まとめリストよりログ列挙のほうが信頼できます。Copilot CLI と別ルートの AI CLI を併用する場合は、それぞれのガイドとルールセットの整合も見てください。

TIP：一度だけGlobal に近いプリセットで CLI を走らせ、症状が消えるかを見てください。消えるなら DIRECT 落ちのルール順が本命で、MATCH より上へ個別 DOMAIN を挿入しやすいです。

ルール記述例（ポリシー名は各プロファイルに合わせる）

以下は Mihomo／Clash Meta 互換の説明用スニペットです。PROXY を利用中のポリシーグループ名へ置換し、既存の MATCH より上に置いてください。

# Example rules snippet — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,microsoftonline.com,PROXY
  # Append hosts observed in Verge Rev logs above MATCH

社内規程により Microsoft／Azure の広い suffix を一律 PROXY にできない場合は、ログで実名が確定したホストのみを載せる運用に留めてください。

ステップ：Copilot CLI を安定させるまで

  1. Clash Verge Rev が期待するプロファイルで起動済みであり、mihomo が待ち受けていることを確認します。
  2. ブラウザで同じノードを用いた海外サイト疎通を見て、問題がCLI 限定かを切り分けます。
  3. 失敗再現直後のログからホスト名を拾い、分流ルールを追加します。fake-ip とルール種別の組み合わせでマッチがズレていないかも見ます。
  4. システムプロキシだけでは足りない場合、新しいターミナルで HTTPS_PROXY と HTTP_PROXY を export してから Copilot CLI を起動します。
  5. GitHub API と Microsoft ログインで使われた URL へ curl -vI を送り、Clash 側で意図したチェーンに乗ったかを確認します。
  6. 個別バイナリが依然として直結する場合は TUN を試す前に、HTTPS インスペクションや別 VPN のスタック競合を疑います。

検証のコツ：DNS と IPv6 を忘れない

「設定した HTTPS_PROXY」が統合ターミナルに届かないときは、非ログインシェル、タスクランナーのサンドボックス、コンテナのネット命名空間などを疑います。

  • 同一ホストで curl と CLI が別結果：curl は変数が効いており CLI が無視しているなら、そのランタイム版のドキュメントで代理関連の環境名やフラグを確認します。
  • IPv6 と IPv4 の分裂：curl -4 でのみ通るときは DNS か経路が二系統化しています。
  • 社内 Split DNS：機密系は NO_PROXY に残し、外部 GitHub API だけ PROXY —— の二段にすると開発者端末での事故が減ります。
注意：コードやログをクラウド側へ送る操作は、利用規約と会社の情報セキュリティポリシーに触れることがあります。ネットワークが安定しても、アップロード可否は別判断です。
ダウンロードページへ

トラブルシューティング

症状：curl は成功するが Copilot CLI だけタイムアウト

想定原因：ランタイムが環境変数を読まず、別設定ファイルやラッパーで直結している。

対処：公式ドキュメントのプロキシ項目を確認し、起動スクリプトで明示的に export。複数バージョンのパス競合も疑います。

症状：PROXY に乗っているのに極端に遅い

想定原因：ノード輻輳、HTTP/3 フォールバック、DNS の迂回失敗。

対処：地域の違うアウトバウンドへ切替、DNS をプロファイル内で固定、検査プロキシを一時的に外して差分確認。

症状：Microsoft ログインだけ途中でループする

想定原因：認証ホストの一部だけ DIRECT に残っておりリダイレクト鎖が途切れている。

対処：ブラウザではなく CLI／デバイスコード経路で現れたホスト名をログから拾い、ルールへ順番どおり追加します。

よくある質問

ブラウザではログインできるのに CLI がダメなのはなぜですか？

UI 層と CLI 層で参照するプロキシ設定が異なるためです。Clash Verge Rev のログで DIRECT 漏れを潰し、Shell に HTTPS_PROXY を揃えてください。

GitHub API と Microsoft 認証は同じルールで十分ですか？

外向きドメインはログの実名を載せ、ローカル待受は除外する二段構成が安全です。固定リスト任せにしないでください。

HTTPS_PROXY はどこに書けばよいですか？

常時なら Shell 設定や direnv、単発検証ならコマンド前置きのみ。副作用を限定するのがポイントです。

単一製品 VPN との比較で見える Clash の利点

ワンタップ型の商用 VPN は初期導入が楽でも、ドメイン単位の細かな例外やログでの逆引きには向きにくいことがあります。開発者ワークステーションでは、社内 Git は直結したい一方で GitHub API だけ別経路で詰まる、といった摩擦が出やすいです。Clash 系は本文のとおり分流ルールとログでホスト粒度の調整ができるため、Copilot CLI と社内サービスを同じ端末上で両立させるほうが現実的になります。

GUI は好みで選べますが、Verge Rev はプロファイル編集とログ監視が近接しており、CLI 中心の検証とも相性がよいです。大手 VPN の「すべて同じ出口」に比べ、詰まった場所をドメイン単位でほどける点が長期的な運用リスクを下げやすく、エンタープライズネットワークでも説明しやすいのが強みです。

無料で Clash を入手し、Copilot CLI 向けの分流と検証を試す →