Proxy URL format that clients actually parse

Two shapes buyers mix up: gateway and raw IP

The single biggest formatting mistake has nothing to do with encoding. It is people pasting the wrong kind of line entirely, because Proxynade products ship in two different shapes and they are not interchangeable.

Rotating pool products (Volume Residential, Premium Residential, and Datacenter) connect through one shared gateway. The host is always proxynade.net, the port is always 2555, and the routing you want, plan, country, and rotation time, is encoded into the username with tokens. One username carries the whole instruction:

http://USER-plan-volume-country-us-lifetime-30:PASS@proxynade.net:2555
socks5h://USER-plan-premium-country-us-lifetime-30:PASS@proxynade.net:2555

Datacenter lines accept the lifetime token only on a sticky session. The password is never touched, and the country and lifetime tokens never get appended to it.

Static ISP is the opposite model. There is no gateway hostname: each order ships its own raw IP, a random port, and a unique user and password, all arriving with the order itself. You drop that exact line in, you do not build a username out of tokens:

socks5://USER:PASS@203.0.113.25:48211
http://USER:PASS@198.51.100.7:51904

Those IPs and ports are examples; yours come on the order. If you try to point a static ISP credential at proxynade.net:2555, or expand a static username with plan tokens, nothing connects, because the two products route in completely different ways.

Encode usernames and passwords

Because the credentials live inside the URL, any reserved URL character in them will confuse the parser. If your username or password contains a symbol, percent-encode it before it goes in the line. The four characters below are the ones that break proxy URLs most often.

Client examples

The same gateway line goes into each client a little differently. curl and Requests take the full credentialed URL, but Playwright splits authentication out into its own fields:

# curl
curl -x http://USER:PASS@proxynade.net:2555 https://example.com -I

# Python Requests
proxies = {
    'http': 'socks5h://USER:PASS@proxynade.net:2555',
    'https': 'socks5h://USER:PASS@proxynade.net:2555',
}

# Playwright
proxy: {
  server: 'http://proxynade.net:2555',
  username: process.env.PROXY_USER,
  password: process.env.PROXY_PASS
}

The Playwright shape is the one people trip on: server does not accept a credentialed URL, so the username and password have to move into their own keys. Several browser clients behave this way, which is why a line that works in curl can fail in automation until you split it.

IPv6 needs brackets

An IPv6 host is full of colons, so the parser cannot tell where the address ends and the port begins unless you wrap the host in square brackets. Add them and the line reads cleanly again:

http://USER:PASS@[2001:db8::10]:2555

This comes up most with raw static ISP lines that happen to be IPv6. When something looks malformed, test the exact proxy with curl first, then move the same pieces into the app rather than retyping them.

Parse the URL before using it

Have the app parse the line and print the pieces back, with the password redacted, before any request goes out. That one step catches encoding bugs while they are still cheap to fix:

const proxy = new URL(process.env.PROXY_URL);

console.log({
  protocol: proxy.protocol,
  username: proxy.username,
  passwordSet: proxy.password.length > 0,
  hostname: proxy.hostname,
  port: proxy.port
});

The output tells you exactly what went wrong. If hostname has swallowed part of the password, the credentials were not encoded. If port comes back empty, the line is missing its last separator or, on IPv6, its brackets.

Connection string checklist

When a line refuses to connect, walk this list before blaming the proxy itself:

• Always include a scheme.
• Encode username and password separately.
• Use brackets around IPv6 hosts.
• Keep full URLs out of Playwright server.
• Use socks5h when proxy-side DNS matters.
• Test the exact line with curl -x.

Watch your own config layer

Plenty of broken lines are damaged after they leave the dashboard, not before. Internal config systems that strip punctuation, lower-case fields, or split on colons will quietly mangle a proxy line, and the token-heavy gateway usernames are especially easy to wreck this way. Pick one storage format, either a full URL string or a set of structured fields, and do not bounce between the two unless you have tests covering the round trip.

For production, structured storage usually holds up best: keep scheme, host, port, username, password, and DNS mode as separate fields, then assemble the final URL only at the edge where the client library actually needs it.

Sharing a line with support

When support asks to see your proxy line, send a redacted version that keeps the structure intact, such as scheme://USER:PASS@host:port. That preserves everything they need to spot a parser mistake while handing over no secrets. Live credentials should never land in a ticket, a screenshot, or a shared chat log.

Proxy string FAQ

Is HTTPS target traffic possible through an HTTP proxy? Yes. The client uses CONNECT to reach the HTTPS target through the proxy.

Why does my password break the proxy URL? Reserved URL characters must be encoded. Raw @ and : are common failures.

Do all apps accept the full proxy URL? No. Some apps require separate host, port, username, and password fields.

What is the first test? Use curl -x with one small target before adding the line to a bigger app.