Nginx Redirect Analyzer
Analyze Nginx redirect chains, detect loops, validate rewrite rules and regex patterns
Enter Nginx configuration containing redirect rules (return, rewrite) to analyze
What is the Nginx Redirect Analyzer?
The Nginx Redirect Analyzer is a client-side tool that inspects Nginx configuration for redirect chains, redirect loops, invalid rewrite regex patterns, and common misconfiguration mistakes. It calculates a quality score and provides actionable recommendations to fix issues before they cause problems in production.
How to Use
- Paste your Nginx configuration containing redirect/rewrite rules
- Click "Analyze" or wait for automatic processing
- Review findings with severity ratings (Critical, High, Medium, Low)
- Check recommendations for fixing detected issues
- Export a full report in JSON or Markdown format
Example: Redirect Loop
This configuration creates an infinite redirect loop between two locations:
location /page-a {
return 301 /page-b;
}
location /page-b {
return 301 /page-a;
}What Issues Are Detected?
- Redirect loops — Circular redirects (A → B → A) that cause ERR_TOO_MANY_REDIRECTS
- Redirect chains — Multi-hop redirects (A → B → C) that add unnecessary latency
- Invalid regex — Rewrite patterns with syntax errors that prevent Nginx from starting
- Missing flags — Rewrite rules without last/break/redirect/permanent termination
- Overly broad patterns — Regex like ^(.*)$ that match all requests unintentionally
- Protocol downgrade — Redirecting from HTTPS to HTTP URLs
- Missing end anchors — Regex starting with ^ but lacking $ for exact matching
- Empty redirect targets — Return codes without URL (301 without destination)
Redirect Best Practices
- Use return instead of rewrite for simple redirects — it is faster and clearer
- Always use 301 for permanent redirects to preserve SEO link equity
- Use 302 only for genuinely temporary redirects (A/B tests, maintenance)
- Keep redirect chains to zero hops — point directly to the final destination
- Add the $ anchor to rewrite patterns for precise path matching
- Use map blocks for managing many redirects efficiently
- Test redirects with
curl -ILto verify the full redirect path
Privacy and Security
All analysis happens entirely in your browser using JavaScript. Your Nginx configuration — which may contain internal server names, IP addresses, and infrastructure details — is never transmitted to any server. No data is stored, logged, or shared.
Frequently Asked Questions
What does the Nginx Redirect Analyzer check?
The Nginx Redirect Analyzer inspects your Nginx configuration for redirect-related issues including redirect chains (A → B → C), redirect loops (A → B → A), invalid rewrite regex patterns, missing termination flags, mixed protocol redirects (HTTPS downgrade to HTTP), overly broad regex patterns, and incorrect return codes. It calculates a quality score and provides specific recommendations for each issue found.
What is a redirect chain and why is it bad?
A redirect chain occurs when a URL redirects to another URL, which in turn redirects to yet another URL (e.g., /old → /middle → /new). Each hop adds latency (typically 100-300ms per redirect) and wastes crawl budget for SEO. Browsers have a maximum redirect limit (usually 20 hops) after which they stop following and show an error. The fix is to point all redirects directly to the final destination.
How do redirect loops happen in Nginx?
Redirect loops occur when two or more rules create a circular redirect path. For example, one rule redirects /page-a to /page-b, and another redirects /page-b back to /page-a. This can also happen with a single overly broad rewrite rule that matches its own target URL. Browsers display ERR_TOO_MANY_REDIRECTS when they detect a loop.
What rewrite flags should I use?
Nginx rewrite supports four flags: 'permanent' (301 redirect, cached by browsers), 'redirect' (302 temporary redirect), 'last' (restarts request processing with new URI, use in server context), and 'break' (stops processing further rewrites, use in location context). Missing a flag can cause the rewrite to continue processing subsequent rules unexpectedly.
When should I use 'return' vs 'rewrite' for redirects?
Use 'return' for simple redirects where you know the exact target URL — it is faster because Nginx does not need to evaluate a regex. Use 'rewrite' only when you need regex pattern matching to transform the URL dynamically (e.g., capturing path segments). For blanket domain or protocol redirects, 'return 301 https://$host$request_uri;' is preferred.
Why is redirecting to HTTP flagged as an issue?
Redirecting from HTTPS to HTTP (protocol downgrade) strips TLS encryption from the connection, exposing user data to interception. This violates HSTS policies if configured, and browsers increasingly warn users about insecure connections. Always redirect to HTTPS targets unless you have a specific reason for plain HTTP (e.g., local development).
Is my Nginx configuration sent to a server?
No. All analysis happens entirely in your browser using JavaScript. Your Nginx configuration — which may contain internal server names, IP addresses, and infrastructure details — is never transmitted to any server. No data is stored, logged, or shared.
What regex issues are detected in rewrite rules?
The analyzer detects: invalid regex syntax that would prevent Nginx from starting, unclosed character classes or capture groups, missing end anchors ($) that cause broader matching than intended, unescaped dots that match any character instead of literal periods, and overly broad patterns (like ^(.*)$) that catch all requests indiscriminately.
What is the difference between this tool and the Nginx Security Inspector?
The Nginx Redirect Analyzer focuses specifically on redirect/rewrite rules — chains, loops, regex validation, and redirect best practices. The Nginx Security Inspector analyzes broader security configuration including SSL/TLS, security headers, rate limiting, sensitive paths, and access controls. Use both for a comprehensive Nginx configuration audit.