Diagnosing redirect loops requires more than just recognizing the error message. You need to identify where in your infrastructure the loop originates, which URLs are involved, and what redirect rules or configurations are causing the circular pattern. Without proper diagnostic tools and methods, you’ll waste time applying random fixes that don’t address the root cause.

This guide covers the essential tools and systematic methods for diagnosing redirect loops. From browser developer tools to specialized redirect checkers and server log analysis, you’ll learn how to trace redirect chains, identify conflicting configurations, and pinpoint exactly what’s causing your ERR_TOO_MANY_REDIRECTS error.

Understanding Redirect Responses and Status Codes

Before diagnosing redirect loops, understand how redirects work at the HTTP level.

HTTP Redirect Status Codes

Redirects use specific HTTP status codes that tell browsers to load a different URL:

• 301 (Moved Permanently) indicates the resource has permanently moved to a new URL. Browsers and search engines cache 301 redirects aggressively.
• 302 (Found/Temporary Redirect) signals a temporary redirect. The original URL might be used again, so browsers cache these less aggressively.
• 307 (Temporary Redirect) is similar to 302 but preserves the HTTP method (POST requests stay POST).
• 308 (Permanent Redirect) is similar to 301 but preserves the HTTP method.

When diagnosing loops, you’ll see these status codes repeating in a circular pattern. A redirect loop might show: URL A (301) → URL B (301) → URL A (301) → continuing indefinitely.

Redirect Limits in Browsers

Browsers limit redirect attempts to prevent infinite loops from crashing.

Web browsers stop following redirects after a certain number of consecutive hops and display a too-many-redirects error. The exact threshold varies by browser and implementation, so the important diagnostic signal is a repeated URL pattern rather than the number of redirects completed.

When this threshold is reached, browsers display the ERR_TOO_MANY_REDIRECTS error. The loop exists before hitting this limit – the browser just gives up after too many attempts.

Pro Tip: The number of redirects before the error appears doesn’t indicate problem severity. Whether you hit the limit after 20 or 16 redirects, a two-step circular redirect (A → B → A) is just as problematic as a complex multi-step loop.

Using Browser Developer Tools

Your browser’s built-in developer tools provide the first line of redirect diagnosis without requiring external tools.

Inspecting Network Activity

Open developer tools (F12 in most browsers or right-click > Inspect), then click the Network tab. Reload the page, experiencing the redirect loop. You’ll see a list of network requests.

Look for requests with status codes 301, 302, 307, or 308. These are redirects. In a redirect loop, you’ll see the same URLs appearing repeatedly with redirect status codes.

Click on individual redirect requests to view details, including request URL, redirect destination (in the Location header), request method (GET, POST, etc.), and response headers revealing which server or system sent the redirect.

The Location header in the response shows where the redirect points. If you see URL A redirecting to URL B, then URL B redirecting back to URL A, you’ve identified the loop visually.

Checking Response Headers

Response headers provide crucial information about who’s creating redirects:

• Server header identifies the web server software (Apache, Nginx, etc.). This helps determine if the server configuration causes the redirect.
• Cloudflare-specific headers such as CF-Ray confirm that the request passed through Cloudflare. If they appear on a redirect response, review Cloudflare Redirect Rules, SSL/TLS settings, and origin-server redirects to determine which layer produced the redirect.
• X-Cache headers suggest caching layers that might cache old redirect rules.
• Location header shows the exact URL the redirect points to. Compare this across multiple redirects to identify the circular pattern.

Preserving Network Logs

By default, the Network tab clears when you navigate to a new page. In redirect loops, this happens rapidly, making diagnosis difficult.

Enable “Preserve log” (Chrome) or “Persist Logs” (Firefox) in the Network tab. This keeps all network requests visible even as redirects occur, so you can see the full redirect chain.

Pro Tip: Use the Network tab’s filter to show only redirect status codes. Type “301 OR 302 OR 307 OR 308” in the filter box to hide all other requests and focus exclusively on redirects.

Online Redirect Checker Tools

Specialized redirect checker tools trace redirect chains without requiring browser developer tool knowledge.

Popular Redirect Testing Tools

• Redirect Checker (redirectchecker.org) shows the complete redirect path from your starting URL to the final destination, including all intermediate redirects, status codes, and response times.
• HTTP Status (httpstatus.io) provides detailed redirect chain visualization with headers, status codes, and identifies redirect loops by showing the circular pattern clearly.
• WhereGoes (wheregoes.com) offers a simple interface showing redirect paths and highlights when loops occur by displaying repeated URLs in the chain.
• Patrick Sexton’s Redirect Mapper visualizes redirect paths and identifies problematic redirects with detailed header information.

Different redirect checkers can produce slightly different results because they may use different user agents, request headers, redirect limits, or geographic infrastructure. When diagnosing an inconsistent loop, compare results from at least two tools and confirm them with browser developer tools or cURL.

Using Redirect Checkers Effectively

Enter the URL experiencing the redirect loop (e.g., http://yoursite.com) and run the check. The tool will follow redirects until it hits the loop or a configured limit.

Look for repeating patterns in the results. If you see the same URL appearing twice in the redirect chain, that’s your loop. For example:

1. http://example.com → (301)
2. https://example.com → (301)
3. http://example.com → (301)
4. Loop detected

This clearly shows http redirects to HTTPS, then HTTPS redirects back to http.

Compare redirect chains for different URL variations (http vs https, www vs non-www). Testing http://example.com, https://example.com, http://www.example.com, and https://www.example.com reveals which combinations create loops.

Pro Tip: Redirect checker tools use a separate HTTP client, so they are not affected by redirects stored in your browser cache. If your browser loops while independent checks return a clean redirect path, test in a private window and clear the browser cache before investigating server-side rules further.

Command Line Tools for Redirect Analysis

For more advanced diagnosis, command-line tools provide detailed redirect information and scripting capabilities.

Using cURL to Trace Redirects

cURL is a command-line tool available on Linux, macOS, and Windows that makes HTTP requests and shows detailed response information.

Basic redirect following:

curl -L -I https://yoursite.com

The -L flag follows redirects, and -I shows only headers (not page content). This displays each redirect in the chain with full header information.

Limiting redirect attempts to detect loops:

curl -L -I –max-redirs 5 https://yoursite.com

This stops after 5 redirects. If it hits the limit, you likely have a loop.

Verbose output showing complete request/response cycle:

curl -v -L https://yoursite.com

The -v (verbose) flag shows exactly what cURL sends and receives, helpful for diagnosing complex redirect issues.

Interpreting cURL Output

cURL output shows each redirect step:

HTTP/1.1 301 Moved Permanently

Location: https://www.example.com/

HTTP/1.1 200 OK

This indicates a redirect from the initial URL to https://www.example.com/, which then returned a successful 200 response (no loop).

In a redirect loop, you’d see:

HTTP/1.1 301 Moved Permanently

Location: https://example.com/

HTTP/1.1 301 Moved Permanently

Location: http://example.com/

curl: (47) Maximum (5) redirects followed

This shows the URLs redirecting in a circle until cURL hits its redirect limit.

Using Wget for Redirect Diagnosis

Wget is another command-line tool with useful redirect diagnostic features:

wget –max-redirect=5 –server-response https://yoursite.com

The –server-response flag shows all HTTP headers, and –max-redirect limits redirect following. Wget’s output format differs from cURL but provides similar diagnostic information.

Checking Server and Application Logs

Server logs record all requests and responses, including redirects, providing historical data about when loops started and what triggers them.

Remember that origin access logs might not contain every request if a CDN or reverse proxy generates the redirect before the request reaches the origin server.

Apache Access and Error Logs

Apache logs show request details, including status codes that identify redirects.

Access logs (typically /var/log/apache2/access.log or /var/log/httpd/access_log) show:

192.168.1.1 – – [18/May/2026:10:30:15] “GET / HTTP/1.1” 301 – “https://example.com/”

The 301 status code indicates a redirect. Multiple log entries for the same client IP with 301/302 status codes suggest redirect loops.

Filter logs for redirect status codes:

grep ” 301 ” /var/log/apache2/access.log

grep ” 302 ” /var/log/apache2/access.log

Error logs (typically /var/log/apache2/error.log) might show rewrite rule errors or configuration issues causing loops.

Nginx Access and Error Logs

Nginx logs use similar formats (typically /var/log/nginx/access.log and /var/log/nginx/error.log).

Filter for redirects:

grep ” 301 ” /var/log/nginx/access.log | tail -20

This shows the last 20 redirect responses, helping identify patterns or specific URLs involved in loops.

WordPress Debug Logs

WordPress can log PHP errors and warnings that might relate to redirect issues, especially those caused by plugins or theme functions.

Enable WordPress debugging in wp-config.php:

define(‘WP_DEBUG’, true);

define(‘WP_DEBUG_LOG’, true);

define(‘WP_DEBUG_DISPLAY’, false);

This writes errors to /wp-content/debug.log. Check this file for plugin or theme errors related to redirects or URL manipulation.

Pro Tip: Server logs show historical data, helping identify when redirect loops started. If logs show normal behavior until a specific date/time, check what changed then (plugin updates, configuration changes, etc.).

How to Diagnose a Redirect Loop: Step by Step

Random troubleshooting wastes time. Use a systematic approach to diagnose redirect loops efficiently.

Step 1: Identify the Redirect Pattern

Use redirect checker tools or browser developer tools to document the exact redirect chain. Write down each URL in the sequence and its status code.

Identify the loop structure: Is it a simple two-step loop (A → B → A)? A three-step loop (A → B → C → A)? Or more complex?

Note which URL variations trigger the loop (HTTP vs HTTPS, www vs non-www, specific paths vs homepage).

Step 2: Determine When It Started

Check if the redirect loop affects everyone or only specific users/browsers. Test in incognito mode and different browsers. If only affecting some users, it’s likely a cache issue.

Identify when the loop started. Recent changes (SSL installation, plugin updates, server config changes, CDN setup) often correlate with when loops began.

Step 3: Isolate Configuration Layers

Test with different infrastructure components disabled:

• Disable CDN (set Cloudflare to DNS-only mode or pause the CDN). If the loop disappears, CDN configuration is involved.
• Disable .htaccess (rename to .htaccess-disabled). If the loop disappears, server redirect rules are the cause.
• Disable plugins (rename the plugins folder). If the loop disappears, a plugin is creating the redirect.
• Switch themes (activate a default WordPress theme). If the loop disappears, the theme is involved.

Test after each change to identify which component causes the loop.

Step 4: Check Configuration Alignment

Once you identify the problematic layer, examine its configuration for conflicts:

• Server configs: Look for multiple or conflicting redirect rules in .htaccess, nginx.conf, or web.config.
• WordPress settings: Verify WordPress Address and Site Address match and use correct protocols (HTTP vs HTTPS).
• CDN settings: Check for “Always Use HTTPS” or page rules that conflict with server redirects.
• SSL configuration: Ensure CDN SSL mode (Flexible, Full, Full Strict) matches your server’s SSL certificate status.

For optimal server configuration and diagnostic capabilities, quality hosting infrastructure with accessible logs, clear configuration interfaces, and support staff familiar with redirect issues speeds up diagnosis and resolution significantly.

Step 5: Confirm the Fix

After making changes, test the affected URL again using the same tools you used during diagnosis. Check HTTP and HTTPS versions, as well as www and non-www variations, and make sure each one reaches the correct destination without repeating URLs. It is also worth testing in a private browser window to rule out cached redirects.

Common Redirect Loop Patterns and Their Causes

Recognizing common patterns speeds up diagnosis.

HTTP/HTTPS Loop

Pattern: http://site.com → https://site.com → http://site.com

Cause: One system forces HTTPS while another forces HTTP, or CDN is in Flexible SSL mode while the server forces HTTPS.

Diagnostic clue: The redirect chain alternates between HTTP and HTTPS for the same domain.

WWW/Non-WWW Loop

Pattern: www.site.com → site.com → www.site.com

Cause: Conflicting redirect rules where one redirects www to non-www and another redirects non-www to www.

Diagnostic clue: The redirect chain alternates between www and non-www versions.

Mixed Protocol and Domain Loop

Pattern: http://www.site.com → https://site.com → http://www.site.com

Cause: Multiple redirect rules handling HTTPS and www/non-www with conflicting logic or execution order.

Diagnostic clue: Each redirect changes both the protocol AND the domain format.

Path-Specific Loop

Pattern: /page-a/ → /page-b/ → /page-a/

Cause: Circular redirect rules in redirect plugins, .htaccess, or application code.

Diagnostic clue: Only specific URLs loop while others load normally.

Documenting Your Findings

Proper documentation during diagnosis helps with fixing and preventing future issues.

Record the exact redirect chain observed, which tools were used for diagnosis, what changed recently before the loop appeared, which infrastructure layers are involved (CDN, server, WordPress, plugins), and any error messages from logs.

This documentation guides your fix and helps you explain the issue to support teams or developers if needed.

Final Redirect Loop Diagnostic Checklist

Redirect loop diagnosis requires systematic investigation using the right tools. Start with browser developer tools or online redirect checkers to visualize the redirect chain and identify the circular pattern. Look for URLs repeating in the sequence, that’s your loop.

Use command-line tools like cURL for detailed header analysis and server logs to identify when the loop started. Apply a methodical diagnostic process: identify the redirect pattern, determine when it began, isolate which infrastructure layer causes it (CDN, server config, WordPress, plugins), and examine that layer’s configuration for conflicts.

Common patterns include HTTP/HTTPS loops (usually SSL misconfiguration), www/non-www loops (conflicting domain preference rules), and path-specific loops (circular redirect rules). Recognizing these patterns speeds diagnosis. Document your findings to guide fixes and prevent recurrence.

Frequently Asked Questions