כתובת האפס של UDP ASSOCIATE ב-Indy אינה יעד ה-datagram

0.0.0.0:0 בבקשת UDP ASSOCIATE של Indy יכול להיות מכוון. הבקשה מתארת את נקודת הקצה הצפויה של UDP בצד הלקוח, ו-RFC 1928 מתיר אפסים כשהיא אינה ידועה. היא אינה בוחרת את השירות הסופי.

BND.ADDR/BND.PORT בתשובה מזהים את הממסר שאליו הלקוח שולח datagrams עטופים.

TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target service

ב-Indy, TIdUDPClient.Connect קורא ל-OpenUDP של הפרוקסי השקוף. TIdSocksInfo מספק את שדות השיוך האפסיים. מאוחר יותר, SendBuffer מעביר את השירות הרצוי אל SendToUDP, אשר בונה את כותרת יעד ה-SOCKS UDP לפני נתוני היישום.

אם השיוך מצליח אך התעבורה נכשלת, בדקו את הממסר המוחזר, היעד המקודד ונתיב תגובת ה-UDP. NAT/חומות אש יכולות לאפשר את חילופי ה-TCP ובמקביל לחסום UDP.

השאירו את חיבור הבקרה של TCP פתוח; סגירתו מסיימת את השיוך. ל-SOCKS4/4a אין פעולה זו, והשם SOCKS5 לבדו אינו מבטיח ששרת תומך ב-UDP.