cURL Proxy Errors: Fix Proxy Format, Auth, 407, Timeout and SOCKS Issues

Symptoms you usually see

• You see an HTTP 407 response, HTTP code 000, or a curl error such as 5, 7 or 28.
• The proxy works in a browser but not in cURL.
• SOCKS proxy syntax fails with an HTTP-style command.
• Special characters in credentials break the proxy URL.

Match the result to the failing step

See the official curl exit-code reference. The error message matters as much as the number.

Fix workflow

1. Run the configuration below from the affected machine with one proxy and one simple HTTPS destination.
2. Read the curl exit status together with the HTTP and CONNECT codes. Locate the first failed step in verbose output.
3. Correct the matching setting: address and port, proxy authentication, source-IP allowlist, protocol or certificate trust.
4. Compare a direct request to the same destination. Keep its URL unchanged while isolating the proxy route.
5. Move the working settings into your application and repeat the same request before restoring normal traffic.

Authentication and TLS checks

--proxy-user supplies proxy credentials; --user supplies destination-server credentials. They are separate. For an IP-authenticated proxy, confirm the affected machine’s current public IP is allowed. A working test from another machine does not establish that.

The proxy scheme describes the connection to the proxy. An http:// proxy can carry an HTTPS destination through CONNECT; changing it to https:// requires a proxy endpoint that actually supports TLS. For certificate errors, correct the trust store, hostname or certificate chain. Avoid making --insecure or --proxy-insecure the permanent workaround.

Before sharing a diagnostic log, remove passwords, authorization headers, cookies and sensitive URL parameters. Keep the timestamp, curl version, sanitized proxy host/port, target hostname and error message.

Run a reproducible proxy test

Create a plain-text file named proxy-check.conf. Replace PROXY_HOST and PORT with your supplied HTTP proxy endpoint. The example destination is public; use a small URL you control when testing your own service.

proxy = "http://PROXY_HOST:PORT"
noproxy = ""
connect-timeout = 5
max-time = 20
verbose
output = "proxy-check-body.txt"
write-out = "\nhttp=%{http_code} connect=%{http_connect}\n"
url = "https://example.com/"

For username/password authentication, add this line using your own credentials. Keep the file private and out of source control. The colon separates username from password; in quoted config values, escape a literal double quote or backslash with a backslash.

proxy-user = "PROXY_USER:PROXY_PASSWORD"

Run from the directory containing the file. On Linux or macOS:

curl --disable --config proxy-check.conf
printf 'exit=%s\n' "$?"

In Windows PowerShell, invoke the executable explicitly:

curl.exe --disable --config proxy-check.conf
$LASTEXITCODE

--disable is first so curl ignores its default config. The empty noproxy value prevents an inherited bypass list from silently skipping this proxy. Received body data is written to proxy-check-body.txt. An early failure can leave an older file unchanged; a later failure can leave partial data. Check this run’s exit status and response codes. Clear or rename the test file before repeating if you need to inspect its body.

Read HTTP, CONNECT and exit status together

http=200 connect=200 with exit 0 means this HTTP-proxy tunnel and request succeeded. It does not prove every destination will accept the proxy. For an HTTPS request refused by an HTTP proxy, you may see http=000 connect=407: the tunnel was rejected before a destination response arrived. For a SOCKS request, connect=000 is expected because there is no HTTP CONNECT exchange.

The test intentionally omits --fail, so a received HTTP 4xx/5xx response is not by itself a nonzero curl exit status. Check the reported HTTP code too. The write-out guide explains curl’s result fields.

Compare the direct route

Rerun with --noproxy "*" after the config argument to bypass the proxy for this test. Use curl.exe in PowerShell.

curl --disable --config proxy-check.conf --noproxy "*"

If direct access works but the proxy route fails, investigate the proxy connection and its destination access. If both fail, inspect the target, local network and TLS details before changing providers. Check the exit status immediately after each run.

Test SOCKS5 with the correct DNS mode

For a SOCKS5 endpoint, change only the config’s proxy value to socks5h://PROXY_HOST:PORT, using the supplied SOCKS port. With socks5h://, the proxy resolves the destination hostname; with socks5://, curl resolves it locally. This distinction can explain why one mode fails. Neither setting guarantees that a destination will permit access. See the official SOCKS proxy guide.

Option details and config escaping are documented in the curl manual; proxy and server credentials are distinguished in the proxy authentication guide.

FAQ