1 Windsurf の通信が分岐する理由
Windsurf エディタはローカルでソースを扱いながら、クラウド側へ HTTPS で推論リクエストを送ります。同時に、サインイン状態の確認や Web サイト連携、機能フラグの取得など、別サブドメインへの往復が続きます。2026 年時点でも「AI プログラミング支援を日常業務に組み込む」動きは加速しており、社内プロキシや地域ルーティングの影響を受ける開発者は少なくありません。
Clash 互換クライアント（Mihomo コアを載せた Clash Verge Rev など）では、ルールモードでホスト名ごとにアウトバウンドを切り替えられます。ポイントは、単一の PROXY に丸投げするのではなく、Codeium／Windsurf 公式が列挙するドメイン帯を同じ品質の経路に載せ、あわせて 拡張マーケット（Visual Studio Marketplace や関連 CDN）を取りこぼさないことです。企業版やハイブリッド構成では追加ホストやトンネル経路が増えるため、社内ドキュメントと接続ログを正として不足を埋める姿勢が安全です。
Electron 系エディタ全般のプロキシの扱いはCursor × Clash の記事、GitHub 認証と Copilot API の二系統はGitHub Copilot 向け記事で扱っています。Windsurf は Codeium ドメイン集合が主役になるため、本稿ではそこを軸にしつつ、VS Code 系と共通する 拡張取得のレイヤーを足します。
2 公式ドキュメントが案内するホスト（要ホワイトリスト）
Windsurf のセキュリティページでは、クラウド／ハイブリッド利用時にクライアントが接続しうるドメインが説明されています。一覧は完全網羅ではない前提で、少なくとも *.codeium.com と *.windsurf.com のホワイトリストが推奨されています。記載例としては次のようなホストが挙げられます（変更されうるため、常に最新版を正としてください）。
- API・バックエンド：
server.codeium.com（多くの API）、web-backend.codeium.com（windsurf.com サイト側からのリクエスト）、unleash.codeium.com（機能フラグ）、inference.codeium.com（一部推論）。 - 配信・ダウンロード：
codeiumdata.comおよび*.codeiumdata.com（言語サーバや Windsurf 関連の取得ホストとして言及）。 - ブランド／Web：
*.windsurf.com— サインイン導線やマーケティングサイトと連動する通信に絡みます。
公式トラブルシュートでも、円滑な動作のために *.codeium.com・*.windsurf.com・*.codeiumdata.com を許可する旨が繰り返し案内されています。プロキシ設定の詳細はWindsurf Editor のプロキシ設定ガイドにまとまっており、システムプロキシの検出や手動指定が説明されています。
3 Clash 分流：DOMAIN-SUFFIX と YAML の骨格
実務では、信頼できる Rule Provider に「開発者向け SaaS」を含めつつ、Windsurf 向けに明示的なサフィックスを足して漏れを防ぐ二段構えが扱いやすいです。以下は 例示です。proxy-groups 名や並び順は、既存の購読ルールと衝突しないよう調整してください。国内向けサイトを遠回りさせない GEOIP,JP,DIRECT などは、このブロックより上に置くか、誤マッチがないかログで確認します。
# Place ABOVE the final MATCH rule. Replace WINDSURF_PROXY with your selector or policy name.
- DOMAIN-SUFFIX,codeium.com,WINDSURF_PROXY
- DOMAIN-SUFFIX,windsurf.com,WINDSURF_PROXY
- DOMAIN-SUFFIX,codeiumdata.com,WINDSURF_PROXY
DOMAIN-SUFFIX,codeium.com は server.codeium.com や inference.codeium.com など多数のサブドメインをまとめてカバーします。社内ミラーだけ DIRECT にしたいホストがある場合は、より具体的な DOMAIN ルールを先に書いて優先させます。Mihomo／Clash Meta では Sniffer や GEOSITE と併用することも多いですが、SaaS のエンドポイントは増減しやすいため、公式の記載＋接続ログでの追記が保守しやすいです。負荷分散で load-balance を使う場合は、長めの HTTPS が途中で切れないノード選びが重要です。関連する考え方はload-balance の記事も参照できます。
Rule Provider に任せる場合の注意
第三者ルールセットに「Codeium」が含まれていても、バージョンやタグによってはサブドメインが不足していることがあります。特定メンバーだけ補完が止まるときは、Clash の接続ビューで実際の SNI を確認し、足りない DOMAIN-SUFFIX を追記してください。OpenAI 系の API プロキシという語彙で整理したい場合は、ホスト集合がベンダー固有である点に注意し、ChatGPT／OpenAI 向け記事とは対象を混同しないと運用が楽になります。
4 拡張マーケットと CDN：VS Code エコシステムの「第三の束」
Windsurf は VS Code ベースのため、拡張の検索・取得・更新は Visual Studio Marketplace や Microsoft が提供する CDN に依存します。Codeium 側のルールだけ整えても、拡張マーケットが DIRECT のまま不安定な経路に落ちていると、「本体は動くが拡張だけ入らない」「アイコンや README の画像だけ欠ける」といった症状が出ます。
代表的には marketplace.visualstudio.com、*.gallerycdn.vsassets.io、vscode.blob.core.windows.net などが挙げられます。チームで Open VSX をミラーとして使う場合は open-vsx.org や自前ホスト名が追加されます。運用ポリシー上、Microsoft ドメインを広く許可できない場合は、拡張をオフライン VSIX で配布するなど別ルートが必要になりますが、いずれにせよ マーケット層をルールから抜かさないことがポイントです。
5 エディタ設定：システムプロキシ検出と環境変数
Windsurf のドキュメントでは、ネットワークにプロキシがあるか確認し、システムプロキシの利用（検出）や手動設定を順に試す流れが案内されています。Clash をローカルの mixed ポート（例: 127.0.0.1:7890）に立てている場合、OS のシステムプロキシを有効化する方法と、シェルに HTTPS_PROXY／HTTP_PROXY を書く方法が併用されます。
VS Code 系は Chromium のネットワークスタックを使うため、システムプロキシを効かせるとエディタ内の HTTPS がまとめて安定しやすいです。一方、CLI の git やコンテナ pull まで含めて一本化したい場合は、TUN モードのガイドで仮想 NIC レベルの捕捉を検討してください。JetBrains 向けプラグインを併用する場合は、IDE 側のプロキシ設定と Windsurf の検出設定が食い違わないよう、公式の JetBrains 向け手順も参照するとよいでしょう。
企業環境では TLS インスペクション（自社 CA による復号）があり、証明書エラーで拡張の取得だけ失敗することがあります。Clash はトラフィックを転送するだけなので、失敗が TLS かタイムアウトかを切り分けると次の打ち手が明確になります。
6 DNS と FakeIP：名前解決をルールと揃える
ルールが正しくても、エディタが見ている DNS 答えと Clash が想定する解決経路がずれると、断続的に DIRECT へ落ちたり、期待しない地域の CDN に刺さったりします。Meta カーネル向け DNS／FakeIP の実務で述べているように、DoH と fake-ip の組み合わせを整え、国内ドメインと海外 SaaS を混在させない運用が安定の鍵です。
ノードを頻繁に切り替える運用では、古いセッションが残ってエディタ側だけ再接続に失敗することがあります。その場合は Windsurf の再読み込みや再起動を試し、並行して Clash のログで該当ホストが新しいアウトバウンドに載っているか確認します。Codeium 側のメンテナンスや地域ルーティングの変更が疑われるときは、公式ステータスやリリースノートもあわせて見ると切り分けが速くなります。
7 トラブルシューティング
- Web の windsurf.com は開くがエディタ内の AI だけ動かない：
codeium.comとcodeiumdata.comがルールで意図したポリシーに載っているか、DNS だけ別経路になっていないかを確認します。 - サインインループやトークン更新が終わらない：
windsurf.comと OAuth／Cookie まわりのサブパスがブロックされていないか、企業プロキシで Cookie が落ちていないかを疑います。 - 拡張の検索はできるがダウンロードで失敗： Marketplace と CDN（
gallerycdn.vsassets.ioなど）がDIRECTのまま不安定経路に落ちていないかを重点的に見ます。 - ETIMEDOUT／ECONNRESET： ノード品質や長连接の切断が多いです。セレクタで別サーバへ切り替え、同じ時刻に Clash ログで RST の有無を確認します。
- CLI は成功するが IDE だけ失敗： システムプロキシと環境変数のどちらが効いているかがズレている典型です。TUN で統一するか、IDE 起動シェルにプロキシを明示します。
8 まとめ
Windsurf は Codeium 系ドメインへの API・配信通信と、VS Code 由来の 拡張マーケット通信という、性質の異なる HTTPS ストリームに依存します。Clash 分流では DOMAIN-SUFFIX で codeium.com・windsurf.com・codeiumdata.com をまとめて意図したアウトバウンドへ載せ、マーケット層のホストを別途取りこぼさないようにします。公式セキュリティ／トラブルシュートの記載と接続ログで不足ホストを埋めるのが、2026 年時点でも再現性の高いやり方です。
システムプロキシと TUN、環境変数のどれを主軸にするかは、チームの端末ポリシーと開発フロー次第です。いずれにせよ DNS をルールと一貫させ、TLS エラーとタイムアウトを切り分けると復旧が速くなります。単機能プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、長時間のコーディングセッションには向きやすい場面が多いです。
Cursor や GitHub Copilot と並べてドキュメント化しておくと、チームのオンボーディングが楽になります。プロダクトごとにドメイン集合が異なることを前提に、記事を分けておくのがおすすめです。
