HTTP vs SOCKS5 proxies: what actually differs

An HTTP proxy understands the protocol you are speaking. A SOCKS5 proxy understands only where you want to go. That single difference explains everything else: what each can carry, what each can see, who looks up the hostname, and why one client leaks DNS queries through SOCKS5 while another does not. Neither protocol is more anonymous than the other by itself, and on GhostConnect the price does not depend on which you use. This guide separates the differences that are real from the ones that are folklore.

How an HTTP proxy carries a request

For a plain http:// URL the client sends the proxy an ordinary HTTP request with the full URL on the first line, GET http://example.com/page HTTP/1.1, plus a Proxy-Authorization header carrying the username and password in Basic form. The proxy reads the request, opens its own connection to the site, forwards the request and passes the response back. It is a full participant: it parses the headers, can add or drop them, and can read the body, because nothing is encrypted.

For an https:// URL the client cannot hand the proxy a request to forward, because the request is going to be encrypted between the client and the site. Instead it asks for a tunnel with the CONNECT method, defined in RFC 9110, section 9.3.6:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic base64(username:password)

The proxy opens a TCP connection to example.com on port 443, answers 200 Connection Established, and from then on copies bytes in both directions without reading them. The TLS handshake and everything after it happens between your client and the site. If the credentials are missing or wrong the answer is 407 Proxy Authentication Required instead, which is why a 407 means "fix the proxy password", never "the site refused you".

How a SOCKS5 connection starts

SOCKS5, from RFC 1928, never sees an HTTP request at all. The client opens a TCP connection to the proxy and the two exchange a few small binary messages:

1. The client lists the authentication methods it supports and the proxy picks one. With a username and password that is method 2, defined in RFC 1929, and the credentials go across in the next message.
2. The client sends a request: a command (CONNECT for an outbound TCP connection, BIND for an inbound one, UDP ASSOCIATE for datagrams), an address type, the address and a port. The address type is the detail that matters later: type 1 is an IPv4 address, type 4 an IPv6 address, and type 3 a domain name, which asks the proxy to resolve it.
3. The proxy connects, replies with a status byte and the address it bound, and from then on relays bytes.

After step 3 the proxy is doing exactly what an HTTP proxy does after CONNECT: copying bytes. The difference is what came before. SOCKS5 needed only an address, so it will relay anything that runs over TCP: HTTP, HTTPS, SSH, SMTP, IMAP, a database wire protocol, a game client. An HTTP proxy needed an HTTP request or a CONNECT, so it carries HTTP, HTTPS, and whatever a client is willing to wrap in a CONNECT tunnel, provided the proxy allows that port.

What the proxy sees of HTTPS

With both protocols, an HTTPS request gives the proxy the same two things: the destination (a hostname and port in the CONNECT line or the SOCKS request, or an IP address if the client resolved the name first) and the encrypted stream, including how many bytes went each way and when. It does not get the URL path, the headers, the cookies or the response body. Those are inside TLS, negotiated between your client and the site, and the proxy holds no key to it. A proxy that tried to decrypt the stream would have to present its own certificate, which your client would reject unless you had installed that certificate yourself.

Plain HTTP is a different matter. An HTTP proxy reads every header and body as a matter of course, because it has to parse the request to forward it. A SOCKS5 proxy relaying plain HTTP has no need to parse the bytes, but it could; they are not encrypted. So the honest rule is this. On plain HTTP, the proxy operator's conduct is the only thing between the operator and your content, whichever protocol you use. On HTTPS, the operator sees destinations and byte counts, not content, whichever protocol you use.

What GhostConnect's network does with that is written on the privacy page: it keeps the destination and the response status code of each request, used to measure success rates so exits that stop working can be replaced, and nothing else. The address you connect from is not recorded, and on plain HTTP the content is not looked at. The two protocols get the same treatment.

DNS: who looks up the name

This is the difference that most often matters in practice, and it sits almost entirely on the client side.

With an HTTP proxy there is no choice to make. The client sends the hostname in the request line or the CONNECT target, and the proxy resolves it from wherever the proxy is. Your machine never asks its own resolver about the site.

With SOCKS5 the client decides. If it sends address type 3, the domain name, the proxy resolves it: remote DNS. If it resolves the name itself first and sends type 1 or type 4, two things happen that you may not want. Your own resolver, whether your ISP's or your office's, learns which site you are visiting even though the connection itself goes through the proxy. And the answer you get is the one chosen for your location, not the exit's, so a site that steers visitors to a regional server by DNS sends you to the wrong region, which can undo the point of choosing a country.

Tools name the two modes differently, and the names are easy to get backwards:

• curl: socks5:// resolves locally; socks5h:// hands the name to the proxy. The h is for hostname. The same split applies to --socks5 and --socks5-hostname; see the curl manual.
• Python requests, with the requests[socks] extra installed: the same two schemes, socks5:// and socks5h://, in the proxies dictionary.
• Firefox: a checkbox in the connection settings, "Proxy DNS when using SOCKS v5", which should be on.
• Chromium-based browsers: send the hostname to a SOCKS5 proxy by default, but do not send a username and password over SOCKS5 at all. With password authentication they need the HTTP port, or an IP allowlist on products that offer one.

Unless you have a reason not to, use remote DNS. The sticky sessions guide uses socks5h in its examples for exactly this reason.

UDP and everything that is not HTTP

SOCKS5 has a UDP ASSOCIATE command in the specification, which is why it is sometimes described as "the one that does UDP". In practice many SOCKS5 servers implement only CONNECT, and many clients never send UDP through a proxy even when the server would accept it. Treat UDP as unsupported on any proxy, including the ones sold here, until you have tested the exact application you need: DNS over UDP, QUIC and HTTP/3, voice and game traffic all fall under that. An HTTP proxy has no UDP story at all. A browser that cannot send QUIC through the proxy falls back to TCP with HTTP/1.1 or HTTP/2, which is what you want anyway.

For TCP protocols other than HTTP, SOCKS5 is the straightforward choice: point an SSH client, a mail client or a database client at the SOCKS5 port and it works, with no wrapping. Through an HTTP proxy the same thing is possible only if the client can issue a CONNECT to an arbitrary port and the proxy accepts it; some proxies do, some restrict tunnels to 443. Test before you depend on it.

Which GhostConnect products speak which

From the catalog, exactly as the product pages state it:

The residential gateway's second ports exist for networks that block the first; they behave identically. The rotating product is HTTP only, which includes HTTPS targets through CONNECT (the example on its product page fetches an https:// URL through it), but a non-HTTP protocol has no way in. If your crawl is HTTP, that costs you nothing; if you wanted to tunnel SSH over fresh IPv6 exits, this is not the product.

The choice of port changes nothing about the bill. Residential bandwidth is $2.99 per GB whichever port carries it: 5 GB costs $14.95 over HTTP and $14.95 over SOCKS5, and the usage graph on the dashboard does not distinguish them. The same credentials, including the targeting and session tags in the password, work on all four residential ports.

The same request both ways

With the documentation credentials from the API reference (they do not connect), a residential request pinned to Germany, first over HTTP and then over SOCKS5 with remote DNS:

curl -x http://residential.ghostconnect.com:1080 \
  -U 'rJxYKRe2U:Yxa5WGCUkvP9km_country-DE' \
  https://ifconfig.me

curl -x socks5h://residential.ghostconnect.com:1081 \
  -U 'rJxYKRe2U:Yxa5WGCUkvP9km_country-DE' \
  https://ifconfig.me

Python, with requests and the requests[socks] extra for the second form:

import requests

HOST = "residential.ghostconnect.com"
AUTH = "rJxYKRe2U:Yxa5WGCUkvP9km_country-DE"

http_proxy  = f"http://{AUTH}@{HOST}:1080"
socks_proxy = f"socks5h://{AUTH}@{HOST}:1081"

for proxy in (http_proxy, socks_proxy):
    r = requests.get("https://ifconfig.me", proxies={"http": proxy, "https": proxy}, timeout=30)
    print(r.text)

Both print a German address. Both carried the request through a tunnel the proxy could not read. The only difference the site could observe is none at all.

When the choice matters, and when it does not

It does not matter when you are fetching HTTPS pages with a client that supports both, which is the common case: curl, requests with the socks extra, Firefox and most crawling frameworks take either. Pick HTTP, because every tool supports it without extras, and move on. The configuration cookbook has the exact flags for each tool on both protocols.

It matters when:

• The protocol is not HTTP. SSH, mail, a database, a custom TCP protocol: SOCKS5.
• Your tool resolves names locally over SOCKS5. Switch to socks5h, turn on remote DNS, or use the HTTP port, where the question does not arise.
• Your tool only supports one. Scrapy speaks HTTP proxies out of the box and needs an extension for SOCKS. Chromium, and so Puppeteer and Playwright's Chromium, will not authenticate to SOCKS5 with a password. Use the port the tool can use.
• You are on plain HTTP and care what the proxy could read. The fix is HTTPS, not a different proxy protocol.
• You are buying rotating IPv6. HTTP only, by design.
• The first port is blocked where you are. Try the residential gateway's second port of the same kind before changing protocols.

What never changes with the protocol: the exit address the site sees, the country you targeted, the session behaviour, the price, and what the network records. Those are properties of the product and of the password tags, not of the handshake. For which product fits which job, see which proxy for which job.