2026 年、Clash で GitHub Models を分流する：
Inference API と OAuth／認証ドメインの設計

1 推論と認証でホストが分かれる理由

2026 年時点でも、ターミナルや CI、ローカルの SDK から GitHub Models を叩くユースケースは増え続けています。ドキュメントで案内されているチャット補完の例では、HTTPS で https://models.github.ai/inference/chat/completions へ POST し、組織向けには https://models.github.ai/orgs/{org}/inference/chat/completions が使われます。ここが本稿でいう Inference API の主戦場です。一方、細粒度の個人アクセストークン（Fine-grained PAT）や GitHub App が発行するトークンには models:read などのスコープが関わり、発行・失効・権限確認の文脈では従来どおり GitHub の REST が絡みます。

その結果、ネットワーク設計では「推論だけプロキシに乗せたい」「GitHub 本体は社内ポリシーで別経路」といった非対称が起きやすく、単一の MATCH ルールでは再現性のある挙動が得られません。Clash 互換（Mihomo コア）ではホスト名ベースの 分流ができるため、まず models.github.ai を明示し、続けて github.com 系を同じ品質のアウトバウンドへ載せる二段構えが扱いやすいです。これは「ブラウザでログインできるのに API だけ失敗する」系の切り分けにも直結します。

ベンダー横断でドメイン集合を整理したい場合は、OpenRouter 向けの DOMAIN 設計とも読み比べると、自前ルールの粒度を決めやすくなります。本稿の焦点は GitHub 固有の github.ai サフィックスです。

2 公式 Inference と GitHub 側ドメインの整理

GitHub Docs の Models inference に沿うと、推論のベースは models.github.ai です。カタログ参照など Models 周辺の REST も同系統で案内されるため、ルールでは DOMAIN-SUFFIX,github.ai をひとまず包括するのが簡潔です（将来サブドメインが増えた場合の保険にもなります）。

• 推論（Inference API）： models.github.ai 上の /inference/... および組織向けパス。ストリーミング応答では接続が長時間続くため、不安定なノードを避けるのが実務上重要です。
• 認証・トークン・REST メタデータ： github.com（ブラウザでのログインや OAuth リダイレクト）、api.github.com（REST）、必要に応じて gist.github.com や *.githubusercontent.com（ドキュメントやアセット、サンプル取得）。
• 補助： テレメトリや Collector 系は組織ポリシーによって扱いが変わります。ブロックすると一部フローに影響する場合があるため、まずは到達性を優先し、後から絞るのが無難です。

既存の Copilot 向け記事では githubcopilot.com や copilot-proxy.githubusercontent.com が中心でした。GitHub Models は推論ホストが github.ai に寄っており、記事を分けておくとチーム内ドキュメントの重複を避けられます。

3 Clash 分流：DOMAIN-SUFFIX と YAML の骨格

以下は 例示です。実際の proxy-groups 名やポリシー名は環境に合わせて置き換えてください。GEOIP,JP,DIRECT など国内向けルールを使う場合は、誤って海外 SaaS を直結させないよう上側で意図を確認します。最終 MATCH より前に置くのが基本です。

# Place ABOVE the final MATCH rule. Replace GH_MODELS_PROXY with your selector/policy.
- DOMAIN-SUFFIX,github.ai,GH_MODELS_PROXY
- DOMAIN-SUFFIX,github.com,GH_MODELS_PROXY
- DOMAIN-SUFFIX,githubusercontent.com,GH_MODELS_PROXY
- DOMAIN,api.github.com,GH_MODELS_PROXY

DOMAIN-SUFFIX,github.ai は models.github.ai を含む将来のホストもまとめてカバーします。api.github.com は DOMAIN で明示してもよいですし、広めに github.com サフィックスに任せる運用もあります。社内ミラーだけ DIRECT にしたいホストがある場合は、より具体的なルールを先に書いて優先度を上げます。

Rule Provider で保守する

第三者の Rule Provider に GitHub 系が入っていても、github.ai が未収録のバージョンがあるかもしれません。推論だけが落ちるときは Clash の接続ビューやログで実際の SNI を確認し、足りない DOMAIN-SUFFIX を追記してください。Mihomo では購読ルールと手書きルールの合成順にも注意が必要です。

4 OAuth、CLI、IDE：リダイレクトが増える経路

ブラウザで OAuth を完了するフローでは、github.com 上の認可画面からコールバック URL へ戻るまで、複数ホストが短時間で連鎖します。ここが DIRECT とプロキシで分断されると、Cookie やリダイレクトが途中で途切れて「ログインしたはずなのにトークンが取れない」症状になります。原則として、GitHub 本体と Inference API を同じアウトバウンドに揃えるか、意図的に分けるならその理由をドキュメント化しておくと再現性が保てます。

gh CLI や各種 SDK は環境変数 HTTPS_PROXY を参照する一方、ブラウザは OS のシステムプロキシに従うことが多いです。経路がズレると「CLI は成功するがブラウザ認可だけ失敗」といったパターンが出ます。統一したい場合は、TUN モードで仮想 NIC レベルに寄せる方法も選択肢です。

5 Mihomo 固有の観点：セレクタとログ

Mihomo を載せた Clash Verge Rev などでは、セレクタでノードを切り替えた際に古い TCP セッションが残り、ストリーミング推論だけ途中切断されることがあります。ノード変更後はクライアントの再接続や、短い非ストリーム要求で疎通確認を挟むと切り分けがしやすいです。負荷分散の load-balance を使う場合は、長めの HTTPS を維持できるノード選定が重要になります。

ルールの読み込み順と Rule Provider の更新周期も、トラブルの温床です。購読失敗時に古いリストが残ると、新しい github.ai ホストが想定外のポリシーに落ちます。定期更新と手元の追記ルールを併用する構成が現場では扱いやすいです。

6 DNS：名前解決をルールと揃える

ルールが正しくても、IDE やランタイムが参照する DNS と Clash の fake-ip 設定がずれると、意図しない地域のエッジへ刺さったり、一瞬だけ DIRECT に落ちたりします。Meta カーネル向け DNS／FakeIP の実務で述べているように、DoH と fake-ip の組み合わせを整え、国内ドメインと海外 SaaS を混在させない運用が安定の鍵です。

GitHub Models の Inference API は長時間接続になりやすいため、DNS の TTL が極端に短い環境では再接続が頻発し、体感レイテンシに影響します。クライアント側のタイムアウト設定とあわせ、Clash ログでホスト単位の再試行回数を確認するとよいでしょう。

7 トラブルシューティング

• 401／403 が返る： トークンのスコープや組織ポリシーを疑う前に、api.github.com と models.github.ai の両方が意図した経路に乗っているかを確認します。片方だけ企業プロキシで TLS インスペクションされているケースがあります。
• 推論だけタイムアウト： models.github.ai が別ノードに振られ、長连接が切れている可能性があります。セレクタを変え、同時刻の Clash ログで RST やタイムアウトを見ます。
• OAuth だけループする： github.com の Cookie ドメインとリダイレクト URL が、プロキシ経由で一貫しているかを確認します。ブラウザ拡張によるブロックも忘れずに。
• Copilot は動くが Models API が動かない： ホスト集合が異なります。本稿の github.ai ルールが不足していないかを優先的に見ます。

8 まとめ

GitHub Models は、Inference API を models.github.ai に置きつつ、トークンと権限の世界は従来の GitHub ドメインに残るため、経路設計では二系統を意識するのが要点です。Clash 分流では DOMAIN-SUFFIX,github.ai と github.com／api.github.com を同じ意図で束ね、Rule Provider と手書きルールの不足をログで埋めるのが再現性の高い方法です。2026 年もクラウド推論への依存は高まるため、DNS と TLS を切り分けられるスタックの方が長いセッションに強い場面が多いです。

同じ GitHub エコシステムでも、Copilot 拡張のホスト集合とは重なりが限定的です。用途別に記事を分けておくと、オンボーディング資料がすっきりします。クライアントの入手先は、多くのプロキシツールと同様に、配布元が明示された公式チャネルから揃えるのが安全です。一般的なプロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、海外 API を安定して使うシナリオに向きやすいことがあります。

→ 無料で Clash をダウンロードし、GitHub Models の推論と認証を同じルールで整える