SOCKS5 and SOCKS4 Proxies

A SOCKS proxy lets an application connect to a destination through an intermediary server. The application tells the proxy where it wants to connect; the proxy opens the connection and relays the traffic. This can serve browsers, automation scripts, file transfer tools and other programs with suitable SOCKS support.

SOCKS4 and SOCKS5 describe how the application talks to that intermediary. If you are choosing between protocol families, SOCKS vs HTTP Proxies covers that comparison. Within SOCKS, the starting choice is clear: use SOCKS5 for a new setup. Keep SOCKS4 or SOCKS4a for software that specifically requires them.

Choosing the version is only the first step. You also need to know who resolves domain names, how the proxy accepts your connection and whether the application supports the traffic you intend to send. Those details explain why the same proxy can work in a command-line test and fail in a browser or another program.

How a SOCKS connection works

Suppose an application wants to reach an HTTPS website through a SOCKS5 proxy. There are four steps before it can exchange the website's data:

1. Reach the proxy. The application opens a TCP connection to the proxy's address and listening port.
2. Agree on access. It offers the authentication methods it supports. The proxy selects an acceptable method, and the client completes that exchange if required.
3. Request the destination. The application supplies the destination address and port. The proxy checks whether it will allow the connection and attempts to open it.
4. Start the application's exchange. After the proxy reports success, the application can negotiate TLS with the HTTPS website and send its request through the connection.

The proxy port and destination port have different jobs. You might connect to the proxy at proxy.example:1080 while asking it to reach example.com:443. Changing the first port does not change the website's port, and a listening proxy does not prove that it can reach the requested destination.

Once the connection is established, SOCKS can relay the application's byte stream without needing to understand its page requests, file commands or other messages. That is why it can support applications beyond a browser. The application still needs native SOCKS support or a compatible adapter, and the service must allow the required destination and port.

SOCKS has its own CONNECT command for opening an outgoing TCP connection. It also defines BIND for certain applications that need an incoming connection through the proxy. Ordinary website and API requests use CONNECT; a working CONNECT service is not a promise of unrestricted incoming ports or support for BIND.

SOCKS4, SOCKS4a and SOCKS5 compared

SOCKS4 provides TCP connections with the destination represented as an IPv4 address. SOCKS4a extends it so the application can pass a domain name to the proxy instead. SOCKS5 adds native IPv6 address fields, negotiated authentication methods and a UDP relay mechanism.

This table describes the protocols. A specific application or service can implement a smaller set of features. In particular, a SOCKS5 endpoint can provide TCP access without providing a usable UDP relay.

The difference between SOCKS4 and SOCKS4a matters if a domain cannot be resolved from your device. Plain SOCKS4 requires an IPv4 destination in its request. SOCKS4a lets the proxy perform the lookup. Both the client and server must understand the extension; choosing SOCKS4 in a menu does not automatically enable SOCKS4a.

SOCKS5 removes these older restrictions from the protocol. There is usually no reason to select SOCKS4 when your application and service both support SOCKS5. Use the older version to meet a real compatibility requirement, not as a way to make the same IP more private or more trustworthy.

Local DNS and DNS through the proxy

DNS translates a domain name into an IP address. SOCKS5 allows the application to send either an already resolved IP or the domain name itself. The application's DNS mode determines which happens. The SOCKS5 label alone does not tell you where the lookup will run.

With local resolution, imagine your application asks its configured DNS resolver for shop.example and receives 203.0.113.40. It then asks the SOCKS proxy to connect to 203.0.113.40:443. The proxy receives an address it can use immediately. The destination lookup has already happened on the client's side.

With proxy-side resolution, the application sends shop.example:443 to the SOCKS proxy. The proxy arranges the DNS lookup and connects to the resulting address. Your application does not need to resolve that destination name before making the request. The domain and IP here are illustrative, not working service addresses.

This choice has practical consequences. If local DNS fails, passing the name to the proxy can allow the connection to proceed. If a service returns different addresses according to the DNS resolver's location, moving the lookup can also change the selected server. It does not guarantee a particular country or grant access to a restricted website.

There is also a privacy difference. A local destination lookup goes to the resolver configured for that lookup even though the later connection uses a proxy. If you expected destination lookups to stay on the proxy side, a lookup sent outside that route is a DNS leak. Encrypted DNS can protect the exchange on the network, but the resolver handling it still receives the question.

In curl, these commands make the distinction explicit:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

The first resolves example.com locally. The second sends the name to the proxy for resolution. Use socks5h:// in curl when you want the destination resolved through the proxy. The h is a client setting, not a separate or newer SOCKS protocol. Another application may use a checkbox, a different option name or remote resolution by default.

This remote lookup for a TCP connection does not require the client to use a UDP relay. It sends the domain name in the SOCKS request, and the proxy handles resolution.

This choice applies to that connection's destination. Your device may still need to resolve the proxy's own hostname to reach it. Other applications keep their own DNS settings. Proxy-side DNS therefore does not mean that every DNS query from the computer has moved to the proxy.

Authentication and protection of your data

With SOCKS5, the client and proxy agree on an authentication method before the destination request. A service can require a username and password or allow a connection without that exchange, for example after checking the client's source IP against an allowlist. SOCKS5 does not mean that every endpoint requires a password.

This also explains two different login failures. If the client offers no method the server accepts, the connection fails before any password is checked. If the parties select username/password authentication and the credentials are rejected, then the login or account access needs attention. Changing a correct password will not fix a client that does not implement the required method.

The standard SOCKS5 username/password exchange sends the credentials without encryption. Connecting to an HTTPS website afterward does not protect that earlier login. To protect it on the network, the path to the proxy needs separate encryption. The fact that a service requires authentication is not evidence that this protection exists.

The application's own protocol determines how its content is protected during ordinary SOCKS forwarding. HTTPS encrypts website data between the application and the website, assuming valid certificate checks and no TLS interception. An unencrypted application protocol does not become encrypted merely because it passes through SOCKS5.

SOCKS4 includes a user ID field, but it does not define the same username/password login method. Servers can still enforce access rules, including source-IP restrictions. A SOCKS4 configuration without a password field is not necessarily an open public proxy.

TCP, UDP and IPv6: what support really means

For TCP applications, SOCKS creates a connection through which the program can exchange an ordered stream of data. HTTPS requests, many API clients and SSH connections can use this path when the client is configured to use SOCKS and the destination is allowed. A proxy that works for a website can still refuse another application's destination port.

UDP is separate. The program must use SOCKS5's UDP ASSOCIATE mechanism, and the service must provide the relay. A normal SOCKS TCP connection does not automatically capture the program's UDP traffic. A game can establish its TCP login connection while its UDP gameplay traffic remains unsupported; a browser test will not expose that problem.

For tasks that need UDP, confirm support in the actual program and service, then test that traffic. An HTTPS request through SOCKS CONNECT tests TCP forwarding. It does not test the UDP relay. The details of UDP forwarding and QUIC require a separate check; a generic “SOCKS5 supported” claim is insufficient.

IPv6 support is another distinct feature. SOCKS5 can represent an IPv6 destination directly. Your connection to the proxy can use IPv4 while the proxy connects onward using IPv6, provided the proxy has working IPv6 access. The two connections do not have to use the same address family.

That protocol capability does not guarantee that a package includes IPv6 exits or that an IPv4-only destination will receive an IPv6 connection. When you need IPv6, confirm that the endpoint can reach IPv6 destinations and test one. Selecting SOCKS5 in a menu cannot supply connectivity that the service lacks.

Why one application works and another does not

A program's SOCKS support has several parts: the version it speaks, the authentication methods it accepts, where it resolves names and which transports it can send. Two programs with a SOCKS5 setting can differ on all the other parts.

For example, Chrome's built-in SOCKS5 support uses proxy-side name resolution for destination requests but does not implement SOCKS5 authentication or UDP relay. A service requiring a SOCKS username and password will not work directly through that setting. It can still work in another client that implements the required authentication. Browser extensions and external adapters are separate arrangements.

Application scope matters too. A proxy set inside a browser does not redirect a separately running script, downloader or desktop program. Even a system proxy setting only affects software that uses it. When a program lacks native SOCKS support, an adapter must redirect its connections; check whether that adapter covers TCP, UDP and DNS for the program you intend to use.

SOCKS is not a general IP tunnel. It does not provide ordinary ICMP forwarding, so a successful or failed ping is not a test of a SOCKS connection. Likewise, opening an IP-check page in one browser says nothing about the route taken by another application.

Configure and verify the intended connection

Start with the endpoint address, listening port, supported SOCKS version and access method. Use the details supplied for that endpoint. Port 1080 is conventional, but services can use other ports. Neither a familiar port number nor an HTTP proxy field changes the protocol spoken by your application.

Keep proxy credentials separate from website credentials. In a graphical client, use the proxy's own authentication fields. In curl, proxy credentials belong to --proxy-user; --user is for authentication to the destination. If the service uses an IP allowlist, the permitted address must match the source IP the proxy sees. Switching networks can change that address.

Then choose DNS behavior. The two curl examples above differ only in who resolves the destination. For a browser or automation library, locate its equivalent setting rather than assuming that the same URL spelling is accepted everywhere. The examples use placeholders: replace the proxy hostname and port with your endpoint and supply its required access details.

Also check proxy bypass rules. A destination on an application's exclusion list may be contacted directly even when a proxy is configured. In curl, NO_PROXY can exclude destinations; for an explicit proxy test, adding --noproxy "" clears that exclusion list for the invocation. Use this deliberately when testing the route.

Verify the result in the program you will actually use. A request to an IP-checking endpoint, or a request recorded in a server log you control, can show the source address used for that request. Compare the proxied result with the direct connection. The proxy endpoint's address and its exit address need not be identical.

Finally, test the real destination and required transport. A visible proxy IP confirms the route of the tested request; it does not establish permission to access another service, UDP support or acceptable performance under your intended workload.

Troubleshooting by connection stage

The useful first question is how far the connection got. A failure to reach the proxy, a rejected login and a refusal by the destination are different problems. Replacing the exit IP before identifying the stage can leave the actual error unchanged.

If a valid HTTPS connection completes and the website returns a login page, CAPTCHA or access denial, SOCKS has already carried the exchange. You are now dealing with the website's response, account rules or assessment of the request. That is different from failing to establish the proxy connection.

If the page still reports your usual public IP, investigate application settings and bypass rules before changing credentials. If web requests work but the required UDP feature does not, test UDP support directly. These checks answer different questions and should not be replaced by one generic “proxy works” result.

What the SOCKS label tells you about a service

SOCKS5 identifies a connection protocol. It does not identify the source of the exit IP, whether the address is shared, how long you keep it or whether it rotates. Datacenter, ISP, residential and mobile services can offer SOCKS access. Those service properties need their own specifications.

It also does not guarantee anonymity. The proxy operator sees the client connection and requested destination; the website sees the exit address and can still recognise an account, cookies or other application information. A new protocol setting does not remove those signals.

Nor does the SOCKS5 label establish speed. Route length, available bandwidth, server load and the destination all affect performance. Compare results for your application and workload instead of treating the protocol name as a performance rating.

For a practical purchase or configuration decision, first establish compatibility: SOCKS version, authentication, DNS mode and any UDP or IPv6 requirement. Then assess the IP service and its performance. That gives you a usable connection and a clear basis for deciding what you are paying for.