Why two settings decide everything
Cloudflare connects in a few clicks, which is exactly why it gets left as is. Yet two failures cost you a client. The first concerns encryption: in Flexible mode, Cloudflare talks plain HTTP to the origin; if the origin already redirects everything to HTTPS, the request loops and the browser shows ERR_TOO_MANY_REDIRECTS. The second concerns caching: as soon as a rule that is too broad makes HTML eligible, a personalised page can be served to another visitor. The answer is not to turn Cloudflare off but to split the roles. The agency owns the client relationship and the zone settings; the host owns the origin, meaning a valid certificate, the redirects and the cache headers.
What this standard configuration spares you
- Redirect loop — Flexible mode combined with an HTTP to HTTPS redirect on the origin, which the browser reports as ERR_TOO_MANY_REDIRECTS.
- Logged-in page served to another visitor — a "cache everything" rule with no exception for the cart, the account or the admin area.
- Frozen back office — the admin area shows an old version because a dynamic response was kept.
- 525 and 526 errors — the TLS handshake fails or the origin certificate fails validation as soon as you switch to Full or Full (strict).
- Cosmetic encryption — in Flexible, the visitor sees the padlock while the leg between Cloudflare and the origin travels in clear text.
- Different settings on every site — one list of steps replaces case-by-case decisions, and therefore the omissions.
Prerequisites to check before touching the zone
Four points, none of which can be guessed. A valid certificate on the origin: not expired, not revoked, issued for the site name, with the full chain (leaf and intermediates). The Cloudflare documentation accepts a certificate from a public authority such as Let's Encrypt, or a Cloudflare Origin CA certificate, which is only valid as long as the record stays proxied. Port 443 open to the origin, with SNI supported. Access to the client's DNS zone. Finally, the list of the site's dynamic URLs: admin, cart, checkout, account.
On a ServOrbit hosting plan, the Let's Encrypt SSL certificate is included, with automatic renewal: the origin therefore meets the first point, and Full (strict) mode becomes possible. The check that renewal still works behind the proxy is in the last step.
Cloudflare SSL/TLS modes, from Off to Full (strict)
Scroll the table
| Mode | Between Cloudflare and the origin | Verdict for a client site |
|---|---|---|
| Off | Everything travels as plain HTTP, on both legs. | Rule it out. |
| Flexible | The visitor can use HTTPS; the leg from Cloudflare to the origin is not encrypted. | Temporary workaround. A loop is guaranteed if the origin redirects to HTTPS. |
| Full | HTTPS to the origin, without validating the certificate: a self-signed or invalid certificate is accepted. | Transition step while you fix the certificate. |
| Full (strict) | HTTPS with validation of the origin certificate (public authority or Origin CA). | Standard target for all your sites. |
| Automatic SSL/TLS | The recommender picks the most secure mode the origin supports, and never a less secure one. | Default setting: still set the mode explicitly so you know what applies. |
Order of operations with no downtime
Check the origin certificate
From your workstation, query the origin directly with its address (IP_ORIGINE is a placeholder to replace):
openssl s_client -connect IP_ORIGINE:443 -servername example.com </dev/null | openssl x509 -noout -subject -datesThe subject must carry the site name and the dates must bracket today. Complete it with
curl -sI --resolve example.com:443:IP_ORIGINE https://example.com/: a valid HTTP response proves the certificate is accepted.List the origin's redirects
Test the origin's port 80:
curl -sI --resolve example.com:80:IP_ORIGINE http://example.com/. If the response contains a Location header pointing to https://, the origin redirects everything to HTTPS. This is the cause of the loop in Flexible mode, and it is not a defect: it is a sound origin setting.Keep the record on DNS only
As long as the two previous checks are not green, the proxy stays off on the record. Traffic goes straight to the origin, as before.
Switch the SSL/TLS mode to Full (strict)
In the zone dashboard, open SSL/TLS, Overview, then choose the custom Full (strict) mode. While the record is not proxied, nothing changes for the visitor.
Turn the proxy on last
Switch the site's A, AAAA or CNAME record to proxied. The procedure, record by record, is described in Turn the Cloudflare proxy on or off for a DNS record.
Enforce HTTPS at the edge
Once in Full (strict), enable "Always Use HTTPS" or a redirect rule on the Cloudflare side, and remove the origin-side redirect where possible: the Cloudflare documentation lists this among the fixes for the loop.
Check the result
Run
curl -sI https://example.com/: you expect a 200 response or the intended redirect, and the server: cloudflare header. Also check that the origin certificate renewal still works behind the proxy: the host documents automatic renewal, not how it behaves behind Cloudflare. Reread the certificate end date with step 1 after the next renewal, and fall back to Full if the certificate expires. Then move on to the cache section before calling the site delivered.
What Cloudflare caches by default, and where the risk appears
Cloudflare decides what to cache from the file extension, not from its MIME type: archives, images, video, fonts, documents, CSS stylesheets and JS scripts are eligible. The documentation states that the CDN does not cache HTML or JSON by default. It adds that it does not keep a response that carries a Set-Cookie header, a response whose Cache-Control is private, no-store, no-cache or max-age=0, or a request that is not a GET. The risk therefore appears the day someone adds a cache rule covering the whole site. That rule makes HTML eligible, and if the origin signals nothing, a cart or account page can end up in the cache.
Paths never to leave in cache on a dynamic site
- Admin and login —
/wp-adminand/wp-login.phpfor WordPress, or the equivalent for your CMS. - Cart and checkout —
/cart,/checkoutand their translated variants on a WooCommerce shop. - Customer account —
/my-accountand any page showing data specific to the visitor. - Session cookies — for example
wordpress_logged_in_orwoocommerce_items_in_cart: a request carrying them must always reach the origin. - Previews — URLs with
?preview=true, which only the logged-in author should see. - Authenticated APIs —
/wp-jsonwhen the response depends on the logged-in user.
Create the bypass rule with Cache Rules
Open Cache Rules
In the zone, open Caching then Cache Rules, and create a rule. Cache Rules require the domain or subdomain record to be proxied.
Write the filter
Choose Edit expression and enter, adapted to your CMS:
(http.request.uri.path contains "/wp-admin") or (http.request.uri.path contains "/wp-login.php") or (http.request.uri.path contains "/cart") or (http.cookie contains "wordpress_logged_in_")Choose Bypass cache
Under "Then", in Cache eligibility, select Bypass cache: matching requests are no longer eligible for caching.
Place and test the rule
Pick its position with "Place at", save, then use Cloudflare's Rules simulator to check that the rule fires on an admin or cart URL.
Checking the cache that is actually applied
A well-written rule proves nothing until you have read the response. The cf-cache-status header tells you what Cloudflare did with each request. For the admin area: curl -sI https://example.com/wp-admin/ | grep -i cf-cache-status. For a page with a simulated login cookie: curl -sI -H "Cookie: wordpress_logged_in_test=1" https://example.com/ | grep -i cf-cache-status. On these two URLs the value must never be HIT. Also test a public page twice in a row, to see a MISS then a HIT if you chose to cache it.
Reading the cf-cache-status values
- HIT — the resource was found in Cloudflare's cache and served from it.
- MISS — the response was eligible but absent from the cache at that moment: the origin served it.
- EXPIRED — a copy existed but it was stale; the origin served a fresh response.
- BYPASS — the request could be cached, but the origin's response turned out not to be cacheable.
- DYNAMIC — Cloudflare decided at request time that the resource is not eligible and queried the origin directly.
- REVALIDATED — the origin confirmed through a conditional request that the cached copy was still valid.
- STALE — an expired copy was served because the origin could not be reached.
Troubleshooting: the errors that keep coming back
Five symptoms cover most client calls after a site is put behind Cloudflare. For each one, the Cloudflare documentation describes the cause; the fix almost always lies at the origin, and so with the host, or in the zone's SSL/TLS mode.
- ERR_TOO_MANY_REDIRECTS (Chrome), "The page isn't redirecting properly" (Firefox) — cause: Flexible mode and an origin that redirects HTTP to HTTPS. Fix: switch to Full or Full (strict), which requires an origin certificate, or remove the origin redirect and enforce HTTPS at the edge. Also check "Always Use HTTPS", HSTS and redirect rules that contradict each other.
- Error 525, SSL handshake failed — the TLS handshake fails while the zone is in Full or Full (strict). Causes listed: no valid certificate installed, port 443 closed, SNI not supported, incompatible cipher suites. Fix: replay step 1 and read the origin's nginx or Apache error log.
- Error 526, invalid SSL certificate — in Full (strict), Cloudflare cannot validate the origin certificate: expired, revoked, wrong name or incomplete chain, since the origin must serve the leaf certificate and the intermediates. Temporary fallback: Full, while you fix it.
- Errors 521 and 522, web server is down and connection timed out — these are not certificate errors: the origin is down or does not answer in time. Check the origin firewall, then give the host the code, the time with its timezone and the affected URL.
- One visitor's cart or account seen by another — a cache rule that is too broad. Disable it, add the bypass rule, purge the cache, then reread cf-cache-status on the sensitive paths.
The rollback, before anyone asks for it
Write down the starting state: SSL/TLS mode, proxied records, existing rules. If the site degrades after the switch, put the record back on DNS only: traffic returns straight to the origin. One trap: a Cloudflare Origin CA certificate is only recognised by Cloudflare, and the documentation warns that when proxying is turned off the visitor sees an untrusted certificate error. So keep a public-authority certificate on the origin.
Who owns what, and where to go next
Once the list is worn in, it fits on one page per site: certificate checked, Full (strict), proxy on, bypass rule tested, cf-cache-status reread. The split stays simple: the agency takes the client's zone and its settings, the host takes the origin. For neighbouring tasks, see Activate managed Cloudflare DNS on a domain, and Migrate a client WordPress site with no downtime if the site changes origin before being placed behind Cloudflare.
