Java DatagramSocket and SOCKS5 UDP Relaying

Your Java HTTP request works through SOCKS, yet a UDP feature still sends traffic directly or fails. Setting the JVM's SOCKS properties does not give DatagramSocket a SOCKS5 UDP implementation.

The DatagramSocket API sends and receives datagrams addressed to network endpoints. Its connect() method chooses a peer for that socket. It does not perform a SOCKS negotiation with the peer.

A SOCKS5 UDP route has extra work

SOCKS5 defines a UDP association established over a TCP control connection. The client then exchanges encapsulated datagrams with the relay address supplied by the proxy. Each encapsulated message identifies its destination. A client implementation needs to handle that framing and the control connection's lifetime.

Pointing an ordinary UDP socket at the proxy's TCP listening port skips those steps. Sending your application's raw datagrams to that address is not a substitute for the association.

Choose a library or application feature that explicitly supports SOCKS5 UDP relay, and confirm the server supports it too. A library advertising SOCKS support might implement only TCP CONNECT. The protocol specification distinguishes the commands.

The UDP relay also needs a usable path

A successful TCP connection to the proxy establishes only the control path. Firewalls or NAT behavior can still interfere with datagrams sent to the relay. Collect the returned relay endpoint and any relay error before concluding that the application destination is offline.

Finally, SOCKS transport support does not add delivery guarantees to UDP. Your application's own timeouts, loss handling, and message-size constraints still apply after the route changes.