SOCKS5 & SOCKS4 Proxies

A SOCKS proxy lets an application ask an intermediary server to connect to a destination for it. The proxy opens the requested connection and passes data in both directions. The application keeps using its own protocol, so this works for web requests, API clients, file transfers and other software with SOCKS support.

For a new setup, SOCKS5 usually gives you the most useful options: more address formats, a choice of authentication methods and support for UDP. SOCKS4 remains useful for software that requires the older version. The broader choice between these protocols and HTTP proxies is covered in SOCKS vs HTTP Proxies.

How an application connects through SOCKS

Consider an application opening https://example.com/ through a SOCKS5 proxy. It first reaches the proxy, asks it to open a connection to the website, and only then exchanges website data. The process has four stages:

1. The application connects to the proxy's hostname or IP and listening port over TCP.
2. The application and proxy select an access method. If that method requires credentials, the application supplies them and the proxy checks them.
3. The application sends a SOCKS CONNECT request with the destination address and port. The proxy checks its access rules, attempts the onward connection and reports the result.
4. After a successful reply, the application communicates with the destination through the proxy. For an HTTPS website, it establishes TLS with the website and verifies its certificate before sending the web request.

The two port numbers belong to different servers. An example proxy might listen at proxy.example:1080, while the website is reached at example.com:443. Port 1080 is conventional for SOCKS, but a service can use another port. Use the listening port assigned to your proxy; it does not replace the destination's port.

During ordinary TCP forwarding, SOCKS passes the application's stream of bytes without having to interpret each HTTP request or file command. The application continues to speak its own protocol to the destination. That is why the same SOCKS connection mechanism can serve web clients and other types of software.

CONNECT is a command within SOCKS, with its own message format; it is different from the HTTP CONNECT method. SOCKS also defines BIND for applications that need a server to connect back through the proxy, as can happen with active FTP. BIND needs separate support and is not used for an ordinary website or API request.

What changes between SOCKS4, SOCKS4a and SOCKS5

SOCKS4 opens TCP connections to IPv4 addresses. SOCKS4a adds the option to send a hostname, so the proxy can find its IP through DNS. SOCKS5 adds a choice of authentication methods, accepts IPv4 addresses, IPv6 addresses and hostnames, and defines UDP forwarding.

These are protocol capabilities. The client and proxy service must implement the particular feature you intend to use. For example, a SOCKS5 service may handle TCP connections while offering no usable UDP relay.

SOCKS5 can carry an IPv6 destination in its request, but the proxy must also be able to reach that IPv6 server. The two connections can use different IP versions: the application may reach the proxy over IPv4, while the proxy connects to the destination over IPv6.

SOCKS4a is an extension of SOCKS4, not another name for every SOCKS4 connection. If an old client only sends IPv4 addresses, selecting SOCKS4 does not give it remote DNS. SOCKS4a requires support at both ends. SOCKS5 is normally the simpler choice when both ends support it; selecting SOCKS4 does not by itself improve the exit IP's reputation or speed.

Who resolves the destination name

Before a connection can reach a named server, its name must be translated into an IP address. SOCKS5 can accept either the result of that lookup or the name itself. The client's DNS setting determines which it sends.

With local DNS, the application asks its configured resolver for reports.example. Suppose the answer is 203.0.113.27: the application then requests a SOCKS connection to 203.0.113.27:443. The lookup has already taken place on the client's side, even though the subsequent website connection passes through the proxy.

With proxy-side DNS, the application sends reports.example:443 without first looking up that destination locally. The proxy obtains its IP through DNS and opens the requested connection. The hostname reaches the proxy as part of the SOCKS request.

This can help when the client cannot resolve a name that the proxy can resolve. Some services return different addresses depending on the DNS resolver, so moving the lookup can change which server receives the connection. It does not set the proxy's exit country or guarantee that the site will accept the request.

In curl, the following two commands choose the two DNS modes:

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

socks5:// makes curl resolve the website name locally; socks5h:// passes it to the proxy. Both use SOCKS5. The h means hostname resolution by the proxy in this client's URL syntax. It does not turn SOCKS5 into HTTPS or add encryption. Other applications may use a checkbox or choose remote DNS automatically. Replace the example proxy hostname and port with your service details and provide its required authentication.

Passing a domain name in a SOCKS5 TCP request does not require UDP relay support. The proxy performs the lookup using its own DNS configuration. This is different from asking SOCKS5 to carry a client's UDP packets.

If a client was configured to leave destination DNS to the proxy but performs that lookup locally, it exposes the requested name outside the intended route. This is a DNS leak. Encrypted DNS protects the exchange with the resolver, but that resolver still receives the name. Looking up the proxy's own hostname is a separate task, and other applications keep their own DNS behavior. Remote DNS in one program does not move every lookup on the device.

Authentication and encryption

SOCKS5 lets the client offer supported authentication methods and the proxy choose one. A username and password are one option. Another is a connection without a SOCKS login exchange, which a service may permit after checking the client's source IP against an allowlist. An endpoint without a password field can therefore still restrict access.

A failure to agree on a method is different from a rejected password: in the first case, the password exchange has not happened. A client that lacks username/password support cannot use a password-only SOCKS5 endpoint merely because it has a SOCKS5 setting. SOCKS4 has a user ID field but no equivalent standard password exchange; its server can still apply access rules.

The usual SOCKS5 username/password exchange does not encrypt the credentials. It occurs before the application establishes HTTPS with the destination, so that later HTTPS connection does not protect the earlier proxy login. Encryption of the client-to-proxy path requires a separate protected connection or an explicitly supported security mechanism.

During ordinary SOCKS forwarding, HTTPS protects the application's exchange with the website, with certificate verification enabled and without TLS interception. An unencrypted application protocol remains unencrypted through the relay. SOCKS5 support or password authentication alone does not promise encrypted traffic.

The proxy still knows the client's connecting IP, requested destination and connection timing. The destination sees the proxy's exit IP and receives the application data intended for it. Cookies, account logins and other application identifiers can still identify the user; changing the SOCKS version does not remove them.

How SOCKS5 carries TCP and UDP

TCP provides an ordered stream of bytes. A browser request, an API call or an SSH session can use a SOCKS TCP connection when the client supports that route and the proxy allows the destination. Success on a website's port 443 does not establish that another application's port is available.

UDP sends separate datagrams. A SOCKS5 client first opens a TCP control connection and requests a relay using UDP ASSOCIATE. The proxy returns the relay address and UDP port. The client sends its datagrams there with SOCKS headers describing their destinations. Closing the TCP control connection ends this UDP association; the datagrams travel separately from the control connection, not inside an ordinary SOCKS CONNECT stream.

Both the application and service must support this mechanism, and the network must allow the UDP path. A program may complete a TCP login while its voice, game or other UDP function still fails. A successful HTTPS request through SOCKS CONNECT demonstrates TCP forwarding, not working UDP. QUIC uses UDP, but usable QUIC also depends on the client and the complete path; the SOCKS5 label alone does not establish it.

Where SOCKS is useful

SOCKS is useful when software needs an intermediary connection while retaining its own application protocol. A script can request API data through an assigned exit IP, a file transfer client can reach a remote server through an approved route, and a compatible desktop application can use a proxy without being a web browser. Each case depends on the client's SOCKS support and the destination ports the service permits.

For repeated work with the same account or server, a fixed exit may be appropriate. For separate tasks, a rotating service may be useful. SOCKS4 and SOCKS5 do not decide this behavior: the service determines the exit IP, its network type, whether other customers use it and when it changes. The protocol version also provides no speed ranking; route length, server load and available bandwidth affect the result.

Client support can be narrower than the protocol. Chrome's built-in SOCKS5 implementation resolves destination names through the proxy but does not perform SOCKS5 username/password authentication or relay UDP. A password-only endpoint can therefore work in curl and fail through that built-in browser setting. An external adapter is a separate part of the connection, with its own capabilities.

A proxy configured inside one program applies to that program's supported connections. It does not configure a separate downloader or script. System proxy settings likewise affect software that uses them. When an adapter redirects connections from an application without native SOCKS support, its coverage of TCP, UDP and DNS matters. SOCKS does not provide ordinary ICMP forwarding, so ping is not a test of this proxy path.

Connection settings and a useful test

Start with the proxy address, listening port, SOCKS version and access method supplied for the endpoint. A number such as 1080 does not identify the protocol by itself. Select SOCKS in the client instead of entering the same address into an HTTP-only proxy field.

Proxy credentials authorize use of the intermediary; a website login authorizes use of the website. They belong in different settings. In curl, --proxy-user supplies proxy credentials, while --user supplies destination credentials. For IP-based access, the allowlist must match the client's source IP as seen by the proxy, which may change when the client changes networks.

Choose the intended DNS mode, then check any bypass rules. A configured proxy can be skipped for destinations on an exclusion list. In curl, NO_PROXY can cause this; --noproxy "" clears those exclusions for one invocation when you deliberately want to test the proxy route.

Test from the actual program that will do the work. An IP-checking endpoint, or a destination server log you control, can show the source IP of the request. Compare that result with a direct request. The address used to reach the proxy and the exit address seen by the destination need not be identical.

Then try the real task. A changed IP demonstrates the route of the tested request, but does not measure all transports or establish how another site will respond. Test UDP or IPv6 separately when the task needs them, and assess response time and connection stability under a representative workload.

Locate an error by its connection stage

Distinguish reaching the proxy, obtaining access, opening the destination connection and receiving the application's response. These stages have different failure causes.

If a verified HTTPS connection succeeds and the site returns a login page, CAPTCHA or access refusal, the SOCKS connection has already carried that exchange. Investigate the site's response and application behavior. If the request instead shows your usual public IP, check the selected proxy and bypass rules in that program.