In this Article
การใช้งาน GitHub จากภายในเครือข่ายองค์กรมักเป็นปัญหาด้านการตั้งค่าที่กระจายอยู่ในเครื่องมือห้าตัวซึ่งไม่ได้แชร์การตั้งค่าร่วมกัน บางครั้ง clone ทำงานได้แต่ npm install ล้มเหลว บางครั้ง npm ทำงานได้แต่ Docker ไม่สามารถ pull ได้ หรือทุกอย่างทำงานได้ในบรรทัดคำสั่งแต่ IDE กลับเชื่อมต่อกับอะไรไม่ได้เลย
คู่มือนี้จะอธิบายว่าเครื่องมือแต่ละตัวอ่านค่าการตั้งค่าพร็อกซีจากที่ใด เหตุใด SSH จึงทำงานแตกต่างจาก HTTPS วิธีตีความข้อผิดพลาดทั้งสี่ประเภทที่คุณจะพบจริง และทางลัดสองแบบที่ควรหลีกเลี่ยง
ข้อเท็จจริงสำคัญ
- เครื่องมือแต่ละตัวมีการตั้งค่าพร็อกซีของตัวเอง Git, npm, pip, Docker และเชลล์ของคุณต่างอ่านค่าการตั้งค่าที่แตกต่างกัน จึงเป็นเหตุผลที่การแก้ไขตัวหนึ่งไม่ได้ทำให้ตัวอื่นๆ ใช้งานได้ตามไปด้วย
- SSH มักล้มเหลวในจุดที่ HTTPS ใช้งานได้ เนื่องจากพร็อกซีขององค์กรส่วนใหญ่ส่งต่อเฉพาะ HTTP CONNECT บนพอร์ตมาตรฐานเท่านั้น
- ข้อผิดพลาดเกี่ยวกับใบรับรองแทบทุกครั้งหมายถึงการตรวจสอบ TLS (TLS inspection) และวิธีแก้คือการเชื่อถือ CA ขององค์กร ไม่ใช่การปิดการตรวจสอบ
- อย่าปิดการตรวจสอบใบรับรองเพียงเพื่อให้ clone ทำงานได้ เพราะจะเปลี่ยนปัญหาการตั้งค่าที่มองเห็นได้ให้กลายเป็นปัญหาด้านความปลอดภัยที่มองไม่เห็น
- ข้อมูลรับรองที่ใส่ไว้ใน URL ของพร็อกซีอาจรั่วไหลเข้าไปใน log และประวัติของเชลล์ได้ จึงควรใช้ที่เก็บข้อมูลรับรอง (credential store) ของเครื่องมือนั้นแทน
เครื่องมือแต่ละตัวอ่านค่าการตั้งค่าพร็อกซีจากที่ใด
แยกกันโดยสิ้นเชิง ซึ่งเป็นต้นตอของความสับสนส่วนใหญ่ เราเรียกสิ่งนี้ว่า โมเดล toolchain 4 ส่วน
| เครื่องมือ | อ่านค่าจากที่ใด | จุดที่มักพลาด |
|---|---|---|
| 1. Git | การตั้งค่าของตัวเอง จากนั้นจึงเป็นตัวแปรสภาพแวดล้อม (environment variables) | remote แบบ HTTPS ใช้งานได้ ในขณะที่ remote แบบ SSH ใช้งานไม่ได้ |
| 2. Package manager ต่างๆ | ไฟล์การตั้งค่าของตัวเอง จากนั้นจึงเป็นตัวแปรสภาพแวดล้อม | แต่ละตัวต้องตั้งค่าแยกกัน และ registry อาจแตกต่างจาก GitHub |
| 3. Docker | การตั้งค่าของ daemon ไม่ใช่แค่เชลล์ของคุณ | ตัวแปรในเชลล์ไปไม่ถึง daemon ที่ทำหน้าที่ pull image |
| 4. IDE และตัวแก้ไขโค้ด | การตั้งค่าของตัวเอง บางครั้งใช้ที่เก็บค่าของระบบ | เทอร์มินัลทำงานได้ แต่ฟีเจอร์ที่รวมอยู่ในตัว IDE ทำงานไม่ได้ |
ดังนั้น การตั้งค่า พร็อกซีสำหรับ GitHub ให้ใช้งานได้จริงจึงหมายถึงการตั้งค่าห้าจุด ไม่ใช่จุดเดียว ลำดับที่ใช้งานได้จริงคือ ตั้งค่าตัวแปรสภาพแวดล้อมของเชลล์ก่อน จากนั้นตั้งค่า git ตามด้วย package manager แต่ละตัว แล้วจึงตั้งค่า Docker daemon และควรใส่รายการ no-proxy สำหรับโฮสต์ภายในตั้งแต่ต้น การข้ามขั้นตอนสุดท้ายนี้เองที่มักทำให้บริการภายในเชื่อมต่อไม่ได้ แม้การตั้งค่าส่วนอื่นจะสำเร็จแล้วก็ตาม
เหตุใด SSH จึงล้มเหลวในขณะที่ HTTPS ใช้งานได้
เพราะทั้งสองเป็นโปรโตคอลที่ต่างกันและใช้พอร์ตต่างกัน และพร็อกซีขององค์กรส่วนใหญ่ส่งต่อเฉพาะ HTTP CONNECT ไปยังพอร์ตจำนวนน้อยเท่านั้น
Git ผ่าน HTTPS เป็นเพียงคำขอเว็บทั่วไปที่พร็อกซีจัดการได้โดยตรงอยู่แล้ว ส่วน Git ผ่าน SSH ใช้พอร์ต 22 ซึ่งโดยปกติแล้วพร็อกซีจะไม่อนุญาตให้ผ่านเลย ผลลัพธ์คือ repository จะ clone ได้สำเร็จเมื่อใช้ remote แบบ HTTPS แต่จะหมดเวลา (time out) เมื่อใช้ remote แบบ SSH และข้อความแสดงข้อผิดพลาดก็แทบไม่เคยบอกสาเหตุที่แท้จริง
มีวิธีแก้ปัญหาที่ใช้ได้จริงสามวิธี เรียงตามลำดับที่แนะนำ ได้แก่ เปลี่ยน remote ให้เป็น HTTPS พร้อมโทเค็น (token) ใช้ SSH ผ่านพอร์ต HTTPS ในกรณีที่ GitHub รองรับ หรือขอให้ทีมเครือข่ายอนุญาตให้ SSH เข้าถึงโฮสต์ที่กำหนด วิธีแรกใช้ได้ในทุกสถานการณ์และเป็นวิธีที่ทีมส่วนใหญ่เลือกใช้ในที่สุด
จะตีความข้อผิดพลาดเหล่านี้อย่างไร
| ข้อผิดพลาด | ใช้วิธีแก้นี้เมื่อ | หลีกเลี่ยงเมื่อ |
|---|---|---|
| Certificate verification failed | เพิ่ม CA ขององค์กร เข้าไปในที่เก็บความน่าเชื่อถือ (trust store) ของเครื่องมือ | อย่าปิดการตรวจสอบเด็ดขาด เพราะจะซ่อนความเสี่ยงที่แท้จริงไว้ |
| Connection timed out on an SSH remote | เปลี่ยนไปใช้ HTTPS หรือ SSH ผ่านพอร์ต HTTPS | การลองซ้ำ เพราะพอร์ตถูกบล็อก ไม่ใช่แค่ทำงานช้า |
| Proxy authentication required | ตั้งค่าข้อมูลรับรองในที่เก็บของเครื่องมือ | การใส่ไว้ใน URL เพราะจะรั่วไหลเข้าไปใน log |
| Works in terminal, fails in Docker | ตั้งค่า Docker daemon จากนั้นรีสตาร์ต | การเพิ่มตัวแปรในเชลล์มากขึ้น เพราะ daemon ไม่เคยอ่านค่าเหล่านั้น |
| Internal hosts unreachable after setup | เพิ่มโฮสต์เหล่านั้นเข้าไปในรายการ no-proxy | การลบการตั้งค่าพร็อกซีทั้งหมดออกไป |
แถวแรกเป็นจุดที่ควรยึดมั่นให้แน่วแน่ การตรวจสอบ TLS (TLS inspection) หมายถึงมี middlebox ทำหน้าที่ยุติและเซ็นใบรับรองการเชื่อมต่อของคุณใหม่ และการตอบสนองที่ถูกต้องคือการเลือกเชื่อถือ CA ขององค์กรอย่างมีเจตนา การปิดการตรวจสอบจะทำให้ข้อผิดพลาดหายไปก็จริง แต่ก็ทำให้การสกัดกั้นข้อมูล (interception) ในอนาคตทุกครั้งมองไม่เห็นไปด้วย
เมื่อใดที่พร็อกซีภายนอกเป็นเครื่องมือที่เหมาะสม
สำหรับปัญหานี้ ไม่ค่อยใช่ และควรทำความเข้าใจให้ชัดเจนตั้งแต่ต้น
พร็อกซีขององค์กรคือโครงสร้างพื้นฐานที่องค์กรของคุณดำเนินการอยู่ และวิธีแก้ปัญหาการเข้าถึง GitHub ผ่านพร็อกซีนี้คือการตั้งค่า ไม่ใช่การเพิ่มพร็อกซีอีกตัว การหาทางเลี่ยงการควบคุมเครือข่ายที่นายจ้างของคุณตั้งใจวางไว้เป็นเรื่องของนโยบายก่อนที่จะเป็นเรื่องทางเทคนิคด้วยซ้ำ
สิ่งที่พร็อกซีเชิงพาณิชย์เหมาะสมจริงๆ คืองานประเภทอื่นที่บังเอิญเกี่ยวข้องกับ GitHub เช่น การเก็บข้อมูล repository สาธารณะในปริมาณมาก การตรวจสอบว่าหน้าเว็บสาธารณะแสดงผลอย่างไรจากอีกประเทศหนึ่ง หรือการรันการตรวจสอบอัตโนมัติจากหลายภูมิภาค สำหรับการเก็บข้อมูล repository โดยเฉพาะนั้น GitHub API พร้อมโทเค็นคือคำตอบที่ถูกต้องอันดับแรก และมีขีดจำกัดที่เอื้อเฟื้อมากพอจนแทบไม่มีเหตุผลที่ต้องใช้การ scraping
เมื่อการเก็บข้อมูลจำเป็นต้องใช้ทางออก (exit) ที่กระจายตัวจริงๆ residential proxy ของ DataImpulse ครอบคลุม 195 ประเทศ ในราคา $1 ต่อ GB ที่เกี่ยวข้อง: proxies for web scraping, 403 Forbidden explained.
คำถามที่พบบ่อย
จะตั้งค่า git ให้ใช้พร็อกซีได้อย่างไร
ตั้งค่าพร็อกซีในการตั้งค่าของ git เอง หรือในตัวแปรสภาพแวดล้อมมาตรฐาน และเพิ่มโฮสต์ภายในเข้าไปในรายการ no-proxy ไปพร้อมกัน Git อ่านค่าการตั้งค่าของตัวเองแยกจาก npm, pip และ Docker ดังนั้นแต่ละเครื่องมือจึงต้องตั้งค่าแยกกัน
เหตุใด git clone ผ่าน SSH จึงล้มเหลวเมื่ออยู่หลังพร็อกซี
เพราะ SSH ใช้พอร์ต 22 และพร็อกซีขององค์กรส่วนใหญ่ส่งต่อเฉพาะ HTTP CONNECT ไปยังพอร์ตเว็บมาตรฐานเท่านั้น remote แบบ HTTPS ใช้งานได้เพราะเป็นเพียงคำขอเว็บทั่วไป การเปลี่ยน remote ให้เป็น HTTPS พร้อมโทเค็นคือวิธีแก้ที่ใช้ได้ในสภาพแวดล้อมส่วนใหญ่ที่สุด
อะไรเป็นสาเหตุของข้อผิดพลาดเกี่ยวกับใบรับรองเมื่ออยู่หลังพร็อกซีขององค์กร
การตรวจสอบ TLS (TLS inspection) กล่าวคือ middlebox จะยุติและเซ็นใบรับรองการเชื่อมต่อของคุณใหม่ด้วยผู้ออกใบรับรอง (certificate authority) ขององค์กรเอง วิธีแก้คือเพิ่ม CA นั้นเข้าไปในที่เก็บความน่าเชื่อถือของแต่ละเครื่องมือ การปิดการตรวจสอบใบรับรองจะทำให้ข้อผิดพลาดหายไป แต่ก็ทำให้คุณไม่สามารถตรวจจับการสกัดกั้นข้อมูลจริงได้อีกด้วย
เหตุใด Docker จึงล้มเหลวทั้งที่เทอร์มินัลของฉันใช้งานได้
เพราะ Docker daemon เป็นตัวที่ทำหน้าที่ pull image ไม่ใช่เชลล์ของคุณ และ daemon จะอ่านค่าการตั้งค่าของตัวเองแทนที่จะอ่านตัวแปรสภาพแวดล้อมของคุณ ให้ตั้งค่าพร็อกซีของ daemon แล้วรีสตาร์ต
ควรใช้พร็อกซีเชิงพาณิชย์เพื่อเข้าถึง GitHub ที่ทำงานหรือไม่
ไม่ควร พร็อกซีขององค์กรคือโครงสร้างพื้นฐานที่องค์กรของคุณจงใจดำเนินการอยู่ และวิธีแก้คือการตั้งค่า พร็อกซีเชิงพาณิชย์เหมาะกับงานประเภทอื่น เช่น การเก็บข้อมูลสาธารณะจากหลายภูมิภาค และแม้แต่ในกรณีนั้น GitHub API พร้อมโทเค็นก็มักเป็นทางเลือกที่ดีกว่า
เมื่องานคือการเก็บข้อมูล ไม่ใช่การเชื่อมต่อ
การตรวจสอบว่าหน้าเว็บสาธารณะแสดงผลอย่างไรจากภูมิภาคอื่น หรือการเก็บข้อมูลสาธารณะในปริมาณมาก เป็นปัญหาที่แตกต่างจากการตั้งค่าเครือข่ายองค์กร residential proxy ของ DataImpulse ครอบคลุม 195 ประเทศ ในราคา $1 ต่อ GB สร้างบัญชี เมื่อนั่นคืองานที่คุณต้องทำ
บทความที่เกี่ยวข้อง: proxies for web scraping · 403 Forbidden when scraping · what is a web proxy.
อัปเดตล่าสุด: 17 กันยายน 2026