Proxy with Login and Password: How Username/Password Authentication Actually Works (2026 Guide)

If you have ever bought a proxy and been handed a line that looks like 171.22.30.14:8000:john123:s8Kd2p, you have already met username/password proxy authentication — even if nobody explained what the last two parts were for. This guide explains, in plain language, what "proxy with login and password" means, how it differs from IP authentication, why it matters for security and multi-accounting, and exactly how to set it up in browsers, antidetect tools, and code. No fluff, no vague theory — the stuff you actually need when a proxy won't connect at 2 a.m.

I have set up thousands of these across scraping jobs, ad-verification farms, and social media operations, so I will also cover the errors that waste the most time (407, silent failures, leaking your real IP) and how to fix them fast.

A proxy server sits between your device and the internet. When you connect through it, websites see the proxy's IP address instead of yours. But the proxy needs to know that you are allowed to use it — otherwise anyone who learned its address could route traffic through it for free (or for crime). There are two ways a proxy verifies you:

IP authentication (IP whitelisting): the proxy stores a list of approved IP addresses. If your connection comes from a listed IP, you are let in — no credentials asked.
Username/password authentication: the proxy asks for a login and password on every connection, regardless of where you connect from.

"Proxy with login and password" simply means the second type. It is the standard for paid residential, mobile, and ISP proxies, because it lets you use the same proxy from any device, any network, without reconfiguring anything on the provider's side.

The credential string, decoded

Most providers hand you proxies in one of these formats:

ip:port:username:password — e.g. 171.22.30.14:8000:john123:s8Kd2p
username:password@ip:port — e.g. john123:s8Kd2p@171.22.30.14:8000
Or as four separate fields in a dashboard: Host, Port, User, Pass.

They all carry the same four pieces of information:

Host / IP — the address of the proxy server (or a gateway hostname like gate.provider.com).
Port — the door on that server your traffic goes through (commonly 8000, 1080, 3128, or a per-session port).
Username — your identity on the proxy. With many residential providers this field also carries session and GEO parameters (more on that below).
Password — your secret. Anyone who has all four can use your proxy, so treat these like a bank login.

IP authentication vs login/password: which should you use?

This is the decision that trips up most beginners, so here is the honest comparison.

IP authenticationLogin & passwordWorks from any networkNo — only from whitelisted IPsYes — anywhereSetup frictionMust pre-register every IP you usePaste credentials, doneDynamic home IPBreaks when your IP changesUnaffectedMultiple devices / teamPainful — every device's IP must be listedEasy — share the credential stringAntidetect browsersOften unsupportedNative support everywhereSecurity if leakedAttacker also needs to be on your IPAttacker only needs the string — rotate it fast

Rule of thumb: if you work from a single server with a fixed IP, IP whitelisting is marginally more convenient. For literally everything else — home connections, laptops, antidetect browsers, teams, mobile work — username/password is the right choice, and it is why most proxy tooling assumes it by default.

Below are the four setups you will actually use, from simplest to most technical.

1. Antidetect browser (AdsPower, Dolphin Anty, Kameleo, Hidemium)

This is where most multi-accounting happens, and it is the easiest:

Open or create a browser profile.
Find the Proxy section of the profile settings.
Choose the protocol: SOCKS5 or HTTP(S) (use whatever your provider specifies; SOCKS5 is more flexible).
Fill the four fields: Host, Port, Username, Password.
Hit "Check proxy" / "Test." A good tool shows the resulting IP and country.
Save. Bind that profile to that proxy permanently.

One profile = one proxy = one identity. Never let two profiles share a proxy, and never let one profile touch two proxies.

2. Raw Chrome / Firefox (no extension)

Here is a catch that costs people hours: plain Chrome and Firefox proxy settings do not have fields for a proxy username and password. They can point to a host and port, but when the proxy demands credentials, the browser just throws a login popup on every request — unusable for real work. Your options:

Use a browser extension that supports authenticated proxies (many exist, including one-click connectors that store login/password proxy profiles).
Use an antidetect browser (above), which is built for this.
On desktop, wrap the proxy with a local tool that converts "login/password upstream" into a local no-auth proxy for the browser.

If you have ever wondered why your proxy "won't take the password" in vanilla Chrome — this is why. It is a browser limitation, not a broken proxy.

3. Python (requests / httpx / Scrapy)

For scraping, embed the credentials directly in the proxy URL:

import requests
proxy = "http://john123:s8Kd2p@171.22.30.14:8000"
resp = requests.get(
    "https://api.ipify.org?format=json",
    proxies={"http": proxy, "https": proxy},
    timeout=20,
)
print(resp.json())  # should show the proxy's IP, not yours

import requests
proxy = "http://john123:s8Kd2p@171.22.30.14:8000"
resp = requests.get(
    "https://api.ipify.org?format=json",
    proxies={"http": proxy, "https": proxy},
    timeout=20,
)
print(resp.json())  # should show the proxy's IP, not yours

For SOCKS5, install requests[socks] and use the socks5:// scheme:

proxy = "socks5://john123:s8Kd2p@171.22.30.14:1080"

proxy = "socks5://john123:s8Kd2p@171.22.30.14:1080"

4. curl (for quick testing)

curl -x http://john123:s8Kd2p@171.22.30.14:8000 https://api.ipify.org

curl -x http://john123:s8Kd2p@171.22.30.14:8000 https://api.ipify.org

If that returns the proxy's IP, your credentials work and the problem (if any) is in your app, not the proxy. This one-liner is the fastest way to isolate a bad proxy from a bad config.

Session control lives in the username (the part nobody tells you)

With residential and mobile proxies, the username field is often not just an identity — it is a control panel. Providers let you append parameters that decide which IP you get and for how long. The format varies, but it usually looks like:

username-country-US-session-abc123-sessTime-30

username-country-US-session-abc123-sessTime-30

Broken down:

country-US — GEO targeting: give me a United States IP.
session-abc123 — a sticky session ID: keep giving me the same IP as long as I use this ID.
sessTime-30 — hold that IP for 30 minutes.

Change the session ID and you get a fresh IP; keep it and the IP stays. This is how you make one "login and password" behave like a rotating pool or a static IP, on demand. Check your provider's docs for their exact syntax — but now you know what those weird-looking usernames are doing.

The errors that waste the most time (and their fixes)

407 Proxy Authentication Required

The proxy received your request but rejected (or never saw) your credentials. Causes, in order of likelihood:

Typo in username or password — copy-paste, do not type.
Credentials sent in the wrong place (e.g., host field contains the whole string).
Wrong protocol — you set HTTP but the proxy is SOCKS5, or vice versa.
Your plan expired or the sub-user was deleted.

It connects but shows your real IP

The proxy isn't actually being used. Usual causes: the tool silently fell back to a direct connection after a failed auth, or WebRTC is leaking your real IP around the proxy. Always verify with an IP checker, and enable WebRTC leak protection in your browser or extension.

Works in curl, fails in the browser

Classic vanilla-browser limitation (see section 2). Move to an extension or antidetect browser that supports authenticated proxies.

Random disconnects mid-session

Your sticky session expired (sessTime too short) or you didn't set a session ID at all, so the provider rotated your IP. Add or lengthen the session parameter.

Security: how not to get your proxies stolen

A login/password proxy is only as safe as the credentials. Practical hygiene:

Never hardcode credentials in code you push to GitHub. Proxy strings get scraped from public repos within minutes. Use environment variables.
Create sub-users if your provider supports them, so you can revoke one without resetting everything.
Rotate on suspicion. If a proxy behaves oddly (unexpected traffic, sudden bans), change the password immediately.
Match GEO to purpose. A US account logging in from a German IP is a red flag to the target site — the leak isn't technical, it's behavioral.

Where to get proxies that use login/password properly

Any serious paid provider offers username/password auth — it is table stakes. What actually varies is IP quality, session control, and whether you are locked into one network. After 2026's wave of provider shutdowns (PIA S5, 922, IP2World were dismantled in a single January takedown; 9Proxy went dark for weeks), the smart setup is a catalog with multiple independent networks on one balance, so a single provider dying never strands your work.

I run mine through ProxyUniverse — residential, mobile, and static ISP proxies that all come as standard host:port:login:password, work in every antidetect browser, and support GEO + sticky sessions through the username field exactly as described above. If you're rebuilding after a provider vanished, that's the setup I'd point you to.

Quick FAQ

Is a proxy with login and password safer than IP authentication? Different, not strictly safer. Login/password is more flexible and works anywhere; IP auth adds a second factor (you must also be on the right IP) but is rigid. For most people, login/password with good credential hygiene is the better tradeoff.

Why won't Chrome accept my proxy username and password? Vanilla Chrome has no fields for proxy credentials and only shows a popup per request. Use an extension that supports authenticated proxies or an antidetect browser.

Can I use one login/password proxy on many devices? Yes — that's the main advantage over IP whitelisting. Just don't run the same account (e.g., the same Instagram profile) from different IPs; that's a behavioral flag, separate from proxy auth.

What's the difference between SOCKS5 and HTTP for authenticated proxies? Both support username/password. SOCKS5 works at a lower level and handles any traffic type (not just web); HTTP(S) is web-oriented and slightly simpler. Use whatever your provider and tool support; SOCKS5 is the safer default for varied workloads.

That's the whole picture. Bookmark the curl one-liner — it will save you the next time a proxy "doesn't work" and you need to know whether it's the proxy or your setup. Questions? Drop them in the responses.

Contents

What "proxy with login and password" means