This cURL proxy guide explains HTTP tunneling, cURL proxy authentication, cURL proxy username password handling, a cURL SOCKS5 proxy, the cURL SOCKS5h DNS choice, cURL proxy environment variables, cURL NO_PROXY rules, and a repeatable cURL proxy command for diagnostics.<\/p>\n
To use a proxy with cURL, pass its URL with A successful command is only one piece of evidence. Reliable cURL proxy testing distinguishes the client-to-proxy connection, proxy authentication, DNS resolution, the proxy-to-destination connection, TLS validation, and the destination’s HTTP response. The examples below use reserved The smallest useful cURL proxy command identifies the proxy scheme, proxy host, proxy port, destination, and time budget. The Everything curl proxy overview<\/a> documents For an HTTPS destination reached through an HTTP proxy, cURL normally asks the proxy to create a tunnel with the HTTP CONNECT method. The destination TLS session then travels through that tunnel. The official HTTP proxy chapter<\/a> explains this behavior. The proxy scheme and destination scheme describe different legs of the route, so an Keep certificate verification enabled. Options such as Use This is cURL proxy authentication, not application login. A proxy commonly returns HTTP 407 when credentials are missing, invalid, or unacceptable for the requested method. A destination commonly returns 401 or 403 for its own authorization rules. Record which hop produced the response before rotating a password or changing application credentials. The broader proxy authentication methods guide<\/a> compares username\/password access with source-IP allowlisting.<\/p>\n The phrase cURL proxy username password often leads to examples with credentials embedded directly in a URL. That can leak through shell history, process listings, screenshots, logs, or copied support tickets. Separate variables improve readability but are not automatically a secure vault. Inject secrets through the operating system, container platform, or CI secret mechanism, restrict access, and redact command traces. Never enable shell tracing around a credential-bearing command.<\/p>\n A cURL SOCKS5 proxy can resolve the destination hostname on either side of the connection. With Use cURL SOCKS5h when remote DNS is required for a split-DNS environment, an internal destination known only to the proxy-side resolver, or a controlled test that must avoid local destination lookups. Use local DNS when that is the intended architecture. Neither choice alone proves privacy or suitability. Compare protocol capabilities in the HTTP versus SOCKS5 guide<\/a>, then validate the actual application path.<\/p>\n DNS can still occur outside the expected path through the application, an operating-system helper, a browser feature, or a second connection. A command-line test covers cURL’s request, not every program on the device. If DNS exposure matters, use the proxy DNS and WebRTC leak guide<\/a> to define what must be observed and where.<\/p>\n cURL proxy environment variables are useful for package jobs, maintenance scripts, and controlled command sessions. According to the official environment variable documentation<\/a>, cURL checks scheme-specific variables such as Command-line options are easier to audit for a one-off diagnostic because the route is visible beside the request. Environment variables are helpful when several commands intentionally share a policy, but they can also create surprising behavior in child processes or scheduled jobs. Document where they are set, scope them to the smallest practical process, and clear them after the test. Do not assume that a browser, SDK, or language runtime interprets the same names identically.<\/p>\n A cURL NO_PROXY value is a comma-separated list of hosts or domains that should bypass the configured proxy. It can also contain IP addresses and, in current cURL versions, CIDR network notation. A leading dot is commonly used to match a domain suffix. The exact rule matters because bypassed traffic leaves directly and will not use proxy authentication, proxy DNS, or proxy egress.<\/p>\n Do not use a wildcard bypass merely to make a failing command work. Begin with the exact owned host, confirm why direct routing is required, and review the rule as a network-policy exception. If the direct request still fails, compare DNS, firewall, certificate trust, and destination authorization rather than widening the list. The proxy troubleshooting guide<\/a> provides a hop-by-hop diagnostic order.<\/p>\n A robust check should produce structured evidence without printing secrets or complete response bodies. cURL’s The remote address reported by cURL must be interpreted in context: with an HTTP proxy, it may be the proxy endpoint rather than the final site’s address. Your approved diagnostic endpoint should return the source address it observes in a minimal response, allowing you to compare the expected egress. The article on how to check whether a proxy is working<\/a> separates connectivity, identity, location, DNS, and stability checks.<\/p>\n Run a direct baseline first, then one proxied request, then a small bounded sample. Classify failures instead of averaging them away. A connection failure before authentication, an HTTP 407, a TLS validation error, a destination 403, and a read timeout need different corrections. Store timestamps, cURL version, destination name, expected route, response class, and timings, while redacting proxy credentials, tokens, cookies, query strings, and personal data.<\/p>\n Start with If the same route works in cURL but fails in application code, compare how the application handles environment variables, authentication, certificates, redirects, and DNS. The Python Requests proxy guide<\/a> demonstrates the corresponding client configuration. cURL is an excellent controlled probe, but it does not reproduce every browser or SDK behavior.<\/p>\n Before turning a successful command into a job, define the authorized destinations, allowed request rate, data minimization rules, error budget, retry policy, secret rotation process, and owner. Prefer a documented API when one exists. Respect destination terms, robots guidance where applicable, privacy requirements, and rate limits. A proxy changes routing; it does not grant permission or remove responsibility for the traffic.<\/p>\n If you are still choosing an endpoint, use the proxy selection checklist<\/a> to map protocol, authentication, location, concurrency, and support requirements. You can then compare those requirements with Mexela’s private proxy service<\/a> instead of selecting a plan from one command alone.<\/p>\n Pass an explicit proxy URL with Use With Use the lowercase Compare a direct baseline with a proxied request to an approved endpoint that reports the source address it observes. Record status and timing data with Configure a cURL proxy with HTTP or SOCKS5, separate proxy credentials safely, control environment variables and bypass rules, and verify each network hop.<\/p>\n","protected":false},"author":1,"featured_media":462,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[189],"tags":[196,190,191,197,195,192,193,194],"_links":{"self":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/posts\/463"}],"collection":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/comments?post=463"}],"version-history":[{"count":1,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/posts\/463\/revisions"}],"predecessor-version":[{"id":464,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/posts\/463\/revisions\/464"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/media\/462"}],"wp:attachment":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/media?parent=463"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/categories?post=463"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/tags?post=463"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}--proxy<\/code>, supply proxy credentials separately with --proxy-user<\/code>, set explicit connection and total time limits, and verify the observed route against an endpoint you own or are authorized to test. Use socks5h:\/\/<\/code> when the proxy should resolve the destination hostname, and use NO_PROXY<\/code> only for destinations that must intentionally bypass the proxy.<\/p>\n.invalid<\/code> hostnames and environment variables so they do not expose a real endpoint, password, or customer destination. Replace them only inside an approved test environment.<\/p>\nStart with an explicit HTTP proxy command<\/h2>\n
-x<\/code> and --proxy<\/code>. If the proxy URL has no scheme, cURL treats it as HTTP, but writing http:\/\/<\/code> explicitly makes reviews and incident evidence clearer.<\/p>\nexport PROXY_URL=\"http:\/\/proxy.example.invalid:3128\"\nexport APPROVED_TEST_URL=\"https:\/\/status.example.invalid\/proxy-check\"\n\ncurl --proxy \"$PROXY_URL\" \n --connect-timeout 5 \n --max-time 20 \n --fail-with-body \n --silent --show-error \n \"$APPROVED_TEST_URL\"<\/code><\/pre>\nhttps:\/\/<\/code> destination does not automatically require an https:\/\/<\/code> proxy endpoint.<\/p>\n--insecure<\/code> can make a broken trust path appear healthy and are deliberately absent from these examples. If an approved enterprise gateway inspects TLS, install the correct trusted certificate chain for that environment instead of suppressing validation.<\/p>\nSeparate proxy authentication from destination authentication<\/h2>\n
--proxy-user<\/code> for the proxy’s username and password. The shorter form is -U<\/code>. -u<\/code> is for destination credentials and is a separate concern, and mixing the two can send a secret to the wrong authentication layer. The official proxy authentication guide<\/a> documents the distinction and the available proxy authentication options.<\/p>\nexport PROXY_URL=\"http:\/\/proxy.example.invalid:3128\"\nexport PROXY_USERNAME=\"approved-user\"\nexport PROXY_PASSWORD=\"read-from-a-secret-store\"\nexport APPROVED_TEST_URL=\"https:\/\/status.example.invalid\/proxy-check\"\n\n# Short equivalent for proxy credentials:\ncurl -U \"$PROXY_USERNAME:$PROXY_PASSWORD\" --proxy \"$PROXY_URL\" \"$APPROVED_TEST_URL\"\n\ncurl --proxy \"$PROXY_URL\" \n --proxy-user \"$PROXY_USERNAME:$PROXY_PASSWORD\" \n --proxy-anyauth \n --connect-timeout 5 \n --max-time 20 \n --silent --show-error \n \"$APPROVED_TEST_URL\"<\/code><\/pre>\nChoose SOCKS5 or SOCKS5h from the DNS requirement<\/h2>\n
socks5:\/\/<\/code>, cURL resolves the destination hostname locally. With socks5h:\/\/<\/code>, the hostname is sent to the proxy for resolution. The final h<\/code> is therefore an operational DNS decision, not a cosmetic spelling difference. The official SOCKS proxy documentation<\/a> describes both forms.<\/p>\nexport SOCKS_PROXY_HOST=\"proxy.example.invalid:1080\"\nexport APPROVED_TEST_URL=\"https:\/\/status.example.invalid\/proxy-check\"\n\ncurl --socks5-hostname \"$SOCKS_PROXY_HOST\" \n --connect-timeout 5 \n --max-time 20 \n --silent --show-error \n \"$APPROVED_TEST_URL\"<\/code><\/pre>\nUse proxy environment variables deliberately<\/h2>\n
http_proxy<\/code> and HTTPS_PROXY<\/code>, then ALL_PROXY<\/code> as a general fallback. The lowercase form of http_proxy<\/code> is intentionally required; cURL does not accept uppercase HTTP_PROXY<\/code> because of long-standing security concerns around CGI environments.<\/p>\nexport http_proxy=\"http:\/\/proxy.example.invalid:3128\"\nexport HTTPS_PROXY=\"http:\/\/proxy.example.invalid:3128\"\nexport ALL_PROXY=\"socks5h:\/\/proxy.example.invalid:1080\"\nexport NO_PROXY=\"localhost,.internal.example.invalid\"\n\ncurl --connect-timeout 5 \n --max-time 20 \n --silent --show-error \n \"https:\/\/status.example.invalid\/proxy-check\"<\/code><\/pre>\nDefine NO_PROXY bypass rules narrowly<\/h2>\n
export HTTPS_PROXY=\"http:\/\/proxy.example.invalid:3128\"\nexport NO_PROXY=\"localhost,.internal.example.invalid\"\n\ncurl --noproxy \"$NO_PROXY\" \n --connect-timeout 3 \n --max-time 10 \n --silent --show-error \n \"https:\/\/health.internal.example.invalid\/ready\"\n\nunset HTTPS_PROXY NO_PROXY<\/code><\/pre>\nRecord status, timings, and the observed route<\/h2>\n
--write-out<\/code> option can report the HTTP response code, remote address, connection time, TLS time, and total duration. The official cURL manual<\/a> is the authoritative reference for these variables and for the options available in the installed cURL version.<\/p>\nexport PROXY_URL=\"http:\/\/proxy.example.invalid:3128\"\nexport APPROVED_TEST_URL=\"https:\/\/status.example.invalid\/proxy-check\"\n\ncurl --proxy \"$PROXY_URL\" \n --connect-timeout 5 \n --max-time 20 \n --output \/dev\/null \n --silent --show-error \n --write-out 'status=%{response_code} remote=%{remote_ip} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}n' \n \"$APPROVED_TEST_URL\"<\/code><\/pre>\nDiagnose common cURL proxy failures by layer<\/h2>\n
curl --version<\/code> so the installed protocols and features are known. Then test the destination directly if policy allows, verify that the proxy host and port are reachable, add authentication, and finally compare DNS and TLS behavior. Change one variable at a time. A verbose trace can expose headers and secrets, so use it only in a protected environment, capture the smallest necessary interval, and sanitize it before sharing.<\/p>\n\n
Build a responsible production checklist<\/h2>\n
\n
--proxy-user<\/code> only for proxy authentication.<\/li>\nsocks5<\/code> or socks5h<\/code> from the DNS design.<\/li>\nFrequently asked questions<\/h2>\n
How do I set a proxy in cURL?<\/h3>\n
--proxy<\/code> or -x<\/code>, add connection and total timeouts, and request an owned or approved test endpoint. For example, an HTTP proxy URL can carry an HTTPS destination through a CONNECT tunnel.<\/p>\nHow do I add proxy authentication without confusing it with site login?<\/h3>\n
--proxy-user<\/code> or -U<\/code> for proxy credentials. Keep destination authorization separate, load secrets from a protected mechanism, and diagnose an HTTP 407 as a proxy-layer response.<\/p>\nWhat is the difference between socks5 and socks5h in cURL?<\/h3>\n
socks5:\/\/<\/code>, cURL resolves the destination hostname locally. With socks5h:\/\/<\/code>, the proxy resolves it. Choose from the intended DNS architecture and verify the observed path.<\/p>\nWhich cURL proxy environment variables should I use?<\/h3>\n
http_proxy<\/code> variable for HTTP destinations, scheme-specific variables such as HTTPS_PROXY<\/code>, or ALL_PROXY<\/code> as a fallback. Scope them narrowly because child processes can inherit them.<\/p>\nHow does NO_PROXY work with cURL?<\/h3>\n
NO_PROXY<\/code> lists hosts, domain suffixes, addresses, or supported network ranges that should connect directly. Every entry is a bypass exception, so keep the list narrow and verify that direct routing is intentional.<\/p>\nHow can I verify that cURL actually used the proxy?<\/h3>\n
--write-out<\/code>, then classify authentication, TLS, destination, and timeout failures separately.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"