IP Authentication for Proxies: Which Address to Allow and When to Use It
IP authentication lets you use a proxy from an approved connection address. You add that address to the provider’s access list, and your application connects without a separate proxy username and password. Providers commonly call this a whitelist, an allowlist, or a list of authorized IP addresses.
This method is useful when an application runs from a stable network, such as a server with a fixed public IP. But the address to allow is the one the application connects from, not the address of the proxy you bought. These addresses are easy to confuse during setup.
For a comparison of access methods, see Proxy Authentication. This guide explains which source IP to allow, how several devices share access, and what to check after a network change.
How a proxy checks an allowed IP
When a connection arrives, the proxy sees its source IP and checks it against the permitted addresses. If it matches and the service’s other requirements are met, the proxy accepts the request. With IP authentication alone, you do not need to send a proxy password. A service can also combine an address check with other access requirements.
Consider a home computer that connects to the internet through a router.
| Address type | Example | Its role |
|---|---|---|
| Computer’s local IP | 192.168.1.20 | Used inside the home network. The external proxy does not see it in this example. |
| Home connection’s public IP | 198.51.100.24 | The connection reaches the proxy from this address. This is the one to allow. |
| Proxy connection address | 203.0.113.80 | Entered in the application’s proxy settings together with the port. |
| Proxy exit IP | 203.0.113.90 | Seen by the website as the source of the connection from the proxy. |
A proxy’s connection address and exit IP may be the same or different. Neither replaces the client’s IP in the access list. Buying a proxy with a static exit IP does not make your home address permanent either.
The same principle applies to a proxy inside a local network: it checks the connection source it can see. That source may be a private address. For a commercial proxy on the internet, you normally need your network’s public outbound address.
When IP authentication is useful
On a server with a fixed outbound address, you can authorize the address once and use the proxies in several of your processes. You do not have to store a proxy password in every configuration, distribute it between applications, or update every copy when it changes.
In a managed office, several computers may share one public IP. A single entry can authorize that network’s outbound address if the service permits this use. The network administrator remains responsible for controlling access within the office.
Another case is an application that supports the required proxy protocol but cannot send a username and password using the method offered. IP authentication may solve that particular problem. It will not add HTTP, SOCKS5, or any other missing capability to the application.
How to find the IP to add
Check the address from the environment where the application will run. For a browser on your home computer, you can open the IP address lookup page without using the proxy being configured. If you open it through that proxy, you will see the proxy’s exit address and may add the wrong IP to the list.
If a script runs on a VPS, you need the VPS’s outbound address, not the address of the home computer you use to manage it. In a cloud environment, a server or container may send traffic through a shared NAT gateway. The gateway’s public address is then the relevant one; it may differ from the address you use to log in to the server.
With a VPN, pay attention to the route. If the connection to the proxy goes through the VPN, the proxy sees the VPN’s exit address. With split routing, a browser and a script may use different exits. A browser lookup therefore confirms only the route it tested; provider connection logs, where available, can help establish the source directly.
IPv4 and IPv6 are separate addresses. Allowing an IPv4 address does not automatically allow an IPv6 connection. Check which version the access list accepts and which address the application uses to reach the proxy. This is separate from the version of the proxy’s exit IP that the website will see.
At ProxyCompass, use the public IPv4 address from the lookup, even if it also shows IPv6. In the service card, open IP Whitelist → Manage, paste the IPv4 address into the add field, and click Add IP. After configuring the list, click Save and wait about three minutes for the access rule to take effect. Then test a new connection through the proxy.
How many allowed IPs do several devices need?
Count the different source addresses from which connections reach the proxy. The number of computers and the number of purchased proxies may be quite different.
For example, eight office computers sharing one public outbound address may use a single entry. A home computer and a VPS with different outbound addresses need two allowed addresses to work at the same time. If only one entry is available, replacing the home IP with the VPS IP does not grant simultaneous access to both sources.
Conversely, if an entry applies to the whole order, connecting from one server to twenty proxies does not require twenty client IPs. Allowed source addresses, the number of proxies in an order, and the concurrent connection limit are separate service settings.
Before buying, check the number of available entries and the conditions for adding or replacing them. Several networks may require extra entries, a shared managed exit, or another authentication method if the service allows it. A shared exit needs maintenance and adds another component whose availability affects the task.
In the ProxyCompass example shown, the package allows 1500 simultaneous connections. The value 750 next to an IP is the limit for connections from that client address, not the number currently open. The two addresses receive 750 each; use the sliders to change the split, for example to 1000 for the first and 500 for the second. Devices behind one public IP share that IP’s allocation.
Adding another IP to the whitelist does not increase the package’s total connection limit. The article on concurrent connection limits explains how this limit affects parallel tasks and reused connections.
How to set up access and check the result
- Identify the outbound IP from the working environment and add it to the correct service’s list. Make sure you have selected the order or proxy group the application will use.
- Obtain the connection address, port, protocol, and access mode for IP authentication from the provider. Enter them in the application. Leave the username and password fields empty only for a mode that actually works without them.
- Allow the rule to take effect according to the service’s instructions. A panel or API response confirming that an entry was saved does not always mean every node is already using the rule. There is no universal waiting period.
- Open a new connection from the working application and make a small request through the proxy. Compare the exit IP with the expected result and confirm that the application has not silently switched to a direct connection. Then start the main task.
A test from another computer or a remote service arrives from another source IP. Rejecting that tester may mean the access restriction is working correctly. It does not, by itself, show that the proxy is faulty.
What happens when your IP or network changes?
If your ISP assigns a new address, a laptop switches to mobile internet, or the VPN exit changes, new connections may arrive from an IP that is not on the list. The proxies themselves may still be working: the client’s access condition has changed.
A brief internet interruption does not necessarily change the IP. Check the current address and compare it with the allowed entry first. If it is unchanged, investigate network availability, application settings, or service status. Existing connections may still need to be restored after a network interruption.
If the address changes often, consider the work involved in maintaining access. A fixed public IP, a stable server exit, or automatic list updates through an API may help where these options are available. Automation must account for the rule’s application time and limit retries. An API key used to change settings is a separate secret, even when the proxy connection uses no password.
Do not keep an old address “just in case” after you lose control of it: it may later be assigned to someone else. Revoke its permission using the service’s controls. Whether revocation ends existing connections depends on the implementation.
What the IP list protects, and how to manage it
If someone learns only a proxy’s address and port, source checking prevents them from connecting from a network that is not allowed. This helps protect against use of a leaked proxy list. However, it operates within the service’s rules and does not replace protection of the computers and gateways that are allowed.
A public IP does not prove a person’s identity. Different employees may use one office exit, while CGNAT—address sharing at the internet provider—can place different subscribers behind one public IP. If access depends only on that IP, the proxy cannot distinguish them using that rule. Allow addresses only when you understand who can use them.
Removing a shared IP blocks that source for everyone; it cannot revoke just one employee’s access while keeping the others connected. Individual access control needs additional measures. Before allowing an entire subnet, check who can connect from it and whether the service also requires credentials.
IP authentication does not itself encrypt traffic or make the exit IP unrecognizable as a proxy. Data protection depends on the connections used, and network behavior or other signals may still reveal information about the proxy. Having no password in the settings means neither that access is uncontrolled nor that traffic is encrypted.
Why IP access may fail
| What happens | What to check first |
|---|---|
| It works at home but not on a VPS | The VPS’s outbound IP and whether it is on the list. The home address does not authorize a different source. |
| It stopped working after a network or VPN change | Whether the source address reaching the proxy has changed. |
| The IP was added, but the connection did not work immediately | The selected service, the exact address, whether the rule has taken effect, and the new connection’s settings. |
An HTTP proxy returns 407 or the application asks for a password | The access mode, port, and provider requirements. The code requests proxy authentication; it does not explain why the expected IP access failed. |
| The connection times out | Address and port reachability, network restrictions, and connection logs. A timeout alone cannot identify an IP list problem. |
| One website refuses access while others open | Who returned the refusal and whether the request used the proxy. For example, a website’s 403 response does not, by itself, prove a proxy authentication problem. |
The 407 code belongs to HTTP. SOCKS5 has its own replies and error messages; you do not need to look for an HTTP code in them. Useful details for support include the attempt time, outbound IP, proxy address and port, selected protocol, and exact error message.
When to choose IP authentication
This method suits an application with a stable, controlled outbound connection when the whole working environment needs access and you want to avoid distributing a password to each process. Before choosing it, confirm that there are enough allowed entries for every location and that you can update the list if the network changes.
If addresses change frequently, staff work from different networks, or access must be revoked individually, consider other authentication methods and the service’s additional restrictions. The decision depends on who will connect and from where, rather than how many addresses are in the proxy list you bought.