The web server failed to serve a page because it got stuck in an infinite loop, repeatedly sending the browser back to itself.

There are a few ways this can happen, but they all boil down to Nginx or Apache telling the browser, "Go here," and then that "here" also telling the browser, "Go here," and so on.

Common Causes and Fixes

1. Incorrect redirect or rewrite Rules in Nginx

  • Diagnosis: Examine your Nginx configuration files (usually in /etc/nginx/nginx.conf or /etc/nginx/sites-available/your_site). Look for return or rewrite directives that might be causing a loop. A common culprit is redirecting HTTP to HTTPS and then having another rule that redirects the HTTPS version back to HTTP, or redirecting www.example.com to example.com and then example.com back to www.example.com without proper conditions.
  • Fix: Ensure your redirect rules are mutually exclusive and have conditions that prevent them from triggering each other. For example, to redirect HTTP to HTTPS, use:
    server {
        listen 80;
        server_name example.com www.example.com;
        return 301 https://$host$request_uri;
    }
    
    server {
        listen 443 ssl;
        server_name example.com www.example.com;
        # SSL configuration...
        # ... your application configuration ...
    }
    
    This rule only applies to port 80 (HTTP) and redirects to the HTTPS version. The HTTPS server block then handles the secure requests.
  • Why it works: The return 301 https://$host$request_uri; directive tells the browser to permanently move to the specified HTTPS URL. By ensuring the listen 443 ssl block doesn’t have a rule that redirects back to HTTP, the loop is broken.

2. Incorrect Redirect or RewriteRule in Apache

  • Diagnosis: Check your Apache configuration files, typically .htaccess files in your web root or the main apache2.conf / httpd.conf and virtual host configurations. Similar to Nginx, look for conflicting Redirect or RewriteRule directives. A common mistake is redirecting http:// to https:// and then having a rule that redirects https:// back to http:// or an infinite redirect between www and non-www versions.
  • Fix: Use conditions in your RewriteRule directives to prevent loops. For example, to redirect HTTP to HTTPS:
    <VirtualHost *:80>
        ServerName example.com
        ServerAlias www.example.com
        Redirect permanent / https://example.com/
    </VirtualHost>
    
    <VirtualHost *:443>
        ServerName example.com
        ServerAlias www.example.com
        # SSL configuration...
        # ... your application configuration ...
    </VirtualHost>
    
    Or using mod_rewrite:
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    
  • Why it works: The RewriteCond %{HTTPS} off ensures the rule only applies when the connection is not HTTPS. The [L] flag means "Last rule," so if this rule is matched, no further rules are processed for this request, preventing a subsequent rule from catching the redirect and looping. The R=301 indicates a permanent redirect.

3. Mixed HTTP and HTTPS URLs in Application Code

  • Diagnosis: Even if your web server redirects are correct, your application (e.g., WordPress, a custom PHP app) might be generating URLs that are a mix of HTTP and HTTPS. This can happen if the application’s "site URL" or "home URL" settings are incorrect, or if it’s hardcoded to use one protocol over the other without checking the current request.
  • Fix:
    • WordPress: Go to Settings -> General in your WordPress admin dashboard and ensure both "WordPress Address (URL)" and "Site Address (URL)" are set to https://yourdomain.com. If you can’t access the admin, you can fix this by editing your wp-config.php file and adding these lines:
      define('WP_HOME','https://yourdomain.com');
      define('WP_SITEURL','https://yourdomain.com');
      
    • Other Apps: Review your application’s configuration files or database settings for hardcoded URLs and ensure they consistently use HTTPS.
  • Why it works: By forcing the application to generate all its links using HTTPS, it stops sending requests to the web server that the server then needs to redirect from HTTP to HTTPS, thus breaking the loop.

4. Incorrect proxy_redirect or proxy_pass in Nginx

  • Diagnosis: If Nginx is acting as a reverse proxy to an application server (e.g., Node.js, Gunicorn), a misconfiguration in proxy_redirect or proxy_pass can cause redirects. This is especially true if the backend application itself issues redirects that Nginx then mangles or re-issues incorrectly.
  • Fix: Ensure proxy_pass is correctly pointing to your backend. For proxy_redirect, it’s often best to let the backend handle its own redirects and have Nginx pass them through. If you need proxy_redirect, ensure it’s not creating a loop. A common fix is to ensure proxy_pass includes a trailing slash if the target location also has one, or to explicitly set proxy_redirect off; if you trust the backend’s redirects.
    location / {
        proxy_pass http://backend_server:8080/; # Note the trailing slash
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect off; # Often a good default if backend is reliable
    }
    
  • Why it works: proxy_pass directs traffic to the backend. proxy_redirect off; tells Nginx not to alter Location or Content-Location headers from the backend, allowing the backend application to control its redirects directly without Nginx interfering and potentially creating a loop.

5. SSL/TLS Certificate Issues Leading to Redirects

  • Diagnosis: Sometimes, a misconfigured SSL setup can cause the server to issue a redirect from HTTPS back to HTTP (or vice-versa) if it believes the certificate is invalid or missing for the requested protocol. Check your SSL certificate installation and configuration for the virtual host.
  • Fix: Ensure your SSL certificate is correctly installed for the domain and that your Nginx or Apache virtual host is configured to listen on port 443 with the correct certificate and key paths.
    • Nginx:
      server {
          listen 443 ssl http2;
          server_name example.com;
          ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
          # ... other config ...
      }
      
    • Apache:
      <VirtualHost *:443>
          ServerName example.com
          SSLEngine on
          SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
          SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
          # ... other config ...
      </VirtualHost>
      
  • Why it works: A properly configured SSL block ensures that when a browser connects via HTTPS, the server responds with the correct certificate and proceeds with serving content, rather than issuing an erroneous redirect due to a perceived SSL problem.

6. Load Balancer/CDN Configuration Errors

  • Diagnosis: If you have a load balancer (like HAProxy, AWS ELB) or a CDN (like Cloudflare) in front of your Nginx/Apache server, the redirect loop could originate there. The load balancer might be configured to redirect HTTP to HTTPS, and your backend server is also configured to do the same, creating a double redirect.
  • Fix: Review the redirect settings on your load balancer or CDN. Often, you’ll want to configure the redirect at only one layer. If your CDN handles SSL termination and redirects HTTP to HTTPS, ensure your backend server is configured to accept HTTPS traffic directly and not issue its own HTTP-to-HTTPS redirects. Check X-Forwarded-Proto or similar headers to understand what protocol the original request used.
  • Why it works: By centralizing the redirect logic to a single point (either the CDN/LB or the backend server), you avoid having two systems try to perform the same redirect simultaneously, which is a common cause of infinite loops.

After fixing these, you’ll likely encounter a 502 Bad Gateway if your backend application wasn’t started correctly during the troubleshooting process.

Want structured learning?

Take the full Http course →