なぜ「開発用トラフィック」だけ別ポリシーに分けるのか

プロキシは一つの出口にまとめても動きますが、開発者ワークフローでは次の理由で npm や Cursor 向けにだけ別のポリシーグループ を用意したくなることが多いです。第一に、レジストリ（例：registry.npmjs.org）やミラー（国内・社内）への経路は、一般のブラウジング用ノードと同じ品質とは限らないこと。第二に、エディタの 拡張機能マーケットプレイス や更新 CDN はホストが分散しており、購読ルールの MATCH 任せだと「一部だけ意図しない DIRECT／別ノード」に寄ることがあること。第三に、CI やコンテナ、社内プロキシと 環境変数（HTTP_PROXY など）が絡むと、ホスト OS の Clash とターミナルの見え方がずれ、同じコマンドでも経路が違う という混乱が起きやすいことです。

ここで押さえるべきは、Clash のルールは 上から順に最初の一致だけ が有効になる、という基本です。開発者向けの行を、広い GEOIP や MATCH より 上 に置く。例外としてローカルやイントラを直結させたい場合はさらに上、という順序が崩れると、画面では成功に見えて実際は別経路、という事象が起きます。分流の骨格（proxy-groups、RULE-SET）そのものは Clash YAML ルール分流ガイド で扱っているので、本稿ではそこを前提に IDE／npm チェーンに絞った追記 として読んでください。

npm・pnpm と Cursor で意識したいドメインとレジストリ

まず npm のデフォルトは registry.npmjs.org です。pnpm も同じレジストリを指すことが多く、チームで .npmrc を共有している場合は registry= が社内 Verdaccio や国内ミラー（例：registry.npmmirror.com など）に置き換わっていることがあります。いずれにせよ「実際に npm install や pnpm install が叩いているホスト名」は、設定ファイルとロックファイルの時代 で変わるため、迷ったらクライアントのログやプロキシログに出る 接続先ホスト を一次情報としてください。

Cursor は VS Code 互換をベースにしており、拡張取得や更新、一部のオンライン機能で open-vsx.org や Microsoft 系 CDN・API に触れることがあります（利用形態やバージョンで変化します）。また AI 補完やチャット連携では、OpenAI や別プロバイダ向けのホストが追加されるため、「IDE の更新」と「AI 機能」は別バケツ に分けてルールを考えると整理しやすいです。AI 側のドメイン切り分けは OpenAI 向け分流の記事 と組み合わせると、ポリシーの責務が重なりません。

DOMAIN-SUFFIX でまとめるとき DOMAIN-SUFFIX,nodejs.org のように広く取ると、意図しないサブサービスまで同じ出口に乗ります。必要なホストがログで確定するまでは、まず DOMAIN で足し足しにするほうが安全な場合があります。

ポリシーグループ：「DEV-EXIT」と汎用を分ける

実装の一例として、汎用の出口（例：PROXY）と、レジストリとパッケージ取得に使うグループ（例：DEV-EXIT）の二層がわかりやすいです。DEV-EXIT は select でレイテンシの良いノードに固定するか、url-test で自動選択するかはチーム方針次第です。さらに Cursor 本体の更新だけ別グループ（IDE-EXIT）に分けるかどうかは、運用の細かさと YAML の複雑さのトレードオフになります。最初から細かくしすぎず、詰まっているホストがログで見えてから グループを増やすのが現実的です。

コアのプロトコル対応や挙動差で詰まる場合は、Clash Meta（mihomo）コアのアップグレード も視野に入れてください。TLS の握りや長時間接続まわりは、クライアントとコアの組み合わせで差が出ます。

proxy-groups:
  - name: "DEV-EXIT"
    type: select
    proxies:
      - "node-low-latency-1"
      - "node-stable-2"
      - "DIRECT"
  - name: "PROXY"
    type: url-test
    # ...

ルール例：レジストリと IDE 系を DEV-EXIT へ（たたき台）

以下は たたき台 です。実際の購読プロファイルでは、これらの行を GEOIP や MATCH より上に置き、ポリシー名を自環境に合わせて置き換えてください。npm のデフォルトレジストリと、よく使われるミラー例を並べたイメージです。

rules:
  - DOMAIN,registry.npmjs.org,DEV-EXIT
  - DOMAIN,registry.npmmirror.com,DEV-EXIT
  # Add marketplace / CDN hostnames you see in logs, e.g.:
  - DOMAIN-SUFFIX,openvsx.org,DEV-EXIT
  # Then generic rules (GEOIP, MATCH, ...)

RULE-SET や購読ルールが先にマッチしてしまう場合は、開発者向けの行をその より上 に移すか、購読側の順序設計を見直します。細かく書きすぎてメンテが大変なら、信頼できるセットに任せつつ、末尾に 自分用の追記だけ を足す方法も有効です（Rule Providers の詳細は YAML 分流ガイド を参照）。

ターミナルと環境変数

npm や pnpm をターミナルから実行するとき、システムの HTTP_PROXY／HTTPS_PROXY と Clash の TUN／システムプロキシ が二重に効いて、意図しない経路に出ることがあります。「Clash では分流しているのに CLI だけ別」というときは、そのプロセスがどのプロキシ設定を見ているか を確認してください。社内スクリプトが固定でプロキシを指定している場合もあります。

TUN・システムプロキシとローカルループバック／イントラの回避

TUN モード はアプリのトラフィックを広く取り込めますが、その分 ローカル開発サーバー（127.0.0.1 や localhost）や 社内のプライベート IP への接続まで巻き込み、想定外の遅延や接続失敗の原因になり得ます。典型例は、フロントの dev サーバーが localhost:5173 で動いているのに、ブラウザやツールの通信がプロキシ側の解釈でループしない、証明書が合わない、といった症状です。

対策の考え方は次のとおりです。第一に、クライアントの bypass／除外 設定（ローカルホスト、プライベート帯、カスタムドメイン）を確認し、127.0.0.0/8 や 10.0.0.0/8 など、開発で触れる帯を プロキシに乗せない ルールを明示する。第二に、Clash のルールで IP-CIDR や GEOIP よりも 上位に「ローカル・イントラは DIRECT」を置く設計にする。第三に、fake-ip や DNS の扱いによっては、名前解決の見え方が変わるため、症状が出たらログで 実際に解決された IP とマッチしたルール を追う。

社内ポリシーとセキュリティ イントラや社内レジストリを直結させる設定は、組織のネットワーク規定に照らして許可された範囲で行ってください。本稿は技術的な整理にとどまります。

モバイル環境では Clash for Android など、端末固有の権限や省電力の影響で PC と別症状が出ることもあります。分流ルールが正しくても、端末側でトラフィックがプロキシに乗っていないケースを忘れないでください。

よくある詰まり：証明書、DNS、ストアまわり

設定を入れても npm／pnpm が遅い・失敗する とき、次の観点で切り分けると迷子になりにくいです。

  • TLS／証明書エラー：企業のスキャン用プロキシや独自 CA が挟まっている環境では、Node が証明書を信頼しない場合があります。これは Clash の分流以前に、OS や Node の trust store の問題であることが多いです。
  • DNS の見え方：ドメインルールは名前と IP の組み合わせで挙動が変わる場合があります。fake-ip や nameserver-policy を使っている場合は、想定と違う解決になっていないかログで確認します。
  • レジストリの切り替え忘れ：.npmrc でミラーに向いているつもりが、プロジェクトローカルの設定で上書きされている、など複数レイヤの設定が衝突することがあります。
  • pnpm のストアやリンク：グローバルなストアパスやハードリンクの挙動は、ファイルシステムと権限に依存します。プロキシとは無関係なエラーも混ざるため、エラーメッセージの全文をまず読むのが近道です。

いずれの場合も、Clash クライアントのログで どのルールにマッチしたか を確認するのが最短です。「DEV 向けの行を足したのに変わらない」場合は、より上の行で既に一致している か、別ホスト名に向いている かのどちらかであることが多いです。

まとめ

2026 年の開発現場では、AI エディタ と npm／pnpm による依存取得がセットで体験を決めます。Clash でこれを快適にする鍵は、ログに出る ホスト名とレジストリ を確認し、ルール分流 で 開発者向けポリシーグループ を切り出すこと、そして TUN・システムプロキシ 利用時に ローカルループバックとイントラ を誤って巻き込まないことです。OpenAI 系の Web／API 向けに書いた ChatGPT／OpenAI API の分流 と役割が被らないよう、本稿では IDE とパッケージチェーンに絞りました。合わせて読むと、開発環境全体の出口設計がしやすくなります。

同じ Clash 系ツールでも、GUI の見え方やコアの組み合わせで迷いがちです。クライアントの選定や入手は ダウンロードページ からまとめて確認でき、長く使うほど「自分用の分流ノート」を YAML に少しずつ足していくのが、最も確実な運用になります。

→ Clashを無料ダウンロード — Meta コア対応の各クライアントを比較し、自分の環境に合うものから試せます。

関連：YAML ルール分流の全般、ChatGPT／OpenAI API 分流、技術コラム一覧。