How does proxy IP authentication work, and when should you use user:pass?

Every paid proxy needs some way to tell its customers apart from the rest of the internet. There are two common answers. The proxy can look at where a connection comes from and compare it with a list (IP authentication, also called IP whitelisting or IP authorization). Or it can ask the client to send credentials with each connection (username and password, sent as a Proxy-Authorization header).

Most confusion comes from the first method, because the IP that counts isn’t the one your computer shows in its network settings. It’s your public IP, the address your router or cloud provider uses on the internet. Add the wrong one, or have it change overnight, and the proxy refuses you even though nothing in your tool changed.

This page explains how each method works, how they compare on security, how to find and keep your public IP, how dynamic DNS fixes changing home IPs, and why serverless and some cloud tools can’t use IP-authorized proxies at all.

• What the proxy checks. IP auth checks the source address of the TCP connection. User:pass checks a header your client sends; the source address doesn’t matter.
• Setup in tools. IP auth needs only IP:PORT, which every tool accepts. User:pass needs a tool that supports proxy credentials; some older tools and some browser settings dialogs don’t, or show a login popup.
• Where you can run. IP auth works only from addresses you’ve listed. User:pass works from anywhere: laptops on hotel Wi-Fi, containers, cloud functions.
• Sharing risk. With user:pass, anyone who sees the credentials can use your plan until you change them. With IP auth, nothing secret is in your scripts, config files or screenshots.
• Changes. A new home IP silently breaks IP auth until you update it. A leaked password needs a reset, but your IP changing doesn’t matter.

For most setups, IP authorization. Credentials for HTTP proxies are usually sent with the Basic scheme, which is base64 encoding, not encryption. Over a plain HTTP connection to the proxy, anyone who can watch that traffic can decode them. Credentials also tend to end up in places they shouldn’t: committed to a Git repository, pasted into a support ticket, stored in a shared browser profile.

IP authorization has no secret to leak. Its weak spot is shared addresses: if your office, campus or mobile carrier puts many people behind one public IP, everyone behind that IP can reach the gateway while it’s on your list. Authorize only addresses you control, remove old ones, and don’t authorize a public Wi-Fi network.

Whichever method you use, remember that the proxy credential protects access to the proxy, not your data. HTTPS sites stay encrypted end to end inside the CONNECT tunnel either way.

Most home and many office connections get their public IP from the provider, and it can change after a router restart or every few days. When it changes, IP-authorized proxies stop accepting you until you update the list.

Dynamic DNS fixes this. A free service such as No-IP gives you a hostname (for example yourname.ddns.net) and keeps it pointed at your current IP, either through a small update client on your computer or through the dynamic DNS setting many routers have built in. You authorize the hostname in the member area instead of the raw IP, and when your IP changes, the hostname follows.

Two details to know. Free No-IP hostnames must be confirmed every 30 days, and the update client doesn’t do that for you; miss it and the hostname stops resolving. And a hostname update still takes a little time to reach the gateways, so expect a short gap after an IP change.

This is where IP authorization stops working, and it’s better to know before you build. Serverless platforms (AWS Lambda, Google Cloud Functions, Vercel and similar), many CI runners and hosted notebooks send traffic from large, shared and changing address ranges. You can’t authorize “whatever IP this run gets”, and authorizing the whole range would let strangers use your plan.

The same goes for software that runs on the vendor’s own servers rather than on your machine, such as some cloud-based SEO tools and AI agents. The connection to the proxy comes from their infrastructure, not from you.

Two fixes work:

• Run the job from a server with a fixed IP. A small VPS has a static public IP that you authorize once. Your serverless code can call that server, or you move the scraper there.
• Use proxies with username:password. Storm’s private dedicated proxies support it, so they work from anywhere. They’re static IPs, so they suit lower-volume or per-account work rather than large-scale rotation.

Some cloud platforms can give outbound traffic a fixed address through a NAT gateway or static egress IP option. If yours does, authorize that address and keep using the rotating gateways.

For rotating and residential plans: IP authorization only, no username or password. You add the public IP (or a dynamic DNS hostname) under Authorized IPs, save, and wait up to 15 minutes. Residential packages allow one access IP per package.

For private dedicated proxies: your choice of IP authorization or username:password. Use user:pass when the tool runs on several machines or from changing IPs.

On Storm rotating and residential gateways, an IP that isn’t on the list doesn’t get a 407. The gateway accepts the connection and resets it, so tools report “connection reset”, “Connection aborted” or “socket hang up”. A real 407 means user:pass on a dedicated proxy or another proxy in the chain; the 407 error guide covers that case.