IP Authentication

IP authentication lets you use a proxy from an approved source IP address without supplying a proxy username and password. The service compares the address your connection comes from with its list of permitted addresses, often called an allowlist or whitelist.

For a comparison with login-based access, see Proxy Authentication. This article explains which IP to allow, how to connect, and what changes when you use several networks or machines.

What IP authentication checks

When you buy proxies, the addresses you receive are the destinations your application connects to. The address you add to the allowlist is normally the public IP from which you connect to those proxies. Copying an address from your purchased proxy list into this field usually authorizes the wrong source.

There are three different roles:

• Client source IP: the address the proxy sees on your incoming connection. This is the address relevant to IP-based access.
• Proxy endpoint: the host or IP and port entered in your application.
• Proxy exit IP: the address from which the proxy connects to the target website.

A static proxy may use the same IP for its endpoint and exit, but your source address is still a separate part of the connection. A fixed proxy IP does not make your home internet address fixed.

On a home or office network using NAT, the proxy usually sees the network's public outgoing address rather than your computer's private address. For a proxy inside your own network, the visible source can instead be a private address.

Providers may call this feature IP authentication, IP whitelisting, allowlisting, or IP binding. Its purpose is to permit a network source; it does not identify an individual person or application behind that source.

When IP authentication is useful

A server with a stable outgoing IP is a good fit. Once that address is permitted, scheduled jobs can use the proxy without carrying a proxy password in every script or configuration file. There is one less secret to distribute when you add another application on the same server.

An office with a controlled internet gateway can use the same approach for several machines. Access follows the approved network, so moving a task between computers on that network may require no change to the proxy allowlist.

It can also suit software that supports the required proxy protocol but cannot supply the authentication method the proxy expects. IP-based access removes that particular requirement. The application must still support the proxy protocol and connect to the correct endpoint.

The practical advantage is simpler access management when your outgoing addresses are stable and under your control. Frequently changing networks and the need to identify each user separately make this arrangement less convenient.

Which IP address to add

Determine the outgoing address from the environment that will run the application. If the job runs on a VPS, checking your home computer's IP does not establish the VPS's source address. The same distinction matters for containers and cloud workloads that send traffic through a gateway.

A public IP lookup should use a direct connection from that environment, without the proxy you are configuring. A lookup made through the proxy reports its exit address. If available, the provider's connection log gives a more direct answer: the source address it actually received.

Three common complications are worth distinguishing:

• VPNs and multiple routes. A VPN can change the source seen by the proxy. With split routing, an IP lookup and the connection to the proxy may even leave through different paths.
• Shared gateways. Several machines can share one outgoing IP. Conversely, a group of cloud machines can use several outgoing addresses even though it belongs to one account.
• IPv4 and IPv6. An IPv4 entry does not authorize a different IPv6 source. What matters is the address used to reach the proxy, which can differ from the IP version used to reach the final website. Temporary IPv6 addresses may also change over time.

Use an address you can keep stable or update reliably. Adding a temporary address without accounting for its replacement creates an access problem later, even if the first connection works.

Set up access and let changes take effect

1. Add the correct source to the correct service. Select the package or access rule you intend to use. Enter the outgoing address from the application's network, not an IP from the purchased proxy list.
2. Configure the application. Use the endpoint, port, and protocol assigned to IP-based access. For access controlled only by IP, no proxy username or password is needed; a combined policy can require both.
3. Make a small test request from the working environment. Use a destination with a known expected response and confirm that the application used the proxy. A successful direct connection caused by a fallback setting does not test proxy access.
4. Start the full job after that test succeeds. This separates an access setup problem from the behavior of a larger workload.

A change shown in a dashboard is not always active on every server immediately. Similarly, an API response may confirm that an update was accepted rather than that every access rule has already changed. The meaning of that response and the application time depend on the service.

When updates are applied asynchronously, automation should test readiness before starting the workload. Use a limited number of retries with a delay and a clear stopping condition. A permanent configuration error should not become an endless retry loop. There is no universal waiting period that applies to every proxy provider.

Allowlist slots and access from several locations

An allowlist limit counts permitted source addresses or entries. It is separate from the number of proxy IPs you buy and from the number of simultaneous connections the package permits. A large proxy list can still have a small allowance for client source addresses.

Consider the same set of static datacenter proxies used from a home PC and a VPS. The home connection and the VPS have different public source IPs. If the package allows only 1 source IP and you have added the home address, the home PC can pass that access check while the VPS cannot. Replacing the entry with the VPS address removes permission for new connections from home once the change takes effect.

More machines do not always require more slots. Several machines behind the same outgoing address can match one entry. The useful count is how many distinct source addresses need access at the same time, subject to the provider's usage rules.

For separate sources, the options are to add permitted addresses, use credentials if the service and applications support them, or route the workloads through an outgoing gateway you control. A shared gateway adds its own running cost and another component that can fail, so it is not automatically the cheapest solution.

Before choosing a package, establish the allowance for source addresses, whether it can be expanded, any extra charge, and the rules for replacing entries. Those terms determine the cost of adding locations. The words “IP authentication” alone say nothing about the number of included slots.

When an IP-authenticated proxy stops working

A brief network interruption does not necessarily change your public IP. It can break an active connection with either authentication method. IP-based access creates an additional problem only if subsequent connections arrive from an address that the rule does not permit.

Use the symptom to narrow down the cause:

If the source matches and access has been granted, investigate the rest of the request separately. A blocked destination, a package limit, or a website's own restrictions will not be fixed by repeatedly replacing an already correct allowlist entry.

Keep the permitted sources under control

IP-based access avoids distributing a proxy password. Someone who learns only your proxy's address and port cannot pass an IP-only rule from an unapproved source. That protection does not extend to someone using an approved machine or gateway.

Behind a shared office IP, the rule cannot distinguish one employee from another. With carrier-grade NAT, the public address can be shared with other subscribers outside your organization. A shared address should therefore not be treated as proof that the connection came from a particular device you own.

Keep permissions as narrow as the workload allows. If the service accepts CIDR ranges, a broader prefix permits every address it covers; use it only when that wider scope is intentional and appropriate. Remove entries for networks you no longer use. The treatment of existing connections after removal depends on the service, so deleting an entry should not be assumed to terminate every established session immediately.

IP restrictions can also affect what an external checker learns. A publicly reachable HTTP proxy that requests credentials can identify itself through its authentication response. If an IP restriction rejects an unknown source before that response, it gives such a checker fewer direct clues. However, an IP-only proxy can still have a reachable port and a recognizable denial response. This is a possible benefit of the provider's configuration, not a guarantee that its proxy addresses will go undetected.

Finally, admission by IP does not encrypt the traffic. Secure transport to the proxy and HTTPS to the target remain separate choices.

Choose IP authentication when you have a manageable set of stable outgoing addresses, enough allowance for the locations you actually use, and no need to revoke access separately for people sharing the same source. When networks change often or individual access matters, credentials may reduce the amount of network access management required.