Windsurf 未接続？Clash で Codeium ドメイン分流 2026

なぜ「Windsurf だけずっと読み込み」になりやすいのか

2026 年現在、AI プログラミング用 IDE として注目を集める Windsurf は、Cascade パネルやクラウド連携機能のために、起動後もバックエンドへ継続的に HTTPS 接続を張ります。公式のプロキシ設定ドキュメントでも、サインインや AI 機能のために外部サービスへ到達する必要があること、企業ネットワークでは HTTP／HTTPS プロキシの明示が必要なことが説明されています。開発者のローカル環境では、そのプロキシ役を Clash（または Mihomo 系クライアント）が担うケースが多く、ここで分流（ホストごとに出口＝プロキシグループを変える）が粗いと、「ブラウザでは普通に開けるのに、エディタ内だけ API タイムアウトや真っ白な画面が続く」という切り分けが起きやすいです。

本稿の焦点は、VS Code 派生エディタである点は似ていても、接続先の API ドメインと更新・認証のホスト構成が Cursor とは別物である、という点です。当サイトの Cursor IDE 向け分流ガイドが cursor.sh や cursorapi.com 束を軸にするのに対し、ここでは Codeium／Windsurf 側でフィルタ回避やファイアウォール許可リストの文脈で繰り返し登場する *.codeium.com、*.windsurf.com、*.codeiumdata.com などを起点にします。ホスト名はサービス側の変更で増減し得るため、最終判断は必ず公式ドキュメントと、ご自身の環境で取得した接続ログを優先してください。

注意：本稿はネットワーク設計のたたき台であり、Windsurf／Codeium の利用規約や勤務先のセキュリティ方針を代替するものではありません。Enterprise 導入では管理ポータルやオンプレ接続の要件が異なる場合があります。

典型症状：IDE は動くのに「クラウド側」だけ失敗する

コミュニティやトラブルシューティング記事で繰り返し見られるのは、次のようなパターンです。(1) エディタ枠は開くが Cascade がスピナーのまま進まない、(2) サインインやライセンス確認が途中で止まる、(3) 一部の自動生成機能だけ deadline_exceeded 系の趣旨のエラーになる、など。DNS フィルタや企業プロキシで特定サフィックスが落ちている例では、許可リストに Codeium 関連ドメインを足すと改善した、という報告もあります。Clash 利用者にとっては、「ブロックされている」のではなく、誤ったノード（遅延が大きい・UDP や長いストリームに弱い・別リージョンの CDN エッジに届かない）へ流れているパターンが同等に重要です。

Cursor 向け記事との棲み分け

どちらも「開発者が毎日触る AI IDE」という大枠は同じですが、拡張マーケットのホストやクライアント更新 CDN の名前が異なります。Cursor 記事で整理した 拡張／CDN 系とモデル API 系の二層に分ける発想は Windsurf にもそのまま移植できますが、貼る DOMAIN-SUFFIX は本稿のリストに差し替える必要があります。OpenRouter 単体に絞った OpenRouter 向け記事とも役割が異なり、ここでは「エディタに組み込まれた Codeium バックエンド」へ向くトラフィックを主役にします。

ドメインの束ね方（出発点）

公式の Windsurf ドキュメント類は docs.codeium.com や docs.windsurf.com など複数ホストに分散しており、プロキシ設定ページも Codeium 側ドキュメントに載っています。実務の分流では、まず次のサフィックスをメモし、接続ログに出てくる実ホスト名と突き合わせると安全です。(1) codeium.com — API や認証まわりで頻出する基底ゾーン、(2) windsurf.com — ブランドサイトやドキュメント、一部クライアント関連、(3) codeiumdata.com — データ／テレメトリ系としてフィルタ製品の許可リストに載る例。さらに開発中に github.com やパッケージレジストリへ依存する場合は、MCP・ツールチェーン向け分流とルールが衝突しないよう、評価順を確認してください。

Clash のルールでは DOMAIN-SUFFIX,codeium.com,WINDSURF_AI のように、意図したプロキシグループ名へ流します。サフィックスを広げすぎると無関係なサブドメインまで巻き込むため、運用では「ログに出たホスト名 → 必要ならより細かい DOMAIN 行」を足す段階的アプローチが扱いやすいです。

プロキシグループの切り方（概念）

例として WINDSURF_AUTH と WINDSURF_AI の二つを考えます。前者は OAuth／アカウント確認や静的ドキュメント取得など、比較的短いリクエストが中心で、特定リージョンの出口に依存しやすい処理向けです。後者は Cascade のようなストリーミング応答や補完 API で、API タイムアウトが出やすい経路ほど、低遅延で切断されにくいノードを選びたくなります。実際には最初は一つの WINDSURF グループにまとめ、ログでボトルネックが分かれた時点で分割するでも構いません。ポイントは、「一般ブラウジング用の自動選択」と「エディタのバックエンド用」を無理に同じノードに固定しないことです。

企業プロキシの外側に Clash を置いている場合、Windsurf 設定の「Detect proxy」が OS のシステムプロキシを拾うかどうかも効きます。Clash Verge 等でシステムプロキシを有効化しているなら、エディタ側は検出オンで一貫させるのが手早い一方、手動で 127.0.0.1:ポート を直打ちする構成もよく使われます。いずれにせよ、DNS が Clash の想定外で先に解決されていないかは別途確認が必要です。

ルール評価順序：RULE-SET に埋もれない

Clash の rules: は上から順に評価され、最初に一致した行で止まります。サードパーティの巨大 RULE-SET や GEOIP が先に当たると、後ろに追記した Codeium 行が一生効かない、というのは定番の落とし穴です。分流を確実に効かせるには、より具体的な DOMAIN-SUFFIX や DOMAIN を、大雑把な締めの行より上へ配置します。共通の書き方はルール分岐の詳解ガイドと同じ考え方です。

YAML の骨格例（サンプル）

実際のキー名・インデントは利用中のコアと GUI に合わせてください。ここでは二系統へ分けるイメージのみ示します。

proxy-groups:
  - name: WINDSURF_AUTH
    type: select
    proxies:
      - 🇺🇸 低遅延
      - 🇯🇵 安定
      - 🌐 自動選択
  - name: WINDSURF_AI
    type: select
    proxies:
      - 🇺🇸 低遅延
      - 🇸🇬 安定
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,codeium.com,WINDSURF_AI
  - DOMAIN-SUFFIX,codeiumdata.com,WINDSURF_AI
  - DOMAIN-SUFFIX,windsurf.com,WINDSURF_AUTH

実運用では、認証と推論で別ノードを使いたい場合は DOMAIN 行でホストを細かく分けるか、サブドメインごとに片方のグループへ寄せてください。最初の一致だけが有効になるため、同一サフィックスを二行に分けて「フォールバック」のように書くことはできません。

DNS・Fake-IP・Secure DNS のすきま

ルールが正しく見えても、名前解決が Clash の外で完結していると、実トラフィックは別経路へ出ます。OS やブラウザの Secure DNS、VPN 切断後の残存設定、Fake-IP とアプリ側キャッシュの組み合わせは、エディタ系で特に紛らわしいです。対策の方向性は、(1) 解決経路をできるだけ一本化する、(2) TUN やシステムプロキシを変えたら OS の DNS キャッシュとアプリ再起動をセットで行う、(3) ダッシュボードの接続ログで「ドメインルールに載ったか」を確認する、の三点にまとまります。手順の全体像は TUN モード完全ガイドの DNS の節が参考になります。

遅延テストと実測の進め方

まず Clash を一時的に「期待どおりのノード」へ単純化し、Windsurf を完全終了してから起動し直します。次に Cascade を開き、同時に Clash の接続一覧でホスト名と選択されたプロキシグループを眺めます。ここで意図しない DIRECT や別の地域ノードが混ざっていれば、ルール順かサフィックス漏れを疑います。その後、同じ購読内で地域違いのノードへ A／B 切替し、API タイムアウトが出口依存かを切り分けます。ストリーミング応答だけ遅い場合は、中継機器の HTTP/2 バッファや TLS インスペクションも視野に入ります（企業ネットワークでは公式のプロキシ手順と併読が安全です）。

Windsurf 側のプロキシ設定メモ

公式ドキュメントでは、設定画面の検索バーに「proxy」と入れ、Detect proxy のトグルや手動のプロキシ URL、認証情報、リモート開発（SSH／dev container）向けの別項目を案内しています。Clash をローカルで動かしている場合、http://127.0.0.1:7890 のような形はよく使われますが、ポートはクライアント設定に合わせてください。リモートセッションだけ別経路になる事例では、ローカルと Remote の両方に同じ到達性が必要です。

チェックリスト（そのまま試せる順）

接続ログに出たホスト名をメモし、codeium.com／windsurf.com／codeiumdata.com などとの対応を確認する
専用の プロキシグループを定義し、DOMAIN-SUFFIX 行を巨大 RULE-SET より上へ置く
Cascade 操作時にログで意図したグループへ流れているか確認する
DNS（Secure DNS、Fake-IP、キャッシュ）を整理し、必要なら TUN 前提で再検証する
Windsurf の Detect proxy／手動プロキシを Clash の運用と揃え、完全再起動後に再試行する
改善しない場合はノードの地域・品質を A／B し、API タイムアウトが出口依存かを切り分ける

よくある誤解

Cursor 向けルールを貼れば Windsurf も必ず動く

ホスト設計が異なります。cursor.sh だけ整備しても Codeium 側のサフィックスが抜けていれば再現します。IDE ごとにリストを分けておく価値があります。

「とにかく最速ノード」一択でよい

帯域テストで速いノードが、長いストリームや特定リージョンの API に合うとは限りません。分流で用途別に出口を分けた方が安定することがあります。

ルールを足したらあとは DNS は見なくてよい

多くの「効かない」報告は評価順とDNSの組み合わせです。ルールとログと名前解決をセットで見て初めて切り分けが終わります。

まとめ

Windsurf のような AI プログラミング IDE は、ローカルの UI とクラウドの API ドメインの両方に依存します。Clash で Codeium 系ホストを独立したプロキシグループへ分流し、ルール順とDNS、エディタ側のプロキシ検出まで揃えると、「起動はするが Cascade だけ止まる」系の症状はかなり追いやすくなります。ドメインは将来変更され得るため、キャプチャと公式資料の併用を忘れないでください。

用語や汎用手順は当サイトのチュートリアル・ドキュメントも参照できます。クライアントの入手と更新は、配布物がまとまっているダウンロードページから行うと取り違えが少ないです。ルールの基礎はルール分岐の詳解、OS 全体へ透過的に効かせたい場合はTUN ガイドと併読すると、本稿の設定がすぐ実装に落ちます。用途別に出口を制御できる Clash は、開発機のプロキシとしてブラウザ一本より実務的なことが多いでしょう。→ Clash クライアントを無料でダウンロードし、Windsurf 向け分流を試す