Errors / Monday September 7, 2026
How to Fix Server Redirect Errors and CDN Redirect Loops
Server-level redirect configurations and CDN settings are powerful tools for managing site traffic, but when misconfigured or conflicting with each other, they create redirect loops that prevent your site from loading. Unlike WordPress-specific issues, server and CDN redirect problems require editing configuration files or adjusting CDN dashboard settings.
This guide covers how to identify and fix redirect loops caused by Apache .htaccess rules, Nginx configuration files, IIS web.config settings, and CDN redirect features. You’ll learn to diagnose conflicts between different infrastructure layers and implement clean redirect rules that work together properly.
Apache and .htaccess Redirect Loop Fixes
Apache servers use .htaccess files to control redirects, URL rewrites, and other server behaviors. Misconfigured .htaccess rules are among the most common causes of redirect loops.
Locating and Accessing .htaccess
The .htaccess file lives in your site’s root directory (usually public_html, www, or htdocs). Access it via FTP, SFTP, or your hosting control panel’s file manager.
.htaccess is a hidden file. Enable “Show hidden files” in your FTP client or file manager to see it. If no .htaccess exists, you can create one, but most WordPress and CMS installations create it automatically.
Pro Tip: Always back up .htaccess before editing. Download a copy to your computer or rename it to .htaccess-backup. A single syntax error can break your entire site, and having a backup lets you quickly restore the working version.
Testing Without .htaccess
The fastest way to determine whether .htaccess is causing your redirect loop is to temporarily disable it.
Rename .htaccess to .htaccess-disabled or .htaccess-old, then test your site. If the redirect loop disappears, something in .htaccess was causing it. If the loop persists, .htaccess isn’t the problem, rename it back to .htaccess and investigate other causes.
Common .htaccess Redirect Mistakes
Several common .htaccess patterns create redirect loops.
Conflicting HTTPS redirects happen when multiple redirect rules try to force HTTPS using different logic:
# Problematic: Two different HTTPS redirect rules
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Somewhere else in the file:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://yoursite.com/$1 [R=301,L]
These rules are redundant because both attempt to redirect HTTP traffic to HTTPS. While redundancy alone does not create a loop, duplicate rules make redirect behavior harder to troubleshoot and can cause conflicts if their target hostnames or conditions later diverge. Keep one canonical HTTPS redirect rule.
WWW/non-WWW conflicts occur when redirect rules conflict about the preferred domain format:
# Problematic: Conflicting www rules
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
# Later in the file:
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]
This redirects www to non-www, then non-www back to www, which is an obvious loop. Choose one preferred format and use only that redirect rule.
Circular redirects happen when redirect destinations trigger other redirect rules:
RewriteRule ^old-page/?$ /new-page/ [R=301,L]
RewriteRule ^new-page/?$ /old-page/ [R=301,L]
This redirects old-page to new-page, which redirects back to old-page. Audit your redirect rules to ensure destinations don’t trigger other redirects.
Clean .htaccess Redirect Rules
Use these tested .htaccess redirect patterns that avoid loops:
HTTPS redirect (single, clean rule):
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
WWW to non-WWW redirect:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
Non-WWW to WWW redirect:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
Combined HTTPS and WWW redirect:
RewriteEngine On
# Redirect to HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Redirect to www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
The [R=301,L] combination issues a permanent redirect and stops Apache from evaluating later rewrite rules during the current pass. However, the [L] flag alone does not guarantee that a .htaccess rule cannot loop, so redirect conditions must also exclude requests that already match the destination.
Pro Tip: Place redirect rules near the top of .htaccess before WordPress or CMS-specific rules. Redirect rules should execute first to prevent interference with application-level rewrites.
Nginx Redirect Loop Fixes
Nginx uses a different syntax than Apache and stores configuration in nginx.conf or site-specific config files (usually in /etc/nginx/sites-available/ or /etc/nginx/conf.d/).
Accessing Nginx Configuration
Unlike .htaccess which site owners can edit, nginx.conf usually requires server access via SSH and root or sudo privileges. Many managed hosting providers do not provide direct access to nginx.conf and instead expose supported configuration options through their control panels.
If you have SSH access, locate your nginx config:
sudo nano /etc/nginx/sites-available/yoursite.conf
Or for general configuration:
sudo nano /etc/nginx/nginx.conf
Always back up before editing:
sudo cp /etc/nginx/sites-available/yoursite.conf /etc/nginx/sites-available/yoursite.conf.backup
Common Nginx Redirect Problems
Conflicting server blocks create loops when HTTP and HTTPS server blocks redirect to each other:
# Problematic configuration
server {
listen 80;
server_name example.com;
return 301 http://example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
return 301 https://example.com$request_uri;
}
These blocks redirect to themselves, creating loops. Proper configuration redirects HTTP to HTTPS, but HTTPS doesn’t redirect:
# Correct configuration
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
# SSL configuration and site content here
# No redirect in HTTPS block
}
Incorrect rewrite rules using regex patterns that match too broadly:
# Problematic: matches everything including the destination
rewrite ^/(.*)$ https://example.com/$1 permanent;
If placed in the HTTPS server block, this matches all requests (including those already on HTTPS) and redirects them to HTTPS again, creating a loop.
Clean Nginx Redirect Rules
HTTPS redirect:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
WWW to non-WWW redirect (HTTPS):
server {
listen 443 ssl;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
# Your SSL and site configuration here
}
Combined HTTP to HTTPS and WWW to non-WWW:
# HTTP to HTTPS
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
# WWW to non-WWW (HTTPS)
server {
listen 443 ssl;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
# Main HTTPS server block
server {
listen 443 ssl;
server_name example.com;
# SSL certificates and site configuration
}
After editing nginx configuration, test the syntax:
sudo nginx -t
If the test passes, reload nginx:
sudo systemctl reload nginx
Pro Tip: Nginx’s return directive is more efficient than rewrite for simple redirects. Use return 301 for permanent redirects rather than complex rewrite rules when possible.
IIS and web.config Redirect Fixes
Windows servers running IIS use web.config files (XML format) to configure redirects through URL Rewrite rules.
Common web.config Redirect Issues
Overlapping URL Rewrite rules that process requests multiple times:
<!– Problematic: Multiple rules that might conflict –>
<rewrite>
<rules>
<rule name=”HTTP to HTTPS” stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTPS}” pattern=”off” />
</conditions>
<action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” />
</rule>
<rule name=”Force WWW” stopProcessing=”false”>
<match url=”(.*)” />
<action type=”Redirect” url=”https://www.example.com/{R:1}” />
</rule>
</rules>
</rewrite>
The second rule’s stopProcessing=”false” allows it to execute even after the first rule, potentially creating loops. Set stopProcessing=”true” on all redirect rules to prevent multiple rules from processing the same request.
Clean IIS Redirect Rules
HTTPS redirect in web.config:
<rewrite>
<rules>
<rule name=”HTTP to HTTPS” stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTPS}” pattern=”off” />
</conditions>
<action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />
</rule>
</rules>
</rewrite>
Always use stopProcessing=”true” to prevent redirect loops from chained rules.
CDN Redirect Configuration
CDN services like Cloudflare, Stackpath, Sucuri, and others provide redirect features that can conflict with server-level redirects.
Cloudflare Redirect Rules and Page Rules
Cloudflare currently provides several redirect mechanisms, including Single Redirects, Bulk Redirects, and legacy Page Rules. For new redirect configurations, Single Redirects are generally the preferred option, while existing Page Rules can continue to be reviewed for conflicts.
Cloudflare Page Rules create redirects, force HTTPS, or manipulate URLs at the edge before requests reach your server.
Common conflicts: Cloudflare Page Rule forces HTTPS while your server .htaccess also forces HTTPS. If these use different logic or timing, loops can occur.
The fix: If your origin supports HTTPS, use Full (Strict) when the origin has a valid certificate, or Full when appropriate, instead of Flexible. Alternatively, remove the origin-level HTTP-to-HTTPS redirect and let Cloudflare handle that redirect. Cloudflare specifically warns that combining origin redirects with Always Use HTTPS can cause redirect-loop errors.
To check Cloudflare Page Rules, log into your Cloudflare dashboard, select your domain, go to Rules > Page Rules, and review active rules. Disable or delete rules that conflict with your server configuration.
Cloudflare Always Use HTTPS
Found under SSL/TLS > Edge Certificates, “Always Use HTTPS” redirects all HTTP requests to HTTPS at Cloudflare’s edge.
This conflicts with server HTTPS redirects when your SSL mode is set to Flexible (Cloudflare connects to your server via HTTP). Your server detects HTTP and redirects to HTTPS, while Cloudflare converts HTTPS back to HTTP when connecting to your origin, creating a loop.
The fix: Change SSL mode from Flexible to Full or Full (Strict) when using “Always Use HTTPS.” This lets Cloudflare connect to your origin via HTTPS, eliminating the HTTP-to-HTTPS redirect loop.
Other CDN Redirect Features
Most CDNs offer similar redirect capabilities. Check your CDN dashboard for features like force HTTPS, URL forwarding, edge redirects, or page rules.
The principle is the same across CDNs: avoid having multiple layers enforce the same redirect. Different redirect responsibilities can exist at different layers as long as they do not overlap or contradict one another.
Diagnosing Server vs CDN Redirect Conflicts
When redirect loops involve both server configuration and CDN settings, identify which layer is causing the issue.
Bypassing the CDN
Temporarily bypass your CDN to test if server configuration alone causes the loop.
For Cloudflare, set the cloud icon next to your DNS records to “DNS only” (gray cloud) rather than “Proxied” (orange cloud). This sends traffic directly to your server, bypassing Cloudflare’s edge.
Test your site. If the redirect loop disappears, the conflict involves Cloudflare configuration. If it persists, your server configuration has the issue.
After testing, re-enable CDN proxying (orange cloud in Cloudflare).
Checking Redirect Headers
Use redirect checker tools (redirectchecker.org, httpstatus.io) or browser developer tools to see which server/CDN is sending redirects.
In browser developer tools (F12), go to the Network tab and reload your page. Look at the response headers for redirect responses (301, 302, 307, 308 status codes). The Server header often indicates whether the redirect came from your origin server or the CDN.
Cloudflare adds a cf-ray header to responses. A Cloudflare-specific response header can confirm that the response passed through Cloudflare, but headers alone do not always prove which configuration layer originally generated a redirect. Compare the full redirect chain and, when possible, temporarily bypass the CDN to isolate the origin.
For reliable server configuration with properly optimized CDN integration, quality managed hosting ensures server-level redirects and CDN settings are configured to work together harmoniously from the start, minimizing redirect conflict risks.
Coordinating Server and CDN Redirects
The key to avoiding redirect loops is coordination between all infrastructure layers.
Single Redirect Responsibility
Assign redirect responsibilities clearly: CDN handles HTTP-to-HTTPS redirects, server handles www/non-www redirects, or choose another division that makes sense for your setup.
Document which layer handles each redirect type. When troubleshooting or making changes, consult your documentation to avoid creating conflicts.
Testing After Configuration Changes
After modifying server configs or CDN settings, test all URL variations: http://example.com, https://example.com, http://www.example.com, and https://www.example.com. All should successfully redirect to your preferred canonical URL without loops.
Use redirect checker tools to visualize the redirect chain. Healthy configurations show minimal redirects (ideally one) from any variation to your canonical URL.
How to Prevent Server and CDN Redirect Loops
Server and CDN redirect loops stem from misaligned configurations across your infrastructure. Start by identifying whether .htaccess (Apache), nginx.conf (Nginx), or web.config (IIS) contains redirect rules, then check if your CDN also enforces redirects. Conflicts between these layers create the loops.
Fix server-side issues by using clean, tested redirect rules that don’t conflict with each other. Ensure HTTPS redirects don’t send HTTPS traffic back to HTTP, and www/non-www redirects only work in one direction. For CDN issues, align CDN SSL modes with your server’s capabilities and disable redundant redirect features.
Choose one infrastructure layer to handle each type of redirect – typically CDN for HTTPS and server for www preferences. Document your choices and test thoroughly after any configuration changes. Proper coordination between the server and CDN prevents loops while ensuring efficient traffic routing.
Frequently Asked Questions
Yes, but only if they handle different redirect types without overlap. For example, your CDN could handle HTTP-to-HTTPS while .htaccess handles www-to-non-www. Avoid having both systems redirect the same traffic, or conflicts will occur.
Temporarily bypass your CDN (set Cloudflare DNS to DNS-only mode or pause the CDN service). If the loop disappears, the CDN configuration was involved. If it persists, the issue is in your server config.
The [L] flag means Last. It stops Apache from evaluating later rewrite rules during the current processing pass. It is commonly paired with [R] for external redirects, but it doesn’t prevent every redirect or rewrite loop in .htaccess because a rewritten request can be processed again. The rule’s conditions must also prevent the destination from matching the same redirect repeatedly.
This typically happens after configuration changes like enabling a new CDN feature, updating server configs, installing plugins that add redirect rules, or renewing/changing SSL certificates. Review recent changes to identify what introduced the conflict.
