Connection & Authentication Problems
Fix Proxio connection failures and Error 407 by verifying the endpoint, copying credentials whole, URL-encoding passwords, picking the right scheme, and diagnosing IP-allowlist auth issues.
Most connection failures come down to one of four things: the wrong endpoint, mangled credentials, a blocked port, or an IP-allowlist mismatch. Work through the checklist in order. Each step is a common cause of 407 Proxy Authentication Required or a dead connection.
Verify the endpoint is exactly geo.proxio.cc:16666
The host is geo.proxio.cc and the port is 16666. The same host and port serve HTTP/HTTPS and SOCKS5. There are no per-pool hostnames. A typo in either the host or the port will look like a connection failure. Confirm with the self-test:
curl -x http://USERNAME:[email protected]:16666 https://ipinfo.io -vCheck your username was copied whole
The base username is 12 lowercase, alphanumeric characters, generated in the dashboard. If you add targeting, the entire string (base plus -region-..., -city-..., -sessid-... segments) is your proxy username. Copy it from the service's Sub-users tab.
A single stray space, a line break, or a truncated base username causes 407. Paste into a plain-text field first to spot hidden whitespace, and make sure your targeting segments were not cut off.
Check the username and password order
In URL form the pattern is http://USERNAME:[email protected]:16666. Username first, then a colon, then the password. Swapping them produces 407. The username and password are separate values in the dashboard; the password is not derived from the username.
URL-encode special characters in the password
When you put credentials inside the URL, any reserved character in the password must be percent-encoded. For example, @ becomes %40, : becomes %3A, and / becomes %2F. An un-encoded character breaks URL parsing and shows up as 407 or a malformed-URL error.
Avoid the problem entirely: pass credentials outside the URL with curl's -U flag, which needs no encoding.
curl -x http://geo.proxio.cc:16666 -U USERNAME:PASSWORD https://ipinfo.ioUse the right scheme
- HTTP proxy: use
http://, even when your target site is HTTPS. Your client issues aCONNECTtunnel and the gateway relays it without ever seeing your TLS. - SOCKS5 proxy: use
socks5h://in curl, Python, and Node so DNS resolves through the proxy. PHP and C# libraries usesocks5://. SOCKS5 supports theCONNECTcommand only.
Using https:// as the proxy scheme is the most common scheme mistake. The proxy endpoint is reached over http://, regardless of the destination.
If you use IP-allowlist (passwordless) auth
Connections from a whitelisted IP need no username or password, so a mismatch fails instantly. Check these:
- Your public source IP must be whitelisted on that credential. Confirm your current IP with
curl https://ipinfo.io/ip, then compare it against the binding. - Dynamic IPs and CGNAT change your public IP. Home ISPs and mobile carriers rotate it, so a binding that worked yesterday can fail today. Re-add the new IP or switch to username/password auth.
- An IP can be bound to only one credential globally. Trying to bind an IP that is already on another credential returns
IP_TAKEN. Remove it from the first credential before binding it to the second. - Private, CGNAT, and reserved ranges are rejected as bindings. You can only whitelist a public IP.
- Removing a binding revokes access instantly. Password auth keeps working in parallel, so you can always fall back to username/password.
Anyone connecting from a whitelisted IP uses your quota with no password. On a shared or NAT'd IP (an office network or a mobile carrier / CGNAT), everyone behind that IP can spend your data. Only whitelist a static, dedicated IP you control.
Confirm the credential is still active
If you rotated or reset the credential in the dashboard, the old username and password stop working immediately. Update your client with the new values from the Sub-users tab.
Check the credential's quota cap
Each credential can carry an optional bandwidth quota cap. If this credential hit its cap, its requests fail even though the package as a whole still has data. Raise or clear the cap in the Sub-users tab, or review remaining data in Usage Statistics.
Testing matrix
Once you have made a change, re-test with the exact protocol you use. A successful call returns JSON from ipinfo.io showing an exit IP that is not your own.
# HTTP/HTTPS proxy. Works for both http:// and https:// targets.
curl -x http://USERNAME:[email protected]:16666 https://ipinfo.io -v
# Same request, credentials kept out of the URL (no encoding needed):
curl -x http://geo.proxio.cc:16666 -U USERNAME:PASSWORD https://ipinfo.io# SOCKS5: use socks5h:// so DNS resolves through the proxy.
curl -x socks5h://USERNAME:[email protected]:16666 https://ipinfo.io -vA full worked example with targeting (base username abcxyz123def, US exit, sticky 15-minute session) looks like this. Quote the URL so your shell does not choke on the special characters:
curl -x "http://abcxyz123def-region-us-sessid-session_9k2p7qz1m4vb1-sesstime-15:[email protected]:16666" https://ipinfo.ioStill getting 407?
Cross-check the exact meaning in the Error & Response Code Reference. If the checklist passes and the self-test still fails, open a support ticket under the PROXY_ISSUE category with the verbose (-v) output attached.
Error & Response Code Reference
What every error means and how to fix it, covering Error 407 Proxy Authentication Required, 502/503/504 gateway failures, connection timeouts, plus target-site 403, 429 and CAPTCHA responses.
Geo-Targeting Not Working
Fix wrong-country and wrong-city proxy results, covering slugging rules (newyork, not new-york), the country/state/city hierarchy, geolocation-database disagreements and stale sticky sessions.