TL;DR: SOCKS proxy connections send application traffic through another server. Each version works with different addresses and connection types.
- SOCKS4 works with IPv4 and TCP. SOCKS4a lets the proxy look up site names.
- SOCKS5 adds IPv6 and lets the proxy choose a supported login method.
- SOCKS5 can also carry UDP, but it does not add encryption.
A SOCKS proxy sends connections from a supported application through another server. SOCKS4 works with Internet Protocol version 4 (IPv4) addresses. SOCKS4 carries Transmission Control Protocol (TCP) traffic.
SOCKS4a lets the proxy look up a site name before connecting. SOCKS5 also accepts Internet Protocol version 6 (IPv6) addresses.
SOCKS5 lets the application and proxy choose a login method. SOCKS5 also defines a way to carry User Datagram Protocol (UDP) traffic.
The Internet Engineering Task Force published Request for Comments 1928 in 1996. The standard defines three SOCKS5 commands. CONNECT and BIND are two, while UDP ASSOCIATE is the third.
Those differences matter when an application needs the proxy to look up a site name. UDP support can also affect the choice. Transport Layer Security or Secure Shell must protect data that needs encryption.
How Does a SOCKS Proxy Route Traffic?
SOCKS proxies accept a connection from an application. The proxy contacts the requested website or service and passes data both ways.
SOCKS works with applications that support it. The application connects to the proxy instead of contacting a website or service directly. The proxy makes that connection for the application.
That design differs from an HTTP proxy. An HTTP proxy understands web requests and can work with request headers. SOCKS simply passes the application data.
A port is the number an application uses to reach a service. The SOCKS5 specification names TCP port 1080 as the usual choice. A provider can use another port.
A normal SOCKS5 connection follows five steps:
- Connect to the proxy: The application uses the SOCKS5 server address and port.
- Offer login methods: The application lists the methods that it supports.
- Choose a method: The proxy selects one method or rejects the connection.
- Name the target: The application sends the website or service address with its port.
- Pass the data: The proxy connects to the target and moves data in both directions.
Only applications set to use SOCKS follow this path. A browser can use the proxy while another program connects normally. Another tool is needed to send more applications through SOCKS.
Key takeaways
- A SOCKS setting changes only traffic from the chosen application, not every device connection.
- The website or service normally sees the proxy IP address for that connection.
- The application still decides what data it sends and whether that data is encrypted.
In short: A SOCKS proxy gives one supported application a different way to reach websites or services. The proxy contacts the website or service and passes the data. Other applications keep their usual connections unless another tool sends them through the same proxy.
How Do SOCKS4, SOCKS4a, and SOCKS5 Differ?
SOCKS4 handles IPv4 TCP traffic. SOCKS4a lets the proxy look up site names. SOCKS5 adds IPv6 and supported UDP traffic too.
SOCKS4 follows an older set of connection rules. The application sends an IPv4 address and a text label called USERID. SOCKS4 does not let both sides choose a login method.
SOCKS4a keeps the same basic design. It lets the application send a site name for the proxy to look up. That helps older applications avoid doing the DNS lookup themselves.
SOCKS5 accepts IPv4 addresses and IPv6 addresses. An application can also send a site name. The proxy can then look up that name.
SOCKS4, SOCKS4a, and SOCKS5 comparison
| Version | Where it can connect | Connections it supports | How login works |
|---|---|---|---|
| SOCKS4 | IPv4 addresses | TCP | Text label called USERID |
| SOCKS4a | IPv4 or a site name looked up by the proxy | TCP | Text label called USERID |
| SOCKS5 | IPv4, IPv6, or a site name | TCP and supported UDP | The proxy chooses a supported method |
Best for new setups: SOCKS5. Choose SOCKS4 for older IPv4-only software. Choose SOCKS4a when older software needs the proxy to look up site names.
The OpenSSH specifications page preserves the SOCKS4 and SOCKS4a references. The same page points to RFC 1928 for SOCKS5.
SOCKS5 defines three commands:
- CONNECT opens a TCP connection to the requested website or service.
- BIND waits for another device to connect through the proxy.
- UDP ASSOCIATE creates a way to send UDP packets.
The RFC 1928 UDP procedure keeps UDP working while the original TCP connection remains open. Closing that TCP connection also stops the UDP traffic.
Key takeaways
- SOCKS4 fits older software that needs IPv4 and TCP.
- SOCKS4a lets the proxy look up site names without replacing the older SOCKS4 design.
- SOCKS5 accepts more address types and can carry UDP when the application and proxy support it.
- Legacy software requirements are the main reason to choose an older version.
In short: SOCKS4 handles basic IPv4 TCP connections, while SOCKS4a adds site-name lookups through the proxy for older applications. SOCKS5 accepts more address types and lets the proxy choose a supported login method. SOCKS5 can also carry UDP when the application and proxy support it.
Does a SOCKS5 Proxy Encrypt Traffic?
SOCKS5 sends data through another server but does not encrypt it. HTTPS or SSH must protect any information that needs encryption.
SOCKS5 changes how data reaches a website or service. It does not add encryption. Unencrypted data remains unencrypted while passing through the proxy.
A login check does not change that fact. The application and proxy can agree on a supported login method. The application must still encrypt its own data.
The common username and password method deserves extra care. RFC 1929 says the password travels without encryption during login. A password prompt does not prove that the proxy connection is encrypted.
What protects a SOCKS5 connection?
| Protection source | What it does |
|---|---|
| SOCKS5 alone | Sends data through another server without encrypting it |
| HTTPS or another encrypted protocol | Encrypts application data between the device and website |
| SSH dynamic forwarding | Encrypts data between the local device and SSH server |
| Username and password method | Controls who can use the proxy without encrypting the data |
HTTPS works normally through a SOCKS5 proxy. The application creates an encrypted HTTPS connection through the proxy. The proxy passes that protected data without decrypting it.
The SOCKS server can still see which website or service receives the connection. It also sees any application data without separate encryption.
Key takeaways
- SOCKS5 alone sends data through another server without encrypting it.
- HTTPS protects application data while it passes through the proxy.
- SSH protects data until it reaches the remote SSH server.
- A username and password control who can use the proxy rather than encrypting the data.
In short: SOCKS5 sends data through another server, but it does not add encryption. HTTPS can protect data between the application and website for the entire connection. SSH protects data until it reaches the SSH server, while a proxy login only controls who can use the proxy.
How Does DNS Work Through a SOCKS5 Proxy?
SOCKS5 can ask the proxy to look up a site name. Some applications do the lookup first, so the setting decides where DNS happens.
The Domain Name System (DNS) turns a site name such as example.com into an IP address. SOCKS5 lets the application send that site name directly to the proxy.
Some applications do the DNS lookup on the local device. They then send the resulting IP address to the proxy. Other applications ask the proxy to perform the lookup.
cURL makes the choice explicit. The official cURL documentation uses socks5:// when the local device looks up the site name. The socks5h:// form asks the proxy to do it.
The first command looks up example.com on the local device. The second leaves that job to the proxy. The letter h tells cURL to send the site name.
Browser labels vary. Look for an option that sends DNS requests through the SOCKS proxy. Test the browser when the setting is unclear.
SOCKS4a can also ask the proxy to look up a site name. Plain SOCKS4 expects the application to provide an IPv4 address.
Key takeaways
- A SOCKS5 application can send a site name directly to the proxy.
- The application setting decides whether the local device performs the DNS lookup.
- cURL uses socks5h when the proxy should look up the site name.
- SOCKS4a offers the same choice for older applications that need the SOCKS4 design.
In short: SOCKS5 can look up a site name on the local device or through the proxy. The application setting decides which one happens, so check it before assuming DNS goes through the proxy. SOCKS4a gives older software this choice when SOCKS5 is unavailable.
How Can SSH Create a Local SOCKS Proxy?
SSH can turn a local port into a SOCKS proxy. It encrypts data between the local device and a remote SSH server while the proxy is in use.
Secure Shell (SSH) can create a temporary SOCKS proxy without another proxy program. The -D option opens the chosen port on the local device. Applications enter that address and port in their SOCKS settings.
The OpenBSD SSH manual calls this feature dynamic forwarding. It supports SOCKS4 and SOCKS5. OpenSSH encrypts each connection until it reaches the remote SSH server.
Set it up in four steps:
- Choose a local port. Port 1080 is familiar, but another free port also works.
- Run the SSH command. Open the port on 127.0.0.1, which always points back to the same device.
- Configure the application. Select SOCKS5 and enter 127.0.0.1 with the chosen port.
- Check DNS behavior. Tell the application to send site-name lookups through the proxy when needed.
The -N option prevents SSH from running another command on the remote server. The -D option creates the temporary SOCKS proxy. Using 127.0.0.1 keeps it on the local device.
Test the proxy with cURL:
SSH encrypts data between the local device and the SSH server. The application must protect data after that server. HTTPS remains useful for the final website or service.
Key takeaways
- OpenSSH can create a temporary SOCKS proxy with one command and no separate proxy program.
- Supported applications use the local address and port after a simple settings change.
- SSH encrypts data until the remote server, but each application controls protection after that point.
In short: SSH can turn one chosen local port into a temporary SOCKS proxy. OpenSSH encrypts each connection until it reaches the remote SSH server. The application still decides whether data stays encrypted between that server and the final website or service.
When Are SOCKS Proxies the Right Choice?
SOCKS proxies suit applications that need TCP or supported UDP through another server without changing every device connection.
SOCKS makes sense when one application needs a different way to connect. A browser or command-line tool can use the proxy while other applications connect normally.
SOCKS proxy decision guide
| What you need | Better choice |
|---|---|
| Send general TCP application traffic | SOCKS5 |
| Let the proxy look up site names | SOCKS5 with the correct application setting |
| Send supported UDP traffic | SOCKS5 when the application and proxy support UDP ASSOCIATE |
| HTTP header handling or web caching | HTTP proxy |
| Encrypt connections from the entire device | VPN |
SOCKS5 is best when one supported application needs a different connection. An HTTP proxy is best for web-only controls. A VPN is best for encrypting the whole device.
Check application support before comparing speed. SOCKS5 is not automatically faster than an HTTP proxy. A busy or distant server can make either option slower.
An HTTP proxy may be simpler for a web-only tool. The HTTP proxy guide explains that option. SOCKS5 becomes more useful when the same application needs non-HTTP connections.
The dedicated HTTP versus SOCKS5 comparison covers the wider choice. That comparison explains pricing and performance in detail. It also covers the relevant web features.
The application and proxy must both support UDP. The UDP over SOCKS guide explains how that feature works.
Key takeaways
- SOCKS5 suits supported applications that need TCP or available UDP support through another server.
- HTTP proxies remain useful for web-specific request handling and caching.
- A VPN is the clearer option for encrypting connections from the entire device.
- Real speed depends on the selected server and the distance to it.
In short: Choose SOCKS5 when one supported application needs TCP or available UDP through another server. Use an HTTP proxy for web controls and caching, or choose a VPN when the entire device needs encryption. Test each option with the real task before deciding.
What Are the Key Takeaways About SOCKS Proxies?
SOCKS proxies send application traffic through another server. Each version works with different address types. DNS and UDP support also vary.
- A SOCKS proxy changes the source IP address seen by a website or service.
- SOCKS4 supports TCP connections with IPv4 destinations.
- SOCKS4a lets the proxy look up site names for older software.
- SOCKS5 supports IPv4 addresses and IPv6 addresses. It also accepts domain names.
- SOCKS5 uses UDP ASSOCIATE when the application and proxy both support UDP.
- SOCKS5 does not encrypt application data without another secure protocol.
- The application setting decides whether the local device or proxy performs the DNS lookup.
Choose the version that the application fully supports. SOCKS5 is the normal choice for a new setup. SOCKS4 and SOCKS4a mainly serve older software.
Remember that a working SOCKS connection may still carry unencrypted data. HTTPS or SSH must provide the encryption.
The version label alone is not enough. Confirm which SOCKS commands the application and proxy support before depending on UDP or BIND.
In short: SOCKS5 works with the widest range of addresses, but application support still controls what works in practice. Check the DNS setting and confirm UDP support on both sides before use. Add HTTPS or SSH wherever the data needs encryption during use.
What Are the Most Common Questions About SOCKS Proxies?
SOCKS proxy questions often cover IP visibility and application support. Readers also ask about speed or VPNs. Scraping comes up too.
Does a SOCKS5 proxy hide your IP address?
A SOCKS5 proxy usually replaces the IP address seen by the website or service for that connection. The proxy still sees the original device IP address. Applications without SOCKS settings connect normally, so one proxy setting does not cover the whole device.
Is a SOCKS5 proxy the same as a VPN?
A SOCKS5 proxy normally covers only applications specifically set to use it one by one. A virtual private network usually encrypts connections from the whole device without changing each application. SOCKS offers narrower control, while a VPN covers more applications and includes encryption.
Is SOCKS5 faster than an HTTP proxy?
SOCKS5 is not automatically faster than an HTTP proxy under the same conditions. The server location and current load often matter more than the proxy type, especially over longer distances. Test both options with the same website and task several times under usual connection conditions before choosing.
What port does a SOCKS proxy use?
SOCKS often uses TCP port 1080 by default in common applications. RFC 1928 lists 1080 as the usual choice but does not require it. Providers can choose another number, so applications must use the server address and port supplied for each individual service.
Can a browser use a SOCKS5 proxy?
A browser can use SOCKS5 when it provides a SOCKS setting or follows the device settings for that profile. Check whether the browser looks up site names locally before opening the site. A separate option may be needed to send DNS through the proxy in some browsers.
Can SOCKS5 proxies be used for web scraping?
SOCKS5 can carry web scraping traffic when the chosen software supports it properly for every request. HTTP proxies may be simpler for standard website requests and easier to configure. SOCKS5 becomes useful when the same collection tool needs the proxy to handle DNS or non-HTTP connections during collection.
In short: SOCKS5 works with browsers and many other supported applications on your device. Each application controls which connections use the proxy and where DNS lookups happen. Test speed and feature support with the real task before choosing a setup for regular use.