はじめに
Clash を有効にした途端、npm install が終わらなくなったり、ETIMEDOUT や ECONNRESET が表示されたりすることがあります。この場合、npm自体の不具合とは限りません。Clashのルールでレジストリへの通信が意図しない経路に振り分けられている、npmがClashのローカルプロキシを認識していない、あるいは環境変数や古い設定が競合している可能性があります。
npmのパッケージ取得では、レジストリだけでなく、依存パッケージの配布先や認証用の接続先にもアクセスすることがあります。そのため、ブラウザーが正常に開けるだけでは、npmの通信も正常だとは判断できません。まずはClashの接続状態、npmのプロキシ設定、レジストリへの到達性を分けて確認することが大切です。
この記事で確認すること
Clashのモードとルール、npmレジストリ、プロキシ設定、環境変数を順に確認し、設定変更後に接続とインストールの両方を検証します。
1タイムアウトが起きる主な原因
タイムアウトは、相手のサーバーから決められた時間内に応答が返ってこないときに発生します。Clashを使っている場合は、次の項目を優先して確認してください。
- Clashのシステムプロキシがnpmに適用されていない： ブラウザーはOSのプロキシ設定を利用していても、ターミナル上のnpmが同じ設定を使うとは限りません。Clashの画面で「System Proxy」を有効にしただけでは、環境によってnpmの通信がプロキシ経由にならないことがあります。
- ルールが接続先を誤った経路へ送っている： Ruleモードでは、接続先のドメインやIPアドレスに一致したルールが適用されます。レジストリがDIRECTになっている、意図しないプロキシグループへ送られている、またはそのグループのノードが停止していると、通信が失敗する場合があります。
- npmと環境変数の設定が食い違っている： npmの
https-proxy、シェルのHTTPS_PROXY、過去に設定した別のプロキシが残っていると、Clashとは異なる接続先にアクセスすることがあります。 - レジストリまたは配布先に到達できない： レジストリの指定が誤っている、ネットワーク上で特定ドメインが遮断されている、または一部の依存パッケージの配布先だけが別ルートになっている可能性があります。
- 接続はできるが、応答に時間がかかっている： ノードの混雑、DNSの遅延、パケットロスなどが原因で、接続確立後のデータ取得が遅くなることもあります。
安易に変更しない設定
strict-ssl=false はTLS証明書の検証を弱める設定です。タイムアウト解消のために安易に有効化せず、証明書エラーが別途確認できた場合も、社内ネットワークの証明書設定など根本原因を調べてください。
2まずClashとnpmの状態を切り分ける
最初に、Clashを一時的に停止した状態と有効にした状態で、同じ接続先を比較します。Clashを停止すると成功し、有効にすると失敗するなら、プロキシ設定やルール、ノードの選択が主な確認対象です。どちらの状態でも失敗する場合は、ネットワーク自体、レジストリ、npmの設定も調べましょう。
ターミナルで、現在のレジストリとプロキシ設定を確認します。出力に社内情報や認証情報が含まれていないか注意し、ログや画面を共有する場合は伏せてください。
通常のnpmレジストリを利用する場合、registryが https://registry.npmjs.org/ になっているか確認します。組織で指定されたプライベートレジストリを使っている場合は、管理者から案内されたURLを維持してください。無断で公開レジストリへ変更すると、社内パッケージを取得できなくなることがあります。
Clash側では、接続ログを開いて、npmの実行時刻に関連ドメインへの接続が記録されるかを見ます。ログに接続がない場合は、npmがClashを経由していない可能性があります。接続が記録されていても、DIRECTや停止中のグループへ割り当てられていれば、ルールまたはノード選択を確認します。
確認のポイント
npmのエラー全文と、Clashログの接続先・ルール・選択グループを同じ時刻で照合すると、問題がどの段階で起きているか判断しやすくなります。
3Clash経由でnpmを動かす手順
ここでは、npmの接続先にClashのローカルHTTPプロキシを指定する方法を説明します。ポート番号は環境によって異なるため、Clashの設定画面または設定ファイルに表示される port や mixed-port を確認してください。以下の 7890 は例です。
- Clashを起動し、利用可能なプロファイルとノードを選択します。接続テストを実行し、ノードが応答することを確認してください。
- Clashの「System Proxy」を有効にします。これだけでnpmが接続できるとは限らないため、続けてnpm側の設定も確認します。
- ClashのローカルHTTPまたはmixedポートに合わせて、npmのプロキシを設定します。
ここで指定するURLの http:// は、ローカルのプロキシサーバーとの通信方式です。npmが取得するパッケージのURLがHTTPSでも、Clashが提供するHTTPプロキシへ接続する設定として利用できます。Clashのポートが異なる場合は、両方のコマンドを実際の番号に置き換えてください。
npm pingを実行し、レジストリから応答が返るか確認します。- 問題が再現するプロジェクトで
npm installをもう一度実行します。Clashの接続ログに必要な接続が表示されているかも確認してください。
設定が不要になった場合や、npmを直接接続に戻したい場合は、追加した設定を削除できます。
設定の保存先や既存値が気になる場合は、npm config list と npm config get userconfig で確認できます。複数のプロジェクトやユーザーで異なる設定ファイルが使われていることがあるため、変更後は実際に npm install を実行するユーザーとシェルで確認してください。
4ルール・環境変数・レジストリを確認する
npmからClashへ接続できるようになったら、接続先が適切な経路へ振り分けられているかを確認します。Clash Verge Revなどのクライアントでは、接続ログから該当ドメインを選び、どのルールが一致したか、どのポリシーやノードが選択されたかを確認できます。設定項目の名称はクライアントやコアによって異なります。
通常の公開レジストリを利用する場合は、必要に応じて registry.npmjs.org が利用したいプロキシグループへ振り分けられるか確認します。ルールを編集する場合は、既存ルールの順序やプロファイルの更新による上書きに注意してください。ルールは上から評価される構成が一般的なので、広い条件のルールが先に一致すると、追加した細かいルールが使われないことがあります。
環境変数も確認します。シェルやCI環境で HTTP_PROXY、HTTPS_PROXY、ALL_PROXY が定義されていると、npmの設定とは別にプロキシが使われる場合があります。値に古いポートや不要な認証情報が含まれていないか調べ、不要であれば現在のシェルだけで一時的に解除して再テストします。
社内のプライベートレジストリを使っている場合は、そのホスト名と認証設定を保ったまま、該当ドメインへの経路を確認してください。レジストリへの接続は成功するのに特定パッケージだけ失敗する場合は、npmの詳細ログからパッケージの取得URLを確認し、その配布先ドメインもClashログで調べます。認証トークンを含むURLやログを公開しないようにしてください。
5設定変更後の検証と再発防止
接続が遅いだけで、正しいレジストリへ到達できている場合は、Clashで別の安定したノードを選び、同じコマンドで再確認します。npmの取得時間に関する設定を変更する前に、まずノード、経路、プロキシポートを確認してください。待ち時間だけを大きくすると、設定ミスに気づきにくくなることがあります。
一時的なネットワーク遅延への対策として再試行回数や取得タイムアウトを調整する方法はありますが、組織の環境やnpmのバージョンによって適切な値は異なります。必要な場合に限って設定し、変更前の値を記録してください。キャッシュの削除も最初の対処にはせず、レジストリへの接続とプロキシ経路が正常であることを確認してから検討します。
npm pingが失敗する： レジストリURL、npmのプロキシ設定、Clashのローカルポートを順番に確認します。npm pingは成功するが、インストールが失敗する： 失敗した依存パッケージの取得先や認証、Clashの接続ログを調べます。- Clashのログにnpmの接続がない： npmが使う環境変数やプロキシ設定を確認し、ターミナルを開き直して再テストします。
- 特定のノードだけで失敗する： 別の利用可能なノードを試し、ノード固有の遅延や到達性の問題か切り分けます。
最後に、成功したコマンド、Clashのモード、使用したポート、レジストリ、必要な環境変数を記録しておくと、次回のトラブル対応が簡単になります。設定を共有する場合は、プロキシ認証情報、npmトークン、社内ホスト名などを必ずマスキングしてください。