Налаштування проксі в npm не маршрутизує все, що запускає npm start
npm налаштовує власні передачі пакетів. Застосунку, запущеному скриптом, усе ще потрібен HTTP-клієнт, який підтримує потрібний вихідний проксі.
npm install працює через проксі. npm start запускає застосунок, і його запит до API йде напряму. npm не обов'язково забув налаштування.
Перший запит зробив менеджер пакетів. Другий робить ваш застосунок. Значення проксі в конфігурації npm — це дані для тих, хто його читає, а не тунель, підкладений під кожен дочірній процес.
Огляньте HTTP-клієнт застосунку та підтримуваний ним інтерфейс проксі. Він може читати стандартні змінні середовища, вимагати явного agent або dispatcher, або використовувати інше задокументоване налаштування. Не вважайте, що змінна на кшталт npm_config_proxy розпізнається автоматично.
Також відокремте вихідний проксі від функції пересилання API сервера розробки. Налаштування, яке пересилає запити браузера з сервера розробки на backend, має іншу роль; воно не є автоматично мережевим виходом для кожного запиту вашого застосунку.
Для користного порівняння назвіть запит, який вдається, і процес, який робить запит, що не вдається. Потім налаштуйте останній свідомо. Застосунок, що використовує fetch з Undici, може дотримуватися своєї конфігурації диспетчера ProxyAgent, з випуском пакета, сумісним із його середовищем виконання Node. Зміна кінцевої точки registry в npm або повторне встановлення застосунку саме по собі не забезпечує цей відсутній маршрут.