If you have used proxies before, IP whitelisting is probably familiar: you register your server’s address with the provider, and any connection from that address is allowed through without credentials. It is a common model, and people arriving from other products often go looking for the setting.
The direct answer for the residential gateway is that there is no IP whitelist. Authentication is username and password on every request, and the credentials are the sole auth mechanism. That is a deliberate design choice rather than a missing feature, and it is worth understanding why, because it changes how you secure access. Whitelisting does exist elsewhere in the product line, on ISP proxies and on legacy port-based plans, and this covers how to set it up there.
Why the residential gateway uses credentials instead
The residential product is a single endpoint, p.shifter.io:443, where all targeting lives inside the username. A request for a US exit with a sticky session is the same host and port as a request for a rotating German exit; only the username string changes. That design has a consequence for authentication: the credential is already carrying per-request information, so it has to be present on every request anyway.
Credential auth is also considerably more portable, which matters more than it first appears. Whitelisting binds access to a fixed egress address, and a great deal of modern infrastructure does not have one. Containers get new addresses when they reschedule, autoscaling groups add and remove nodes, serverless functions egress through shared address space that changes without warning, CI runners are ephemeral, and a developer on a laptop or a home connection has a dynamic address that can change overnight. Under whitelisting, every one of those is a support ticket. With credentials in a secret store, the same configuration works from a laptop, a container, a CI job, and a production cluster without anyone registering anything.
So if you came looking for the whitelist setting on residential proxies, the thing to configure instead is credential handling, covered below.
Where whitelisting does apply
Two products use source-IP authentication, and if whitelisting is a hard requirement for you, these are the ones to look at.
ISP proxies support two authentication modes, and you pick one per plan in the panel. In authorized source IP mode you register your server’s address and then connect to your pinned IPs on port 1337 with no credentials at all. In username and password mode you connect from anywhere with credentials, one line per IP. The trade-off is exactly the one described above: whitelisting keeps credentials out of your code entirely, at the cost of only working from registered addresses. ISP proxies are a different product from rotating residential, with pinned static addresses rather than a rotating pool, so if you are choosing between them the comparison is in ISP versus residential proxies and what static residential proxies are.
Legacy port-list plans authenticate by source IP only. Each port in your allocation has its own subdomain, and you whitelist your server’s address in the panel, or manage the list through the legacy management API, and then connect to any port in your list. If you are on one of these plans, whitelisting is not optional, it is the only auth mechanism. The background on why the industry moved away from this model is in why the per-port era is over.
Setting up a whitelist on ISP proxies
The mechanics are straightforward, but two details cause most of the failures.
First, register your egress address, not a local one. The address that matters is the public address your traffic arrives from, which is not your LAN address, not your container’s internal address, and not what ifconfig prints on the machine. Determine it from the machine that will actually make the requests:
# run this ON the server that will connect to the proxies
curl -s https://ipinfo.io/ipIf your infrastructure egresses through a NAT gateway or a load balancer, that shared address is what to register, and it is worth confirming it is stable rather than assigned dynamically.
Second, choose the auth mode deliberately in the panel under ISP Proxies, because the two modes are alternatives rather than a layered system. Once you are in authorized source IP mode, you connect with no credentials:
# authorized source IP mode: no username or password
curl -x 185.199.108.153:1337 https://ipinfo.io/jsonIf that returns an error and you are sure the address is registered, the usual causes are that your egress address changed, that you registered an IPv4 address while your traffic is leaving over IPv6 or the reverse, or that requests are coming from a different node than the one you tested from.
The trade-off, stated plainly
Whitelisting removes secrets from your code and your configuration, which is genuinely valuable: nothing to leak in a repository, nothing to rotate, nothing to end up in a log. Its weakness is that it fails the moment your egress address changes, and it cannot support access from anywhere that does not have a stable address.
Credential auth is portable and works from any environment, but the credentials are a secret you now own, which means they belong in a secret manager rather than in source, and they need a rotation plan.
Neither is inherently more secure. They fail differently, and the right choice depends on whether your infrastructure has stable egress.
Securing residential credentials, since there is no whitelist
If you are on the residential gateway, this is the section that replaces whitelisting for you.
Keep credentials out of source control and out of container images, and load them from environment variables backed by a secret manager. Use separate credentials per environment where you can, so a leaked development value does not expose production. Treat rotation as a deployment rather than a panel click: update the secret store first, roll clients, then rotate the old value, because every client still holding the previous password will start returning 407 the moment it changes, which is the most common self-inflicted version of the problem covered in fixing 407 and credential errors.
Then control the other side. Even without a provider-side whitelist, you can restrict which of your own systems reach the gateway using ordinary egress rules, network policy, or a security group, so a leaked credential is less useful from outside your infrastructure. And monitor bandwidth usage, because unexplained consumption is the signal that a credential has escaped, which is easier to spot when you have a baseline from your own pipeline monitoring.
Common mistakes
Registering a private address such as a 10.x or 192.168.x value, which can never match, since only the public egress address is visible to the provider. Whitelisting a laptop or home connection and being surprised when it stops working after a router reboot reassigns the address. Forgetting that autoscaling adds nodes behind different addresses. Registering IPv4 while the traffic actually leaves over IPv6. And assuming a whitelist entry on one product covers another: an ISP proxy whitelist has no effect on the residential gateway, which will still require credentials.
The bottom line
There is no IP whitelist on the residential gateway, and that is by design: targeting lives in the username, so credentials are present on every request anyway, and credential auth keeps working across containers, autoscaling, CI, and dynamic connections where a whitelist would break. If you need source-IP authentication specifically, ISP proxies offer it as one of two selectable modes and legacy port-list plans use it exclusively, and in both cases the thing to register is your public egress address rather than anything local. On residential, replace whitelisting with disciplined credential handling: secret manager, per-environment values, a rotation procedure that updates clients before invalidating the old password, plus egress controls and usage monitoring on your side.
The complete auth reference for every product is in the authentication documentation, and the gateway specifics are in gateway and authentication. The product itself is residential proxies, one endpoint and one credential pair across every country and session mode, with per-GB pricing.