IP whitelisting

✓Residential — supported✓Rotating ISP — supported✓Rotating DC — supported

Register the addresses your traffic leaves from and we accept their requests with no credentials at all.

Setting it up

Proxy Access → IP Authorization in the dashboard. Add each public address your traffic egresses from.

That is your server’s public IP, not its private one. If you are unsure, run this from the machine itself:

curl https://api.ipify.org

Making requests

No username, no password.

curl -x us-east.gw.rayobyte.com:8000 https://api.ipify.org

Targeting moves into headers, since there is no password to append to:

curl --proxy-header "X-Rayobyte-Country: US" \
     --proxy-header "X-Rayobyte-City: dallas" \
     -x us-east.gw.rayobyte.com:8000 https://api.ipify.org

Every option and its header name is on How targeting works.

SOCKS5 needs the password form

SOCKS5 carries no request headers. To target over SOCKS5 you have to send credentials with the options appended, even if your IP is whitelisted.

When this is the right choice

Fixed egress: dedicated servers, a NAT gateway, a static-IP office. There is no secret to leak into a log, a repository or a screenshot, and nothing to rotate.

When it is not

Anything with a moving address. Laptops, CI runners, autoscaling workers, consumer connections with dynamic IPs, most container platforms. Your requests start failing the moment the address changes, and the failure looks like an auth problem rather than a network one.

Use username and password there.

Whitelisting is per-account

The whitelist covers your account. Sub-accounts have their own. See Sub-accounts.