検索意図からみる四段階：registry → マーケット → MCP → モデル API
「Cline SDK インストール 遅い」「Cline CLI npm」「VS Code 拡張 更新 失敗」「MCP 接続 タイムアウト」「Claude API Cline 使えない」——これらは似た体感でもレイヤが異なります。第一段は registry.npmjs.org と tarball CDN への npm 依存取得。第二段は marketplace.visualstudio.com や *.vscode-unpkg.net など拡張機能マーケット／更新 CDN。第三段は Cline が呼ぶ MCP リモートサーバー（SSE や stdio ブリッジ先の HTTPS）。第四段は各プロバイダのモデル API——api.anthropic.com、api.openai.com、generativelanguage.googleapis.com など——への推論リクエストです。四段を頭に置けば、Connections 一覧に出ているのがどの層か切り分けてからルール増分へ進めます。
2026年5月の Cline SDK 公開以降、VS Code 拡張・JetBrains プラグイン・CLI が同じ SDK コアを共有するため、一度 npm で CLI を入れたあと IDE 側の拡張更新と MCP 設定を並行すると、失敗ログが複数レイヤに重なって見えます。まず再現したい操作をひとつに絞り（例：npm install -g cline だけ、または VS Code 内で Cline 拡張の更新だけ）、その時間帯の Clash ログだけを読むのが近道です。MATCH が意図せず直行に落ちていないか、GEOIP と名前ルールの順序も併せて確認してください。
ブラウザは速いが IDE とターミナルだけ不安定になりやすい理由
デスクトップブラウザはシステムプロキシに従いやすい一方、VS Code（Electron）の子プロセスや Node ベースの Cline CLI は、プロキシ解釈・証明書ストア評価が別系統だったり、GUI から起動した統合ターミナルに HTTPS_PROXY が引き継がれないことがあります。Mixed Port だけでは「標準環境変数を尊重しない」経路を拾えず、HTTP/3（QUIC）が UDP で抜ける構成もあります。Clash のTUN は下位レイヤで送出を拘束するため、npm・IDE・MCP クライアント・CLI のどれを叩いても一覧に同じ FQDN が載りやすく、分流ルールの効果を検証しやすいです。
名前の前段では DNS も強い論点です。fake-ip とルール評価の順序、別製品の DoH と Mihomo の同時オン、企業 MITM による証明書差し替えは、画面上は抽象的なタイムアウトのまま、一覧側には IP だけの行が増えるなどの痕跡を残します。WSL2 上で Cline CLI を動かす場合は Windows ホストの TUN と Linux ゲストのプロキシ設定が二重になりやすいので、検証コンソールの所在を先にひとつに寄せてください。詳細は WSL2 × Git と npm の記事 を参照すると短絡になります。
最初のひと叩き：RULE で TUN を確実にオンにする
製品ごとのクリック順は異なりますが、方針は共通です。RULE（ルール）モードでプロフィールがエラーなく読み込めることを確認し、TUN をオンにして macOS のネットワーク拡張／Windows のヘルパー承認まで完了させてください。初めて TUN を触る場合は Clash Verge Rev TUN モードガイド を先に通すと安全です。スタックは gvisor と system の選択が環境依存なので、TUN スタック比較記事 も併読するとよいでしょう。
運用ヒント：HTTPS_PROXY・TUN・システムプロキシを同時に強く入れないでください。TUN を先、不足分だけ環境変数を足す順がログを読むうえでも安全です。NO_PROXY に localhost と社内 LAN が入っているか毎回確認します。
フル機能 VPN と同居していると一覧が多重に見え理由が読めなくなるので、検証中だけ切り離す価値があります。TUN が OS 側でブロックされている端末では、Cline CLI を実行する同じシェルにだけ HTTP_PROXY／HTTPS_PROXY を export し、npm config set proxy で Node 層にも伝える二重運用が現実解になることもあります。
分流はログ優先：npm・VS Code マーケット・各社モデル API
固定リストだけに頼ると CDN 切り替わりで陳腐化するので、「失敗ログに名前が並んだときだけ増やす」が持続可能です。npm 側では registry.npmjs.org、npmjs.org、tarball 実体の CDN 名が典型。VS Code 拡張更新では marketplace.visualstudio.com、vscode-unpkg.net、場合によって open-vsx.org（JetBrains／VSCodium 系）も増えます。各社モデル API では api.anthropic.com、api.openai.com、generativelanguage.googleapis.com、OpenRouter 経由なら openrouter.ai などがログに現れます。これらを広い GEOIP,CN,DIRECT やデフォルト MATCH より手前に置き、手動で固定したいプロキシグループへマップします。
# Sketch: observe logs first, paste only what fails
rules:
- DOMAIN-SUFFIX,npmjs.org,PKG_PROXY
- DOMAIN-SUFFIX,visualstudio.com,IDE_PROXY
- DOMAIN-SUFFIX,anthropic.com,AI_PROXY
- DOMAIN-SUFFIX,openai.com,AI_PROXY
- DOMAIN-SUFFIX,googleapis.com,AI_PROXY
# Add MCP remote hostnames from Connections panel
ルールの「量」より「順序」が重要です。Clash Meta ルール順序と MATCH を理解し、頻出ホスト集合は Rule Provider にまとめてメイン設定を肥大化させないでください。Cline が複数プロバイダを切り替えるワークフローでは、url-test がセッション中に出口を変えて推論が途切れることもあるため、モデル API 用グループは更新頻度の低い手動選択に寄せる運用が安定しやすいです。
Cline と MCP リモートツール：接続先をログで確定する
Cline SDK は MCP サーバーを IDE／CLI から呼び出し、ファイル操作・ブラウザ・データベースなど外部能力を Agent に渡します。ローカル stdio 型 MCP はルーティングに関与しませんが、リモート SSE やクラウド上の MCP ブリッジは別 FQDN への HTTPS になり、npm 用ルールだけでは足りません。拡張の MCP 設定画面に表示される URL のホスト名を、Cline 実行中の Connections 一覧と突き合わせ、不足分だけ分流へ追加してください。MCP 全般の切り分け論点は MCP × Clash 分流・DNS 記事 が詳しいです。
MCP とモデル API が同時に失敗する場合、四段階のうちどちらが先に詰まっているかを時間軸で分けます。MCP だけ成功して推論だけ止まるなら第四段（各社 API）、npm は通るがツール呼び出しだけ失敗なら第三段——という切り方が再試行コストを下げます。WebSocket や長時間 SSE を使う MCP 実装では、途中でプロキシグループが自動切替しないよう、MCP 用ホストを専用グループに分離するのも有効です。
DNS と Fake-IP：TUN の内外で評価を同期させる
ルールに DOMAIN を書いても DNS モジュールが別経路だと、「命中したように見えて実送信が分叉」する静かな失敗が起きます。Meta コア DNS 漏洩防止ガイド と fake-ip-filter 記事 を参照し、FakeIP モードではローカル域・社内管理域を fake-ip-filter に入れ、nameserver-policy を使う場合はルールに現れるホストと整合させてください。ドメイン別 DoH の書き方は nameserver-policy ガイド が参考になります。
npm：registry・strict-ssl・グローバル CLI 導線
npm config get registry と npm config list -l で「いまのシェルの実ソース」を確認します。社内 mirror や未同期の地域 mirror を指していると、メタデータは取れるが tarball が引けない中途半端な状態になります。npm ping や npm view cline version --json（パッケージ名は公開名に合わせて読み替え）で軽くプローブを打ち、Connections と TLS の成否を同時に見ます。企業 Nexus ではパブリック出口ノードと混在させず、TLS と監査ポリシーが合う専用グループへ分離してください。
# Minimal probes before full install
npm config get registry
npm ping
curl -Iv https://registry.npmjs.org/
curl -Iv https://api.anthropic.com/
strict-ssl と企業根証明書の不一致は「タイムアウト」に見えることがあります。TUN と npm レベル proxy が二重に効いていないかも確認し、必要なら npm の proxy 設定を空にして TUN に一本化する選択肢も検討します（社内が明示 upstream を強制する場合は IT 方針優先）。pnpm／yarn 混在ワークスペースでは lockfile 側の registry URL が二重になりやすい点にも注意してください。
VS Code 拡張マーケット：Cline 更新の第二段
Cline を VS Code 拡張として使う場合、SDK 移行後の更新チェックは marketplace 系ホストへ独立した HTTPS 連鎖を張ります。ブラウザで marketplace.visualstudio.com が開けても、Electron 内の更新クライアントが別経路のままだとスピナーが止まらないことがあります。Windsurf 拡張マーケット記事 と同様、ログに載った CDN 名だけを増分し、拡張更新と npm CLI 導入を同時に試さない方が切り分けやすいです。JetBrains 系では Marketplace 以外の配信 URL が増えることもあるため、Connections を正とします。
再現ワークフロー：迷わない並び順
- RULE でプロフィール読み込みとダッシュボード異常なし。
- 再現操作をひとつに絞る（npm グローバル導入／VS Code 拡張更新／MCP 接続／モデル推論のいずれか）。
- TUN オン〜権限確認〜同じシェル／同じ IDE から再試行〜一覧増分を読む。
- ログにだけ現れた FQDN を
DOMAIN-SUFFIXで増やし、MATCH 手前評価を確認。 - DNS（fake-ip、DoH 競合、stack）を独立点検。
- npm registry／
.npmrc／環境変数をこのセッションだけで読む。 - MCP URL と Cline プロバイダ設定（API キー・ベース URL）を突き合わせ、第四段のモデル API まで再走。
注意：TUN とプロフィール変更が契約・学校・社内規程と衝突する場合があります。許可されていないときはインフラ窓口の案内に従ってください。
よくある質問
ウェブでも npm と各社 AI が開けるのに Cline の npm だけ止まります。
ブラウザと Node／Electron の経路・証明書評価差です。TUN で名前付き一覧を先に読める状態へ寄せ、registry と tarball のどちらで止まっているか切り分けてください。
SDK は入ったが MCP ツールだけタイムアウトします。
リモート MCP の FQDN が分流に未登録、または SSE／WebSocket が途中で切断されている可能性があります。Connections で MCP 接続先だけを増分し、MCP 向け記事 の DNS→ルール→ログの順も参照してください。
Anthropic は通るが OpenAI／Gemini だけ Cline 内で失敗します。
プロバイダごとに API ホストが異なり、片方だけルールに載っていない典型パターンです。失敗した推論リクエストの時間帯のログ diff で不足 suffix を追加し、url-test による出口自動切替も疑ってください。
まとめ
2026年5月の Cline SDK 公開で VS Code・JetBrains・Cline CLI が一本化される一方、詰まりは npm registry・拡張マーケット・MCP・各社モデル APIの四段に分散しやすく、ブラウザとの経路非対称に見えるだけになりがちです。Clash のTUN で IDE とターミナルプロキシを拘束し、Connections をソースに分流ルールへ反映、DNS と npm 実値を並べれば、体感の大半はここで滑らかになります。シェルごとに proxy URL を手コピーする暫定運用より、一覧とルール評価を揃える GUI クライアントの方が再現性が高いです。試すなら 無料で Clash をダウンロード のうえ、TUN ガイドを先に通し、最小 curl プローブで四段それぞれを独立検証してください。競合 CLI だけの手書き YAML 長期運用は疲弊しやすく、ログ付き製品側に寄せるほど Cline 移行期のトラブルも追いやすくなります。