Proxy Formats and How to Use Them in Your Tools

A proxy line is nothing more than four pieces of data serialized into a string. Once you can identify each piece, converting between formats is mechanical.

• Host — the endpoint hostname, <proxy-host>. Always the same.
• Port — 80 for HTTP, HTTPS, and SOCKS5 alike.
• Username — your generated proxy user. Targeting parameters (country, sticky session, TTL) are appended here as suffixes like -cc-US or -s-abc123.
• Password — your generated proxy password. It never changes with targeting; only the username carries parameters.

Conventions differ on ordering and separators. Some tools want credentials first, some want the host first, some want a full URL with a scheme prefix. The data is identical in every case.

Here is the same proxy written four ways. Learn to recognize these on sight — between them they cover nearly every tool you will meet.

user123:pass456@<proxy-host>:80
<proxy-host>:80:user123:pass456
http://user123:pass456@<proxy-host>:80
socks5://user123:pass456@<proxy-host>:80

• user:pass@host:port — the URL-style order without a scheme; common in config files and libraries that add the scheme themselves.
• host:port:user:pass — colon-delimited, popular with bulk proxy lists and Windows GUI tools that split on :.
• http://... URL — for tools that take a full proxy URL and tunnel HTTPS through it with CONNECT.
• socks5://... URL — same idea for SOCKS5; use this when the traffic is not plain HTTP or the tool prefers SOCKS.

curl takes a full proxy URL with the -x (or --proxy) flag. The scheme prefix selects the protocol.

# HTTP proxy (HTTPS targets tunnel via CONNECT)
curl -x "http://user123:pass456@<proxy-host>:80" https://example.com

# SOCKS5, with DNS resolved through the proxy
curl -x "socks5h://user123:pass456@<proxy-host>:80" https://example.com

The socks5h:// variant resolves hostnames on the proxy side rather than locally, which is usually what you want. A quick curl against a known site is also the fastest sanity check when another tool misbehaves — it isolates whether the credentials work at all.

The requests library takes a proxies dict mapping each scheme of the target URL to a proxy URL. Point both http and https at the same proxy.

import requests

proxy = "http://user123:pass456@<proxy-host>:80"
proxies = {"http": proxy, "https": proxy}

r = requests.get("https://example.com", proxies=proxies, timeout=30)
print(r.status_code, r.text[:200])

For SOCKS5, install the socks extra (pip install requests[socks]) and use socks5h:// as the scheme. Since rotation gives you a new IP per request by default, each requests.get exits from a different address unless you add a sticky-session suffix to the username.

Node's HTTP stack does not read proxy settings on its own; you attach a proxy agent to the request. The agent packages take the same proxy URL as curl.

// npm install https-proxy-agent   (or socks-proxy-agent for SOCKS5)
import { HttpsProxyAgent } from "https-proxy-agent";
import https from "node:https";

const agent = new HttpsProxyAgent("http://user123:pass456@<proxy-host>:80");

https.get("https://example.com", { agent }, (res) => {
  console.log(res.statusCode);
});

Most HTTP clients in the Node ecosystem accept an agent (or an equivalent proxy option) the same way — construct it once from the proxy URL and pass it per request or as a client default. For SOCKS5, swap in a SOCKS agent with a socks5:// URL.

Browsers do not take a proxy line directly; you enter the four fields separately. There are three common setups.

• OS-level settings — set <proxy-host> and port 80 in your system proxy configuration; the browser prompts for the username and password on first use. This affects most applications that respect system proxy settings, not just the browser.
• Proxy-switcher extension — lets you store credentials, switch proxies per tab or per rule, and turn the proxy off without touching system settings. Usually the most convenient option for browser work.
• Per-profile browsers — some browsers support a separate proxy configuration per profile; each profile takes the same host, port, and credential fields.

Some tools want a format none of the standard exports match — reversed fields, unusual separators, extra literals. The generator's custom template covers these: you write the line once using the variables {HOST}, {PORT}, {USER}, and {PASS}, and every generated line follows it.

Template:  {USER}|{PASS}|{HOST}|{PORT}
Output:    user123|pass456|<proxy-host>|80

Template:  socks5://{USER}:{PASS}@{HOST}:{PORT}
Output:    socks5://user123:pass456@<proxy-host>:80

Any targeting you selected — country, city, sticky session, TTL — is already baked into {USER} in the output, so the template only has to worry about ordering and separators. You can generate up to 50,000 lines at once and download them as a .txt file.

Format mistakes cause most first-connection failures. Before digging deeper, check the mechanical things.

• Field order: <proxy-host>:80:user123:pass456 pasted into a tool expecting user:pass@host:port will fail authentication with confusing errors.
• Scheme mismatch: a socks5:// URL given to a tool configured for HTTP proxying (or vice versa) typically fails to connect at all.
• Stale credentials: regenerating credentials in the dashboard invalidates the old ones everywhere — re-export your lists after a regeneration.
• Typos in username suffixes: a malformed targeting parameter like -cc-USA instead of -cc-US can reject the connection.

The built-in proxy checker tests your actual credentials with live results (IP, country, latency) and is the quickest way to separate a credential problem from a tool problem. For a systematic walkthrough of connection errors, timeouts, and geo mismatches, see troubleshooting proxies.