The most reliable first test for SOCKS5 UDP support is a direct UDP ASSOCIATE probe—not a browser, VoIP app, or system-wide tunnel. The Python checker below negotiates SOCKS5, requests a UDP relay, sends a DNS query through it, and validates both the returned SOCKS5 envelope and DNS answer. It does not print proxy credentials, and it does not treat an arbitrary packet or a timeout as a definitive result.
Quick Answer
Save the checker in this guide as socks5_udp_check.py, then run:
If the proxy requires username/password authentication, load SOCKS5_USERNAME and SOCKS5_PASSWORD through your existing secrets workflow before running the command. Do not put a password in the command itself, a proxy URL, source code, screenshots, or logs.
A passing result means the proxy accepted UDP ASSOCIATE, relayed one DNS query to the selected resolver, returned a valid unfragmented SOCKS5 UDP packet, and carried a structurally complete DNS response. The accepted IPv4 answer must belong to the queried name or a CNAME chain rooted at it. A pass does not prove that every UDP destination or protocol is allowed.
A timeout is inconclusive. It may reflect a blocked resolver, local firewall, routing problem, source-address restriction, packet loss, or proxy policy—not necessarily a lack of SOCKS5 UDP support.
Key Takeaways
- SOCKS5 TCP CONNECT support does not prove that the same endpoint permits UDP ASSOCIATE.
- A valid test must inspect the relay reply, SOCKS5 UDP envelope, complete DNS message, and answer ownership—not merely receive a datagram.
- Keep the TCP control connection open for the association, and never include proxy credentials in test output.
- Treat silence as unresolved. Isolate routing, firewall, destination, proxy-policy, and packet-loss variables before using tun2socks or an application-level test.
What Counts as a Valid SOCKS5 UDP Test?
A useful checker validates each layer independently. Otherwise, it can report a false pass after receiving an unrelated or malformed datagram—or a false failure when only the chosen DNS resolver is unreachable.
| Test stage | What the checker verifies | What a pass establishes | What a failure establishes |
|---|---|---|---|
| TCP connection | The SOCKS5 control endpoint is reachable | The client can reach the proxy over TCP | A reachability, DNS, port, or firewall problem exists before UDP testing begins |
| Method negotiation | The server selects a method the client offered | SOCKS5 negotiation is valid | The endpoint, version, or available authentication method is wrong |
| Authentication | Username/password authentication succeeds when configured | The supplied credentials are accepted | Authentication failed; it says nothing about UDP relay support |
| `UDP ASSOCIATE` | The server returns success and a usable relay address/port | The server accepted the association request | The reply code identifies a command or policy failure |
| Relay packet | The reply comes from the negotiated relay and has valid reserved, fragment, address, and port fields | One unfragmented SOCKS5 UDP response was structurally valid | The returned datagram cannot be trusted as a valid SOCKS5 UDP response |
| DNS response | Transaction ID, response flags, question, return code, declared sections, CNAME chain, and A-record owner are valid | The selected DNS request completed through the relay | The payload was malformed, incomplete, unrelated to the query, or returned no valid A record for the requested name chain |
The SOCKS5 specification, RFC 1928, defines UDP ASSOCIATE as command 0x03. It also defines the UDP request/reply envelope: two reserved bytes, a fragment byte, an address type, destination address, destination port, and application data.
How SOCKS5 UDP ASSOCIATE Works
The test uses two related connections:
The TCP connection is not just setup traffic. RFC 1928 says the UDP association ends when the TCP connection that requested it terminates. A test that closes the control socket before waiting for the UDP reply can create its own failure.
The proxy's successful UDP ASSOCIATE reply includes the address and port of its UDP relay. The client sends the DNS query to that relay—not directly to the resolver—and wraps it in the SOCKS5 UDP header. The proxy returns the resolver's reply in the same kind of envelope.
This checker sets FRAG to zero and rejects nonzero FRAG values in replies. RFC 1928 makes fragmentation support optional for clients and requires clients without it to drop fragmented datagrams.
Before You Run the Checker
You need:
- Python 3.10 or newer.
- A SOCKS5 hostname and port.
- A username and password only if the endpoint requires them.
- An approved UDP DNS resolver reachable from the proxy. The default is Google Public DNS at 8.8.8.8:53, whose published addresses and UDP/TCP service are documented by Google Public DNS.
- Permission to test the proxy and destination.
The script uses only Python's standard library. It makes one A-record query for example.com unless you override --name. Choose a domain and resolver you are allowed to query, and keep retries bounded.
For authenticated access, let your password manager, CI secret store, or runtime secrets system populate SOCKS5_USERNAME and SOCKS5_PASSWORD. If you need a one-time local prompt that avoids putting the values in shell history, use:
Clear the variables from the shell when the test is complete:
Username/password authentication is defined by RFC 1929. That subnegotiation does not encrypt the credentials by itself, so use it only across a trusted network path or an additional protected transport appropriate to your environment.
Python SOCKS5 UDP Checker
Save the following exact script as socks5_udp_check.py:
The code intentionally keeps the TCP control socket open until after DNS validation. It also reports only the proxy host, port, and authentication method. The username and password are read from the environment but never included in the result object.
Run the Test
Run the default DNS probe:
To use a different approved resolver or DNS name:
Do not add credentials as command-line flags. Command arguments may be visible to other processes, recorded by shell history, or captured in support output.
How to Read a Passing Result
A successful result looks like this example:
The example values are illustrative. A pass establishes all of the following for that one probe:
- The TCP SOCKS5 endpoint was reachable.
- The selected authentication method succeeded.
- The proxy accepted UDP ASSOCIATE.
- The reply arrived from the negotiated UDP relay.
- The SOCKS5 UDP reserved field was zero and FRAG was zero.
- The embedded source was the requested resolver on UDP port 53.
- The DNS transaction ID matched the query.
- The packet was a non-truncated standard DNS response with NOERROR.
- Every record declared in the answer, authority, and additional counts was structurally present, with no undeclared trailing bytes.
- The response repeated the expected question and contained an IPv4 A answer owned by that name or a validated CNAME chain rooted at it.
This is stronger than checking for “some bytes,” but it is still scoped evidence. It does not establish access to other resolvers, arbitrary UDP ports, QUIC, games, voice applications, or every network path.
How to Read a Failure
The stage field identifies the last operation attempted:
| Failure stage | Likely area to inspect | Does it prove UDP is unsupported? |
|---|---|---|
| `configuration` | Missing credential pair, invalid port, invalid resolver, or invalid DNS name | No |
| `tcp_connect` | Proxy hostname, TCP port, local route, allowlist, or firewall | No |
| `method_negotiation` | Wrong endpoint, unsupported authentication method, or non-SOCKS service | No |
| `authentication` | Username, password, account state, or access policy | No |
| `udp_associate` | SOCKS reply code, proxy policy, command support, or address-type support | Sometimes; inspect the explicit reply code |
| `udp_relay` | Local UDP route, relay reachability, client source restriction, destination policy, congestion, or packet loss | No; a timeout is inconclusive |
| `socks_udp_response` | Malformed relay envelope, fragmentation, unexpected relay source, or wrong embedded source | It proves this response was not accepted as a valid result |
| `dns_response` | Mismatched transaction, bad flags, DNS error, incomplete declared section, wrong question, unrelated A-record owner, broken CNAME chain, or missing A answer | No; UDP transport may have worked while the payload failed validation |
For example, a silent test returns an error similar to:
That language is deliberate. RFC 1928 allows a UDP relay to silently drop a datagram it cannot or will not relay. UDP itself also has no delivery acknowledgement. Silence therefore identifies a symptom, not its unique cause.
SOCKS5 UDP ASSOCIATE Reply Codes
When stage is udp_associate, the checker includes the proxy's REP code and its standard meaning.
| Code | RFC 1928 meaning | Practical next check |
|---|---|---|
| `0x01` | General SOCKS server failure | Review proxy logs or ask the provider which condition failed |
| `0x02` | Connection not allowed by ruleset | Confirm UDP use and the selected destination are permitted |
| `0x03` | Network unreachable | Check the proxy's route to the requested network |
| `0x04` | Host unreachable | Verify the resolver address and upstream reachability |
| `0x05` | Connection refused | Confirm the endpoint and destination service |
| `0x06` | TTL expired | Investigate the upstream network path |
| `0x07` | Command not supported | The endpoint rejected `UDP ASSOCIATE`; confirm that UDP-over-SOCKS5 is available on that product or port |
| `0x08` | Address type not supported | Try a supported IPv4, IPv6, or domain address type as appropriate |
A 0x00 success reply proves only that the association was accepted. The relay still needs to return a valid application response before the end-to-end test passes.
Troubleshoot an Inconclusive Timeout
Use a controlled sequence rather than immediately concluding that the proxy lacks UDP support.
1. Confirm the control endpoint
Verify that the hostname, port, authentication method, account allowlist, and product are correct. A SOCKS5 endpoint and an HTTP proxy endpoint are not interchangeable. Ordinary HTTP proxy support does not imply arbitrary UDP relay support.
2. Inspect the last successful stage
If the test never reaches udp_associate, solve the TCP or authentication issue first. If the proxy returns 0x07, it explicitly rejected the command. If the association succeeds but the relay is silent, more than one explanation remains.
3. Check the negotiated relay address
The UDP relay address may differ from the TCP proxy address. Ensure the client can send UDP to the returned address and port. Check outbound firewall rules, security groups, container networking, Kubernetes network policies, NAT behavior, and VPN routes.
The relay can also associate packets with the source address used by the client. Running the TCP control connection and UDP socket from different hosts or network paths can cause packets to be dropped.
4. Run a direct control test from the same machine
Test whether the selected resolver is reachable directly from the same environment, without the proxy, if your policy permits it. A failed direct control suggests the destination or local network—not the SOCKS5 relay—is the first issue to solve.
Do not treat a successful direct DNS query as proof that the proxy path must work. It only removes one variable.
5. Try one second approved resolver
If policy permits, run one bounded retry with another known resolver, such as 8.8.4.4. A destination-specific block can otherwise look like general UDP failure. Avoid an unbounded retry loop because it hides the failure rate and generates unnecessary traffic.
6. Check proxy-side evidence
If you operate the SOCKS5 server, inspect its logs and packet counters. If you use a managed service, give support the timestamp, proxy host and port, returned REP code, relay address, resolver, and failure stage. Do not send the password or an unredacted command history.
7. Capture packets only in an approved environment
A packet capture can show whether the UDP request left the client and whether a reply reached it. Protect the capture as sensitive operational data: authentication traffic, internal addresses, DNS queries, and other application data may be present.
Why DNS Is a Better First Probe Than a Browser or VoIP App
DNS gives the checker a compact request and a structured response with fields that can be independently validated. The DNS message format in RFC 1035 provides a transaction ID, response flag, operation code, return code, question section, and typed answer records.
By contrast, a browser may disable or reroute QUIC, fall back from HTTP/3 to TCP-based HTTP/2, use encrypted DNS through another path, or apply its own proxy rules. A voice or gaming application can fail because of authentication, media negotiation, NAT, codecs, application servers, or firewall policy. Those are useful workload tests after the transport path is understood, but weak first diagnostics for SOCKS5 UDP.
An NTP request is also small, but a raw timestamp response provides fewer query-specific validation fields than DNS. Receiving one packet is not enough unless the client verifies it belongs to the request it sent.
When to Use tun2socks
Use tun2socks when the application cannot speak SOCKS5 UDP itself and you need to route operating-system traffic through a SOCKS proxy. Test the proxy directly first. That separates proxy capability from TUN-device, route, DNS, and application configuration.
A typical engine command resembles:
That command alone does not complete system routing. Creating a TUN interface and changing routes normally requires elevated privileges. A bad route can disconnect the machine or send the proxy's own traffic back into the tunnel, creating a loop. Use the project's current tun2socks examples, preserve an out-of-band recovery path, and explicitly exclude the SOCKS5 server from the tunnel route.
Do not paste credentials into a shared terminal recording or a repository. Use the tool's supported secret-handling method for your environment.
Does This Test QUIC or HTTP/3?
No. The checker proves one DNS-over-UDP exchange through one SOCKS5 relay. QUIC and HTTP/3 also use UDP, but browser support, proxy configuration, destination policy, TLS, and connection migration introduce different variables.
If your actual requirement is HTTP/3, first pass this low-level relay test, then run a separate application-level test with a client that explicitly documents how it carries QUIC through SOCKS5. Confirm the traffic path with client diagnostics or approved network evidence. Do not infer QUIC support merely because a website loads: the browser may have fallen back to TCP.
Testing UDP With Proxidize
UDP support is specific to the selected product, version, endpoint, protocol, and configuration. The current Proxidize Gen 2 release notes state that version 0.6.13 added a Settings-page option for enabling UDP through SOCKS5 proxies. That product-specific note does not establish support on every residential or managed mobile endpoint, and it does not document that every UDP destination or port is permitted.
The default checker requires outbound UDP port 53 to the resolver selected with --resolver. Before running it, confirm that UDP-over-SOCKS5 is enabled on the exact Gen 2 endpoint and that its destination policy permits the resolver and port. If UDP/53 is not permitted, this DNS probe is not suitable; use a provider-approved UDP destination and a validator designed for that application protocol. An HTTP endpoint cannot carry arbitrary UDP simply because another endpoint offers SOCKS5.
Proxidize provides the network connection and proxy controls. Your application still owns protocol behavior, timeouts, validation, retry policy, evidence handling, and compliance with the destination's rules and applicable law.
Common Testing Mistakes
Accepting an unrelated response
Validate the negotiated relay, SOCKS5 envelope, complete DNS sections, and answer owner. An unrelated A record does not satisfy the query unless it is reached through a validated CNAME chain rooted at the requested name.
Testing the wrong endpoint or closing it early
Use the documented SOCKS5 endpoint, not an HTTP proxy port, and keep the TCP control connection open until validation finishes. The control connection defines the lifetime of the UDP association.
Calling every timeout “no UDP support”
Silence can result from local routing, firewall policy, source restrictions, destination policy, congestion, or packet loss. Report it as inconclusive and isolate each layer.
Putting credentials in the output
Test reports need a host, port, timestamp, failure stage, and sanitized configuration—not a username or password. Redact secrets from logs, tickets, screenshots, packet captures, and repositories.
Validation Notes for This Guide
The checker was syntax-validated with Python 3.11 and exercised against a local mock SOCKS5 server on September 22, 2026. Thirteen automated tests covered:
- A valid unauthenticated UDP association and DNS answer.
- A valid username/password flow with an assertion that the serialized result contains neither credential.
- An authentication timeout attributed to the authentication stage.
- A rejected UDP ASSOCIATE command.
- A nonzero reserved field in the SOCKS5 UDP reply.
- A fragmented reply.
- A mismatched DNS transaction ID.
- An unrelated A-record owner being rejected.
- A valid CNAME chain leading to an accepted A record.
- A declared but missing additional record being rejected.
- A silent relay timeout reported as inconclusive.
- Domain-address parsing.
- IPv6-address encoding and parsing.
These are protocol and control-flow tests, not a production proxy benchmark. No live provider endpoint was used, and the results do not measure latency, success rate, destination coverage, or support across products. Run the checker against your authorized endpoint and workload before relying on it operationally.
Final Recommendation
Start with the direct checker, preserve its failure stage, and investigate timeouts rather than converting silence into a definitive verdict. Move to tun2socks or an application-level test only after the controlled probe has separated proxy behavior from system routing and application configuration.
Frequently asked questions
No. SOCKS5 defines the UDP ASSOCIATE command, but a particular server, product, account, or endpoint may not implement or permit it. Confirm the exact endpoint and test it.
A strong test shows that the proxy accepted UDP ASSOCIATE, returned a usable relay, sent back a valid SOCKS5 UDP envelope from that relay, and carried an application response that matches the original request. This guide requires a complete DNS response with an A record owned by the queried name or a validated CNAME chain rooted at it.
No. It proves that the server accepted the association request. You still need to send an encapsulated UDP datagram and validate the application response returned through the negotiated relay.
No. A timeout is inconclusive because local routing, firewall rules, relay reachability, source restrictions, destination policy, congestion, or packet loss can all produce silence. An explicit 0x07 reply is stronger evidence that the endpoint does not support the requested command.
RFC 1928 ties the UDP association to the TCP connection that requested it. Closing that connection ends the association, so the checker keeps it open until the UDP response has been validated.
cURL is useful for TCP-based protocols through SOCKS5, but it is not a general arbitrary-UDP UDP ASSOCIATE checker. Use a purpose-built client such as the Python script in this guide for a controlled DNS-over-UDP probe.
Not reliably by itself. A browser can fall back from HTTP/3 to TCP-based HTTP/2, use a different DNS path, or apply its own proxy rules. Use the direct checker first, then an application-specific test with diagnostics that confirm the actual route and protocol.
tun2socks routes traffic from a virtual network interface through a SOCKS proxy. It is helpful for applications without native SOCKS support, but it adds operating-system routing and TUN configuration that can obscure a basic proxy test.
Not by the RFC 1929 username/password subnegotiation itself. Use a trusted network path or an additional protected transport suitable for your environment, and never expose credentials in code, command arguments, logs, screenshots, or test reports.
The packet may come from the wrong sender, contain an invalid SOCKS5 UDP header, identify the wrong destination, carry a mismatched DNS transaction, report a DNS error, or contain no acceptable answer. Receiving bytes is necessary but not sufficient for a valid result.