How to Fix a WordPress HTTPS Redirect Loop

A WordPress HTTPS redirect loop usually means two parts of the site disagree about whether a request is secure. Check the WordPress URLs first, then inspect your CDN or reverse proxy before changing plugins or rewriting server rules.

Before editing configuration or database values, create a backup of the affected file or database table.

Check the WordPress URLs

If you can access WP-CLI, run:

wp option get home
wp option get siteurl

Both values should use the intended hostname and protocol, such as:

https://example.com

A mismatch such as http://example.com for one option and https://example.com for the other can create competing redirects.

Correct the values with WP-CLI if necessary:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

These commands change site configuration, so record the old values first. The WP-CLI option command documentation covers retrieving and updating WordPress options.

If WP-CLI is unavailable, check Settings > General in the dashboard. Confirm that both WordPress Address (URL) and Site Address (URL) use the same protocol and canonical hostname.

When wp-admin is inaccessible

You can temporarily define the URLs in wp-config.php:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Add these lines above:

/* That's all, stop editing! Happy publishing. */

Remove the definitions after correcting the underlying database values unless you intend to manage the URLs permanently through wp-config.php.

As another fallback, edit the home and siteurl rows in the database’s options table using your hosting database tool. Confirm the table prefix before editing because it may not be wp_.

Check whether WordPress detects HTTPS

A common loop occurs when a CDN, load balancer, or reverse proxy accepts HTTPS but connects to WordPress over HTTP. The proxy redirects traffic to WordPress, WordPress sees an HTTP request, and another component sends the visitor back to HTTPS repeatedly.

WordPress documents this case in its guidance on administration over SSL and reverse proxies.

If your trusted proxy sends the X-Forwarded-Proto header, add this before WordPress loads in wp-config.php:

if (
	isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) &&
	strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false
) {
	$_SERVER['HTTPS'] = 'on';
}

Only use this when your hosting provider or proxy confirms that it sets and controls that header. Accepting a client-supplied forwarding header without a trusted proxy can make WordPress misidentify insecure requests as HTTPS.

If your platform uses a different header, ask the host for its supported WordPress configuration rather than guessing.

Correct the Cloudflare SSL mode

With Cloudflare, a loop can occur when the visitor-to-Cloudflare connection uses HTTPS but Cloudflare connects to the origin over HTTP while the origin forces HTTPS.

In Cloudflare, open SSL/TLS and check the encryption mode:

• Use Full (strict) when the origin has a valid certificate.
• Use Full only when the origin supports HTTPS but its certificate cannot pass strict validation.
• Avoid Flexible when WordPress or the origin server redirects HTTP requests to HTTPS.

Cloudflare explains the connection behavior of each option in its SSL/TLS encryption modes documentation.

Do not select Full (strict) until HTTPS works directly at the origin with a valid certificate. Otherwise, the redirect loop may be replaced by an origin certificate error.

Remove competing HTTPS redirects

HTTPS may be enforced in several places:

• The hosting control panel
• Cloudflare or another CDN
• Apache .htaccess
• Nginx configuration
• A security or redirect plugin
• WordPress code in wp-config.php

Choose one primary layer to handle the HTTP-to-HTTPS redirect. Multiple identical redirects do not always cause a loop, but conflicting protocol or hostname rules often do.

For example, one rule may redirect http://www.example.com to https://example.com, while another sends https://example.com back to https://www.example.com.

Temporarily disable custom redirect rules one layer at a time. Keep a copy of every file or rule before changing it. After each change, test these addresses:

http://example.com
http://www.example.com
https://example.com
https://www.example.com

They should all settle on one canonical HTTPS address without alternating between hostnames or protocols.

If removing an Apache or Nginx rule fixes the site, restore only the single redirect needed for the chosen canonical URL. Ask the host to review server-level rules when they are not visible in your account.

Purge every cache layer

A cached 301 redirect can make a corrected site appear broken. After changing the URLs, proxy configuration, or redirect rules, clear:

1. The WordPress caching plugin
2. The host’s page or reverse-proxy cache
3. The CDN cache
4. The browser cache and cookies for the site

Test again in a private browsing window. If the loop remains there, it is probably still being generated by the server, CDN, or WordPress rather than the normal browser cache.

Check plugins only after the HTTPS layers agree

If the URLs, proxy headers, SSL mode, and server redirects are correct, temporarily disable plugins that manage SSL, redirects, caching, security, or canonical URLs.

When the dashboard is unavailable, rename the suspected plugin directory under wp-content/plugins, then test the site. Restore the original directory name immediately if disabling it does not change the redirect behavior.

Re-enable plugins individually. If the loop returns after one plugin is activated, review that plugin’s HTTPS and redirect settings before replacing or removing it.