Proxy Authentication: IP Whitelisting vs Username/Password
Every proxy service requires authentication -- a way to verify that the person sending requests is an authorized customer, not a random stranger piggybacking on the infrastructure. The two dominant authentication methods are IP whitelisting (sometimes called IP authorization) and username/password (sometimes called credential-based authentication). Each has distinct security properties, convenience trade-offs, and operational implications.
This guide covers both methods in technical detail, provides configuration examples for common tools, and gives you a clear framework for choosing the right one. For reference, see our proxy authentication glossary entry and network authentication methods page.
How IP Whitelisting Works
IP whitelisting authentication is based on your source IP address. You register one or more IP addresses with your proxy provider, and the proxy gateway accepts connections only from those addresses. No username or password is required.
The Authentication Flow
1. You register your server IP (e.g., 203.0.113.50) with Hex Proxies.
2. Your server connects to gate.hexproxies.com:8080.
3. The gateway checks the incoming connection's source IP.
4. Source IP matches whitelist → connection accepted.
5. Source IP not on whitelist → connection rejected.Configuration Example
With IP whitelisting, your proxy configuration contains no credentials:
import requests
# No username/password needed — your server's IP is pre-authorized
proxy = {
"http": "http://gate.hexproxies.com:8080",
"https": "http://gate.hexproxies.com:8080",
}
response = requests.get("https://httpbin.org/ip", proxies=proxy, timeout=15)
print(response.json())# cURL with IP whitelisting — no -U flag needed
curl -x gate.hexproxies.com:8080 https://httpbin.org/ipAdvantages of IP Whitelisting
No credentials in code. Your proxy configuration files, scripts, and environment variables do not contain any secrets. If your code repository is accidentally exposed, no proxy credentials are compromised.
Simpler configuration. Tools that have limited proxy authentication support (some older browsers, network appliances, IoT devices) can use IP-whitelisted proxies without any special credential handling.
No credential rotation overhead. You never need to rotate passwords, update API keys, or synchronize credentials across multiple servers.
Faster connection setup. The gateway can authorize the connection during the TCP handshake based on the source IP, without waiting for an HTTP Proxy-Authorization header. This saves one round-trip in some implementations.
Limitations of IP Whitelisting
Static IP required. Your server must have a fixed, public IP address. This excludes home connections with dynamic IPs, mobile networks, and many cloud functions (Lambda, Cloud Functions) that use ephemeral IPs.
One IP change = dashboard visit. Every time your server IP changes (infrastructure migration, new cloud instance, ISP reassignment), you must update the whitelist. If you forget, your proxy access breaks silently.
Shared environments are problematic. If you run code from a shared server, VPN, or coworking network, other users on the same public IP could theoretically use your proxy access. This is rare but worth noting for security-sensitive deployments.
Multi-location complexity. If you run scrapers from 10 different servers, you need all 10 IPs whitelisted. Managing this list becomes an operational burden as your infrastructure grows.
How Username/Password Authentication Works
Username/password authentication uses HTTP's standard Proxy-Authorization header. Your proxy client sends credentials with each connection attempt, and the gateway verifies them against your account.
The Authentication Flow
1. Your application connects to gate.hexproxies.com:8080.
2. Your application sends: Proxy-Authorization: Basic base64(user:pass)
3. The gateway decodes and verifies the credentials.
4. Credentials valid → connection accepted.
5. Credentials invalid → 407 Proxy Authentication Required.Configuration Example
import requests
# Credentials embedded in the proxy URL
proxy = {
"http": "http://myuser:mypass123@gate.hexproxies.com:8080",
"https": "http://myuser:mypass123@gate.hexproxies.com:8080",
}
response = requests.get("https://httpbin.org/ip", proxies=proxy, timeout=15)
print(response.json())# cURL with username/password
curl -x http://myuser:mypass123@gate.hexproxies.com:8080 https://httpbin.org/ip
# Or using -U flag
curl -x gate.hexproxies.com:8080 -U myuser:mypass123 https://httpbin.org/ip// Node.js with axios
const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent('http://myuser:mypass123@gate.hexproxies.com:8080');
const response = await axios.get('https://httpbin.org/ip', { httpsAgent: agent });Advantages of Username/Password
Works from any IP. You can connect from your office, home, a coffee shop, a cloud function, or a mobile device. The gateway does not care where the connection originates — only that the credentials are correct.
Dynamic infrastructure friendly. Serverless functions, auto-scaling groups, Kubernetes pods, and CI/CD runners all get new IPs frequently. Credential-based auth works seamlessly in these environments without whitelist management.
Session control through username parameters. Many proxy providers (including Hex Proxies) encode session and targeting parameters in the username field. For example: myuser-session-abc123-country-us:mypass123. This powerful feature is only available with credential-based authentication.
Multi-user support. You can create separate credentials for different team members, projects, or clients. Each set of credentials can have its own usage limits, access controls, and billing allocation.
Immediate access. No whitelist configuration needed. Generate credentials, paste them into your code, and start making requests.
Limitations of Username/Password
Credentials in code. Your proxy username and password must exist somewhere your application can read them. If stored in source code, configuration files, or environment variables, they can be leaked through repository exposure, log files, or error messages.
Credential management overhead. Best practices require regular password rotation, secure storage (environment variables or secret managers), and access controls around who can view the credentials.
Proxy-Authorization header exposure. In HTTP (non-HTTPS) connections to the proxy, the credentials traverse the network in Base64 encoding (which is trivially decodable). Always use HTTPS connections to the proxy gateway to protect credentials in transit.
Security Comparison
| Security Aspect | IP Whitelisting | Username/Password |
|---|---|---|
| Credential exposure risk | None (no credentials exist) | Moderate (credentials in code/config) |
| Works from compromised network | No (attacker needs your IP) | Yes (attacker only needs credentials) |
| Lateral movement risk | Low (tied to specific IP) | Higher (credentials can be used from anywhere) |
| Audit trail | IP-based (limited) | User-based (detailed) |
| Revocation speed | Instant (remove IP from whitelist) | Instant (change password) |
| Shared environment risk | High (same IP = same access) | Low (credentials are individual) |
Which Is More Secure?
Neither method is inherently more secure — the answer depends on your threat model.
IP whitelisting is more secure when:
- You have a stable, dedicated server with a fixed IP.
- Your primary risk is credential leakage (code repo exposure, phishing).
- You want zero secrets in your codebase.
Username/password is more secure when:
- You operate in a shared hosting environment where others share your public IP.
- You need granular per-user access control and audit trails.
- Your primary risk is IP spoofing or network-level attacks.
For most production deployments, the best approach combines both: use username/password authentication for flexibility, and store credentials in a secret manager (AWS Secrets Manager, HashiCorp Vault, or at minimum, environment variables) rather than in code.
Configuration Best Practices
For IP Whitelisting
1. Use a dedicated IP. Ensure your server has a static, dedicated public IP. Shared IPs (from NAT, load balancers, or shared hosting) introduce risk because other users on the same IP inherit your proxy access.
2. Whitelist the minimum set of IPs. Only add IPs that genuinely need proxy access. Remove IPs for decommissioned servers promptly.
3. Monitor your whitelisted IPs. Set up alerts for when a whitelisted IP changes or goes offline. Cloud providers sometimes reassign IPs during maintenance.
4. Document your whitelist. Maintain a record of which IP belongs to which server and purpose. When something breaks at 2am, you need to know which IP to check.
For Username/Password
1. Never hardcode credentials.
# WRONG: Credentials in source code
proxy = "http://myuser:mypass123@gate.hexproxies.com:8080"
# RIGHT: Credentials from environment variables
import os
proxy_user = os.environ["PROXY_USER"]
proxy_pass = os.environ["PROXY_PASS"]
proxy = f"http://{proxy_user}:{proxy_pass}@gate.hexproxies.com:8080"2. Use separate credentials per project. If one project's credentials are compromised, only that project's access is affected.
3. Rotate credentials periodically. Change passwords quarterly or after any team member departure.
4. Use HTTPS connections to the gateway. This encrypts the Proxy-Authorization header in transit, preventing network-level credential interception.
5. Exclude proxy URLs from logs. Configure your logging framework to redact proxy URLs, which contain embedded credentials.
import logging
# Redact proxy credentials from log output
class ProxyRedactFilter(logging.Filter):
def filter(self, record):
record.msg = re.sub(
r'http://[^:]+:[^@]+@',
'http://***:***@',
str(record.msg)
)
return TrueChoosing the Right Method: Decision Matrix
| Your Situation | Recommended Method |
|---|---|
| Dedicated server with static IP | IP whitelisting |
| Cloud functions / serverless | Username/password |
| Multiple team members need access | Username/password |
| CI/CD pipeline with dynamic runners | Username/password |
| Home connection with dynamic IP | Username/password |
| Security-sensitive environment (no secrets in code) | IP whitelisting |
| Need session/geo parameters in proxy URL | Username/password |
| Simple setup, single server, minimal management | IP whitelisting |
| Kubernetes / auto-scaling infrastructure | Username/password |
Using Both Methods Together
Some proxy providers, including Hex Proxies, support using both methods simultaneously. You whitelist your server IP and use credentials. The gateway requires both to match before accepting the connection. This provides defense in depth: an attacker needs both stolen credentials and access from your whitelisted IP.
# Double authentication: IP must be whitelisted AND credentials must be valid
proxy = {
"http": "http://myuser:mypass123@gate.hexproxies.com:8080",
"https": "http://myuser:mypass123@gate.hexproxies.com:8080",
}
# Connection only succeeds if the source IP is also whitelistedThis combined approach is recommended for production deployments handling sensitive workloads.
Frequently Asked Questions
Can I use both IP whitelisting and username/password at the same time?
Yes. Hex Proxies supports dual authentication where both the source IP and credentials must be valid. This is the most secure configuration for production deployments. Configure your whitelisted IPs in the dashboard and include credentials in your proxy URL.
What happens if my IP changes while using IP whitelisting?
Your proxy connections will be rejected immediately. You will see connection refused or 403 errors. Log into your Hex Proxies dashboard, update the whitelisted IP, and connections will resume within seconds. For environments where IP changes are frequent, username/password authentication is the better choice.
Are proxy credentials sent in plain text?
The Proxy-Authorization header uses Base64 encoding, which is not encryption. If you connect to the proxy gateway over plain HTTP, the credentials are visible to anyone monitoring the network. Always connect to the proxy gateway over HTTPS to encrypt the credential exchange.
How many IPs can I whitelist?
Hex Proxies allows up to 50 whitelisted IPs per account. For deployments requiring more IPs, contact support for an enterprise plan, or switch to username/password authentication which has no IP limitation.
Which method has less latency?
IP whitelisting is marginally faster (1-5ms) because the gateway can authorize the connection at the network level without waiting for HTTP headers. In practice, this difference is negligible compared to the total request latency through the proxy.
Ready to configure proxy authentication for your project? Explore our ISP proxy plans with unlimited bandwidth and flexible auth options, or check out residential proxy plans with credential-based session control. Visit our authentication methods documentation for gateway-specific configuration details.