Source: https://miproxy.io/guides/curl-proxy-guide Updated: 2026-10-17 # How to use a proxy with cURL Configure an authenticated HTTP proxy in cURL with timeouts, TLS verification and a focused connection troubleshooting checklist. ## Quick answer Pass the proxy endpoint with --proxy and authenticate with --proxy-user. Start with one authorized request and explicit timeouts. The template below deliberately uses .invalid hosts and cannot connect until you replace them. ## Introduction cURL is a useful first client because it makes the gateway, authentication and timeout choices visible in one request. Start with that small connection check before adding browser automation or a larger collection job. The example here uses reserved .invalid names. Replace them with documented allocation details and an endpoint you are allowed to request. A command that parses correctly is not evidence of a live MiProxy route. ## Editorial disclosure Examples contain placeholders and were not run against a production MiProxy allocation for this guide. Official cURL documentation supports the option semantics. No destination coverage, throughput or uptime is asserted. ## How this guide was researched Protocol guidance based on the official cURL manual and proxy-authentication documentation. This is a configuration template and diagnostic sequence, not a current-allocation connection test. - Gateway transport versus destination URL scheme. - Explicit proxy authentication without literal secrets in examples. - Bounded requests with destination certificate verification preserved. - Separating proxy errors from DNS, connection and destination failures. ## Collect the connection details You need an active allocation, its gateway host, port, protocol and proxy username. Proxy credentials can differ from your account login. Use an endpoint you are authorized to request and whose expected output you understand. These are protocol templates, not a live MiProxy allocation test. Confirm the connection details in the portal before replacing the placeholders. curl --version shows your installed version and supported protocols. ## Make one bounded HTTPS request For a normal HTTP proxy, an HTTPS destination still uses an http:// proxy URL: cURL establishes a CONNECT tunnel and verifies the destination’s TLS certificate. An HTTPS proxy is a separate capability that must be supported by the gateway. With only a username supplied to --proxy-user, cURL prompts for the proxy password interactively. This avoids putting a literal password into the example or shell history. Use a secret store for unattended jobs. ```bash # Replace both .invalid hosts and the example port before use. curl --proxy 'http://gateway.invalid:8080' \ --proxy-user 'YOUR_PROXY_USERNAME' \ --connect-timeout 10 \ --max-time 30 \ --fail-with-body \ --url 'https://check.invalid/ip' ``` ## Verify the result, then the route A successful response should match the permitted endpoint’s documented output. If it reports an IP address, compare that observation with your intended route. One request demonstrates that connection at that moment; it does not measure pool size, long-term stability or every destination. Keep TLS verification enabled. Do not add --insecure to hide a certificate error. Confirm the hostname, your system trust store and any organization-approved certificate requirements instead. ## Understand the two connections Your client first reaches a proxy gateway. The gateway then provides the route to the destination. A failure before reaching the gateway differs from a response returned by the destination. Keep those stages separate when interpreting an error. ## Understand the two connections: The gateway URL describes gateway transport An http:// gateway URL does not mean the requested website must use HTTP. For an HTTPS destination, an HTTP proxy can establish a CONNECT tunnel. The client then verifies the destination certificate. An https:// gateway URL adds a separate gateway transport requirement; use it only when your selected endpoint documents support. ## Understand the two connections: Check where a name-resolution failure occurs The gateway hostname and destination hostname are different names with different roles. Record which name failed, the selected proxy mode and the cURL exit information. Replacing a password cannot resolve an invalid gateway hostname. Switching TLS verification off cannot repair DNS or make an unsupported port work. ## Keep connection troubleshooting separate from secret handling An interactive password prompt is convenient for a first request because the command itself does not contain a password. Unattended tasks need a deliberate secret-delivery method appropriate to their environment. Copying a full credential-bearing command into chat, a ticket or a repository creates unnecessary exposure. ## Keep connection troubleshooting separate from secret handling: Be precise about credential formats A separate proxy-user option and a credential-bearing URL have different parsing boundaries. Follow the cURL manual for your chosen form and quote shell arguments deliberately. If you change formats while troubleshooting, record the sanitized structure so you can distinguish an encoding problem from incorrect credentials. ## Keep connection troubleshooting separate from secret handling: Share a useful sanitized record A support record can contain time, cURL version, gateway hostname without secrets, destination category, selected protocol, timeout values and the resulting status or exit code. If verbose output is required, review it locally before sharing. Remove authentication values, cookies and private destination parameters. ## A returned page is the start of verification After the first response, check its body against the endpoint’s documented expected output. A status alone cannot establish that the result is useful. For a connection-check endpoint, inspect the reported observation rather than assuming the selected country or session setting proves the route. ## A returned page is the start of verification: tradeoffs ### Where it helps - A small explicit command makes connection choices inspectable. - Separate timeout controls help bound a first diagnostic request. - The same sanitized command shape makes support discussions easier. ### What to account for - A working command against one endpoint does not validate other destinations. - Shell quoting, inherited configuration and credential formatting still need care. - Verbose traces can expose secrets if shared without review. ## Move from one request to a maintained workflow Once the bounded request gives the expected result, decide what your larger client needs to preserve: routing options, credential sourcing, timeouts, TLS trust and a rule for classifying output. Record those choices before raising concurrency. A working interactive command does not automatically configure a different client library. ## Move from one request to a maintained workflow: Add retries only for a defined condition Decide which transient errors may be retried and set an attempt limit. Do not repeatedly resend a bad password or turn a destination rate limit into a burst of new attempts. Keep each attempt visible so that a later report can distinguish first-pass output from recovered output. ## Move from one request to a maintained workflow: Use the intended trust configuration If an organization requires an approved certificate bundle, configure it using the documented cURL options and deployment process. Disabling verification hides an important check. Keep gateway transport and destination verification distinct when deciding which certificate or hostname an error concerns. ## Separate authentication, network and destination errors HTTP 407 points to proxy authentication; check gateway credentials and the permitted authentication method. A name-resolution failure or connection timeout belongs to a different layer. HTTP 403 or 429 from the destination requires inspecting destination access and rate limits. For support, record time, cURL version, sanitized command, status or exit code, and whether failure happens before or after connection. Verbose traces can contain secrets; redact them before sharing. ## Which approach should you choose? Prove one bounded request with the documented gateway first. Inspect the expected output before treating the connection as successful. ### First connection Use the gateway host, port and supported protocol from the active allocation; supply credentials separately. ### HTTPS destination through an HTTP gateway Use the documented HTTP proxy URL and retain destination TLS verification; CONNECT establishes the tunnel. ### Unexpected failure Classify the status or cURL error before changing credentials, trust settings or routing mode. ## Why use an HTTP proxy URL for an HTTPS website? The proxy URL specifies the transport to the gateway. An HTTP proxy can tunnel an HTTPS destination with CONNECT while the client verifies the destination certificate. ## Are these production MiProxy credentials? No. The .invalid hosts and example username are placeholders. This guide does not establish current live allocation availability. ## What does --proxy-user configure? It supplies credentials for authenticating to the proxy. These can differ from credentials for the destination website. Follow the gateway’s documented authentication method and avoid sharing a literal password in commands or traces. ## Does an HTTP proxy URL disable HTTPS certificate checks? No. The proxy gateway transport and destination certificate verification are separate. For a supported HTTP gateway and HTTPS destination, cURL can use CONNECT and still verify the destination certificate. ## Why use connection and total timeouts together? They bound different parts of the request. An explicit connection limit constrains establishment, while a total-time setting bounds the overall cURL operation. Review the manual for the installed version and chosen command. ## Sources - [curl: proxy authentication](https://everything.curl.dev/usingcurl/proxies/auth.html) — checked 2026-10-16 - [curl command-line manual](https://curl.se/docs/manpage.html) — checked 2026-10-16 ## Related reading - [Fix HTTP 407 Proxy Authentication Required](https://miproxy.io/guides/proxy-error-407) - [Use an authenticated proxy with Python Requests](https://miproxy.io/guides/python-requests-proxy-guide) - [Rotating vs. sticky proxies: match the session to the task](https://miproxy.io/blog/rotating-vs-sticky-proxies) - [Residential vs. datacenter proxies: choose by the job](https://miproxy.io/blog/residential-vs-datacenter-proxies) - [Non-expiring proxy bandwidth: what to check before buying](https://miproxy.io/blog/non-expiring-proxy-bandwidth)