内部レジストリには直接到達できる一方、公開パッケージの通信には依然としてオフィスのプロキシが必要です。プロキシ設定はそのまま残し、内部の宛先を noproxy に追加します。

たとえば、該当する .npmrc のエントリは次のようにできます。

registry=https://registry.corp.example/repository/npm/
proxy=http://proxy.example:8080
https-proxy=http://proxy.example:8080
noproxy[]=registry.corp.example
noproxy[]=packages.corp.example

バイパスのエントリが示すのは宛先であり、プロキシサーバーではありません。ホスト単位のエントリなので、レジストリのスキーム、パス、ポートはこれらの文字列に含めません。

npm 11.6.4 に同梱のセレクターでは、ドメインの構成要素を右から比較します。registry.corp.example はそのホスト名とそのサブドメインに一致します。この比較では先頭のドットが取り除かれ、ホスト名の例にリテラルのアスタリスクは不要です。

レジストリが別の内部ホスト名で tarball の URL を返す場合は、パッケージ内容のホストも含めてください。そうしないと、レジストリのインデックスとファイルのダウンロードが別の経路を通る可能性があります。

配列構文なら複数の例外を読みやすく保てます。npm はカンマ区切りの文字列形式と、環境から導出される NO_PROXY の既定値も文書化しています。ある宛先が依然として想定外の経路を通る場合は、この呼び出しが使う実際の noproxy 設定を確認してください。

関連記事