ตรวจสอบคุณภาพ Proxy IP: 5 ขั้นตอนเช็กด้วยตนเองและติดตามระยะยาว

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

ห้ารายการต่อไปนี้พร้อมวิธีตรวจสอบแบบเจาะจง ใช้เวลาประมาณสิบนาทีหากทำทีละข้อ

1. ตำแหน่งและผู้ให้บริการถูกต้องหรือไม่

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

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

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

2. ช่วง IP แบบบ้านพักอาศัยหรือดาต้าเซ็นเตอร์

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

วิธีง่ายที่สุดคือดูหน่วยงานที่จดทะเบียนของ ASN ชื่อที่มีคำว่า Cloud, Hosting, Data Center หรือ VPS มักเป็นช่วงดาต้าเซ็นเตอร์ ส่วน Telecom, Broadband, Cable หรือ Communications มักเป็นช่วงบ้านพักอาศัยหรือ ISP ให้ดู reverse DNS ประกอบด้วย: IP บ้านพักอาศัยมักมี reverse record ที่ผู้ให้บริการกำหนด ส่วน PTR ของ IP ดาต้าเซ็นเตอร์มักใช้รูปแบบโดเมนของผู้ให้บริการคลาวด์

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

3. การเชื่อมต่อและ packet loss

เชื่อมต่อได้ไม่เท่ากับเสถียร การ ping ช่วงสั้นอาจไม่เห็นปัญหา จึงต้องสังเกตต่อเนื่องระยะหนึ่ง

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

ประเภท Proxy ต้องตรงกันด้วย SSH, SOCKS5 และ HTTP ไม่สามารถผสมตั้งค่าแบบสุ่มได้ โปรโตคอลที่เลือกในไคลเอนต์ต้องตรงกับที่เซิร์ฟเวอร์เปิดจริง มิฉะนั้นอาจดูเหมือนเชื่อมต่อได้แต่ทราฟฟิกไม่ผ่าน พอร์ตก็เช่นกัน หากพอร์ตเริ่มต้นอย่าง SSH 22 ถูกผู้ให้บริการบล็อก ให้แก้กฎ firewall ก่อน อย่าเพิ่งสรุปว่ารหัสผ่านผิด

4. DNS และ WebRTC รั่วหรือไม่

สองรายการนี้เป็นตัวกำหนดว่าตำแหน่งจริงของคุณอาจรั่วออกทางช่องทางอื่นหรือไม่

วิธีตรวจ DNS leak คือเข้าเว็บที่รองรับการทดสอบ DNS leak แล้วดูว่าคำขอ resolve ถูกส่งออกจากโหนดใด หาก resolver สุดท้ายยังอยู่ในเครือข่ายท้องถิ่น การที่ทราฟฟิกผ่าน Proxy ก็ยังไม่พอ เพราะแพลตฟอร์มสามารถคาดเดาพื้นที่จริงจากตำแหน่งการ resolve DNS แล้วนำไปเทียบกับตำแหน่ง IP ได้ วิธีแก้คือเปิด remote DNS resolution ในสภาพแวดล้อม หรือเลือกประเภท Proxy ที่รองรับการ resolve DNS ผ่าน Proxy

WebRTC leak มองเห็นยากกว่า เบราว์เซอร์จะเก็บข้อมูลอินเทอร์เฟซเครือข่ายในเครื่องเพื่อใช้สื่อสารแบบ peer-to-peer และในบางการตั้งค่าอาจข้าม Proxy แล้วเปิดเผยที่อยู่ภายในหรือแม้แต่ที่อยู่สาธารณะ ให้เปิดหน้า WebRTC test แล้วดูว่ามี IP จริงของคุณอยู่ใน candidate addresses หรือไม่ หากมี ให้ปิด WebRTC ในเบราว์เซอร์หรือการตั้งค่าสภาพแวดล้อม หรือจำกัดให้ใช้เฉพาะผ่าน Proxy

5. เขตเวลาและภาษาสอดคล้องกันหรือไม่

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

วิธีดูระยะยาวว่า IP ถูกทำเครื่องหมายหรือไม่

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

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

แนวทางแก้มีสองทาง: เปลี่ยนเป็น Proxy แบบบ้านพักอาศัย หรือเปลี่ยนไปใช้โหนดภูมิภาคที่มีผู้ใช้น้อยกว่า

ลำดับการตรวจในวันที่ตั้งค่าเสร็จ

1. ใช้หน้า IP lookup ตรวจตำแหน่ง ผู้ให้บริการ และ ASN แล้วตรวจว่ามี IPv6 leak หรือไม่
2. ใช้หน่วยงานที่จดทะเบียนของ ASN และ reverse DNS เพื่อดูว่าเป็นช่วงบ้านพักอาศัยหรือดาต้าเซ็นเตอร์
3. ส่งคำขอต่อเนื่องหลายร้อยครั้งเพื่อดู packet loss และความผันผวนของ latency และแยกทดสอบเป็นช่วงหากจำเป็น
4. ใช้ DNS leak test และ WebRTC test เพื่อยืนยันว่าทางออกจริงไม่ถูกเปิดเผย
5. จัดเขตเวลา ภาษา และภูมิภาคอินเทอร์เฟซให้ตรงกับตำแหน่ง IP

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

Proxy ที่เชื่อมต่อได้กับ Proxy ที่มีคุณภาพเหมาะสมเป็นคนละเรื่อง แบบแรกต้องแค่ตั้งค่าถูกต้อง ส่วนแบบหลังต้องตรวจทีละข้อ รายการที่ไม่ได้ตรวจ เช่น DNS leak, WebRTC และประเภท IP เป็นสิ่งที่ลดความน่าเชื่อถือของสภาพแวดล้อมทั้งหมดได้ง่ายที่สุดโดยไม่รู้ตัว