How to connect HTTP and SOCKS5 proxies with curl
Build a repeatable curl proxy test: use the correct gateway and credentials, compare HTTP and SOCKS5 DNS behavior, and verify responses before scaling.
KAIROXO
A working proxy integration begins with one request you can explain. curl is useful for that first test because you can separate the gateway, proxy authentication, target URL and response. Once the request works, the same settings become a reference for your browser, application or data pipeline.
This tutorial builds that reference in five steps. KAIROXO product pages describe the protocols supported by each access type; copy the actual connection details from the selected product and console. The hostnames, usernames and ports below are placeholders, not live KAIROXO endpoints. Test against a page you own or are permitted to access, then review the result before adding parallel requests.
Before you run the first command
Prepare the proxy host, port, full generated username and password, an authorized HTTPS target, and the protocol enabled for your product. Preserve targeting or session segments in a generated username. Read the quickstart and authentication guide if any value is unclear. Record which product and region you are testing so that later comparisons use the same setup.
Five steps to a repeatable proxy request
Check curl and choose a small test target
Run the version command first and confirm which curl executable your terminal uses. On Windows PowerShell, use curl.exe if curl points to a shell alias. The examples are single-line commands so they do not depend on Bash continuation characters. A small HTTPS page is enough to test connectivity; a successful download does not yet prove the requested region or session behavior.
Keep the target constant while testing protocols. If the target itself is unavailable, a proxy comparison becomes misleading. Use your own diagnostic endpoint if you need to record the source IP. The example.com address below is only a neutral illustrative target, not an exit-IP verification service.
proxy-test.shsh curl --versionSend an HTTPS request through an HTTP proxy
Use --proxy for the gateway and --proxy-user for proxy credentials. Replace all four placeholders with values from your console. Keep the target URL separate from the proxy URL; HTTPS in the target does not automatically mean the proxy endpoint itself uses HTTPS. curl establishes an HTTP CONNECT tunnel for an HTTPS target through an HTTP proxy. See the official HTTP proxy guide.
If your selected product supplies an HTTPS proxy endpoint, use its documented scheme rather than changing it by guesswork. Do not put proxy credentials into the target website URL or send them as target-site login credentials. A target login and a proxy login solve different problems.
proxy-test.shsh curl --proxy "http://PROXY_HOST:PROXY_PORT" --proxy-user "PROXY_USERNAME:PROXY_PASSWORD" --connect-timeout 10 --max-time 30 "https://example.com/"Compare SOCKS5 with local and proxy DNS
For a SOCKS5 endpoint, choose the scheme deliberately: socks5:// resolves the target hostname locally, while socks5h:// asks the proxy to resolve it. The extra h changes DNS handling, not the selected account or product. These two variants are documented in the official SOCKS guide.
Start with one variant and record which you used. When diagnosing a DNS problem, compare it with the other variant while keeping the gateway, credentials and target unchanged. Different results help narrow the investigation; they do not by themselves establish a network fault. HTTP proxy ports and SOCKS5 ports may differ, so use the values returned for the chosen protocol.
proxy-test.shsh curl --proxy "socks5h://PROXY_HOST:PROXY_PORT" --proxy-user "PROXY_USERNAME:PROXY_PASSWORD" --connect-timeout 10 --max-time 30 "https://example.com/"Inspect the response instead of judging by a downloaded page
Save the body and headers separately, and add a compact timing summary. --write-out can print transfer metadata; see the official write-out guide. Read the final HTTP status together with curl's exit result. A program can complete a transfer even when the website returns an error page, so body text alone is not a sufficient acceptance check.
For an HTTP proxy, a successful CONNECT response is also not the same as a successful target response. Inspect the final response and expected content. These timing values describe this test run, not a service benchmark. Repeat a few low-volume requests before deciding whether a difference is consistent.
proxy-test.shsh curl --proxy "http://PROXY_HOST:PROXY_PORT" --proxy-user "PROXY_USERNAME:PROXY_PASSWORD" --connect-timeout 10 --max-time 30 --silent --show-error --dump-header response-headers.txt --output response-body.html --write-out "status=%{http_code} connect=%{time_connect}s total=%{time_total}s\n" "https://example.com/"Validate region and session settings before moving into your app
Use an authorized diagnostic endpoint to observe the exit IP, then check the chosen region using the method required by your task. Test a generated sticky-session configuration separately from a rotating configuration; do not infer rotation from one request. Preserve the complete username when copying a working example into another client, and keep a redacted configuration record.
Choose a small request budget, stop on repeated errors, and decide what counts as success before increasing concurrency. For workflows that depend on continuity, read rotating versus sticky sessions. For location checks, continue with the localization testing workflow.