2026 年、Snowflake Cortex Code を Clash で安定：
コンソール・API・Git 連携の DOMAIN 分流

1 Cortex Code が「別物」になる理由（汎用 AI 記事との差）

Cortex Code は、汎用チャット UI ではなく Snowflake アカウント上のメタデータ・SQL・セキュリティ境界と結びついた AI コーディング支援として説明されています。ローカルに CLI を置き、認可されたワークスペースへ接続するモデルは、ブラウザで chat.openai.com を開く用途とは認証の起点も証明書検証の相手も異なります。そのため「OpenAI 用に書いた DOMAIN-SUFFIX を足したから大丈夫」という楽観は、典型的に穴を残します。

実務では、(1) Web コンソールとアセット CDN、(2) アカウント固有の API ホスト（sfc-*.snowflakecomputing.com やリージョン付き URL）、(3) Git ホスト（GitHub／GitLab など Snowflake 側の Git 連携設定に依存）、(4) 企業が選ぶ SSO／IdP（Microsoft Entra、Okta など）の四層に分かれます。いずれか一つが意図しない経路に落ちると、「ブラウザの Worksheets は動くが CLI の OAuth が終わらない」「Git 連携だけタイムアウト」といった部分的成功になりがちです。

本稿のゴールは、これらを同じ品質のプロキシポリシーに載せ、ログで漏れホストを追いかけられる状態にすることです。Microsoft テナントとセットで見る場合は、Microsoft 365 Copilot／Office サインイン向けの記事で述べた login.microsoftonline.com まわりと棲み分けしつつ、Snowflake 固有サフィックスを明示的に足してください。

2 Snowflake 側の代表ホストと DOMAIN-SUFFIX の考え方

公式ドキュメントやリリースノートは随時更新されるため、常に最新の許可リストを正とし、本稿の列挙は出発点です。多くの環境で最初に押さえるのは次のような層です。

• アカウント API： snowflakecomputing.com 配下のアカウント URL。REST／SQL エンドポイント、ステージ、OAuth コールバックなどがここに収まります。
• 新 UI／ランディング： app.snowflake.com とその配下。ブラウザのセッションや一部の埋め込みリソースが別 CDN に伸びることもあります。
• コーポレートサイトと学習コンテンツ： snowflake.com、ドキュメントやトレーニング、ステータスページなど。CLI 単体では必須ではない一方、初回セットアップ時の参照で必要になることがあります。
• 証明書／OCSP： 中間者プロキシや TLS インスペクションがあると、クライアント証明書検証で詰まるケースがあります。Snowflake のエラーが TLS 由来かを切り分けます。

DOMAIN-SUFFIX,snowflakecomputing.com,POLICY のように広いサフィックスでまとめると保守は楽ですが、社内検証用に同名空間をローカル DNS で割っている場合は誤マッチに注意します。そのときは DOMAIN でアカウント FQDN を先に固定し、例外を DIRECT に寄せる二段構えが安全です。

3 Git 連携と企業 SSO：二系統目の「別経路」

Snowflake の Git 連携は、Git プロバイダの API と Webhook、および組織の IdP をまたぎます。GitHub を選ぶ場合、リポジトリ操作と OAuth は github.com 系に集中しますが、すでにGitHub Copilot 向けの記事で整理したホスト集合と重複します。運用上は「Snowflake 用ポリシー」と「汎用 GitHub 用ポリシー」を同一アウトバウンドに寄せるか、セレクタで分けるかをチーム方針で決めるとよいです。

GitLab セルフホストのようにオンプレ URL を登録する場合は、グローバルリストに存在しないため、DOMAIN-SUFFIX,git.example.corp,POLICY のような自前ルールが必須です。SSO が Microsoft Entra ID なら、login.microsoftonline.com やテナント固有ホストが追加で必要になります。ここは Copilot 記事と同型の「ログインと API を分けず同じ経路品質に乗せる」発想がそのまま使えます。

Cortex Code CLI がブラウザでデバイス認証や OAuth を開く場合、一時的に localhost コールバックへ戻るフローがあります。TUN モードでローカルループバックをどう扱うか、企業プロキシが localhost を書き換えないかは、TUN モードのガイドとあわせて確認してください。

4 コピー用 YAML の骨格と Rule Provider

以下は 例示です。SNOWFLAKE_PROXY は実際のセレクタ名に置き換え、MATCH より上に配置してください。国内向け直結ルールがある場合は、このブロックと競合しない順序をログで確認します。

# Place ABOVE the final MATCH rule. Replace SNOWFLAKE_PROXY with your policy name.
- DOMAIN-SUFFIX,snowflakecomputing.com,SNOWFLAKE_PROXY
- DOMAIN-SUFFIX,app.snowflake.com,SNOWFLAKE_PROXY
- DOMAIN-SUFFIX,snowflake.com,SNOWFLAKE_PROXY
# Optional: append CDN or edge hosts your tenant actually hits (verify in Clash logs).

コメント行のとおり、実際に接続ログに出た CDN やエッジのホスト名を追記してください。リージョンや機能フラグによって追加ドメインが増えるため、静的な例示リストだけに依存しない運用が安全です。Rule Provider に「クラウド SaaS」カテゴリを任せる場合でも、アカウント URL のサフィックスは明示ルールで補強するのが再現性が高いです。購読更新で上書きされないよう、mixin による追記でローカル差分を残す運用も現場では一般的です。

セレクタと API の長连接

Cortex／LLM 系の推論呼び出しは HTTPS の長めのセッションになりやすく、不安定なノードでは途中切断が出ます。url-test で選んだサーバが SQL ワークロード向けに最適とは限らないため、レイテンシより成功率を優先するセレクタ設計や、フォールバックグループの併用を検討してください。関連する YAML の型はurl-test／fallback の記事が参考になります。

5 CLI・HTTPS プロキシ、環境変数と TUN

Go／Rust 系の単一バイナリ CLI は、OS のシステムプロキシを自動では見ないことが多いです。HTTPS_PROXY／https_proxy をシェルに設定し、Clash の mixed ポート（例: 127.0.0.1:7890）へ向けるのが手早いです。一方でブラウザでの SSO はシステムプロキシを参照するため、ブラウザと CLI で別経路になりやすい点に注意します。

チーム全員の設定ブレを減らすには、TUN モードで仮想 NIC レベルにトラフィックを集約し、ルールで Snowflake と Git をまとめて載せる方法が扱いやすいです。コンテナや WSL から同じマシンの Clash を使う場合も、境界が一つになるメリットがあります。細部は OS ごとに異なるため、端末ポリシーに合わせて選んでください。

6 DNS・FakeIP と接続ログでの裏取り

ルールが正しくても、IDE や CLI が参照するリゾルバと Clash の DNS モジュールがずれると、意図しない地域のエッジに刺さったり、DIRECT へ落ちたりします。Meta カーネル向け DNS／FakeIP の実務で述べているように、DoH と fake-ip の組み合わせをルール設計と一貫させることが安定の鍵です。

変更後は Clash の接続ビューで、snowflakecomputing.com と app.snowflake.com、Git ホスト、IdP ドメインがすべて同じアウトバウンド名に載っているかを確認します。SNI が見えない場合は Sniffer 設定の影響も調べますが、Snowflake のようにホストが明確な HTTPS では、まず DOMAIN-SUFFIX 側を疑う方が早いです。

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

• コンソールは開くが CLI だけ失敗： API ホストが DIRECT のまま残っていないか、CLI だけ NO_PROXY に入っていないかを確認します。
• Git 連携だけ 403／タイムアウト： GitHub／GitLab の API ドメインと、組織の IP 許可リストの両面を見ます。Clash 側はサフィックス漏れが多いです。
• SSO ループ： IdP と Snowflake の両方のホストが同一ポリシーに乗っているか、Cookie が途中で落ちていないかを疑います。
• 証明書エラー： 企業インスペクションと Snowflake の相性を先に切り分け、Clash のルート起因ではないかを確認します。
• ノード切替後だけ不安定： 長连接が切れている可能性があります。セレクタの切替ポリシーと、url-test の間隔を見直します。

8 まとめ

Snowflake Cortex Code のようなデータクラウド直結型の開発者ツールは、汎用 LLM 記事で扱う OpenAI／Anthropic 系ドメインとは別のホスト集合に依存します。Clash 分流では snowflakecomputing.com と app.snowflake.com を軸に DOMAIN-SUFFIX で束ね、Git 連携と SSO に使う Git ホストと IdP を同じ品質の経路へ載せるのが再現性の高い型です。Rule Provider に任せる場合も、アカウント URL と CDN の漏れを接続ログで埋める運用が現実的です。

ブラウザと CLI、Git と IdP の四者が別々にプロキシ解決するのが混乱の源です。システムプロキシ、環境変数、TUN のどれを主軸にするかをチームで一本化し、DNS をルールと揃えると、Cortex Code のセットアップや日常の Worksheets 利用の両方が楽になります。単機能の HTTP プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、2026 年の B2B SaaS 開発フローには向きやすい場面が多いでしょう。

クライアントの入手は配布元を一本化する意味でも当サイトのダウンロードページから行い、ソースや Issue は GitHub を併用する程度に分けると運用が安定します。

→ 無料で Clash をダウンロードし、Snowflake と Git の経路をルールでまとめて整える