Your browser does not appear to have javascript enabled. This page needs JavaScript activated to work properly. Please enable javascript or choose a different browser (Chrome or Safari)

Cloudflare Verification — Help for Schools

Please pass this page to your IT team. The steps below require changes to your school’s web filtering or firewall settings and cannot normally be carried out by a student or teacher.

Why does eRevision use Cloudflare?

eRevision uses Cloudflare to protect the site from malicious traffic, bots, and denial-of-service attacks. Cloudflare is one of the world’s largest and most trusted internet security and performance companies, used by millions of websites globally — including major banks, government services, and leading educational platforms. Occasionally Cloudflare will show a “Verifying your browser” or “Just a moment” screen before allowing access. For most users on a home or mobile network this happens at most once and is quick — Cloudflare stores a short-lived cookie (cf_clearance) that proves the verification was passed.

Why does the verification screen keep repeating at school?

If pupils at your school are repeatedly shown the Cloudflare verification screen — completing it, only to be shown it again — this is almost always caused by your school’s web-filtering software performing SSL inspection (also called HTTPS inspection or TLS interception).

Many schools use products such as Securly, Cisco Umbrella, Zscaler, or similar, which decrypt and re-encrypt HTTPS traffic to scan its contents. This is called a Man-in-the-Middle (MITM) arrangement. When this is active, Cloudflare cannot recognise the pupil’s browser, and the verification loop occurs for the following reasons:

Mechanism Cloudflare relies on	What SSL inspection does	Result
TLS/JA3–JA4 fingerprint	The filter terminates your pupils’ TLS connections and opens new ones with its own identity	Cloudflare sees an unrecognised fingerprint on every request → re-challenges
Private Access Tokens (PATs)	PATs require an unbroken TLS path to Apple/Google attesters; MITM proxies cannot relay them	The token silently fails; Cloudflare cannot verify the browser is legitimate
`cf_clearance` cookie	The filter’s redirect chain (e.g. `?scrlybrkr=…`) causes the cookie to be absent or invalid on the next request	Cloudflare sees no proof of prior verification → re-issues the challenge → loop

How to fix it — steps for your IT team

The primary solution is to tell your web filtering software to stop decrypting (intercepting) HTTPS traffic to eRevision. This is different from simply “allowing” the site — the site must be on a bypass or “Do Not Decrypt” list, not just an allow list. Some filtering systems may also require the domains to be added to a standard Allow List (sometimes called a Whitelist or Permitted Sites list) to ensure traffic is passed through without being blocked or redirected. We recommend doing both.

Step 1 — Add these ZigZag Education and Cloudflare related domains to your Allow List

Add the following domains to your filter’s Allow List (sometimes called a Whitelist, Permitted Sites list, or Safe Sites list). This tells the filter to pass traffic to these sites without blocking or redirecting it:

erevision.uk
zigzageducation.co.uk
zzed.uk
publishmenow.co.uk
challenges.cloudflare.com

Step 2 — Add the domains to the SSL Inspection Bypass list

This is the most important step. Add the same domains above to your filter’s SSL Inspection Bypass list (sometimes labelled “Do Not Decrypt”, “HTTPS bypass”, or “Certificate inspection exclusions”). This stops the filter from acting as a man-in-the-middle for these sites, which is the root cause of the Cloudflare verification loop.

If you use Securly

Based on our research, the method in Securly is:

Open the Securly Policy Editor.
Go to your school’s policy and find the Global Allow List (or “Bypass List”).
Add all the domains listed above as high-priority entries. According to Securly’s documentation, entries on the Global Allow List bypass the proxy entirely, which stops SSL inspection for those domains.
Save and apply the policy.

Note: The exact menu names in Securly may differ slightly from the above depending on your version. If you cannot locate the option, contact Securly support and ask them to add the domains above to the SSL inspection bypass / Do Not Decrypt list.

If you use a different filtering product

The SSL bypass option is commonly found under names such as:

SSL Inspection Bypass / Exclusions
Do Not Decrypt list
HTTPS Inspection exemptions
Certificate pinning bypass
Transparent proxy exclusions

Ask your filtering vendor to add all the domains listed above to whichever of these lists stops the product from acting as a TLS middleman for those domains.

Step 3 — Verify the fix has worked

After making the change, visit https://www.cloudflare.com/cdn-cgi/trace on a school device. The page will show a short block of text. Look for the ip= line. If the IP address shown is the school’s own public IP (rather than an IP belonging to the filtering provider), the bypass is working correctly.

Then try erevision.uk. If the bypass is in place, the Cloudflare verification screen should appear at most once and not repeat.

Step 4 — If the problem persists

If the bypass has been applied and the loop continues, please collect the following and send them to us via the sign-in page contact link:

A HAR file captured while the loop is occurring (in Chrome/Edge: Developer Tools → Network tab → Export HAR).
A screenshot of the browser’s Console tab at the same time.
The IP address shown at https://www.cloudflare.com/cdn-cgi/trace on a school device.

This will help us investigate whether there is a secondary cause and advise on next steps.

← Back to Sign In