ל־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 מחליש את אימות התעודות; הוא אינו מחליף בחירה נכונה של פרוקסי או חומרי אמון.

כשהבדיקה נגמרת, הסירו את עקיפות הגדרות הפרויקט שהוספתם ובדקו שוב את הערכים הפעילים. כך הפרויקט יורש את תצורתו הקודמת ללא שינוי פרויקטים אחרים באותה מכונה.

מאמרים קשורים