A SOCKS5 proxy works at the socket level. Your client runs a short handshake with the proxy, and the proxy relays raw TCP streams (and sometimes UDP datagrams) to the destination. It doesn’t inspect that traffic and it doesn’t encrypt it; if anything stays confidential, that’s TLS doing the work at the application layer.
This is also why SOCKS5 fails quietly. The handshake can succeed while your DNS lookups and WebRTC traffic walk straight past the tunnel, so “connected” never means “proxied.” The five checks below settle it end to end, in about ten minutes, with curl and a browser.
Check 1: Run a quick SOCKS5 connection test with curl
I run this pair of commands on any new proxy before I touch a single application setting:
curl https://ipinfo.io/ip
curl -x socks5h://user:pass@host:port https://ipinfo.io/ipThe first prints your real public IP. The second routes the same request through the proxy. If the output switches to the proxy’s exit IP, the TCP path works and your credentials were accepted. If both print the same address, the proxy never touched the request.
A pass here proves exactly one thing: a single TCP connection made it through the tunnel. That’s also the blind spot of every online SOCKS5 checker, which runs the same test from a web page and calls it a day. DNS, UDP, and everything else on your machine are still unaccounted for.
If the command hangs or errors out, add -v. Verbose output prints each handshake stage, so a refused connection (wrong host or port) looks nothing like an authentication failure (wrong credentials), and you stop guessing.
Check 2: Test for DNS leaks (socks5 vs socks5h)
The scheme prefix decides this one. With socks5://, your machine resolves hostnames locally and hands the proxy a bare IP, so every domain you visit still reaches your ISP’s resolver. With socks5h://, the hostname travels to the proxy unresolved and the proxy does the lookup. That one letter decides who sees your DNS queries.
Run both versions and compare the verbose output:
curl -v -x socks5://user:pass@host:port https://ipinfo.io/ip 2>&1 | grep resolved
curl -v -x socks5h://user:pass@host:port https://ipinfo.io/ip 2>&1 | grep resolvedcurl labels the first connection “(locally resolved)” and the second “(remotely resolved)”. Only the second keeps your lookups inside the tunnel.
Browsers need their own test because they don’t always honor what you configured. Open dnsleaktest.com in the proxied browser and run the extended test; every resolver it lists should belong to the proxy’s network, not your ISP. Chrome’s DNS prefetching is the classic silent leak. It resolves hostnames for links you might click, outside any proxy, and I once watched a Chrome profile with a green proxy extension hand every hostname on the page to the ISP resolver through prefetch alone. If that’s happening to you, turn off “Preload pages” in Chrome’s performance settings and run the leak test again.
Check 3: Catch WebRTC leaks in your browser
Browser proxy settings don’t cover WebRTC by default. When a page starts a WebRTC session, the browser collects ICE candidates by querying STUN servers directly over UDP, and those packets carry your real local and public addresses right around the proxy. The page doesn’t need a video call to trigger this. One JavaScript call is enough.
Open browserleaks.com/webrtc while the proxy is active. If any address under ICE candidates matches your real public IP, you’re leaking through WebRTC even while every HTTP request shows the proxy’s exit.
The fix depends on the browser. Firefox has a switch: set media.peerconnection.enabled to false in about:config. Chrome doesn’t, so install the WebRTC Network Limiter extension and restrict it to the default public interface, or block non-proxied UDP entirely.
Check 4: Verify real UDP support
SOCKS5 handles datagrams through a separate command, UDP ASSOCIATE. The client asks the proxy, over the existing TCP connection, to open a UDP relay, and the proxy replies with the address and port where it accepts datagrams. That TCP connection stays open as a control channel; close it and the relay dies with it.
Here’s a minimal probe in Python. Run it against a proxy with no-auth or IP whitelisting enabled, because a password-only proxy answers this greeting with 0xFF:
import socket, struct
s = socket.create_connection(("host", 1080))
s.sendall(b"\x05\x01\x00") # greeting: no-auth
print(s.recv(2)) # expect 05 00
s.sendall(b"\x05\x03\x00\x01" + socket.inet_aton("0.0.0.0") + struct.pack(">H", 0))
print(s.recv(10)) # second byte: 00 granted, 07 not supportedRead the second byte of the final reply. 0x00 means the association was granted, and the bytes after it are your relay endpoint. UDP ASSOCIATE is in the SOCKS5 spec, but plenty of services only relay TCP and never say so, which matters if you plan to push game traffic or QUIC through the proxy. Providers that sell SOCKS5 proxies with full UDP support return a relay address here; a 0x07 reply or a dropped connection means TCP-only, whatever the sales page claims.
Check 5: Confirm app routing and authentication
A SOCKS5 proxy isn’t a VPN. Nothing uses it unless you point that specific application at it, and whatever you forgot (an updater, a second browser profile) keeps connecting with your real IP. Once everything is configured, repeat the IP test from Check 1 inside each app that matters: load ipinfo.io in every browser and rerun the curl command from the environment your scripts actually run in.
Authentication fails in its own special way. Chrome accepts a SOCKS5 server through flags or system settings, then silently drops your username and password, so the connection fails or falls back with no visible error. In the browser, the workaround is a proxy extension that injects credentials. If an app keeps rejecting credentials you know are right, switch to IP whitelisting. Some providers, Anonymous Proxies among them, run username/password and IP auth on the same proxy, which removes the credential problem for headless tools.
SOCKS5 proxy still not working? Quick fixes
A proxy that connects but routes nothing is almost always failing one of these rows. Every pass condition is a yes or a no, so rerun the matching check after each fix. The table covers most of the failures people ask me about.
| Check | Pass condition | Most common fix |
|---|---|---|
| 1. Exit IP | curl shows the proxy IP, not yours | Fix host, port, or credentials; debug with -v |
| 2. DNS | curl says “remotely resolved”; leak page shows proxy resolvers | Switch to socks5h://; turn off Chrome preloading |
| 3. WebRTC | No real IP among ICE candidates | Disable WebRTC or restrict it with an extension |
| 4. UDP | Reply byte 0x00 plus a relay address | Move game or QUIC traffic to a UDP-capable plan |
| 5. Apps and auth | Every configured app shows the exit IP | Configure each app; whitelist your IP for Chrome |
FAQ
How do I know if my SOCKS5 proxy is working?
Start with the curl IP comparison, then test DNS, WebRTC, UDP, and per-app routing separately. The proxy is working only when every one of those paths goes through it, not just the first TCP connection.
Why is my SOCKS5 proxy connected but not working?
“Connected” only proves the handshake succeeded. The usual culprits are local DNS resolution, an app that never got pointed at the proxy, or Chrome throwing away your credentials. The table above maps each symptom to its fix.
Does a SOCKS5 proxy leak DNS?
It can. If your client resolves hostnames locally instead of handing them to the proxy, your ISP sees every domain you visit. The curl comparison in Check 2 settles it in under a minute.
Does SOCKS5 encrypt my traffic?
No. The proxy relays bytes exactly as it receives them, so confidentiality depends on TLS in the application. An https:// request stays unreadable to the proxy; plain HTTP crosses it in cleartext.
Does SOCKS5 support UDP?
On paper, yes, through the UDP ASSOCIATE command. In practice, support varies a lot, so probe the service yourself instead of trusting the product page.
When to run all this again
Proxies break long after setup day, usually because something else changed: a browser updated itself, or an OS upgrade reset a network setting. Rerun the five checks after any change like that, and if a row fails, stop sending traffic through the proxy until it passes again.
