Windows で npm・pnpm を Clash 経由にする：HTTP_PROXY と国内レジストリ直結の分流（2026）

1. 解きたい課題：システムプロキシだけでは足りないことがある

Windows の「設定」アプリでシステム全体のプロキシをオンにすると、多くのブラウザや Store 系は追従しますが、ターミナルから起動する Node プロセスが必ずしも同じスタックを参照するとは限りません。特に npm や pnpm は libcurl 相当の実装や独自の HTTP スタックを介して接続するため、GUI でオンにしただけでは未設定のままというケースが珍しくありません。目的は明確で、「開発用シェルにだけ」プロキシ環境変数を載せ、出口は常に本機の Clash に寄せることです。こうしておけば、レジストリのホストごとに Clash 側のルールで DIRECT と代理を切り替えるという二段構えが現実的になります。

コンテナや WSL2 からホストの Clash を見に行く話は、当サイトの Docker をホスト Clash 経由にする記事や WSL2 から Windows の Clash へ向ける記事と住み分けできます。本稿はネイティブ Windows 上の PowerShell／CMD／Windows Terminalにフォーカスします。IDE 周りのドメイン束ねは Cursor 向け分流の記事と補完関係にあります。購読やルールの基礎は サブスクリプション導入と ルールルーティングの解説をあわせて読むと、どの策略に tarball 取得が乗るかも追いやすくなります。

2. Clash 側の前提：ポート・bind・allow-lan

Verge Rev や他の GUI ラッパーでも中身は mihomo／Meta 系の設定が多く、mixed-port に HTTP と SOCKS が同居している構成が一般的です。npm 系は HTTP プロキシ（CONNECT）で十分なことが多いので、まずは http://127.0.0.1:ポート が応答するかを確認します。説明の便宜上ここでは 7890 を仮置きしますが、実際の値はダッシュボードの表示に合わせて読み替えてください。

bind-address が 127.0.0.1 のみだと、同一マシン上の別名前空間からは届きません。本稿の想定はループバックからの接続なので通常は問題になりにくいですが、LAN 越しに別端末から同じポートを使う実験をするなら allow-lan とバインド先の見直しが必要です。Windows 11 で GUI から TUN／システムプロキシを併用する全体像は Windows 11 の Verge Rev セットアップ記事も参照ください。

3. 環境変数：HTTP_PROXY / HTTPS_PROXY / ALL_PROXY

Node や多くの CLI は大文字または小文字の HTTP_PROXY と HTTPS_PROXYを参照します。HTTPS_PROXY が空なら HTTP_PROXY にフォールバックする実装もありますが、明示しておく方がトラブル時の当たりが付きやすいです。形式は http://127.0.0.1:7890 のように スキーム付きで HTTP プロキシを指すのが無難です（Clash が HTTP プロキシとして応答していることが前提）。ALL_PROXY を SOCKS に載せる構成もありますが、npm の挙動と二重解釈しないよう、まずは HTTP 系だけに絞ると切り分けが楽です。

PowerShell の現在のセッションだけなら次のようにします。恒久化はユーザ環境変数に入れる方法もありますが、プロキシ不要な別ターミナルまで汚染しないよう、プロファイルで条件分岐するか、開発用プロファイルを分けると安全です。

# PowerShell: current session only (port is example)
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY    = "localhost,127.0.0.1,::1,registry.npmmirror.com,*.npmmirror.com"

CMD では set HTTP_PROXY=... の形式です。Git for Windows の bashを併用している場合は export 側も同様に揃え、MSYS 系が localhost をどう解釈するかだけは頭の片隅に置いておくとよいです。環境変数を変えたあと、別ウィンドウで古い値が残っていないかも確認してください。

4. NO_PROXY の設計（ミラー直結の要）

NO_PROXY（no_proxy）は、プロキシを通すと遅い・不要・ポリシ上まずい宛先を列挙します。国内ミラーを使う場合は、ミラーの FQDN と tarball を配る CDN の代表的なサフィックスを入れておくと、Clash 側で DIRECT に振っていなくてもそもそもプロキシに流れないため挙動が素直になります。逆に、ここが空だと国内ミラーまで海外ノードに迂回し、レイテンシだけでなく帯域の無駄と失敗率が跳ね上がります。

列挙の区切りはカンマが一般的です。先頭にドットを付けたサフィックス形式（例：.corp.example）を解釈するツールもありますが、npm が参照する HTTP 実装で未対応なパターンもあるため、重要なホストはフルで書き切る方が確実です。社内の Nexus や Artifactory を併用する場合も、そのホスト名と IP を必ず含めるようにしてください。IPv6 スタックのみ有効な環境では ::1 を忘れずに。

5. npm と pnpm：.npmrc・プロキシ行の住み分け

npm はユーザまたはプロジェクトの .npmrc に proxy= と https-proxy= を書けます。シェルの環境変数と .npmrc の両方に値があると、どちらが優先されるかで混乱しがちなので、方針を決めてどちらか一方に寄せるのがおすすめです。本稿の推奨は、シェル側の HTTP_PROXY 系に統一し、.npmrc には registry や認証トークンだけを置くパターンです。どうしてもプロジェクト単位で固定したい場合のみ .npmrc にプロキシを書き分けます。

pnpm も同様に環境変数を尊重しますが、グローバルストアや仮想ストアのパスが絡むと「取得は成功したのにリンクで失敗する」など別次元のエラーが出ます。ネットワーク起因と切り分けるため、まずは pnpm config get registry で実際に叩いている registry URLを確認し、pnpm why やロックファイルで tarball のホスト名がどこに向いているかを見ます。社内レジストリを registry にしている場合、そのホストは NO_PROXY に必須です。

strict-ssl=false は一時しのぎになりやすく、根本原因が中間者プロキシの証明書か、社内 CA の未インポートかを切り分けたうえで判断してください。Clash 自身が TLS を終端しない通常構成であれば、strict-ssl を落とす必要はないことがほとんどです。逆に企業プロキシのような別階層が挟まる場合は、OS の信頼ストアにルート CA を入れる方が筋が良いです。

# Show effective registry (example)
npm config get registry
pnpm config get registry

6. 分流ルール例：DOMAIN と GEOIP の順序

環境変数で「すべて Clash に入る」形にしたうえで、Clash のルール先頭付近で国内ミラーや社内レジストリを DIRECT にします。例としては DOMAIN-SUFFIX,npmmirror.com,DIRECT や DOMAIN,registry.npmjs.org,PROXY のような明示的な DOMAIN 行を、広い MATCH より前に置くイメージです。実際のポリシー名（PROXY など）は自分の設定ファイルの proxy-groups に合わせて置換してください。

tarball が registry.npmjs.org 以外の CDN に散らばる場合、ログに出たホスト名をルールに足す運用が現実的です。mihomo では rule-providers に任せる構成も多いですが、開発トラフィックだけを素早く直したいときは、まず数行の DOMAIN-SUFFIX で足場を作り、あとからプロバイダへ昇格させると安全です。GEOIP,cn,DIRECT のような広い行は意図しないホストまで直結させる副作用があるため、npm だけを救いたい局面ではドメイン単位の明示ルールを先に厚くする方が予測可能性が高いです。

# Mihomo / Clash Meta style (illustrative; group names are placeholders)
rules:
  - DOMAIN-SUFFIX,npmmirror.com,DIRECT
  - DOMAIN,registry.npmjs.org,PROXY_GROUP
  - DOMAIN-SUFFIX,npmjs.org,PROXY_GROUP

DNS モードが fake-ip のときは、名前解決とルール評価の順序が絡んで挙動が変わります。タイムアウトが続くときは、一時的に 該当ドメインだけ redir-host 相当の扱いに寄せる、あるいは Sniffer を有効にして SNI とルールを一致させる、といった別稿で扱うテーマと接続します。購読更新自体が不安定な場合は Windows の購読 TLS・DNS・ログの記事も参照ください。

7. 切り分け：タイムアウト・証明書・DNS

まず curl -v -x http://127.0.0.1:7890 https://registry.npmjs.org のように、プロキシ経由で HTTPS が張れるかを見ます。ここで失敗するなら Clash 側のポート・バインド・ルールが先です。成功するのに npm だけ失敗する場合は、npm_config_registry など別経路の環境変数や、.npmrc の上書きを疑います。npm ping や pnpm ping が使える場合は、レイテンシと到達性のスナップショットとして有用です。

ログでは どの策略に載ったかと、TCP 接続が張れたのか TLS まで進んだのかを分けて読みます。企業環境では 別階層の HTTPS インスペクションが有効で、Clash の外側で証明書が差し替わっていることもあります。その場合は Node が参照する CA ストアに社内ルートを入れる必要があり、Clash のルール調整だけでは解決しません。逆に、直近だけ自己署名を挟んだローカルミラーを試しているなら、一時的な例外として strict-ssl を下げる判断もあり得ますが、恒久運用には持ち込まないのが無難です。

最後に、「プロキシを切ると速いが、オンにすると遅い」ときは、ノードの地理的距離だけでなくDNS が別リゾルバを見て意図しない IP に着地している可能性もあります。Windows のネットワークプロファイルと、Clash の DNS 設定を同じシナリオで見る癖を付けると、長時間のインストール待ちが続く状況でも焦らず切り分けできます。

8. まとめ

Windows 本機で npm／pnpm を安定させるコツは、シェルに HTTP_PROXY／HTTPS_PROXY を明示し、国内ミラーと社内レジストリを NO_PROXY で直結に逃がすこと、そして Clash のルール先頭で同じホストを DIRECT に固定することの二段です。どちらか片方だけでは、設定の読み違いや購読ルールの更新タイミングで再び混線した経路に戻りがちです。コンテナや WSL と同じ頭で考えないことも重要で、レイヤごとに入口を切り出すと運用が楽になります。

Clash 系のクライアントは実装が分かれていても、ルールと可観測性という軸は共通です。開発者が毎日触れるパッケージマネージャほど、小さなネットワーク差分がストレスに直結するので、一度ベースラインを決めてログで微調整するサイクルに乗せるのがよいでしょう。同種の GUI ツールと比較しても、ドメイン単位の制御とログの往復がしやすい点は、長い install を抱える開発者にとって実利的です。

オープンソースのライセンスやソースコードを確認したい方は、公式の GitHub リポジトリも参照できます。一方でインストーラの入手とプラットフォーム別のまとまった説明は、当サイトのダウンロードページの方が迷いにくい構成になっています。

まずは手元のビルドを選び、mixed-port を確認したうえで環境変数から試すのが最短です。クライアントの入手は → 無料で Clash をダウンロードして、快適な接続を試す からどうぞ。