Key Takeaways

• Two authentication methods exist: username and password sent with every request, or a static IP whitelisted in advance.
• User:Pass is the flexible option – it works on any network, even when your IP changes, but credentials can leak.
• IP whitelisting is more secure for a fixed setup, but breaks immediately if your ISP changes your IP.
• The choice comes down to one question: is this running from a static server, or a local and dynamic connection?
• Several GoProxies tutorials already show working authentication code in Puppeteer, Playwright, and cURL.

Every residential proxy needs one of two authentication methods: credentials sent with every request, or a trusted static IP registered in advance. Here's exactly how each works and which one fits your setup.

How Proxy Authentication Works

Proxy authentication is how a provider confirms that a request reaching its gateway belongs to a paying customer, not to anyone who happened to find the hostname.

That matters more than it sounds. A residential proxy endpoint is a publicly reachable address, and without authentication anyone who learned it could route traffic through your allocation and spend your bandwidth. Every provider therefore requires proof of identity on connection, and the industry has settled on two ways of supplying it: something you know, sent with each request, or somewhere you are, registered ahead of time.

Both methods authorize the same traffic to the same pool. What differs is where the credential lives, what breaks when circumstances change, and what an attacker gets if something leaks.

User:Pass Authentication

With User:Pass authentication, you send a username and password in the connection header on every request, typically embedded in the proxy URL as http://username:password@host:port.

This setup suits mobile users, remote teams, dynamic home networks, and cloud scrapers whose outbound IP changes frequently. Many providers also carry targeting parameters in the username string – country, city, or a session identifier appended to the base username – which means the credential does double duty as a configuration channel.

Best for: anything running from a connection you don't control or can't predict.

Pros:

• Works from any network: Move between office, home, and a coffee shop, and nothing needs updating.
• Survives IP changes: A dynamic ISP reassignment doesn't interrupt anything.
• Carries targeting parameters: Geo and session settings travel with the credential rather than living in a separate config.

Cons:

• Credentials can leak: A password committed to a repository, pasted into a ticket, or baked into a container image lets anyone drain your traffic allocation.
• Secrets management becomes your problem: Environment variables and a secrets store, not hardcoded strings.

For working implementations, see setting up authentication with Puppeteer and authenticating a proxy with cURL.

Whitelisted IP Authentication

With IP whitelisting, you register a trusted static IP address in your provider's dashboard, and the proxy accepts traffic only from that address. No password travels with the request at all.

This fits dedicated office networks, data centers, and cloud servers with a fixed public IP – any environment where the source address is stable and under your control.

Best for: static infrastructure with a known, unchanging egress IP.

Pros:

• Nothing to steal: There's no credential in your code, so there's no credential to leak.
• Cleaner configuration: No secrets management, no rotation policy, no password in the proxy URL.
• Simpler once running: Configure it once in the dashboard and the code stays plain.

Cons:

• Breaks the moment your IP changes: An unannounced ISP reassignment takes your pipeline offline with no warning, and the resulting error doesn't obviously point to the cause.
• Poor fit for anything dynamic: Mobile work, remote teams, and ephemeral cloud functions all fail this requirement.
• Adds a step to scaling: Every new server needs registering before it can send a single request, which is friction that shows up exactly when you're in a hurry.

Which Should You Use?

One question settles it: is this running from a static server or IP, or from a local machine or connection that could change?

Static setup – office network, data center, fixed cloud server – whitelist the IP. You skip credential-leak risk entirely, and your code stays free of secrets.

Anything dynamic – mobile use, remote teams, cloud functions that spin up on different addresses – use User:Pass. Whitelisting would break the first time the IP shifted, and on a home connection that's a question of when rather than whether.

Plenty of teams run both: whitelisting for production servers, credentials for local development. There's no rule against it, and it maps neatly onto how the two environments actually differ.

When Authentication Fails

Three failure modes account for nearly all authentication problems, and each looks different enough to diagnose on sight.

• A 407 on every request: The proxy rejected your credentials outright. Usually the username or password is wrong or missing, but with correct credentials the most common cause is a special character breaking URL parsing. An @ in your password is the classic offender: it terminates the credential section early, so the parser reads everything after it as a hostname. Percent-encode @,:, /, and # in both the username and password before embedding them. Worth knowing that credentials are account-wide – if one proxy returns a 407, every proxy will, so check the credential rather than debugging the endpoint.
• Everything worked yesterday, and nothing works today: This is the whitelisting failure. Your ISP reassigned your address overnight; the registered IP no longer matches, and the proxy is refusing traffic from a stranger. Check your current public IP against what's registered before checking anything else.
• Authentication succeeds locally but fails in production: Almost always an environment problem rather than a proxy one. The secret didn't make it into the deployment, or the container is reading an empty variable and sending an empty password. An empty credential produces the same 407 as a wrong one, which is why this takes longer to find than it should.

Authentication is also a setup-stage decision that pairs with rotation intervals, since sticky sessions are configured through the same username string that carries your credentials.

Where GoProxies Fits

GoProxies supports username and password authentication, and its own tutorials show it working in practice – credential-based setups in Puppeteer, Playwright, and cURL, with targeting and session parameters passed through the username string.

That's the method that fits most scraping work, since scrapers frequently run from cloud environments where the outbound address isn't fixed. GoProxies' rotating residential proxies cover 30M+ IPs across 200+ locations with ISP, ASN, country, state, and city targeting, all configured through the same credential string rather than a separate interface.