With an allowlist, the proxy checks where a connection comes from instead of what credentials it carries. Connections from a listed address are served; everything else is refused, typically with a 407. There are no secrets in your code or config, and nothing to leak in logs.
When it wins
- Tools that cannot send proxy credentials. Chromium cannot authenticate to a SOCKS5 proxy, and some browser automation setups make HTTP proxy auth awkward. An allowlist sidesteps both.
- Servers with a fixed public IP, where the address is stable and nobody else shares it.
When it fails
- Your IP changes. Home connections, laptops on the move and many serverless platforms do not keep one outbound address.
- Shared exits. An office or cloud NAT means everyone behind it can use your proxy.
How to set it up
List the public address of the machine that runs your code, not the proxy's address and not a private one like 192.168.1.20. Ask from that machine:
curl -s "https://api.ipify.org?format=json"
On ProxyHive you choose username and password or an IP allowlist on the order in the dashboard at https://app.proxyhive.io. The proxy authentication guide walks through both and when to prefer each.
Common confusion
"Allowlisting" also describes the reverse arrangement: a partner or API adds your proxy's exit IP to its own firewall. That needs a static IP, because a rotating exit cannot be listed. The two can meet in one setup: your server's IP on the proxy's allowlist, and the proxy's IP on the partner's.