L'adreça zero d'UDP ASSOCIATE a Indy no és la destinació del datagrama
Separeu l'adreça d'associació del client, el relé SOCKS retornat i la destinació codificada a cada paquet UDP.
0.0.0.0:0 en una sol·licitud UDP ASSOCIATE d'Indy pot ser intencionat. Aquesta sol·licitud descriu l'extrem UDP esperat del costat client, i la RFC 1928 permet zeros quan és desconegut. No selecciona el servei final.
El BND.ADDR/BND.PORT de la resposta identifica el relé al qual el client envia els datagrames encapsulats.
TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target serviceA Indy, TIdUDPClient.Connect crida OpenUDP del proxy transparent. TIdSocksInfo proporciona els camps d'associació a zero. Més tard, SendBuffer passa el servei desitjat a SendToUDP, que construeix la capçalera de destinació SOCKS UDP abans de les dades de l'aplicació.
Si l'associació té èxit però el trànsit falla, inspeccioneu el relé retornat, la destinació codificada i el camí de resposta UDP. NAT/tallafocs poden admetre l'intercanvi TCP mentre bloquegen UDP.
Mantingueu oberta la connexió de control TCP; tancar-la acaba l'associació. SOCKS4/4a no tenen aquesta operació, i l'etiqueta SOCKS5 per si sola no garanteix que un servidor admeti UDP.