curl Fails but Browser Works: Compare Connection Paths

When curl fails but browser works, first compare the actual curl program, HTTPS request, proxy, and certificate trust path. A browser page loading does not show that the terminal sent the same request or received the expected response; preserve the exit code, HTTP status, and content evidence separately.

Key Takeaways:

• Confirm that the shell invokes curl rather than an alias or another program.
• A successful transfer can still return an HTTP error or a login page.
• Browser and curl trust stores can differ; keep certificate verification enabled.
• Change one input at a time and validate the original read-only request after a route comparison.

What should you prepare before comparing requests?

Choose an HTTPS URL you own or are authorized to test. Confirm that its endpoint is read-only, small, and safe to repeat, then record its expected status and a harmless content marker. Do not diagnose connectivity by repeating a payment, deletion, message submission, or expensive job.

Keep the original failing command in a private local record. Identify its method, headers, request body, redirects, proxy options, and expected destination without publishing credentials or signed query parameters. A shorter diagnostic command is useful only when its differences from the original are explicit.

Record the operating system, shell, curl version, execution host, timestamp, and network used. If the same failure affects several applications, follow the device and app fault-isolation sequence before making tool-specific changes. A remote SSH terminal also runs curl on the remote computer, even when your browser is local.

Step 1: Which binary has the curl fails but browser works problem?

Check the program your shell resolves. In a POSIX shell, inspect command -v curl; in PowerShell, use Get-Command curl and review the command type. If your intended program is an executable, call its approved path explicitly; on Windows, curl.exe --version helps distinguish it from a same-name alias.

Run the actual executable with --version and record the output privately. The reported TLS backend and build capabilities help explain why two curl installations can behave differently. Do not assume that an executable bundled with a development tool has the same certificate integration as the operating system's copy.［3］

Avoid downloading a random replacement binary merely to make the request work. If an update is needed, use the platform's approved installation mechanism and preserve the original version information. Diagnose the initial failure before introducing a version change, since an upgrade and a route change in the same attempt cannot be separated afterward.

Check where the terminal runs. A container, remote host, or CI runner has its own environment and trust configuration. Naming the real execution host is part of the comparison, not an optional detail; a local browser is not its network baseline.

Step 2: Are the browser and curl making equivalent requests?

Use the same approved HTTPS hostname and path, and compare the method and authentication contract. Loading a site's homepage is different from querying its API or downloading a protected resource. A browser can also show cached content or use an existing login session, so record what actually proves a new request succeeded.

This illustrative command performs a bounded GET and keeps headers and body in local files. Run it only after replacing the placeholder with an approved read-only URL and choosing a private working directory. It does not follow redirects automatically:

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header response-headers.txt --output response-body.bin \
  --write-out 'HTTP=%{http_code}\n' \
  'https://example.com/'

The 5-second connection and 20-second overall limits are example diagnostic budgets, not universal service requirements. Keep the chosen values unchanged across your comparison. The saved files can contain cookies, account details, or confidential data even when the command line has no secrets, so inspect them locally and never attach them unredacted.［3］

Do not replace GET with HEAD just to make a quick test pass. Servers can implement the two methods differently, and a headers-only response does not verify a download body. Likewise, adding arbitrary browser headers or copying cookies changes the experiment and can conceal an authentication issue rather than repair a connection.

Step 3: What do the exit code and HTTP status prove?

Capture the process exit status immediately after the command. In a POSIX shell, inspect $?; in PowerShell, inspect $LASTEXITCODE after the native executable. Do not insert another command first or use a pipeline that silently substitutes a different program's status.

curl normally treats an HTTP error response as a completed transfer unless options such as --fail change that behavior. Therefore, exit zero is not enough to establish application success. The command's recorded HTTP code and locally inspected expected content provide separate evidence.［3］

Evidence	What to investigate	What not to conclude
Exit 5 or 6	Proxy or destination name resolution	That browser success identifies the DNS cause
Exit 7	Connection establishment	That the server application handled the request
Exit 28	A configured wait expired	That every timeout occurred at the same phase
Exit 60	Certificate verification	That disabling TLS is a valid fix
Exit 0 with HTTP 401, 403, or 5xx	HTTP responder and application result	That the requested operation succeeded

Use the complete local error context to interpret the code; a proxy can be the responder or the source of a connection failure. For exit 28, record which budget was reached and whether any HTTP status was received. For an HTTP error, investigate the response's meaning and the service's supported authentication rather than repeating network changes blindly.

If you receive a redirect, first inspect its approved destination. Do not add --location indiscriminately to a command with sensitive headers or credentials. Follow the service's documented redirect behavior and verify the final content; a redirect to a sign-in page is not the expected API result.［1］

Step 4: Are curl proxy environment variables or trust settings different?

Compare command-line proxy options, relevant environment settings, and curl's configuration file. Inspect the source privately instead of printing all environment values. The official tutorial describes proxy environment variables; the actual invocation can also contain an explicit proxy or bypass rule, so preserve the effective inputs in your notes.［1］

A browser's system proxy is another layer. Use the Windows proxy configuration checklist or Mac network service proxy guide to inspect it. Do not assume every terminal tool automatically inherits those settings, and do not remove an organization-mandated proxy or bypass list to produce a successful screenshot.

A curl certificate error requires checking the executable's TLS backend, approved CA source, requested hostname, and any organizational inspection certificate. curl builds can use different native or file-based trust arrangements, while the browser can use a separate store. Get the administrator's approved CA configuration rather than substituting an unfamiliar bundle.［2］

Keep certificate and hostname verification enabled. Do not use --insecure, edit the hostname to avoid a mismatch, or disable endpoint protection. If trust is wrong, a route comparison without repairing the approved trust configuration cannot establish that the HTTPS service is safe to use.

Step 5: Does an approved alternate exit change the transfer?

Use this comparison for a genuine transport failure after confirming the intended request, proxy policy, and TLS setup. On the computer executing the terminal command, connect AethoVPN and enable global mode, then select a suitable available home-country or nearby position in the app. Repeat the exact curl invocation and compare its exit status, HTTP status, and expected body; leave timeout, method, headers, and proxy configuration unchanged.

For the execution machine, Windows uses the official installer and Linux support is the Debian/Ubuntu x64 .deb; a Mac uses configuration from the website's setup wizard with Pro or Premium. If curl runs through SSH, inside a container, or in CI, verify that environment's actual path separately instead of claiming the laptop's global mode covered it.

Changing the terminal's exit path does not install a missing trusted CA, provide browser login credentials, or grant access to a restricted API. To try this local transport comparison, start the 3-day Pro trial with email-code registration and no password; the trial is available once per user.

The tunnel checks to run before retrying curl can confirm connection preparation, but the original curl result remains the acceptance test. If the same private proxy cannot be reached through the alternate path, stop and obtain an approved route from its owner. Do not silently remove the proxy and call that the same experiment.

Write down the before-and-after request identity and timing. A single successful transfer supports a narrower conclusion that this attempt worked through this path. It does not prove the earlier cause was DNS, that every application uses the route, or that future requests will always succeed.

Step 6: How should you restore settings and share evidence?

Restore temporary request or proxy changes after the controlled comparison. Preserve the intended TLS configuration and organizational controls. Keep your notes concise: actual executable, version and TLS backend, execution environment, sanitized destination, timeout values, effective proxy source, exit code, HTTP code, and expected-content result.

If curl works but a Postman request still times out, examine its Agent and Console rather than copying the successful command as proof that all clients work. If the remaining failure is in Python's connection or response wait, align the interpreter, Session, and proxy configuration before comparing it with curl.

Use verbose output only when needed for private diagnosis. Before sharing it, remove Authorization and Cookie headers, tokens, signed query strings, proxy credentials, private addresses, personal identifiers, and sensitive bodies. Do not publish a browser-exported curl command; it can embed far more state than its visible URL suggests.

Stop if repeated attempts add no evidence, a service rate limit appears, or the operation's safety is uncertain. Confirm the state of any original non-idempotent operation with its owner. The purpose is a repeatable failure record, not an unlimited retry loop or a way to evade access rules.

Summary

• Identify the executable and execution environment.
• Compare the real request rather than a site's unrelated page.
• Read exit status, HTTP status, and content as separate results.
• Keep trust and proxy policy intact during a route test.
• Restore temporary settings and share only sanitized evidence.

FAQ

Can a shell alias explain the difference?

Yes, the name curl can resolve to a different command or wrapper. Inspect the command type and intended executable, then record its version before comparing its behavior with the browser.

Should I copy the browser's Cookie header?

Use the service's supported authentication mechanism instead. Browser cookies can expose your session and change the request's authorization context, making the comparison unsafe and technically different.

Does exit zero mean the API succeeded?

Exit zero can mean that the transfer completed while the server returned an error or login page. Verify the expected HTTP status and content rather than relying on the process result alone.［3］

Can proxy settings come from the environment?

Yes, curl supports proxy environment variables as well as other configuration inputs. Inspect their source privately and keep any administrator-required routing policy when designing the comparison.［1］

Why can the browser trust a certificate that curl rejects?

Different builds can use different TLS backends and trust stores. Ask the administrator to align the approved CA configuration without disabling certificate or hostname verification.［2］

Should I follow every redirect automatically?

Inspect the intended destination and the service's documented behavior first. Redirects can lead to login or error pages, and commands containing sensitive headers require particular care before following them.

Is verbose output safe to attach to a ticket?

Not without review: it can reveal credentials, request headers, private infrastructure, and signed URLs. Share a sanitized excerpt with the relevant stage and codes rather than an entire trace or browser export.

Disclaimer: Use authorized endpoints and diagnostic routes, comply with local laws and organizational controls, and protect request data. The command illustrates a method; it does not report measured results or guaranteed connectivity.

Sources:

1. curl — Tutorial — https://curl.se/docs/tutorial.html
2. curl — SSL CA Certificates — https://curl.se/docs/sslcerts.html
3. curl — How To Use — https://curl.se/docs/manpage.html

Sources checked 7 October 2026.

---

Related Articles:

• Identify the Postman runtime behind a failed request
• Separate Python connection and read timeouts
• Trace a Windows proxy setting to its source
• Compare the Mac network service's proxy configuration
• Verify the connection before retesting the terminal request