การรั่วไหลของ IP ที่แท้จริงใน WebRTC: วิธีตรวจสอบและแก้ไข — คู่มือทีละขั้นตอน

บทนำ

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

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

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

เวลาในการดำเนินการ: การตรวจสอบพื้นฐานและการปิดการรั่วไหลในเบราว์เซอร์หนึ่งตัวใช้เวลา 40–60 นาที; การเพิ่มส่วนขยาย การทำงานกับเบราว์เซอร์ป้องกัน และการทดสอบขั้นสุดท้ายอีก 20–30 นาที หากคุณกำลังตั้งค่าหลายเบราว์เซอร์และโปรไฟล์ ควรเตรียมเวลาประมาณ 90–120 นาที

การเตรียมตัวเบื้องต้น

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

เครื่องมือและสิทธิ์ที่ต้องการ

• การเข้าถึงเบราว์เซอร์ที่ทำงานได้บนคอมพิวเตอร์ (Chrome, Edge, Firefox, Opera หรือ Safari)
• การเข้าถึงการตั้งค่าของพร็อกซีที่คุณใช้ (HTTP(S) หรือ SOCKS5) หากคุณทำงานกับพร็อกซีมือถือ ให้เตรียมสิทธิ์จากผู้ให้บริการ ตัวอย่างของบริการดังกล่าวคือ mobileproxy.space
• ความพร้อมในการติดตั้งส่วนขยายเพื่อจัดการ WebRTC (เช่น ส่วนขยายที่จำกัดหรือปิด WebRTC ในเบราว์เซอร์ที่ใช้โครเมียม) และ uBlock Origin เพื่อเพิ่มความปลอดภัยเพิ่มเติม
• หากใช้เบราว์เซอร์การป้องกัน: การเข้าถึงบัญชีของคุณและแผงควบคุมการตั้งค่าโปรไฟล์

ข้อกำหนดของระบบ

• Windows 10/11, macOS 12+ หรือ Linux ดิสโทรที่ทันสมัย
• เบราว์เซอร์เวอร์ชันล่าสุด (อัปเดตในปี 2026) อัปเดตเบราว์เซอร์ก่อนเริ่ม
• การเชื่อมต่ออินเทอร์เน็ตที่เสถียร

สิ่งที่ต้องดาวน์โหลดและติดตั้ง

• เบราว์เซอร์ที่คุณวางแผนใช้งาน
• ส่วนขยายในการจำกัด WebRTC สำหรับเบราว์เซอร์ที่ใช้จ่ายโครเมียม (เช่น WebRTC Control หรือ WebRTC Leak Prevent) นอกจากนี้ให้ติดตั้ง uBlock Origin และเปิดใช้งานฟังก์ชันการป้องกันการรั่วไหลของ WebRTC หากมีในการตั้งค่า
• เบราว์เซอร์การป้องกัน (ถ้าจำเป็น) หากคุณทำงานกับโปรไฟล์ ตัวอย่างเช่น: AdsPower, Dolphin{anty}, Incogniton, GoLogin, Octo Browser และอื่นๆ

การสำรองข้อมูล

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

⚠️ หมายเหตุ: ก่อนเปลี่ยนการตั้งค่าที่ซ่อนอยู่ในเบราว์เซอร์ (เช่น about:config ใน Firefox หรือ flags ในเบราว์เซอร์ที่ใช้โครเมียม) ให้เขียนค่าปัจจุบันลงไป สิ่งนี้จะช่วยให้คุณสามารถกู้คืนได้ หากเว็บไซต์ใดเว็บไซต์หนึ่งไม่ทำงานตามที่คาดหวัง

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

แนวคิดพื้นฐาน

คำศัพท์สำคัญในภาษาง่าย

• WebRTC — เทคโนโลยีในเบราว์เซอร์สำหรับการแลกเปลี่ยนเสียง, วิดีโอ และข้อมูลเรียลไทม์ WebRTC แลกเปลี่ยน "ผู้สมัคร" เส้นทางเครือข่าย (ICE) รวมถึงผ่าน STUN/TURN
• ICE-candidates — เส้นทางที่เป็นไปได้สำหรับการเชื่อมโยงระหว่างสองฝ่าย อาจมีทั้ง IP สาธารณะและ IP ภายใน
• STUN/TURN — เซิร์ฟเวอร์เสริมที่ช่วยระบุ IP สาธารณะของคุณ, กำหนดเส้นทาง และ建立การเชื่อมต่อแม้ในเครือข่าย NAT และไฟร์วอลล์
• mDNS — วิธีการซ่อน IP ภายในของคุณเมื่อสร้าง ICE-candidates โดยการเปลี่ยนที่อยู่ภายในให้เป็นหมายเลขออกแบบ mDNS ชั่วคราว
• พร็อกซี — เซิร์ฟเวอร์กลางที่ใช้ในการรับส่งข้อมูล HTTP(S) หรือ SOCKS5 ของคุณ พร็อกซีซ่อน IP จริงของคุณจากเว็บไซต์ที่คุณเข้าเยี่ยมชม

ทำไมถึงเกิดการรั่วไหลของ WebRTC

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

สิ่งที่สำคัญต้องเข้าใจก่อนเริ่ม

• การปิดใช้งาน WebRTC ทั้งหมดอาจทำให้การโทรเสียงและวิดีโอ, การแชร์หน้าจอ และฟังก์ชันอื่นๆ ขัดข้อง
• เป้าหมายของคู่มือนี้คือไม่ใช่การ "ทำให้ WebRTC เสีย" แต่เพื่อให้ IP จริงของคุณไม่ถูกเปิดเผย โดยที่เราจะเลือกวิธีการที่ "อ่อนโยน" ตามที่เป็นไปได้: mDNS, การจำกัดเส้นทางสาธารณะ, และกฎเกี่ยวกับ ICE-candidates
• เบราว์เซอร์ต่างๆ ให้ระดับการควบคุมที่แตกต่างกัน Firefox อนุญาตให้ปรับแต่งได้ละเอียดยิ่งขึ้นผ่าน about:config ในเบราว์เซอร์ที่ใช้โครเมียมจะใช้ส่วนขยายหรือนโยบายที่มีประสิทธิภาพมากกว่า

เคล็ดลับ: หากฟังก์ชัน WebRTC (การโทร, การส่งไฟล์ในเบราว์เซอร์) ไม่เป็นที่ต้องการในงานของคุณ, ควรพิจารณาการปิดใช้งานอย่างเข้มงวดในโปรไฟล์ที่ใช้กันเพื่อความเป็นส่วนตัวอย่างน้อย

ขั้นตอนที่ 1: กำหนดกรอบของพร็อกซีและสภาพแวดล้อม

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

ขั้นตอนโดยละเอียด

1. เปิดเบราว์เซอร์ที่คุณใช้งานผ่านพร็อกซี
2. ตรวจสอบการกำหนดค่าพร็อกซีที่ใช้งานอยู่ สำหรับเบราว์เซอร์ที่ใช้โครเมียม ให้เปิดการตั้งค่า: การตั้งค่า — ระบบ — เปิดการตั้งค่าพร็อกซี ให้แน่ใจว่ามีการระบุเซิร์ฟเวอร์พร็อกซี, ชื่อผู้ใช้ และรหัสผ่าน (หากจำเป็น)
3. หากคุณใช้โปรไฟล์ในเบราว์เซอร์การป้องกัน ให้เปิดการตั้งค่าโปรไฟล์และตรวจสอบว่าระบุพร็อกซีอยู่ที่นั่น: ประเภท (HTTP, HTTPS หรือ SOCKS5), โฮสต์, พอร์ต, ชื่อผู้ใช้ และรหัสผ่านเมื่อต้องการ
4. บันทึก IP ภายนอกปัจจุบันที่เว็บไซต์มองเห็นผ่านพร็อกซีของคุณ ให้พิมพ์ในแถวค้นหา "my ip" และเปิดบริการใดบริการหนึ่งที่แสดง IP ภายนอก บันทึก IP นี้ในชื่อ "IP ผ่านพร็อกซี"
5. หากคุณใช้พร็อกซีมือถือ ให้บันทึกแผงควบคุมของผู้ให้บริการ ตัวอย่างเช่นใน mobileproxy.space ตรวจสอบที่อยู่ IP, ภูมิภาค, วิธีการอนุญาต (โดยชื่อผู้ใช้/รหัสผ่านหรือจากรายการ IP ที่ได้รับอนุญาต) และสถานะการหมุนของ IP

ประเด็นสำคัญ

• พร็อกซี ≠ WebRTC พร็อกซีจะจัดการข้อมูล HTTP(S)/SOCKS แต่ WebRTC สามารถให้ IP ในกระบวนการแลกเปลี่ยน ICE
• เราจำเป็นต้องตรวจสอบว่า WebRTC-candidates ใดๆ ไม่ได้เปิดเผย IP สาธารณะและ IP ภายในจริงของคุณ

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

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

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

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

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

ขั้นตอนที่ 2: ตรวจสอบการรั่วไหลของ WebRTC ในเบราว์เซอร์เดสก์ท็อป

เป้าหมายของขั้นตอน: ยืนยันการมีหรือไม่มีการรั่วไหลก่อนเริ่มทำการตั้งค่า

ขั้นตอนโดยละเอียด

1. เปิดหน้าต่างเบราว์เซอร์ในโหมดปกติ หากในเบราว์เซอร์มีการเปิดส่วนขยายให้ปิดชั่วคราวเพื่อทำการทดสอบที่บริสุทธิ์
2. เปิดบริการใด ๆ ที่แสดงผลลัพธ์ของตัวตรวจสอบ WebRTC ในเบราว์เซอร์ ทดสอบการทำงาน ตรวจสอบที่อยู่สองประเภท: ผู้สมัคร IP สาธารณะ และผู้สมัคร IP ภายใน (เช่น ที่อยู่รูปแบบ 192.168.x.x, 10.x.x.x หรือ 172.16–31.x.x)
3. เปรียบเทียบ IP สาธารณะที่แสดงโดยตัวตรวจสอบ WebRTC กับ "IP ผ่านพร็อกซี" ที่คุณบันทึกไว้ก่อนหน้านี้ หากแตกต่างกันและ WebRTC แสดง IP ของผู้ให้บริการจริงของคุณ — นี่คือการรั่วไหล
4. หากเห็นผู้สมัคร IP ภายในอย่างชัดเจน นี่ก็เป็นอีกการรั่วไหลของการกำหนดค่า เนื่องจากเว็บไซต์สามารถใช้ข้อมูลเหล่านี้ในการทำความสัมพันธ์ทางฟิงเกอร์พริ้นต์และการสร้างอัตลักษณ์
5. บันทึกภาพหน้าจอหรือเขียนผลลัพธ์ IP สาธารณะและ IP ภายในที่แสดงโดยการทดสอบ จากนั้นคุณจะเปรียบเทียบกับผลลัพธ์หลังการตั้งค่า

ประเด็นสำคัญ

• ทดสอบแต่ละเบราว์เซอร์แยกกัน อย่าสรุปผลจากเบราว์เซอร์หนึ่งสำหรับทั้งหมด
• ผลลัพธ์ขึ้นอยู่กับเวอร์ชันและฟีเจอร์ที่เปิดใช้งานอยู่ โดยเฉพาะใน Safari และ Firefox

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

✅ การตรวจสอบ: คุณมีผลลัพธ์ที่บันทึกไว้ก่อนการตั้งค่า ว่าผลิตภัณฑ์ IP สาธารณะและ IP ภายในที่ WebRTC แสดงตอนนี้เป็นยังไง นี่คือจุดเริ่มต้น

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

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

ขั้นตอนที่ 3: ปิดการรั่วไหลของ WebRTC ในเบราว์เซอร์ตามปกติ

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

เบราว์เซอร์ Chromium (Chrome, Edge, Opera, Brave และอื่นๆ)

1. เปิดการตั้งค่าในเบราว์เซอร์ ไปที่ส่วน "ความเป็นส่วนตัวและความปลอดภัย" — "การตั้งค่าไซต์" — "การอนุญาตเพิ่มเติม" (ชื่ออาจแตกต่างกัน) ค้นหาส่วนที่เกี่ยวข้องกับกล้องและไมโครโฟน แม้ว่าจะไม่ปิด WebRTC แต่การห้ามการเข้าถึงสื่อจะลดจำนวนกรณีที่แท้จริงที่การแลกเปลี่ยน ICE เริ่มต้นขึ้นเมื่อมีการโทร
2. เปิดหน้าธง (chrome://flags หรือ edge://flags, opera://flags) ค้นหาพารามิเตอร์ที่รับผิดชอบในการทำให้ IP ภายในใน WebRTC เป็นนิรนาม (เช่น "Anonymize local IPs exposed by WebRTC" หรือ "mDNS ICE candidates") เปลี่ยนเป็น Enabled และรีสตาร์ทเบราว์เซอร์
3. ตรวจสอบนโยบายขององค์กร (ถ้ามี) ในสภาพแวดล้อมที่มีนโยบายสามารถกำหนด WebRtcIpHandlingPolicy ให้เป็น "default_public_interface_only" หรือ "disable_non_proxied_udp" เพื่อห้ามการเชื่อมต่อ UDP ที่ไม่ผ่านพร็อกซีของตรงโดยไม่มีการเชื่อมต่อที่ไม่มีพร็อกซี สำหรับผู้ใช้ทั่วไป เส้นทางนี้ไม่จำเป็นต้องทำ

Firefox (Desktop)

1. ในแถบที่อยู่ ให้พิมพ์ about:config และยืนยันว่าคุณเข้าใจความเสี่ยง
2. ค้นหาพารามิเตอร์ media.peerconnection.enabled และหากคุณไม่ต้องการมีการโทรผ่านเบราว์เซอร์ ให้ตั้งค่าเป็น false เพื่อปิด WebRTC โดยสมบูรณ์ หากต้องการใช้งานการโทร ให้ไม่ปิดการใช้งานแบบทั่วๆ ไปและใช้พารามิเตอร์ถัดไป
3. ตั้งค่า media.peerconnection.ice.no_host เป็น true เพื่อไม่ให้เปิดเผยที่อยู่ IP ภายในในฐานะ ICE-candidates
4. ตั้งค่า media.peerconnection.ice.default_address_only เป็น true เพื่อจำกัดผู้สมัครเฉพาะที่อยู่ตามค่าเริ่มต้นเท่านั้น ไม่ใช่จากอินเทอร์เฟซทั้งหมด
5. ตั้งค่า media.peerconnection.ice.obfuscate_host_addresses เป็น true เพื่อเปิดใช้งานการซ่อนที่อยู่ภายในด้วย mDNS
6. รีสตาร์ท Firefox

Safari (macOS, iOS/iPadOS)

1. ใน macOS ให้เปิดเมนู "การพัฒนา" (Safari — การตั้งค่า — ขั้นสูง — แสดงเมนู "การพัฒนา" ในแถบเมนู)
2. เปิด "การพัฒนา" — "ฟังก์ชันการทดลอง" และตรวจสอบพารามิเตอร์ที่เกี่ยวข้องกับ mDNS ICE-candidates เปิดใช้งาน mDNS ICE-candidates เพื่อไม่ให้ IP ภายในถูกเปิดเผยโดยตรง
3. ในการตั้งค่าไซต์ ให้จำกัดการเข้าถึงกล้องและไมโครโฟนสำหรับเว็บไซต์ที่ไม่จำเป็น เพื่อไม่ให้ WebRTC ถูกเรียกใช้งานโดยไม่จำเป็น
4. ใน iOS/iPadOS ใน "การตั้งค่า — Safari — ส่วนขยาย/ฟังก์ชันการทดลอง" ให้เปิดใช้งานฟังก์ชันที่คล้ายกับ mDNS ICE-candidates หากมีให้ และจำกัดการเข้าถึงกล้อง/ไมโครโฟนสำหรับเว็บไซต์

⚠️ หมายเหตุ: การปิดการใช้งาน WebRTC อย่างสมบูรณ์อาจทำให้การโทรเวบ, การแชร์หน้าจอ และบางฟังก์ชั่นในองค์กรเสียหาย หากต้องการฟังก์ชั่นการโทร โปรดใช้โหมดที่มี mDNS และการจำกัดผู้สมัครต่อไปแทนการปิดใช้งานอย่างสมบูรณ์

เคล็ดลับ: หากคุณเปลี่ยนเครือข่ายและอินเทอร์เฟซบ่อย (เช่น Ethernet และ Wi-Fi) ให้ตรวจสอบธงและ about:config ใหม่หลังจากอัปเดตเบราว์เซอร์ อาจมีการรีเซ็ตฟังก์ชันทดลองหลังจากอัปเดต

✅ การตรวจสอบ: เริ่มการทดสอบจากขั้นตอนก่อนหน้า ที่อยู่ IP ภายในไม่ควรปรากฏอย่างชัดเจน, ผู้สมัครสาธารณะไม่ควรตรงกับ IP ที่แท้จริงของผู้ให้บริการ หากการทดสอบยังแสดง IP จริง ให้ไปที่ขั้นตอนส่วนขยาย

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

• ปัญหา: ในธง Chromium ไม่มีตัวเลือกในการทำให้ IP ภายในเป็นนิรนาม สาเหตุ: เวอร์ชันของเบราว์เซอร์หรือนโยบาย วิธีการแก้ไข: ใช้ส่วนขยายสำหรับ WebRTC และ uBlock Origin หรือนำใช้เชิงนโยบายในระดับระบบ (เหมาะสำหรับผู้ดูแลระบบ)
• ปัญหา: Firefox หลังจากปิด WebRTC ทำให้การโทรล้มเหลว สาเหตุ: คุณได้ปิด media.peerconnection.enabled วิธีการแก้ไข: เปิดใช้งานใหม่และใช้พารามิเตอร์จุดบน ดังกล่าว no_host, default_address_only และ obfuscate_host_addresses

ขั้นตอนที่ 4: ปิดการใช้งาน WebRTC ด้วยส่วนขยาย

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

ขั้นตอนโดยละเอียด

1. เปิดไดเรกทอรีส่วนขยายในเบราว์เซอร์ของคุณ ค้นหาและติดตั้งส่วนขยายที่จัดการนโยบาย WebRTC (เช่น WebRTC Control หรือ WebRTC Leak Prevent) ส่วนขยายเหล่านี้ช่วยในการกำหนดกลยุทธ์: "Default public interface only", "Disable non-proxied UDP" เป็นต้น
2. หลังจากติดตั้งแล้ว ให้เปิดการตั้งค่าของส่วนขยาย เลือกนโยบายที่ซ่อนผู้สมัครภายในและห้าม UDP ที่ไม่ผ่านพร็อกซี ในอินเทอร์เฟซอาจมีการเรียกว่า "Disable non-proxied UDP" หรือ "Use default public interface only" บันทึกการตั้งค่า
3. ให้ติดตั้ง uBlock Origin ด้วย เปิดการตั้งค่าของมันและในส่วน "การตั้งค่า" เปิดใช้งานตัวเลือกที่ป้องกันการรั่วไหลของ WebRTC (หากมีในรุ่นของคุณ) นี่คือการประกันที่เพิ่มเติมเข้ามา
4. รีสตาร์ทเบราว์เซอร์หรือปิด-เปิดส่วนขยายเพื่อให้แน่ใจว่านโยบายถูกนำไปใช้

ประเด็นสำคัญ

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

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

เคล็ดลับ: หากคุณสลับระหว่างนโยบายหลายตัว (เช่น สำหรับการโทรและการทำงานทั่วไป) ให้สร้างสองโปรไฟล์ในเบราว์เซอร์: "ทำงาน (WebRTC ที่เข้มงวด)" และ "การโทร (WebRTC ปานกลาง)"

✅ การตรวจสอบ: ทำการทดสอบ WebRTC ใหม่อีกครั้ง IP สาธารณะไม่ควรตรงกับ IP จริงของผู้ให้บริการของคุณ, IP ภายในต้องไม่ปรากฏอย่างชัดเจน หากผลลัพธ์คือเชิงลบ — การรั่วไหลของข้อมูลได้ถูกปิด

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

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

ขั้นตอนที่ 5: ตั้งค่า WebRTC ในเบราว์เซอร์การป้องกัน

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

ขั้นตอนโดยละเอียด (แผนผังทั่วไป)

1. เปิดแผงควบคุมของเบราว์เซอร์การป้องกันของคุณ (เช่น AdsPower, Dolphin{anty}, Incogniton, GoLogin, Octo Browser และอื่นๆ)
2. สร้างโปรไฟล์ใหม่หรือเปิดโปรไฟล์ที่มีอยู่ ค้นหาส่วน "WebRTC" หรือ "การตั้งค่าเครือข่าย/สื่อ/ฟิงเกอร์พริ้นต์" ภายในโปรไฟล์
3. เลือกกลยุทธ์ WebRTC: โดยทั่วไปจะมีตัวเลือก "Disabled", "Real", "Altered/Fake", "Default public interface only", "Proxy only" หรือที่คล้ายกัน หากคุณไม่ต้องการการโทรและต้องการความเป็นส่วนตัวสูงสุด ให้เลือก "Disabled" หรือทางเลือกที่ไม่รวมผู้สมัครภายในและห้าม UDP ไม่ผ่านพร็อกซี หากการโทรเป็นสิ่งที่ต้องการให้เลือก "Proxy only" หรือ "public interface only" บวกด้วย mDNS หากสนับสนุนในชุดเบราว์เซอร์ที่เป็นป้องกัน
4. ระบุพร็อกซีในโปรไฟล์: ประเภท (HTTP(S) หรือ SOCKS5), โฮสต์, พอร์ต, ชื่อผู้ใช้/รหัสผ่าน ตรวจสอบการเชื่อมต่อผ่านปุ่ม "ทดสอบ" ที่มีอยู่ในโปรไฟล์
5. บันทึกโปรไฟล์และเริ่มใช้งาน เปิดตัวทดสอบ WebRTC และตรวจสอบให้แน่ใจว่า IP จริงไม่ปรากฏ บันทึกผลลัพธ์

ประเด็นสำคัญ

• ในเบราว์เซอร์ป้องกันมักมีกลยุทธ์ WebRTC ที่เลียนแบบการตั้งค่าปรับใกล้เคียง: การสร้าง ufrag, รหัส ICE, ฟิลด์ SDP พยายามอย่าเปลี่ยนแปลงค่าโดยไม่จำเป็น เป้าหมายของคุณคือการปิดการรั่วไหล ไม่ใช่การเบี่ยงเบนประเภทแปลก ๆ
• นโยบาย WebRTC ที่เหมือนกันในโปรไฟล์ที่ต่างกันจะให้พฤติกรรมที่เหมือนกันบนเว็บไซต์

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

✅ การตรวจสอบ: ในแต่ละโปรไฟล์ที่เปิดใช้งาน ทำการทดสอบซ้ำ IP สาธารณะจริงต้องไม่ปรากฏ, ผู้สมัคร IP ภายในควรถูกซ่อนหรือแทนที่ด้วย mDNS

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

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

ขั้นตอนที่ 6: การเชื่อมต่อกับพร็อกซีมือถือ

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

ขั้นตอนโดยละเอียด

1. เตรียมการเข้าถึงพร็อกซีมือถือ ในแดชบอร์ดของผู้ให้บริการ (เช่น mobileproxy.space) ตรวจสอบการตั้งค่าการเชื่อมต่อ: ที่อยู่โหนด, พอร์ต, ประเภทพร็อกซี, การตรวจสอบสิทธิ์ (ชื่อผู้ใช้/รหัสผ่านหรือลิสต์ IP ที่ได้รับอนุญาต)
2. หากผู้ให้บริการสนับสนุนการหมุน IP ให้กำหนดว่าเมื่อไหร่และอย่างไรการหมุนจะเกิดขึ้น ให้แน่ใจว่าคุณสามารถทำการทดสอบให้เสร็จสิ้นได้หลังจากการหมุน
3. ในเบราว์เซอร์หรือโปรไฟล์การป้องกัน ให้ระบุพร็อกซีมือถือ: ประเภท (HTTP(S)/SOCKS5), โฮสต์, พอร์ต, ชื่อผู้ใช้/รหัสผ่าน ดำเนินการทดสอบการเชื่อมต่อ (มักมีปุ่ม "ตรวจสอบพร็อกซี" หรือเปิดเว็บไซต์ใดเว็บไซต์หนึ่งเพื่อให้แน่ใจว่าหน้าโหลดได้)
4. ตรวจสอบว่านโยบาย WebRTC ได้ถูกตั้งค่ายัง: ในเบราว์เซอร์ที่ใช้โครเมียม — ผ่านส่วนขยายและธงเคล็ดลับในการทำให้ IP ที่ภายในเป็นนิรนาม, ใน Firefox — ผ่าน about:config, ในป้องกัน — ผ่านโปรไฟล์
5. เปิดตัวทดสอบ WebRTC ตรวจสอบว่า IP สาธารณะที่แสดงเป็นผู้สมัครต้องตรงกับ IP ของพร็อกซีมือถือ ไม่ใช่ IP จริงของผู้ให้บริการ ที่อยู่ IP ภายในต้องถูกซ่อนหรือแสดงผ่าน mDNS

ประเด็นสำคัญ

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

เคล็ดลับ: หากความสำคัญคือการระบุภูมิศาสตร์ ให้บังคับการตั้งค่าทางภูมิศาสตร์ที่ชายฝั่งของพร็อกซีมือถือ (เช่น mobileproxy.space) และไม่ให้สลับเครือข่าย Wi-Fi และเครือข่ายมือถือพร้อมกัน

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

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

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

ขั้นตอนที่ 7: เทคนิคการควบคุมระดับเบราว์เซอร์และระบบเพิ่มเติม

เป้าหมายของขั้นตอน: เสริมความคาดเดาได้ของพฤติกรรมโดยไม่ทำให้ความถูกต้องตามกฎหมายและความสะดวกในการทำงานเสียหาย

ขั้นตอนโดยละเอียด

1. ตรวจสอบสิทธิ์การเข้าถึงไซต์: การตั้งค่า — ความเป็นส่วนตัวและความปลอดภัย — การตั้งค่าไซต์ — การอนุญาต ให้จำกัดการเข้าถึงกล้องและไมโครโฟนอัตโนมัติ; ควรมีการขอระหว่างการใช้งาน
2. สร้างโปรไฟล์แยกสำหรับงานที่ต้องการความเป็นส่วนตัวสูง ในโปรไฟล์นี้ให้ใช้กลยุทธ์ WebRTC ที่เข้มงวดและส่วนขยายขั้นต่ำ
3. หากคุณเป็นผู้ดูแลระบบ ให้บังคับใช้การตั้งค่าเบราว์เซอร์ในทางจำกัดเพื่อกำหนดนโยบาย WebRTC แบบรวมศูนย์ ผู้ใช้ที่ไม่มีสิทธิ์เป็นผู้ดูแลนั้นไม่จำเป็นต้องทำขั้นตอนนี้
4. ตรวจสอบหลังจากการอัปเดต: บางครั้งเบราว์เซอร์จะเปลี่ยนพฤติกรรมเริ่มต้นของ mDNS หรือ WebRTC-flags อัปเดตไปเดือนละครั้งเพื่อตรวจสอบ

ประเด็นสำคัญ

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

เคล็ดลับ: สร้างกิจวัตร: "โปรไฟล์ใหม่ — ทดสอบ WebRTC ทันที", "อัปเดตเบราว์เซอร์ — ทดสอบ WebRTC ทันที", "เปลี่ยนพร็อกซีหรือผู้ให้บริการ — ทดสอบ WebRTC ทันที" สิ่งนี้ใช้เวลา 1–2 นาที แต่ประหยัดเวลาไปหลายชั่วโมง

✅ การตรวจสอบ: คุณได้ยืนยันว่ากิจวัตรและนโยบายการจัดการใหม่ทำงานอยู่: การทดสอบไม่แสดง IP จริงในโปรไฟล์ใด ๆ และหลังการอัปเดต

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

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

ขั้นตอนที่ 8: การวินิจฉัยด้วยการทดสอบหลายครั้ง

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

ขั้นตอนโดยละเอียด

1. ทำการทดสอบ WebRTC ใหม่ในสองถึงสามเว็บไซต์ที่แตกต่างกัน เปรียบเทียบเพื่อให้แน่ใจว่าไม่มี IP จริงจากผู้ให้บริการถูกเปิดเผย และไม่มี IP ภายในที่ปรากฏอย่างชัดเจน
2. ทำการทดสอบเครือข่ายพื้นฐานครั้งเดียวในระดับ DNS เปิด cmd โดยในการใช้งานของ Windows ใช้คำสั่ง: nslookup -type=txt o-o.myaddr.l.google.com 8.8.8.8 ใน macOS/Linux ใช้คำสั่ง: dig +short TXT o-o.myaddr.l.google.com @8.8.8.8 ตรวจสอบให้แน่ใจที่อยู่ที่ได้รับตรงตามเส้นทางที่ผ่านระบบพร็อกซี หากคุณมีการกำหนดพร็อกซีกำหนดไว้ในระดับระบบ หรือหากเพียงใช้ในระดับเบราว์เซอร์ การทดสอบนี้อาจแสดง IP จริงของคุณก็เป็นได้ซึ่งถือว่าเป็นเรื่องปกติในระดับระบบ
3. ทดสอบการเข้าถึงกล้องและไมโครโฟนในเว็บไซต์ที่ต้องการจริงๆ ตรวจสอบให้แน่ใจว่าการโทรสามารถทำได้ หากคุณเลือกกลยุทธ์ WebRTC ที่ "ปานกลาง" ไว้อย่างมีเจตนา

ประเด็นสำคัญ

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

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

✅ การตรวจสอบ: การทดสอบทั้งหมดในระดับเบราว์เซอร์ให้ผลลัพธ์ที่สอดคล้องกัน: IP จริงไม่มีการเปิดเผย, IP ภายในก็ไม่ถูกเปิดเผยอย่างชัดเจน

ปัญหาและวิธีการแก้ไขที่เป็นไปได้

• ปัญหา: ตัวทำให้ WebRTC แสดงผลแตกต่างกันในแต่ละตัวทดสอบ สาเหตุ: ความลึกของข้อมูลที่ใช้ในการประมวลผลแตกต่างกัน วิธีการแก้ไข: มุ่งเน้นไปที่ปัจจัยที่สำคัญ — การปรากฏตัวของ IP สาธารณะจริงหรือ IP ภายใน; อย่ากลัววัดค่าที่ไม่สำคัญ
• ปัญหา: มีการรั่วไหลบ้างในบางครั้ง สาเหตุ: การขยายไม่สามารถเปิดอยู่หรือไม่ได้นำการตั้งค่ามาใช้ไว้ วิธีการแก้ไข: รีสตาร์ทเบราว์เซอร์, ตรวจสอบอนุญาตของส่วนขยาย, ทำการทดสอบซ้ำ

การตรวจสอบผลลัพธ์

เช็คลิสต์ที่ควรทำงาน

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

วิธีทดสอบ

1. เริ่มการกำหนดค่าสุดท้าย: เบราว์เซอร์/โปรไฟล์ที่เปิดพร็อกซีและนโยบาย WebRTC
2. เปิดตัวทดสอบ WebRTC และบันทึกผลลัพธ์
3. หากคุณใช้พร็อกซีมือถือ ให้ทำการหมุน IP และทำการทดสอบใหม่
4. เปรียบเทียบกับบันทึกเดิม ให้มั่นใจว่า IP จริงไม่มีการปรากฏในกรณีใดๆ

การทดสอบการรั่วไหล DNS

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

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

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

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

• ปัญหา: หลังจากทุกขั้นตอน IP จริงยังคงปรากฏในเว็บไซต์ต่าง ๆ สาเหตุ: ส่วนขยายไม่มีสิทธิ์ในการทำงานในโหมดส่วนตัวหรือนโยบายไม่ถูกนำไปใช้ วิธีการแก้ไข: เปิดส่วนขยายสำหรับหน้าต่างส่วนตัว, รีสตาร์ทเบราว์เซอร์, ตรวจสอบธงและ about:config, ทำการทดสอบซ้ำ
• ปัญหา: การโทรในเบราว์เซอร์เสีย สาเหตุ: WebRTC ปิดการใช้งานไปโดยสิ้นเชิง วิธีการแก้ไข: เปิด WebRTC ขึ้นมาอีกครั้ง แต่ซ่อนที่อยู่ IP ภายในและใช้ mDNS; ห้าม UDP ที่ไม่ผ่านพร็อกซีเท่านั้น
• ปัญหา: โปรไฟล์การป้องกันให้ผลลัพธ์ที่แตกต่างกัน สาเหตุ: โหมด WebRTC ที่แตกต่างกันหรือตั้งค่าภายในที่แตกต่างกัน วิธีการแก้ไข: สร้างแม่แบบโปรไฟล์ให้ซิงค์โหมด WebRTC และบันทึกรายการส่วนขยาย
• ปัญหา: หลังจากการอัปเดตเบราว์เซอร์การรั่วไหลกลับมา สาเหตุ: การรีเซ็ตธง/การตั้งค่าส่วนขยาย วิธีการแก้ไข: ทำการตรวจสอบการตั้งค่าอย่างรวดเร็ว, นำเข้าการกำหนดค่าที่บันทึก และตรวจสอบด้วยการทดสอบ
• ปัญหา: บนเว็บไซต์บางแห่งไม่มีการรั่วไหล ในบางแห่งมีการรั่วไหล สาเหตุ: วิธีการตรวจสอบอาจแตกต่างกัน อาจมีการเรียก STUN โดยตรง วิธีการแก้ไข: ตรวจสอบว่า“ Disable non-proxied UDP” เปิดอยู่, ตรวจสอบ uBlock Origin และอนุญาตให้ใช้ส่วนขยาย
• ปัญหา: พร็อกซีกำลังเปลี่ยน IP และการทดสอบบางครั้งปรากฏค่าตรงกลาง สาเหตุ: ความจำเป็นในการหมุนใช้เวลา ระยะเวลาไม่เพียงพอ วิธีการแก้ไข: รอให้การหมุนเสร็จสิ้น, เคลียร์แคช, รีสตาร์ทหน้า, ทำการทดสอบซ้ำ
• ปัญหา: นโยบายในระดับ OS อาจห้ามด้วยธงที่คุณต้องการ สาเหตุ: นโยบายขององค์กร วิธีการแก้ไข: ติดต่อผู้ดูแลระบบหรือใช้เส้นทางที่สนับสนุนพร้อมกับส่วนขยายที่ไม่มีความขัดแย้ง

ความสามารถเพิ่มเติม

การตั้งค่าขั้นสูง

• นโยบายธุรกิจของ Chromium: ตั้งค่านโยบาย WebRtcIpHandlingPolicy เป็น "default_public_interface_only" หรือ "disable_non_proxied_udp" ให้กับทุก ๆ สถานีงาน
• Firefox about:config: ร่วมกันใช้ mDNS และห้ามใช้ผู้สมัคร host เพื่อปรับมลดสัญลักษณ์การระบุ
• การตรวจสอบแบบป้องกัน: บันทึกเวอร์ชันของแกนและนโยบาย WebRTC ในแม่แบบ เพื่อให้เมื่อตรวจสอบแกนมีการตรวจสอบที่รวดเร็วกับโปรไฟล์ที่เฉลี่ยไว้เพียงอันเดียว

การเพิ่มประสิทธิภาพ

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

สิ่งที่สามารถทำได้เพิ่มเติม

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

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

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

1. ทำไมไม่ว่าพร็อกซี WebRTC ยังคงสามารถแสดง IP จริงของฉันได้

เพราะ WebRTC ใช้ผู้สมัคร ICE และ STUN ที่สามารถทำงานข้ามเส้นทาง HTTP(S) รวมถึง UDP ที่ไม่ผ่านพร็อกซื โดยไม่มีมาตรการพิเศษใด ๆ เบราว์เซอร์อาจเผย IP สาธารณะของผู้ให้บริการให้เห็นได้

2. ถ้ามีการปิด WebRTC จะเพียงพอไหม

การทำเช่นนั้นจะทำให้ผลลัพธ์ปรากฏชัด แต่จะทำให้การโทรและแอพบางตัวล้มเหลว การใช้โหมดที่มี mDNS, การจำกัดข้อความภายใน และการห้ามที่ไม่ได้ผ่านพร็อกซีจะดีกว่า หากคุณต้องการฟังก์ชัน WebRTC

3. จำเป็นต้องใช้ทั้งส่วนขยายและการปรับแต่งธงหรือไม่

บ่อยครั้งที่ส่วนขยายเพียงพอ แต่การเปิดใช้งาน mDNS ในระดับธงพลัสกับส่วนขยายจะให้ผลลัพธ์ที่คาดการณ์ได้ดีกว่า โดยเฉพาะอย่างยิ่งหลังจากการอัปเดต

4. ในเบราว์เซอร์การป้องกันควรเลือกโหมดไหน

ถ้าไม่ต้องการการโทรให้เลือก "Disabled" หรือ "Proxy only" ที่ไม่อนุญาต UDP ที่ไม่ได้ผ่านพร็อกซี หากต้องการการโทรเลือก "public interface only" พลัส mDNS และควบคุมสิทธิ์สื่อ

5. จะเข้าใจได้อย่างไรว่าที่อยู่ IP ภายในไม่ถูกเห็น

ในแถวผู้สมัคร ICE ไม่ควรมีรูปแบบที่คุ้นเคย 192.168.x.x, 10.x.x.x, 172.16–31.x.x ควรมีให้เห็นเพียง mDNS และหมายเลขระยะเวลา

6. ฉันมีพร็อกซีมือถือแต่ทดสอบยังแสดง IP จริงอยู่

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

7. สิ่งที่ผู้ให้บริการพร็อกซีมือถืออย่าง mobileproxy.space ให้ได้

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

8. การทำการทดสอบการรั่วไหล DNS จำเป็นต้องทำหรือไม่

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

9. ควรทำอย่างไรหากทุกอย่างเสียหลังจากการอัปเดตเบราว์เซอร์

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

10. จะป้องกันการรั่วไหลแน่แท้ได้หรือไม่

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

บทสรุป

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

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

ลงลึกต่อไป: เรียนรู้เกี่ยวกับการป้องกันการรั่วไหลอื่น ๆ (Canvas, AudioContext, WebGL), ตรวจสอบนโยบายค่าใช้จ่ายในการแยกไซต์, กลยุทธ์วิธีการคุกกี้ และการจัดการฟิงเกอร์พริ้นต์ แต่พื้นฐานการปรับปรุงช่องทางในที่ที่ไม่มีการรั่วไหลของ IP จริงผ่าน WebRTC คุณได้ตั้งค่าไว้และทดสอบแล้ว