SOCKS5 is a general-purpose proxy protocol. A SOCKS-aware application connects to the proxy first, tells it which destination it wants, and lets the proxy establish or relay the connection.
Consider a Windows host that can reach an internal database through an authorized company network connection. A second workstation cannot reach that database directly, but its database client supports SOCKS5. The path can look like this:
SOCKS_PORT means the port configured for the SOCKS5 listener. It is not a fixed product port.
What SOCKS5 actually defines
The protocol is standardized in RFC 1928. A client first negotiates with the SOCKS5 server, then sends a request describing the destination and the operation it wants.
Three request types are defined:
| SOCKS5 command | Purpose | What it means in practice |
|---|---|---|
| CONNECT | Ask the proxy to establish a TCP connection | The most common mode for browsers, developer tools, database clients, SSH-capable tools, and other TCP applications that support SOCKS. |
| BIND | Ask the proxy to accept an incoming connection | Used by some protocols and uncommon in everyday desktop proxy configuration. |
| UDP ASSOCIATE | Create a UDP relay association | Works only when the client and server actually implement the SOCKS5 UDP behavior and the surrounding network permits it. |
This is why SOCKS5 is often described as more general than an HTTP proxy: the proxy is not limited to understanding HTTP requests before it can relay a connection.
TCP is the common case; UDP needs separate verification
SOCKS5 CONNECT is straightforward for TCP. If a desktop application explicitly offers a SOCKS5 option, TCP is often the first capability it supports.
UDP is different. RFC 1928 defines UDP ASSOCIATE, but an application can advertise “SOCKS5” while implementing only TCP CONNECT. The server can also omit or restrict UDP support.
This matters for software that mixes protocols. Voice, video, games, DNS, and real-time applications can use UDP for some functions and TCP for others. Partial success can therefore be misleading.
DNS: local resolution and proxy-side resolution are not the same
Suppose the target is erp.company.internal. Before a connection can be made, somebody has to turn that name into an address.
A SOCKS5 request can carry an IPv4 address, IPv6 address, or a domain name. But the client decides whether it resolves the name locally first or sends the domain name to the proxy.
| Resolution path | What happens | Typical failure |
|---|---|---|
| Local resolution | The client resolves the hostname on PC B, then asks SOCKS5 to connect to the resulting address. | An internal company hostname may fail because PC B cannot use the DNS view available to Windows A. |
| Proxy-side resolution | The client sends the domain name through SOCKS5 and lets the proxy side resolve it. | Works only if the client really supports remote hostname resolution and the proxy host can resolve the name. |
curl makes the difference visible: its proxy documentation distinguishes SOCKS modes that resolve locally from SOCKS5 hostname resolution through the proxy. Other applications may expose the option with names such as “proxy DNS,” “remote DNS,” or may not expose it at all.
SOCKS5 does not provide encryption by itself
SOCKS5 includes a method-negotiation step and can be paired with authentication methods. That is not the same as encrypting the application data.
If the application uses HTTPS, SSH, TLS, or another encrypted protocol inside the SOCKS5 connection, that protocol can protect its own traffic. If the application sends an unencrypted protocol, ordinary SOCKS5 does not magically turn the payload into an encrypted VPN tunnel.
This is one reason “SOCKS5 versus VPN” is not a simple faster/slower comparison. They operate differently and can be combined with different security properties.
Why SOCKS5 still does not mean system-wide proxying
A SOCKS5 server can be perfectly healthy while a program on the same PC continues to connect directly. The missing piece is often the client.
The application must either:
- have native SOCKS5 support;
- use a library or runtime configured for SOCKS5; or
- be handled by another local mechanism that redirects its connections into SOCKS5.
Without one of those paths, simply having a SOCKS5 listener on the LAN does not alter the application's routing.
If the requirement is “all software on this computer should use another host without per-application proxy settings,” see Proxy vs VPN vs Gateway on Windows. That is a network-path problem, not just a SOCKS5 configuration problem.
How NetConfiger uses SOCKS5 in the current public mode
NetConfiger can expose a SOCKS5 listener on a Windows host that already has an authorized, usable upstream network connection. Compatible downstream applications can point to the host's LAN address and configured SOCKS5 port.
The current public mode should be described as explicit proxy distribution:
- the Windows host owns the upstream network path;
- NetConfiger exposes the proxy endpoint;
- the downstream application must support and use SOCKS5;
- protocol behavior such as UDP and DNS must be verified for the actual client.
For browser- and web-oriented traffic, an HTTP proxy can be a simpler fit. The companion article What Is an HTTP Proxy? explains HTTP and HTTPS CONNECT separately.
Five tests that tell you more than “the proxy connects”
- Test the exact application. A browser result does not prove a database client or desktop app is using SOCKS5.
- Test the exact destination. Public Internet access and access to an internal subnet are different checks.
- Test a hostname and an IP separately. This reveals many DNS-resolution differences.
- Identify TCP versus UDP. Do not assume one working transport proves the other.
- Compare with the proxy disabled. If the application behaves identically, verify that it was actually using the proxy at all.
What SOCKS5 is good at — and where to stop
SOCKS5 is a strong option when an application explicitly supports it and needs a general TCP connection through another host. It can also support UDP when both sides implement the required behavior.
It is not a substitute for every network layer. ICMP, raw IP traffic, layer-2 broadcasts, applications that ignore proxy settings, and system-wide default routing are different problems. Treating those as “SOCKS5 bugs” usually sends troubleshooting in the wrong direction.
Key points
- SOCKS5 is broader than a web proxy because it can relay general TCP connections and defines UDP relay behavior, but real support depends on both client and server.
- DNS can be resolved locally or through the proxy depending on the application, so hostname failures need separate testing from IP connectivity.
- SOCKS5 is still explicit proxying: applications that do not support or use it can continue to connect through their normal network path.