Implementing Cloudflare on a WordPress site can lead to dramatic improvements in loading speed and enhanced security. However, even a minor configuration error can often cause issues such as “pages not loading” or “being unable to access the admin panel (wp-admin).”
The most common issues include a redirect loop known as “ERR_TOO_MANY_REDIRECTS” and access restrictions caused by a “403 Forbidden” error. In this article, we’ll explain the causes of these common errors that occur when combining Cloudflare and WordPress, along with practical solutions you can implement right away.
Causes and Solutions for ERR_TOO_MANY_REDIRECTS (Redirect Loop)
The most common error screen encountered immediately after connecting Cloudflare to a WordPress site is the “Too Many Redirects (ERR_TOO_MANY_REDIRECTS)” error. This error indicates that a redirect loop has occurred between Cloudflare and the server during the HTTP-to-HTTPS redirection process, causing the process to go round in circles.
Cause: SSL or TLS Configuration Mismatch
The root cause is a discrepancy between Cloudflare’s SSL encryption mode and the HTTPS settings on the origin server (such as a shared hosting server). For example, if a free SSL certificate is already active on the origin server but Cloudflare’s SSL setting is set to “Flexible,” the following vicious cycle occurs:
- The browser accesses Cloudflare via “HTTPS”
- Cloudflare forwards the request to the server via “HTTP” (due to the Flexible setting)
- The server enforces “HTTPS” communication and responds to Cloudflare with “Redirect to HTTPS”
- Cloudflare continues to instruct the browser to “redirect to HTTPS”
Solution: Change the SSL encryption mode to “Full” or “Full (Strict)”
The simplest and most reliable solution is to change the SSL setting to “Full” or “Full (Strict)” in the Cloudflare dashboard.
- Log in to the Cloudflare dashboard
- Select the target domain (website)
- Open “SSL/TLS” from the left-hand menu
- Change the encryption mode to “Full” or “Full (Strict)”
This setting change will ensure that communication between Cloudflare and the origin server also occurs over HTTPS, resolving the loop. Additionally, please clear the cache in your browser and any caching plugins installed in WordPress to apply the changes.
Causes and Solutions for 403 Forbidden
“403 Forbidden” is an HTTP status code that appears when a request reaches the server successfully but is denied access by the server due to a lack of permissions.
Cause: False positives from anti-bot features or WAF
When using Cloudflare, all traffic passes through a proxy server. There are two main scenarios to consider in this case.
- Cloudflare’s Web Application Firewall (WAF) or anti-bot measures are mistakenly identifying certain WordPress functions (such as REST API calls or plugin processing) as cyberattacks and blocking them
- The hosting provider’s security features (such as restrictions on access from foreign IP addresses) are treating access from Cloudflare’s relay servers as suspicious and blocking it entirely
Solution 1: Review the server’s restrictions on access from foreign IP addresses
On Japanese hosting services (such as Lolipop or Xserver), features that restrict access from overseas IP addresses to the WordPress admin panel are enabled by default. Since Cloudflare’s edge servers are located worldwide, this can cause the block. Open your server’s control panel and temporarily disable settings like “Overseas IP Access Restrictions” or “WordPress Security Settings” to see if the issue is resolved.
Solution 2: Configure WAF exception rules on the Cloudflare side
Conversely, if Cloudflare is blocking the access, check the access logs under “Security” → “Events” in the dashboard. If your own access or necessary APIs (such as wp-json) are included among the “Blocked” requests, identify the rule ID and add it to the exception rules.
Troubleshooting When You Can’t Access wp-admin
It can be particularly frustrating when the front-end of your site appears normal, but you’re unable to access the admin panel (wp-admin / wp-login.php) or keep getting blocked after repeated login attempts.
Cause: Cookie mismatch or conflict with forwarding rules
When “Always Use HTTPS” is enabled in Cloudflare settings, if WordPress cannot correctly recognize via environment variables that it is communicating over HTTPS, login cookies will not be issued properly, preventing access to the admin panel.
Solution: Add reverse proxy settings to `wp-config.php`
To ensure WordPress correctly recognizes that it is running behind a proxy, add the following code to the top of `wp-config.php` (above the line `require_once(ABSPATH . ‘wp-settings.php’);`).
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}This allows WordPress to recognize that the connection is currently via HTTPS even when using a proxy, resolving login errors and unintended admin panel loops. After modifying the code, clear your browser cache and try logging in again.
Resolving Mixed Content Errors
After switching to HTTPS, if a “Not Secure” warning appears in the browser’s address bar or if some images or CSS files on the site fail to load, this is referred to as “Mixed Content.”
Cause: “http://” remains in URL links
Even if the entire site is served over “https://,” if image URLs within posts or theme file sources are hardcoded to start with “http://,” the browser will block the loading of those files as a security risk.
Solution: Enable Automatic HTTPS Rewrites
The easiest solution is to use Cloudflare’s feature to automatically rewrite these URLs. Follow the steps below to configure it.
- Open the “SSL/TLS” menu on the left side of the Cloudflare dashboard
- Go to “Edge Certificates” in the submenu
- Toggle the “Automatic HTTPS Rewrites” switch to ON
When this feature is enabled, Cloudflare automatically rewrites all URL links in HTML that can be safely replaced from “http://” to “https://” before serving the content.
How to Debug When Caching Doesn’t Work
It’s common for design changes not to appear, or for old files to keep loading even after you’ve fixed a bug.
Cause: Old response data is retained on the CDN side
Even if you clear the cache in your WordPress caching plugin, if a strong cache remains on the Cloudflare servers upstream, end users will always be served the old data.
Solution: Purge All and Developer Mode
Whenever you make changes to CSS, JS, or other files, be sure to delete the data on the Cloudflare side as well.
- Click “Purge Everything” under “Purge Cache” in the top-right corner of the dashboard
- While working, you can temporarily bypass the caching functionality by temporarily enabling “Development Mode” in the bottom-right corner of the Overview page
If you need to check how caching works through Cloudflare directly in your browser, open your browser’s developer tools (Network tab) and look for `cf-cache-status: HIT` or `cf-cache-status: MISS` in the response headers of the target file to determine whether the issue is on the server side or the CDN side.
Summary
While the combination of Cloudflare and WordPress is powerful, it is not uncommon to encounter redirect loops or errors that occur at the boundary between the infrastructure and the application. The key to troubleshooting is to calmly identify “where the connection is being interrupted or looping.”
- If a redirect loop (ERR_TOO_MANY_REDIRECTS) occurs, set the SSL configuration to “Full (Strict)”
- If a 403 error occurs, check for server-side IP restrictions or WAF block logs
- If the error occurs in the admin panel, add the proxy forwarding code (X-Forwarded-Proto) to wp-config.php
- For mixed content or layout issues, utilize HTTPS automatic rewriting and cache purging
By keeping these solutions in mind, you can quickly resolve most issues. To ensure stable site operation and improve performance, review your settings and maintain a secure server environment.
Comment