単独ターミナルで「ログインだけ」「AI だけ」が壊れやすい理由

Warp のようなネイティブ端末は、シェルセッションそのものをローカルで持ちながら、認証まわりや AI の応答生成はクラウド側と長めの HTTPS／WebSocket 相当の対話で繋がります。このとき UI のコードやフォント、アニメーション付きのコンポーネントが静的 CDN から届き、OAuth のリダイレクトやトークン検証は別ドメインへ飛ぶことが珍しくありません。結果として「ウィンドウは立ち上がったのにログイン完了しない」「ログイン後も質問送信だけスピナーのまま」といった症状は、製品バグというよりホストごとの出口がバラバラになっているときに起きやすいタイプです。

Docker や CLI を mixed-port で通す記事でも触れているとおり、ターミナル系アプリは OS のシステムプロキシに従う場合と、環境変数の HTTPS_PROXY だけ見る場合が混在します。Warp がどちら側を優先するかはプラットフォームと版次第ですが、Clash 側で名前ベースの分流が破綻していると、アプリは「半分だけつながった」状態で止まります。対処の第一歩は推測ではなく、失敗しているホスト名の列挙です。

ℹ 観測のコツ： OS のファイアウォールログ、Clash の接続ビュー、可能ならプロキシ直下での TLS 切断コードをメモします。warp.dev だけプロキシへ送り、OAuth のコールバック先だけ直結残り——というパターンは「ログインだけ終わらない」典型です。

Cursor／Copilot／Windsurf 記事との違い：経路のレイヤ

IDE の拡張エコシステムでは、マーケット・GitHub・ベンダ API が別レイヤになります。Windsurf と Codeium の分流記事が扱うのはその典型です。対して Warp は単体バイナリのターミナルであり、VS Code のワークスペース内プロセスというよりデスクトップ常駐アプリに近い経路を取ります。したがって「エディタの拡張だけルールを足せば足りる」と限定できず、認証ブラウザ／埋め込み WebView／静的 CDN／AI APIのどこが別出口になっているかを個別に見る必要があります。

ルールの読み方自体は共通で、ルール分流のベストプラクティス に沿って上から最初の一致を前提に組み立てます。広い GEOIP や巨大な RULE-SET が、細かい Warp 向け行より上にあると、意図しない DIRECT／別ポリシーへ抜けます。細かいドメインほど前列に明示行を置くか、巨大セットの挿入位置を見直してください。

分流の核：WARP_AI（相当）へ束ねる

実務では WARP_AI のような専用ポリシーグループを置き、少なくとも warp.dev を核にした公式サービス系ホストをすべてそこへ送るのが素直です。DOMAIN-SUFFIX,warp.dev,WARP_AI 一行でサブドメイン広がりをまとめられる場合が多い一方、認証で第三者 IdP にリダイレクトされると、そのホストも同じグループへ載せないとOAuth の往復が途中で別経路になります。業務ポリシー上プロキシを強制したい場合でも、まずは観測されたホスト集合をそのまま束に写すのが安全です。

ノードが細い・不安定だと、テキストよりストリーミング応答が先にタイムアウトに見えます。timeout と TLS のログ読みとセットで、握手前後どちらで止まっているかを分けます。またクライアント選定は クライアントの選び方 を参照し、接続ログがそのまま確認できる GUI を優先すると復旧が早くなります。

OAuth・CDN・API をログと開発者ツールで観測する

OAuth は実装ごとにホストが増減するため、静的な「完全リスト」を前提にしない方がよいです。ログイン試行のたびに現れたFQDN をメモし、同じストラテジへ寄せます。UI のバンドルやフォントが *.cloudfront.net、*.fastly.net のような CDN 接尾辞になっている場合、その行だけ別ポリシーへ落ちていると画面は描画されるのに操作だけ詰まったように見えます。許可された環境では、一時的に該当 CDN を WARP_AI に寄せて比較し、症状が消えるかで因果を切り分けます。

AI の質問応答が別系列の API ドメインへ伸びている場合も同様です。ChatGPT／OpenAI 分流で整理した「名前空間が増えるほど漏れが出る」問題が、別ベンダのエンドポイントでも繰り返されます。プロファイルには観測ベースの追補行を残し、ルールプロバイダの更新だけに依存しない運用が長期では楽です。

システムプロキシ・TUN・CLI の環境変数のずれ

macOS や Windows では「システムが見ているプロキシ」と「シェルが見ている環境変数」が食い違うことがあります。Clash をシステムプロキシモードで公開しているのに、Warp がプロセス独自の設定で直結している——というケースは、アプリ側設定や企業デバイス管理と組み合わさると発生します。取りこぼしをルーティング表レベルで揃えるなら TUN が有効です。導入手順と副作用は TUN の詳解 にまとめています。

逆に TUN を避ける方針なら、Warp が参照するプロキシ設定と Clash の mixed-port／socks-port を数値が一致しているかを再確認します。ここがずれると「curl は通るがアプリだけ不通」になりがちです。

DNS／fake-ip・ルール順と広い RULE-SET

fake-ip を使う構成では、ブラウザやランタイムが受け取る IP と、実際にプロキシが接続するときの名前解決経路が分離されます。ドメインルールが後追いできていないホストだけ別ストラテジへ落ちると、「名前解決は成功したのに TLS が進まない」という見え方になります。Clash Meta の DNS で nameserver／fallback／fake-ip-filter をルール設計と揃えてください。

またルールは宣言順がそのまま優先度です。広いブロックリストや広域 GEOIP が先頭だと、細かな Warp 行が永遠に評価されません。FAQ の接続性セクション と併せ、「どの行に命中したか」をログで確認するクセをつけると迷走が減ります。

記述例：DOMAIN-SUFFIX とルールプロバイダ

以下はあくまで説明用の断片です。実際の IdP や CDN は環境ごとに異なるため、丸写しではなく自分のログに出た名前へ差し替えてください。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,warp.dev,WARP_AI
  # Append OAuth / CDN hosts you observe (examples only — verify on your network):
  # - DOMAIN-SUFFIX,accounts.example-idp.com,WARP_AI
  # - DOMAIN-SUFFIX,cdn.example-static.net,WARP_AI
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

RULE-SET を併用するときは、ローカルの明示行とセットの読み込み順に注意します。セットが OpenAI／GitHub など広いカテゴリだけを持ち、Warp 周辺が欠けている場合は、ローカル追補が効きます。

⚠ コンプライアンス： サービス利用規約と職場ポリシー、適用法を守ってください。本文は許可されたネットワーク上での経路調整の説明であり、保護されたサービスへの不正アクセスを助長する意図はありません。

許可環境での自己チェックリスト

次を上から順に潰すと、設定の総入れ替えより早く収束しやすくなります。

  1. 対象組織で Warp とプロキシ利用が許可されていることを確認する。
  2. ログイン失敗時・AI 応答停滞時に現れたFQDN を列挙する。
  3. 各ホストが Clash ログ上でどのポリシーに命中したかを記録する。
  4. warp.dev と OAuth／CDN／API を同一ポリシーへ寄せ、広い RULE-SET が先に奪っていないか確認する。
  5. システムプロキシ・TUN・環境変数の三組み合わせで挙動を A/B する。
  6. DNS と fake-ip がルールと矛盾していないか確認する。
  7. ノードを安定したチェーンに切り替え、ストリーミング応答の途中切断が消えるか比較する。

まとめ

Warp は IDE 内ツールとは異なり、単独ターミナル＋クラウド AI というスタックで経路が複数レイヤに分かれます。warp.dev 本体・OAuth・CDN・推論 API が別出口になった瞬間にログインや AI 応答だけが壊れて見えるので、Clash ではそれらをWARP_AI のような同一ポリシーに束ねるのが基本戦術です。分流の作法は ベストプラクティス に揃え、DNS とルール順を同じ設計言語で読むと再現のないスピナーを減らせます。

グローバルオンリーへの逃避より、ログで炙ったホスト集合をプロファイルに載せる運用のほうが、バージョンアップ後も保守しやすくなります。

→ 無料で Clash をダウンロードし、ターミナルでの試行錯誤をネットワーク経路のブラックボックスに費やさず、本来の開発タスクへ時間を戻してください。