SOCKS5 กับ HTTP proxy ต่างกันอย่างไร หลายบัญชีควรเลือกแบบไหน

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

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

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

เส้นแบ่งของสองโปรโตคอล: ใครคือผู้จัดการคำขอของคุณ

HTTP proxy ทำงานที่ชั้นแอปพลิเคชัน ส่วน SOCKS5 ทำงานอยู่ชั้นลงมา ตำแหน่งต่างกัน หน้าที่ก็แบ่งกันต่างกัน ใครอ่านคำขอของคุณออก ใครก็มีโอกาสแก้มันได้

HTTP proxy ถูกออกแบบมาสำหรับทราฟฟิกเว็บ มันอ่านคำขอ HTTP ออก ว่ากำลังไปที่ไหน แนบส่วนหัวอะไรมา ใช้เมธอดแบบไหน ความสามารถอ่านออกนี้มีสองด้าน ด้านดีคือแคชกับการกรองทำได้ ด้านที่ต้องระวังคือมันยืนอยู่ตรงที่มองเห็นคำขอแบบไม่เข้ารหัสได้พอดี

ในหน้าอธิบายเรื่องเซิร์ฟเวอร์พร็อกซีกับการส่งผ่านแบบอุโมงค์ MDN ระบุว่าพร็อกซี HTTP บางตัวจะเพิ่มหรือแก้ไขฟิลด์กำกับอย่าง Via หรือ Forwarded ตอนส่งต่อ โดยจะใส่หรือไม่ขึ้นกับการพัฒนาและการตั้งค่าของพร็อกซีแต่ละตัว คำขอที่ผ่านพร็อกซีแบบนี้จึงอาจติดร่องรอยว่าเคยผ่านพร็อกซีมา ซึ่งฝั่งเว็บมีโอกาสสังเกตได้ แต่ก็ไม่ใช่พฤติกรรมตายตัวของพร็อกซี HTTP ทุกตัว

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

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

ตารางเดียวเห็นครบ: จากการจัดการคำขอถึงตำแหน่งการแปลง DNS

ความต่างที่กระจายอยู่ตามย่อหน้าเทียบกันยาก รวมเข้าตารางก่อน เกณฑ์การเลือกควรมาจากการเทียบความสามารถของโปรโตคอลเป็นรายข้อ ไม่ใช่จ้องมิติเดียว:

แถวอื่นในตารางอ่านตามตัวหนังสือได้ แต่แถว DNS ควรแยกออกมาเล่า ตอนเดินผ่าน HTTP proxy เบราว์เซอร์มักส่งชื่อโดเมนปลายทางไปให้พร็อกซีตรง ๆ การแปลงจึงเกิดที่ฝั่งพร็อกซี คำขอแปลงชื่อจากเครื่องเราไม่ได้ออกไปไหน แต่พอเป็น SOCKS5 ไม่มีข้อตกลงตายตัวแบบนี้ ตำแหน่งการแปลง DNS ขึ้นอยู่กับว่าโปรแกรมลูกส่งที่อยู่ปลายทางให้ใคร บางตัวยกชื่อโดเมนไปให้พร็อกซีแปลงก่อน บางตัวแปลงที่เครื่องตัวเองแล้วค่อยต่อ แบบที่แปลงที่เครื่องเอง คำถามชื่อโดเมนจะออกจากเครือข่ายของเราไปหาเซิร์ฟเวอร์ DNS ตรง ๆ โดยไม่เกี่ยวกับจุดออกของพร็อกซี

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

งานหลายบัญชีเลือกยังไง: สามเส้นทาง

กลับมาที่การเลือกตัวเอง ทราฟฟิกของงานหลายบัญชีส่วนใหญ่ดูออกไม่ยาก จัดเข้าช่องตามสามเส้นนี้:

1. งานเว็บล้วน: หลังบ้านขายของออนไลน์ เวอร์ชันเว็บของโซเชียล หน้าจัดการโฆษณา ทราฟฟิกเป็นคำขอเว็บทั้งหมด สองโปรโตคอลรับได้หมด ตอนนี้เลือกเส้นทางที่คุณภาพดีกว่ามานั่งเทียบชนิดโปรโตคอลจะคุ้มกว่า

2. โปรแกรมเดสก์ท็อปกับสคริปต์: แอปอย่าง Telegram สคริปต์เก็บข้อมูล เครื่องมือที่ต่อกับ API ทราฟฟิกพวกนี้ไม่จำเป็นต้องเดินตามความหมายแบบ HTTP ช่องทางส่งต่อข้อมูลแบบทั่วไปของ SOCKS5 จึงเหมาะกว่า ความสัมพันธ์ของจุดออกสองชั้นฝั่งโปรแกรมลูก มีบทความตั้งค่าพร็อกซี Telegram แยกไล่ตามทางเข้าให้แล้ว

3. เสียงภาพเรียลไทม์กับทราฟฟิก UDP: ไลฟ์ที่มีปฏิสัมพันธ์ คอลเสียง SOCKS5 ส่งต่อ UDP ได้ แต่ HTTP proxy ไม่มีความสามารถชั้นนี้ เหลือทางเดียวคือ SOCKS5

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

เลือกโปรโตคอลถูก ไม่ได้แปลว่าความเสี่ยงโยงบัญชีหายไป

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

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

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

ตั้งค่าพร็อกซีใน MostMate: จากกรอกข้อมูลถึงการตรวจสอบ

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

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

ขั้นที่ 2: กรอกพร็อกซีเข้ารายการจัดการพร็อกซี MostMate เก็บพร็อกซีไว้ในเมนูแยกต่างหาก มีทางเข้าสร้างพร็อกซีใหม่กับนำเข้าพร็อกซี รายการบันทึกข้อมูลพร็อกซี โน้ต IP ปลายทาง และวันที่สร้างเป็นรายการ ๆ ตอนกรอก รีบใส่โน้ตด้วยเลย เขียนให้ชัดว่าใช้ทำอะไร ผู้ให้บริการไหน หรือเส้นทางหมายเลขอะไร โน้ตเขียนไว้ให้คนที่รับงานต่ออ่าน

ขั้นที่ 3: ผูกพร็อกซีเข้ากับโปรไฟล์ เข้าไปที่ฟอร์มสร้างหรือแก้ไขโปรไฟล์ ส่วนตั้งค่าพร็อกซีมีสามทางเลือก: ไม่ใช้พร็อกซี พร็อกซีกำหนดเอง หรือเลือกพร็อกซีที่กรอกไว้แล้วตรง ๆ ดรอปดาวน์ชนิดครอบคลุม SOCKS5, HTTP, HTTPS และ SSH ให้ทางเลือกตรงกับโปรโตคอลจริง ตอนกรอกพร็อกซีกำหนดเองให้ทำตามรูปแบบที่ฟอร์มแนะนำ ถ้าผู้ให้บริการให้พรีฟิกซ์มาเป็น socks5 ก็เลือก SOCKS5

ขั้นที่ 4: เช็กการเชื่อมต่อพร็อกซี ในฟอร์มมีปุ่มตรวจพร็อกซี ใช้ทดสอบว่าต่อได้ไหม พร้อมเทียบแหล่งที่อยู่ของ IP ปลายทางผ่านช่องทาง IP lookup ผ่านปุ่มนี้เป็นแค่ด่านแรก ข้อมูลอย่าง DNS กับ WebRTC ไม่อยู่ในขอบเขตที่ปุ่มนี้ครอบคลุม ต้องเปิดโปรไฟล์แล้วไปตรวจต่อที่หน้าเช็กจากภายนอกอีกที

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

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

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

ตั้งค่าครบแต่ต่อไม่ได้: ไล่ปัญหาสามอาการ

เดินสายการตั้งค่าจบแล้ว สิ่งที่เหลือคือจัดการความผิดปกติ วิธีไล่ปัญหาควรเริ่มจากอาการแล้วย้อนหาสาเหตุ ไม่ใช่เปิดมาเติมค่าทั้งชุดใหม่อีกรอบ ในงานหลายบัญชีพบบ่อยสามอาการ จดอาการก่อน แล้วค่อยหาสาเหตุ

อาการที่ 1: ตรวจผ่าน แต่ภูมิภาคของ IP ปลายทางไม่ตรง

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

อาการที่ 2: ตรวจผ่าน แต่เว็บเปิดไม่ได้

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

อาการที่ 3: สองโปรไฟล์ขึ้น IP ปลายทางเดียวกัน

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

คำถามที่พบบ่อย

ใช้ SOCKS5 กับ HTTP proxy ปนกันในโปรไฟล์ชุดเดียวกันได้ไหม

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

พร็อกซี HTTPS อยู่ตรงไหนในสายการตัดสินนี้

วิธีรับมือหน้าเข้ารหัสของมันคือสร้างอุโมงค์ต่อจากกลไกของ HTTP proxy สำหรับทราฟฟิกเว็บใช้ได้เทียบเท่า SOCKS5 แนวคิดการเลือกที่เล่ามาข้างบนใช้กับมันได้เช่นกัน พื้นที่ของบทความเก็บไว้ให้ส่วนที่ต่างกันมากที่สุด ส่วนที่เหลือไม่เล่าซ้ำ

SOCKS5 กับ HTTP proxy แบบไหนเร็วกว่า

ความเร็วขึ้นกับคุณภาพเส้นทาง ระยะทาง และแบนด์วิดท์เป็นหลัก ต้นทุนการประมวลผลของตัวโปรโตคอลเอง ภายใต้เครือข่ายยุคนี้ต่างกันนิดหน่อย ราคาเท่ากัน HTTP proxy เส้นดีจะเร็วกว่า SOCKS5 เส้นทราชัดเจน ถ้าเอาโปรโตคอลเป็นเกณฑ์ตัดสินความเร็ว มีหวังเลือกผิดทาง

ใช้ SOCKS5 แล้วยังต้องมีเบราว์เซอร์แอนติดีเทกต์อยู่ไหม

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

บทสรุป

เส้นแบ่งของ SOCKS5 กับ HTTP proxy อยู่ที่วิธีจัดการคำขอกับตำแหน่งการแปลง DNS: แบบหนึ่งอ่านคำขอออกและอาจทิ้งร่องรอย อีกแบบสร้างช่องทางอย่างเดียวแล้วส่งต่อตามเดิม งานหลังบ้านเว็บใช้ได้ทั้งคู่ โปรแกรมกับสคริปต์ให้ SOCKS5 เป็นตัวก่อน วิธียืนยันตัวตนตัดสินตั้งแต่ตอนซื้อ เลือกเสร็จ กรอกพร็อกซีเข้ารายการรวม ผูกเข้าโปรไฟล์ ตรวจผ่านค่อยล็อกอิน มีความผิดปกติก็ย้อนจากอาการหาสาเหตุ ชั้นช่องทางส่งต่อข้อมูลถึงจะปิดจบอย่างเรียบร้อย อยากลองเทียบจุดออกสองเส้นด้วยตัวเอง ดาวน์โหลด MostMate เวอร์ชันฟรี เปิดสองโปรไฟล์ผูกคนละเส้นทาง ทดสอบปุ๊บก็รู้ผล