なぜ Windsurf は Marketplace と API を「一括プロキシ」に載せにくいか

Windsurf は VS Code 系のシェルを引き継ぐため、起動直後から 拡張マーケット やアイコン CDN、更新チェックなど、Microsoft／Visual Studio ブランドの名前空間へ短い間隔でアクセスします。一方でサインイン、タブ補完、Cascade のようなエージェント処理は codeium.com や windsurf.com、ドキュメント類の docs.codeium.com／docs.windsurf.com など、Codeium 側のホストへ分かれます。ここを一つの「とにかく PROXY」に押し込むと、マーケットだけ遅い、ログイン画面は開くのにトークン交換だけ失敗する、補完だけ API タイムアウト といった 部分的成功 が増えます。

Clash は接続ごとにルールを上から評価し、最初にマッチした行でポリシーグループを決めます。Windsurf のような Electron アプリは子プロセスごとにプロキシ継承が微妙に異なることもあり、ブラウザでは速い経路が、IDE 内の取得だけ別出口に落ちることがあります。症状はすべてスピナーに見えますが、実態は「どのホストがどのポリシーに乗ったか」と「DNS の答えと実経路が一致しているか」の二点に還元できることが多いです。

ℹ 観測のコツ：接続ログに出る SNI／ドメインをメモし、拡張検索時・ログイン時・Cascade 実行時で ホスト名が変わるか を比較します。層が分かれば、MATCH 前に差し込む明示ルールの位置も自然に決まります。

四つの層：VS Code マーケット、GitHub 周辺、Codeium API、Windsurf 公式

実務では次の四層に分けるとブレにくいです。(1) VS Code 系拡張マーケットと配信 CDN——marketplace.visualstudio.com、*.visualstudio.com、vsassets.io など、メタデータと VSIX／アセット取得。(2) GitHub 周辺——拡張のソース取得や Git 操作、github.com／githubusercontent.com／api.github.com。Windsurf 単体でも Git 連携やプラグイン取得で触れるため、Copilot 記事と同様に「GitHub を完全に無視できる」とは限りません。(3) Codeium のバックエンド——補完、Cascade、課金・利用状況など、DOMAIN-SUFFIX,codeium.com で束ねるのが一般的な出発点です。(4) Windsurf 公式サイトと配信——windsurf.com やダウンロードページ、リリースノート、サインイン導線。公式がホストを増やすことはあるため、固定リストの丸写しより、ログで不足分を足しつつ ルールプロバイダ で追従する方が長持ちします。

層ごとの典型ホスト（参考）

具体名は SKU やリージョンで変わり得ますが、分流設計のたたき台としては次を押さえます。拡張まわりは Copilot 記事で触れた Visual Studio マーケット群と重なりますが、本稿の焦点は Codeium／Windsurf 固有の名前空間をどのポリシーに固定するか です。api.codeium.com や server.codeium.com といったサブドメインがログに出たら、まとめて同じ低ジッターグループへ寄せます。ドキュメント取得が遅いだけなら docs.codeium.com／docs.windsurf.com を別グループに切り出す選択もあります。いずれにせよ「全部同じ高帯域ノード」より、レイテンシと切断耐性が要求に合う経路に揃える ことが安定の鍵です。

ルール行の順序とルールプロバイダの当たり方

rules セクションは上から評価されます。狭い DOMAIN／DOMAIN-SUFFIX を先に置き、GEOIP や巨大カテゴリ、広告ブロック系ルールセットの前に「開発者スタック用」の束を差し込みます。サードパーティルールが github.com や CDN を先に捕捉すると、ブラウザでは無問題でも Windsurf の子プロセスだけ API タイムアウト に見える、という切り分けが難しくなります。ルールの責務をコメントで残し、更新手順は ルール分流のベストプラクティス に沿って整理してください。

rule-providers から展開される行も、通常は rules 内の挿入位置に従います。プロバイダ A（広域ブロック）をプロバイダ B（開発者向け許可リスト）より上に置いた瞬間に、意図せずマーケットや API が別出口へ流れることがあります。「ファイルの記述順」と「GUI での並べ替え」がズレているクライアントでは、見た目は正しくても実際の評価順が逆、という事故もあるため、反映後は必ず実接続ログでドメインと選択ポリシーを突き合わせます。

次の例は概念図です。ポリシー名は利用中のサブスクリプションに合わせて置き換えてください。

rules.yaml（例：概念のみ／本番は検証のうえ調整）

# Place explicit Windsurf / Codeium domains before broad catch-all rules
rules:
  - DOMAIN-SUFFIX,marketplace.visualstudio.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,visualstudio.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,vsassets.io,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,github.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,githubusercontent.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,api.github.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,codeium.com,CODEIUM_LOW_JITTER
  - DOMAIN-SUFFIX,windsurf.com,WINDSURF_LOGIN
  - DOMAIN-SUFFIX,docs.codeium.com,DOCS_OR_DIRECT
  - DOMAIN-SUFFIX,docs.windsurf.com,DOCS_OR_DIRECT
  - MATCH,PROXY_OR_DEFAULT

CODEIUM_LOW_JITTER と WINDSURF_LOGIN を分けるか同一にするかは、ログインだけ別ノードに寄せたいかによります。重要なのは、OAuth や長めのセッションを伴うホストが、意図せず「ダウンロード向けの高帯域だが不安定なノード」へ流れないことです。マーケット取得と推論 API が 別ポリシーに割れて証明書や出口の癖が食い違う と、見かけ上はすべてタイムアウトに見えます。

システムプロキシと TUN：どちらが実トラフィックを覆うか

macOS／Windows では、Clash が OS のプロキシ設定を書き換える方式と、TUN で仮想インタフェースを立てる方式の二系統が一般的です。システムプロキシは「OS の設定を読むアプリ」には手軽に効きますが、Electron 系は子プロセスや拡張ホストが独自のネットワークスタックを持ち、継承が欠けることがあります。TUN はカーネルレベルで捕捉するため取りこぼしは減りますが、企業 VPN やゼロトラスト製品と ルーティング優先度 が衝突することがあります。

「ブラウザでは windsurf.com が開くのに、IDE のサインインだけ回る」場合、まず カバレッジ を疑います。システムプロキシのみで再現するか、TUN へ切り替えて差が消えるかを A/B します。TUN の前提や競合の典型は TUN の深掘り記事 を参照し、複数の透明プロキシを無秩序に重ねないようにしてください。

ループプロキシ にも注意が必要です。OS 全体を Clash に向けたまま、サブスクリプション取得やルールプロバイダ更新まで不安定なチェーンに流すと、ルールが古いままになり「昨日まで動いていた」状態に陥ります。更新系は確実な DIRECT か専用の低リスクグループを残し、Windsurf 本体のトラフィックと混ぜない方が安全です。

DNS・fake-ip と「名前は解けるのに API が timeout」

fake-ip モードでは、アプリに返る IP が合成値であり、実解決は Clash の DNS か上流プロキシ側に委ねられます。DOMAIN-SUFFIX が薄いと、一見すぐに応答が返るのに TCP が進まず、API タイムアウト に見えるパターンが出ます。Codeium／Windsurf の公式名を明示ルールで覆い、nameserver-policy やフォールバックとルーティング判断を一致させると改善しやすいです。

企業ネットワークでは、社内 DNS が同じラベルに別答えを返し、IDE だけ到達不能なアドレスに向くことがあります。split tunnel と整合を取るか、一時的にクリーンな回線で比較し、「名前が悪い」のか「経路が悪い」のかを分けます。一般的な DNS の整理は FAQ も併せて参照してください。

複数ツールがそれぞれ DNS を握ると答えが衝突し、ログイン直後だけ失敗する、といった再現になりがちです。権威を一つに寄せるだけで症状が薄まることもあります。

Cursor／Copilot 向け記事との棲み分け

当サイトの Cursor 向け記事 は、別ベンダーの OAuth と長寿命セッション全般の整理が主で、対象ホストも Windsurf とは異なります。GitHub Copilot 向け記事 は microsoft.com 系と Copilot バックエンドに軸を置いており、本稿の Codeium 名前空間とは重なりが限定的です。VS Code マーケットの取り扱いは両方に出ますが、本稿は Windsurf／Codeium のサインインと推論 API を主役にします。生成 AI 全般の分流は ChatGPT／OpenAI 向け など別記事を参照してください。

⚠ コンプライアンス：法令、利用規約、職場のセキュリティ方針を遵守してください。本稿は許可されたネットワークでの接続安定化の整理であり、未承認の迂回やポリシー回避を推奨するものではありません。

許可された利用の前提で押さえるチェック

  1. この環境で Clash と Windsurf／Codeium を使うことが許可されているか確認する。
  2. 失敗時のホスト名を列挙し、マーケット／GitHub／Codeium API／Windsurf 公式のどの層かを分類する。
  3. ルール行の順序とルールプロバイダの挿入位置を確認し、広域リストが先に当たっていないか見る。
  4. システムプロキシのみ、TUN のみ、の A/B 比較で IDE プロセスの取りこぼしを潰す。
  5. DNS モードと fake-ip をルールと整合させ、「即解決・接続停滞」を再現ログで切り分ける。
  6. サブスクとルール更新がループせず成功する直列経路を残す。
  7. 別回線やモバイルテザリングで切り分け、ISP 側とサービス側障害を除外する。

各ステップの前後でログ行を残すと、設定の総入れ替えより早く収束します。

まとめ

Windsurf の不安定さは、単一の「拡張マーケットが遅い」では説明できないことが多く、VS Code マーケット／GitHub 周辺／Codeium API／Windsurf 公式という複数層に分けて見ると対処が明確になります。Clash ではドメインルールとルールプロバイダの順序で出口を決めるため、層ごとに DIRECT とプロキシを揃え、システムプロキシと TUN のどちらが実トラフィックを覆っているかを一致させることが重要です。DNS／fake-ip を同じ設計言語で扱えば、見かけの API タイムアウト の多くは観測可能なずれに還元できます。

ブラックボックスな「アクセラレータ」より、ルールとログが読めるクライアントの方が、開発者の時間を節約します。Cursor 向けや Copilot 向けの記事と併せ、自分のスタックに合った分流だけをプロファイルに載せるのが長期運用では一番ラクです。

同種のツールと比べると、Clash 系はポリシー表現が明示的で、接続ログから握手・転送・切断の段階を追いやすいです。謎のプリセットに振り回されるより、再現手順が残る設定の方がチームでも再利用しやすくなります。

→ ルール設計が固まったら、Clash を無料ダウンロードし、同じ方針を日々の開発環境に載せてみてください。ログインの再試行や Cascade の再接続に費やす時間を、本来のコーディングに戻せます。