この記事で分かること

2026 年時点で、AI IDE の競争は「ローカル編集」だけではなく、クラウド側の推論や補助 API、エージェント的なワークフローまで一体になって評価されます。検索の現場では「Windsurf」「Cascade」「落ちる」「API」「タイムアウト」「HTTPS_PROXY」「プロキシ」「ルール分流」といった語が並び、体感としてはブラウザや一般サイトは通るのに、IDE だけクラウドモデルが細かく切断される、あるいは長い応答だけ失敗するといった切り分けが増えています。

本稿はデスクトップ向け Mihomo／Clash Meta 系 GUI のひとつである Clash Verge Rev を前提に、(1) API 分流として Rule で外向きホストを意図したアウトバウンドへ送る、(2) OS のシステムプロキシと IDE 内プロセスの参照経路のズレを減らす、(3) 統合ターミナルや CLI へ HTTPS_PROXY／HTTP_PROXY／NO_PROXY をどう渡すか——を、ログと curl を軸にした実測の流れでまとめます。別の AI IDE で同種の症状を扱う場合はCursor 3 向けのクラウド Agent／ブラウザツール記事や、CLI 中心の切り分けはCodex CLI 向けガイドとあわせて読むと、用語と手順の対応が取りやすいです。Verge Rev の基本操作はチュートリアルを参照してください。

検索意図と症状：Cascade とクラウドモデル

Windsurf の Cascade を使う構成では、次のクリティカルパスで「ネットは生きているのに IDE だけ不調」に見えやすく、キーワードと対応させて整理できます。

  • チャットや補完は短く通るが、長い推論やツール連鎖で止まる：ストリーミングや再接続が特定ホストに張り付き、そのホストだけ DIRECT に落ちている、Keep-Alive の向き先が分散している、ノードの揺らぎが乗る——など、TLS 以前または途中ホップの問題が混じります。
  • GUI では成功するが、統合ターミナルのみ失敗：シェルが HTTPS_PROXY を読まない、別のプロファイルしか読んでいない、コンテナやサンドボックスがネットワーク名前空間を分けている——といった環境変数レイヤの欠落が典型です。
  • 外向き API だけ不安定：ブラウザと IDE の HTTP スタックが別で、片方だけシステムプロキシを見てもう片方が直結している——といった経路の二重化が起きやすいです。
  • 成功と失敗が交互（フラッピング）：複数 VPN、ゼロトラストクライアント、社内 DNS の Split horizon が重なると、同一マシン内でも名前解決と実経路が揺れます。

いずれも「回線が完全に死んだ」より、HTTPS クライアントが期待したプロキシ列に乗っていない比率が高いです。Clash Verge Rev のログで一行ずつ追えることは、説明責任のある運用では大きな利点になります。

AI IDE の表示層とバックエンド呼び出しのズレ

同じマシンでも、デスクトップアプリの UI、埋め込みビュー、言語サービス、ターミナルは参照するプロキシ設定が完全一致しないことがあります。GUI は OS のシステムプロキシを先に見る一方、多くの CLI や一部ランタイムは HTTPS_PROXY と NO_PROXY に強く依存します。

このズレは「Windsurf を使い始めたあとだけ Cascade が細かく切断される」「一般ブラウザでは問題ないのに IDE 内だけ ETIMEDOUT」という体感として現れやすいです。ターミナルで env | grep -i proxy を確認し、API 分流のログと突き合わせるのが早いです。

クラウド推論と外向き API を同じ頭で扱う

Cascade のようなクラウド連携は、短時間に「モデル推論」「認可」「テレメトリ」「補助ドメイン」の HTTPS が走ります。ルール分流では次の二層に分けると事故が減ります。

  • 内向き（そのマシン上）：127.0.0.1／localhost は意図的に DIRECT。NO_PROXY に明示し、誤ってプロキシへ流すと往復が増えてレイテンシだけが跳ね上がります。
  • 外向き（プロバイダ側）：ログに出たドメインを DOMAIN または妥当な DOMAIN-SUFFIX で PROXY に寄せ、MATCH より上へ置きます。

「AI IDE の更新で急にホストが増えた」場合も、固定リストより失敗直後のログ行をソースにしたほうが再現性が高いです。

Rule を軸に、TUN は補助として使う

ルール分流は、社内 Git や金融系ドメインを DIRECT に残しつつ、クラウド推論や一般 API を PROXY へ送る第一選択です。YAML の順序とログを突き合わせれば、「どのホストがどのポリシーへ落ちたか」をテキストで説明できます。

TUN はプロキシ変数を無視するバイナリでも一度 Mihomo 側へ引き込める強力な手段ですが、他社 VPN や仮想 NIC と競合しやすいです。実務的には、(1) Rule とシステムプロキシで足りるか試す、(2) 特定プロセスだけの問題なら限定的に TUN、(3) 常時フル TUN は最後の手段、の順が安全です。

Clash Verge Rev では「システムプロキシをセット」「TUN を開始」が別操作のため、ブラウザだけ整備されターミナルが裸、という分岐に注意してください。

HTTPS_PROXY を中心にしたターミナル向け環境変数

Windsurf の統合ターミナルから外向き API を叩く場合、GUI よりも環境変数の比重が大きくなります。典型的には次を揃えます。

  • HTTPS_PROXY：HTTPS への CONNECT が主用途なら最優先。
  • HTTP_PROXY：リダイレクト先行の HTTP フェーズで参照されます。
  • ALL_PROXY：単一変数しか読まないツールへの保険（無視されることもあります）。
  • NO_PROXY：localhost、127.0.0.1、社内 SSO を除外し、ローカル待受とのループを防ぎます。

値は多くの場合 http://127.0.0.1:<mixed-port> で足り、TLS は CONNECT でトンネルします。書き場所の例は ~/.zshrc、~/.bashrc、リポジトリの .envrc、あるいは検証時のみのコマンド前置きです（ポートは各自のプロファイルに合わせて読み替え）。非ログインシェルだけが読む設定ファイルに書いてしまい、統合ターミナルに届かない、という落とし穴には注意してください。

ルールへ載せるホストはログ実測を優先

ネット上に転がる古いドメイン表は保守コストが高く、サービス側変更で陳腐化します。検索で繰り返し見かける型としては次を出発点にし、実名はログで上書きしてください。

  • プロダクト提供元の認証・課金・配布：HTTPS の証明書名（SNI）とホストが一致していることをログで確認します。
  • クラウド推論やモデル API：設定で選んだプランに応じたホスト（利用規約と社内規程を確認のうえ）。公式ドキュメントの更新日と突き合わせると安全です。
  • CDN・解析補助：Cascade が内部的に追加するホストは、エラー直後の一行ログから拾うのが最短です。

エラーメッセージに出るホスト名は、ブログ本文の一般的な列挙よりログに出た実名のほうが信頼できます。API 分流をチームで共有する際も、スクリーンショットよりログ行を貼るほうが再現性が高いです。

TIP：一度だけGlobal に近いプリセットで同じ操作を試し、症状が消えるかを見てください。消えるなら DIRECT 落ちのルール順が本命で、MATCH より上へ個別 DOMAIN を挿入しやすいです。

ルール記述例（ポリシー名は各プロファイルに合わせる）

以下は Mihomo／Clash Meta 互換の説明用スニペットです。PROXY を利用中のポリシーグループ名へ置換し、既存の MATCH より上に置いてください。実ホスト名は Verge Rev のログからコピーし、下のコメント行を置き換えます。

# Example rules snippet — replace PROXY with your policy group name
rules:
  # Paste DOMAIN / DOMAIN-SUFFIX lines from Verge Rev logs (Cascade / API)
  # - DOMAIN,example-cascade-api.example.com,PROXY
  # Keep local endpoints on DIRECT via explicit rules or NO_PROXY

広すぎる DOMAIN-KEYWORD は誤爆しやすいので、ログに出た実名を DOMAIN で足す運用を推奨します。

ステップ：Cascade のクラウド経路を安定させるまで

  1. Clash Verge Rev が期待するプロファイルで起動済みであり、mihomo が待ち受けていることを確認します。
  2. 通常のブラウザで同じノードを用いた外向きサイト疎通を見て、問題がAI IDE／Cascade 限定かを切り分けます。
  3. 切断やタイムアウトの再現直後にログからホスト名を拾い、API 分流ルールを追加します。fake-ip とルール種別の組み合わせでマッチがズレていないかも見ます。
  4. OS のシステムプロキシと Verge Rev の設定が矛盾していないか確認し、必要なら「システムプロキシをセット」をやり直します。
  5. 統合ターミナルで動くツール向けに、新しいシェルセッションで HTTPS_PROXY と HTTP_PROXY を export してから同じ操作を繰り返します。
  6. 問題の URL へ curl -vI を送り、Clash 側で意図したチェーンに乗ったかを確認します。
  7. 個別バイナリが依然として直結する場合は TUN を試す前に、HTTPS インスペクションや別 VPN のスタック競合を疑います。

検証のコツ：状態を一元化する

「設定した HTTPS_PROXY」が統合ターミナルに届かないときは、非ログインシェル、タスクランナーのサンドボックス、コンテナのネット命名空間などを疑います。

  • 同一ホストで curl と IDE が別結果：curl は変数が効いており IDE 内だけ無視しているなら、そのランタイムのドキュメントで代理関連の環境名やフラグを確認します。
  • IPv6 と IPv4 の分裂：curl -4 でのみ通るときは DNS か経路が二系統化しています。
  • 社内 Split DNS：機密系は NO_PROXY に残し、外部 API だけ PROXY —— の二段にすると開発者端末での事故が減ります。
注意：コードやログをクラウド推論へ送る操作は、利用規約と会社の情報セキュリティポリシーに触れることがあります。ネットワークが安定しても、アップロード可否は別判断です。
ダウンロードページへ

トラブルシューティング

症状：UI は動くが Cascade だけ途切れる

想定原因：長めのストリームや再接続が特定ホストに張り付いており、そのホストだけ DIRECT または不安定なノードに落ちている。

対処：ログでホスト名を特定し DOMAIN ルールで固定。ノードを差し替え、DNS と fake-ip の組み合わせを確認します。

症状：curl は成功するが IDE 内ツールだけ失敗

想定原因：埋め込みビューやサブプロセスがシステムプロキシと異なる経路を見ている、証明書検証まわりでプロキシが二重化している。

対処：OS プロキシと Verge Rev の設定を再適用。社内検査プロキシと Clash の二重構成になっていないか確認します。

症状：ローカルの補助サービスだけ不安定

想定原因：ローカル待受が NO_PROXY に入っていない、または誤ってプロキシへ流している。

対処：127.0.0.1 系を除外し、外向きだけルールを厚くする。セキュリティソフトのローカルループ制限も確認します。

よくある質問

Cascade だけクラウドモデルがタイムアウトするのはなぜですか？

UI 層と長時間ジョブ層で参照するプロキシ設定や DNS が一致しないためです。Clash Verge Rev のログで DIRECT 漏れを潔し、Shell に HTTPS_PROXY を揃えてください。

外向き API 通信も同じルールで足りますか？

外向きドメインはログの実名を載せ、ローカル待受は除外する二段構成が安全です。固定リスト任せにしないでください。

HTTPS_PROXY はどこに書けばよいですか？

常時ならログインシェル設定や direnv、単発検証ならコマンド前置きのみ。副作用を限定するのがポイントです。

単一製品 VPN との比較で見える Clash の利点

ワンタップ型の商用 VPN は初期導入が楽でも、ドメイン単位の細かな例外やログでの逆引きには向きにくいことがあります。開発者ワークステーションでは、社内 Git だけ直結できない、AI IDE の Cascade だけ別経路で詰まる、ターミナルだけ API が直結する——といった摩擦が出やすいです。Clash 系は本文のとおりルール分流とログで API 分流を説明できるため、Windsurf と社内サービスを同じ端末上で両立させるほうが現実的になります。

フロントエンドは好みで選べますが、Verge Rev はプロファイル編集とログ監視が近接しており、エディタとターミナルを行き来する検証とも相性がよいです。大手 VPN の「すべて同じ出口」に比べ、詰まった場所をドメイン粒度でほどける点が長期的な運用リスクを下げやすいです。

無料で Clash を入手し、Windsurf Cascade 向けの分流と検証を試す →