Mastering cURL Follow Redirect: A Guide for Command-Line Users
When using cURL, if you’re receiving an unexpected response, don’t worry. The issue might not be with your request. This often happens when cURL doesn’t follow the redirect. By default, the responses stop at 3xx, leaving the actual content or the endpoint just out of reach.
So, how do you make cURL follow the redirect and finish what it started? You use the cURL -L flag (short for -location). This guide covers why cURL doesn’t follow redirects by default, how the -L flag works, and what to do when handling POSTs, redirect limits, headers, and proxies. It also touches on debugging and cases where cURL falls short.
In a rush? Here's a quick cURL Follow Redirect cheat sheet that covers everything you need to handle redirect behavior efficiently.
| Purpose | Command / Flag | What It Does |
|---|---|---|
| Follow redirects | -L | Tells cURL to follow HTTP 3xx redirect responses |
| Limit the number of redirects | --max-redirs <number> | Sets how many redirects cURL will follow (default is 50) |
| Remove redirect limit (infinite) | --max-redirs -1 | Lets cURL follow unlimited redirects (use with caution) |
| View only headers during redirects | -I with -L | Sends a HEAD request and follows redirects without downloading content |
| Show redirect chain in output | -v | Displays each redirect step, status code, and header details during execution |
| Forward headers across domains | --location-trusted | Allows sensitive headers (like Authorization) to follow cross-domain redirects |
| What to use for client-side redirects | Puppeteer, Playwright, Selenium | Tools that act like browsers and handle JavaScript-based redirects |
Why cURL Doesn’t Follow Redirects By Default?
cURL doesn’t just follow redirects like your browser does. Even when the server responds with a redirect using status codes like 301, 302, or 307, cURL doesn’t follow.
The reason for this is that it aims to be predictable and controlled. Unless you’re explicitly told to follow, it waits for you to decide what to do next. This way, you get complete control over how requests are handled, instead of going wherever the server points.
You can use the 301 redirect response as a simple example.
Browsers follow the redirects without asking by checking the “Location” header. Next, it automatically makes another request to the new URL. However, cURL doesn’t do that unless you use the -L flag.
Following Redirects with cURL -L and Controlling the Flow
The -L flag in cURL changes how it handles HTTP conversations. Instead of stopping at a redirect, it tells cURL to actively follow the path a server responds with.
For example, when you run a command like: curl http://example.com, cURL stops at the first response. Using the -L command line option, it looks for the Location header in that response and repeats the request to the new URL.
cURL continues this process until it reaches a final, non-redirect response or until it hits the redirect limit. By default, cURL will follow up to 50 redirects in a single request chain. But how to control it? You can use the --max-redirs flag.
In the example below, cURL follows redirects but stops after five hops. Even if the final destination hasn’t been reached.
However, sometimes you might want to test how your script handles long or infinite redirect chains. In this scenario, you can remove the limit by setting it to -1. Here is how to do it.
Behind the scenes, cURL keeps following redirects without stopping. While handy when testing, be aware that your script could hang or consume unnecessary system resources. This happens when the server keeps redirecting between URLs with no end.
cURL Redirects: Preserving Request Methods
What if your request sends data, but after the redirect, it never makes it to the destination?
This happens when cURL changes the HTTP method during a redirect. By default, cURL switches to GET when the server responds with 301, 302, or 303. During this process, the original data can be dropped.
To overcome this, cURL also offers flags (--post301, --post302, and --post303) that preserve the original method across redirects.
Check out the example below. It sends a POST request with login credentials to a login endpoint. If the server responds with a 302 Found, cURL would normally follow the redirect, but change the request to a GET, dropping the login data entirely.
That’s where --post302 comes in. With this flag, cURL keeps the method as POST during the redirect. It allows the request body to reach the final destination as intended.
Note: This isn’t always the case. If the server responds with a 307 or 308 code, cURL will keep the original method by default. These codes are designed to preserve method consistency and are often used in APIs for that reason. Just keep in mind that 308 may not work with older clients.
How To Trace and Debug Redirect Chains in cURL
You’ve seen how cURL can switch methods unless you use the --post flags. But knowing how your request behaves is just as important as controlling it. This is possible with flags like -v and -I, which let you inspect each step of the redirect and understand how cURL processes the request behind the scenes.
Using -v to Trace Redirect Paths
The -v flag stands for verbose mode. When you add this to your command, you’ll see the HTTP status codes, with each redirect as it happens. It also displays the Location headers that cURL follows along the way.
In the above example, cURL is instructed to follow three redirects using the -L flag, while the -v flag prints each step of the process. You’ll see the status codes, Location headers, and how the request moves from one URL to the next.
The best part is that you can also spot when a request method changes, like a POST turning into a GET, or when important headers are missing between hops.
Using -I to Inspect Headers Only
If you don’t want to figure out if a redirect is happening, identify caching headers, or confirm the destination URL without making a full request, the -I flag (Inspect) comes in handy.
In the example below, the -I flag tells cURL to make a HEAD request, which fetches only the headers. The -L flag, on the other hand, allows it to follow any redirects until it reaches the final URL.
Note: If you're sending headers like Authorization and the redirect goes to another domain, cURL will drop those headers by default. To keep them, use the --location-trusted flag, but only if the redirected URL is trusted. However, be cautious when doing this with third-party URLs, as it can expose sensitive data.
When cURL Isn’t Enough: What It Can’t Follow?
Unfortunately, cURL cannot follow every kind of redirect. Even if the troubleshooting doesn’t help the request from stopping short or ending on the wrong page, this might be the reason.
Everything we’ve covered so far involves server-side HTTP redirects, which are triggered by status codes. However, many websites rely on client-side redirects, which cURL simply can’t detect or process.
Here’s what cURL can’t follow:
- HTML meta refresh tags: These are used to refresh or redirect a page after it loads. Since cURL doesn’t parse HTML, it misses these entirely.
- JavaScript-based redirects: Redirects triggered through JavaScript, such as changing window.location, don’t register in cURL because it doesn’t execute scripts.
- Framework-based routing: Single-page applications built with frameworks like React or Vue often change routes without sending an actual HTTP redirect. These changes are invisible to cURL.
Pro Tip: If you're working with pages that rely on any of these, switching to a browser automation tool like Puppeteer, Selenium, or Playwright is a better choice. These tools act like real browsers and can follow client-side redirects without issue.
