พร็อกซี SOCKS อาจโหลดข้อความได้แต่ล้มเหลวในการโทร
การใช้คู่มือ Dante และข้อกำหนด UDP ของ SOCKS5 อธิบายว่าเหตุใดเส้นทาง TCP ที่ใช้งานได้จึงไม่ได้พิสูจน์การรองรับทราฟฟิกการโทรของแอปพลิเคชัน
ข้อความตัวอักษรมาถึงผ่านพร็อกซี SOCKS แต่การโทรด้วยเสียงไม่เคยเชื่อมต่อ พร็อกซีอาจไม่ได้เสียหายทั้งหมด แอปพลิเคชันอาจใช้การขนส่งอื่นสำหรับการโทร
คำขอ TCP ที่สำเร็จพิสูจน์เส้นทาง TCP สำหรับการดำเนินการนั้น SOCKS5 ยังกำหนดการเชื่อมโยง UDPด้วย แต่ไคลเอนต์ บริการ SOCKS กฎเครือข่าย และการตั้งค่าแอปพลิเคชันทั้งหมดต้องรองรับเส้นทาง UDP ที่ต้องการ
มีมากกว่าตัวรับฟัง TCP
คู่มือ Dante แยกกฎโปรโตคอลและกฎคำสั่ง รวมถึง connect, udpassociate และ udpreply กฎที่อนุญาตเฉพาะการเชื่อมต่อ TCP ที่คุณทดสอบแล้วไม่ได้สร้างสิทธิ์ UDP ที่จำเป็น
การเชื่อมโยง UDP ยังเกี่ยวข้องกับจุดปลายทางการส่งต่อและทราฟฟิกขากลับ ไฟร์วอลล์และการแปลที่อยู่ต้องอนุญาตเส้นทางจริงนั้น การเปิดตัวรับฟัง TCP ของ SOCKS ไม่เท่ากับการทำให้ตัวส่งต่อ UDP ของมันเข้าถึงได้
ตรวจสอบเอกสารและการตั้งค่าพร็อกซีปัจจุบันของแอปพลิเคชัน เวอร์ชันที่ต่างกันอาจจัดการข้อความ สื่อ และการโทรต่างกัน ไม่ควรนำสูตรจากฟอรัมสำหรับไคลเอนต์เก่ามานำเสนอเป็นหลักฐานว่าไคลเอนต์ปัจจุบันทุกตัวส่งการโทรผ่าน SOCKS
หลีกเลี่ยงการเปิดทุกพอร์ต UDP เป็นการวินิจฉัยแรก กำหนดพฤติกรรมการส่งต่อและขอบเขตไคลเอนต์ที่ต้องการ แล้วใช้นโยบายเครือข่ายแบบจำกัดที่เหมาะสม ในทำนองเดียวกัน การปิดการตั้งค่าพร็อกซีสำหรับการโทรอาจทำให้การโทรทำงานได้โดยส่งโดยตรง ซึ่งเปลี่ยนเส้นทางออกแทนที่จะซ่อมแซมเส้นทางที่ผ่านพร็อกซี
บันทึกความสำเร็จแยกตามการดำเนินการ: ข้อความ การถ่ายโอนสื่อ และการโทร คำขอเดียวที่ใช้งานได้หรือ IP ของเบราว์เซอร์ที่เปลี่ยนไปไม่สามารถพิสูจน์ได้ว่าทุกส่วนของแอปพลิเคชันอื่นใช้ทางออกพร็อกซีเดียวกัน