Proxy Protocols Compared: HTTP, HTTPS, SOCKS4, SOCKS5
A compact reference to the four proxy protocols: what layer each works at, what traffic it carries, and how to troubleshoot the symptoms each one produces.
- proxy-basics
- networking
Proxy protocols differ in how deep into the network stack they operate, and that difference determines what traffic they can carry and which tools accept them. This is a reference you can scan when a connection misbehaves.
The four in brief
| Protocol | Layer | Carries | Typical port | Notes |
|---|---|---|---|---|
| HTTP | Application | HTTP, HTTPS via CONNECT | 8080, 3128 | Understands requests and headers |
| HTTPS | Application | HTTPS via CONNECT | 8080, 8443 | The label usually means CONNECT support |
| SOCKS4 | Transport | TCP only | 1080 | No authentication options beyond a user id, no IPv6 |
| SOCKS5 | Transport | TCP and UDP | 1080 | Username and password auth, IPv6 support |
HTTP and "HTTPS" proxies
An HTTP proxy parses HTTP. It can apply rules based on URL, method and headers, and it handles secure destinations by opening a tunnel with the CONNECT method. Once the tunnel is up, the proxy relays encrypted bytes and cannot read the content.
This is why "HTTPS proxy" is a misleading term. In nearly all cases it means a proxy that supports CONNECT tunnelling, not one that decrypts or encrypts your traffic. The distinction matters, and we go through it properly in HTTP vs HTTPS Proxies.
The practical strength of HTTP proxies is compatibility. Browsers, requests, curl and most scraping libraries have first-class support, so configuration is usually one parameter or one environment variable.
SOCKS4
SOCKS4 is the older of the two SOCKS variants. It forwards TCP connections without understanding the payload, which makes it protocol-agnostic within that limit. It has no real authentication mechanism, no UDP support and no IPv6, which is why it has largely been superseded.
You will still encounter it in older infrastructure. If a client only offers SOCKS4, it is usually worth upgrading rather than working around the limits.
SOCKS5
SOCKS5 is the modern general-purpose option. It establishes TCP connections on your behalf, supports UDP associations for protocols that need them, handles IPv6, and includes username and password authentication in its handshake.
Because it does not parse HTTP, it does not introduce HTTP-level behaviour such as URL normalisation, and it can carry non-web TCP traffic that an HTTP proxy cannot touch. The cost is client support: some libraries and browsers handle SOCKS5 credentials awkwardly or not at all, which is the most common reason a SOCKS5 setup fails where HTTP succeeded. We compare the two in SOCKS5 vs HTTP Proxies.
Which to choose
- Web scraping with common libraries. HTTP.
- Browsers and general web traffic. HTTP.
- Non-HTTP protocols, or tools that speak SOCKS natively. SOCKS5.
- Uncertain. Start with HTTP, because failures produce clearer errors and documentation overwhelmingly assumes it.
Remember that protocol and IP type are independent. Choosing SOCKS5 does not make an address more trusted, and choosing HTTP does not make it less anonymous.
Troubleshooting by symptom
Different protocols fail differently, which makes the symptom a useful clue.
407 Proxy Authentication Required. Credentials were rejected by the proxy, on any protocol with auth. Check the format and whether the source IP needs allowlisting, covered in Proxy Authentication.
Connection refused or timeout at connect. Usually a wrong host or port. A SOCKS5 port used for HTTP, or the reverse, produces exactly this.
TLS errors after connecting. Often a hostname or certificate issue rather than a protocol one, especially with gateways that terminate TLS themselves.
Works with curl but not the library. Frequently a credential-format problem, such as a library that does not parse user and password from a SOCKS URL.
UDP-dependent feature fails. An HTTP proxy cannot carry UDP. You need SOCKS5 with UDP enabled, and not every provider switches it on.
DNS behaves unexpectedly. Some clients resolve names locally and some send them to the proxy. The difference explains why a target sees a request it did not expect, or why a lookup fails through a proxy that does not forward DNS.
Verifying the connection
Whatever protocol you use, confirm two things rather than assuming: which IP the request exited from, and how much latency the proxy added. The LightningBytes proxy checker reports both for HTTP and SOCKS5 endpoints, and IP lookup resolves the exit address to a country and network.
LightningBytes endpoints accept HTTP on the standard port and SOCKS5 on a dedicated port. Connection details are on the residential and mobile pages, and the FAQ answers the setup questions we get most.