Following Redirects with curl: A Practical Handbook

Why redirects trip people up with curl

One of the first surprises new curl users hit is fetching a URL and getting back what looks like an empty or strange response, only to realise the server actually returned a redirect that curl dutifully refused to follow. This is not a bug; it is curl being precise. By default the tool fetches exactly the address you give it and reports the response verbatim, redirect and all. This handbook explains why that happens, how the single most useful flag changes it, how to inspect and control a redirect chain, and how to keep redirect-heavy fetching reliable when you run it across many URLs through a proxy.

What an HTTP redirect actually is

A redirect is the web's way of saying "what you asked for lives somewhere else now." When you request a URL, the server can reply with a 3xx status code and a Location header pointing at a new address. A browser follows that automatically and you barely notice, but curl, being a precise tool, shows you the redirect response and stops. Redirects are everywhere: HTTP-to-HTTPS upgrades, trailing-slash normalisation, moved pages, link shorteners and tracking hops all rely on them. Understanding that a redirect is just a status plus a Location header is the key to handling it confidently.

The default behaviour and why it exists

Run a plain curl against a URL that redirects and you will see the 3xx status and the Location header, but not the content of the destination. curl behaves this way deliberately, because predictability matters in a tool people script around. If it silently chased every redirect by default, you could end up somewhere unexpected without realising. By making you opt in, curl keeps you in control of exactly how far a request travels, which is especially valuable when you are debugging or scraping and need to know each hop a URL takes.

The -L flag: following the chain

The single flag that changes everything is -L, also written as --location. It tells curl that when a response is a redirect, it should issue a fresh request to the Location header and keep doing so until it reaches a final, non-redirecting response. With it, a shortened or moved URL resolves all the way to its real destination in one command:

curl -L https://example.com/old-page

That is the whole trick for everyday use. Add -L and curl walks the chain for you, returning the content of wherever the URL ultimately leads rather than the first redirect it meets.

Inspecting the full redirect chain

When you need to see every hop rather than just the destination, combine -L with header and verbose options. Using -I fetches headers only, and -v prints the full conversation, so you can watch each status and Location as curl travels the chain:

curl -ILv https://example.com/short-link

This is invaluable for debugging. If a URL ends somewhere unexpected, or loops, the chain printout shows you exactly which hop went wrong, what status it returned, and where it tried to send you next.

Limiting how far curl will follow

Following redirects blindly can be dangerous: a misconfigured server can produce a loop, and a chain that never resolves will leave a script hanging. The --max-redirs option caps the number of hops curl will follow before it stops and reports an error:

curl -L --max-redirs 5 https://example.com/maybe-loops

Setting a sensible ceiling is good hygiene in any automated context. It turns a potential infinite loop into a clean, catchable failure you can handle in your script.

How methods change across a redirect

Redirects do not always preserve the request method, and this catches people out. Depending on the status code, curl may switch a POST to a GET when it follows the redirect, which is correct behaviour for some codes but not what you want for others. If you need the original method preserved across the hop, curl offers options that force it to keep the method and body. Knowing this matters most when you are submitting data, not just reading pages, since a silently downgraded method can make a request behave very differently from what you intended.

Carrying cookies and headers through the chain

Many redirect flows depend on state. A login or session step may set a cookie on one hop that the next hop expects to see. To follow these correctly, enable cookie handling with the -c and -b options so curl stores and resends cookies across the chain, and pass any custom headers the target needs. Without that, a redirect that relies on a just-set cookie can bounce you back to the start. Treating the chain as a stateful conversation, not a series of isolated requests, is what makes complex redirect flows work.

Where proxies enter redirect-heavy work

A single curl command needs no proxy, but redirect-following often shows up inside loops, resolving thousands of shortened links, checking where many URLs ultimately land, or fetching pages that each bounce through several hops. All of that traffic leaving one IP looks like exactly the automated access that rate limiters target. Proxies spread the requests across many addresses so no single one draws a block, keeping bulk redirect resolution smooth. In curl this is a small addition to your command, but the proxy type you pick shapes how reliably the job runs.

Following redirects through a proxy

You combine -L to follow redirects with -x to route the request through a proxy. curl then sends every hop of the chain through that endpoint:

curl -L -x http://user:pass@proxy-host:port https://example.com/short-link

To rotate, cycle the -x value across a list of endpoints between runs, or point it at a provider gateway that rotates the exit IP for you. Rotation is what keeps a redirect-resolving loop from being throttled when it runs across many URLs.

Which proxy types suit this work

Each proxy type trades cost against trust, and the right one depends on how strict the targets are.

• Datacenter proxies are fast and affordable, a sound default for tolerant, high-volume redirect resolution.
• Residential proxies carry more trust on strict sites that block datacenter IPs, at a higher cost.
• ISP proxies give static residential-grade addresses with datacenter speed for steady bulk jobs.
• Mobile proxies use carrier IPs with the highest trust for the strictest targets.
• IPv4 proxies remain the safe compatibility default when target support is uncertain.

Top use cases for following redirects

• Resolving shortened links to their true destinations at scale.
• SEO audits, mapping redirect chains and spotting needless extra hops.
• Link verification, confirming that thousands of URLs still land where they should.
• Affiliate and tracking checks, seeing the full path a click travels.
• Scraping and monitoring where target pages bounce through several redirects.

Common mistakes to avoid

The classic error is forgetting -L and concluding a site is broken when it merely redirected. Others follow redirects with no --max-redirs and let a loop hang their script, lose cookies across hops so stateful flows break, or assume the request method survives the redirect when it may not. At scale, ignoring proxies until rate limits appear is another trap, as is treating cheap untested IPs as interchangeable when their quality is what keeps a loop running. Setting -L, a redirect cap, cookie handling and a proxy from the start sidesteps nearly all of these.

A checklist for redirect-heavy curl scripts

• Always add -L when you expect the URL to redirect.
• Set --max-redirs to a sensible ceiling to avoid loops.
• Enable cookie handling with -c and -b for stateful chains.
• Decide whether the request method must survive the redirect, and force it if so.
• Use -ILv to inspect a chain whenever the final destination surprises you.
• Add a proxy with -x once you run redirect resolution across many URLs.
• Start on affordable datacenter IPs and escalate to residential where blocks appear.

curl versus a scripting language for redirects

curl on the command line is unbeatable for quick checks and shell loops, and -L plus -x covers most redirect work cleanly. When your logic grows, parsing each hop, branching on status codes, storing results in a database, a scripting language with an HTTP library gives you more structure, while still letting you follow redirects and set proxies the same way. Many people prototype with curl and graduate to Python or Node once the job needs real data handling. Both follow the same redirect rules; the difference is how much surrounding logic you need.

Recommended proxy providers

When you resolve redirects across many URLs, the IPs behind curl decide whether the job finishes, so choose a proxy provider deliberately.

• Cheapest Proxies — our Featured Value Pick. A sensible first stop for redirect-heavy fetching, pairing affordable pricing with practical proxy types so you can run tolerant bulk work cheaply, benchmark costs, and escalate to pricier options only where a strict target truly demands it.
• A large residential network — worth considering when strict sites block datacenter IPs and you need broad, high-trust coverage.
• A datacenter-focused provider — a fair option for fast, high-volume redirect resolution of tolerant targets where speed and price lead.
• An ISP-proxy specialist — useful when you want static, residential-grade IPs with datacenter speed for steady bulk jobs.

How to get started today

Take a single URL you know redirects, run a plain curl to see the 3xx response, then add -L and watch it resolve to the destination. Add -ILv to study the chain, set a --max-redirs cap, and turn on cookie handling if the flow needs it. Only once you wrap this in a loop over many URLs should you add -x and confirm the proxy keeps your success rate high. Building from a single working command outward is the fastest way to a dependable redirect-resolving script.

Key takeaways

curl does not follow redirects by default because it values precision; the -L flag is what walks a redirect chain to its destination. Inspect chains with -ILv, cap them with --max-redirs, carry cookies for stateful flows, and mind whether the request method survives each hop. When you scale redirect resolution across many URLs, route curl through proxies with -x to avoid rate limits, and let a value-focused provider like Cheapest Proxies handle the bulk of that tolerant work affordably.