IPRoyal Proxy Setup: Choosing HTTP vs SOCKS5 vs Shadowsocks and Verifying Your First Request

Overview

IPRoyal offers residential, datacenter, and ISP proxies over HTTP(S), SOCKS5, and Shadowsocks-style tunneling, billed either pay-as-you-go or flat monthly, backed by a pool of 32M+ IPs. That protocol range is exactly why people choose it — and it is also the most common reason a first setup fails. Pasting a SOCKS5 endpoint into an HTTP-only field, or the reverse, produces errors that look like a dead proxy rather than a configuration mismatch.

This tutorial takes you from a fresh IPRoyal account to a verified, scriptable connection. You will choose the right proxy type and protocol for your workload, build a working proxy URL, prove that traffic actually exits through IPRoyal, and check that DNS is not resolving around the tunnel. Every command runs in a macOS or Linux terminal; the proxy URLs are identical on Windows, only the shell variable syntax differs.

What you need

• An active IPRoyal plan (residential, datacenter, or ISP) and access to your dashboard
• The gateway host, port, username, and password exactly as the dashboard shows them
• curl built with SOCKS5 support (the standard builds on macOS, Debian, and Ubuntu include it)
• Optional: Python 3.8+ with the requests library for scripted checks

Choosing the proxy type and protocol

Proxy type and protocol are two separate decisions. The type determines which IP you appear as; the protocol determines how your traffic is wrapped on the way there. Pick the type first, then the protocol.

Protocol availability can differ by product and plan, so confirm what your specific dashboard exposes before you build anything. Where both are offered, HTTP(S) is easier to debug and SOCKS5 is more capable — start with HTTP(S), then move to SOCKS5 once the credentials are proven to work.

Steps

1. Copy the endpoint and credentials from the dashboard. Do not retype them. Use copy buttons so that trailing spaces and lookalike characters never enter the picture. The four values you need are the gateway host, the port, the username, and the password.

   export PROXY_USER="dashboard-username"
   export PROXY_PASS="dashboard-password"
   export PROXY_HOST="gateway-host-from-dashboard"
   export PROXY_PORT="gateway-port-from-dashboard"
   

2. Build the proxy URL for each protocol. The URL format is the same everywhere: credentials, then host, then port.

   http://USERNAME:PASSWORD@HOST:PORT     # HTTP/HTTPS proxy
   socks5h://USERNAME:PASSWORD@HOST:PORT  # SOCKS5, DNS resolved at the proxy
   

   If your password contains @, :, /, or ?, percent-encode it (@ becomes %40, : becomes %3A). Unencoded special characters are the single most common cause of authentication failures.

3. Verify an HTTP(S) request from the terminal. This proves the credentials, host, and port are all correct before you involve a browser or a script.

   curl -sS \
     --proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
     "https://api.ipify.org?format=json"
   

   You should receive a small JSON object containing an ip value that is not your own address. If you see your real IP here, the flag was ignored and traffic went out directly.

4. Verify a SOCKS5 request, and get remote DNS. Use --socks5-hostname so the proxy resolves the hostname instead of your machine doing it locally.

   curl -sS \
     --socks5-hostname "$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
     "https://api.ipify.org?format=json"
   

   The difference matters: --socks5 resolves DNS on your device and then tunnels the connection, while --socks5-hostname sends the hostname to the proxy. For privacy work, prefer --socks5-hostname and the equivalent socks5h:// URL scheme in scripts.

5. Inspect the tunnel when something looks off. Verbose output shows whether the proxy accepted the request before any page content is involved.

   curl -v \
     --proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
     -o /dev/null "https://example.com"
   

   Look for a CONNECT line followed by HTTP/1.1 200 Connection established. A 407 at that point is an authentication problem; a timeout at that point is a host or port problem.

6. Script the same check in Python. For HTTP proxies, requests needs no extra packages.

   import os
   import requests
   
   proxy_url = os.environ["IPROYAL_PROXY_URL"]  # http://user:pass@host:port
   proxies = {"http": proxy_url, "https": proxy_url}
   
   response = requests.get(
       "https://api.ipify.org?format=json",
       proxies=proxies,
       timeout=30,
   )
   response.raise_for_status()
   print(response.json())
   

   For SOCKS5, install the optional dependency first, then use a socks5h:// URL so DNS resolves at the proxy end.

   pip install "requests[socks]"
   

   import os
   import requests
   
   socks_url = os.environ["IPROYAL_SOCKS_URL"]  # socks5h://user:pass@host:port
   proxies = {"http": socks_url, "https": socks_url}
   
   session = requests.Session()
   print(session.get("https://api.ipify.org", proxies=proxies, timeout=30).text)
   

7. Decide between rotation and sticky sessions. Run step 3 twice with the same credentials and compare the two addresses. If the IP is unchanged, your plan is holding a sticky session, which is what you want for logins and multi-step forms. If you need a new address, request one using the session or rotation controls your dashboard provides rather than hand-editing URL parameters — generated credentials are already correctly formatted.

8. Confirm the exit region and check for DNS leaks. A Cloudflare trace request shows both the exit IP and the country it is registered in, which is the fastest way to catch a misrouted plan.

   curl -sS \
     --proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
     "https://1.1.1.1/cdn-cgi/trace"
   

   Read the ip= and loc= lines: loc= should match the region you intended to use. Then run a public DNS leak test in the browser you configured; if the resolver shown is your local ISP rather than the proxy network, switch that browser to a SOCKS5 configuration or a client that supports socks5h-style remote DNS.

Troubleshooting

• 407 Proxy Authentication Required — Credentials are wrong, revoked, or contain unencoded special characters. Percent-encode the password and re-copy both values.
• curl: (7) Failed to connect or a timeout — Wrong host or port, or the protocol and port do not match (an HTTP port used with a SOCKS5 URL). Check the protocol column in the dashboard.
• curl: (97) Can't complete SOCKS5 connection — curl reached something that is not a SOCKS5 endpoint. Confirm you are on the SOCKS5 port and not the HTTP one.
• Works in curl, fails in the browser — Most browser proxy fields accept HTTP(S) only. Either use the HTTP endpoint or configure SOCKS5 at the operating-system or client level.
• Repeated 403 or 429 from a target site — The site is rate-limiting the address or the session. Slow the request rate, or hold one session for a longer sequence instead of rotating on every request.
• Exit IP never changes — A sticky session is active, or the selected pool is geographically narrow. Use the dashboard's session controls to request a different exit.
• HTTPS works but pages still show your local region — DNS is resolving locally. Switch to socks5h/--socks5-hostname, or move the client into a full-tunnel configuration.
• Shadowsocks client will not start — Usually a mistyped cipher or key. Paste the generated configuration instead of transcribing it, and make sure the local listening port you chose is not already in use.
• Charges climbing unexpectedly — Pay-as-you-go plans meter usage, so a runaway loop in a scraper or a browser syncing in the background can consume quota quickly. Check usage after your first verification run.

Summary

• Proxy type (residential, datacenter, ISP) chooses which IP you appear as; protocol (HTTP, SOCKS5, Shadowsocks) chooses how traffic is wrapped. Decide both deliberately.
• Copy the host, port, username, and password from the dashboard, percent-encode special characters, and build one URL format per protocol.
• Verify with a single curl request to an IP echo service before touching a browser or a script — it isolates credential errors from application errors.
• Use socks5h:// or --socks5-hostname whenever DNS privacy matters, and confirm the exit region with a trace request.
• Test rotation versus sticky sessions early, since that choice determines how your tooling should handle retries and logins.

Once a single verified request succeeds, the same credentials drop straight into a browser, a scraping library, or a proxy-chaining tool. IPRoyal is one reasonable provider for this workflow given its protocol range and billing options; the verification steps above apply to any provider you compare it against.