IP Allowlisting: Which Proxy Address Must Stay Fixed?

If a partner asks you to allowlist an IP address, first identify where its rule is enforced and which source address that rule evaluates. For a source-IP rule at the partner's public edge, this is normally the public egress of the connection arriving there. It is not automatically your laptop's address, the hostname you use to connect to a proxy, or the IP written in a request header. Separately, a proxy provider may allowlist the address from which your worker reaches its service. These are two different gates.

This guide is for developers choosing a route for an authorized partner API or other approved integration. Its deliverable is an address-and-owner worksheet and an offline policy exercise. If an existing direct route already supplies the approved stable egress, adding a proxy may add cost and another failure point without solving a new problem.

Draw the two gates before choosing a product

The addresses below are documentation examples, not live servers or measured IPHTML addresses. A provider can use different entry and exit infrastructure; the diagram does not imply a one-to-one allocation.

Worker → its public egress A → provider entry B → exit C → partner edge
         192.0.2.10           203.0.113.40       198.51.100.20

Gate 1: provider accepts source A, if using source-IP authentication
Gate 2: partner accepts source C, if enforcing at its public network edge

Direct alternative: worker → approved public egress A → partner edge

A stable proxy hostname only identifies an entry service. It does not establish a stable exit. Likewise, a session-continuity test answers whether a particular workflow retained its identity over its test window; a partner's address rule can outlive that window. Use the session continuity guide for the former and this worksheet for the latter.

Agree on the enforcement point, including any CDN or gateway

Ask the partner to name the protected hostname, protocol/port, environment, rule owner and address field used by the rule. If a reverse proxy or CDN fronts the service, the origin socket may see that intermediary. An application-level rule may instead use a client address restored by a configured trusted intermediary. Record that trust arrangement; do not equate every origin access-log field with the address checked at the public edge.

A client-supplied Forwarded or X-Forwarded-For value is not proof of source-IP identity. RFC 7239 section 8.1 explains the integrity limits of forwarded address information. Changing a header does not change a connection's transport source address. The exercise below deliberately models source-address rules, not a trusted-CDN header policy.

Public service documentation shows why specificity matters. MongoDB Atlas distinguishes cluster access lists from its management-UI list. That is an example of scope, not a recommendation to send database traffic through an HTTP proxy. Confirm protocol support separately. AWS documents that a public NAT gateway uses its Elastic IP as the source when routed through an internet gateway in the same VPC; other paths can expose its private address. The phrase “we have a fixed IP” is therefore incomplete without the route.

Replay eleven address-policy cases without touching a firewall

Download the offline Python exercise, inspect it, then run it with Python 3.9 or later. It uses only the standard library, makes no network requests and changes no configuration. All addresses and outcomes are synthetic. This tests reasoning about two declared rules; it does not discover your egress, implement a proxy or verify a provider.

python3 ip-allowlist-egress-check.py

Start with provider rule 192.0.2.10/32 and target rule 198.51.100.20/32. Each case changes the specified inputs independently. A /32 denotes one IPv4 address; a /128 denotes one IPv6 address. The fixture never broadens a live rule.

The expected totals are four eligible-for-trial cases, four target blocks, one provider block and two pending-evidence cases. Three additional counterexamples check that changing the entry address or an untrusted header cannot establish egress approval, and that removing backup approval blocks that backup. “Eligible” means only the modeled address gates match. Target authentication, TLS, protocol behavior and useful application results remain untested.

Turn the model into a bounded acceptance trial

1. Name the real workload. Record worker environments, intended primary and recovery routes, hostname, protocol/port and applicable IPv4/IPv6 paths. Check the actual client configuration with the curl/Python route guide if a terminal and an application disagree. A laptop test cannot certify a scheduled production job.
2. Agree on the allowed set. Obtain the partner owner's approved address or finite set, scope and activation time. Ask the route provider what is allocated, how long allocation lasts, what can change after reconnect/restart/maintenance and how replacements are communicated. “Dedicated” or “sticky” alone does not answer those questions.
3. Correlate an approved request. Use a harmless authorized request and an opaque request ID. Obtain time, environment, route, evaluated source, rule result and application outcome from the relevant owners. A separate echo endpoint is diagnostic only: destination-based routing can differ. Keep tokens and credentials out of the worksheet.
4. Exercise the transitions that matter. In an agreed test window, cover normal requests, fresh connections, a worker restart and each proposed recovery path. Address-family behavior and session-expiry behavior belong in scope when applicable. Ask the partner to verify fresh-connection behavior for rule changes; an already open connection is not enough.
5. Record a decision, not an uptime claim. Accept only the observed scope if every exercised route used an approved source and the application result was correct. Hold rollout for unexplained source changes or missing logs. Retain an approved fallback, and record untested maintenance/replacement events as residual risks with an owner.

A useful evidence row is time | worker | route | family | gate | evaluated source | rule revision | request ID | network result | application result. Store it in your controlled project records. For a wider workload acceptance plan, use the representative trial guide; for a failure at the provider's authentication gate, use the 407 diagnosis guide. An HTTP status alone does not identify which address rule caused a failure.

Choose the least complicated route that meets the contract

Keep an approved direct route when its egress and recovery behavior meet the partner's requirements. Evaluate a managed fixed-egress route when multiple changing workers need an agreed source and your team cannot reliably operate that route itself. Confirm protocol, destination permission, allocation/change terms, capacity and total cost before purchasing. These are procurement questions, not verified IPHTML capabilities.

Do not choose a changing exit pool for a single-address contract unless the partner explicitly supports the resulting address set and change process. If only one address is accepted and a backup uses another, there is no approved backup yet. Do not make the requirement disappear by opening a broad range. If the destination is reachable only over an approved private connection, evaluate that architecture with its owner instead of assuming a public proxy fits.

If an authorized task also needs a particular regional residential network, review the residential options against that separate requirement. For the allowlist decision, ask IPHTML to confirm the required egress and protocol terms before a trial: include the number of permitted source addresses, environment, protocol, required region and maintenance constraints, without credentials. Fixed allocation, exclusivity, failover behavior and service performance have not been established by this article. A missing answer is a reason to keep the purchase decision open.