1. 症状と 2026 年の文脈
「拡張は最新なのに、Copilot Chat だけ再接続を繰り返す」「github.com へのサインインは通るのに、インライン補完が出ない」「GitHub Models を叩くスクリプトだけタイムアウトする」——こうした非対称な不具合は、単一の設定ミスよりホストの取りこぼしに起因することが多いです。VS Code は本体更新、マーケットプレイス、設定同期、そして GitHub Copilot の各バックエンドへ並行に TLS を張ります。どれか一条が DIRECT のまま不安定な直回線へ落ちると、画面では「また落ちた」としか見えません。
2026 年も GitHub Changelog の Copilot ラベルは高頻度で更新されています。例として同年 5 月 6 日付の「GitHub Copilot in Visual Studio Code, April releases」は、VS Code 向けCopilot のリリースノート系エントリで、機能追加と同時に接続対象の複雑さが増していく流れを読み取る材料になります。記事本文の趣旨は「新機能の網羅」ではなく、その変化に合わせてルールとログを育てることです。
利用規約違反やログイン回避を促す内容ではありません。GitHub や Copilot の契約範囲で、自前の出口と DNS を整える話に限定します。
2. 切断が起きるレイヤー
切り分けの順番は次の四層が扱いやすいです。
- 名前解決：意図しない DNS 経路で遅延・失敗
- ルール評価：対象ホストが
PROXYに乗らずDIRECT - 出口ノード：プロキシ先の輻輳・ブロック・途中切断
- アプリ設定：VS Code が OS プロキシや証明書ストアと噛み合っていない
四つが同時に絡むため、「ルールは正しいはず」でも症状が残るのは日常茶飯事です。Clash（Mihomo 系）の接続ログに出る Server Name をメモし、その時点の策略（ポリシー）と突き合わせてください。
3. VS Code Copilot のアップデートと接続
GitHub Copilot 拡張は、認可・モデル一覧・チャット・Agent 実行のために、ブラウザで見えている github.com 以外のホストへ継続的にアクセスします。モデルピッカーや BYOK（別プロバイダのキー）を有効にすると、さらに第三者の推論エンドポイントが増えます。いずれも「GitHub のルールだけ足した」ときに取りこぼしやすいので、失敗した瞬間のログからホストを拾う運用が現実的です。
VS Code 本体や他拡張の更新は、update.code.visualstudio.com や *.vscode-cdn.net 系へ飛ぶことがあります。Copilot 本体の不安定さと混同しないよう、症状再現の手順（例：チャットだけ／同期だけ）を固定し、ログのホストを切り分けてください。
4. 押さえるホスト集合
以下は出発点用のチェックリストです。運用・リージョン・プランで変わるため、必ず手元のログで検証してください。
- GitHub ウェブ／API／Git：
github.com、api.github.com、raw.githubusercontent.com、objects.githubusercontent.comなど - パッケージやコンテナ：利用時のみ
ghcr.io、npm.pkg.github.com等 - GitHub Models（推論 API）：ドキュメント上は
models.github.aiが中心（GitHub Models API） - Copilot 系：ログに
githubcopilot.comやcopilotを含むサブドメインが出ることが多い。総称で copilot-proxy と呼ばれる経路も、実名はログが正です
ひとつでも広い GEOIP,CN,DIRECT などに先に飲まれると、「ブラウザの github.com だけ快適・補完だけ死ぬ」が起きます。rules: の評価順序もあわせて確認してください。
社内プロキシや TLS 検査
企業 LAN で HTTPS インスペクションが有効だと、クライアント証明書や SNI の扱いで途中切断が増えます。Clash の外側の問題かを切り分けてからルールを厚くしてください。
5. Clash 分流ルールの実装
Clash では DOMAIN-SUFFIX を基本に、GitHub 資産と推論 API を同じ 策略グループへ載せます。Mihomo 系なら RULE-SET を併用してもよいですが、取りこぼし時は手元の短い追記が早いです。
# Example only — verify every hostname in your client logs (SNI)
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,githubusercontent.com,PROXY
- DOMAIN-SUFFIX,githubcopilot.com,PROXY
- DOMAIN-SUFFIX,github.ai,PROXY
- DOMAIN-SUFFIX,models.github.ai,PROXY
- DOMAIN-SUFFIX,ghcr.io,PROXY
- MATCH,DIRECTDOMAIN-KEYWORD,copilot は便利そうに見えますが、無関係なホストへ誤爆しやすいです。可能ならサフィックスとログ上の実名を優先してください。設定全体の構造は Clash のドキュメントと併読すると安全です。
6. Agents と長時間接続
Agents やクラウド連携は、短い REST だけでなくストリーミングや長めのセッションを維持します。輻輳した出口では途中でソケットが切れ、UI では「再接続」を繰り返します。策としては、(1) 同一ホスト集合をまず同一ノードへ固定、(2) それでも足りない場合のみ、ホスト単位で別策略に分離、の順が扱いやすいです。最初から細かく分けると、認証クッキーやエフェメラルなトークンが別経路に散って再ログイン地獄になりがちです。
リモートの MCP だけを別ノードへ分けたい場合は、汎用ルールよりホスト単位の優先ルールが必要です。当サイトでは MCP 向け分流を別稿で扱っています。本稿は GitHub Copilot in VS Code と GitHub Models API を主役に置きます。
7. ノード選び
レイテンシの数字だけで選ぶと失敗しやすい領域です。大きな差分の git push、長文チャット、モデル切り替えは、帯域・安定性・レート制限の影響が出ます。
| 症状 | 疑う順 | 先に試すこと |
|---|---|---|
| 補完だけ途切れる | Copilot 系ホストの DIRECT 残り | ログの SNI をサフィックスに追加 |
| Models API だけ失敗 | models.github.ai の取りこぼし |
単独ルールで PROXY へ |
| 夕方だけ悪化 | 混雑・帯域・ISP | 時間帯変更、手動ノード固定 |
| TLS／証明書エラー | 検査・社内プロキシ | セキュリティ製品設定の確認 |
url-test や自動フェイルオーバーは便利ですが、閾値によっては切り替わり過ぎで余計に切断します。まず手動で安定した出口を決め、改善を確認してから自動化を検討してください。
8. DNS／Fake-IP
Fake-IP モードでは、名前解決のタイミングとルール評価の関係が複雑です。dns がプロキシの外で権威へ直行していると、ログ上は PROXY でも実パケットの出口がバラけます。redir-host 派でも、キャッシュや競合 resolver で似た現象が出ます。
github.com は速いのに推論だけ遅いとき、実際は別ホストの DNS が直結しているケースが多いです。クライアントの DNS ログと、ルールヒット結果をセットで見てください。IPv6 が別経路に逃げている場合は、切り分けのために一時的に IPv4 優先へ寄せる手もあります。
詳しい基礎は Fake-IP／DNS の切り分けも参照してください。
10. セルフチェック
- 拡張と VS Code を最新系に：リリースノートで接続要件が変わったかをざっと確認（例：2026-05-06 の VS Code 向けまとめ）。
- Clash を最新系に：GUI とコアのズレを解消（ダウンロードページ）。
- ログの Server Name を列挙：
github.com以外に出た名前をすべてメモ。 rules:の順序：広いGEOIPやMATCHが先に当たっていないか。- 手動ノードで再現性：自動切替を止め、一本の出口で試す。
- DNS を揃える：Fake-IP／追跡モードと矛盾がないか。
それでも直らない場合は、ISP 側の輻輳・地域要因・組織ポリシーを疑い、公式ステータスやフォーラムの報告と突き合わせます。
11. よくある質問
copilot-proxy とログのホストが一致しません
正常です。呼び方はコミュニティ由来で、真実はいつもクライアントログの SNI です。一致しないことを気にせず、その名前をルールへ足してください。
GitHub Models だけ遅いのはなぜですか
models.github.ai など推論系が DIRECT に落ちている・別 DNS 経路になっていることが多いです。ログで策略を確認し、必要なら単独行を上に置きます。
Agents を使うとすぐ切断します
長めのストリームを途中で落とす出口は、短い ping では露見しません。別ノードへ切り替え、TLS エラーが増えていないかも合わせて見ます。
12. まとめ
GitHub Copilot in VS Code は 2026 年も機能追加とともに接続先が増えやすい製品です。GitHub Changelogで流れを追いつつ、手元では Clash ログの実名で 分流ルールを育てるのがもっとも再現性が高いです。github.com 系に GitHub Models API、Copilot 系を同じ安定出口へ揃え、DNS と矛盾がないかまで見ると、「アップデートのたびに壊れる」感覚は大きく減らせます。
汎用 VPN アプリや単一トンネルではルール粒度が粗く、開発者が毎日触るホスト単位の切り分けに不向きなこともあります。GUI なしで syslog だけ…という構成も大変です。Clash 系は接続とルールの対応を追いやすく、ログを見ながらホストを足していく運用に向きます。github.com と copilot-proxy 実名・models.github.ai を揃えたうえで、Clash を無料ダウンロードし、開発環境の経路を試すのが近道です。