لدى 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 التحقق من الشهادات؛ ولا يعوّض اختيار الوكيل أو مادة الثقة الصحيحة.

عند انتهاء الاختبار، أزل إعدادات التجاوز الخاصة بالمشروع التي أضفتها وراجع القيم الفعلية مجددًا. يتيح ذلك للمشروع وراثة إعداده السابق دون تغيير مشاريع أخرى على الجهاز نفسه.

مقالات ذات صلة