DNS Leak คืออะไร: ทำไมทราฟฟิกถึงหลุดออกนอกพร็อกซี และวิธีปิด DNS Leak ระดับระบบ

บทนำ: ทำไมพร็อกซีสมบูรณ์แบบ แต่คุณยังถูกมองเห็นอยู่ดี

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

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

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

ในคู่มือนี้เราจะเจาะลึกหัวข้อนี้ทั้งหมด คุณจะได้รู้ว่าการ resolve ชื่อทำงานอย่างไรและมันหลุดออกนอกพร็อกซีตอนไหน เข้าใจว่า HTTP และ SOCKS พร็อกซีต่างกันอย่างไรในแง่ DNS ทำไมตัวอักษรตัวเดียวในสตริงการเชื่อมต่อถึงตัดสินทุกอย่าง และเบราว์เซอร์ที่เปิด encrypted DNS สร้างหมวดหมู่การรั่วใหม่ได้อย่างไร เราจะให้สี่วิธีปฏิบัติ — การวินิจฉัย การตั้งค่าไคลเอนต์ซอฟต์แวร์ เบราว์เซอร์และแอนตี้ดีเทค และระดับระบบ — แต่ละวิธีมีขั้นตอนทีละขั้นและเช็กลิสต์ เราจะดูล้อมผิดพลาดทั่วไป เคสพร้อมตัวเลข และตอบคำถามยากๆ

เส้นแบ่งสำคัญ: บทความนี้ว่าด้วยชั้น DNS การรั่วผ่าน WebRTC, fingerprint ของเบราว์เซอร์, timing และช่องทาง de-anonymize อื่นๆ เป็นหัวข้อแยกที่เราดูในบทความอื่นของบล็อก เราจะโฟกัสที่หนึ่งช่องทางที่ фундаamental เพราะถ้าไม่เข้าใจมัน การตั้งค่าที่เหลือทั้งหมดก็ยืนอยู่บนทราย

พื้นฐาน: DNS ทำงานอย่างไร และอะไรเรียกว่า dns leak

สมุดโทรศัพท์ของอินเทอร์เน็ต

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

การ resolve ชื่อในทางปฏิบัติเป็นแบบนี้:

1. แอปพลิเคชันเรียกฟังก์ชันระบบ (ในโลก Unix ส่วนใหญ่คือ getaddrinfo) ส่งชื่อโดเมนให้มัน
2. ระบบปฏิบัติการตรวจสอบแคชในเครื่องและไฟล์ hosts
3. ถ้าไม่มีคำตอบ stub resolver ของ OS จะส่งคำถามไปยังที่อยู่ DNS server ที่ตั้งไว้ในการตั้งค่าเครือข่าย ปกติคือเซิร์ฟเวอร์ของผู้ให้บริการที่ได้รับผ่าน DHCP หรือ public resolver ที่คุณระบุเอง
4. Recursive resolver ของผู้ให้บริการจะไล่ไปตามห่วงโซ่ root server, server ของเขตโดเมน และ authoritative server ของโดเมน ค้นหาคำตอบและส่งกลับมาให้คุณ
5. แอปพลิเคชันได้รับ IP และเพิ่งตอนนี้จึงเริ่มการเชื่อมต่อ

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

อะไรกันแน่ที่เรียกว่าการรั่ว

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

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

สามบทบาทที่มองเห็นการรั่วของคุณ

• ผู้ให้บริการอินเทอร์เน็ตของคุณ เขาเห็นคำขอที่มาถึง resolver ของเขาและรู้ว่าคุณเยี่ยมชมโดเมนอะไร แม้เนื้อหาจะวิ่งผ่านพร็อกซีก็ตาม
• เจ้าของ resolver ถ้าคุณระบุ public DNS ไว้ ผู้ดำเนินการของมันก็จะเห็นรายชื่อโดเมนทั้งหมดของคุณและ IP จริงของคุณ
• เว็บไซต์ปลายทางและระบบแอนติ้ฟรอด เขาไม่ได้รับ DNS query โดยตรง แต่มีช่องทางอ้อม: ภูมิศาสตร์ของ authoritative server, กลไก EDNS Client Subnet, การ route ของ CDN และโดเมนทดสอบพิเศษที่สร้างขึ้นสำหรับเซสชันนั้นโดยเฉพาะ เรื่องนี้จะลงรายละเอียดในหัวข้อถัดไป

เจาะลึก: กายวิภาคของการรั่ว DNS เมื่อทำงานผ่านพร็อกซี

HTTP พร็อกซี: ทำไมปกติไม่รั่ว แต่ก็มีข้อยกเว้น

เมื่อทำงานผ่าน HTTP พร็อกซี เบราว์เซอร์ส่งคำขอที่มีโดเมนเป็นข้อความไปให้ สำหรับ HTTP ที่ไม่เข้ารหัสคือ URL เต็มในบรรทัดแรกของคำขอ สำหรับ HTTPS เบราว์เซอร์ส่งคำสั่ง CONNECT พร้อมชื่อโฮสต์และพอร์ต แล้วพร็อกซีจะ resolve ชื่อนั้นเองและสร้าง tunnel ในทั้งสองกรณี ไคลเอนต์ไม่จำเป็นต้องรู้ IP ของเซิร์ฟเวอร์ปลายทาง การ resolve ทำโดยพร็อกซี ฝั่งของเขา ด้วย resolver ของเขา ในกรณีของมือถือพร็อกซี — ฝั่งโมเด็มหรือโทรศัพท์ ผ่าน DNS server ของโอเปอเรเตอร์ นี่คือสิ่งที่ควรเป็น

แล้วการรั่วมาจากไหนกับ HTTP พร็อกซี? แหล่งที่มาของมันเป็นทางอ้อม:

• PAC script ไฟล์ config พร็อกซีอัตโนมัติอาจมีฟังก์ชัน dnsResolve ที่ resolve โดเมนในเครื่องเพื่อตัดสินใจว่าจะส่งคำขอผ่านพร็อกซีหรือไม่ การตัดสินใจเกิดขึ้นหลัง DNS query ในเครื่องแล้ว
• การ resolve ชื่อล่วงหน้า แอปพลิเคชันบางตัวตรวจสอบว่าโฮสต์เข้าถึงได้ก่อนเชื่อมต่อ: ping, resolve แล้วค่อยวิ่งผ่านพร็อกซี แอปพลิเคชัน Java ที่ใช้ InetAddress, ตัว scrape บางตัว, ปลั๊กอินตรวจสอบลิงก์
• บริการเบื้องหลังของเบราว์เซอร์ การ prefetch หน้าเพจ, DNS-prefetch, การตรวจสอบ safe browsing และการอัปเดต อาจทำงานด้วยกฎของตัวเองและไม่ได้เคารพการตั้งค่าพร็อกซีเสมอ

SOCKS: ตัวอักษรเดียวระหว่างเซสชันสะอาดกับการรั่ว

ตรงนี้เริ่มน่าสนใจ โปรโตคอล SOCKS4 ในเวอร์ชันดั้งเดิมรับได้แค่ IP ปลายทางเท่านั้น นั่นหมายความว่าไคลเอนต์ต้อง resolve ชื่อเองก่อนเชื่อมต่อ การรั่วถูกฝังอยู่ในโปรโตคอล ส่วนขยาย SOCKS4a เพิ่มความสามารถในการส่งชื่อโฮสต์ SOCKS5 รองรับที่อยู่ปลายทางสามแบบ: IPv4, IPv6 และชื่อโดเมน

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

จากตรงนี้เองที่ตัวอักษร h ที่โด่งดัง comes in ใน curl และไลบรารีที่ทำตามแบบแผนของมัน scheme socks5:// หมายถึงการ resolve ชื่อในเครื่อง ส่วน socks5h:// หมายถึงการส่งชื่อโฮสต์ให้พร็อกซี resolve ที่ฝั่งไกล ตัวอักษรเดียว ความต่างระหว่างเซสชันสะอาดที่ทุกอย่างรวมถึง DNS ออกจากเครือข่ายมือถือของโอเปอเรเตอร์ กับเซสชันที่ทุกชื่อรั่วไปยังผู้ให้บริการของคุณก่อน

ทำไมพร็อกซีเซิร์ฟเวอร์ถึงควร resolve เอง

ตรงนี้มีจุดที่ไม่ชัดเจนที่หลายคนมองข้าม เรื่องนี้ไม่ใช่แค่ความเป็นส่วนตัว เมื่อฝั่งไกลของมือถือพร็อกซี resolve ชื่อ คำตอบ DNS จะถูกสร้างขึ้นโดยคำนึงถึงตำแหน่งของโอเปอเรเตอร์ บริการขนาดใหญ่ใช้ CDN และ geo-DNS: โดเมนเดียวกันจะให้ IP ต่างกันแก่ไคลเอนต์ต่างกัน ตามที่ใกล้ที่สุด ถ้าผู้ให้บริการบ้านของคุณ resolve คุณจะได้ที่อยู่ CDN node ใกล้ตำแหน่งจริงของคุณ แล้วคุณค่อยเชื่อมต่อกับ node นั้นผ่านมือถือพร็อกซีจากภูมิภาคอื่น สำหรับบริการแล้วดูแปลกๆ: ไคลเอนต์จากเครือข่ายมือถือภูมิภาค A กลับมาที่ node ที่ออกแบบสำหรับภูมิภาค B นี่คือช่องทางอ้อมในการตรวจจับ dns leak ที่ไม่ต้องเข้าถึง DNS query ของคุณเลย

EDNS Client Subnet: resolver แจกซับเน็ตของคุณอย่างไร

กลไก EDNS Client Subnet (ECS) ถูกคิดขึ้นเพื่อให้ public resolver ส่งส่วนหนึ่งของที่อยู่ไคลเอนต์ให้ authoritative server — ปกติคือ 24 บิตแรกสำหรับ IPv4 เพื่อให้ CDN เข้าใจว่าผู้ใช้จริงมาจากไหนและให้ node ที่ใกล้ที่สุด สะดวกต่อความเร็ว แต่ในแง่การรั่วนั้นหมายความว่าเมื่อ resolve ในเครื่องผ่าน public DNS ที่รองรับ ECS authoritative server ของโดเมนปลายทางจะได้รับซับเน็ตของการเชื่อมต่อจริงของคุณ ไม่ใช่ที่อยู่เต็ม แต่เพียงพอที่จะเข้าใจผู้ให้บริการและเมือง แล้วการเชื่อมต่อก็มาพร้อมมือถือ IP สองซับเน็ต สองโอเปอเรเตอร์ หนึ่งผู้ใช้

Encrypted DNS: หมวดหมู่การรั่วใหม่

ตั้งแต่ยุค 2020 เบราว์เซอร์และระบบปฏิบัติการเปลี่ยนไปใช้ DNS over HTTPS (DoH) และ DNS over TLS (DoT) กันเป็นวงกว้าง และพอถึงปี 2026 ก็เพิ่ม DNS over QUIC เข้ามา ไอเดียนั้นดี: ผู้ให้บริการไม่เห็นคำขอของคุณอีกต่อไป แต่สำหรับการทำงานผ่านพร็อกซีก็เกิดผลข้างเคียงขึ้นมา เบราว์เซอร์ที่เปิด «safe DNS» จะติดต่อ DoH server ที่เลือกด้วยไคลเอนต์ของตัวเอง และทราฟฟิกนี้ไม่ได้ตามการตั้งค่าพร็อกซีเสมอ นั่นคือชื่อถูก resolve ไม่ใช่ที่โอเปอเรเตอร์มือถือ แต่ที่ public resolver ขนาดใหญ่ และทำจาก IP จริงของคุณ การเข้ารหัสช่วยป้องกันจากผู้ให้บริการ แต่ไม่ช่วยจากความไม่สอดคล้องระหว่างฝั่ง DNS กับฝั่งการเชื่อมต่อ

ชั้นความซับซ้อนเพิ่มเติมมาจาก Encrypted Client Hello (ECH) เพื่อให้มันทำงาน เบราว์เซอร์ขอระเบียน HTTPS พิเศษใน DNS ยิ่งเว็บไซต์ใช้ ECH มาก เบราว์เซอร์ก็ยิ่งทำ DNS query มาก — และยิ่งมีช่องให้รั่วมากขึ้น ถ้า DNS ไม่ได้วิ่งตามเส้นทางที่ถูกต้อง

IPv6 และ Happy Eyeballs

ระบบสมัยใหม่ขอทั้งระเบียน A (IPv4) และ AAAA (IPv6) พร้อมกัน แล้วพยายามเชื่อมต่อกับอันที่ตอบเร็วกว่า — อัลกอริทึม Happy Eyeballs ถ้าเครือข่ายจริงของคุณรองรับ IPv6 แต่พร็อกซีทำงานผ่าน IPv4 เท่านั้น แอปพลิเคชันบางตัวสามารถออกไปตรงๆ ทาง IPv6 ข้ามพร็อกซีทั้งหมด พูดตรงๆ นี่ไม่ใช่ dns leak แต่เป็นการรั่วของการเชื่อมต่อ แต่ตัวกระตุ้นคือคำตอบ DNS ที่มี AAAA record นั่นเอง เพราะฉะนั้นในบริบทของ DNS hygiene ต้องคำนึงถึง IPv6 ไว้ด้วย

แคชและ hosts: การรั่วจากอดีต

OS แคชคำตอบ DNS ถ้าคุณทำงานโดยไม่ใช้พร็อกซี แล้วภายหลังเปิดมัน ชื่อบางชื่อก็ฝังอยู่ในแคชพร้อมที่อยู่ที่ได้จาก resolver บ้านแล้ว จะไม่มีคำขอใหม่ แต่การเชื่อมต่อจะไปยัง CDN node «บ้าน» เช่นเดียวกันกับไฟล์ hosts: ระเบียนในนั้นแทนที่การ resolve ชื่อทั้งหมด และพร็อกซีก็ไม่รู้เรื่องนี้

วิธีที่ 1. การวินิจฉัย: ตรวจสอบ dns leak ด้วยตัวเองอย่างไร

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

การทดสอบออนไลน์ทำงานอย่างไร

บริการตรวจสอบ dns leak ทุกตัวทำงานเหมือนกัน หน้าเว็บสร้างซับโดเมน уникальные หลายตัวในรูปแบบ สตริงสุ่ม.โดเมนทดสอบ แล้วบังคับให้เบราว์เซอร์ resolve พวกมัน ปกติผ่านการโหลดรูปภาพหรือสคริปต์ที่มองไม่เห็น เนื่องจากซับโดเมนนั้น уникальные จึงไม่มีทางอยู่ในแคชใดๆ คำขอจะไปถึง authoritative server ของโดเมนทดสอบที่เป็นของบริการนั้นแน่นอน มันบันทึกว่า query มาจาก IP ไหน — นั่นคือที่อยู่ของ recursive resolver ที่คุณใช้ แล้วหน้าเว็บจะแสดงสองคอลัมน์: ที่อยู่ที่การเชื่อมต่อ HTTP มาจาก และที่อยู่ของ resolver ถ้าการเชื่อมต่อมาจากโอเปอเรเตอร์มือถือ แต่ resolver เป็นของผู้ให้บริการบ้านหรือบริการ public DNS — แสดงว่ามีการรั่ว

สิ่งสำคัญที่ต้องเข้าใจ: เว็บไซต์ใดก็ทำแบบเดียวกันได้ กลไกนี้ไม่ต้องมีสิทธิ์พิเศษ ระบบแอนติ้ฟรอดของแพลตฟอร์มใหญ่ใช้เทคนิคคล้ายกันเป็นส่วนหนึ่งของการประเมินความเสี่ยงเซสชัน นี่ไม่ใช่ทฤษฎีสมคบคิด แต่เป็นวิศวกรรมมาตรฐาน

ขั้นตอนการตรวจสอบทีละขั้น

1. บันทึกพื้นฐาน ปิดพร็อกซี เปิดการทดสอบ dns leak บันทึกว่า resolver ไหนแสดงออกมา นี่คือ «fingerprint บ้าน» ของคุณ คุณควรจำได้ในพริบตา
2. ล้าง DNS cache ใน Windows คำสั่ง ipconfig /flushdns ใน macOS รีสตาร์ทบริการ mDNSResponder ใน Linux ขึ้นอยู่กับ resolver (เช่น resolvectl flush-caches สำหรับ systemd-resolved) รีสตาร์ทเบราว์เซอร์ — มันมีแคชของตัวเอง
3. เปิดพร็อกซี ด้วยวิธีที่คุณจะใช้จริง: ผ่านโปรไฟล์แอนตี้ดีเทค, ส่วนขยาย, การตั้งค่าระบบ หรือโค้ด
4. รันการทดสอบแบบขยาย ที่ทำการตรวจสอบหลายสิบครั้ง ไม่ใช่แค่ครั้งเดียว การรั่วเป็นบางส่วนได้: เก้าในสิบคำขอผ่านพร็อกซี แต่ตัวที่สิบวิ่งตรง การทดสอบเดี่ยวจะพลาดเรื่องนี้
5. เปรียบเทียบ resolver ทั้งหมดต้องเป็นของโอเปอเรเตอร์มือถือที่พร็อกซีทำงานผ่าน หรือโครงสร้างพื้นฐานของบริการพร็อกซี ไม่มีที่อยู่ใดจากพื้นฐานเลย ไม่มี public resolver ใดที่คุณไม่ได้เลือกอย่างรู้ตัว
6. ตรวจ IPv6 แยกต่างหาก ถ้าการทดสอบแสดงที่อยู่ IPv6 ใดๆ ที่ไม่ใช่ของพร็อกซี — มีการรั่ว
7. ทำซ้ำหลังสิบ นาทีทำงาน กระบวนการเบื้องหลังบางตัวเริ่มทำงานด้วยความล่าช้า

ตรวจสอบโดยไม่ใช้บริการภายนอก: โดเมนทดสอบของตัวเอง

สำหรับคนที่ทำงานกับฟาร์มบัญชีหรือ scraping ในระดับอุตสาหกรรม การมีเครื่องมือของตัวเองเป็นเรื่องสมเหตุสมผล วิธีคือ: คุณจดโดเมนราคาถูก แล้วตั้ง authoritative DNS server สำหรับมันบน VPS ของคุณพร้อมเปิด logging คำขอ จากนั้นในทุกโปรเจกต์ เมื่อเริ่มทุกเซสชัน คุณจะเข้าถึงซับโดเมน уникальный ในรูปแบบ รหัสเซสชัน.โดเมนของคุณ ในล็อกของ DNS server จะมีบันทึก: ซับโดเมนไหนถูกขอ และจาก IP resolver ไหน คุณก็จับคู่กับรหัสเซสชันแล้วเห็นทันทีว่าเซสชันไหน โปรไฟล์ไหน worker ไหนรั่ว นี่เปลี่ยนการตรวจสอบครั้งเดียวให้เป็น monitoring ต่อเนื่อง

ตรวจสอบระดับต่ำ: ดูที่เครือข่าย

วิธีที่ตรงที่สุดคือดูว่าอะไรออกจาก network interface จริงๆ เปิดตัววิเคราะห์ทราฟฟิก (Wireshark หรือ tcpdump) บน interface ทางกายภาพของเครื่อง แล้วกรองพอร์ต 53 UDP และ TCP รวมถึงพอร์ต 853 สำหรับ DoT จากนั้นทำงานผ่านพร็อกซีห้านาที ในโลกอุดมคติ filter จะว่างเปล่า: ชื่อทั้งหมดถูก resolve ที่ฝั่งพร็อกซี ไม่มีแพ็กเก็ต DNS ในเครื่องเลย ถ้ามีแพ็กเก็ต คุณก็เห็นทันทีว่าโดเมนไหนและวิ่งไปที่ไหน สำหรับ DoH filter ซับซ้อนกว่า เพราะมันคือ HTTPS ปกติบนพอร์ต 443 แต่เบาะแสคือการเชื่อมต่อไปยังที่อยู่ของ public DoH provider ที่รู้จัก ซึ่งปรากฏขึ้นโดยไม่ผ่านพร็อกซี

เช็กลิสต์การวินิจฉัย

• พื้นฐานที่ไม่มีพร็อกซีถูกบันทึกแล้ว
• แคช OS และเบราว์เซอร์ถูกล้างก่อนการทดสอบ
• การทดสอบแบบขยายหลายสิบครั้งทำเสร็จแล้ว
• resolver ทั้งหมดสอดคล้องกับฝั่งพร็อกซี
• ไม่มีที่อยู่ IPv6 ของเครือข่ายอื่น
• การทดสอบซ้ำหลัง 10 นาทีผ่านแล้ว
• สำหรับโปรเจกต์สำคัญ: ตัววิเคราะห์ทราฟฟิกบนพอร์ต 53 แสดงแพ็กเก็ตเป็นศูนย์

วิธีที่ 2. การตั้งค่าคลไคลเอนต์ซอฟต์แวร์และโค้ดที่ถูกต้อง

คุณพบการรั่วแล้ว ตอนนี้ต้องเข้าใจว่าแอปพลิเคชันตัดสินใจ resolve ชื่อในเครื่องตรงไหน และเปลี่ยนให้มันใช้การ resolve ที่ฝั่งไกล มาดูสภาพแวดล้อมที่พบบ่อยที่สุดจากประสบการณ์ของนัก arbitrage และนักพัฒนา

หลักการ: ชื่อโฮสต์ต้องไปถึงพร็อกซี

กฎมีข้อเดียว และใช้ได้สากล พร็อกซีต้องได้รับชื่อโดเมนจากคุณ ไม่ใช่ IP สำหรับ HTTP พร็อกซีมันเกิดขึ้นเองตามธรรมชาติ สำหรับ SOCKS5 ต้องเลือกโหมด remote DNS อย่างชัดเจน สำหรับ SOCKS4 ที่ไม่มีส่วนขยาย a มันเป็นไปไม่ได้ในหลักการ — พร็อกซีแบบนั้นไม่เหมาะสำหรับงานที่สะอาด มือถือพร็อกซีของบริการสมัยใหม่รองรับทั้ง HTTP และ SOCKS5 พร้อม remote resolving เพราะฉะนั้นข้อจำกัดอยู่แค่ฝั่งไคลเอนต์

curl และ command line

สำหรับ SOCKS5 ให้ใช้ scheme ที่มีตัว h เสมอ ตัวอย่างการเรียกที่ถูกต้อง:

curl -x socks5h://user:pass@host:port https://example.com/

ถ้าไม่มี h curl จะ resolve ชื่อในเครื่อง เรื่องนี้ใช้กับเครื่องมือทั้งหมดที่สร้างบน libcurl ด้วย สำหรับ HTTP พร็อกซี scheme http:// ในพารามิเตอร์ -x ก็เพียงพอ: ชื่อจะไปในคำขอ CONNECT

Python: requests, httpx, aiohttp

ในไลบรารี requests ที่ติดตั้งแพ็กเกจรองรับ SOCKS ก็มีกฎเดียวกัน: socks5:// หมายถึง local resolving, socks5h:// หมายถึง remote นี่คือข้อผิดพลาดที่พบบ่อยที่สุดในตัว scrape: นักพัฒนาคัดลอกตัวอย่างจากเอกสารที่มี socks5 แล้วก็วิ่งทราฟฟิกที่มี dns leak มาหลายปีโดยไม่รู้ตัว ใน httpx และ aiohttp การรองรับ SOCKS ทำผ่าน transport ของบุคคลที่สาม และโหมด remote resolution ต้องตรวจสอบในเอกสารของ transport นั้นๆ — บางที่มันเป็นพารามิเตอร์ rdns บางที่ก็เป็น scheme ที่มี h ตรวจสอบไม่ใช่ตามเอกสาร แต่ตามความเป็นจริง: รันสคริปต์กับโดเมนทดสอบของคุณเองแล้วดูล็อกว่า query มาจากไหน

กับดักอีกอย่างคือไลบรารี socket ระดับต่ำที่ monkey-patch โมดูล socket มาตรฐานเพื่อห่อทราฟฟิกทั้งหมดใน SOCKS พวกมันมีแฟล็ก remote resolution แต่ค่าเริ่มต้นมักปิดไว้ บวกกับทุกการเรียก socket.gethostbyname ในโค้ดของคุณหรือใน dependencies จะข้ามไปและ resolve ชื่อผ่าน resolver ของระบบ

Node.js และ headless browser

ในระบบนิเวศ Node.js SOCKS agent มักส่งชื่อโฮสต์ให้พร็อกซี แต่มันขึ้นอยู่กับแพ็กเกจและเวอร์ชันนั้นๆ สำหรับ Puppeteer และ Playwright พร็อกซีถูกกำหนดที่ระดับการเปิดเบราว์เซอร์ และพฤติกรรมสืบทอดจาก Chromium engine — เรื่องนี้จะพูดถึงในหัวข้อถัดไป ถ้าคุณใช้โหมด HTTP ของมือถือพร็อกซี คำถามก็หมดไป: Chromium จะส่ง CONNECT พร้อมชื่อโฮสต์

Go, Java และภาษาอื่นๆ

ใน Go แพ็กเกจมาตรฐาน golang.org/x/net/proxy สำหรับ SOCKS5 ส่งชื่อโฮสต์ไปฝั่งไกล แต่เฉพาะเมื่อคุณใช้ Dialer ของมันโดยตรง ไม่ใช่ resolve ก่อน ใน Java system property สำหรับ SOCKS พร็อกซีทำงานได้ แต่ HTTP client หลายตัวสร้างออบเจกต์ InetSocketAddress พร้อมการ resolve ล่วงหน้า ซึ่งทำให้เกิดการรั่ว ทางแก้คือสร้างที่อยู่ที่ยังไม่ resolve (เมธอดอย่าง createUnresolved) และตรวจสอบว่าไคลเอนต์รองรับการส่งชื่อ คำแนะนำสากลสำหรับภาษาใดๆ: ค้นหาในโค้ดและใน dependencies ทุกที่ที่โดเมนกลายเป็น IP แล้วตรวจสอบว่ามันเกิดขึ้นหลังการเชื่อมต่อกับพร็อกซี ไม่ใช่ก่อน

การ audit โปรเจกต์ทีละขั้น

1. ค้นหาทุกสตริงการเชื่อมต่อพร็อกซีในโค้ด ตรวจสอบ scheme: socks5 ที่ไม่มี h — ธงแดง
2. ค้นหาทุกการเรียก resolve ชื่ออย่างชัดเจน: gethostbyname, getaddrinfo, dns.lookup, InetAddress.getByName ทุกตัวคือการรั่วที่เป็นไปได้
3. ตรวจสอบ dependencies: ไลบรารีตรวจสอบการเข้าถึง, health-check, retry ที่ ping ล่วงหน้า
4. รันโปรเจกต์กับโดเมนทดสอบของคุณเองโดยใช้ซับโดเมน уникальный สำหรับทุก worker ล็อก DNS server จะแสดงว่าใครรั่ว
5. เพิ่ม autotest: เซสชันจะไม่ถือว่า valid จนกว่าการตรวจสอบ DNS จะยืนยันว่า resolver เป็นของฝั่งพร็อกซี
6. บันทึกผลลัพธ์ในเอกสารโปรเจกต์: ไลบรารีไหน เวอร์ชันไหน โหมดไหน

เช็กลิสต์สำหรับนักพัฒนา

• การเชื่อมต่อ SOCKS5 ทั้งหมดใช้ remote resolution
• ไม่มีการ resolve ล่วงหน้าก่อนเชื่อมต่อ
• ไลบรารีตรวจสอบแล้วไม่ใช่จากเอกสาร แต่จากล็อกของโดเมนทดสอบ
• การตรวจสอบ DNS อัตโนมัติฝังอยู่ในการเริ่มเซสชัน
• สำหรับโหมด HTTP พร็อกซี ตรวจสอบว่าใช้ CONNECT ไม่ใช่การแทนที่ด้วย IP

วิธีที่ 3. เบราว์เซอร์และแอนตี้ดีเทคเบราว์เซอร์ที่ไม่รั่ว DNS

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

Firefox และทายาท

Firefox ให้การควบคุมที่โปร่งใสที่สุดมาโดยตลอด พารามิเตอร์สำคัญใน about:config คือ network.proxy.socks_remote_dns ถ้าค่าเป็น true ชื่อจะถูกส่งให้ SOCKS พร็อกซีเพื่อ resolve ที่ฝั่งไกล ถ้าเป็น false — resolve ในเครื่อง ในบิลด์และโปรไฟล์เก่าหลายตัวมันปิดอยู่ พารามิเตอร์ที่สองคือ network.trr.mode ซึ่งควบคุม encrypted DNS: ค่า 5 ปิดมันทั้งหมด ซึ่งสำหรับการทำงานผ่านพร็อกซีเป็นที่นิยมกว่า เพราะไม่งั้นเบราว์เซอร์อาจติดต่อ DoH server ด้วยไคลเอนต์ของตัวเอง บล็อกที่สามคือ prefetch: network.dns.disablePrefetch เป็น true และ network.predictor.enabled เป็น false ปิดการ resolve ชื่อแบบ speculative สำหรับลิงก์บนหน้า ซึ่งไม่งั้นอาจวิ่งนอกพร็อกซีก่อนที่จะคลิกจริง แอนตี้ดีเทคเบราว์เซอร์บน engine Firefox มักตั้งค่าพารามิเตอร์เหล่านี้ถูกต้อง แต่ควรตรวจทุกครั้งหลังอัปเดต

Chrome, Chromium และแอนตี้ดีเทคที่สร้างบนพื้นฐานของมัน

กับ Chromium เรื่องซับซ้อนกว่า เมื่อทำงานผ่าน HTTP พร็อกซี มันส่ง CONNECT พร้อมชื่อ — ไม่มีการรั่ว แต่เมื่อใช้ SOCKS5 พร็อกซีผ่านแฟล็กเปิดตัว engine ในการกำหนดค่าบางแบบจะ resolve ชื่อในเครื่อง และไม่มีการตั้งค่า «remote DNS» ในอินเทอร์เฟซ กลเม็ดทางวิศวกรรมที่รู้จักกันดีคือแฟล็ก --host-resolver-rules พร้อมกฎที่ map ชื่อทั้งหมดให้อยู่ในสถานะ «ไม่พบ» ยกเว้นที่อยู่ของพร็อกซีเอง ผลคือ local resolver ไม่สามารถ resolve อะไรได้ และเบราว์เซอร์ถูกบังคับให้ส่งชื่อให้พร็อกซี ดูเหมือน hack แต่ทำงานได้เชื่อถือได้ จุดสำคัญที่สองคือการตั้ง secure DNS ในส่วนความเป็นส่วนตัว: เมื่อเปิด Chromium จะใช้ DoH กับผู้ให้บริการที่เลือก และทราฟฟิกนี้ไม่ได้ตามพร็อกซีเสมอ สำหรับการทำงานผ่านมือถือพร็อกซีควรปิดมัน หรือตรวจสอบในการทดสอบว่ามันถูก tunnel อย่างถูกต้อง ที่สามคือ prefetch หน้า: ในการตั้งค่าประสิทธิภาพมีตัวเลือก prefetch ที่เริ่ม DNS query สำหรับลิงก์ที่คุณยังไม่ได้คลิก

แอนตี้ดีเทคเบราว์เซอร์ที่ดีควรทำอะไรได้

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

• โหมด remote DNS สำหรับ SOCKS5 เปิดโดยค่าเริ่มต้นสำหรับทุกโปรไฟล์ ไม่ใช่แค่ระดับ global
• การแยก DNS ระหว่างโปรไฟล์ แคชของชื่อที่ resolve แล้วไม่ควรใช้ร่วมกัน ไม่งั้นโปรไฟล์บนมือถือพร็อกซีภูมิภาคหนึ่งจะได้ IP ที่โปรไฟล์บนพร็อกซีอีกภูมิภาคแคชไว้
• Encrypted DNS ที่ปิดหรือ tunnel ได้ ถามฝ่ายสนับสนุนตรงๆ: DoH ในตัวทำงานอย่างไรเมื่อผ่านพร็อกซี
• Prefetch ที่ปิด การ resolve แบบ speculative ไม่ควรอยู่ในโปรไฟล์ที่แสร้งว่าเป็นผู้ใช้มือถือธรรมดา
• การตรวจสอบในตัว dns leak ตอนเริ่มโปรไฟล์ หรืออย่างน้อยทางลัดไปยังการทดสอบที่สะดวก
• พฤติกรรมเมื่อพร็อกซีขาด เบราว์เซอร์ทำอะไรถ้าพร็อกซีเข้าถึงไม่ได้: บล็อกการเชื่อมต่อหรือออกไปตรงๆ? อย่างหลังคือหายนะ ไม่ใช่แค่เรื่อง DNS

ส่วนขยายพร็อกซี: น้ำแข็งบางๆ

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

การตั้งค่าโปรไฟล์ทีละขั้น

1. สร้างโปรไฟล์และระบุมือถือพร็อกซี แนะนำโหมด HTTP ถ้าแอนตี้ดีเทคไม่รับประกัน remote DNS สำหรับ SOCKS5
2. ปิด encrypted DNS ในการตั้งค่า engine หรือโปรไฟล์
3. ปิด prefetch หน้าและ DNS-prefetch
4. ถ้าเป็น engine แบบ Firefox — ตรวจสอบ socks_remote_dns ด้วยตัวเอง
5. เปิดโปรไฟล์ ล้างแคช และผ่านการทดสอบ dns leak แบบขยาย
6. เดินเล่นผ่านหลายเว็บไซต์ที่มี analytics ทำงาน แล้วทำการทดสอบซ้ำ: มี resolver ใหม่โผล่มาไหม
7. บันทึกผลลัพธ์เป็นค่าอ้างอิงสำหรับโปรไฟล์นี้

วิธีที่ 4. ระดับระบบและโครงสร้างพื้นฐาน: ปิดการรั่วแบบบังคับ

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

หลักการ «ห้ามทุกอย่างที่ไม่ผ่านพร็อกซี»

บนเครื่องทำงานหรือเซิร์ฟเวอร์ฟาร์ม จะตั้ง firewall ที่บล็อกทราฟฟิกขาออกไปยังพอร์ต 53 (UDP และ TCP) และพอร์ต 853 สำหรับทุกโปรเซส ยกเว้นที่อนุญาตชัดเจน ใน Windows คือกฎ outbound ใน Firewall ใน Linux — nftables หรือ iptables ใน macOS — pf ความหมายคือ: ถ้าเบราว์เซอร์หรือสคริปต์พยายาม resolve ชื่อในเครื่อง มันจะได้ error ไม่ใช่การรั่วเงียบๆ error นั้นเห็นทันที — คุณจะเห็นและแก้การตั้งค่าแอปพลิเคชัน การรั่วเงียบๆ อาจอยู่ได้เป็นเดือน

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

การแยกผ่านคอนเทนเนอร์และ network namespace

สำหรับนักพัฒนาและเจ้าของฟาร์มบน Linux เครื่องมือที่ทรงพลังที่สุดคือ network namespace และคอนเทนเนอร์ ไอเดีย: ทุก worker ทุกโปรไฟล์เบราว์เซอร์หรือกลุ่มโปรไฟล์อยู่ใน network namespace ของตัวเอง ซึ่งไม่มี default route ออกอินเทอร์เน็ตเลย ทางเดียวออกไปคือที่อยู่ของพร็อกซี อะไรก็ตามที่แอปพลิเคชันพยายามทำ — resolve ชื่อ, ออกไปทาง IPv6, เปิดการเชื่อมต่อตรง — มันไม่มี route ทางกายภาพ นี่คือวิธีที่เชื่อถือได้ที่สุดในการรับประกันไม่มี dns leak ในระดับ scale ใน Docker ทำได้ด้วย custom network ที่ไม่มี external gateway บวกกับอนุญาตการเข้าถึงเฉพาะที่อยู่ของพร็อกซี เพิ่มเติมในการตั้งค่า resolver ของคอนเทนเนอร์สามารถระบุที่อยู่ที่เข้าถึงไม่ได้ เพื่อให้ทุกความพยายาม resolve ในเครื่องล้มเหลวทันที ไม่ใช่ค้างจน timeout

IPv6 ในระดับระบบ

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

System resolver และลักษณะพิเศษ

OS สมัยใหม่มี resolver หลายชั้น ใน Windows 11 มีการรองรับ DoH ในระดับระบบ และถ้าเปิดสำหรับ adapter ของคุณ การ resolve ในเครื่องทั้งหมดจะไปยัง DoH server ที่เลือก สำหรับเครื่องทำงานที่มีพร็อกซี ต้องตระหนักเรื่องนี้: system DoH ที่เปิดอยู่เปลี่ยนภาพการรั่ว แต่ไม่ได้กำจัดมัน Android ใช้ฟีเจอร์ Private DNS — เรื่องคล้ายกันสำหรับคนที่ทำงานกับพร็อกซีบนอุปกรณ์มือถือหรือ emulator ใน Linux ที่ใช้ systemd-resolved ควรตรวจสอบว่า DNS server ไหนถูกกำหนดให้ interface ไหน เพราะ resolver สามารถ route คำขอตามโดเมนซัฟฟิกซ์ระหว่าง interface ได้ และนี่สร้างเส้นทางที่ไม่คาดคิด

การ monitoring เป็นกระบวนการ

ในระดับโครงสร้างพื้นฐาน การตรวจสอบ dns leak เปลี่ยนจากครั้งเดียวเป็นต่อเนื่อง สิ่งที่ควรนำมาใช้:

• การ log ความพยายาม DNS ที่ถูกบล็อก โดย firewall ทุกรายการในล็อกคือแอปพลิเคชันที่พยายาม resolve ในเครื่อง นี่คือรายการที่คุณต้องแก้
• โดเมนทดสอบของตัวเอง พร้อมซับโดเมน уникальный ต่อเซสชันและ alert อัตโนมัติเมื่อมี resolver แปลกปลอมโผล่มา
• สแนปช็อตทราฟฟิกเครือข่ายเป็นระยะ บนพอร์ต 53 จาก interface ทางกายภาพ — วันละครั้ง อัตโนมัติ พร้อม alert เมื่อตัวนับไม่เป็นศูนย์
• ตรวจสอบหลังทุกการอัปเดต ของเบราว์เซอร์ แอนตี้ดีเทค ไลบรารี การอัปเดตคือแหล่ง regression หลัก: นักพัฒนาเปลี่ยนค่าเริ่มต้น เปิดฟีเจอร์ prefetch ใหม่ เพิ่ม encrypted DNS

เช็กลิสต์ระดับระบบ

• ทราฟฟิกขาออกไปยังพอร์ต 53 และ 853 ถูกบล็อกสำหรับโปรเซสทำงาน
• ที่อยู่ public DoH ที่รู้จักถูกบล็อกสำหรับโปรเซสเดียวกัน
• IPv6 ถูกปิดหรือบล็อกบน interface ทำงาน
• worker สำคัญถูกแยกใน network namespace ที่ไม่มี route ตรง
• ล็อก firewall เรื่อง DNS ถูกรวบรวมและตรวจสอบ
• โดเมนทดสอบและ alerting ถูกตั้งค่าแล้ว

ข้อผิดพลาดทั่วไป: สิ่งที่ไม่ควรทำ

ข้อผิดพลาด 1. ตรวจแค่ IP

ที่พบบ่อยที่สุด คนเห็นที่อยู่โอเปอเรเตอร์มือถือบนหน้าตรวจสอบ IP แล้วถือว่างานเสร็จ แต่การตรวจ IP ตอบแค่คำถาม «การเชื่อมต่อมาจากไหน» ไม่ใช่ «DNS query มาจากไหน» สองคำถาม สองคำตอบ

ข้อผิดพลาด 2. ระบุ public DNS แล้วสบายใจ

ตรรกะเข้าใจได้: ถ้าผู้ให้บริการเห็นคำขอของฉัน ก็ระบุ public resolver ไป แต่สำหรับการทำงานผ่านพร็อกซี นี่ไม่ใช่วิธีแก้ แต่เป็นการเปลี่ยนการรั่วหนึ่งเป็นการรั่วอีกอย่าง คำขอยังคงออกจาก IP จริงของคุณ เพียงแต่ไปยังผู้สังเกตอีกราย และ public resolver ยังใช้ ECS ส่งซับเน็ตของคุณให้ authoritative server อีกด้วย ความไม่สอดคล้องระหว่างฝั่ง DNS กับฝั่งการเชื่อมต่อยังคงอยู่

ข้อผิดพลาด 3. ใช้ SOCKS5 โดยไม่มี remote DNS

scheme socks5 แทน socks5h ในโค้ด, socks_remote_dns ที่ปิดในเบราว์เซอร์, แอนตี้ดีเทคที่มี local resolving เป็นค่าเริ่มต้น โปรเจกต์นับพันอยู่กับข้อผิดพลาดนี้มาหลายปี

ข้อผิดพลาด 4. คิดว่า encrypted DNS คือทางออกของปัญหา

DoH ปกป้องเนื้อหาคำขอจากผู้ให้บริการ แต่เมื่อทำงานผ่านพร็อกซี มันสร้างช่องทางแยกที่ไม่ได้ผ่านพร็อกซี การเข้ารหัสไม่เท่ากับการ route ที่ถูกต้อง

ข้อผิดพลาด 5. มองข้าม prefetch และบริการเบื้องหลัง

เบราว์เซอร์ resolve ชื่อของลิงก์ที่คุณยังไม่ได้เปิด โปรแกรมแอนตี้ไวรัสตรวจ URL ตัวอัปเดตหาเซิร์ฟเวอร์อัปเดต ทั้งหมดนี้คือ DNS query ที่อาจวิ่งอ้อม การทดสอบครั้งเดียวไม่จับเรื่องพวกนี้

ข้อผิดพลาด 6. แคช DNS ร่วมกันระหว่างโปรไฟล์

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

ข้อผิดพลาด 7. ไม่ทดสอบหลังการอัปเดต

เบราว์เซอร์เวอร์ชันใหม่เปิด safe DNS เป็นค่าเริ่มต้น ไลบรารีที่อัปเดตเปลี่ยนพฤติกรรม SOCKS การอัปเดตแอนตี้ดีเทครีเซ็ตการตั้งค่า engine ทั้งหมดนี้คือสถานการณ์จริงที่เปิดเผยได้ด้วยการตรวจสอบซ้ำเท่านั้น

ข้อผิดพลาด 8. อนุญาตให้ออกตรงเมื่อพร็อกซีเข้าถึงไม่ได้

การตั้งค่าแบบ «ถ้าพร็อกซีไม่ตอบ ให้ออกไปตรง» เปลี่ยนทุกความล้มเหลวเป็นการ de-anonymize เซสชันทั้งหมด เริ่มจาก DNS พฤติกรรมที่ถูกต้องคือบล็อกการเชื่อมต่อจนกว่าพร็อกซีจะกลับมา

ข้อผิดพลาด 9. Resolve ด้วยมือ «เพื่อความเร็ว»

ตัว scrape บางตัว resolve โดเมนครั้งเดียวแล้ววิ่งตาม IP เพื่อประหยัด DNS นอกจากจะรั่วคำขอแล้ว ยังได้ IP ที่ geo-DNS เลือกสำหรับภูมิภาคจริงของคุณ แล้วค่อยส่งทราฟฟิกผ่านมือถือพร็อกซีไปยัง CDN node «อื่น» การประหยัดมิลลิวินาทีกลายเป็นโปรไฟล์ที่ไม่สอดคล้อง

เครื่องมือและทรัพยากร

การทดสอบการรั่วออนไลน์

บริการตรวจสอบ dns leak แบ่งเป็นพื้นฐานและแบบขยาย แบบพื้นฐานทำหนึ่งสองคำขอ เหมาะกับการประเมินเร็ว แบบขยายสร้างซับโดเมน уникальный หลายสิบตัวและเปิดเผยการรั่วบางส่วน สำหรับการทำงานให้เลือกที่แสดงไม่ใช่แค่ IP ของ resolver แต่รวมถึงสังกัด: องค์กร ระบบอัตโนมัติ ประเทศ การทดสอบที่ดียังแสดง IPv4 และ IPv6 แยกกัน และทดสอบพฤติกรรมเมื่อคำขอซ้ำ

ตัววิเคราะห์ทราฟฟิก

Wireshark — ตัววิเคราะห์แบบกราฟิกพร้อมฟิลเตอร์อย่าง dns หรือ udp.port == 53 tcpdump — คอนโซลเทียบเท่าสำหรับเซิร์ฟเวอร์และเครื่อง Linux ทั้งคู่ให้คุณเห็นความจริง: อะไรออกจาก network interface จริงๆ สำหรับ DoH ให้ดูเพิ่มที่การเชื่อมต่อ TLS ไปยังที่อยู่ของ public resolver

Authoritative DNS ของตัวเอง

สำหรับ monitoring ในระดับ scale: DNS server เบาๆ ใดก็ได้ที่ log คำขอ (CoreDNS, Unbound ในโหมด authoritative, BIND, เซิร์ฟเวอร์เล็กๆ บน Go หรือ Python) บวกกับโดเมนของตัวเอง ค่าใช้จ่ายต่ำมาก แต่ผลลัพธ์คือการเฝ้าระวัง worker และโปรไฟล์ทั้งหมดอย่างต่อเนื่อง

เครื่องมือ command line

dig และ nslookup แสดงว่า system ติดต่อ resolver ไหนและมันตอบอะไร resolvectl ใน Linux กับ systemd-resolved แสดง config DNS แยกตาม interface curl พร้อมแฟล็กแสดงผลละเอียดแสดงว่ามันส่งชื่อให้พร็อกซีหรือ resolve เอง ใน Windows ipconfig /displaydns จะแสดงเนื้อหาแคช และ Get-DnsClientServerAddress ใน PowerShell — เซิร์ฟเวอร์ที่กำหนดตาม adapter

Firewall

Windows Firewall ในตัวพร้อมกฎตามโปรแกรม, nftables และ iptables ใน Linux, pf ใน macOS สำหรับการจัดการกฎตามแอปพลิเคชันที่สะดวกมีส่วนเสริมแบบ GUI ข้อกำหนดหลักคือความสามารถในการบล็อกพอร์ตสำหรับโปรเซสเฉพาะและ log การบล็อกได้

การ containerize

Docker และ Podman พร้อม custom network, Linux network namespace ผ่าน ip netns และสำหรับฟาร์มเบราว์เซอร์ — ตัวจัดการโปรไฟล์ที่รองรับการแยกเครือข่ายในระดับโปรไฟล์ พวกมันเปลี่ยนกฎ «เฉพาะผ่านพร็อกซี» จากการตั้งค่าเป็นการรับประกันเชิงสถาปัตยกรรม

ความสามารถฝั่งบริการพร็อกซี

ให้ความสนใจกับสิ่งที่ผู้ให้บริการมือถือพร็อกซีเสนอ: การรองรับ SOCKS5 พร้อม remote resolution, โหมด HTTP ที่จัดการ CONNECT อย่างถูกต้อง, ความเสถียรของ DNS ฝั่งโอเปอเรเตอร์, ไม่มีการแทนที่คำตอบ DNS ฝั่งโครงสร้างพื้นฐาน มีประโยชน์ที่จะถามฝ่ายสนับสนุนว่า resolve ชื่อผ่าน resolver ไหนเมื่อทำ remote resolving — คำตอบที่ถูกต้องคือ: ผ่าน resolver ของโอเปอเรเตอร์มือถือที่โมเด็มเชื่อมต่ออยู่

เคสและผลลัพธ์

เคส 1. ฟาร์มบัญชีโฆษณาและสาเหตุการแบนที่มองไม่เห็น

ทีมนัก arbitrage ดูแลบัญชีโฆษณาประมาณ 120 บัญชีบนมือถือพร็อกซีผ่านแอนตี้ดีเทคยอดนิยม อายุเฉลี่ยของบัญชีจนถึงแบนอยู่ที่ 9–12 วัน โดยการตั้งค่าดูสมบูรณ์แบบ: มือถือ IP ในภูมิภาคที่ถูกต้อง, fingerprint ที่เรียบร้อย, การอุ่นเครื่อง การ audit พบว่าหลังการอัปเดตแอนตี้ดีเทคล่าสุด encrypted DNS ถูกเปิดใน engine และทุกโปรไฟล์ resolve ชื่อผ่าน public DoH resolver เดียวกันจาก IP จริงของออฟฟิศ ผู้ใช้ «อิสระ» 120 คนจากต่างเมือง resolve ชื่อจากจุดเดียวกัน หลังปิด DoH เปิด remote DNS และบล็อกพอร์ต 53 ด้วย firewall อายุเฉลี่ยของบัญชีเพิ่มเป็น 30+ วัน และสัดส่วนการแบนเร็วในสัปดาห์แรกลดลงประมาณสามเท่า ค่าใช้จ่ายในการแก้ไข — สองชั่วโมงของ specialists หนึ่งคน

เคส 2. ตัว scrape มาร์เก็ตเพลสและราคาตามภูมิภาคที่ลึกลับ

นักพัฒนารวบรวมราคาจากมาร์เก็ตเพลสขนาดใหญ่ตามภูมิภาคผ่านมือถือพร็อกซีต่างเมือง ข้อมูลไม่ตรงกับที่ผู้ใช้จริงในภูมิภาคนั้นเห็น: ส่วนหนึ่งของราคาและสต็อกสอดคล้องกับอีกเมืองหนึ่ง สาเหตุกลับอยู่ที่สตริงการเชื่อมต่อ: ไลบรารี requests กับ scheme socks5 ที่ไม่มี h ชื่อถูก resolve ในเครื่องที่เมืองของนักพัฒนา geo-DNS ของมาร์เก็ตเพลสให้ node ของภูมิภาคเขา และต่อมาคำขอผ่านมือถือพร็อกซีของอีกเมืองไปถึง node «อื่น» ซึ่งส่งผลลัพธ์ตามภูมิภาคตามตรรกะของมันเอง การเปลี่ยนตัวอักษรเดียวในการตั้งค่าและการเพิ่มการตรวจสอบ DNS อัตโนมัติเมื่อเริ่ม worker ทุกตัวคืนความถูกต้องของข้อมูล ผลข้างเคียง: สัดส่วนคำขอที่มาร์เก็ตเพลสตอบด้วย captcha ลดลง — เซสชันสอดคล้องกันมากขึ้น

เคส 3. การทดสอบโฆษณาสำหรับผู้ชมตามภูมิภาค

เอเจนซีการตลาดตรวจสอบว่าโฆษณาและ landing page แสดงต่อผู้ใช้ต่างภูมิภาคอย่างไร โดยทำงานผ่านมือถือพร็อกซีและเบราว์เซอร์ Chromium ที่เชื่อมต่อ SOCKS5 การทดสอบบางส่วนแสดงเนื้อหาของภูมิภาคที่ไม่ถูกต้อง ในล็อกของโดเมนทดสอบของเอเจนซีเอง resolver เป็นของผู้ให้บริการของออฟฟิศ การเปลี่ยนไปใช้โหมด HTTP ของมือถือพร็อกซีเดียวกัน ซึ่ง Chromium ส่งชื่อผ่าน CONNECT บวกกับการปิด prefetch หน้า ลบความไม่สอดคล้องนั้นได้ โบนัสเพิ่มเติม — ผลการทดสอบที่เสถียรโดยไม่ต้องรันซ้ำ ประหยัดเวลาทีมประมาณ 15 เปอร์เซ็นต์ในการ audit ประจำ

เคส 4. มัลติแอคเคาน์ติ้งในโซเชียลมีเดียและแคชร่วม

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

ข้อสรุปรวมจากเคส

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

FAQ: คำถามยากเรื่องการรั่ว DNS

ถ้าเว็บไซต์ไม่ได้รับ DNS query ของฉัน มันรู้เรื่องการรั่วได้อย่างไร?

ผ่านสามเส้นทางอ้อม เส้นทางแรก — ซับโดเมนทดสอบเฉพาะ: เว็บไซต์สามารถบังคับเบราว์เซอร์ของคุณให้ resolve โดเมนที่มันควบคุมเอง แล้วดูว่า query มาจาก resolver ไหน เส้นทางที่สอง — geo-DNS และ CDN: ถ้าคุณมาถึง node ที่ออกแบบสำหรับภูมิภาคอื่น ความไม่สอดคล้องกับ IP ของคุณก็เห็นได้จากฝั่งโครงสร้างพื้นฐาน เส้นทางที่สาม — EDNS Client Subnet: public resolver ส่งซับเน็ตของไคลเอนต์ให้ authoritative server และมันไม่ตรงกับซับเน็ตของการเชื่อมต่อ ไม่มีเส้นทางใดที่ต้องเข้าถึงผู้ให้บริการของคุณ

มือถือพร็อกซี resolve ชื่อผ่านโอเปอเรเตอร์ นี่ดีหรือไม่ดี?

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

โหมด HTTP ของมือถือพร็อกซีดีกว่า SOCKS5 ในแง่ DNS ตรงไหน?

ตรงที่ในโหมด HTTP ชื่อโฮสต์ถูกส่งให้พร็อกซีตามนิยามของโปรโตคอล — ใน CONNECT สำหรับ HTTPS และใน URL สำหรับ HTTP ไคลเอนต์ไม่สามารถresolve ชื่อในเครื่องโดยบังเอิญได้ ยกเว้นกรณีแปลกๆ อย่าง PAC script ใน SOCKS5 remote resolution เป็นตัวเลือกที่ไคลเอนต์ต้องเลือกอย่างชัดเจน และไคลเอนต์หลายตัวไม่ทำเป็นค่าเริ่มต้น ถ้าคุณไม่แน่ใจในพฤติกรรมของเบราว์เซอร์หรือไลบรารีเฉพาะ โหมด HTTP ปลอดภัยกว่า SOCKS5 สะดวกกว่าสำหรับโปรโตคอลที่ไม่ใช่ HTTP แต่ต้องควบคุม

แค่ปิด safe DNS ในเบราว์เซอร์ก็เพียงพอไหม?

ไม่ นั่นปิดช่องทางหนึ่ง — DoH ของเบราว์เซอร์ ยังเหลือ local resolution สำหรับ SOCKS5, prefetch, บริการเบื้องหลัง, system DoH ใน OS และ IPv6 การปิด safe DNS เป็นขั้นตอนที่จำเป็นแต่ไม่เพียงพอ สิ่งที่เพียงพอคือการยืนยันด้วยการทดสอบแบบขยาย และในอุดมคติ — บล็อก DNS ตรงที่ระดับระบบ

ถ้าในการทดสอบมี resolver ที่ไม่ใช่ของฉันและไม่ใช่ของโอเปอเรเตอร์ ควรทำอย่างไร?

ค่อยๆ ไล่ตามห่วงโซ่ ก่อนอื่นระบุองค์กรตาม IP: ถ้าเป็น public DNS service ให้หา DoH ที่เปิดในเบราว์เซอร์หรือระบบ ถ้าเป็น hosting ที่ไม่รู้จัก อาจเป็นโครงสร้างพื้นฐานพร็อกซีที่ใช้ resolver ของตัวเองแทนของโอเปอเรเตอร์ — ถามผู้ให้บริการ ถ้าเป็นผู้ให้บริการของคุณ แต่ไม่ใช่ resolver ที่เห็นในพื้นฐาน — อาจเป็น IPv6 หรือ adapter อื่น ทุก resolver ที่ไม่คาดคิดมีคำอธิบาย และต้องหามันให้เจอ ไม่ใช่เพิกเฉย

dns leak มีผลต่อความเร็วในการทำงานผ่านพร็อกซีไหม?

มี และบ่อยครั้งไปในทางที่ไม่คาดคิด เมื่อ resolve ในเครื่อง geo-DNS เลือก CDN node ใกล้ตำแหน่งจริงของคุณ แล้วทราฟฟิกวิ่งผ่านเครือข่ายมือถือของอีกภูมิภาคไปยัง node นั้น — เส้นทางยาวกว่าที่ควร เมื่อ resolve ที่ฝั่งไกล node ถูกเลือกใกล้ทางออกของพร็อกซี และเส้นทางจากพร็อกซีไปยังเซิร์ฟเวอร์สั้นกว่า เพราะฉะนั้นการตั้งค่า DNS ที่ถูกต้องมักไม่ทำให้ช้า และในบางกรณีทำให้โหลดเร็วขึ้น

จะทดสอบ dns leak ในสถานการณ์อัตโนมัติโดยไม่มีเบราว์เซอร์ได้อย่างไร?

เส้นทางที่เชื่อถือได้ที่สุด — โดเมนทดสอบของตัวเอง เมื่อเริ่มทุก worker สคริปต์เข้าถึงผ่านพร็อกซีไปยังซับโดเมน unique และ authoritative DNS server ของคุณ log ว่า query มาจาก resolver ไหน สคริปต์อ่านล็อกผ่าน API และเปรียบเทียบที่อยู่ resolver กับช่วงที่คาดหวังของโอเปอเรเตอร์ ถ้าไม่ตรง เซสชันจะไม่เริ่ม นี่เปลี่ยนการตรวจสอบจาก manual เป็น contractual: worker ไม่มีสิทธิ์ทำงานจนกว่าจะพิสูจน์ความสะอาดของ DNS ได้

ภาพเปลี่ยนไปอย่างไรเมื่อ ECH และ encrypted DNS แพร่หลายในปี 2026?

ภูมิทัศน์เคลื่อนไปในทาง «DNS สำคัญขึ้น» ECH ขึ้นอยู่กับระเบียน DNS ประเภท HTTPS, เบราว์เซอร์เปิด encrypted DNS เป็นค่าเริ่มต้น, ระบบปฏิบัติการเพิ่ม system DoH และ DoQ สำหรับผู้ใช้ทั่วไปนี่เป็นบวกต่อความเป็นส่วนตัว สำหรับคนที่ทำงานผ่านพร็อกซี นี่หมายถึง DNS traffic มากขึ้น, DNS client อิสระมากขึ้นในระบบ และจุดที่ query อาจวิ่งนอกพร็อกซีมากขึ้น ระบบแอนติ้ฟรอดก็ยิ่งใช้ความสอดคล้องระหว่างฝั่ง DNS กับฝั่งการเชื่อมต่อเป็นสัญญาณมากขึ้น ข้อสรุป: วินัยในการจัดการ DNS เปลี่ยนจาก «น่าจะทำ» เป็น «ต้องทำ»

เชื่อถือแอนตี้ดีเทคเบราว์เซอร์ที่โฆษณาว่าป้องกัน dns leak ได้ไหม?

เชื่อได้ — แต่ต้องตรวจเสมอ คำโฆษณาไม่ลบล้าง regression หลังการอัปเดต ความแตกต่างระหว่าง engine และลักษณะเฉพาะของการตั้งค่าพร็อกซีของคุณ ตรวจสอบทุกโปรไฟล์หลังสร้างและหลังทุกการอัปเดตเบราว์เซอร์ การทดสอบแบบขยายหนึ่งครั้งใช้เวลาหนึ่งนาที แต่การกู้ฟาร์มที่ถูกเผาใช้เวลาเป็นสัปดาห์

บทสรุป: DNS คือรากฐานของเซสชันที่สะอาด

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

เราดูว่า DNS รั่วอย่างไรในสถานการณ์ต่างๆ: SOCKS ที่ไม่มี remote resolution, encrypted DNS ในเบราว์เซอร์และระบบ, prefetch, แคชร่วม, IPv6, PAC script และการ resolve ล่วงหน้าในโค้ด เราให้สี่วิธีที่ทำงานร่วมกัน: การวินิจฉัยพร้อมพื้นฐานและการทดสอบแบบขยาย, การตั้งค่าไคลเอนต์และไลบรารีที่ถูกต้อง, การตั้งค่าเบราว์เซอร์และแอนตี้ดีเทค และสุดท้ายการป้องกันแบบบังคับที่ระดับ firewall และการแยกเครือข่าย แต่ละวิธีปิดส่วนหนึ่งของปัญหา ทั้งหมดร่วมกัน — ทำให้การรั่วเป็นไปไม่ได้ในทางเทคนิค

ก้าวต่อไปของคุณ

1. วันนี้: บันทึกพื้นฐานโดยไม่มีพร็อกซี แล้วผ่านการทดสอบ dns leak แบบขยายในทุกโปรไฟล์ทำงานและทุกสคริปต์ บันทึกผลลัพธ์
2. สัปดาห์นี้: ตรวจสอบทุกสตริงการเชื่อมต่อในโค้ดว่ามี socks5 ที่ไม่มี h ไหม ปิด encrypted DNS และ prefetch ในเบราว์เซอร์ ตรวจสอบการแยกแคชระหว่างโปรไฟล์
3. เดือนนี้: บล็อก DNS ตรงที่ระดับระบบสำหรับโปรเซสทำงาน ปิดหรือบล็อก IPv6 บน interface ทำงาน ตั้งโดเมนทดสอบของตัวเองพร้อม logging
4. ตลอดไป: ทำการทดสอบซ้ำหลังทุกการอัปเดตเบราว์เซอร์ แอนตี้ดีเทค และไลบรารี ทำให้มันเป็นพิธีกรรมเหมือนการตรวจ IP

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