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.confor/etc/nginx/sites-available/your_site). Look forreturnorrewritedirectives 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 redirectingwww.example.comtoexample.comand thenexample.comback towww.example.comwithout 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:
This rule only applies to port 80 (HTTP) and redirects to the HTTPS version. The HTTPS server block then handles the secure requests.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 ... } - Why it works: The
return 301 https://$host$request_uri;directive tells the browser to permanently move to the specified HTTPS URL. By ensuring thelisten 443 sslblock 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
.htaccessfiles in your web root or the mainapache2.conf/httpd.confand virtual host configurations. Similar to Nginx, look for conflictingRedirectorRewriteRuledirectives. A common mistake is redirectinghttp://tohttps://and then having a rule that redirectshttps://back tohttp://or an infinite redirect betweenwwwand non-wwwversions. - Fix: Use conditions in your
RewriteRuledirectives to prevent loops. For example, to redirect HTTP to HTTPS:
Or using<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>mod_rewrite:RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] - Why it works: The
RewriteCond %{HTTPS} offensures 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. TheR=301indicates 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 -> Generalin your WordPress admin dashboard and ensure both "WordPress Address (URL)" and "Site Address (URL)" are set tohttps://yourdomain.com. If you can’t access the admin, you can fix this by editing yourwp-config.phpfile 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.
- WordPress: Go to
- 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_redirectorproxy_passcan cause redirects. This is especially true if the backend application itself issues redirects that Nginx then mangles or re-issues incorrectly. - Fix: Ensure
proxy_passis correctly pointing to your backend. Forproxy_redirect, it’s often best to let the backend handle its own redirects and have Nginx pass them through. If you needproxy_redirect, ensure it’s not creating a loop. A common fix is to ensureproxy_passincludes a trailing slash if the target location also has one, or to explicitly setproxy_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_passdirects traffic to the backend.proxy_redirect off;tells Nginx not to alterLocationorContent-Locationheaders 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>
- Nginx:
- 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-Protoor 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.