Налаштування проксі npm для HTTP та HTTPS

Налаштуйте HTTP- та HTTPS-маршрути проксі npm, зрозумійте винятки noproxy та використовуйте приватний CA без вимкнення перевірки TLS.

npm має окремі налаштування proxy та https-proxy. Відмінність — у призначенні запиту. Для звичайного HTTP-проксі, що тунелює HTTPS, обидва значення можуть указувати на ту саму кінцеву точку 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 ще не довіряє. npm підтримує файл CA:

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

Використовуйте справжній затверджений набір для цього середовища. strict-ssl=false послаблює перевірку сертифікатів; це не заміна вибору правильного проксі чи матеріалів довіри.

Після тестів видаліть додані перевизначення проєкту й знову перевірте чинні значення. Проєкт успадкує попередню конфігурацію без зміни інших проєктів на тому самому комп’ютері.

Схожі статті