logo
GeekFormat

Redirect Chain Checker

Redirect Chain Inspector

Hop-by-hop inspection of 301/302/307/308 redirects, detecting loops, cross-domain redirects, and HTTPS downgrade issues.

When you type a URL into your browser, a series of invisible redirects may happen behind the scenes: HTTP→HTTPS, non-www→www, old domain→new domain, short URL→long URL… Each redirect hop consumes time, impacts SEO rankings, and may even silently downgrade HTTPS to HTTP. The Redirect Chain Checker traces the complete redirect path from the server perspective hop-by-hop, showing each hop's status code (301/302/303/307/308), Location header, and target address. It automatically detects redirect loops, cross-domain jumps, HTTPS downgrades, and chain truncation, helping you uncover hidden redirect issues during domain migrations, HTTPS deployment, and SEO optimization.

Related

Use Cases

  • Domain migration verification: after switching from an old domain to a new one, verify hop-by-hop that old URLs correctly 301-redirect to the new addresses, avoiding traffic loss from chained redirects and wrong status codes
  • HTTPS deployment check: confirm that HTTP→HTTPS redirect chains are single-hop 301s, check for HTTP→HTTPS→HTTP downgrade loops, and verify that HSTS configuration is working
  • Short URL landing page detection: trace the complete redirect path of short URLs (t.cn, bit.ly, etc.), marketing UTM links, or social share links—confirm the final landing page is the expected address, and check if intermediate hops inject tracking parameters or malicious redirects
  • www vs non-www canonicalization: check whether www and root domains correctly 301-redirect to each other's canonical version, avoiding duplicate content SEO issues from dual-track operation
  • Redirect loop troubleshooting: when your browser reports ERR_TOO_MANY_REDIRECTS, use the tool to precisely locate the node where the loop occurs—distinguish whether it's caused by Nginx/Apache misconfiguration, CDN rule conflicts, or WordPress plugins
  • CDN and reverse proxy debugging: troubleshoot redirect conflicts in multi-layer architectures like Cloudflare, CDN services, and Nginx reverse proxies—identify issues where CDN rules and origin rules redirect each other
  • SEO health audit: regularly check redirect chain length for core pages, evaluate the impact of multi-hop redirects on PageRank flow efficiency, and optimize excessively long redirect chains
  • Cross-domain redirect risk assessment: detect cross-domain redirect scenarios like login jumps, OAuth callbacks, and payment redirects—confirm that Cookies and Sessions are correctly passed across domains
  • Load balancing and multi-active verification: check redirect strategies in multi-active data centers and GSLB global load balancing scenarios—confirm users in different regions are correctly redirected to the nearest available node
  • Redirect cache debugging: verify Cache-Control and Expires header settings for 301 permanent and 302 temporary redirects—troubleshoot abnormal access caused by browsers caching old redirect rules

Features

  • Hop-by-hop full tracing: follows every redirect from the server perspective, showing the original URL, each hop's status code, status text, Location response header, and complete redirect path—no intermediate nodes missed
  • Full status code support: covers 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, and 308 Permanent Redirect, with annotations on semantic differences between each status code
  • Redirect loop detection: automatically identifies closed-loop patterns like A→B→A, marks the specific node where the loop starts and the loop length, precisely pinpointing the root cause of ERR_TOO_MANY_REDIRECTS errors
  • Cross-domain redirect identification: detects Host/Domain changes hop-by-hop, marks cross-domain redirect nodes, and alerts about Cookie loss risks and CORS preflight issues
  • HTTPS downgrade warning: counts HTTP (non-HTTPS) nodes in the redirect chain, marks HTTPS→HTTP downgrade jumps, and alerts about security risks and negative SEO impact
  • Chain truncation protection: sets a maximum redirect depth limit (20 hops), automatically truncating and marking when the chain is too long to avoid request timeouts from infinite tracing
  • Redirect summary statistics: provides key metrics at a glance—total redirect count, final destination URL, loop detected, cross-domain status, HTTP node count, and chain truncation status
  • SEO impact assessment: automatically evaluates the impact level on PageRank flow and Core Web Vitals based on hop count, status code type, and HTTPS coverage
  • Preset test URLs: built-in common test addresses like geekformat.com, github.com, httpbin.org/redirect, and URL shortener services—one-click fill for quick testing
  • Recent query history: automatically saves the last 8 queries (stored locally in the browser), supports one-click re-testing for easy before/after comparison of fixes
  • Diagnostic recommendation cards: provides specific fix suggestions and best practice guidance for detected issues like redirect loops, cross-domain jumps, HTTP downgrades, and excessive chain length
  • Dual view: details and summary—default view shows the chain summary card; expand to see each hop's full request URL, response status, Location target, and HTTPS flag

How to Use

  1. Enter the URL to check in the input box (must include http:// or https:// protocol prefix), or click a preset URL button (geekformat.com, github.com, httpbin.org/redirect, etc.) to quickly fill a test address
  2. Click the "Trace Redirect Chain" button—the tool will send a request from the server side, following Location response headers hop-by-hop and recording complete information for each hop
  3. Check the top summary card: total redirect count, final destination URL, whether a loop was detected, whether cross-domain redirects exist, number of HTTP nodes, and whether the chain was truncated due to too many hops
  4. View detailed information for each hop in the chain visualization area: sequence number, request URL, response status code and description text, target URL from Location response header, and HTTPS security flag
  5. Pay attention to diagnostic warning cards: if redirect loops (red), HTTPS downgrades (orange), cross-domain jumps (yellow), or excessive chain length (yellow) are detected, the tool highlights them with problem descriptions
  6. Use the SEO impact assessment area to see the current redirect chain's impact level on PageRank flow efficiency, page load speed, and Core Web Vitals, along with optimization suggestions
  7. After detection, click any record from the recent query history to quickly re-test and compare redirect chain changes before and after fixes; you can also screenshot or copy results for team communication and ticket records

FAQ

How many redirect hops are too many? What's the SEO impact?

Google officially recommends keeping redirect chains to a single hop, no more than 3 maximum. According to Google Search Central documentation, Googlebot typically follows up to 5 redirect hops before stopping, but that doesn't mean 5 hops is safe. Each redirect hop adds page load latency (100-300ms/hop), wastes crawl budget, and may cause PageRank transfer decay. 1 hop has almost no SEO impact; 2 hops is acceptable but recommended to optimize; 3+ hops start affecting LCP and crawl efficiency; 5+ hops risk pages not being indexed. Use this tool to check your core pages' redirect chains, ensuring critical URLs (homepage, core product pages, high-traffic inner pages) are all single-hop direct.

Will 301 redirects hurt SEO? Does PageRank transfer fully?

Correctly used 301 permanent redirects do not hurt SEO. Google's Gary Illyes and John Mueller have confirmed multiple times that 301 redirects from HTTP domain migration to HTTPS domain, and within-domain permanent page migrations, pass PageRank at 100% with no loss. But note: 1) 302 temporary redirects don't pass PageRank (or do so very inefficiently); 2) If noindex, robots.txt blocking, or 4xx/5xx errors appear in the redirect chain, authority transfer interrupts; 3) After cross-domain 301 migration, you need to submit a domain change notification in Google Search Console to accelerate index migration; 4) 301s are cached long-term by browsers—during testing phase, recommend first verifying with 302 before switching to 301.

Why does my website automatically redirect to HTTP instead of HTTPS? How to fix?

HTTPS→HTTP downgrade redirects are typically caused by: 1) Reverse proxy/CDN fetches origin via HTTP, and when origin Nginx/Apache uses $scheme variable to get protocol, it gets http instead of https; 2) Application layer code hardcodes URLs with http:// prefix; 3) WordPress and other CMS have Home URL or Site URL set to http; 4) Legacy HTTP rules remain in .htaccess; 5) Third-party service (CDN/WAF) SSL/TLS set to "Flexible" mode instead of "Strict" mode. Fix steps: first use this tool to determine which hop the downgrade occurs at; set CDN SSL to "Full (strict)" mode; correctly handle X-Forwarded-Proto header in Nginx; WordPress add $_SERVER['HTTPS']='on'; in wp-config.php; deploy HSTS response headers to prevent browser-level downgrades; check all redirect rules ensure targets are https://.

How to fix redirect loops in Nginx (ERR_TOO_MANY_REDIRECTS)?

Over 90% of Nginx redirect loops are caused by X-Forwarded-Proto headers not being correctly handled in reverse proxy/CDN scenarios. Fix methods: 1) Ensure CDN/load balancer sends X-Forwarded-Proto header to backend: proxy_set_header X-Forwarded-Proto $scheme; 2) Nginx uses X-Forwarded-Proto instead of $scheme when deciding whether to jump to HTTPS. Recommend using map block: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) Avoid writing rewrite rules in server blocks that infinitely match themselves; 4) Configure www and non-www redirects as one-way jumps in only one server block, don't configure bidirectionally.

How to fix redirect loops in Apache .htaccess?

Apache .htaccess loops are typically caused by RewriteRule conflicts. Fix steps: 1) Ensure RewriteEngine On appears only once; 2) HTTP→HTTPS redirect rule goes before all other rules, use: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) www/non-www rules go after HTTPS redirect, and only do one-way jump (non-www→www or vice versa); 4) Note that [L] flag means "last" but if the rule modifies the URL it restarts matching from the first rule, potentially causing loops—complex rules consider using [END] flag (Apache 2.3.9+); 5) Check if multiple .htaccess files exist (.htaccess in subdirectories also take effect); 6) Temporarily change R=301 to R=302 for testing, avoiding browser cache interference.

How to fix redirect loops caused by Cloudflare?

The most common cause of Cloudflare loops is incorrect SSL/TLS encryption mode settings or page rule conflicts: 1) Change Cloudflare SSL/TLS mode from "Flexible" to "Full" or "Full (strict)"—in Flexible mode, Cloudflare uses HTTP to origin, and if the origin configures HTTPS forced redirects, it creates a loop; 2) Check if "Always Use HTTPS" in Cloudflare's "Edge Certificates" is enabled—don't configure HTTPS redirects at both origin and Cloudflare simultaneously; 3) Check Page Rules for conflicting forwarding rules; 4) If using Cloudflare WordPress plugin, don't configure HTTPS redirects in both the plugin and Cloudflare; 5) Check if Forwarding URL rules point to addresses that Cloudflare redirects again.

What's the difference between 301, 302, 307, and 308 redirects? Which should I choose?

The core differences are in two dimensions: permanence and whether to preserve the request method. Quick selection guide: For regular webpage GET requests (user visiting pages)—permanent migration use 301 (domain migration, HTTPS switch, permanent URL change), temporary redirect use 302 (A/B testing, temporary maintenance, login redirect); For POST/PUT/DELETE requests (API calls, form submission)—permanent migration use 308, temporary redirect use 307, ensuring request method and body aren't lost; 303 is specifically for jumping to result page after POST form submission (forces GET, prevents duplicate submission). Simple memory: 301=permanent GET-safe, 302=temporary GET-safe, 307=temporary all-methods, 308=permanent all-methods, 303=POST result page redirect.

Do browsers permanently cache 301 redirects? How to clear 301 cache?

301 permanent redirects are cached by browsers by default, but cache duration depends on Cache-Control and Expires settings in response headers. If cache headers aren't explicitly specified, default caching behavior varies by browser: Chrome typically caches 301 redirects for weeks to months (may even persist after browser restart); Firefox caches 301 by default but may revalidate after restart; Safari's caching strategy is relatively conservative. Methods to clear 301 cache: 1) Chrome: Settings→Privacy and security→Clear browsing data→Time range select "All time"→check "Cached images and files"→Clear data; 2) When DevTools (F12) is open, check "Disable cache" in Network panel; 3) Add meaningless query parameter after URL (?nocache=1) to bypass cache; 4) Chrome developers can Flush sockets at chrome://net-internals/#sockets, or Clear host cache at chrome://net-internals/#dns; 5) During testing phase use 302 temporary redirects instead of 301, switch to 301 after confirming correctness.

What's the difference between Meta Refresh and HTTP redirects? Which is better?

Meta Refresh is a redirect implemented via <meta> tag in HTML documents (like <meta http-equiv="refresh" content="0;url=https://example.com/new">), executed after the browser parses HTML, while HTTP redirects are instructed directly by the server at the HTTP protocol level via 3xx status codes. Comparison: 1) Speed: HTTP redirects start jumping when response headers are received; Meta Refresh needs to wait for HTML download and parsing before jumping, slower; 2) SEO: Google usually recognizes Meta Refresh and passes authority (if delay=0), but officially recommends HTTP 301/302 redirects because Meta Refresh is client-side and signals are less clear than server-side redirects; 3) Delay: Meta Refresh can set delay time (like content="5;url=..." means jump after 5 seconds), but HTTP redirects don't have this feature; 4) Accessibility: W3C doesn't recommend Meta Refresh because screen readers and assistive technologies handle it poorly and it may confuse users; 5) Back button: Meta Refresh may break back button behavior in some browsers. Conclusion: always prefer HTTP 301/302/307/308 redirects, avoid Meta Refresh unless you can't control server configuration (like static page hosting platforms where you can't configure server-side rules).

Do redirects affect LCP in Core Web Vitals?

Yes, and the impact is very significant. Redirects happen before the browser gets the HTML document, meaning each redirect hop delays the start of HTML document download. LCP (Largest Contentful Paint) calculation starts at navigation start, and the browser must get the final HTML before it can start parsing DOM, loading CSS, and rendering LCP elements. Assuming each redirect hop adds 150ms network latency (DNS+TCP+TLS+request-response), 3 redirect hops would increase LCP by at least 450ms—enough to push LCP from "good" (≤2.5s) to "needs improvement" (2.5-4s) range. Google's Core Web Vitals documentation explicitly lists "avoid multiple redirects" as one of the key recommendations for optimizing LCP. Best practice: ensure core pages have zero redirects (link directly to final URLs), and keep necessary redirects like HTTP→HTTPS and www canonicalization to a single hop.

How do I check where a short URL ultimately redirects to?

Short URLs (bit.ly, etc.) typically reach the final URL via 1-3 redirect hops, with possible UTM tracking parameters, device detection redirects, geographic redirects, etc. in between. Using this tool you can: 1) Enter the short URL (including http:// or https://); 2) Click trace to see the complete path of each hop; 3) View the final destination URL, redirect count, and status code types; 4) Check if intermediate hops have HTTP downgrades or abnormal cross-domain behavior. Note: some short URLs return different final targets based on User-Agent or IP geography. This tool uses server IP for requests, so results may differ slightly from what you see in your browser directly (especially for overseas short URL services).

Should HTTPS forced redirect use 301 or 302? Do I need to add HSTS?

HTTPS forced redirect should use 301 permanent redirect, because switching from HTTP to HTTPS is a permanent change, not a temporary redirect. After configuring 301, you should also deploy HSTS response headers. The complete HTTPS enforcement scheme has three phases: 1) Phase 1 (testing period): first configure HTTP→HTTPS 301 redirect, don't enable HSTS, observe 1-2 weeks to confirm all resources and subdomains work correctly; 2) Phase 2 (stable period): add Strict-Transport-Security response header, initial max-age set to short duration (like max-age=300, or 5 minutes), gradually increase to max-age=31536000 (1 year); 3) Phase 3 (Preload): after confirming all subdomains support HTTPS, add includeSubDomains and preload directives, then submit to HSTS Preload List (hstspreload.org), so browsers have your domain's HSTS policy built in, eliminating the first-visit HTTP window. Note that once HSTS is cached in browsers, it can't be revoked server-side before max-age expires, so be sure to test thoroughly.

What's the difference between JavaScript window.location redirects and HTTP redirects?

JavaScript redirects (like window.location.href='https://example.com') are fundamentally different from HTTP 3xx redirects: 1) Execution level: HTTP redirects happen at the protocol level with the server returning a status code, and the browser jumps immediately upon receiving response headers; JS redirects require HTML download and JS execution before jumping, slower; 2) SEO: Search engine crawlers correctly recognize and follow HTTP 301/302 redirects passing authority, but the SEO effect of JS redirects depends on whether the crawler executes JS and when—signals are weak and unstable; 3) Intermediate process: the page starts loading before JS redirects (may show white screen or partial content flashing), HTTP redirects users reach the target page directly, smoother experience; 4) Reliability: JS may be blocked by browsers, plugins, or Content Security Policy, HTTP redirects are handled by browser core, highest reliability. Conclusion: when you need permanent/temporary URL redirects, always use server-side HTTP 301/302 redirects; JS redirects are only for page navigation in interaction logic (like redirect after form validation, button click redirects, etc.).

Can redirect chains cause inaccurate A/B test results?

Yes, redirect chains affect A/B testing in multiple ways: 1) If A/B testing is implemented via redirects (50% of users 302 to version A, 50% to version B), redirect latency makes page load speeds differ between the two versions, and speed itself may affect conversion rates (faster versions naturally have higher conversion rates), causing test bias; 2) UTM parameters or source markers may be lost during redirects, leading to inaccurate attribution data; 3) If 302 redirects persist too long, Google may judge them as 301 and pass authority, affecting SEO of test pages; 4) If certain hops in multi-hop redirects set Cookies, they may affect user grouping logic. Recommend using server-side rendering splitting or client-side JS splitting (like Google Optimize, Optimizely) for A/B testing, avoid redirect splitting. If you must use redirects (like testing completely different URL paths), use 302 (not 301) and ensure single-hop direct, and remove redirects promptly after testing ends.

How do I batch check redirect chains for an entire website?

Batch checking website redirect chains requires combining crawler tools: 1) Use crawler tools like Screaming Frog SEO Spider to crawl the entire website, view all redirect URLs and chain lengths in the Redirect Chains report; 2) Use site audit features from SEO tools like Ahrefs, Semrush, or Sitebulb—they automatically detect redirect chains and loops; 3) For core page lists, you can write scripts calling this tool's backend API for batch detection; 4) Check Google Search Console "Page indexing" report for "Redirect error" and "Redirect chain too long" notices; 5) Use Chrome DevTools Lighthouse audit, Performance section marks redirect issues. Recommend prioritizing checking: homepage, main navigation pages, high-traffic landing pages, recently migrated/redesigned pages, all HTTP URLs after HTTPS switch, and all URLs under old domains.

术语表

Redirect
A mechanism where the server returns a 3xx status code and Location response header, instructing the client to automatically visit another URL. Redirects are usually transparent to the user, and browsers automatically follow jumps.
301 Moved Permanently
Permanent redirect status code. Indicates the resource has permanently moved to a new location. Search engines transfer the old URL's PageRank to the new URL, and browsers cache this redirect long-term. Recommended for permanent changes like domain migration and HTTPS switching in GET request scenarios.
302 Found
Temporary redirect status code (formerly Moved Temporarily). Indicates the resource is temporarily located elsewhere. Search engines do not transfer authority, and browsers don't cache long-term. Note: most browsers convert POST requests to GET when receiving 302, potentially losing the request body.
303 See Other
See Other status code. Typically used for redirecting to a result page after POST form submission, explicitly requiring the client to request the new URL via GET to prevent duplicate form submissions. 303 responses should not be cached.
307 Temporary Redirect
Temporary redirect status code (introduced in HTTP/1.1). Same semantics as 302, but strictly requires preserving the request method and body—POST requests receiving 307 must still request the new URL as POST, without losing form data. Suitable for temporary redirects in API and form scenarios.
308 Permanent Redirect
Permanent redirect status code (defined in RFC 7538). Same semantics as 301, but strictly requires preserving the request method and body—POST requests receiving 308 still redirect as POST. It's the "method-safe" version of 301, fully supported by modern browsers.
Location header
HTTP response header field used to specify the target URL in 3xx redirect responses. Can be an absolute URL (recommended) or relative URL. The client automatically initiates a new request to that URL after receiving it. Non-ASCII characters in Location headers must be URL-encoded.
Redirect Chain
A series of consecutive redirects from the initial URL to the final destination URL. For example, A→B→C→D forms a 3-hop redirect chain. Excessively long redirect chains slow down loading speed and erode SEO authority—recommended to keep to a single hop, no more than 3 maximum.
Redirect Loop
When a URL repeats in the redirect chain, forming an infinite jump cycle (like A→B→A). Browsers display ERR_TOO_MANY_REDIRECTS errors after reaching the maximum redirect count (usually 20). Common causes include HTTP↔HTTPS mutual jumps, www↔non-www mutual jumps, and reverse proxy protocol loss.
Domain Migration
The process of permanently switching a website from one domain to another, such as brand renaming or company mergers. During migration, all URLs on the old domain need to be 301-redirected to corresponding pages on the new domain, and a domain change notification should be submitted in Google Search Console.
URL Canonicalization
The process of unifying multiple URL variants of the same content (www/non-www, with/without trailing slash, HTTP/HTTPS, case differences) into a single standard URL, typically implemented via 301 redirects. Canonicalization avoids duplicate content issues and concentrates SEO authority.
HTTPS Forced Redirect
Configuration that redirects all HTTP (port 80) requests to HTTPS (port 443) via 301 redirects. It's a necessary step after deploying SSL/TLS certificates. Typically used with HSTS response headers to eliminate the HTTP plaintext window on first visit.
HSTS
HTTP Strict Transport Security—via the Strict-Transport-Security response header, tells the browser to only access the domain via HTTPS within a specified time. The browser internally automatically upgrades HTTP to HTTPS without server redirect. Effectively defends against SSL stripping attacks.
Short URL
Services that convert long URLs to short URLs (like bit.ly). Accessed via 301/302 redirects jumping to the original URL. Short URLs often hide multi-hop redirect chains behind them, potentially containing tracking parameters or redirecting to different targets under certain conditions.
PageRank
Web page ranking algorithm invented by Google founders Larry Page and Sergey Brin, evaluating page authority through link relationships. 301 permanent redirects transfer the old URL's PageRank to the new URL, while 302 temporary redirects typically transfer none or very little.
Core Web Vitals
Core web experience metrics defined by Google, including LCP (Largest Contentful Paint, measures load performance, good threshold ≤2.5s), FID/INP (interactivity, good threshold ≤100ms/200ms), and CLS (visual stability, good threshold ≤0.1). Redirect chains delay HTML download and directly worsen LCP metrics.
Cross-origin Redirect
When the redirect target URL has a different domain than the original URL (including completely different domains or different subdomains). Cross-origin redirects are constrained by the same-origin policy, potentially causing Cookies not to be sent, third-party Cookie blocking, and CORS preflight failures.
Chain Truncation
When the number of redirect chain hops exceeds the maximum depth limit set by the tool or browser (20 hops for this tool, 20 for Chrome), the tracer stops following subsequent redirects and marks the chain as truncated. Chain truncation usually suggests an infinite loop or abnormally complex redirect configuration.

HTTP Redirect Status Code Complete Reference

301Moved PermanentlyYes (Permanent)May change (POST→GET)Domain migration, HTTPS switch, www/non-www canonicalization, permanent URL changes
302FoundNo (Temporary)May change (POST→GET)Temporary maintenance pages, login redirects, A/B testing, short-term campaign pages
303See OtherNo (Temporary)Yes (Forces GET)Redirect to result page after POST form submission, prevents duplicate submissions
307Temporary RedirectNo (Temporary)No (Strictly preserves original method)API temporary redirects, temporary jumps needing to preserve POST data
308Permanent RedirectYes (Permanent)No (Strictly preserves original method)RESTful API permanent migration, permanent redirects needing to preserve PUT/DELETE methods

Redirect Chain SEO Impact Reference

0 hops (direct)No impact, optimal stateNo extra latencyMaintain as-is, internal links point directly to final URLs
1 hopPageRank transfers normally, SEO impact negligibleAdds ~100-300ms latency (one round trip)Acceptable, common hop count for HTTP→HTTPS and domain canonicalization
2 hopsSlight authority transfer decay possible, crawlers follow normallyAdds ~200-600ms latencyRecommend optimizing to single hop, check if internal links point to intermediate redirect URLs
3 hopsAuthority transfer efficiency drops, some crawlers may abandonAdds ~300-900ms latency, LCP may be affectedMust optimize, consolidate redirect rules directly to final URL
4-5 hopsSignificant PageRank decay, indexing may be affected, crawl budget wasteAdds 500ms-1.5s latency, LCP likely exceeds thresholdUrgent fix, check CDN/origin/application multi-layer redirect stacking
6+ hopsSevere risk, search engines may stop tracking causing deindexingLatency exceeds 1 second+, very poor user experienceImmediately investigate loops or configuration errors, restructure redirect rules
Loop (ERR_TOO_MANY_REDIRECTS)Page completely inaccessible, search engines remove from indexPage fails to load, browser shows errorHighest priority fix, use this tool to locate loop nodes

Common Redirect Configuration Errors and Fixes

ERR_TOO_MANY_REDIRECTS loop error, HTTP↔HTTPS repeated jumpingCDN/load balancer fetches origin via HTTP, origin doesn't correctly handle X-Forwarded-Proto header, always redirects to HTTPSAdd to Nginx config: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } or use $scheme variable with proxy_set_header X-Forwarded-Proto configuration
www and non-www redirecting to each other forming a loopCDN layer configures www→non-www redirect, origin Nginx configures non-www→www redirect, conflicting rulesChoose one canonical version (recommend non-www or www, stay consistent), configure redirect at only one layer (CDN or origin), delete corresponding rules at other layers
Redirect chain takes 4-5 hops to reach final pageHTTP→HTTPS hop→non-www→www hop→trailing slash hop→old path→new path, multi-layer rule stackingConsolidate redirect rules, jump directly from initial URL to final URL in one step. Use return directive in Nginx to jump to the complete final address at once
HTTP nodes appear in HTTPS site redirect chain (downgrade)Server configuration hardcodes redirect targets with http:// prefix, or application generates redirect URLs without recognizing current connection is HTTPSConfigure application to trust reverse proxy, correctly read X-Forwarded-Proto; use https:// absolute URLs or $scheme variable in Nginx (provided proxy correctly sets scheme); deploy HSTS
Browser still jumps to old address after modifying 301 redirectBrowser caches 301 permanent redirect rules long-term, F5 refresh doesn't helpDuring testing phase use 302 temporary redirects to confirm before switching to 301; clear browser cache (Chrome: Settings→Privacy→Clear browsing data→Cached images and files); use DevTools Disable cache option
Form data lost after POST request redirectUsed 301 or 302 redirect, browser automatically converts POST to GET, request body discardedFor non-GET requests like POST/PUT/DELETE, use 307 (temporary) or 308 (permanent) redirects instead, strictly preserving request method and body
URL shows double-encoded characters like %2520 after redirectURL parameters were already URL-encoded once, server encodes them a second time during redirectCheck redirect logic, ensure URL is encoded only once; use $request_uri (original URI, not decoded) rather than $uri (decoded) in Nginx
AJAX/fetch request reports CORS error after cross-origin redirectTarget server of cross-origin redirect hasn't configured CORS response headers (Access-Control-Allow-Origin, etc.)Ensure servers at every hop in the redirect chain correctly configure CORS headers; or avoid cross-origin redirects in AJAX requests, instead have frontend get target URL then request directly

Troubleshooting