OS settings and a browser extension handle proxy setup manually, once — that fails for a script or a scraper, where the address must be wired in programmatically at the client, session and driver level, with error handling and a way to confirm the traffic went through.

Connection string format with authentication

A proxy address for code follows one scheme: protocol://login:password@host:port. The protocol sets the mode (http, https, socks5), login and password sit between a colon and @, then host and port follow. Client libraries and most browser drivers accept the whole string as one value, no separate parameters needed.

The password must not contain @ or other URL-reserved characters unencoded, or the parser cuts the string at the first special character and the connection goes out with broken credentials. Auto-generated credentials should be URL-encoded before insertion.

The difference between HTTP and SOCKS mode

HTTP mode works at the protocol level: the server reads the request and its headers. For HTTPS it decrypts nothing — it tunnels the encrypted TLS connection via CONNECT, so HTTP mode suits both http and https addresses despite the name.

SOCKS mode, almost always SOCKS5, sits a layer lower and does not parse the application protocol at all — it just relays bytes. SOCKS5 is transparent for HTTP and arbitrary TCP connections and, unlike HTTP mode, supports UDP — needed for DNS lookups and some libraries. Name resolution can be delegated to the same server, so the hostname never leaves in the clear via a local resolver — critical for geo-sensitive sites. HTTP mode usually covers scraping; SOCKS5 suits custom-protocol apps.

Setup at the client, session and browser driver level

An address can be set at three levels, not interchangeably. Request level — passed into every call separately, useful when rotating IPs per page. Session level — set once for a session or pool, and every request inside reuses one exit and the keep-alive connection, keeping the IP consistent for sites that check address continuity between login steps.

Driver level is trickier: the launch argument usually accepts only host and port, no credentials in the string. An authenticated channel needs a workaround — an extension that intercepts the auth dialog and fills in credentials, or a driver that intercepts network events and answers the browser's auth challenge programmatically. A walkthrough is in setting up a proxy for an antidetect browser.

Handling connection errors

Errors at the intermediary layer differ from errors on the target site — tell them apart by status code, not by the fact a request failed. Auth failure: a 407 instead of a site response means credentials or the connection string are wrong, or access expired; retrying unchanged is pointless. Timeouts and drops: the node stays silent or drops the session before a reply, so a sane timeout with paced retries helps, not an instant retry.

A 403, captcha or verification redirect from the target site is not a connection error but a sign the address is used up or fails a reputation check, so retrying with the same IP is pointless — swap the address. Telling a healthy address from a problem one in advance is covered in proxy quality metrics.

Confirming a request actually went through the proxy

Before the main scenario, hit any service that echoes the request's IP and compare it with the client's real address — one call that catches a config typo sending traffic directly instead.

Second, watch for headers a transparent relay can add: X-Forwarded-For or Via carrying the client's original address. Such a node leaks the real IP, so anonymity-sensitive tasks need an elite mode without these headers. Build this check into the rotation logic itself — more in rotating IPs via API.

For a browser driver the check is harder: the browser can bypass the route via WebRTC, opening a direct P2P connection that can leak the local, sometimes public, IP. If the scenario is sensitive to that, disable WebRTC with a separate launch flag rather than trusting the route alone.

Frequently Asked Questions

Can the same proxy serve both an HTTP client and a browser driver at once?

Technically yes, if the address type supports both modes, but in practice two separate connections are set up: retry logic and lifetimes differ between client and driver, and a shared exit for two processes raises the block risk from a matching request pattern.

Why does a proxy work in one HTTP client and fail in another with the same string?

Libraries parse the string differently and treat proxy environment variables differently — one reads them automatically, another needs the parameter explicit, a third ignores system settings. Pass the string explicitly when moving code between libraries.

Does the connection need closing manually after every request?

Not in session mode — it is reused by the pool and closes on an idle timeout or session close. Close it explicitly only when a scenario holds connections far longer than the task, otherwise it is easy to hit the concurrent-session limit.

Ready-to-use proxies with login and password for HTTP and SOCKS5, plus connection docs, are in the proxy section; request format and limits for integration are in the proxy API.