Choosing an HTTP Proxy: Protocol, Auth and Connection Behavior

HTTP proxy basics that decide a fit: the CONNECT tunnel, per-connection rotation, authentication format and concurrency accounting.

An HTTP proxy connection that works in curl can still be the wrong fit, because transport support and operating behavior are different questions. This guide covers what "HTTP proxy" actually commits you to: how it carries HTTPS traffic, how authentication is sent, when the exit changes, and how to count what you are paying for.

TL;DR

An HTTP proxy carries HTTPS traffic through an HTTP CONNECT tunnel; both the proxy and your client need to support that.
Plain HTTP gets a new exit per request on a rotating gateway; an HTTPS CONNECT tunnel or a SOCKS5 connection holds one exit for its whole life, so a keep-alive client reuses an exit across many requests.
Authentication format differs by product: static datacenter sends none at all, rotating sends a username with an optional empty password, and residential sends neither.
A concurrent-connection limit, a request count and a data allowance measure three different things; do not substitute one for another.

Why protocol support isn't the whole answer

HTTP proxy support tells you how your client reaches the proxy. It does not tell you whether the exit stays fixed, how a target responds, or what counts against your plan's limit. Those are the decisions this guide walks through; for whether HTTP or SOCKS5 is the right transport for your client in the first place, see HTTP vs SOCKS5 and the cross-vendor SOCKS5 availability comparison, which this guide does not repeat.

What decides an HTTP proxy fit

CONNECT support: Confirm your client issues an HTTP CONNECT request for HTTPS destinations and that the proxy answers it; a proxy that only relays plain HTTP cannot carry HTTPS traffic through the same path.
Authentication format: Match the credential shape (none, username only, username and password) to the product. Copying another product's username syntax produces a silent authentication failure, not a helpful error.
Rotation boundary: Establish whether the exit changes per request, per connection, or on a sticky-session timer. A keep-alive HTTP client behaves differently from a one-shot script against the same gateway.
Concurrency accounting: Check whether a limit applies to simultaneous connections, requests, or transferred data; those units are not interchangeable.
Target-level validation: Evaluate the returned content, not just the connection result. A successful CONNECT tunnel does not prove a successful collection job.

HTTP proxy options at a glance

Product	Authentication	Exit boundary on HTTP	Billing unit
Datacenter	Register the source IP; connect with no credentials	Fixed for the life of the plan	Per IP, per month
Shared	Register the source IP; connect with no credentials	Fixed, shared with other customers	Per proxy, per month
Rotating Datacenter	Username with an empty password for targeting, or nothing for an untargeted exit	New exit per plain-HTTP request; one exit per HTTPS CONNECT tunnel; sticky session up to 30 minutes on a session id	Per GB
Rotating Unmetered	Same as Rotating Datacenter	Same exit boundary as Rotating Datacenter	Per concurrent connection
Residential	No username and no password for an untargeted exit; credentials required only to target country, state, city or a session	Best-effort, up to 30 minutes on a session id	Per GB

Protocol support does not erase these differences. You can configure an HTTP client correctly and still choose the wrong product for the authentication model or the exit boundary your job needs.

The CONNECT tunnel is what makes HTTPS work through an HTTP proxy

An HTTP proxy reaches an HTTPS destination by opening a CONNECT tunnel: your client asks the proxy to open a raw connection to the target, then runs TLS end to end through it. The proxy never sees the decrypted traffic; it only relays bytes once the tunnel is open. Confirm your library actually does this rather than attempting plaintext HTTP against an https:// URL, which fails differently depending on the client.

: "${PROXY_URL:?Set PROXY_URL to your proxy endpoint}"
: "${TARGET_URL:?Set an authorized HTTPS destination}"

curl --silent --show-error \
  --proxy "$PROXY_URL" \
  --connect-timeout 10 \
  --max-time 30 \
  --write-out 'proxy_connect=%{http_connect} http_status=%{http_code}\n' \
  --output response.body \
  "$TARGET_URL"

proxy_connect is the gateway's own reply to the CONNECT request, separate from http_status, which is the destination's answer after the tunnel opened. A proxy_connect failure is a proxy-side problem; a http_status failure happened past the tunnel, at the target.

Exit boundary depends on keep-alive, not just the product

On Node4's rotating gateway, plain HTTP gets a new exit for each request, because the upstream transport disables keep-alive on that path. An HTTPS CONNECT tunnel or a SOCKS5 connection gets one exit for the life of that connection, so a client that reuses connections (requests.Session, most browsers, Node's default HTTP agent) will see the same exit across many requests inside one tunnel. Neither behavior is "every request" or "every connection" universally; it depends on which path your client takes. Read the full mechanism in how long a rotating proxy keeps the same IP address before assuming either default.

A sticky session id overrides both defaults and holds one exit for up to 30 minutes from first assignment on the rotating gateway, regardless of request volume. Track the assignment time, not the latest request, when planning a task boundary.

Authentication format is product-specific, not protocol-specific

HTTP as a protocol does not dictate one authentication shape; Node4's products use three different ones, and sending the wrong shape authenticates against the wrong targeting, not a generic error:

Static datacenter (shared, dedicated): register the source IP and connect with no username or password at all.
Rotating (Rotating Datacenter, Rotating Unmetered): send nothing for an untargeted exit, or the username with an empty password to keep country or session targeting without the secret.
Residential: send no username and no password for an untargeted, freely rotating exit. Anything that targets a country, state, city or session authenticates with credentials instead.

Do not reuse one product's username syntax on another; the gateway parses it differently and the failure looks like a routing problem rather than an authentication one.

Concurrency, requests and data are three separate limits

A concurrent-connection limit caps how many tunnels can be open at once; it says nothing about how fast you can open and close them. A per-GB plan caps transferred data regardless of connection count. Per-plan thread numbers are fair-use guidance, not an enforced ceiling, so do not advertise or plan around them as a hard cap. Count open connections in your own client rather than assuming one worker equals one connection; a pooled HTTP client or a browser can hold more than one connection per logical task.

Test before expanding the job

Use the same acceptance workflow for every candidate product. Separate the CONNECT result, the destination's answer, and your application's content check, so a failure has one clear cause.

HTTP 407: proxy authentication was not accepted. Check the credential format against the product table above before changing anything else.
HTTP 403: the destination refused the request past the tunnel. This does not by itself say whether the cause was the exit address, permissions, or application behavior.
HTTP 200 with the wrong content: inspect the body. A login page or an empty template can arrive inside a successful status.
Connection errors: separate name resolution, TCP connection, proxy CONNECT negotiation, and TLS failures before retrying anything.

Which HTTP proxy product should you choose?

Start from the authentication format and exit boundary your application can support, then pick the product that matches. A script with no session state fits static datacenter or untargeted rotating access; a workflow that needs the same exit for a sequence of steps needs a sticky session id; a connection-managed worker pool fits Rotating Unmetered. Compare plans once the shape is settled.

FAQ

Are HTTP proxies compatible with HTTPS websites?

Yes, through an HTTP CONNECT tunnel: the client asks the proxy to open a raw connection to the destination, then runs TLS through it end to end. Confirm your library issues CONNECT for https:// URLs rather than assuming it does.

Does every HTTP request get a different IP?

Not necessarily. On Node4's rotating gateway, plain HTTP gets a new exit per request, but an HTTPS CONNECT tunnel or a SOCKS5 connection holds one exit for the life of that connection, so a keep-alive client reuses it across requests.

Do I need a username and password for an HTTP proxy?

It depends on the product. Static datacenter proxies use IP registration with no credentials; rotating and residential proxies need credentials only when you are targeting a country, state, city or session, not for an untargeted exit.

Does a concurrent-connection limit also cap my data transfer?

No. A connection limit and a data allowance are separate measures. Rotating Unmetered caps connections with no byte meter; Rotating Datacenter caps data with no connection limit of its own.

How long does a sticky session hold the same exit?

On Node4's rotating gateway, up to 30 minutes from first assignment, regardless of how many requests you send in that window.

Should I use HTTP or SOCKS5?

It depends on what your client needs to tunnel. See HTTP vs SOCKS5 for the protocol-level trade-off; this guide covers configuring and testing the HTTP path once you have chosen it.