npm-ის პროქსი პარამეტრები HTTP-სა და HTTPS-ისთვის

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 ასუსტებს სერტიფიკატების შემოწმებას და არ ცვლის სწორი პროქსის ან ნდობის მასალის არჩევას.

ტესტის ბოლოს წაშალეთ დამატებული პროექტული გადაფარვები და ხელახლა შეამოწმეთ მოქმედი მნიშვნელობები. პროექტი წინანდელ კონფიგურაციას დაიმკვიდრებს იმავე მანქანის სხვა პროექტების შეცვლის გარეშე.