Issue with Aruba hosting

Hi, thanks for the detailed report — that really helps narrow it down.

This is almost certainly caused by a change in 5.0: since then, each invisible puzzle is cryptographically bound to the visitor’s IP, and forwarded headers (X-Forwarded-For) are only trusted if the connecting IP is listed as a trusted proxy. On a load-balanced host like Aruba, the plugin sees Aruba’s internal proxy IP as the connection address instead of the real visitor IP — and if that proxy IP changes between the puzzle request and the form submit, verification fails and everything is flagged as spam. 4.x didn’t do this binding, which is why the rollback fixes it.

One quick test to confirm it (incognito, DevTools → Network tab open, then submit a Forminator form):

Is there a get_stamp request that returns clean JSON (not HTML / not a PHP notice)?
Is there a check_stamp POST that returns {“accepted”:true}?
If both succeed but the form is still marked spam → it’s the IP/proxy issue below.
If either one returns HTML or an error (e.g. 403) → your host’s security layer (mod_security/WAF) is likely blocking admin-ajax.php; let me know and we’ll go from there.
The fix for the IP/proxy case:

Go to the plugin settings and find the “Trusted proxies” option, then enter Aruba’s proxy address/range.

To find the value, drop a tiny file whatismyip.php in your web root with:

Open it in the browser. If the IP shown there is not your own public IP (i.e. it’s an internal/proxy address), that’s the one to trust — enter it in “Trusted proxies” (a whole subnet like 10.0.0.0/8 is fine if it varies). Delete the file afterwards. Once that’s set, the plugin will use the real visitor IP again and submissions should stop being flagged.

If you’d rather not test yourself, you can also just try setting “Trusted proxies” first and re-test — it’s a safe change.

Thanks again for reporting this so precisely — please let me know what the Network tab shows, that pins it down completely.

Thanks for the update, and sorry for the trouble. You don’t need the network tab or any developer knowledge for this — please forget that step. There are three small things I need instead, and they can all be read off the screen.

1) The exact version number

Please open Plugins -> Installed Plugins and copy the version shown for the plugin. There is no 5.5.1 — the latest released version is 5.2.1, so something else must be installed. This matters: the bug where a Difficulty value above 20 turned every submission into spam was fixed in 5.2.1, and the diagnostic label in step 3 only exists from 5.2.0 on. If you are on an older 5.x, please update to 5.2.1 first.

2) Please don’t stay on 4.x

The 4.x branch is missing the security fixes released in 5.1.1. Instead of downgrading, keep 5.2.1 installed and go to the plugin settings, section “Spam Processing”, and turn OFF the option “Block spam”.

With that setting off, messages are still checked and still logged in the Spam folder with a reason, but they are no longer blocked — so no real sender loses a message while we diagnose. Note: if “Flag spam” is on, delivered messages will carry a marker in the text.

3) The “Blocked because:” line

After that, send one test submission through your form.

Then open the “Spam” menu, open that message, and copy the line at the very top that starts with “Blocked because:”.

Possible values are: No proof of work / Gibberish content / Known spam value / Blocked value pattern / Simulation mode / Under-attack quarantine. That single line tells me which family of causes we are dealing with.

4) Two small extra details

What number is set in the “Difficulty” field in the settings?

Is the site behind Cloudflare, a CDN or a reverse proxy? If yes, that proxy’s address has to be entered under “Trusted proxies” in the settings — otherwise the IP-bound check fails permanently, which is a known way a site that worked on 4.x can end up marking everything as spam on 5.x.

With the exact version, the “Blocked because:” text, the Difficulty number and the proxy answer, I can tell you which of the causes applies and what to change. Thanks for your patience.

One more question:
Can you navigate to a submission form, press f12 (code inspector), navigate to console and than submit the form.

Do you see any console errors here, or after submission? As they may stop the PoW-algh to work the stamp. I wonder whether some incompatibility was introduced with the release.

Thanks for checking the console — that is a useful result. If the puzzle script had crashed in the browser, we would normally see a warning there, so the client side appears to be doing its job and the mismatch most likely happens later, when the submission is checked on the server. That is still a working assumption, not a conclusion.

In the meantime 5.3.0 has been released, and it contains fixes for exactly that class of problem, i.e. valid submissions being flagged as spam without any visible error:

The request that fetches the puzzle is no longer served from a page or CDN cache, which previously could make every submission look like spam.

A cache, a proxy pool or an IPv4/IPv6 dual stack no longer causes every submission to be flagged; the puzzles no longer depend on the visitor address. This can matter even without Cloudflare, since hosting stacks often have their own caching and proxy layers.

Blocked messages now name the actual cause instead of only the kind of block.

So please do the following:

1) Update the plugin to 5.3.0.

2) Clear any page cache on the site, and any caching layer your host offers.

3) If your hosting panel has a “flush OPcache” button (or an option to restart PHP), please use it once after the update. Otherwise an old copy of the code can stay active in memory.

4) Turn spam blocking back on and send a test submission.

I cannot say from here whether your case was caused by one of the issues above — that depends on your site, and only a test will show it. If submissions are still blocked after the update, please post the exact new wording of the blocked message. From 5.3.0 on it names the concrete reason, and that tells us which step fails instead of leaving us guessing.

A difficulty of 16 is fine and not the problem, so there is no need to change that value.

Sorry for the extra round trips, and thanks for your patience with the testing.