HTTP or SOCKS5: how do you choose a proxy protocol?

The protocol is a separate layer from the IP type. A correct residential IP with the wrong protocol still produces a “proxy not working” error. This guide compares what each protocol sends on the wire, where DNS is resolved, how UDP and headers behave, the performance claims, and tool support. The examples use the WeProxy gateway gw.weproxy.com.tr:8989; USER and PASSWORD are the credentials from your dashboard.

What is the difference between an HTTP proxy and SOCKS5?

The core difference is how much of the traffic the proxy understands. An HTTP proxy reads HTTP messages: with plain HTTP it sees the URL and headers, with HTTPS it sees only the target host and port. SOCKS5 does not interpret any application protocol; it takes a target address and copies bytes in both directions.

The last row is often missed. Neither protocol encrypts the connection between the client and the proxy. With HTTPS targets the content is protected by TLS, but the proxy credentials and the target hostname reach the proxy in the clear. If the whole path between your device and the exit has to be encrypted, use a VPN; the proxy vs VPN comparison lays out the difference in scope and encryption in a table.

How does an HTTP proxy work?

With an HTTP proxy, the client opens a TCP connection to the proxy, not to the target site, and sends the request there. The request format depends on whether the target is http:// or https://.

Plain HTTP: the absolute URL

For a target without TLS, the client writes the absolute URL in the request line instead of just the path. RFC 9112 calls this the absolute-form:

GET http://example.com/products?id=42 HTTP/1.1
Host: example.com
Proxy-Authorization: Basic VVNFUjpQQVNTV09SRA==

The proxy reads the URL, resolves example.com itself, connects to the target and relays the response. In this model the proxy sees the whole request: path, query parameters, cookies and body. The Proxy-Authorization value is only Base64 encoding, not encryption; VVNFUjpQQVNTV09SRA== decodes to USER:PASSWORD.

HTTPS: the CONNECT tunnel

For HTTPS targets the client asks the proxy for a tunnel with the CONNECT method in RFC 9110:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic VVNFUjpQQVNTV09SRA==

HTTP/1.1 200 Connection established

Once the proxy returns 200, the connection becomes a raw TCP pipe. The client performs the TLS handshake with the target directly inside that pipe. From then on the proxy only carries encrypted bytes; it cannot see the URL path, headers or body. An authentication failure at this stage returns 407, an unreachable target 502.

CONNECT is not limited to HTTP; in theory it can open a tunnel to any TCP port. In practice many proxies restrict CONNECT to specific ports such as 443. That is why SOCKS5 is the more predictable path for non-HTTP TCP work.

How does SOCKS5 work?

A SOCKS5 connection has three steps: method selection, authentication and the command. All of them are binary messages with no HTTP headers.

Handshake and authentication (RFC 1928 and RFC 1929)

These are the bytes a client sends when it connects to an HTTPS site with a username and password:

Client → Proxy : 05 02 00 02          VER=5, 2 methods: 0x00 (no auth), 0x02 (username/password)
Proxy → Client : 05 02                0x02 selected
Client → Proxy : 01 04 "USER" 08 "PASSWORD"   RFC 1929 subnegotiation
Proxy → Client : 01 00                authentication succeeded
Client → Proxy : 05 01 00 03 0b "example.com" 01 bb   CONNECT, ATYP=domain name, port 443
Proxy → Client : 05 00 00 01 <BND.ADDR> <BND.PORT>    REP=0x00, connection ready

If the proxy accepts none of the offered methods, it returns 0xFF and closes the connection. In RFC 1929 the username and password travel as plaintext; this is neither weaker nor stronger than Base64 in HTTP. On an untrusted network, using an IP whitelist instead of credentials is an option. On WeProxy plans, username/password and IP whitelist authentication both work over HTTP and SOCKS5.

Commands and address types

RFC 1928 defines three commands and three address types:

For an unsupported command the proxy returns 0x07, for an unsupported address type 0x08. The full list of these reply codes and their typical causes is in the proxy error codes guide.

Where is DNS resolved: socks5 or socks5h?

With an HTTP proxy, the target hostname travels to the proxy inside the request (CONNECT example.com:443 or the absolute URL), and the proxy resolves it. A well-behaved client does not make a local DNS query for the target.

With SOCKS5 the decision is on the client. If the client resolves the name itself and sends an IP with ATYP 0x01, the DNS query goes to your own resolver. If it sends the name with ATYP 0x03, the proxy resolves it. In curl and Python this difference is expressed through the scheme name:

• socks5:// — local resolution in most clients. The query goes to your ISP or office DNS with your real IP.
• socks5h:// — the hostname is sent to the proxy (“h” = hostname). Resolution happens on the exit side.

socks5h is not a separate protocol; it is the ATYP 0x03 usage of the same RFC 1928. Local resolution has two side effects. The first is a DNS leak. The second is geographic inconsistency: a site behind a CDN returns an IP close to your location, and the proxy connects to that distant address. The DNS leak guide covers the test and the fixes in detail.

Which protocol carries UDP traffic?

An HTTP proxy does not carry UDP. CONNECT is a TCP tunnel; QUIC (HTTP/3) and game traffic do not pass through it. That is why browsers behind a proxy usually fall back from HTTP/3 to HTTP/2 or HTTP/1.1 over TCP.

SOCKS5 has the UDP ASSOCIATE command for UDP. The client first establishes a TCP control connection, and the proxy returns a UDP relay address. Each datagram is sent to that relay with a small SOCKS header containing the target address and port. When the control connection closes, the UDP association ends too.

The command is defined in the RFC, but it is not enabled on every provider or every plan. At WeProxy, the static residential IPv4 proxy product offers SOCKS5 + UDP in locations outside Türkiye; the Türkiye location is HTTP and plain SOCKS5. An endpoint without UDP support rejects a UDP ASSOCIATE request with 0x07. Details for games, VoIP and real-time applications are in the UDP proxy guide.

Does a proxy change headers?

With plain HTTP requests, an HTTP proxy sits inside the message and can add headers. RFC 9110 defines the Via header for forwarding intermediaries; reverse proxies and some corporate proxies also add X-Forwarded-For or Forwarded. Most anonymous forward proxies do not send these headers, but verify your own exit with an echo endpoint anyway.

HTTPS requests are different. After CONNECT the traffic is encrypted, so the proxy cannot touch the headers going to the target. The target site sees only the headers your client sends.

SOCKS5 never adds or reads headers. This is often presented as a “privacy” advantage, but in the HTTPS era both protocols end up in the same place: your code decides which headers the target sees. Consistency of User-Agent, Accept-Language and cookies matters more than the protocol.

Is SOCKS5 faster than an HTTP proxy?

In general, no. Once the tunnel is up, both protocols carry bytes the same way; there is no extra header or per-packet cost. The only difference is the number of round trips (RTT) during connection setup.

The TCP connection to the proxy costs 1 RTT in both cases. After that, for an HTTPS target an HTTP proxy adds 1 RTT with a single CONNECT exchange. SOCKS5 with username/password adds 3 RTT for method selection, authentication and CONNECT. If the proxy is 50 ms away, that means roughly 100 ms of extra waiting on every new connection. With IP whitelist authentication the auth step disappears and the gap shrinks to 1 RTT.

Even this gap only shows up on new connections. In a client that uses keep-alive and a connection pool, the cost is paid on the first request. The factors that set real speed are different: the type of exit IP and its distance to the target, the residential device’s line, the target site’s response time and your concurrency settings. The claim that “SOCKS5 is more anonymous” is wrong in the same way; anonymity is decided by DNS, WebRTC and header behavior, not by the protocol name.

Which tools support which protocol?

Tool support often makes the choice for you. The table below summarizes the default behavior of common clients:

Chromium’s lack of SOCKS5 authentication is the most common obstacle in practice. If you pass an authenticated SOCKS5 proxy to Puppeteer or Selenium, the connection is not established. The fix is either to use an HTTP proxy or to add your server’s IP to the whitelist in the dashboard and connect to SOCKS5 without credentials.

Different tools expect the same credentials in different formats: ip:port:user:pass, user:pass@host:port or a URL with a scheme. Instead of converting formats by hand, use the proxy format converter.

How do you use HTTP and SOCKS5 with cURL and Python?

The examples below connect to the same gateway with both protocols. Connection details may differ by plan; use the host and port shown in your dashboard.

cURL

# HTTP proxy: CONNECT tunnel for an HTTPS target
curl -sS -x "http://USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, DNS on the proxy side (recommended)
curl -sS -x "socks5h://USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, DNS resolved locally (leak risk)
curl -sS --socks5 "USER:[email protected]:8989" https://api.ipify.org
echo

# To see the handshake
curl -v -x "socks5h://USER:[email protected]:8989" https://api.ipify.org

The scheme of the proxy URL describes the proxy’s protocol, not the target’s. Even when you reach an HTTPS site through an HTTP proxy, the scheme stays http://. If the password contains @, : or /, percent-encode it. If the SOCKS handshake fails, curl returns error (97).

Python

import requests

GATEWAY = "gw.weproxy.com.tr:8989"
AUTH = "USER:PASSWORD"

profiles = {
    "http": f"http://{AUTH}@{GATEWAY}",
    "socks5h": f"socks5h://{AUTH}@{GATEWAY}",  # pip install "requests[socks]"
}

session = requests.Session()
session.trust_env = False  # keep the HTTP_PROXY env variable from overriding the dict

for name, proxy in profiles.items():
    try:
        r = session.get(
            "https://api.ipify.org?format=json",
            proxies={"http": proxy, "https": proxy},
            timeout=(10, 30),
        )
        print(name, r.status_code, r.json()["ip"])
    except requests.exceptions.RequestException as e:
        print(name, "error:", e)

If both profiles return the same exit IP, both protocols work. Which one you use then depends on the tool and the job. Setup details are on the Python integration and Node.js integration pages. To see how both profiles are set up in requests, httpx and aiohttp side by side, read the guide to using a proxy in Python. You can also confirm that the proxy responds correctly in terms of protocol and authentication with the proxy checker.

Which protocol should you choose for which use case?

The short rule: if the job is web or API traffic, start with HTTP; if there is non-HTTP TCP, UDP, or an application without a proxy setting, choose SOCKS5. In tools that support both, an HTTP proxy gives fewer round trips and wider tool compatibility.

On the product side, protocol support varies by plan; check the technical specs on the product page before buying. The rotating residential IPv4 proxy offers HTTP and SOCKS5 and fits web work such as scraping, SEO and automation. For games or real-time jobs that need UDP, look at the UDP-enabled locations of the static residential IPv4 proxy. All plans include unlimited threads and concurrent sessions; starter packages are listed on the product pages. For scenario-specific details, see the web scraping and gaming proxy pages.

The protocol choice does not change the target site’s terms of service. Automation should stay within what the target allows and within the WeProxy acceptable use rules.

An HTTP proxy is built for the web, SOCKS5 for everything. Start with whatever your tool supports, write the scheme as socks5h when you use SOCKS5, and confirm the plan’s UDP ASSOCIATE support in advance if you need UDP.