Connecting
Endpoint
| Host | proxy.hypercall.dev (routes to the nearest entry point) |
| HTTP | 4444, 8888 |
| SOCKS5 | 1080 |
Those are the conventional assignments, but every port accepts both
protocols; the protocol is detected per connection, so a SOCKS5 client pointed
at 4444 works too. 8888 exists because some clients default to it.
Regional hostnames (us.proxy.hypercall.dev, eu.proxy.hypercall.dev) let
you connect directly to a region you already know you want. This does not
change the exit location, only where you enter the network.
Protocols
HTTP: both plain forward proxying and CONNECT for HTTPS.
curl -x 'http://USER-country-us:[email protected]:4444' https://example.com
SOCKS5: CONNECT only. Hostnames are resolved at the exit
(socks5h-style), so DNS never leaks from your machine.
curl -x 'socks5h://USER-country-us:[email protected]:1080' https://example.com
SOCKS5 UDP ASSOCIATE is not supported. UDP requests are rejected cleanly with SOCKS reply
0x07.
Proxy-string formats
Most tools accept one of these. host:port:user:pass is a common format for
automation tools:
proxy.hypercall.dev:4444:USER-country-us:PASS
http://USER-country-us:[email protected]:4444
socks5h://USER-country-us:[email protected]:1080
You can generate ready-made strings, including sticky ids spread across sessions, from the API:
curl -H "Authorization: Bearer $HYPERCALL_KEY" \
'https://api.hypercall.dev/api/me/proxies?country=us&count=5&format=txt'
See the API reference for the parameters.
IP authentication
Instead of username/password, an account can authorise by source IP: you register your IPs, connect with no credentials, and the account is identified by where you’re connecting from. IP auth runs on a dedicated port that is enabled on request: contact support to have it set up for your account before relying on it.
Register the IPs with:
curl -H "Authorization: Bearer $HYPERCALL_KEY" -X PUT \
-H 'Content-Type: application/json' \
-d '{"ips": ["203.0.113.7"]}' \
https://api.hypercall.dev/api/users/<id>/ip-auths
With IP auth you cannot pass option tokens (there’s no username to put them in), so requests use the account’s defaults.
Restricting where credentials can be used
Separately, you can restrict a username/password account to a set of source networks. Requests from anywhere else are refused even with valid credentials:
curl -H "Authorization: Bearer $HYPERCALL_KEY" -X PUT \
-H 'Content-Type: application/json' \
-d '{"cidrs": ["203.0.113.0/24"]}' \
https://api.hypercall.dev/api/users/<id>/allowed-ips
An empty list means unrestricted. The check always uses the real connecting address, never a forwarded header.