Static Proxy IPs for API Allowlists: Setup and Failover

Two allowlists protect different connections

Authorizing your laptop at the provider does not authorize the proxy at an API. Conversely, adding the proxy exit to an API allowlist does not grant your worker permission to use the proxy. Configure both layers where required, using the proxy authentication guide.

The route is:

1. Your worker connects to the configured proxy host and port.
2. The proxy authenticates the worker using supported credentials or source-IP authorization.
3. The proxy opens the connection toward the HTTPS API.
4. The API evaluates the proxy exit IP, then its API authentication and authorization rules.

The proxy host you dial and the exit IP can differ. Use the address observed on the destination connection, not an assumption based on the proxy hostname. An allowlist also does not replace a valid API token or permission scope.

Choose static egress, then verify its lifecycle

For a small API allowlist, start with an explicitly assigned static exit rather than a rotating pool. Dedicated allocation gives you exclusive use; it does not by itself promise an IP will remain unchanged forever. Read static versus rotating proxies and dedicated versus semi-dedicated proxies to separate those properties.

Ask how the address behaves on renewal, replacement, location changes and infrastructure maintenance. Confirm any retention commitment in the applicable service terms. BuyProxies describes its service as stable private datacenter proxies; treat that description as a starting point for verification, not a guarantee of permanent ownership of an address.

Also confirm the destination permits datacenter egress. An API can reject datacenter IPs or impose account, geography and rate-limit restrictions even after an address is allowlisted. Agree on the route with the API operator before depending on it.

Maintain a record of the endpoint, observed exit, destination policy entry, authentication method, renewal date and owner. Recheck the exit after renewal or a provider change. Reserve a separately configured backup with its own verified exit.

Probe the route from the actual worker

Test inside the container, VM or job runner that will make the API calls. A browser test on your laptop cannot prove the worker’s routing. Use a controlled HTTPS endpoint to observe egress, then a harmless authenticated read on the intended API; its logs provide the strongest destination-specific confirmation.

Here is an illustrative curl configuration. Every hostname and credential is a placeholder. Save your real values in an access-restricted api-probe.conf through your secret-management process; do not commit it or include it in diagnostic uploads.

proxy = "http://proxy.example:3128"
proxy-user = "PROXY_USER:PROXY_PASSWORD"
noproxy = ""
url = "https://api.example/v1/read-only-health"
header = "Authorization: Bearer API_TOKEN"
connect-timeout = 5
max-time = 20
fail-with-body
silent
show-error

Run curl --disable --config api-probe.conf; on Windows PowerShell use curl.exe to select the executable. The first option disables the default curl configuration. The empty noproxy value overrides environment exclusions that could bypass the proxy. These options are documented in the curl manual.

An http:// proxy can tunnel an https:// API through HTTP CONNECT, as curl’s HTTP proxy documentation explains. Preserve destination TLS certificate verification and the real API hostname. API TLS does not encrypt the separate HTTP proxy login: protect that connection with a trusted network or a secure proxy transport explicitly supported by your provider.

A successful tunnel is only the transport check. Validate the expected API status and body, token scope and destination-observed exit. Test every worker path, including scheduled jobs, and check for proxy bypass rules. This example is a setup template, not evidence of a live connectivity test.

Add, probe, cut over, drain, then remove

For an illustrative migration, call the old exit A and the new exit B. Keep both destination entries during the controlled overlap:

1. Stage the allowlist addition. Add B while A remains allowed. Wait for the destination’s documented propagation interval; GitHub’s enterprise documentation, for example, warns that policy changes can take a few minutes because of caching.
2. Probe B through the exact worker route. Verify proxy access, TLS, API credentials, useful response and the destination-observed exit. Stop if the exit differs.
3. Cut over gradually. Send a small batch through B, observe errors, then move remaining workers. Keep A available for a controlled rollback.
4. Drain A. Stop starting requests on A and wait for in-flight work and pooled connections to finish. Check older job configurations.
5. Remove A once safe. Confirm no required worker uses it and retain a tested, approved backup route before retiring the old policy entry.

Use exact single-address entries where the destination supports them. Avoid allowing a whole provider network just to simplify replacement. Keep an audit record of policy and worker changes.

Fail over only to a preapproved backup IP

Prepare the backup before an incident: verify its exit, add it to the destination allowlist and test it using the same credentials and read-only operation. If the primary fails, switch to that backup. If neither approved route works, stop or queue work and alert the owner. Never fall back to a direct connection or an arbitrary rotating IP.

Make this explicit in application configuration: a missing or unusable proxy must cause a routing error, and destination bypass rules must be empty for this API. Where available, enforce outbound network policy so workers cannot reach the API outside the approved route.

Bound retries and follow the API’s backoff rules. A timeout on a write may happen after the server committed it. Use the destination’s documented idempotency mechanism before replaying writes; see HTTP idempotency guidance. Record route and request identifiers without logging tokens.

For budget planning, see proxy pricing and cost per useful request. Use the proxy tester for basic checks and the API testing guide for application validation. Explore dedicated proxy packages after confirming the destination’s requirements.

Frequently asked questions

Which IP goes into the API allowlist?

The verified exit IP the API observes. The worker’s public IP belongs in provider source-IP authorization when that method is used.

Will a static IP stay the same forever?

Do not assume permanence. Confirm retention terms and reverify identity after renewal, replacement or maintenance.

Can I remove API tokens after allowlisting?

No. Keep API authentication, scopes and TLS verification. The allowlist is an additional access condition.

Should a failed proxy trigger a direct retry?

No. Use a tested, preapproved backup exit, or pause work until an approved route is available.