Short answers
What is the difference between an HTTP proxy and a SOCKS5 proxy?
An HTTP proxy handles HTTP requests and can open CONNECT tunnels for HTTPS. SOCKS5 negotiates a destination address and port before relaying application traffic. The SOCKS5 specification also includes UDP, but support must be confirmed for both client and service.
Does an HTTP proxy work with HTTPS?
Yes. The client asks the HTTP gateway for a CONNECT tunnel and then establishes TLS with the destination through it. Keep destination certificate verification enabled. The HTTP scheme for the gateway does not mean that the destination request uses plain HTTP.
Is SOCKS5 faster than HTTP?
The protocol name does not establish which route is faster. Compare a representative permitted workload with the same client, endpoint and settings. DNS, connection reuse, network conditions and destination processing can all affect the result; we have no protocol speed benchmark to promise.
Can SOCKS5 carry UDP?
RFC 1928 defines UDP ASSOCIATE. That does not establish support in a particular gateway or application. The checks on this page use TCP; they provide no evidence for UDP or QUIC support.
What does the h in socks5h mean?
In curl, socks5h:// sends the destination hostname to the proxy for resolution; socks5:// resolves it locally. Other clients can use different configuration syntax. Proxy-side resolution does not prove where the DNS resolver is located or how a website will classify the exit.
Which port do I use here?
HTTP on 7000 and SOCKS5 on 7001, with the same username and password on both. The username carries the pool, the country, the rotation mode and any session name, so switching protocol changes nothing about your targeting.
Which one should I pick?
Start with HTTP for a browser or HTTP client that supports authenticated HTTP proxies. Consider SOCKS5 when your client and permitted workflow need it. Check authentication support separately: Chrome supports SOCKS5 routing but does not support SOCKS5 authentication.
Ready to choose a connection? The HTTP buying page and SOCKS5 buying page cover client compatibility, the two shared pools and current GB prices. This guide explains the protocol differences behind that choice.
What “HTTP SOCKS proxy” and “HTTPS SOCKS proxy” mean
Proxy names mix two separate things. HTTP and SOCKS5 name the protocol your client speaks to the gateway, and so the port it connects to. HTTPS usually names the destination: an https:// website whose TLS runs from your client to the site through either kind of proxy.
| Name you see | What it usually means | What to use here |
|---|---|---|
| HTTP SOCKS proxy, or HTTP/SOCKS proxy | One service that accepts both protocols. | The same username and password on either port |
| HTTPS SOCKS proxy, or SOCKS5 for HTTPS | SOCKS5 carrying https:// requests. TLS still runs from your client to the website. | The SOCKS5 port 7001, on the SOCKS5 proxy page |
HTTPS proxy, or an HTTPS_PROXY setting | The proxy for https:// destinations. For this gateway its address starts with http://. | The HTTP port 7000; the HTTP proxy page explains the name |
A proxy URL starting with https:// | TLS between your client and the proxy itself, a separate setting from an HTTPS destination. | The scheme the connection builder prints |
In our local curl 8.7.1 checks, an HTTPS request completed with certificate verification through an HTTP proxy port and through a SOCKS5 port. An https:// proxy URL pointed at a plain-HTTP proxy port failed in the TLS handshake with the proxy, before any CONNECT was sent.
How an HTTP proxy handles a request
For a plain http:// URL the client sends the whole absolute address in the request line and the proxy makes the request on its behalf. It is an HTTP participant: it can read and add headers, and it answers with its own status codes, which is why an authentication failure arrives as 407 rather than as a broken socket.
For an https:// URL the client first asks for a CONNECT tunnel. After a successful response, it establishes TLS with the destination. A tunnel refusal and a destination HTTP error happen at different stages. The CONNECT specification describes this transition.
CONNECT exposes the destination host or address and port to the gateway. In an ordinary tunnel, with correct certificate verification and no trusted TLS interception, HTTPS protects the request path, headers and body. It does not conceal connection metadata. An HTTP gateway connection does not encrypt Basic proxy credentials before the tunnel opens.
How SOCKS5 handles the same request
SOCKS5 is a small binary negotiation, once per connection: the client offers authentication methods, the server picks one, the client sends a user name and password if that was chosen, then names the target host and port. After the reply, the socket is a plain pipe.
SOCKS5 can relay TCP protocols beyond HTTP, but this is a protocol capability, not a promise that every service permits every destination or port. RFC 1928 also defines UDP association. Confirm application support, gateway support and permitted use before relying on either.
SOCKS negotiation errors use binary reply codes, not HTTP 407. A later HTTP request carried through a SOCKS connection can still receive an HTTP error from its destination. Username/password authentication does not encrypt the SOCKS connection: RFC 1929 describes that exchange. Use HTTPS for HTTPS destinations and preserve certificate verification.
What actually changes when you switch
| HTTP proxy (7000) | SOCKS5 (7001) | |
|---|---|---|
| Connection | Forwards HTTP or opens a CONNECT tunnel | Negotiates a destination before relaying traffic |
| Scope here | HTTP gateway carrying an HTTPS request | TCP relay carrying an HTTPS request; UDP untested |
| Authentication | Basic credentials in a Proxy-Authorization header | User name and password inside the SOCKS5 handshake |
| Failure reporting | Separate CONNECT and destination status codes | SOCKS negotiation error, then any application response |
| Destination DNS in curl | Gateway resolves a hostname supplied in the request | Local with socks5://, proxy-side with socks5h:// |
| Dependencies | Check your HTTP client’s proxy interface | Some clients require an optional SOCKS dependency |
| Chrome authentication | HTTP proxy authentication is supported | SOCKS5 authentication is not supported |
Chrome’s proxy documentation distinguishes routing from authentication support. For a username/password proxy in a Chromium workflow, start with the HTTP port and the client’s separate proxy credential fields. Use the Playwright guide for a page-navigation check; a working curl request does not configure the browser.
Check both protocols with curl
Use an interactive sh, bash or zsh terminal. The examples below reuse the bounded checks from the curl guide. Replace every complete sample username with the complete value from the connection builder, choosing currently available settings. To compare protocols, use the same pool, country and rotation settings in both blocks; the illustrative usernames printed below differ.
This block runs two separate checks. Each prompts for the raw proxy password; leave it out of the command and URL. The second check prints the CONNECT and destination statuses without the response body.
# Replace USERNAME with the account part shown in the dashboard.
# Enter the password at each curl prompt; leave it out of the command.
curl --disable --silent --show-error --noproxy '' --connect-timeout 5 --max-time 15 -x "http://gw.portproof.org:7000" \
--proxy-user "USERNAME-mbl-us-rot-auto10" \
https://api.portproof.org/v1/echo-ip
# record tunnel and destination statuses separately
curl --disable --silent --show-error --noproxy '' --connect-timeout 5 --max-time 15 -o /dev/null -w 'connect=%{http_connect} target=%{response_code}\n' \
-x "http://gw.portproof.org:7000" \
--proxy-user "USERNAME-mbl-us-rot-auto10" \
https://api.portproof.org/v1/echo-ipThis is another request and another password prompt. Keep the same complete generated username when comparing protocols. Proxy-side DNS is selected by the socks5h scheme.
curl --disable --silent --show-error --noproxy '' --connect-timeout 5 --max-time 15 -x "socks5h://gw.portproof.org:7001" \
--proxy-user "USERNAME-peer-nl-rot-ondemand" \
https://api.portproof.org/v1/echo-ipThe five-second connection and fifteen-second transfer limits do not time password entry. The commands do not follow redirects. --disable skips curl’s default configuration file, and --noproxy clears exclusions for this check; confirm that the explicit route matches your intended network configuration. A password environment variable expanded into an argument can still expose the value through process inspection.
Check the expected HTTP response and JSON content, not just curl’s exit code. A failed CONNECT has no destination response; target=000 is a missing-status marker. A successful echo reports the address seen for that request, not the outcome of another website request. Tests use traffic, so keep them small. For application integration, use the complete Requests or Node.js fetch examples.
DNS is the part people get wrong
When curl sends a destination hostname to an HTTP gateway, the gateway resolves it. With curl’s SOCKS settings, socks5:// resolves the destination locally and socks5h:// asks the proxy to resolve it. This spelling is a client convention, not a universal SOCKS configuration interface. Check the curl reference before transferring an option to another tool.
Local and proxy-side DNS can return different addresses, but proxy-side resolution does not prove that the resolver sits in the exit country. It also does not set a browser’s language, cookies, account region or location permissions. For regional QA, record these separately and inspect the application result. The search results guide explains other inputs that can affect a regional check.
Choosing in practice
- Headless browsers and browser profiles: the HTTP port. Credentials go in the separate username and password fields, never in the server address.
- Python, Node, Go and Java HTTP clients: check the supported proxy interface and use the complete example for that client. SOCKS may need another dependency.
- A permitted non-HTTP TCP workflow: consider SOCKS5 only after checking destination, port and authentication support on both sides.
- A workflow needing proxy-side DNS: choose a client that can pass the hostname to the proxy. Changing a URL scheme cannot add support to a client that lacks it.
- Unsure: start on the HTTP port, prove it with the curl testing guide, then change one thing at a time.
The protocol is independent of everything else you choose. The same username selects mobile 4G/5G or residential, the country and the rotation mode, on either port, and both draw on the same balance at the same price per GB. The full token table and more snippets are on the setup docs.
What is not allowed
Use either protocol for authorised research, monitoring and QA. Protocol support does not grant access to a destination or permit scanning, credential attacks or prohibited mail traffic. See the acceptable-use policy.