Windsurf Cascade が繋がらない？モデル API とゲートウェイ域名を Clash・mihomo で分流して安定させる（2026）

1. なぜ Cascade だけ不安定に見えるか

第一に、AI IDE 全体のトラフィックが単一ドメインに収まらないことです。公式サイトの表示、サインイン、エディタ本体の更新、Cascadeやチャット用のモデルゲートウェイ、拡張の取得が、それぞれ別のホスト名に割り振られるのは一般的です。windsurf.com だけをプロキシへ送っても、旧来の Codeium 側名前や API サブドメインが直結のまま残ると、画面の一部だけが読み込めずAPI タイムアウトに見えます。

第二に、越境アクセスとアカウントポリシーの影響です。到達性は経路だけでなく、サービス側のリージョン設定にも依存します。本稿は名前解決と出口を揃える技術的な整理に限定し、規約違反になり得る回避行為は扱いません。

第三に、url-test や auto 系策略への散らばりです。自動選択のグループを大きく運用しているほど、Cursor や Windsurf のように短い再試行を繰り返すクライアントでは、毎回別ノードに落ちてTLS や認証が不整合に見えることがあります。IDE 向けには専用の select グループで出口を固定しやすいです。

2. Cursor／OpenRouter 記事との役割分担

当サイトでは、Cursor 向けの開発者ドメイン分流や、OpenRouter のモデルゲートウェイを別稿で扱っています。いずれも「API が別経路に落ちないようにホスト名で束ねる」点は共通していますが、Windsurf は Codeium 由来の名前空間が残りやすく、Cascadeのエージェント実行では長時間ステイするストリーム型の接続が混ざる点がCursor 稿と微妙に異なります。

OpenRouter 記事が単一ゲートウェイ域名に寄るのに対し、Windsurf では公式ドメイン・認証・補完 API・パッケージ取得が同時に動くため、ルールの抜け漏れが「たまに失敗」として表れやすいです。Google 特化の挙動はGemini と QUICの記事と分担し、IDE バイナリと npmの経路は Cursor 稿を参照して足し算するイメージが運用しやすいです。

購読の取り込み自体はサブスクリプション導入を前提に、以下では追記する rules の位置に注目します。

3. まず押さえるドメインと「モデル GW」周り

次の一覧は切り分けの出発点であり、サービス改修で変わり得ます。公式ドキュメントでは JetBrains 連携などでhttps://windsurf.com 到達の確認が例に挙がることがあります。併せて、ブランド移行の途中ではcodeium.com やそのサブドメイン、ドキュメント類の docs.codeium.com／docs.windsurf.com といった二系統のホストが混在しがちです。

エディタの裏側では、VS Code 互換の拡張取得で marketplace.visualstudio.com や Azure Blob 名、オープン側なら open-vsx.org、依存取得で registry.npmjs.org、ソースやリリースで github.com／objects.githubusercontent.com が絡みます。Cascadeがリポジトリを跨いで操作する場面では、これらが同じ秒に別策略へ落ちると、エージェントだけ途中で止まるように見えます。

Cognitionによる事業統合後は、新しいモデル GW名や認証フローが増える可能性があります。推測で広い DOMAIN-SUFFIX を一括追加するより、ログに出たホストから足す方が副作用が少ないです。

ルールの評価順はルールルーティング解説の通り、具体的な DOMAIN 行を MATCH より上に置きます。購読プロバイダの末尾に追記するだけでは効かないことがある点に注意してください。

4. mihomo ルール例：DOMAIN-SUFFIX と評価順

実務では WINDSURF_DEV のような策略グループを一つ用意し、IDE とよく一緒に動くレジストリ名をそこへ寄せます。TUN やプロセス分流に対応したクライアントなら、バイナリ名での上書きも併用できます。

以下は構造例です。プロキシ名・実在ドメインは環境に合わせて差し替えてください。

# proxy-groups: stable exit for Windsurf + dev tooling
proxy-groups:
  - name: WINDSURF_DEV
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_JP
      - DIRECT

# rules: keep IDE/API hosts above broad MATCH
rules:
  - DOMAIN-SUFFIX,windsurf.com,WINDSURF_DEV
  - DOMAIN-SUFFIX,windsurf.ai,WINDSURF_DEV
  - DOMAIN-SUFFIX,codeium.com,WINDSURF_DEV
  - DOMAIN-SUFFIX,registry.npmjs.org,WINDSURF_DEV
  - DOMAIN-SUFFIX,open-vsx.org,WINDSURF_DEV
  - DOMAIN-SUFFIX,marketplace.visualstudio.com,WINDSURF_DEV
  - PROCESS-NAME,Windsurf,WINDSURF_DEV
  - MATCH,PROXY

PROCESS-NAME は OS ごとに表記が変わります。Windows では実行ファイル名に .exe が付くことが多く、ログのスペルに合わせてください。macOS・Linux でもElectron 系の実名は環境差が出ます。

TUN モードでは DNS フォールスルーとセットで見ると、接続表と名前解決の矛盾に早く気づけます。

5. 策略グループと API タイムアウトの見極め

API タイムアウトが「別ノードにすると直る」タイプであれば、select で出口を固定するのが第一候補です。逆に、429 や明確な認証エラーが返っている場合は、レート制限やサブスクリプション側を疑った方が早いことがあります。

Cascadeのように長めの応答待ちになる処理では、安定性よりも切断率が効いて見えます。url-testの間隔が短すぎると、試行中に別ノードへ切り替わってストリームが途中で閉じたように見えることがあるため、IDE 向けグループは手動 selectと組み合わせると切り分けが楽です。

チーム利用なら「Windsurf 用に使うノード名」を README に固定し、個人の画面イジり由来の差を減らすのが実務的です。

6. DNS・fake-ip でルールが空振りするパターン

fake-ipモードでは、ブラウザが見ている名前とコアが保持する仮想 IPの対応が崩れると、DOMAIN ルールに乗らないように見えます。Claude 向け fake-ip 記事でも触れた通り、出口とドメイン表記のセットはサービスごとに重要度が違います。

IDE は OS のスタブリゾルバとプロキシチェーン内の DNSのどちらを使うかが実装依存です。失敗時はどのレイヤで名前を解いたかをログに残し、ルールのサフィックスと実ホストが一致しているかを戻り値で確認してください。DoH を fake-ip と揃える手順も併せて参照すると、二重 DNS による誤マッチを減らせます。

github.com など広いサフィックスは、仕事用リポジトリまで同じ策略へ巻き込む副作用があります。必要になった名前だけを足す運用が安全です。

7. システムプロキシ・QUIC・UDP の補足

Windsurf はドキュメント上、OS のプロキシ検出や手入力のプロキシ設定に対応しています。Clash 側がmixed-portで HTTP と SOCKS を同じ番号に出しているときは、IDE が期待するスキームと一致させてください。allow-lanやファイアウォールでループバック以外が塞がれていると、検出は成功しても実接続が失敗することがあります。

HTTP/3（QUIC）は UDP を使うため、ノード側の UDP 扱いやローカル FW でTCP だけ通る状況と差が出ます。Google 系が絡む場合は前述の Gemini 記事の QUIC 切り分けを参照し、ドメインを揃えたうえでトランスポートを疑う順序を守ると迷子になりにくいです。

端末の省電力やスリープ直後にだけ失敗するなら、DNS キャッシュやNIC の再起動で名前が一瞬古いまま残るケースもあるため、再現手順にスリープの有無を書き添えるとチーム共有が速くなります。

8. 切り分け手順：ログの見方

実測での推奨順は次の通りです。（1） mihomo のログで、問題のホストがどの策略にマッチしたかを確認する。（2） 意図したグループへ入っているのに遅い・切れるなら、そのグループ内のノードを入れ替え、レイテンシと成功率を比較する。（3） HTTP ステータスやTLS エラーが一定なら、認証・課金・レートの線を並行して疑う。

開発者ツールのネットワークパネルが取れる場合は、失敗レスポンスのホストとパスをそのままメモし、ルールに足りないサフィックスがないかを日付付きで追記する運用が続きやすいです。体感で直ったどの名前が残っていたかを残すのがコツです。

CLI や別プロセスから npm を叩く場合、PROCESS-NAME の対象外になるため、ターミナル経路もログで一本化されているか確認してください。コンテナ越しに開発しているならDocker とホストプロキシのガイドも合わせて読むと早いです。

9. よくある質問

Cascade パネルだけ真っ白で、エディタ自体は動きます。何から疑えばよいですか？

別ホストへの API が別策略や DIRECT に落ちている可能性が高いです。コアログで該当ドメインがどの proxy-groups にマッチしたかを最初に確認してください。

windsurf.com だけプロキシに載せているのに直りません。

認証・モデル・拡張取得が codeium.com 系や npm、マーケット別名へ分散することがあります。失敗 URL のホストごとにルールを足す運用が安全です。

Cognition 買収後もドメインは同じですか？

統合に伴いエンドポイントやブランド表記が変わる余地があります。常に手元のログと公式の接続要件を優先し、本稿の一覧は出発点として扱ってください。

10. まとめ

WindsurfのCascadeや補完のつながり悪さは、複数ホストへの分散とClash 分流のばらつきが重なると原因が見えにくくなります。mihomoでwindsurf・codeium 系と開発者レジストリを同じ策略に束ね、DNS・fake-ipをルールと突き合わせ、必要なら QUIC も切り分ける——この流れが、Cursor稿・OpenRouter稿と重ならない補助線になります。Cognition傘下の将来変更にも備え、ログで伸びる名前を都度ルールへ取り込む習慣が効きます。

汎用 VPN や更新が止まったラッパー型クライアントでは、ホスト単位の接続ログが薄かったり、ルール順を細かく制御しにくかったりして、AI IDE のように短い再試行が続くワークロードでは原因特定が長引きがちです。mihomo 系の Clash クライアントはDOMAIN 行の追記とログ照合が素直なので、チームでモデル GW 域を共有メモに残す運用にも向きます。

自分向けビルドの選び方とポート確認から始めるなら、 → Clash 公式ページから無料ダウンロードし、分流とログを試す のが手早いでしょう。