แก้ไขข้อผิดพลาดพร็อกซี: 407, 502, 504 และ tunnel connection failed — คู่มือทีละขั้นตอน

ข้อผิดพลาดพร็อกซีมักทำให้เราตกใจเพราะเกิดขึ้นแบบไม่ทันตั้งตัว เมื่อกี้ยังใช้งานได้อยู่เลย แต่ตอนนี้กลับเจอ 407, 502 หรือข้อความ tunnel connection failed ที่ดู mysterious ข่าวดีก็คือ เบื้องหลังทุกข้อผิดพลาดเหล่านี้มีสาเหตุที่ชัดเจนและมีเหตุผล คู่มือนี้จะสอนให้คุณอ่านข้อความเหล่านี้ได้เหมือนอ่านหนังสือเปิด

บทนำ: ทำไมคุณถึงต้องอ่านคู่มือนี้ และคุณจะได้อะไร

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

สิ่งที่คุณจะได้รับเมื่ออ่านจบ:

• ความสามารถในการแยกข้อผิดพลาดพร็อกซีออกจากข้อผิดพลาดของเว็บไซต์เป้าหมายได้ทันที
• ความเข้าใจว่ารหัส 407, 502, 504, 403 และข้อความ tunnel connection failed หมายถึงอะไร
• ทักษะการอ่านผลลัพธ์ของคำสั่ง curl -v ทีละบรรทัด โดยแยกส่วน client-proxy-server ได้อย่างชัดเจน
• ตัวอย่างการวินิจฉัยพร้อมใช้งานใน curl, Python requests และ Node.js พร้อมข้อความ error จริง
• ตารางวินิจฉัยด่วนแบบ อาการ-สาเหตุ-สิ่งที่ต้องตรวจสอบ ที่พิมพ์เก็บไว้ข้างตัวได้

คู่มือนี้เหมาะกับใคร เหมาะสำหรับคนที่เพิ่งเริ่มทำงานกับพร็อกซี แต่ก็มีรายละเอียดเชิงลึกสำหรับนักพัฒนาและผู้เชี่ยวชาญด้านระบบอัตโนมัติด้วย หากคุณกำลังตั้งค่า parser ทำ multi-accounting หรือแค่อยากรู้ว่าทำไมสคริปต์ถึงหยุดดึงข้อมูลกะทันหัน บทความนี้เหมาะกับคุณ

สิ่งที่ต้องรู้ล่วงหน้า แค่เข้าใจพื้นฐานว่า URL, พอร์ต และ HTTP request คืออะไรก็พอ ไม่ต้องมีความรู้เชิงลึกเรื่องเครือข่าย เราจะอธิบายทุกคำศัพท์เป็นภาษาง่าย ๆ ไปพร้อมกัน

ใช้เวลานานแค่ไหน อ่านครั้งแรกประมาณ 30-40 นาที ลองทำตามตัวอย่างในโปรเจกต์ของคุณเองอีก 20-30 นาที หลังจากนั้นการวินิจฉัยข้อผิดพลาดทั่วไปจะใช้เวลาแค่หนึ่งถึงสองนาที

หมายเหตุสำคัญเกี่ยวกับขอบเขต ในคู่มือนี้เราจะพูดถึงเฉพาะข้อผิดพลาดของชั้นพร็อกซีเท่านั้น รหัส 429 (คำขอมากเกินไป) และกลยุทธ์การ retry จะไม่กล่าวถึงที่นี่ เพราะเป็นหัวข้อใหญ่ที่มีตรรกะและแนวทางของตัวเอง 429 ต้องมีบทความแยกเกี่ยวกับ retry และ limit เราจะเน้นเฉพาะการวินิจฉัยความล้มเหลวของการเชื่อมต่อพร็อกซีอย่างเคร่งครัด

การเตรียมพร้อม: เครื่องมือและการเข้าถึง

ก่อนเริ่มวินิจฉัย มาเตรียมชุดเครื่องมือกันก่อน ทั้งหมดฟรีและใช้ได้บนระบบปฏิบัติการใดก็ได้

เครื่องมือที่จำเป็น

1. ติดตั้ง curl บน Linux และ macOS ส่วนใหญ่มีอยู่แล้ว ตรวจสอบด้วยคำสั่ง curl --version ถ้าเห็นเลขเวอร์ชันก็พร้อมใช้
2. บน Windows curl รวมอยู่ในระบบตั้งแต่เวอร์ชันใหม่ ๆ เปิด PowerShell แล้วพิมพ์คำสั่งตรวจสอบเดิม
3. ติดตั้ง Python เวอร์ชัน 3.10 ขึ้นไป หากจะลองตัวอย่าง requests ตรวจสอบด้วยคำสั่ง python --version
4. ติดตั้งไลบรารี requests ด้วยคำสั่ง pip install requests ใน terminal
5. ติดตั้ง Node.js เวอร์ชัน 20 ขึ้นไปสำหรับตัวอย่าง JavaScript ตรวจสอบด้วยคำสั่ง node --version

สิ่งที่ต้องเตรียม

• ข้อมูลพร็อกซีของคุณ: ที่อยู่โฮสต์, พอร์ต, ชื่อผู้ใช้และรหัสผ่าน (ถ้ามี)
• ที่อยู่เป้าหมายสำหรับทดสอบ สำหรับการตรวจสอบ แนะนำให้ใช้เว็บไซต์ง่าย ๆ ที่แสดงข้อมูลเกี่ยวกับ request
• โปรแกรมแก้ไขข้อความสำหรับบันทึก log และบันทึกการวินิจฉัย

เคล็ดลับ: สร้างไฟล์ข้อความแยกชื่อ diagnostic-notes บันทึกทุกคำสั่งและผลลัพธ์ลงไป จะช่วยคุณได้มากเมื่อผ่านไปครึ่งชั่วโมงแล้วคุณลืมว่าตรวจอะไรไปแล้วบ้าง

⚠️ ข้อควรระวัง: ห้ามบันทึกชื่อผู้ใช้และรหัสผ่านพร็อกซีในแชทสาธารณะ, repository สาธารณะ หรือภาพหน้าจอเด็ดขาด การรั่วไหลของข้อมูลเหล่านี้อาจทำให้คนอื่นเข้าถึงทราฟฟิกของคุณได้ เก็บไว้ในโปรแกรมจัดการรหัสผ่านที่ปลอดภัย

✅ ตรวจสอบ: ในขั้นตอนนี้ คำสั่งตรวจสอบเวอร์ชันทั้งสาม (curl, python และ node) ต้องรันสำเร็จ หากตัวใดตัวหนึ่งใช้ไม่ได้ ให้กลับไปติดตั้งเครื่องมือนั้นก่อน

แนวคิดพื้นฐานในภาษาง่าย ๆ

เพื่อให้การวินิจฉัยเป็นไปอย่างเข้าใจ มารู้จักคำศัพท์สำคัญกันก่อน อย่าข้ามส่วนนี้แม้คำศัพท์จะดูคุ้นเคยแล้วก็ตาม

พร็อกซีคืออะไรกันแน่

พร็อกซีคือตัวกลางระหว่างโปรแกรมของคุณกับเว็บไซต์เป้าหมาย คำขอของคุณจะไปถึงพร็อกซีก่อน แล้วพร็อกซีจึงส่งต่อไป คำตอบจะส่งกลับตามเส้นทางเดิม เพราะมีตัวกลางนี้เอง ข้อผิดพลาดจึงเกิดขึ้นได้ในสามที่: ที่ client ของคุณ, ที่พร็อกซี หรือที่เว็บไซต์เป้าหมาย

การแบ่งหลัก: client, proxy, server

จำสามจุดในห่วงโซ่ให้ขึ้นใจ จุดแรกคือ client ของคุณ นั่นคือโปรแกรมที่ส่งคำขอ จุดที่สองคือ พร็อกซี ตัวกลาง จุดที่สามคือ เซิร์ฟเวอร์เป้าหมาย เว็บไซต์ที่คุณต้องการเข้าถึง การวินิจฉัยทั้งหมดสรุปเป็นคำถามเดียวว่า: ความล้มเหลวเกิดที่จุดใดในสามจุดนี้?

รหัส HTTP ในคำสั้น ๆ

เว็บไซต์และพร็อกซีตอบกลับด้วยรหัสตัวเลข รหัสขึ้นต้นด้วย 4 (เช่น 407, 403) มักหมายถึงปัญหาที่ฝั่งคำขอหรือการเข้าถึง รหัสขึ้นต้นด้วย 5 (502, 504) หมายถึงปัญหาที่ฝั่งเซิร์ฟเวอร์หรือตัวกลาง แต่มีความซับซ้อนที่แอบซ่อนอยู่: รหัส 502 อาจส่งมาจากเว็บไซต์เป้าหมายหรือพร็อกซีเองก็ได้ การแยกให้ออกคือหนึ่งในเป้าหมายหลักของคู่มือนี้

ความต่างระหว่าง HTTP และ HTTPS ผ่านพร็อกซี

เมื่อคุณเข้าเว็บ HTTP ธรรมดา พร็อกซีจะเห็นคำขอทั้งหมด แต่เมื่อคุณเข้าเว็บ HTTPS ที่มีการป้องกัน พร็อกซีจะอ่านเนื้อหาไม่ได้ เพราะมีการเข้ารหัส แทนที่ client ต้องขอให้พร็อกซีสร้าง tunnel ที่ปลอดภัยผ่านคำสั่งพิเศษชื่อ CONNECT ด้วยเหตุนี้ข้อผิดพลาด tunnel connection failed จึงปรากฏเฉพาะบน HTTPS เราจะอธิบายเรื่องนี้แยกต่างหากอย่างละเอียด

เคล็ดลับ: จำภาพง่าย ๆ ไว้ในหัว: client เคาะประตูพร็อกซี พร็อกซีตัดสินใจว่าจะให้ผ่านไหม จากนั้นพร็อกซีไปเคาะประตูเว็บไซต์ เว็บไซต์ตัดสินใจว่าจะตอบไหม ข้อผิดพลาดเกิดขึ้นที่การเคาะครั้งที่ล้มเหลว

ขั้นตอนที่ 1: แยกข้อผิดพลาดพร็อกซีออกจากข้อผิดพลาดเว็บไซต์เป้าหมาย

เป้าหมายของขั้นนี้: เรียนรู้ที่จะรู้ภายในไม่กี่วินาทีว่าใครผิด — พร็อกซีหรือเว็บไซต์ นี่คือทักษะพื้นฐานที่การวินิจฉัยทุกอย่างเริ่มต้นจากตรงนี้

หลักการแบ่งแยกหลัก

คำถามสำคัญคือ: คำขอของคุณไปถึงเว็บไซต์เป้าหมายหรือยัง หรือยังติดอยู่ที่พร็อกซี? ถ้าติดที่พร็อกซี แปลว่าชั้นพร็อกซีมีปัญหา ถ้าคำขอไปถึงเว็บไซต์และเว็บไซต์ตอบกลับ แปลว่าปัญหาอยู่ฝั่งเว็บไซต์

1. ดูรหัสข้อผิดพลาดและข้อความ
2. ระบุว่าใครส่งคำตอบนี้: พร็อกซีหรือเซิร์ฟเวอร์ header ของคำตอบและเนื้อหาจะบอกได้
3. ถ้าในข้อความกล่าวถึงคำว่า proxy, tunnel หรือชื่อโปรแกรมพร็อกซีโดยตรง เกือบแน่นอนว่าชั้นพร็อกซีผิด
4. ถ้าคำตอบมีหน้า HTML ของเว็บไซต์เป้าหมายพร้อมโลโก้และการจัดรูปแบบของเว็บนั้น แปลว่าคำขอไปถึงเว็บไซต์แล้ว

สามสัญญาณเร็วที่บ่งบอกว่าพร็อกซีผิด

• รหัส 407 รหัสนี้มีเฉพาะพร็อกซี เว็บไซต์เป้าหมายไม่เคยส่งรหัสนี้ เจอ 407 แปลว่าคุณอยู่ที่ชั้นพร็อกซีแน่นอน
• ข้อความ tunnel connection failed หรือ Received HTTP code จากพร็อกซี ถ้อยคำแบบนี้เกิดจากตัวกลางเท่านั้น
• การปฏิเสธการเชื่อมต่อที่เกิดขึ้นทันที ถ้าคำขอล้มเหลวเกือบทันที ก่อนที่จะไปถึงเว็บไซต์ได้ น่าจะเป็นปัญหาระหว่าง client กับพร็อกซี

เคล็ดลับ: ทำการทดลองควบคุม: ส่งคำขอเดิมโดยตรงโดยไม่ผ่านพร็อกซี ถ้าโดยตรงใช้ได้ แต่ผ่านพร็อกซีไม่ได้ แปลว่าปัญหาอยู่ที่ชั้นพร็อกซีหรือการทำงานร่วมกันของพร็อกซีกับเว็บไซต์ วิธีนี้ตัดสมมติฐานไปครึ่งหนึ่งได้ในหนึ่งนาที

ตัวอย่าง curl สำหรับตรวจสอบเร็ว

รันคำขอผ่านพร็อกซีพร้อม flag verbose คำสั่งมีลักษณะดังนี้: curl -v -x http://ชื่อผู้ใช้:รหัสผ่าน@โฮสต์:พอร์ต https://ตัวอย่าง-เว็บไซต์ flag -v แสดงบทสนทนาทั้งหมด flag -x ระบุพร็อกซี ให้ดูบรรทัดที่ขึ้นต้นด้วยลูกศรและเครื่องหมายดอกจัน เราจะอธิบายอย่างละเอียดในขั้นตอนการอ่าน log แยกต่างหาก

⚠️ ข้อควรระวัง: อย่าสรุปผลจากคำขอเดียวไปยังเว็บไซต์ที่ไม่เสถียร ลองส่งคำขอซ้ำสองสามครั้ง ความล้มเหลวของเครือข่ายครั้งเดียวอาจดูเหมือนข้อผิดพลาดพร็อกซี ทั้งที่พร็อกซีไม่เกี่ยวเลย

✅ ตรวจสอบ: คุณต้องตอบได้สำหรับทุกข้อความ error ว่า: อันนี้พร็อกซีส่งหรือเว็บไซต์ส่ง? ถ้าตอบได้ ให้ไปต่อ ถ้ายังไม่แน่ใจ ให้กลับไปดูสามสัญญาณเร็วด้านบน

ขั้นตอนที่ 2: ข้อผิดพลาด 407 Proxy Authentication Required

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

407 หมายถึงอะไร และต่างจาก 401 อย่างไร

รหัส 407 บอกตรง ๆ ว่า: พร็อกซีต้องการให้คุณแสดงตัวด้วยชื่อผู้ใช้และรหัสผ่าน แต่คุณไม่ได้ทำหรือทำไม่ถูกต้อง ความต่างสำคัญจาก 401 คือ รหัส 401 ถูกส่งจากเว็บไซต์เป้าหมายเมื่อตัวเว็บไซต์เองต้องการการยืนยันตัวตน ขณะที่ 407 ถูกส่งจากพร็อกซีเอง ถ้าคุณเห็น 407 แปลว่าคุณยังไม่ถึงเว็บไซต์ด้วยซ้ำ — ตัวกลางสกัดไว้ตั้งแต่ประตู

ชื่อผู้ใช้และรหัสผ่านหายไปตรงไหน

ส่วนใหญ่มักหายในสามที่

1. ไม่ได้ส่งชื่อผู้ใช้และรหัสผ่านไปในคำสั่งเลย client เคาะประตูพร็อกซีแบบไม่แสดงตัว พร็อกซีจึงปฏิเสธ
2. ส่งไปแล้วแต่มีพิมพ์ผิด เคาะวรรคเกินมาหนึ่งตัวหรือ layout คีย์บอร์ดผิด การยืนยันตัวตนก็ไม่ผ่าน
3. ส่งไปถูกต้องแล้ว แต่รหัสผ่านมีอักขระพิเศษที่ทำให้โครงสร้าง connection string พัง นี่คือสาเหตุที่แอบซ่อนที่สุด

อักขระพิเศษในรหัสผ่านและการเข้ารหัส URL

connection string ของพร็อกซีมีรูปแบบ: ชื่อผู้ใช้ โคลอน รหัสผ่าน แอด เครื่องหมาย โฮสต์ โคลอน พอร์ต ปัญหาคือ โคลอน แอด เครื่องหมาย สแลช และอักขระอื่น ๆ มีความหมายพิเศษในสตริงนี้ ถ้ารหัสผ่านของคุณมีแอด เครื่องหมายหรือโคลอน โปรแกรมจะเข้าใจผิดและตัดสตริงผิดที่

วิธีแก้เรียกว่าการเข้ารหัส URL อักขระพิเศษจะถูกแทนที่ด้วยเครื่องหมายเปอร์เซ็นต์ตามด้วยตัวอักษรหรือตัวเลขสองตัว ตัวอย่างเช่น แอด เครื่องหมายกลายเป็น เปอร์เซ็นต์สี่ศูนย์ โคลอนกลายเป็น เปอร์เซ็นต์สามเอ สแลชกลายเป็น เปอร์เซ็นต์ทูเอฟ เคาะวรรคกลายเป็น เปอร์เซ็นต์ทูศูนย์

1. ค้นหาอักขระพิเศษทั้งหมดในรหัสผ่านของคุณ
2. แทนที่แต่ละตัวด้วย URL code ของมัน
3. ประกอบ connection string ใหม่โดยใช้รหัสผ่านที่เข้ารหัสแล้ว
4. ส่งคำขออีกครั้ง

เคล็ดลับ: อย่าเข้ารหัสด้วยมือถ้ารหัสผ่านซับซ้อน ใน Python มีฟังก์ชันสำหรับเข้ารหัสชื่อ quote จากโมดูล urllib.parse ส่งรหัสผ่านเข้าไป แล้วมันจะคืนเวอร์ชันที่ปลอดภัย วิธีนี้ขจัดข้อผิดพลาดจากการพิมพ์ด้วยมือ

ตัวอย่าง curl

ข้อความ error จริงเมื่อการยืนยันตัวตนไม่ถูกต้องมีลักษณะดังนี้: curl (56) Received HTTP code 407 from proxy after CONNECT หรือบนเว็บ HTTP: HTTP 407 Proxy Authentication Required คำสั่งที่ถูกต้องพร้อมการยืนยันตัวตน: curl -v --proxy-user ชื่อผู้ใช้:รหัสผ่าน -x http://โฮสต์:พอร์ต https://ตัวอย่าง-เว็บไซต์ การใช้ flag --proxy-user มักเชื่อถือได้กว่าการเขียนข้อมูลลงใน address โดยตรง เพราะ curl จะจัดการอักขระให้อย่างถูกต้องเอง

ตัวอย่าง Python requests

ใน requests พร็อกซีระบุผ่าน dictionary คีย์ http และ https ค่าคือ connection string ถ้ารหัสผ่านมีอักขระพิเศษ ให้ห่อด้วยฟังก์ชัน quote ข้อผิดพลาดทั่วไปใน response: response.status_code จะคืน 407 และใน body จะมีข้อความ Proxy Authentication Required ให้ตรวจสอบ status code เป็นหลัก ไม่ใช่แค่ข้อความ

ตัวอย่าง Node.js

ใน Node เมื่อใช้ client ยอดนิยม พร็อกซีระบุผ่าน agent พิเศษ ข้อผิดพลาดจริงมีลักษณะเป็น object ที่มีฟิลด์ statusCode เท่ากับ 407 หรือเป็น promise ที่ reject พร้อมข้อความ error เกี่ยวกับการยืนยันตัวตน tunnel ตรวจสอบให้แน่ใจว่าคุณส่ง header ยืนยันตัวตนพร็อกซี ไม่ใช่ header ยืนยันตัวตนเว็บไซต์ — สองอย่างนี้ต่างกัน

⚠️ ข้อควรระวัง: header ยืนยันตัวตนสำหรับพร็อกซีกับ header ยืนยันตัวตนสำหรับเว็บไซต์เป็นสอง header ที่ต่างกัน ตัวหนึ่งชื่อ Proxy-Authorization อีกตัวชื่อ Authorization ถ้าสลับกันจะได้ 407 จากพร็อกซีหรือ 401 จากเว็บไซต์ ตรวจสอบว่าไลบรารีของคุณส่ง header ตัวไหน

✅ ตรวจสอบ: หลังจากแก้การยืนยันตัวตนแล้ว code ของคำตอบควรเปลี่ยนจาก 407 เป็นอย่างอื่น ถึงเว็บไซต์จะตอบ error ของตัวเอง ก็ถือว่าคืบหน้าแล้ว: คุณผ่านพร็อกซีและไปถึงเว็บไซต์ได้

ขั้นตอนที่ 3: ข้อผิดพลาด 502 จากพร็อกซี

เป้าหมายของขั้นนี้: เรียนรู้ที่จะเข้าใจว่าเมื่อไหร่ 502 หมายถึงปัญหาของเว็บไซต์เป้าหมาย และเมื่อไหร่คือความล้มเหลวของช่องทางพร็อกซีเอง

502 หมายถึงอะไร

รหัส 502 ชื่อ Bad Gateway คือ gateway แย่ มันบอกว่าตัวกลางพยายามติดต่อจุดถัดไป แต่ได้คำตอบที่ไม่ชัดหรือถูกตัดขาด ปัญหาคือ 502 ปรากฏได้ในสองสถานการณ์ที่ต่างกันสิ้นเชิง และภายนอกดูคล้ายกัน

เมื่อโฮสต์เป้าหมายผิด

สถานการณ์แรก: พร็อกซีเชื่อมต่อกับเว็บไซต์เป้าหมายสำเร็จ แต่เว็บไซต์คืนขยะ ตัดการเชื่อมต่อ หรือตัวมันเองดึงคำตอบจาก backend ไม่ได้ ในกรณีนี้พร็อกซีส่ง 502 ต่อมาอย่างซื่อสัตย์ว่า: ฉันไปถึงเว็บไซต์แล้ว แต่เว็บไซต์ตอบแย่

1. ส่งคำขอเดิมโดยตรงไม่ผ่านพร็อกซี
2. ถ้าโดยตรงเว็บไซต์ก็ตอบ 502 หรือค้าง แปลว่าเว็บไซต์ผิด ไม่ใช่พร็อกซี
3. ในกรณีนี้เปลี่ยนพร็อกซีก็ไม่มีประโยชน์ ปัญหาอยู่ฝั่งเป้าหมาย

เมื่อช่องทางเองผิด

สถานการณ์ที่สอง: พร็อกซีเองไม่เสถียร ช่องทาง上层ขาด หรือพร็อกซีตั้งการเชื่อมต่อกับเว็บไซต์ไม่ได้ด้วยซ้ำ แล้ว 502 ก็คือสัญญาณว่าตัวกลางป่วย

1. ส่งคำขอผ่านพร็อกซีเดียวกันไปยังเว็บไซต์ที่เสถียรแน่ ๆ
2. ถ้าแม้แต่เว็บไซต์ที่เสถียรก็คืน 502 แปลว่าปัญหาอยู่ที่ช่องทางพร็อกซี
3. ลองพร็อกซีอื่นหรือ node อื่นถ้ามี

เคล็ดลับ: วิธีตรวจสอบแบบไขว้ได้ผลเสมอ เปลี่ยนทีละตัวแปร เริ่มจากตรึงพร็อกซีและเปลี่ยนเว็บไซต์ จากนั้นตรึงเว็บไซต์และเปลี่ยนพร็อกซี จุดตัดของผลลัพธ์จะแสดงผู้กระทำผิด

ข้อความ error จริง

ใน curl คุณจะเห็น HTTP response code 502 และมักมีหน้า HTML ที่เขียนว่า Bad Gateway บางครั้งใน header ของคำตอบจะเห็นสัญญาณว่าเซิร์ฟเวอร์ใดส่งมา ใน Python requests คือ response.status_code เท่ากับ 502 ใน Node คือฟิลด์ statusCode เท่ากับ 502 ให้สังเกต body ของคำตอบ: หน้าที่จัดรูปแบบของเว็บไซต์เป้าหมายบ่งชี้ว่าคำขอไปถึงเว็บไซต์ ขณะที่หน้าเทคนิคง่าย ๆ มักมาจากพร็อกซี

⚠️ ข้อควรระวัง: อย่ารีบโทษพร็อกซีเมื่อเจอ 502 ครั้งแรก เว็บไซต์เป้าหมายคืน 502 บ่อยมาก โดยเฉพาะเมื่อมีภาระสูง ควรส่งคำขอควบคุมโดยตรงก่อนเปลี่ยนการตั้งค่าพร็อกซีเสมอ

✅ ตรวจสอบ: คุณต้องสามารถบอกได้จากผลของคำขอไขว้สองครั้งว่า 502 นี้มาจากเว็บไซต์หรือพร็อกซี ถ้ายังทำไม่ได้ ให้ส่งคำขอควบคุมทั้งสองซ้ำและเปรียบเทียบผลลัพธ์

ขั้นตอนที่ 4: ข้อผิดพลาด 504 และ timeout

เป้าหมายของขั้นนี้: เรียนรู้ที่จะแยกความต่างของ timeout สองประเภทที่ต่างกันโดยสิ้นเชิง และตั้งค่าใน client ได้อย่างถูกต้อง

504 หมายถึงอะไร

รหัส 504 ชื่อ Gateway Timeout คือ gateway รอคำตอบไม่ไหว มันบอกว่าตัวกลางรอคำตอบจากจุดถัดไปนานเกินไปและยอมแพ้ แต่จะเข้าใจว่าเวลาติดอยู่ตรงไหน ต้องแยก timeout สองประเภทนี้ก่อน

Connect timeout กับ read timeout

มีช่วงเวลารอที่ต่างกันโดยสิ้นเชิงสองจุด

• Connect timeout คือเวลาสำหรับสร้างการเชื่อมต่อ client พยายามต่อถึงพร็อกซี หรือพร็อกซีต่อถึงเว็บไซต์ ถ้าเชื่อมต่อไม่สำเร็จในเวลาที่กำหนด connect timeout จะทำงาน ปกติเป็นสัญญาณว่า address เข้าไม่ถึงหรือพอร์ตปิด
• Read timeout คือเวลารอคำตอบหลังจากเชื่อมต่อสำเร็จแล้ว มีการเชื่อมต่ออยู่ คำขอออกไปแล้ว แต่ข้อมูลไม่มา ปกติเป็นสัญญาณว่าเว็บไซต์คิดนานหรือค้างอยู่ที่การประมวลผล

วิธีแยกใน client

การวินิจฉัยที่ถูกต้องเริ่มจากการตั้ง timeout ทั้งสองแยกกัน แล้วคุณจะเข้าใจทันทีว่าเวลาติดอยู่ที่ขั้นตอนไหน

1. ใน curl ใช้ flag --connect-timeout เพื่อจำกัดเวลาสร้างการเชื่อมต่อ แยก flag --max-time จำกัดเวลารวมทั้งหมดของการดำเนินการ
2. ใน Python requests พารามิเตอร์ timeout ส่งเป็น tuple สองตัวเลขได้ ตัวแรกคือ connect timeout ตัวที่สองคือ read timeout ตัวอย่าง timeout ห้าวินาทีและสามสิบวินาที
3. ใน Node client ส่วนใหญ่มีการตั้งค่าแยกสำหรับเวลาเชื่อมต่อและเวลารอคำตอบ ตั้งให้ต่างกันเพื่อให้เห็นว่าตัวไหนทำงาน

วิธีอ่านผลลัพธ์

ถ้า connect timeout ทำงาน แปลว่าคุณยังสร้างการเชื่อมต่อไม่สำเร็จด้วยซ้ำ ให้ตรวจสอบการเข้าถึงพร็อกซีและความถูกต้องของพอร์ต ถ้า read timeout ทำงาน แปลว่ามีการเชื่อมต่ออยู่ แต่คำตอบมาไม่ทันเวลา ให้ตรวจสอบว่าเว็บไซต์โหลดหนักหรือคำขอหนักเกินไปหรือไม่

เคล็ดลับ: ตั้ง connect timeout ให้น้อย ประมาณห้าวินาที การสร้างการเชื่อมต่อจะเกิดขึ้นเร็วหรือไม่เกิดขึ้นเลย ส่วน read timeout ให้ตั้งเผื่อ เพราะบางหน้าจอใช้เวลาเตรียมคำตอบนานจริง ๆ

⚠️ ข้อควรระวัง: read timeout ที่เล็กเกินไปทำให้เกิด error หลอก คุณจะตัดคำตอบที่ปกติแต่ช้า และคิดว่าพร็อกซีเสีย ตรวจสอบเสมอว่าคุณไม่ได้ตั้ง limit เข้มเกินไปเอง

ข้อความ error จริง

ใน curl connect timeout มีข้อความว่า Connection timed out ทาง stderr ใน Python requests เป็น exception ConnectTimeout สำหรับการเชื่อมต่อ และ ReadTimeout สำหรับคำตอบ ชื่อ exception บอกคุณทันทีว่าขั้นตอนไหนล้มเหลว ใน Node คุณจะเห็น error ที่มี code ETIMEDOUT หรือข้อความเฉพาะเรื่องการเกินเวลาตอบ

✅ ตรวจสอบ: หลังตั้ง timeout แยกกันแล้ว คุณต้องได้ข้อความ error ที่ระบุชัดว่า: เป็น timeout ของการเชื่อมต่อหรือ timeout ของการอ่าน ถ้าเห็นแค่คำว่า timeout ทั่ว ๆ โดยไม่มีรายละเอียด แสดงว่ายังไม่ได้แยก timeout

ขั้นตอนที่ 5: ข้อผิดพลาด tunnel connection failed และวิธี CONNECT

เป้าหมายของขั้นนี้: เข้าใจว่าทำไม error นี้ปรากฏเฉพาะบนเว็บที่ปลอดภัย และวิธีวินิจฉัย

ทำไม error นี้มาบน HTTPS เท่านั้น

เมื่อคุณเข้าเว็บ HTTP ธรรมดา พร็อกซีแค่ส่งคำขอต่อ แต่เมื่อคุณเข้าเว็บ HTTPS เนื้อหาถูกเข้ารหัส พร็อกซีอ่านไม่ได้ ดังนั้น client ต้องส่งคำสั่งพิเศษชื่อ CONNECT พร้อมที่อยู่เว็บให้พร็อกซีก่อน คำสั่งนี้หมายถึงคำขอว่า: ช่วยสร้าง tunnel ที่ปลอดภัยไปยังที่อยู่นี้ให้ฉันหน่อย ฉันจะคุยกับเว็บไซต์ผ่านคุณตรง ๆ

ถ้าพร็อกซีสร้าง tunnel ไม่ได้ด้วยเหตุใดก็ตาม มันจะคืนข้อผิดพลาด tunnel connection failed บน HTTP ธรรมดาไม่มีคำสั่งนี้ จึงไม่มี error นี้ นี่คือสัญญาณระบุตัวตนหลักของคุณ

สาเหตุหลักที่ tunnel ล้มเหลว

• พร็อกซีเชื่อมต่อกับที่อยู่เป้าหมายไม่ได้ อาจเป็นเพราะเว็บไซต์เข้าไม่ได้หรือพอร์ตปิด
• พร็อกซีห้ามวิธี CONNECT ไปยังที่อยู่หรือพอร์ตนี้ พร็อกซีบางตัวอนุญาตเฉพาะพอร์ตที่กำหนด
• การยืนยันตัวตนไม่ผ่าน ในกรณีนี้คุณมักเห็นการรวมกัน: พยายาม CONNECT ก่อน แล้วตามด้วยรหัส 407
• พร็อกซีโหลดหนักหรือช่องทาง上层ขาดในขณะสร้าง tunnel

วิธีวินิจฉัย

1. รัน curl -v ไปยังที่อยู่ HTTPS และหาใน output บรรทัดที่มี CONNECT มันแสดงช่วงเวลาของการขอ tunnel
2. ดูว่ามีคำตอบอะไรกลับมาที่ CONNECT คำตอบ code 200 หมายถึง tunnel สร้างสำเร็จ code อื่นหมายถึงล้มเหลว
3. ถ้าเห็น 407 ใกล้ ๆ แปลว่าปัญหาอยู่ที่การยืนยันตัวตน ไม่ใช่ตัว tunnel กลับไปขั้นตอน 407
4. ถ้าเห็นการปฏิเสธการเชื่อมต่อ แปลว่าพร็อกซีต่อถึงเว็บไซต์ไม่ได้

เคล็ดลับ: ตรวจสอบว่าคุณเข้าถึงพอร์ตที่อนุญาตจริง พอร์ตมาตรฐานสำหรับการเชื่อมต่อที่ปลอดภัยมักอนุญาต ขณะที่พอร์ตที่ไม่มาตรฐานพร็อกซีจำนวนมากบล็อก การเปลี่ยนพอร์ตเป็นมาตรฐานมักแก้ปัญหาได้ทันที

ข้อความ error จริง

ใน curl เป็นข้อความแบบ curl (56) Received HTTP code จาก proxy after CONNECT หรือ tunnel connection failed ตรง ๆ ใน Python requests เป็น exception ProxyError พร้อมข้อความซ้อนเรื่อง tunnel ไม่สำเร็จ ใน Node เป็น error ที่มีข้อความว่าสร้างการเชื่อมต่อ tunnel ไม่ได้ มักระบุ code สถานะจากพร็อกซีด้วย

⚠️ ข้อควรระวัง: อย่าสับสนระหว่าง tunnel ล้มเหลวกับ error ใบรับรอง ถ้า tunnel สร้างแล้วแต่ภายหลังมีปัญหาเรื่องใบรับรองของเว็บไซต์ นั่นเป็นปัญหาอีกเรื่องที่ไม่เกี่ยวกับชั้นพร็อกซี ให้ดูว่า error เกิดที่ขั้นตอนไหน: ก่อนหรือหลังคำตอบ CONNECT

✅ ตรวจสอบ: คุณต้องหาใน output ของ curl บรรทัดที่มีคำตอบต่อ CONNECT และเข้าใจจาก code ว่า tunnel สร้างสำเร็จหรือไม่ code 200 — มี tunnel code อื่น — หาสาเหตุที่ล้มเหลว

ขั้นตอนที่ 6: ข้อผิดพลาด 403 จากพร็อกซี

เป้าหมายของขั้นนี้: เรียนรู้ที่จะจดจำเมื่อ 403 ถูกส่งจากพร็อกซีเนื่องจาก limit, ภูมิศาสตร์ หรือพอร์ตต้องห้าม

403 ในบริบทของพร็อกซีหมายถึงอะไร

รหัส 403 ชื่อ Forbidden คือ ห้าม ปกติรหัสนี้ถูกส่งจากเว็บไซต์เป้าหมายเมื่อมันปิดการเข้าถึง แต่พร็อกซีก็ส่ง 403 ได้เช่นกันเมื่อมันตัดสินใจไม่ให้คำขอของคุณผ่าน ภารกิจคือเข้าใจว่าใครเป็นคนสั่งห้าม

สามสาเหตุของ 403 จากพร็อกซี

• Limit พร็อกซีอาจจำกัดจำนวนคำขอ ปริมาณทราฟฟิก หรือจำนวนการเชื่อมต่อพร้อมกัน เมื่อเกินจะคืน 403 เป็นการปฏิเสธให้บริการ
• ข้อจำกัดทางภูมิศาสตร์ พร็อกซีบางตัวอนุญาตให้เข้าถึงเฉพาะบางภูมิภาค หรือในทางกลับกัน ห้ามบางทิศทาง คำขอไปยังทิศทางที่ปิดจะได้ 403
• พอร์ตต้องห้าม พร็อกซีอาจอนุญาตเฉพาะพอร์ตมาตรฐาน การเข้าถึงพอร์ตที่ไม่มาตรฐานจบลงด้วยการปฏิเสธ

วิธีแยก 403 ของพร็อกซีจาก 403 ของเว็บไซต์

1. ดู body ของคำตอบ หน้าที่จัดรูปแบบของเว็บไซต์เป้าหมายพร้อมดีไซน์ของมัน หมายถึงเว็บไซต์เป็นคนสั่งห้าม
2. หน้าเทคนิคง่าย ๆ หรือข้อความที่กล่าวถึงพร็อกซี หมายถึงตัวกลางเป็นคนสั่งห้าม
3. ส่งคำขอเดิมโดยตรง ถ้าโดยตรงเว็บไซต์คืน 403 และผ่านพร็อกซีก็คืน 403 แปลว่าเว็บไซต์ผิด
4. ถ้าโดยตรงเว็บไซต์เปิดได้ แต่ผ่านพร็อกซีคืน 403 ให้หาสาเหตุใน limit หรือข้อจำกัดของพร็อกซี

เคล็ดลับ: ตรวจสอบเอกสารหรือแผงจัดการของพร็อกซีเรื่อง limit บ่อยครั้งในหน้าสมาชิกจะเห็นว่าทราฟฟิกหมดหรือถึง limit คำขอแล้ว นี่คือวิธีที่เร็วที่สุดในการยืนยันสาเหตุ

⚠️ ข้อควรระวัง: อย่าพยายามหลบเลี่ยง limit ของพร็อกซีด้วยวิธีการแยบยล ถ้าคุณติดข้อจำกัดของแพ็กเกจ วิธีที่ถูกต้องคืออัปเกรดแพ็กเกจหรือปรับจำนวนคำขอให้เหมาะสม การหลบเลี่ยงข้อจำกัดทางเทคนิคของบริการเป็นการละเมิดเงื่อนไขการใช้งาน

ข้อความ error จริง

ใน curl เป็น HTTP response 403 Forbidden พร้อม body ที่บอกแหล่งที่มา ใน Python requests คือ response.status_code เท่ากับ 403 ใน Node คือ statusCode เท่ากับ 403 วิเคราะห์ body ของคำตอบพร้อม code เสมอ เพราะ body คือสิ่งที่เปิดเผยผู้สั่งห้ามที่แท้จริง

✅ ตรวจสอบ: คุณต้องระบุได้จาก body ของคำตอบและผลของคำขอโดยตรงว่าใครส่ง 403 ถ้าเป็นพร็อกซี — ตรวจสอบ limit, ภูมิศาสตร์ และพอร์ต ถ้าเป็นเว็บไซต์ — สาเหตุไม่อยู่ที่ชั้นพร็อกซี

ขั้นตอนที่ 7: การเชื่อมต่อขาดโดยไม่มีคำตอบ — connection reset และ EOF

เป้าหมายของขั้นนี้: เรียนรู้ที่จะวินิจฉัยกรณีที่ลึกลับที่สุด เมื่อไม่มีคำตอบเลยและการเชื่อมต่อขาดไปเฉย ๆ

error เหล่านี้คืออะไร

บางครั้งคุณไม่ได้รับ HTTP code ใด ๆ เลย แต่การเชื่อมต่อกลับขาดไปกะทันหัน มีสองอาการทั่วไป

• Connection reset แปลตรงตัวว่า การเชื่อมต่อถูก reset ฝ่ายใดฝ่ายหนึ่งปิดช่องทางทันทีโดยไม่จบการสนทนา เหมือนคู่สนทนาวางสายกลางคำ
• EOF, unexpected end of file แปลตรงตัวว่า จุดสิ้นสุดข้อมูลที่ไม่คาดคิด client รอคำตอบต่อ แต่สายข้อมูลกลับสิ้นสุดกะทันหัน

สิ่งที่ต้องดูก่อน

1. ระบุช่วงเวลาที่ขาด เกิดขึ้นก่อนคำตอบ CONNECT ระหว่างส่งคำขอ หรือระหว่างรับคำตอบ? output ของ curl -v จะแสดงบรรทัดที่สำเร็จล่าสุดก่อนขาด
2. ถ้าขาดตั้งแต่เริ่มต้น ขณะเชื่อมต่อกับพร็อกซี น่าจะเป็นปัญหาที่พร็อกซีเองหรือเส้นทางเครือข่ายไปถึงมัน
3. ถ้าขาดหลังสร้าง tunnel ระหว่างคุยกับเว็บไซต์ น่าจะเป็นปัญหาจากฝั่งเว็บไซต์หรือช่องทางไม่เสถียร
4. ส่งคำขอซ้ำหลายครั้ง การขาดที่เกิดซ้ำสม่ำเสมอแสดงถึงสาเหตุเชิงระบบ ส่วนที่เกิดแบบสุ่มแสดงถึงความไม่เสถียรชั่วคราวของเครือข่าย

สาเหตุที่พบบ่อย

• พร็อกซีโหลดหนักและปิดการเชื่อมต่อส่วนเกินแบบบังคับ
• ช่องทาง上层ของพร็อกซีไม่เสถียรและขาด
• เว็บไซต์เป้าหมายปิดการเชื่อมต่อเนื่องจากข้อจำกัดของตัวเอง
• ปัญหาเครือข่ายระหว่างจุดต่าง ๆ ในห่วงโซ่

เคล็ดลับ: เมื่อขาดแบบสุ่ม ให้เก็บสถิติ ส่งคำขอติดกันเช่นยี่สิบครั้ง แล้วนับว่าขาดกี่ครั้ง ถ้าขาดหนึ่งในยี่สิบ ถือว่าความไม่เสถียรพอรับได้ ถ้าขาดครึ่งหนึ่ง แปลว่ามีปัญหาเชิงระบบที่ต้องแก้

ข้อความ error จริง

ใน curl เป็น Connection reset by peer หรือ Empty reply from server ใน Python requests เป็น exception ConnectionError พร้อมข้อความซ้อนเรื่องการ reset การเชื่อมต่อ ใน Node เป็น error ที่มี code ECONNRESET ข้อความเหล่านี้ไม่มี HTTP code เพราะการแลกเปลี่ยน HTTP ไม่ได้จบอย่างปกติ

⚠️ ข้อควรระวัง: การขาดโดยไม่มีคำตอบสับสนกับ timeout ได้ง่าย ความต่างคือ ใน timeout client เองหยุดรอ ขณะที่ reset อีกฝ่ายปิดช่องทางอย่างจริงจัง ให้ดูข้อความ error: คำว่า reset บ่งชี้การ reset โดยตรง คำว่า timeout บ่งชี้การหมดเวลารอ

✅ ตรวจสอบ: คุณต้องระบุได้จากบรรทัดสุดท้ายของ output curl ว่าการเชื่อมต่อขาดที่ขั้นตอนไหน วิธีนี้จำกัดวงผู้ต้องสงสัยเหลือหนึ่งหรือสองจุดทันที

ขั้นตอนที่ 8: ภาคปฏิบัติ — อ่าน curl -v ทีละบรรทัด

เป้าหมายของขั้นนี้: เรียนรู้ที่จะเห็นใน output ของ curl ขอบเขตระหว่าง client, พร็อกซี และเซิร์ฟเวอร์ นี่คือจุดสูงสุดของคู่มือทั้งหมด

สัญลักษณ์ที่ต้นบรรทัดหมายถึงอะไร

output ของ curl -v ใช้สัญลักษณ์พิเศษที่ต้นบรรทัดแต่ละบรรทัด และนี่คือกุญแจสำคัญในการเข้าใจ

• เครื่องหมายดอกจันต้นบรรทัดหมายถึงข้อความข้อมูลของ curl เอง เป็นความเห็นของ client เกี่ยวกับสิ่งที่มันทำ: สร้างการเชื่อมต่อ, สร้าง tunnel, ตรวจสอบใบรับรอง
• ลูกศรชี้ขวาหมายถึงข้อมูลที่ client ส่งไปยังพร็อกซีหรือเซิร์ฟเวอร์ เป็นคำขอขาออก
• ลูกศรชี้ซ้ายหมายถึงข้อมูลที่ client ได้รับกลับ เป็นคำตอบขาเข้า

ขอบเขต client-proxy-server อยู่ตรงไหน

มาดูเส้นทางทั่วไปไปยังเว็บที่ปลอดภัยผ่านพร็อกซี เริ่มแรก curl แจ้งด้วยเครื่องหมายดอกจันว่ากำลังเชื่อมต่อกับพร็อกซีที่ address และพอร์ตที่ระบุ นี่คือช่วง client-proxy จากนั้นมีลูกศรขาออกพร้อมคำสั่ง CONNECT — client ขอให้พร็อกซีสร้าง tunnel ต่อไปลูกศรขาเข้าพร้อมคำตอบต่อ CONNECT — นี่คือคำตอบของพร็อกซี ถ้า code 200 tunnel ถูกสร้างแล้ว และขอบเขตจะเลื่อน: ต่อจากนี้การแลกเปลี่ยนทั้งหมดเป็น client-server ผ่าน tunnel

วิเคราะห์ log จริง

สมมติว่าคุณเห็นลำดับดังนี้ บรรทัดที่มีเครื่องหมายดอกจัน: กำลังเชื่อมต่อกับ address และพอร์ตของพร็อกซี นี่หมายถึง client หาพร็อกซีเจอแล้ว บรรทัดถัดไปที่มีเครื่องหมายดอกจัน: การเชื่อมต่อกับพร็อกซีสำเร็จ เยี่ยม ช่วงแรกผ่านแล้ว ต่อไปลูกศรขาออก: CONNECT ไปยัง address ของเว็บไซต์เป้าหมาย client ขอ tunnel แล้ว จากนั้นลูกศรขาเข้า: คำตอบต่อ CONNECT พร้อม code นี่คือทางแยกสำคัญ

1. ถ้า code ของคำตอบต่อ CONNECT คือ 200 tunnel ถูกสร้างแล้ว อ่านต่อ
2. ถ้า code คือ 407 พร็อกซีต้องการการยืนยันตัวตน ปัญหาอยู่ที่ชั้นพร็อกซี ช่วง client-proxy ไปที่ขั้นตอน 407
3. ถ้าบรรทัดเขียนว่า tunnel connection failed พร็อกซีสร้าง tunnel ไม่ได้ สาเหตุอยู่ระหว่างพร็อกซีกับเว็บไซต์

สมมติว่า tunnel สร้างแล้ว ต่อไปมีเครื่องหมายดอกจันเรื่องการตรวจสอบการเชื่อมต่อที่ปลอดภัยกับเว็บไซต์ นี่คือช่วง client-server แล้ว จากนั้นลูกศรขาออกพร้อมคำขอจริง: บรรทัดคำขอและ header สังเกตว่า: จนถึงตอนนี้เว็บไซต์ยังไม่เห็นคำขอของคุณเลย มันเพิ่งสร้าง tunnel เสร็จ และในที่สุดลูกศรขาเข้าพร้อม code คำตอบของเว็บไซต์ นี่คือจุดที่ความรับผิดชอบของเว็บไซต์เป้าหมายเริ่มต้น

วิธีประยุกต์ใช้ในการวินิจฉัย

1. หาบรรทัดสร้างการเชื่อมต่อกับพร็อกซี ถ้าไม่มีหรือมี error ปัญหาอยู่ระหว่าง client กับพร็อกซี
2. หาคำตอบต่อ CONNECT ดู code เพื่อระบุว่าชั้นพร็อกซีผ่านหรือไม่
3. หาลูกศรขาเข้าพร้อมคำตอบของเว็บไซต์ ถ้ามี แปลว่าคุณไปถึงเว็บไซต์แล้ว และ error ใด ๆ ที่นี่อยู่ในเขตเว็บไซต์
4. บรรทัดสุดท้ายก่อนขาดจะบอกได้เสมอว่าทุกอย่างพังที่ช่วงไหน

เคล็ดลับ: อ่าน output จากบนลงล่างเหมือนบันทึกการเดินทางของคำขอ แต่ละบรรทัดคือก้าวหนึ่งของการเดินทาง เมื่อถึงบรรทัดที่มี error หรือขาด ให้ดูบรรทัดที่สำเร็จก่อนหน้า มันจะชี้จุดสุดท้ายที่ยังมีชีวิต

⚠️ ข้อควรระวัง: flag -v แสดง header รวมถึงบรรทัดการยืนยันตัวตนพร็อกซี ถ้าคุณแชร์ log ให้คนอื่นช่วย ต้องปิดบรรทัดที่มีข้อมูลยืนยันตัวตนทุกครั้ง ไม่ฉะนั้นคุณจะเปิดเผยชื่อผู้ใช้และรหัสผ่าน

✅ ตรวจสอบ: หยิบ log curl -v ของคุณสักอัน แล้วทำเครื่องหมาย: ช่วง client-proxy อยู่ตรงไหน, คำตอบต่อ CONNECT อยู่ตรงไหน, เขตเว็บไซต์เริ่มต้นตรงไหน ถ้าคุณขีดเส้นเหล่านี้ได้อย่างมั่นใจ แสดงว่าคุณเชี่ยวชาญทักษะวินิจฉัยหลักแล้ว

ขั้นตอนที่ 9: ตารางวินิจฉัยด่วน อาการ-สาเหตุ-สิ่งที่ต้องตรวจสอบ

เป้าหมายของขั้นนี้: ได้คู่มือพร้อมใช้สำหรับเปิดดูได้ในทุกช่วงที่เกิด error

วิธีใช้ตาราง

หาอาการของคุณในคอลัมน์แรก อ่านสาเหตุที่น่าจะเป็น ทำตามการกระทำในคอลัมน์ที่สามก่อน — มันมีแนวโน้มสูงสุดที่จะยืนยันหรือหักล้างสาเหตุ

อาการ: รหัส 407

สาเหตุที่น่าจะเป็น: ไม่ได้ส่งหรือส่งข้อมูลยืนยันตัวตนพร็อกซีผิด หรืออักขระพิเศษในรหัสผ่านทำให้ connection string พัง สิ่งแรกที่ต้องตรวจสอบ: ความถูกต้องของชื่อผู้ใช้และรหัสผ่าน รวมถึงการเข้ารหัส URL ของอักขระพิเศษในรหัสผ่าน

อาการ: tunnel connection failed บน HTTPS

สาเหตุที่น่าจะเป็น: พร็อกซีสร้าง tunnel ไปยังเว็บไซต์ไม่ได้ อาจเนื่องจากพอร์ตต้องห้ามหรือเว็บไซต์เข้าไม่ได้ สิ่งแรกที่ต้องตรวจสอบ: คำตอบต่อ CONNECT ใน output ของ curl -v และการอนุญาตพอร์ตเป้าหมาย

อาการ: รหัส 502

สาเหตุที่น่าจะเป็น: คำตอบแย่จากจุดถัดไป ผิดที่เว็บไซต์หรือช่องทางพร็อกซีที่ไม่เสถียร สิ่งแรกที่ต้องตรวจสอบ: คำขอไขว้ — เว็บไซต์เดิมโดยตรงและพร็อกซีเดิมไปยังเว็บไซต์ที่เสถียร

อาการ: รหัส 504

สาเหตุที่น่าจะเป็น: หมดเวลารอ ต้องเข้าใจว่าเป็นการเชื่อมต่อหรือคำตอบ สิ่งแรกที่ต้องตรวจสอบ: connect timeout และ read timeout แยกกัน เพื่อดูว่าขั้นตอนไหนใช้เวลานาน

อาการ: รหัส 403 ผ่านพร็อกซี

สาเหตุที่น่าจะเป็น: limit ของพร็อกซี ข้อจำกัดทางภูมิศาสตร์ หรือพอร์ตต้องห้าม สิ่งแรกที่ต้องตรวจสอบ: body ของคำตอบเพื่อดูแหล่งที่มาของการห้าม และแผงจัดการพร็อกซีเรื่อง limit ที่หมดไป

อาการ: connection reset หรือ ECONNRESET

สาเหตุที่น่าจะเป็น: ฝ่ายใดฝ่ายหนึ่งปิดการเชื่อมต่อแบบบังคับ มักเป็นพร็อกซีโหลดหนักหรือช่องทางไม่เสถียร สิ่งแรกที่ต้องตรวจสอบ: ช่วงที่ขาดจากบรรทัดสุดท้ายของ curl -v และความสม่ำเสมอของปัญหาจากชุดคำขอ

อาการ: EOF, empty reply

สาเหตุที่น่าจะเป็น: สายข้อมูลขาดก่อนถึงจุดสิ้นสุดของคำตอบ สิ่งแรกที่ต้องตรวจสอบ: การขาดเกิดขึ้นที่ช่วงไหน — ก่อนหรือหลังคำตอบต่อ CONNECT

อาการ: connect timeout

สาเหตุที่น่าจะเป็น: สร้างการเชื่อมต่อไม่ได้ address เข้าไม่ถึงหรือพอร์ตปิด สิ่งแรกที่ต้องตรวจสอบ: การเข้าถึง address ของพร็อกซีและความถูกต้องของพอร์ต

อาการ: read timeout

สาเหตุที่น่าจะเป็น: มีการเชื่อมต่ออยู่ แต่คำตอบไม่มา เว็บไซต์ประมวลผลนานหรือค้าง สิ่งแรกที่ต้องตรวจสอบ: read timeout ของคุณเล็กเกินไปหรือไม่ และเว็บไซต์โหลดหนักหรือไม่

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

✅ ตรวจสอบ: ลองไล่ตารางกับ error ล่าสุดของคุณทุกอัน สำหรับทุกอันคุณต้องรู้ว่าการตรวจสอบแรกคืออะไร

ตรวจสอบผลลัพธ์: เช็กลิสต์นักวินิจฉัย

ตรวจสอบให้แน่ใจว่าคุณเชี่ยวชาญทักษะหลักทั้งหมด ไล่เช็กลิสต์

• คุณตอบได้ในไม่กี่วินาทีว่าใครส่ง error — พร็อกซีหรือเว็บไซต์
• คุณเข้าใจความต่างระหว่าง 407 กับ 401 และแก้การยืนยันตัวตนได้ รวมถึงอักขระพิเศษในรหัสผ่าน
• คุณแยก 502 จากเว็บไซต์กับ 502 จากพร็อกซีได้ผ่านการตรวจสอบไขว้
• คุณแยก connect timeout กับ read timeout และรู้ว่าแต่ละอันหมายถึงอะไร
• คุณเข้าใจว่าทำไม tunnel connection failed เกิดเฉพาะบน HTTPS และอ่านคำตอบต่อ CONNECT ได้
• คุณจดจำสามสาเหตุของ 403 จากพร็อกซีได้: limit, ภูมิศาสตร์ และพอร์ต
• คุณวินิจฉัยการขาดการเชื่อมต่อได้จากขั้นตอนที่เกิดขึ้น
• คุณอ่าน output ของ curl -v ทีละบรรทัดและขีดเส้นขอบเขต client-proxy-server ได้

วิธีทดสอบตัวเอง

1. หยิบ log จริงสามอันที่มี error ต่างกัน
2. สำหรับแต่ละอัน ระบุจุดที่ผิดภายในหนึ่งนาที
3. บอกการตรวจสอบแรกตามตาราง
4. ถ้าทำได้ทั้งสามอัน แสดงว่าคุณเชี่ยวชาญการวินิจฉัยแล้ว

✅ ตรวจสอบ: ตัวชี้วัดความสำเร็จคือ คุณไม่ตื่นตระหนกเมื่อเห็น error พร็อกซีอีกต่อไป แต่ค่อย ๆ แยกมันตามจุดในห่วงโซ่ได้อย่างใจเย็น

ข้อผิดพลาดทั่วไปและวิธีแก้

ปัญหา: เปลี่ยนพร็อกซีทันทีเมื่อเจอ error ทุกอัน

สาเหตุ: ไม่มีนิสัยตรวจสอบไขว้ วิธีแก้: ส่งคำขอควบคุมโดยตรงและไปยังเว็บไซต์ที่เสถียรเสมอก่อนเปลี่ยนการตั้งค่า ครึ่งหนึ่งของ error อยู่ฝั่งเว็บไซต์

ปัญหา: รหัสผ่านที่มีแอด เครื่องหมายทำให้การเชื่อมต่อพัง

สาเหตุ: อักขระพิเศษไม่ได้เข้ารหัสและตัดสตริง วิธีแก้: ใช้การเข้ารหัส URL กับรหัสผ่าน หรือใช้พารามิเตอร์ยืนยันตัวตนแยกแทนการเขียนลง address

ปัญหา: สับสนระหว่าง 407 กับ 401

สาเหตุ: ไม่แยกการยืนยันตัวตนพร็อกซีกับการยืนยันตัวตนเว็บไซต์ วิธีแก้: จำไว้ว่า 407 มาจากพร็อกซีเสมอ 401 มาจากเว็บไซต์เสมอ ตรวจสอบว่าส่ง header ตัวไหน: Proxy-Authorization หรือ Authorization

ปัญหา: timeout เข้มเกินไปตัดคำขอปกติ

สาเหตุ: read timeout ตั้งเล็กเกินไป วิธีแก้: แยก connect กับ read timeout ให้ read timeout มีเผื่อสำหรับหน้าที่ช้า

ปัญหา: tunnel connection failed บนพอร์ตไม่มาตรฐาน

สาเหตุ: พร็อกซีห้าม CONNECT ไปยังพอร์ตนี้ วิธีแก้: ใช้พอร์ตมาตรฐานสำหรับการเชื่อมต่อที่ปลอดภัย หรือสอบถามรายการพอร์ตที่อนุญาตจากพร็อกซี

ปัญหา: เห็น 502 แล้วคิดว่าพร็อกซีตาย

สาเหตุ: ไม่ได้ตรวจว่าใครส่ง 502 วิธีแก้: การตรวจสอบไขว้ บ่อยครั้ง 502 มาจากเว็บไซต์เป้าหมายที่โหลดหนัก ขณะที่พร็อกซียังดีอยู่

ปัญหา: เปิดเผยชื่อผู้ใช้และรหัสผ่านใน log

สาเหตุ: แชร์ output ของ curl -v โดยไม่ได้ลบ วิธีแก้: ลบบรรทัดการยืนยันตัวตนก่อนส่ง log ให้ใครเสมอ และถ้าเป็นไปได้ให้เปลี่ยนข้อมูลที่รั่วไหล

ปัญหา: คิดว่าการขาดการเชื่อมต่อคือ timeout

สาเหตุ: ไม่แยก reset กับ timeout วิธีแก้: ดูข้อความ error reset — การปิดจากอีกฝ่ายอย่างจริงจัง timeout — การหมดเวลารอของคุณ เป็นสาเหตุที่ต่างกัน

ความสามารถเพิ่มเติมสำหรับผู้ขั้นสูง

การบันทึก log อย่างต่อเนื่อง

ตั้งค่าบันทึก log รายละเอียดของทุกคำขอพร็อกซีในแอปพลิเคชันของคุณ เมื่อเกิด error คุณจะมีประวัติอยู่แล้วและไม่ต้องจำลองปัญหาใหม่ บันทึก code คำตอบ ช่วงที่ขาด และเวลาดำเนินการ

การจำแนก error อัตโนมัติ

ในโค้ดสามารถสร้างฟังก์ชันที่จำแนก error ตามประเภท exception และ code คำตอบไปยังจุดที่ถูกต้องทันที ตัวอย่าง ConnectTimeout — ช่วงการเชื่อมต่อ, ReadTimeout — ช่วงคำตอบ, ProxyError พร้อม tunnel — ชั้นพร็อกซี วิธีนี้เร่งการตอบสนองในระบบอัตโนมัติ

การเก็บสถิติความเสถียร

เก็บเมตริก: สัดส่วนคำขอที่สำเร็จ, สัดส่วนการขาด, เวลาตอบเฉลี่ย การเสื่อมลงอย่างฉับพลันของเมตริกจะเตือนปัญหาก่อนที่คุณจะเจอด้วยตัวเอง

เคล็ดลับ: แยกเมตริกตามจุด นับ error สร้างการเชื่อมต่อกับ error ในช่วงคำตอบแยกกัน แล้วคุณจะเห็นทันทีว่าอะไรกำลังเสื่อม — การเข้าถึงพร็อกซีหรือการคุยกับเว็บไซต์

⚠️ ข้อควรระวัง: เมื่อสร้างการจัดการอัตโนมัติ อย่าทำให้มันกลายเป็นการส่งคำขอเดิมซ้ำไม่สิ้นสุด ตรรกะการ retry เป็นหัวข้อใหญ่แยกต่างหากที่มีกฎของตัวเอง เกี่ยวข้องกับรหัส 429 ด้วย มีบทความเฉพาะเรื่องนี้ และควรศึกษากันแยก

FAQ: คำถามที่พบบ่อยเกี่ยวกับการวินิจฉัย

จะรู้ได้เร็ว ๆ อย่างไรว่าพร็อกซีผิด ไม่ใช่โค้ดของฉัน?

ส่งคำขอเดิมโดยตรงไม่ผ่านพร็อกซี ถ้าโดยตรงใช้ได้ แต่ผ่านพร็อกซีไม่ได้ ปัญหาอยู่ที่ชั้นพร็อกซีหรือการทำงานร่วมกันกับเว็บไซต์ วิธีนี้ตัดสมมติฐานครึ่งหนึ่งได้ในหนึ่งนาที

ทำไมได้ 407 ทั้งที่ใส่รหัสผ่านถูก?

น่าจะมีอักขระพิเศษในรหัสผ่านที่ทำให้ connection string พัง ใช้การเข้ารหัส URL กับรหัสผ่าน หรือส่งข้อมูลผ่านพารามิเตอร์ยืนยันตัวตนแยกแทนการใส่ใน address

รหัส 502 หมายถึงพร็อกซีเสียเสมอหรือไม่?

ไม่ 502 อาจถูกส่งจากเว็บไซต์เป้าหมายได้เช่นกัน ถ้ามันตอบไม่ดีด้วยตัวเอง ทำการตรวจสอบไขว้: เว็บไซต์เดิมโดยตรงและพร็อกซีเดิมไปยังเว็บไซต์ที่เสถียร จุดตัดของผลลัพธ์จะแสดงผู้กระทำผิด

connect timeout ต่างจาก read timeout อย่างไร?

connect timeout คือการรอสร้างการเชื่อมต่อ read timeout คือการรอคำตอบหลังเชื่อมต่อสำเร็จแล้ว แยกทั้งสองใน client แล้วคุณจะเห็นทันทีว่าขั้นตอนไหนใช้เวลานาน

ทำไม tunnel connection failed เกิดเฉพาะบน HTTPS?

เพราะสำหรับเว็บที่ปลอดภัย client ขอให้พร็อกซีสร้าง tunnel ด้วยคำสั่ง CONNECT บน HTTP ธรรมดาไม่มีคำสั่งนี้ ถ้า tunnel สร้างไม่ได้ error นี้จะมา และมันเกิดได้เฉพาะบน HTTPS

จะแยก 403 จากพร็อกซีจาก 403 จากเว็บไซต์อย่างไร?

ดู body ของคำตอบ หน้าที่จัดรูปแบบของเว็บไซต์หมายถึงเว็บไซต์ห้าม หน้าเทคนิคหรือข้อความที่กล่าวถึงพร็อกซีหมายถึงตัวกลางห้าม ยืนยันด้วยคำขอโดยตรงไปยังเว็บไซต์

ทำอย่างไรเมื่อการเชื่อมต่อขาดแบบสุ่ม?

เริ่มจากระบุความสม่ำเสมอ: ส่งชุดคำขอแล้วนับสัดส่วนการขาด การขาดครั้งคราวคือความไม่เสถียรของเครือข่ายที่รับได้ การขาดจำนวนมากคือปัญหาเชิงระบบของพร็อกซีหรือช่องทาง

จะแชร์ log curl -v อย่างปลอดภัยได้อย่างไร?

ลบบรรทัดการยืนยันตัวตนพร็อกซีและ header ที่ละเอียดอ่อนทุกอันก่อนส่งเสมอ ไม่ฉะนั้นคุณจะเปิดเผยชื่อผู้ใช้และรหัสผ่าน ถ้ากังวล ให้เปลี่ยนข้อมูลที่รั่วไหล

ทำไมคำขอปกติของฉันบางครั้งถูกตัดด้วย timeout?

น่าจะตั้ง read timeout เข้มเกินไป และคุณตัดคำตอบที่ช้าแต่ยังปกติออกไป เพิ่ม read timeout ให้มีเผื่อ ส่วน connect timeout ให้เล็กไว้

อ่านเรื่องรหัส 429 และการ retry ได้ที่ไหน?

รหัส 429 และกลยุทธ์ retry เป็นหัวข้อใหญ่แยกต่างหากที่ไม่เกี่ยวข้องโดยตรงกับความล้มเหลวของชั้นพร็อกซี มีบทความเฉพาะเรื่องนี้ ศึกษากันแยกจากการวินิจฉัย error พร็อกซี

บทสรุป: คุณเชี่ยวชาญอะไรแล้ว และไปต่ออย่างไร

ยินดีด้วย คุณเดินทางจากความสับสนต่อรหัสลึกลับมาสู่การวินิจฉัยที่มั่นใจทีละขั้น มาทบทวนสิ่งที่อยู่ในคลังอาวุธของคุณตอนนี้

สรุปการดำเนินการที่ทำไปแล้ว คุณเรียนรู้ที่จะแบ่งห่วงโซ่ออกเป็นสามจุด — client, พร็อกซี และเซิร์ฟเวอร์ — และระบุว่า error เกิดที่ไหน คุณเข้าใจรหัส 407 และการยืนยันตัวตนพร็อกซี รวมถึงอักขระพิเศษที่แอบซ่อนในรหัสผ่าน คุณเข้าใจธรรมชาติสองแง่ของ 502 และวิธีตรวจสอบไขว้ คุณเชี่ยวชาญการแยก connect กับ read timeout เมื่อเจอ 504 คุณเข้าใจวิธี CONNECT และ error tunnel connection failed บน HTTPS คุณเรียนรู้ที่จะจดจำสามสาเหตุของ 403 จากพร็อกซีและวินิจฉัยการขาดการเชื่อมต่อตามขั้นตอน และสุดท้าย คุณเชี่ยวชาญทักษะหลัก — การอ่าน output ของ curl -v ทีละบรรทัดพร้อมขีดเส้นขอบเขตระหว่างจุดอย่างแม่นยำ

ทำอะไรต่อไป ตอกย้ำทักษะด้วยการปฏิบัติ ทุกครั้งที่เจอ error พร็อกซี อย่าเดา แต่ค่อย ๆ แยกมันตามจุดด้วยตารางวินิจฉัย หลังฝึกราวหนึ่งสัปดาห์ การวินิจฉัยจะเป็นไปโดยอัตโนมัติ

จะพัฒนาต่อไปอย่างไร ขั้นต่อไปที่สมเหตุสมผลคือศึกษาหัวข้อรหัส 429 และกลยุทธ์ retry ที่เหมาะสม ซึ่งมีบทความเฉพาะเรื่องนี้ จากนั้นเจาะลึกการจำแนก error อัตโนมัติในโค้ดและการเก็บเมตริกความเสถียร สิ่งนี้จะเปลี่ยนคุณจากคนที่ดับไฟ เป็นวิศวกรที่มองเห็นปัญหาล่วงหน้า

เคล็ดลับ: บันทึกคู่มือนี้และตารางวินิจฉัยไว้ในบุ๊กมาร์ก กลับมาดูเมื่อเจอ error ใหม่ทุกครั้ง จนตรรกะกลายเป็นธรรมชาติที่สองของคุณ ความมั่นใจในการวินิจฉัยเกิดจากการทำซ้ำจริง ๆ คุณทำได้แน่นอน