npmにはproxyとhttps-proxyという別々の設定があります。区別するのはリクエストの宛先です。HTTPSをトンネルする通常のHTTPプロキシなら、両方に同じhttp://接続先を指定できます。

プロジェクト単位の.npmrcには次のように記述できます。

proxy=http://203.0.113.10:8080
https-proxy=http://203.0.113.10:8080
noproxy=localhost,127.0.0.1,registry.example.internal

ドキュメント用の接続先を自分のプロキシに置き換えます。許可された公開レジストリのテストには、HTTPプロキシ一覧がHTTP候補を提供します。最後の行は指定の内部レジストリを意図的に直接接続にしています。別のプロキシアドレスではありません。

npmにリクエストを送らせる

キャッシュからのインストールは経路テストに向きません。npmが必要なものをすべて持っている可能性があります。レジストリへのpingなら、より小さな確認になります。

npm ping --registry=https://registry.npmjs.org/

正常終了が示すのは、このnpm実行がそのレジストリへの経路に到達したことです。すべてのtarballホスト、Git依存関係、別のパッケージマネージャープロセスも同じ経路を使うとは証明できません。

設定の競合を探すには、すぐに別のファイルを編集せず、有効な値を確認します。

npm config get proxy
npm config get https-proxy
npm config get noproxy

これらのコマンドは、URLに認証情報が埋め込まれていると表示することがあります。出力はローカルで確認し、そのまま不具合報告に貼り付けないでください。

プロジェクトの.npmrcはグローバルインストールでは使われません。npm install -gだけが失敗するなら、プロジェクトファイルを読んだと決めつけず、その実行で有効な設定を確認します。

IPを変える前に除外を確認する

npmはプロキシ環境変数も使い、noproxy設定はNO_PROXYから来る場合があります。有効な設定で除外された宛先は、プロキシ値があっても直接接続できます。逆に、一つの.npmrcから行を消しても、継承した環境変数は削除されません。

証明書エラーは分けて考える

許可された検査プロキシには組織のCAが必要な場合があります。Node/npm環境がまだそのCAを信頼していないかもしれません。npmはCAファイルに対応しています。

cafile=/path/to/approved-ca-bundle.pem
strict-ssl=true

その環境で承認された実際のバンドルを使ってください。strict-ssl=falseは証明書検証を弱めます。正しいプロキシや信頼材料を選ぶ代わりにはなりません。

テスト終了後、追加したプロジェクトの上書き設定を削除し、有効な値を再確認します。同じマシンの他のプロジェクトを変えずに、以前の設定を継承できます。

関連記事