Users are unable to register: the captcha displayed to the user does not match the real captcha. Wordpress

This is probably because the captcha image is cached on the server used by the user. So they always enter the old captcha value. I’m referring to the captcha built into my WordPress website and registration page. I’ve actually created a rule that the registration page shouldn’t be cached, but it still doesn’t work.

What settings need to be applied so that the captcha on the page is always up-to-date for the user?

If this is not possible, are there any settings that will help avoid spam registrations and at the same time allow registering without captcha at all?

Did you try adding disable performance in the page rule? I disable mine for my registration and login.

Yes, thanks for the advice. I have created a rule like this:
Cache Level: Bypass, Disable Performance
Unfortunately, problems with user registration persist.
The Caching Level is Standard. I tried No query string, but the problem was the same.

As for the login, the settings are as follows:
Browser Integrity Check: On, Always Online: Off, Security Level: High, Cache Level: Bypass, Disable Performance
I have no problems with the login. However, if I need to change something on the site, I switch to the developer mode.

Does the problem persist when you set Cloudflare to development mode?

What I would do if I were you:

  1. Put Cloudflare in development mode first to rule that out or in. If it’s ruled out then turn it back on and commit to the rest of the steps.
  2. Download the Health Check & Troubleshooting by
  3. Active that plugin’s troubleshooting feature.
  4. Leave that plugin for the captcha turned on as well as anything else you use for the registration.

It will deactivate all of your plugins and change your theme only for you and not any of your users, so they will not be affected. You can enable plugins and themes one by one until you find the culprit if it’s not a Cloudflare issue.

It seems to be a Cloudflare problem. I’ve described the situation to my hosting provider, so far, they haven’t found anything that might have affected it.

Usually, the Purge Everything button solves this problem.

However, if many users come to some network node, they encounter a cached version of the captcha. Therefore, despite the created rule I mentioned above, the cache update for some users doesn’t happen.

This is my version, but I’m not an expert.
Thanks for the advice; I will try the procedure you suggested.

Regarding the effect of development mode, I can’t answer definitively. I don’t remember the problem appearing during this mode.

I meant to say that you should put cloudflare in development mode first to rule out if it’s cloudflare or not but it sounds like a strong possibility. If it is cloudflare then one of the MVPs can help more than I can or you could contact cloudflare support directly.

If it still isnt working I’d commit to that plugin to find a culprit within your WordPress setup but you don’t need cloudflare in development mode for that process.

Apologies I couldnt be more of help.

1 Like

Request for @MoreHelp according to
3. If you don’t receive a reply within 72 hours or if the replies do not answer your question, reply to your own Community post with your ticket number and at mention @MoreHelp to bring your post to our attention.

Ticket #2208958 (Cloudflare Help Center)

Can you share the domain name and the steps to reproduce the error?

Yes, of course. The domain is

An error occurs when a person wants to register on a website. Goes to the page and fills in the form, including a captcha.
After clicking on the registration button, it appears that the captcha value does not match.

There is also a problem that may be of the same nature. Users who have registered on the site are sometimes unable to access the lessons they have purchased. Even though they are logged in to the site, they get the content displayed as if they were unlogged visitors. This is where the Purge Everything feature usually helps.

When I was using the caching plugin, there was no such problem, as I set the setting not to cache content for logged in users.

In case this had to be done, I mention @MoreHelp and ticket #2208958 as well.
The problem remains. We have to respond to requests from users who cannot register. There are about 80% of them. So we launch the purge cache and register them manually.

Can you tell me whether to expect a solution to the problem? Can it be solved?

I am escalating this for my colleagues to review as I cannot reproduce the error

[quote=“, post:3, topic:286911”]
cannot reproduce the error[/quote]

It is unlikely that you will reproduce this error. My understanding is that this happens on highly visited nodes on a network whose server caches some of the information from the page, including the captcha image. Isn’t there a setting that prevents this from happening? Here is my rule for this page:
Cache Level: Bypass, Disable Performance
The Caching Level is Standard.

Isn’t this enough to work correctly?

I am seeing a cf-cache-status: HIT on the capture image which is


Did you try writing the page rule to bypass that directory or file rather than the /register/ directory?
It doesn’t matter where the html is, the caching is done for the individual paths to the resource.

  • Scott
1 Like

Thank you, I have made the changes you suggested and will see how it affects the registration process. If it solves the problem, I’ll make a note of the solution.

I also mentioned the issue with access to purchased lessons for users who are logged in.

Can you give any advice on this? I need to create something like “don’t cache content for logged in users”.

It sounds like you are looking for something like the ‘Bypass Cache on Cookie’ feature which is available on Business and Enterprise plans.

You could also look at doing something similar using Workers, but that would require custom code.

This is why it’s not recommended for most users to use Cache Everything on dynamic sites, unless you really know what you’re doing.

1 Like

It looks like they’re using APO, but with a cookie that’s not supported. If there’s enough demand for that particular cookie, @yevgen might be able to add it, but I believe custom cookies is on the roadmap for APO.


I believe you are right, and the error lies somewhere in these settings. I got them from some article that seemed convincing.

Which setting would be better for an issue with logged in users? Or is it better to disable caching of the whole site at all?

Turn that Page Rule off. That should help.

1 Like

It looks like you’re right. Thanks.
But that would completely eliminate caching, and I’d like to somehow not lose too much in site speed.
Or does that mean I have to switch to a higher plan?