The line structure never changes
Every Proxynade proxy line follows the same shape: protocol://username:password@proxynade.net:2555. Host and port are fixed. The protocol and username carry the routing options.
The four protocol prefixes for the same gateway endpoint:
http://USERNAME:PASSWORD@proxynade.net:2555
https://USERNAME:PASSWORD@proxynade.net:2555
socks5://USERNAME:PASSWORD@proxynade.net:2555
socks5h://USERNAME:PASSWORD@proxynade.net:2555Treat the protocol as load-bearing, not decoration. socks5h resolves DNS through the proxy side (RFC 1928). Plain socks5 may resolve locally, depending on the library. Swapping one for the other silently changes the DNS path, which changes which IP the target sees.
The username encodes your routing options
The dashboard generates a username that carries the plan, optional country, and optional rotation window in sequence. The structure:
| Token | Values | Required |
|---|---|---|
| Base username | Your account identifier, e.g. rt97db6958d9 | Yes |
| Plan token | volume, premium, or datacenter | Yes |
| Country | country-us, country-gb, etc. (lowercase ISO 3166-1 alpha-2) | No |
| Rotation window | lifetime-<minutes>, e.g. lifetime-30 | Residential only |
A volume residential line targeting the US with a 10-minute sticky window looks like: rt97db6958d9-plan-volume-country-us-lifetime-10. A datacenter line for the same account skips lifetime: rt97db6958d9-plan-datacenter-country-us.
Copy the full generated username without editing tokens. One missing segment changes the route silently — there is no error at connection time, just different behavior.
Field splitting is where lines break
The most common mismatch: the dashboard generates a correct line, but the application does not run it. This happens when apps split the proxy into separate fields — host, port, username, password — and rebuild the URL at runtime.
A worker that takes separate fields and reconstructs the username from a plain PROXY_USER env var loses every token past the base username. The curl test passes. The worker sees a different route.
Check the value the application actually sent, not what the dashboard generated. The proxy line in your env var, config file, or Playwright launch option is the value that matters. If an app splits the line into fields, split the generated value the same way without altering tokens.
When the client takes a single URL, paste the complete generated string. Do not change the protocol, drop username tokens, or swap the port.
Test the exact line inside the real application
Curl passing proves the credentials reach the gateway. It does not prove the application sends the same URL. Run one request through the real application before scaling.
Check both sides after that single request: the application result and the provider usage log. The usage log in the dashboard shows host, outcome, latency, and byte totals. If no matching row appears after the request, the application sent a different line or no proxy at all.
One request is enough to confirm the wire. Scale after both sides agree.
App bytes and provider bytes will not match
An application log showing 40 MB saved against a provider bill showing more traffic is normal, not a billing error.
Provider logs count bytes at the wire: redirects, blocked responses, retries, page assets, and bodies the application fetched but discarded before writing anything. A browser-based worker makes this gap larger — the page may pull scripts, fonts, tracking calls, and error pages while the application records one result row.
Application logs count what reached business logic: kept rows, parsed JSON, saved screenshots, final bodies. The two numbers measure different things.
A log row that separates the two clearly prevents most bandwidth arguments: worker=collector-07 status=403 outcome=blocked app_result=discarded_body is a blocked response. worker=browser-12 status=200 bytes=982113 app_result=screenshot_saved is a screenshot job pulling assets. Same proxy, different cost profiles.
Reference: MDN: 403 Forbidden.
Minimum fields worth logging per request
Keep enough fields to reconstruct what happened without guessing. Status code and outcome first, then bytes and latency, then the plan token, worker ID, and application result. The exact proxy line or at least its plan and country tokens should appear in the row so failures can be reproduced.
outcome=ok with app_result=discarded_body is not an authentication problem. High bytes with a successful screenshot may be fine. A fast blocked page is a different issue. Without per-request fields, every failed batch looks like the same vague proxy complaint.
Proxy line FAQ
What is the base format for a Proxynade proxy line? protocol://username:password@proxynade.net:2555 — host and port never change; the username carries routing options.
What tokens go in the username? Base username, then plan token (volume, premium, or datacenter), then optional country-<cc>, then optional lifetime-<minutes> for residential plans. Datacenter lines skip the lifetime token.
Does the protocol in the URL matter? Yes. http, socks5, and socks5h reach the same gateway port but behave differently for DNS resolution and credential handling. Swapping protocol silently changes routing.
Why does provider bandwidth exceed what my app recorded? Provider logs count bytes at the wire: redirects, blocked pages, retries, and assets your app discarded. App logs count what survived to business logic.
How do I confirm a generated line works before scaling? Run the exact line inside the real application, not just curl. Check that the provider usage log shows a matching request before scaling.
Generation checklist
- Copy the full generated line without editing tokens.
- Confirm the application runs the same URL curl tested, not a reconstructed one.
- Check the provider usage log after one request before scaling.
- Log status, outcome, bytes, and app result per request.
- Treat app bytes and provider bytes as measuring different things.