Proxy Authentication: Username and Password or IP Whitelist?

Proxy authentication is how a proxy server checks who is opening a connection and turns away anyone who isn’t allowed. There are two methods: with username and password, the client sends credentials on every connection; with an IP whitelist (IP allowlist), the proxy looks at the public IP address the connection comes from and accepts connections from listed addresses without a password.

Choose username and password if your IP address changes often or you use the proxy on more than one device. If your code runs on a server with a fixed IP, or the program you use has no password field, an IP whitelist is more practical. The examples use the WeProxy gateway address gw.weproxy.com.tr:8989; USER and PASSWORD are the credentials from your dashboard.

What is proxy authentication and how does it work?

A proxy has to know whose traffic it is carrying; an open proxy would let anyone push traffic through your package. That’s why authentication happens at the very start of the connection and is settled before any request reaches the target site.

For an HTTP proxy, the flow is defined in RFC 9110. If the client connects without credentials, the proxy returns a 407 Proxy Authentication Required response along with a Proxy-Authenticate header. The client then repeats the request with a Proxy-Authorization: Basic ... header. In the Basic scheme, user:password is only Base64-encoded, not encrypted (RFC 7617).

In SOCKS5, the client first lists the methods it supports (RFC 1928). 0x00 means no authentication and 0x02 means username/password. If the proxy picks 0x02, the username and password travel in plain text through the RFC 1929 subnegotiation. On a connection that uses an IP whitelist, the proxy accepts 0x00, since it has already made its decision based on the source IP.

An IP whitelist doesn’t depend on the protocol. The proxy compares the address the TCP connection comes from with the list saved in your dashboard. If the address is on the list, the connection goes through. If it isn’t, you’ll get a 407 over HTTP, and over SOCKS5 either a rejected method (0xFF) or a closed connection.

How do you use a proxy with a username and password?

The credentials are either added to the proxy address or typed into separate fields in the program. Both forms work in cURL:

curl -x "http://USER:[email protected]:8989" https://api.ipify.org
curl -x "http://gw.weproxy.com.tr:8989" -U "USER:PASSWORD" https://api.ipify.org

The main advantage of this method is portability. The same line works on your home connection, on mobile data, on a cloud server and on a coworker’s computer. Nothing needs to change when your outgoing IP changes. And because it no longer matters which device you connect from, sharing access within a team is easy.

The downside is that the password gets written down in many places. The proxy line gets into scripts, environment variables, antidetect profiles and sometimes logs. One shared screenshot or one config file pushed to a public repository is enough to open your package to someone else. In code, read the password from an environment variable, and strip the password from the URL before you share logs.

The second limit is that some programs don’t accept credentials at all. Chrome’s --proxy-server flag ignores the user:pass@ part, and Chrome doesn’t support SOCKS5 proxies with a username and password. The system proxy screens in Windows and Android only have host and port fields. For a password-protected proxy in the browser you can use the official extension; setup is on the Chrome integration page. If the password contains characters such as @ or :, it needs percent-encoding in URL form; the syntax rules are in the proxy formats guide.

What is an IP whitelist and how does it work?

With an IP whitelist, you save your own public IP address in the dashboard instead of using a password. The proxy accepts connections from that address without a password, and the proxy line shrinks to host:port:

curl -x "http://gw.weproxy.com.tr:8989" https://api.ipify.org

The address you save must not be your computer’s local address (192.168.x.x, 10.x.x.x). The proxy only sees the public address you use to reach the internet. You can find it on the device that will use the proxy, with the proxy turned off, by opening the My IP tool or from the command line:

curl https://api.ipify.org     # your public IPv4 address
curl https://api64.ipify.org   # your IPv6 address, if you have one

If your server connects to the gateway over IPv6, the list needs the IPv6 address; if you only saved the IPv4 address, the connection is refused. In cloud environments, the internal address of the machine running your code differs from the NAT address it uses to reach the internet. Always put the outbound (egress) address on the list.

With this method there are no credentials at all. There’s no password to leak, and programs without a password field can use the proxy too. The address, however, has to stay fixed. On a home connection the public IP changes when the router restarts, on mobile data when you switch cell towers, and with a VPN when the VPN server changes; after that, connections are refused.

Some internet providers and mobile carriers share one public IP among many subscribers through CGNAT. If you whitelist a shared address, everyone behind that address can connect to your package without a password. Only whitelist fixed addresses that belong to you.

Username/password vs IP whitelist compared

Authentication only affects speed on new connections. SOCKS5 with a username and password adds one extra round trip to every new connection, while an IP whitelist skips that step. On connections that stay open, you won’t notice the difference. The other differences between the protocols are covered in HTTP vs SOCKS5.

Which method should you choose in which situation?

Some teams use both methods side by side. Jobs on the server connect through the whitelist, and tests on a laptop connect with a username and password. If your product offers both methods, this setup keeps the password out of server files. Code examples for both methods in Python are in the Python proxy guide; Puppeteer setup is on the Puppeteer integration page.

Which method do WeProxy products use?

The available method depends on the product. Here is what the product pages say:

For other products, the method and supported protocols are listed in the technical specifications and FAQ sections of the product page. General questions are collected on the FAQ page. Credentials and whitelist settings are managed from your dashboard. Only add IP addresses that belong to you or that you have permission to use.

The target site’s IP whitelist: when you need a fixed outgoing IP

The word whitelist sometimes shows up in the opposite direction. A partner’s API, an admin panel or a payment service may only answer requests from registered IPs. In that case, you give them the outgoing IP the proxy assigns you; how you connect to the proxy doesn’t matter.

For this you need a product whose outgoing address doesn’t change. With a rotating proxy, the IP changes from request to request or when the session expires, so the other side’s list breaks at the first change. A static datacenter IPv4 proxy gives you a fixed IP dedicated to you, and the address stays the same for the whole package period. You connect to the proxy with a username and password, and the target service recognizes your fixed outgoing IP. The difference between static and rotating IP models is explained in the sticky vs rotating proxy guide, and the choice between datacenter and ISP proxies in ISP proxy vs datacenter proxy.

How do you fix a 407 error and whitelist problems?

Most authentication problems show up as 407 Proxy Authentication Required. In SOCKS5, the same problem usually appears as a connection that closes right away.

To check whether the line itself is correct regardless of the program, paste it into the proxy checker tool. If a line works in the checker but not in your program, the problem is in the program’s proxy settings. The proxy error codes guide explains which layer 407, 403, 429 and 502 come from. How to order a VPN and a proxy when you use them together is covered in proxy vs VPN.

Checklist for keeping proxy credentials safe

• Don’t write the password into your code repository; read it from an environment variable or a secrets manager.
• Strip the password from the URL before sending logs, error reports or support tickets.
• If you suspect the password has leaked, stop using it and request new credentials through the dashboard or the support team.
• Only whitelist fixed addresses that belong to you; don’t add home or mobile IPs behind CGNAT.
• Remove the IPs of servers you no longer use from the list. The address of a shut-down VPS may be given to another customer after a while.
• With an HTTP proxy, Basic credentials travel unencrypted as far as the proxy. For HTTPS targets the page content stays encrypted inside the CONNECT tunnel, but keep this in mind when using proxy credentials on networks you don’t trust.

Whichever method you choose, the target site’s terms of use, its robots.txt file, and GDPR and local data protection laws such as Türkiye’s KVKK still apply to what you do through the proxy. Permitted uses of WeProxy services are listed on the acceptable use page.