Ways to Follow Redirects with curl

The command-line tool curl is a staple for testing web requests, debugging APIs, and automating downloads. One behaviour that trips up newcomers is redirects: by default curl shows you the first response it gets, even when that response is just an instruction to go somewhere else.

Modern websites redirect constantly, from HTTP to HTTPS, between regional domains, and through link shorteners. If you do not tell curl to follow those hops, you will see a short redirect response instead of the page you expected.

This guide explains how to make curl follow redirects properly, how to inspect the chain it takes, and how redirect handling interacts with proxies when you are testing how a site behaves from different locations.

Why curl Stops at the First Response

When a server wants to send you elsewhere, it replies with a 3xx status code such as 301 or 302 and a Location header pointing to the new address. By design, curl reports exactly what it received and does not automatically chase that pointer.

This is sensible default behaviour for a precise diagnostic tool. It lets you see the raw redirect response, including its status code and headers, which is often exactly what you want when debugging. The catch is that beginners expect to see the final page and instead get a near-empty body. Understanding that a redirect is itself a complete, valid response is the first step to handling it correctly.

The Core Flag for Following Redirects

To make curl follow redirects, add the location flag, written as -L or --location. With it, curl reads the Location header, issues a new request to that address, and repeats until it reaches a final, non-redirecting response.

• -L tells curl to follow each redirect to its destination.
• It works alongside other options, so you can combine it with headers, methods, and output flags.
• It is the single most common fix when curl appears to return an empty or unexpected page.

For most everyday use, adding this one flag is all you need to land on the final page rather than stopping at the first hop.

Inspecting the Full Redirect Chain

Sometimes you want to see every step a request takes, not just the final destination. Combining the verbose or include-headers options with location following lets you watch each hop, its status code, and the address it points to next.

This is invaluable when a redirect loop, an unexpected detour, or a downgrade from HTTPS to HTTP is causing problems. Seeing the chain laid out makes it obvious where things go wrong, such as a stray trailing slash or a region redirect you did not anticipate. Reading headers at each stage turns a confusing redirect into a clear, traceable sequence you can reason about and fix.

Limiting How Many Redirects to Follow

Redirect chains should be short, but misconfigured sites occasionally create loops or excessively long sequences. curl lets you cap the number of redirects it will follow so a runaway chain does not hang your command indefinitely.

Setting a sensible maximum is good hygiene for automated scripts, where an unexpected loop could otherwise stall a job. If curl reports that it hit the limit, that itself is useful information: it usually points to a configuration fault on the target rather than a problem with your request. Treating the cap as both a safety net and a diagnostic signal helps your scripts fail fast and clearly.

Handling Methods and Bodies Across Redirects

Redirects can change how a request is repeated. By default, certain status codes cause curl to switch a POST to a GET when following, which is often what the server intends but not always what you want. There are options that control whether the original method and body are preserved across the hop.

This matters most for API testing and form submissions, where dropping the request body or changing the method silently produces confusing results. When a redirected request does not behave as expected, checking how the method is being carried forward is a common culprit. Being explicit about method preservation removes a whole class of subtle bugs from your testing.

Saving the Final Page or File

Once curl follows redirects to the destination, you usually want to do something with the result, whether that is printing it, saving it to a file, or piping it onward. Combining location following with output options lets you capture the final content rather than the intermediate redirect responses.

For downloads behind a redirect, such as a file served through a shortener or a content delivery network, following the chain is essential to retrieve the actual asset. Naming the output sensibly and confirming you received the final page rather than a redirect stub helps you avoid the common mistake of saving an empty or near-empty response by accident.

Combining Redirects with Proxies

curl can route its requests through a proxy, which is useful when you want to test how a site redirects visitors from a particular region or network. Because some sites redirect based on the visitor's location, the chain you see can change depending on the IP address you appear to come from.

Passing a proxy to curl alongside the location flag lets you observe these geo-aware redirects directly. Our proxy use cases page covers scenarios like this. Choosing an appropriate proxy type matters, and availability can depend on the selected plan, so confirm the details before relying on a particular region.

Testing Geo-Based Redirects Reliably

Region-aware redirects are common on retail, media, and content sites, where visitors are quietly sent to a localised version. To verify this behaviour you need to appear to originate from the relevant location, which is exactly what region-specific proxies provide.

For trustworthy testing, the proxy should present a clean, representative address rather than one flagged for abuse. Residential addresses often resemble ordinary visitors most closely, which our residential proxies page explains in more depth. Pairing curl's redirect following with a well-chosen regional proxy gives you a repeatable way to confirm what users in different places actually experience.

Common Mistakes and How to Avoid Them

A handful of recurring errors account for most redirect confusion with curl. The biggest is simply forgetting the location flag and then wondering why the page looks empty. Close behind is ignoring the redirect chain when debugging, which hides where a request actually goes.

• Forgetting to follow redirects and misreading a 3xx response as a broken page.
• Overlooking method changes that silently turn a POST into a GET.
• Not capping redirects, allowing loops to hang automated scripts.

Keeping these in mind, and reading the headers when something looks off, resolves the vast majority of redirect issues quickly.

Frequently asked questions

Related pages worth comparing

Have a comparison question about how to follow redirects with curl? Email info@comparebestproxy.com.