การตั้งค่าพร็อกซี 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 ทำให้การตรวจใบรับรองอ่อนลง ไม่ใช่ตัวแทนการเลือกพร็อกซีหรือข้อมูลความเชื่อถือที่ถูกต้อง

เมื่อทดสอบเสร็จ ให้ลบค่าทับระดับโปรเจกต์ที่เพิ่ม แล้วตรวจค่าที่มีผลอีกครั้ง โปรเจกต์จะสืบทอดค่าเดิมโดยไม่เปลี่ยนโปรเจกต์อื่นในเครื่องเดียวกัน