How to Fix "ERR_TOO_MANY_REDIRECTS" Error in Nginx with SSL

An alert went off at 2:15 a.m. when a user reported that they couldn't access the company website. Upon investigation, the team discovered the dreaded "ERR_TOO_MANY_REDIRECTS" error. This is a common issue among developers configuring SSL for Nginx servers, and understanding how to resolve it is crucial.

What Happens During Redirects in Nginx?

To troubleshoot this effectively, it’s important to understand the mechanism behind redirects in Nginx. When a client sends a request to a server that should ideally redirect the user from HTTP to HTTPS (or vice versa), the server evaluates its configuration files to determine how to handle the incoming request.

1. Initial Request: The client (browser) sends a request to access a resource. This could be an HTTP request for http://example.com.
2. Redirection Rule Triggered: Nginx checks its configuration files for any redirect rules. For instance, a common rule might redirect all HTTP traffic to HTTPS.
3. Response Sent: Nginx responds with a 301 or 302 status code, instructing the client to make a new request to the specified HTTPS URL.
4. Repeat Process: If there’s another conflicting redirection rule or if the client is mistakenly redirected back to HTTP or to the same URL, this process repeats.
5. Cycle Formation: Eventually, the browser detects that it has been redirected too many times, leading to the "ERR_TOO_MANY_REDIRECTS" message.

Understanding this process is essential when diagnosing the problem and configuring your Nginx settings correctly.

Failure Case Study: Real-World Incident

In one case, a developer set up an Nginx server for a new application, enforcing HTTPS via a redirect. However, they inadvertently created a loop by having both the server block and the HTTP to HTTPS redirection block overlap incorrectly.

Symptoms Observed:

• Users reported "ERR_TOO_MANY_REDIRECTS" when trying to access the website.
• The issue persisted across different browsers and devices.

Root Cause:

The developer had a configuration that included both a server block for www.example.com and another for example.com, each with its own redirection rules. The syntax conflict led to an infinite redirect loop.

Resolution:

After inspecting the configuration, the developer consolidated the rules into a single block, ensuring that all HTTP requests were redirected to HTTPS without conflicts. The issue was rectified by 3 a.m., allowing normal access to the application.