Proxy Exit IP Allowlist Rollover: A Zero-Downtime Migration Runbook

An exit IP allowlist creates a dependency between two independently changing systems: the proxy egress pool and the destination access policy. If either side changes first, valid traffic can be denied. If old entries remain forever, the allowlist becomes inaccurate and harder to audit. A safe rollover therefore needs a planned overlap, not a one-step replacement.

This runbook is for authorized business integrations in which a partner, API, database gateway, file-transfer service, or internal application admits traffic by source IP. It covers static datacenter exits, dedicated residential exits where contractually supported, regional proxy gateways, and mixed IPv4/IPv6 environments.

1. Confirm that an IP allowlist is the right control

An IP address identifies a network path, not a person or workload. Before planning the change, confirm that the destination also uses application authentication and transport protection. Keep API keys, mutual TLS identities, signed requests, or user credentials separate from the IP rule.

Document why the allowlist exists, who owns it, which destination ports it protects, and whether the source addresses are exclusive to your organization. Shared proxy exits may not provide the identity property an allowlist assumes. If the destination requires exclusive addresses, verify that requirement with the proxy service before migration.

2. Build the old-to-new inventory

Create a versioned inventory with one row per exit path. Record:

• old and proposed new public exit address;
• address family and CIDR, using the narrowest correct prefix;
• proxy product, region, gateway, and pool;
• destinations and ports that depend on the entry;
• owner on the proxy side and destination side;
• first-seen and planned retirement times in UTC;
• validation state and rollback state.

Resolve hostnames from the actual runtime environment, but do not treat DNS answers as proof of egress. Send an authorized request through the proxy to an approved endpoint that reports the observed source address, then compare that result with the inventory. Repeat across every worker network, region, address family, and failover path.

For pools that change frequently, first apply the residential proxy inventory churn monitor. A rapidly changing shared pool usually needs a different access design than a static allowlist.

3. Define success and rollback before touching policy

Choose observable success criteria. A useful minimum is:

• new exits can authenticate and complete the intended transaction;
• old exits continue working during the overlap window;
• no direct or unapproved path reaches the destination;
• denial rates, latency, and application errors remain within baseline;
• every destination rule matches the reviewed inventory exactly.

Define rollback triggers at the same time. Examples include a rise in connection denials, a wrong observed source address, failed authentication after network acceptance, a material latency regression, or a missing region. Assign one person who can restore routing and another who can restore destination policy.

4. Add the new entries before moving traffic

Use an additive phase:

1. Freeze the reviewed old and new inventory versions.
2. Add new addresses to the destination allowlist without removing old addresses.
3. Confirm the applied rule through the destination control plane or a second reviewer.
4. Test from each new exit with a low-impact authorized transaction.
5. Record the observed source address, destination response class, authentication result, and timestamp.

Network acceptance alone is not enough. A TCP connection can succeed while the application rejects a token, tenant, certificate, or resource scope. Test the complete business transaction using non-destructive data.

Do not widen a prefix simply to make the test pass. A broad CIDR may admit unrelated customers or future addresses. Stop and reconcile the inventory instead.

5. Canary the routing change

Move a small, identifiable traffic slice to the new exit pool. Select a workload whose volume and expected outcome are known. Keep retry counts bounded so policy denials do not become a request storm.

Observe at least four layers:

If the canary is healthy, increase traffic in measured steps by region and address family. Do not combine a provider migration, credential rotation, DNS change, and allowlist replacement into one opaque event. The proxy provider migration runbook provides a broader sequencing model.

6. Verify IPv4, IPv6, and failover independently

Dual-stack applications can select a different address family after a resolver, operating-system, or network change. Test IPv4 and IPv6 explicitly when both are supported. Record the observed exit and the destination decision for each.

Also force the declared failover path. A standby gateway that has never been tested may present an address missing from the allowlist. Validate regional recovery pools, secondary providers, disaster-recovery workers, and scheduled jobs that run from a different network.

Use the multi-region proxy routing policy test to confirm that policy and observed geography remain aligned.

7. Run the overlap window long enough to catch hidden clients

Keep old and new entries active for a defined observation period. The correct duration depends on workload cycles: hourly workers may need hours, while weekly settlement or reporting jobs may need more than a week.

During overlap, search for traffic still using old exits. Group it by workload owner, destination, region, and last-seen time. Do not retire an old entry just because the main application moved; low-frequency jobs, manual tools, and recovery workflows often surface later.

Set a firm end time and an exception process. An indefinite overlap turns a controlled migration into permanent policy expansion.

8. Remove old entries in a controlled second change

After the old path has been quiet for the agreed interval:

1. Save the current destination policy and the old inventory version.
2. Remove only the reviewed old addresses.
3. Validate the resulting rule against the new inventory.
4. Force fresh tests from every new exit and failover path.
5. Confirm old exits are denied if a safe negative test is available.
6. Monitor denials and business outcomes through the rollback window.

Rollback should restore the narrow old entries and, if necessary, route the affected workload back to the old pool. It should not disable authentication or open a broad network range.

9. Preserve evidence without exposing secrets

Keep the policy version, change ticket, destination, region, address family, observed source address, response class, and UTC timestamp. Redact tokens, cookies, proxy credentials, private keys, and response bodies containing personal or customer data.

Metrics should distinguish connection denial, proxy authentication failure, destination authentication failure, throttling, timeout, and invalid business results. Treating every failure as a “bad proxy IP” encourages unnecessary rotation and hides the real layer.

Rollover checklist

• The business purpose and owners are documented.
• New exits are exclusive enough for the destination policy.
• Old and new addresses were observed through real proxy paths.
• IPv4, IPv6, every region, and failover were inventoried.
• Success metrics and rollback thresholds are agreed.
• New entries were added before traffic moved.
• The complete authorized transaction passed on canaries.
• Retry volume remained bounded.
• The overlap window covers low-frequency jobs.
• Old entries were removed in a separate reviewed change.
• Final policy matches the new inventory exactly.
• Logs contain no secrets or unnecessary payloads.

FAQ

Can a hostname replace the IP allowlist?

Only if the destination control supports hostname-based policy with clearly defined resolution and update behavior. Many network controls still evaluate concrete source addresses, so verify the actual mechanism rather than assuming DNS creates automatic rollover.

Should we allowlist the entire provider range?

Usually not. Use the narrowest addresses or prefixes that the provider contract and destination policy support. Broad ranges weaken isolation and complicate ownership audits.

How long should old and new entries overlap?

Long enough to cover normal and low-frequency workload cycles, plus a monitored rollback period. Define the duration before migration and require a documented exception to extend it.

What if the observed exit differs from the provider list?

Stop the rollout. Confirm the selected gateway, region, address family, routing configuration, and provider assignment. Do not broaden the destination rule until the discrepancy is understood.

Compliance note

Use source-IP access rules only for systems and integrations you are authorized to operate. Maintain application authentication, follow partner and regional requirements, minimize retained connection data, and never use allowlist changes to bypass destination controls, rate limits, or access restrictions.