Username/password authentication lets you log in to a proxy via credentials instead of binding your IP. If you are new to the topic, start with proxy authentication methods and access options to see all models and how they differ.
What is username/password proxy authentication?
Credential auth is a login method where the proxy verifies a username and password on each connection instead of trusting your source IP. It is also called "proxy authorization" “username/password auth”, “credential auth”, “HTTP Basic proxy auth”, or “login-based auth”.
In practice, the client sends credentials during the proxy handshake. With HTTP(S) proxies this happens via the Proxy-Authorization header; with SOCKS the username and password are negotiated in the initial greeting. Because access is tied to credentials, you can connect from different networks or machines without changing any IP allowlists.
Protocol quick look
- HTTP/HTTPS:
The client retries the request with Proxy-Authorization: Basic <base64(username:password)> after a 407 Proxy Authentication Required challenge. Most HTTP stacks do this automatically once you set the proxy credentials. - SOCKS4/5:
SOCKS5 supports username/password auth in its handshake. SOCKS4a typically has no auth; use SOCKS5 for credentials.
When to choose credentials over IP allowlists
Choose credential auth when your team travels, uses cloud runners, or frequently changes egress IPs. IP allowlists fit stable environments with fixed addresses.
Credential auth reduces coordination friction: there is no ticket to “add my new IP,” and CI runners or mobile links “just work.” IP allowlists can be preferable in tightly locked-down networks or where auditors require source-IP binding.
How providers pack options into the username
Many vendors encode routing and session options inside the username, so you can change behavior without new accounts. Typical fields include country or city codes, desired ISP label, rotation parameters, and TTL.
For rotation mechanics and sticky session specifics, see the section on static vs rotating proxies for session parameters.
Common patterns
| Purpose | Example in username | Meaning |
| Country selection | ...+cc=US | Egress through US IPs |
| City targeting | ...+city=la | Prefer Los Angeles nodes |
| ISP label | ...+isp=comcast | Use an ISP-labeled range (if available) |
| Sticky session | ...+session=abc123 | Keep the same IP while session is alive |
| Rotation by time | ...+ttl=600 | Hold IP for 600 seconds, then rotate |
| Rotation by request | ...+rotate=1 | Force change on next request |
| Pool or plan | ...+pool=premium | Select a specific IP pool tier |
The exact syntax varies. Some providers use separators like ;, _, or -, and some fold options into the password instead.
Need a refresher on how location selectors work and what “depth of geo” means? See proxy IP geolocation targeting for city/ASN granularity, fallbacks, and typical caveats.
Credential hygiene and scoping
Treat proxy credentials like API keys. Rotate them periodically, store them in your secrets manager, and avoid hard-coding in repositories. Prefer one account per bot, worker group, or microservice so you can revoke access surgically and monitor per-user consumption.
A clean separation of credentials also clarifies ownership: if “scraper-east-01” burns an IP range or hits rate limits, you immediately know which process to fix without interrupting unrelated workflows.
Provider limits and anti-resale policies
Login-based access is easy to share, which is why vendors guard it. Expect limits such as:
- Max concurrent users/devices per account (for example, up to 3 active users).
- Thread, connection, or request ceilings applied per username.
- Tighter rate or region scopes to prevent multi-tenant reselling.
If you legitimately need to fan out across a large team, ask for multi-user licensing or per-worker credentials tied to your plan, not ad-hoc credential sharing.
Setup examples
cURL over HTTP proxy
curl -x http://username:[email protected]:8080 https://ipinfo.io/json
cURL over SOCKS5 proxy with credentials
curl --socks5-hostname username:[email protected]:1080 https://ipinfo.io/json
Node.js (Axios) with HTTP proxy auth
const axios = require('axios');
const instance = axios.create({
proxy: {
host: 'proxy.example.com',
port: 8080,
auth: { username: 'user+cc=US+session=abc123', password: 'pass' }
},
timeout: 15000
});
const { data } = await instance.get('https://ipinfo.io/json');
console.log(data);
Python (Requests) with HTTP proxy auth
import requests
proxies = {
"http": "http://user+ttl=600:[email protected]:8080",
"https": "http://user+ttl=600:[email protected]:8080",
}
r = requests.get("https://ipinfo.io/json", proxies=proxies, timeout=15)
print(r.json())
Tip: when testing, verify the public IP and location from the target service you care about, not with ICMP ping.
Failure modes to expect
Credential auth introduces a few predictable pitfalls. Knowing the symptoms helps you fix them quickly.
Wrong username syntax. If options are mis-typed, the proxy may ignore them or reject the login. Start with a minimal username, then add options one by one.
Mixed HTTP/SOCKS confusion. Your app might only accept HTTP proxies while your account is SOCKS-only, or vice versa. Match protocol to product.
Interactive prompts in headless tools. Some CLIs prompt for a password if you omit it, which stalls automation. Always pass credentials explicitly via env vars or config.
Session stickiness surprises. Forgetting to change session or ttl can “stick” you to one IP longer than intended. If you need a new IP, switch the session token or lower TTL. For how rotation vs stickiness behaves in different products, read the rotating/static overview linked above.
Pros and cons
| Aspect | Username/Password Auth |
| Setup from changing networks | Excellent; no IP allowlist updates |
| Multi-device use | Easy, but often capped by provider |
| Access revocation | Immediate per credential |
| Risk profile | Credentials can leak if not managed properly |
| Fine-grained control | High, via per-user options in username |
| Vendor posture | Stricter limits due to resale/abuse risk |
FAQs
Can I use the same credentials on multiple servers at once?
Usually yes, but providers may cap concurrent users or threads. If you need broad concurrency, request additional usernames rather than sharing one.
Why did my IP not change after I switched regions in the username?
The option may be wrong, your plan may not include that region, or stickiness is holding the session. Verify the option syntax, confirm plan coverage, and change the session token or TTL.
Do I have to base64-encode the username and password manually?
No for HTTP. Your HTTP client will add Proxy-Authorization automatically when you supply credentials. With SOCKS, the library handles the handshake once you set the auth.
Is credential auth more “secure” than IP allowlists?
They solve different problems. Credentials are flexible and revocable, while IP allowlists reduce exposure if secrets leak. Pick based on your workflows and compliance rules.
What are the common synonyms for this method?
Username/password auth, credential auth, HTTP Basic proxy auth, login-based auth.