2026：Windsurf／Codeium の IDE クラウド依存を Clash で整える——分流ルールと DNS の段階実測
2026 年もAI ネイティブ IDEの需要は高く、Windsurf（Codeium 傘下）は Cascade などクラウド側のモデル・認証・拡張機能取得に強く依存します。一方で「ログイン画面は出るのにトークン取得だけ失敗する」「補完は動くのに拡張機能マーケットだけ真っ白」「アップデートチェックだけタイムアウト」といった症状は、単一ドメイン一行の PROXY では足りないホスト集合と、DNS（fake-ip・DoH）の取り違えとして現れやすいです。本稿はClash（多くの場合 Clash Meta／Mihomo コア）で認証・モデル API・拡張機能マーケット・CDN／テレメトリに現れる分流ルールの出発点と、Rule モードのログで再現する手順を日本語で整理します。Cursor と GitHub 向け記事が扱う別プロダクトのホスト集合と混ぜず、Windsurf／Codeium エコシステム固有のドメイン分岐に焦点を当てます。CDN やエッジは更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。
なぜ「汎用の生成 AI 向けルール」をそのまま流用しにくいか
Windsurfは配布・案内ドメインとして windsurf.com 系、ドキュメントに docs.windsurf.com や docs.codeium.com のような別 FQDNが並ぶ構成が一般的です。Codeiumブランドのサービス本体は codeium.com 配下に集約されやすく、認証や課金、管理コンソール、beta 系のサブドメインがログイン周りに現れることもあります。チーム／エンタープライズ向けの分析やヘルス系 API では、ドキュメント上 server.codeium.com のようなIDE の UI とは別ホストが案内されることがあり、ブラウザでは通るのにバックグラウンドの API だけ失敗する切り分けに直結します。VS Code 互換の拡張機能取得では、Visual Studio Marketplace（marketplace.visualstudio.com）や *.visualstudio.com 系、オープン側の Open VSX（open-vsx.org）などIDE 本体とは別ホストが絡みます。さらに静的アセットや計測用のCDN、サードパーティの分析・クラッシュレポート用ホストが混ざると、ブラウザで公式サイトは開けるのにIDE 内の埋め込み WebView だけ失敗するといった切り分けが典型です。
Clash の観点では「どのホストがどのポリシーにマッチしたか」「広い RULE-SET に先に飲まれていないか」「Electron 系アプリがシステムプロキシを読まずに別出口へ出ていないか」が分岐点になります。チュートリアルでモードの前提を押さえたうえで、カスタムルールの書き方と併読すると、IDE 向けの例外を上に積む判断がしやすくなります。
チャット中心の単一ベンダー整理は ChatGPT 向け記事やClaude 向け記事が担います。本稿はIDE＋クラウド依存に絞り、WindsurfとCodeiumの分流ルールとDNSまわりの切り分けを重ねます。
ホストの束ね方：認証・モデル API・拡張機能・CDN／テレメトリ
認証では、ブラウザで開くログイン／同意画面と、IDE がバックグラウンドで叩くトークンエンドポイントが別ドメインになることがあります。企業 SSO や IdP を挟む場合は、組織側で許可されたドメインがさらに増えます。モデル APIは製品アップデートでパスやホストが変わり得るため、検索で見つかるドメイン一覧は参考にとどめ、自分の Rule ログに出た名前を正として育てるのが長く使うコツです。
拡張機能マーケットは、GUI からの検索・インストールが marketplace.visualstudio.com や *.gallerycdn.vsassets.io のようなCDN 系に分岐しやすい典型です。チーム方針で Open VSX だけを許可している場合は open-vsx.org とその配信ホストをセットで見ます。CDN／テレメトリはプロダクトポリシーとインフラ変更で増減しやすく、プライバシー設定をオフにしても接続が残るケースがあります。セキュリティとコンプライアンスの判断はプロキシ設定とは独立して必ず確認してください。
HTTPS の SNI と実ホストの取り違えで挙動がおかしいときは、Clash Meta の sniffing と DNS の切り分けも併せて確認すると原因が絞りやすいです。
分流の土台：proxy-groups に「Windsurf／Codeium 用」を置く
購読テンプレの汎用 PROXY を直接指すより、WindsurfCodeium のような用途名のグループを select または url-test で用意し、rules からは常にその名前を参照するのが運用しやすいです。補完トラフィックと拡張機能取得を同じ出口に揃えるか、レイテンシや社内ポリシーの都合でマーケットだけ別グループにするかも、グループ名を分けておけば後から差し替えが容易です。ネストや型の詳細は proxy-groups のガイド を参照してください。
rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。
ドメインルールの出発点（YAML 例）
方針として、(A) Windsurf／Codeium の第一接続先を同じ WindsurfCodeium に寄せる、(B) 拡張機能 CDN を別グループに分けたい場合は別名の proxy-groups を追加する、(C) 社内ポリシーで特定ゾーンだけ直結にしたい場合は、GEOIP や広い RULE-SET との衝突をログで確認しながら例外を上に積む、が現実的です。DOMAIN-SUFFIX,com のような広すぎる一括は他サービスへ波及しやすいので避け、ログで確認したサフィックスに絞るのが無難です。以下は出発点であり、実際の接続ログと公式ドキュメントの最新表記を優先してください。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。
rules:
# Examples only — tune group name (WindsurfCodeium) and domains to your logs/docs
- DOMAIN,server.codeium.com,WindsurfCodeium
- DOMAIN,docs.windsurf.com,WindsurfCodeium
- DOMAIN,docs.codeium.com,WindsurfCodeium
- DOMAIN,windsurf.com,WindsurfCodeium
- DOMAIN,www.windsurf.com,WindsurfCodeium
- DOMAIN-SUFFIX,windsurf.com,WindsurfCodeium
- DOMAIN-SUFFIX,codeium.com,WindsurfCodeium
- DOMAIN-SUFFIX,marketplace.visualstudio.com,WindsurfCodeium
- DOMAIN-SUFFIX,visualstudio.com,WindsurfCodeium
- DOMAIN-SUFFIX,vsassets.io,WindsurfCodeium
- DOMAIN-SUFFIX,open-vsx.org,WindsurfCodeiumブラウザ、Windsurf本体、ターミナル統合から起動したサブプロセス、コンテナ内のツールチェーンは、参照するホスト名が UI と一致しないことが多く、本稿のリストとは必ずしも一致しません。テレメトリやアップデートで別ドメインが出た場合は、接続ログに出た FQDN をそのまま DOMAIN や DOMAIN-SUFFIX で追加してください。画像や WASM、埋め込みリソースの読み込みに別ドメインが混ざる場合も、ログに出た名前を足すたびに、安定アクセスの再現性が高まります。
DNS と fake-ip：ルールより前に潰れる「名前解決」
分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラー、長時間接続の中断に見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で codeium.com や windsurf.com だけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。
ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。Electron 系 IDEがシステムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案を検討してください。ルールの優先順位は、より具体的な DOMAIN を汎用の MATCH や広い RULE-SET より上に置く、という原則が API や長時間接続の取りこぼし防止に効きます。
動作モード：Rule・Global・Direct の使い分け
Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。補完は動くが拡張機能だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。
段階実測：ログで「宛先」と「採用ルール」を確認する
-
1
Baseline（Direct または Clash 停止）
まず Direct で Windsurfを起動し、ログインと補完、拡張機能の検索まで一通り試し、症状が再現するかを記録します。これで「ローカル回線やプロバイダ側」の要因も見えます。
-
2
Rule に戻し、認証・モデル・マーケットそれぞれでログを読む
サインイン、Cascade などのモデル呼び出し、拡張機能のインストール、アップデートチェックについて、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。
-
3
一行ずつルールを足して再計測
DOMAIN-SUFFIXを追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。 -
4
DNS ログがあれば併記する
名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。
この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、CDN やエンドポイント変更にも追従しやすくなります。企業ネットや地域によっては特定ドメインへの到達性が制約される場合でも、出口の品質・DNS・ルールの三つを同時に疑うと早く収束しやすいです。
よくある質問
ブラウザは快適なのに Windsurf だけログインできない
ブラウザはシステムプロキシ経由でルールが効いているが、Electron 系 IDE がプロキシ設定を読んでいないパターンです。TUN、または IDE 側のプロキシ設定の有無を確認してください。
補完は動くのに拡張機能マーケットだけ真っ白
マーケットと CDN 用のホストが別ドメインに分かれ、意図せず DIRECT や遅いノードに落ちている可能性があります。ログに出たホストを追加し、該当行を上に移動して再確認してください。ノード側のタイムアウトも疑ってください。
職場・学校のネットワークでは
組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。
まとめ
WindsurfとCodeiumをClashで安定利用したい場合は、openai.com 向けに整理した分流ルールだけでは取りこぼしが出やすく、windsurf.com 系・codeium.com 系・server.codeium.com のようなAPI 用ホスト・拡張機能マーケットとその CDN、テレメトリに現れるホストを、ログで拾い上げてドメイン分流に落とし込むのが実務的です。本稿の例は出発点であり、ログに基づきルールを育てることが長く使うコツです。GitHub 中心の整理は Cursor と GitHub 向け記事、オープン模型ホスティングの別例は Hugging Face 向け記事で扱っているため、混同せず参照してください。
クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。オープンソースの参照や Issue の確認は GitHub 等でも可能ですが、インストーラの主導線は本サイトのダウンロードページに寄せるのが、他の開発者向け記事とも揃った使い方です。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用体験が一段整理されやすい場面が多いです。