IP รั่วไหลหรือเปล่า ตรวจยังไง เช็คเอง 3 ขั้นด้วย ip-api, ipinfo, ip111

สรุปสั้น ๆ: รันเว็บเช็ค IP สักเว็บเดียวยืนยันว่า "ไม่รั่ว" ไม่ได้ เพราะเส้นทางออก สถานะของ IP และการรั่วไหลเป็นสามชั้นที่แยกกัน ต้องใช้ ipinfo, ip-api, ip111 และ ipleak ร่วมกันตามลำดับ เช็คเส้นทางออก เช็คสถานะ เช็คการรั่วไหล ให้แต่ละชั้นได้ชุดข้อมูลมาก่อนแล้วค่อยสรุป. ขั้นตอนทั้งหมดใช้เวลาขั้นละหนึ่งสองนาที เช็คให้จบใน environment ก่อนเอาไปใช้งานจริง ประหยัดกว่าไล่แก้ทีหลังมาก

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

เส้นทางออก สถานะ และการรั่วไหล เป็นสามเรื่องคนละเรื่อง เว็บเดียวดูไม่ครบ

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

ระบบความเสี่ยงของแพลตฟอร์มมองอย่างน้อยสามชั้น

• ชั้นแรกคือที่มาของเส้นทางออก: ประเทศ เมือง และ ASN ของ IP ต้องสอดคล้องกับตัวตนของบัญชี

• ชั้นที่สองคือสถานะของเส้นทางออก. IP ช่วงเดียวกันมีทั้งบรอดแบนด์บ้านและดาต้าเซ็นเตอร์ ในโมเดลความเสี่ยง ช่วงของเซิร์ฟเวอร์ถูกให้น้ำหนักไม่เหมือนช่วงบ้านเลย

• ชั้นที่สามคือการรั่วทางเบี่ยง. WebRTC สอดรูปหาที่อยู่สาธารณะของเครื่องได้จากในเบราว์เซอร์เลย การแก้ DNS อาจลัดไปใช้ช่องเริ่มต้นของระบบแทนพร็อกซี ส่วน IPv6 เปิดโล่งได้บนเส้นทางที่พร็อกซีครอบแค่ IPv4 ทุกช่องทางเหล่านี้ต่อตรง ไม่ผ่านพร็อกซีทั้งสิ้น

แต่ละชั้นต้องการข้อมูลคนละแบบ สี่เครื่องมือแบ่งกันดูทีละชั้น ไล่ตามลำดับ

ขั้นตอนเช็คเองแบบผสมสามขั้น

สามขั้นนี้ต้องทำใน environment เท่านั้น เบราว์เซอร์บนเครื่องเราวัดออกมาเป็นเน็ตของเครื่องเรา ไม่มีค่าอ้างอิงกับ environment เลย

1. ขั้นที่หนึ่ง: ใช้ ipinfo ดูที่มาของเส้นทางออก เปิด ipinfo.io ใน environment หน้าเว็บจะบอกที่ตั้ง องค์กร และ ASN ของเส้นทางออกปัจจุบันทันที เทียบทีละบรรทัดกับที่ผู้ขายพร็อกซีระบุไว้ ประเทศกับเมืองตรงกันไหม องค์กรใช่เจ้าที่เขาอ้างไว้หรือเปล่า ถ้าเจอคลาดเคลื่อนให้จดไว้ในโน้ตของ environment ก่อน เอาไว้ยืนยันข้ามในขั้นที่สอง ฐานข้อมูลแต่ละเจ้าอัปเดตช่วง IP เดียวกันได้เร็วไม่เท่ากัน ผลจากเจ้าเดียวยังสรุปไม่ได้

2. ขั้นที่สอง: ใช้ ip-api ดูสถานะของเส้นทางออก เปิด ip-api.com ผ่านเบราว์เซอร์ตรง ๆ จะได้ข้อความ JSON กลับมา ฟิลด์ proxy กับ hosting คือตัวตัดสินสถานะ hosting เป็น true แปลว่าช่วง IP นี้อยู่ในดาต้าเซ็นเตอร์หรือห้องเซิร์ฟเวอร์ ส่วน proxy บอกว่าถูกติดป้ายว่าเป็นพร็อกซีหรือยัง พร็อกซีส่วนใหญ่วิ่งบนช่วงเซิร์ฟเวอร์ hosting เป็น true ถือว่าปกติ คุณค่าของฟิลด์นี้คือทำให้รู้ว่าเส้นทางออกของเราในสายตาแพลตฟอร์มมีสถานะแบบไหน ส่วนจะเหมาะกับงานของบัญชีหรือไม่ ต้องตัดสินเองจากลักษณะงาน

3. ขั้นที่สาม: ใช้ ip111 กับ ipleak เช็คการรั่วทางเบี่ยง ip111.cn จะรายงานเส้นทางออกสามรอบจากสามทิศทาง เว็บในประเทศ เว็บต่างประเทศ และกูเกิล ปกติสามผลต้องตรงกันและชี้ไปที่เส้นพร็อกซีเดียวกัน ipleak.net เติมแผง WebRTC, DNS และ IPv6 ให้อีกสามแผง ถ้าช่องไหนโผล่ที่อยู่นอกพร็อกซี แปลว่ามีการรั่วทางเบี่ยง ยิ่งต้องระวังช่วงของผู้ให้บริการบรอดแบนด์ในประเทศ อยากไล่ลึกชั้นนี้ สองบทความ การตรวจจับ DNS leak และ การตรวจจับ IPv6 leak มีขั้นตอนครบทั้งสองเรื่อง

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

ฝังการเช็คไว้ใน environment: ช่องเทียบพร็อกซีของ MostMate

เครื่องมือภายนอกเหมาะกับการเช็คลึกตอนเพิ่มพร็อกซีเข้าคลัง ส่วนเช็คประจำวันใช้ช่องคงที่ใน environment เร็วกว่า ในฟอร์มพร็อกซีของ MostMate มีรายการ [ช่องทางเช็ค IP] ช่องตัวอย่างค่าเริ่มต้นคือ ip-api ตั้งพร็อกซีเสร็จกด [ตรวจสอบพร็อกซี] environment จะวัดเส้นทางออกจริงตามช่องทางที่เลือกแล้วกรอกผลกลับมา ขั้นเข้าคลังนี้ไม่ต้องออกจาก environment เลย

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

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

อ่านผลอย่างไร: การตีความผิดสามแบบกับจังหวะการเช็ค

ผลที่ผิดปกติต้องยืนยันข้ามกันก่อนถึงจะสรุปได้ การตีความผิดที่พบบ่อยสามแบบมีทางจัดการของตัวเองคนละทาง

ความคลาดเคลื่อนของฐานข้อมูล: IP เดียวกัน ipinfo บอกเมืองหนึ่ง ip-api บอกอีกเมือง ส่วนใหญ่เพราะจังหวะอัปเดตของสองฐานไม่เท่ากัน ตอนตัดสินให้ดูฟิลด์ที่นิ่งกว่า ระดับประเทศตรงกันทั้งคู่ก็ใช้ต่อได้ ความต่างระดับเมืองจดไว้ในโน้ตของ environment ถ้ายังอยู่ครบหลายรอบการตรวจ ค่อยติดต่อผู้ขายมายืนยัน

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

การรั่วทางเบี่ยง: ผลสามแบบนี้มีแบบเดียวที่ต้องจัดการทันที แผง WebRTC หรือ DNS โผล่ที่อยู่นอกพร็อกซี ให้กลับไปที่ environment ยืนยันก่อนว่าพร็อกซีทำงานจริง แล้วค่อยดูวิธีจัดการ WebRTC บทความ ตั้งค่า WebRTC ใน antidetect browser เขียนวิธีปรับแยกตามสถานการณ์ไว้แล้ว แก้เสร็จวัดใหม่ แผงสะอาดค่อยกลับมาทำงานต่อ

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

อยากเพิ่มการตรวจอีกชั้นที่ fingerprint ของเบราว์เซอร์ บทความ อ่านเฉลย 11 รายการตรวจของ BrowserLeaks แยกรายการออกเป็นสามกลุ่ม เส้นทางออก การอ่านค่า และการประกาศ

บทสรุป

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

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

ip-api ฟรีหรือเปล่า

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

ip111 โชว์เส้นทางออกสามที่ไม่ตรงกันทำอย่างไร

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

เจอ WebRTC รั่วต้องทำอย่างไร

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

สามขั้นผ่านหมด บัญชีปลอดภัยแน่นอนไหม

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