1 GitHub Copilot の通信が分岐する理由
VS Code や JetBrains 向けの Copilot 拡張は、ローカルでコードを読みながらクラウド側へ HTTPS で推論リクエストを送ります。一方でアカウント連携や課金状態の確認は GitHub 本体のドメインへ戻るため、「認証は通るのにインライン補完だけ失敗する」といった非対称な症状が出やすい領域です。2026 年時点でも AI プログラミング支援への需要は高く、社内プロキシや地域ルーティングの影響を受ける開発者は引き続き多いでしょう。
Clash 互換クライアント（Mihomo コアを載せた Clash Verge Rev など）では、ルールモードでホスト名ごとにアウトバウンドを切り替えられます。ポイントは、単一の PROXY に丸投げするのではなく、GitHub の一般利用（リポジトリ閲覧、Issue、パッケージ取得）と Copilot 専用エンドポイントを同じ品質の経路に乗せることです。厳密には企業版や GitHub Enterprise Cloud では追加ホストが増えるため、運用ドキュメントの許可リストを正とし、接続ログで漏れを埋める姿勢が安全です。
Cursor など別 IDE に特化した記事では取り上げきれない GitHub ドメイン集合をここで扱います。Electron 系エディタ全般のプロキシの扱いはCursor × Clash の記事、ベンダー横断の API プロキシの発想はChatGPT／OpenAI 向け記事と補い合う構成にしています。
2 Web／認証とモデル API のホストを切り分ける
GitHub 公式ドキュメントの Copilot 向けプロキシ／ファイアウォール設定には、認証・テレメトリ・推論 API が表形式で列挙されています。代表的には次のような層に分かれます。（ホスト名は更新されることがあるため、常に最新版を正としてください。）
- 認証・ユーザー情報：
github.com上のログインフロー、api.github.com（ユーザー情報や Copilot 内部 API パスを含む場合あり）。 - 推論・チャット系 API：
copilot-proxy.githubusercontent.com、origin-tracker.githubusercontent.com、*.githubcopilot.com（Chat 検証ではapi.githubcopilot.comの_pingが案内されることもあります）。 - コンテンツ配信：
*.githubusercontent.com、objects.githubusercontent.com、codeload.github.comなど、拡張の取得やアセット配信に絡むホスト。 - テレメトリ：
collector.github.com、copilot-telemetry.githubusercontent.comなど。ブロックすると一部機能に影響する場合があります。
開発者ネットワークの設計では、「ブラウザで github.com が開ける」ことと「IDE 拡張が上記 API に到達できる」ことは別検証になります。前者がシステムプロキシ経由、後者が Node ランタイムのプロキシ解決や TUN 全域キャプチャに依存するケースが混在するからです。
curl で https://copilot-proxy.githubusercontent.com/_ping への到達を確認する例が示されています。Chat まわりは https://api.githubcopilot.com/_ping が案内されることもあります。Clash のログで同じホストが意図したポリシーにマッチしているかをあわせて見てください。
3 Clash 分流：DOMAIN-SUFFIX とコピー用 YAML の骨格
実務では、信頼できる Rule Provider に GitHub 系を含めつつ、Copilot 向けに明示的なサフィックスを足して漏れを防ぐ二段構えが扱いやすいです。以下は 例示です。実際の proxy-groups 名や並び順は、既存の購読ルールと衝突しないよう調整してください。日本国内向けサイトを遠回りさせない GEOIP,JP,DIRECT などは、このブロックより上に置くか、誤マッチがないかログで確認します。
# Place ABOVE the final MATCH rule. Replace COPILOT_PROXY with your selector or policy name.
- DOMAIN-SUFFIX,github.com,COPILOT_PROXY
- DOMAIN-SUFFIX,githubusercontent.com,COPILOT_PROXY
- DOMAIN-SUFFIX,githubcopilot.com,COPILOT_PROXY
- DOMAIN-SUFFIX,githubassets.com,COPILOT_PROXY
- DOMAIN,api.github.com,COPILOT_PROXY
- DOMAIN-SUFFIX,github.dev,COPILOT_PROXY
DOMAIN-SUFFIX,githubusercontent.com は copilot-proxy.githubusercontent.com を含む多数のサブドメインをまとめてカバーします。逆に、社内ミラーだけ DIRECT にしたいホストがある場合は、より具体的な DOMAIN ルールを先に書いて優先させます。Mihomo／Clash Meta では Sniffer や GEOSITE ルールと組み合わせることも多いですが、Copilot のようにホストが増えやすいサービスは公式リスト＋ログ追記が保守しやすいです。
Rule Provider に任せる場合の注意
第三者のルールセットに「GitHub」が含まれていても、バージョンや地域タグによってはサブドメインが不足していることがあります。補完が特定環境だけ失敗するときは、Clash の接続ビューで実際の SNI を確認し、足りない DOMAIN-SUFFIX を追記してください。負荷試験用に load-balance グループを使う場合は、長めの HTTPS ストリームが途中で切れないノードを選ぶことが重要です。関連する YAML の考え方はload-balance の記事も参照できます。
4 エディタ拡張とプロキシ：システム・TUN・環境変数
GitHub のドキュメントでは、エディタ側のプロキシが未設定のとき HTTPS_PROXY／https_proxy／HTTP_PROXY／http_proxy を参照する優先順位が説明されています。Clash をローカルの mixed ポート（例: 127.0.0.1:7890）に立てている場合、OS のシステムプロキシを有効化する方法と、シェルに環境変数を書く方法が併用されます。
VS Code 系は Chromium のネットワークスタックを使うため、システムプロキシを効かせると拡張の HTTPS がまとめて安定しやすいです。一方、CLI や一部ツールは環境変数や TUN がないとすり抜けます。リポジトリの clone や LFS、コンテナ pull まで含めて一本化したい場合は、TUN モードのガイドで仮想 NIC レベルの捕捉を検討してください。
https:// で始まる形式は現時点でサポート対象外とされています。企業ゲートウェイの設定をそのまま流用すると失敗するので、Clash 側を HTTP プロキシとして公開する構成か、公式が案内する形式に合わせてください。
企業環境では TLS インスペクション（自社 CA による復号）があり、拡張が証明書エラーを出すことがあります。OS の信頼ストアに CA を入れるほか、Node 系では NODE_EXTRA_CA_CERTS の利用が文脈によっては有効です。Clash 自体はトラフィックを転送するだけなので、失敗メッセージが TLS かタイムアウトかを切り分けることが次の一手になります。
5 DNS と FakeIP：名前解決をルールと揃える
ルールが正しくても、IDE が見ている DNS 答えと Clash が想定する解決経路がずれると、断続的に DIRECT へ落ちたり、期待しない地域の CDN に刺さったりします。Meta カーネル向け DNS／FakeIP の実務で述べているように、DoH と fake-ip の組み合わせを整え、国内ドメインと海外 SaaS を混在させない運用が安定の鍵です。
Copilot を試すたびにノードを切り替える運用では、古いセッションが残ってエディタ側だけ再接続に失敗することがあります。その場合は拡張の再読み込み、エディタの再起動、あるいは GitHub への再ログインを順に試し、並行して Clash のログで該当ホストが新しいアウトバウンドに載っているか確認します。
6 トラブルシューティング
- ブラウザの GitHub は快適だが Copilot だけ動かない： 拡張が参照するホストがルールで
DIRECTになっていないか、DNS だけ別経路になっていないかを確認します。githubcopilot.comとgithubusercontent.comを重点的に見ます。 - ログインループやデバイス認証が終わらない：
github.comと OAuth 関連のサブパスがブロック／誤ルーティングされていないか、企業プロキシで Cookie が落ちていないかを疑います。 - ETIMEDOUT／ECONNRESET： ノード品質や長连接の切断が多いです。セレクタで別サーバへ切り替え、同じ時刻に Clash ログで RST の有無を見ます。
- CLI の
gitやghは成功するが IDE だけ失敗： システムプロキシと環境変数のどちらが効いているかがズレている典型です。TUN で統一するか、IDE 起動シェルにプロキシを明示します。 - 組織ポリシーで Copilot が無効： ネットワークではなく管理者設定の可能性があります。ローカルルールをいじる前に、GitHub 上の Copilot 利用権限を確認します。
7 まとめ
GitHub Copilot は、GitHub ドメインでの認証と、Copilot 専用 API への推論リクエストという二系統の HTTPS に依存します。Clash 分流では DOMAIN-SUFFIX で github.com・githubusercontent.com・githubcopilot.com をまとめて意図したアウトバウンドへ載せ、公式の許可リストと接続ログで不足ホストを埋めるのが再現性の高いやり方です。API プロキシという言葉で語られる OpenAI 系サービスと同型の発想ですが、対象ホスト集合が GitHub 固有である点が本稿の焦点です。
システムプロキシと TUN、環境変数のどれを主軸にするかは、チームの端末ポリシーと開発フロー次第です。いずれにせよ DNS をルールと一貫させ、TLS エラーとタイムアウトを切り分けると復旧が速くなります。単機能プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、AI コーディングの長めのセッションには向きやすい場面が多いです。
同じ VS Code 系エコシステムでも、Cursor のクラウドモデル経路とはドメインが異なります。用途別に記事を分けておくと、チーム内のドキュメントやオンボーディングがしやすくなります。
