Which IP should I whitelist for a proxy?

For a proxy gateway source allowlist, use the public source address of the client connecting to that gateway. For a destination allowlist, use the exit address reaching the destination. Confirm which boundary the rule controls.

Can I whitelist my laptop IP for a cloud worker?

Only if the worker actually uses that same public egress path. Hosted workers usually need their own route measured from the deployment environment.

Will a sticky mobile session work with a permanent destination allowlist?

Do not assume it will. Session retention and permanently assigned egress are different requirements, especially after a disconnect or rotation.

Does Coronium support IP authentication on every plan?

This guide makes no universal support claim. Follow the authentication method provided for your purchased connection and confirm any required IP-based restriction before buying.

Proxy routing and network checks

Proxy IP Allowlisting vs Password Authentication: Which IP?

Identify the address being authorized, then choose a proxy authentication method that survives your worker and network changes.

Coronium Technical TeamSources checked October 14, 20268 min read

Start with the connection path

A gateway allowlist normally checks the public source IP connecting to that gateway. That is different from the proxy exit IP seen by a website.
A destination allowlist checks the source arriving at that destination. A rotating mobile exit may be unsuitable for a fixed allowlist.
Verify that the purchased proxy plan supports the required authentication method. Do not assume a username-password endpoint also supports IP allowlisting.

There are two different allowlists

Which address belongs in which rule?
Rule owner	Address being checked	Frequent mistake
Proxy provider gateway	Public source of the worker connecting to it	Adding the proxy exit instead of the worker egress.
Your destination API	Source reaching the API after proxying	Adding a laptop IP while requests arrive from the proxy.
Cloud firewall near the worker	Addresses and ports at that network boundary	Assuming an application credential opens a blocked network path.
Local process configuration	Chosen proxy and bypass destinations	Passing a direct request because NO_PROXY matches.

Map the request path before editing any rules:

Your worker -> its public egress -> proxy gateway -> proxy exit -> destination

At the proxy gateway, a source allowlist authorizes the worker's visible public address. At the destination, an IP allowlist authorizes the proxy exit that reaches it. Adding the proxy exit to the gateway's client allowlist usually confuses those two roles.

A hostname can introduce another address: the proxy gateway listener. That listener address is not necessarily the source IP a destination sees. Use observations from the relevant connection rather than choosing whichever address appears first in your dashboard.

This distinction is especially useful for cloud workers and mobile exits. If your target is an API you control with a fixed allowlist, decide whether stable egress is a requirement before choosing a rotating service. See mobile rotation behavior and static residential proxies for the product distinction.

Measure the worker source from the right environment

A laptop, a hosted runner and a queue worker can have different public egress. Run the check from the exact process environment that will connect to the gateway. For gateway authorization, use a deliberately direct request to a diagnostic endpoint you control or consult the gateway's connection logs. For destination authorization, check through the proxy instead.

A cloud NAT layer may determine the observed source. AWS documents that public NAT gateways use their associated Elastic IP for internet-bound traffic through an internet gateway, while other routing paths can expose a different address. Verify the path that your deployment actually uses.

Private interface addresses such as 192.168.x.x and shared carrier addresses are not interchangeable with internet egress. RFC 6598 defines shared 100.64.0.0/10 address space. Do not add an internal address to an internet-facing allowlist and expect it to represent your worker.

For an AI tool runner, test the runner itself. Configuring the developer's browser or adding the developer's home IP does not authorize the remote tool process. The Node.js and Python HTTPX guides show how to keep those clients explicit.

Choose credentials or an IP allowlist for the job

Username-password authentication follows the credential wherever the supported client runs. That can fit workers whose egress changes, but the password needs a secret store, access control and a rotation procedure. Do not embed it in a public notebook or model-visible tool configuration.

Source-IP authorization can be convenient when a provider supports it and your worker has controlled, stable egress. It also means processes sharing that authorized egress may share the ability to connect, depending on the provider's other controls. Do not treat a NAT address as an individual user's identity.

Some services can combine credentials with network restrictions; some offer only one mode. Confirm the exact product contract. This article does not claim that every Coronium connection supports IP-based authentication. Use the authentication method shown for your purchased connection and confirm additional requirements with support.

Before comparing mobile proxy options, write down the client library, worker environment, protocol and required source stability. For web scraping connections, also record the permitted destination and whether the workflow needs account-session continuity.

Why a rotating exit breaks destination allowlists

Suppose your API permits one proxy exit, and a later mobile reconnection produces another. Authentication at the proxy can continue working while your API denies the request. The gateway password did not fail; the destination rule no longer matches the observed source.

A sticky session is not the same guarantee as a permanently assigned IP. Check the supplier's retention conditions and verify what happens after a disconnect, restart or explicit rotation. If your application requires fixed destination allowlisting, a documented stable-egress service may be a better fit than a rotating mobile connection.

Avoid broadly allowing an entire carrier network to compensate for changing addresses. That authorizes far more sources than your own worker. Where you control the application, use properly authenticated requests and a network restriction appropriate to its risk model. Test rejection of an unauthorized source as well as acceptance of the intended one.

Use the response to find the rejecting layer

A 407 response means a proxy is requesting authentication. An allowlist failure can appear differently depending on the provider: rejection, timeout or a vendor-specific response. A website 403 is not enough evidence to identify which rule rejected the request.

Compare three controlled observations: the worker's direct connection, its authenticated proxy connection to a neutral test endpoint, and the request to the intended destination. Preserve response codes and timestamps. Inspect logs at the boundary you operate. Do not erase working restrictions to make an unexplained test succeed.

If you manage a Cloudflare-protected destination, review the exact product's behavior. Cloudflare IP Access Allow rules can bypass security checks; they are not just a label saying an IP is familiar. Use the narrowest appropriate rule and test the intended scope instead of allowing a whole ASN.

Continue with the proxy error reference or location mismatch diagnosis when authentication works but the returned content is unexpected.

A deployment checklist you can repeat

Before release, identify who owns each allowlist and record the intended public source privately. Make one allowed request and one request from an unauthorized source to a test environment you control. Confirm the latter is denied for the expected reason, rather than merely failing for an unrelated network error.

Restart or redeploy the worker and repeat the source check. If there are multiple regions or outbound NAT paths, check each one. Document what triggers a rule update and how a stale entry is removed. Keep a rollback path so a rule change does not interrupt unrelated workloads.

For credential-based access, confirm that the application reads the secret at the expected time and that logs omit it. Test a wrong password once against your own account to verify useful error handling. Do not repeatedly retry invalid credentials.

Sources were checked October 14, 2026. The address model and checklist are configuration guidance; we did not audit your cloud routing or validate every provider's allowlisting behavior. Use the observed source and the purchased product's documented authentication controls as your acceptance evidence.

Sources and review scope

Sources reviewed October 14, 2026. Primary documentation and diagnostic procedures are identified separately from measured results. These guides do not claim carrier-wide location accuracy or universal support for an authentication feature.