Source-IP Authentication for a Fleet of Proxy Workers

An IP-authenticated proxy account can work from one worker and reject another because the workers arrive from different public addresses. The fleet needs a deliberate outward path before it connects to the proxy.

One AWS IPv4 arrangement is:

private worker → public NAT gateway → internet gateway → proxy service → destination

A public NAT gateway has an associated Elastic IP. For traffic sent through the VPC's internet gateway, AWS translates the NAT gateway's private address to that Elastic IP. A remote proxy can therefore authorize that public egress address instead of the private address of each worker.

Route the intended workers' internet-bound traffic through the planned gateway and register the possible public egress addresses with the proxy service. If the deployment uses several NAT gateways or additional egress addresses, account for every path the fleet may take.

The source accepted by the proxy is one address relationship. The proxy's exit address observed by the destination is another. Giving the account a stable connecting IP does not force the service to use that IP as its exit.

A private NAT gateway does not provide this public-Elastic-IP internet arrangement. AWS also documents different address behavior when a public NAT gateway sends traffic through a transit or virtual private gateway instead of the internet gateway.

The operational check is the proxy service's observation of a connection from each worker route, including failover. Keep that observation with the egress configuration so a later network change can be reflected in the account's allowlist.