A SOCKS Proxy Can Load Messages but Fail on Calls

Text messages arrive through a SOCKS proxy, but a voice call never connects. The proxy is not necessarily completely broken. The application may be using a different transport for calls.

A successful TCP request proves a TCP path for that operation. SOCKS5 also defines UDP association, but the client, SOCKS service, network rules, and application settings all have to support the intended UDP route.

There is more than a TCP listener

The Dante manual separates protocol and command rules, including connect, udpassociate, and udpreply. A rule that permits only the TCP connection you already tested does not establish the required UDP permissions.

UDP association also involves a relay endpoint and return traffic. Firewalls and address translation must permit that actual path. Opening the SOCKS TCP listener is not equivalent to making its UDP relay reachable.

Check the application's current proxy documentation and settings. Different versions can handle messaging, media, and calls differently. A forum recipe for an old client should not be presented as proof that every present client routes calls through SOCKS.

Avoid opening every UDP port as a first diagnosis. Determine the relay behavior and intended client scope, then apply the appropriate restricted network policy. Likewise, disabling a proxy-for-calls setting may make a call work by sending it directly, which changes the outward route rather than repairing the proxied one.

Document success per operation: messages, media transfer, and calls. A single working request or a changed browser IP cannot establish that every part of another application shares the same proxy exit.