A proxy port does not accept a connection without authorization — otherwise anyone who learned the address and port could use it. Providers offer two ways to tell the port "this is mine": a fixed login-password pair, or the client's external IP added to a whitelist. The methods are not interchangeable: each has its own failure mode, leak point, and convenience for team work.
How both methods work
A login-password pair is sent inside the connection request itself — either in the proxy URL (login:password@host:port) or as a separate authorization header. The port checks the pair on every connection, regardless of origin. This is a classic "who are you" check tied to credentials, not to origin.
An IP whitelist works differently: the port already holds a list of external addresses allowed to connect without a password. The check is not "who are you" but "where are you from" — it compares the IP the TCP request arrived from. If the client's address does not match an entry on the list, the connection is rejected before any authorization attempt.
When an IP whitelist is more convenient
A whitelist saves time wherever the client's external address is stable: a dedicated server, an office channel with a static IP, a cloud VPS. Add the address once in your account, and every script connects without a password afterward, which simplifies configs and removes the risk of accidentally committing a credential pair to a repository. Before relying on a whitelist, it is worth confirming the channel itself holds stable metrics — otherwise a stable address can mask a degrading connection.
There is exactly one downside, but it is fatal: if the server's external IP changes — a reboot, a datacenter move, a plan change with the carrier — the whitelist stops recognizing the client instantly and without warning. The script gets a connection refusal rather than an authorization error, which is harder to diagnose: the code looks fine, the proxy looks paid for, and traffic simply does not flow.
When login-password is mandatory
A dynamic external address makes a whitelist useless in principle. Home internet reconnecting over DHCP, mobile access, a laptop going online from a new place every day — the client's IP changes faster than the list in the provider's account could be updated. Login-password is the only working method here: authorization does not depend on where the request physically came from.
The second case is many machines sharing one set of credentials. When several employees or servers with unpredictable addresses work through the same proxy, adding every IP to a whitelist by hand is inefficient, and with autoscaling cloud infrastructure it is outright impossible. The same logic applies to teams running accounts through an antidetect browser: each employee has their own profile and IP, so pinning a whitelist entry per person makes no sense.
The risk of a leaked login-password pair
Login-password has a weak point a whitelist does not: the credential pair is a secret that can leak — in application logs during debugging, in shell history, in a public repository from an accidentally committed config, in chat messages when access is handed to a colleague. Whoever obtains the pair can connect from any IP — the proxy checks only whether the correct password was given, not where the request came from.
A whitelist is more resilient here: even if someone learns the proxy's address and port, they cannot connect without their own external IP on the list. There is no secret to copy and carry away — only a binding to infrastructure an outsider does not control.
What to choose for team work
A mixed approach is usually more precise than one universal answer. For stable server infrastructure, use a whitelist: fewer secrets in configs, lower leak risk. For mobile or home access, test environments, and API integrations, use login-password — but rotate it: a pair shared in chat or used in a test should be changed, not left valid indefinitely. Which method a port supports can be checked in your account when the address is issued.
Frequently Asked Questions
Can both methods be used on the same port at once?
A port usually applies one scheme, set when the address is issued, but nothing stops you from keeping several ports for different scenarios: whitelist for servers, login-password for mobile tasks.
Why did the proxy suddenly stop letting me in with no code changes?
Usually the client's external IP changed while it was on the whitelist. Check the server's current outbound address and compare it with the list in your account; a hosting provider can reassign it after a reboot or migration.
Which is safer to keep in a config — a password or a whitelist?
If the infrastructure is stable, a whitelist is safer: no secret stays in the config to copy. If the client's address changes, login-password is unavoidable — store it in environment variables or a secrets manager, not in plain text.
Choose the authentication type and set up access in the proxy section. The same page shows which channels support a whitelist and which are issued only with login-password — worth checking before payment, not after the first refusal.