ProxioDocs
Proxies & Targeting

IP Authentication (Passwordless)

Whitelist the source IPs you control and connect to Proxio Residential with no username or password. Learn how per-binding geo and session defaults work, the 50-IP limit, the one-credential rule, and the security tradeoff.

IP authentication lets a machine at a known, fixed IP address use your Residential proxies without sending a username or password. You whitelist the source IP once; after that, connections from it are recognized and authorized automatically. This runs alongside username/password auth, so turning it on does not disable your credentials.

How it works

Whitelist your source IP

In your Residential service's Sub-users tab, add the public IP address of the machine that will connect. This creates a binding between that IP and the credential.

Connect with no credentials

From that IP, point any client at the gateway with the username and password left out entirely:

curl -x http://geo.proxio.cc:16666 https://ipinfo.io

Targeting comes from the binding

Because there is no username to carry -region- or -sessid- segments, each binding stores its own defaults and applies them automatically.

Per-binding defaults

Every binding remembers a small set of defaults that are applied to connections from that IP:

DefaultValues
Country / state / cityAny target you would otherwise put in the username
StickyOn or off
Session length (sesstime)1 to 90 minutes

This means two different whitelisted IPs on the same credential can behave differently (one pinned to Germany with a 30-minute sticky session, another rotating freely in the US) without either one sending a username.

Limits and rules

  • Up to 50 whitelisted source IPs per credential.
  • An IP can be bound to only one credential across the whole platform. If you try to bind an IP that is already in use, you get an IP_TAKEN error. Remove it from the other credential first.
  • Only public addresses are allowed. Private, CGNAT and reserved ranges are rejected, because they are not globally unique and cannot identify you safely.

The security tradeoff

IP auth trades a password for trust in an address, so the address has to be one you truly control.

Only whitelist an IP you control

Anyone connecting from a whitelisted IP uses your quota with no password. On a shared or NAT'd IP (office network, mobile carrier / CGNAT), everyone behind that IP can spend your data. Only whitelist a static, dedicated IP you control.

Password auth keeps working

Adding an IP binding never turns off username/password authentication. Both work in parallel, so a whitelisted server and a laptop using credentials can hit the same credential at once.

Removing a binding revokes access instantly: the moment you delete the IP from the Sub-users tab, connections from it stop being authorized.

On this page