Skip to content
CheckView
Get Started
Browse documentation

How to Whitelist CheckView’s IPs on Rocket.net Hosting

Updated 2026-07-29

If your website is hosted on Rocket.net and your CheckView form or WooCommerce tests keep failing at the submission step, the most common cause is Rocket.net’s server-level firewall (ModSecurity) blocking CheckView’s test traffic before it reaches your form. This guide explains how to recognize it and how to resolve it.

Symptoms: what you’ll see

The page itself loads normally, but the test fails at (or just after) the form submission. Depending on your test flow, the error usually reads as one of the following:

  • “The submission was not found in the database”

  • “The test inbox did not receive emails within the time limit”

  • The browser did not reach the confirmation / thank-you page after submitting

A key tell-tale sign is that the failure is often intermittent: an on-demand (manual) test may pass, while your scheduled tests fail. This is because the firewall’s decision can depend on recent traffic and IP reputation at the moment of the request, so the same test can pass at one time and be blocked at another. If an on-demand test passes but your scheduled tests keep failing, that is a strong indicator of a host firewall block rather than a problem with your form.

Why this happens

Rocket.net runs a server-level Web Application Firewall (ModSecurity) that inspects incoming requests and can flag CheckView’s shared testing IP addresses as suspicious. When that happens, the form submission (a POST request) is blocked at the server — commonly returned as a 403 Forbidden, or redirected to a /403.shtml page — before it ever reaches your form. As a result, no entry is saved and no notification email is sent, which is why the test reports the submission or email as missing.

Important — the firewall is applied per server. Rocket.net configures ModSecurity on a per-server basis, so whitelisting CheckView on one site does not automatically cover your other sites. If you run several sites with Rocket.net, each server that hosts them needs CheckView’s IPs whitelisted. It is common to see some of your sites passing while others fail, even in the same test run, purely because they sit on different servers.

How to fix it: ask Rocket.net to whitelist CheckView

Rocket.net’s support team can whitelist CheckView’s testing IPs in ModSecurity. Open a support ticket (via chat or your Rocket.net dashboard) and request the following:

  • Ask them to whitelist CheckView’s testing IP addresses in ModSecurity / the server firewall.

  • Provide the current CheckView IP list: https://checkview.io/test-ips/

  • If you have more than one site, list every domain so they can apply the whitelist to each server that hosts them.

  • Once they confirm, re-run your test. For intermittent cases, let a scheduled run complete — that is the true confirmation.

Message you can send to Rocket.net support

Hi,

I use a form-monitoring service called CheckView to test my website's forms.
Its test submissions are being blocked by the server firewall (ModSecurity) -
the form submission is blocked before it reaches my form (returning a 403, or
redirected to a 403 page).

Could you please whitelist CheckView's testing IP addresses in ModSecurity for
the server(s) hosting the following site(s):

  - example.com
  - (list any additional domains here)

The current IP list is here: https://checkview.io/test-ips/

Note: since ModSecurity is configured per server, please apply the whitelist to
every server that hosts my sites, not just one.

Thank you!

Confirming the fix

After Rocket.net confirms the whitelist, re-run the affected test. If your failures were intermittent (manual passing, scheduled failing), the most reliable confirmation is a successful scheduled run, since it reproduces the conditions that triggered the block. Once a scheduled run passes cleanly, you’re all set.