If the WordPress block editor fails to save with a vague "the response is not a valid JSON response" error, or an app/plugin that talks to your site over its API suddenly stops working, aaPanel's own firewall or web application firewall (WAF) blocking requests to /wp-json/* is a real and often-overlooked cause on aaPanel-hosted sites. Checking aaPanel's firewall logs for blocked REST API requests takes a couple of minutes and will confirm or rule this out directly.

Symptoms

  • Gutenberg (the block editor) shows "Updating failed" or "The response is not a valid JSON response" when trying to save or publish a post.
  • The classic editor and normal page loads work fine — only actions that go through WordPress's REST API (/wp-json/...) fail.
  • A mobile app, Jetpack-style connection, or any third-party integration that talks to your site via its API stops authenticating or syncing, while the website itself loads normally in a browser.
  • The issue appeared after enabling or tightening aaPanel's firewall/WAF, installing a security plugin at the same time, or moving the site to a server with aaPanel's firewall freshly configured.
  • Visiting yourdomain.com/wp-json/ directly in a browser returns a blocked/forbidden response instead of JSON output.

Likely causes, in order of how often they actually happen

  1. aaPanel's built-in firewall or WAF has a rule that generically matches REST API request patterns. Default rule sets aimed at blocking common attack patterns (unusual query strings, POST requests to non-standard paths, or requests with certain header/user-agent combinations) can catch legitimate /wp-json/* traffic as a false positive, because REST API calls look structurally similar to some attack probes the rules are designed to catch.
  2. A CC (anti-CC/rate-limiting) rule is throttling rapid REST API calls. The block editor and some plugins make several REST requests in quick succession while you're actively editing — if aaPanel's anti-CC (frequency-limiting) protection is set aggressively, it can start blocking a burst of legitimate requests from the same IP.
  3. A separate WordPress security plugin is also blocking or restricting REST API access, and it's easy to mistake this for an aaPanel-level block since the symptom looks identical. Worth ruling out early since the fix is completely different.
  4. The REST API is disabled or restricted at the WordPress level itself (via a setting in a security plugin, or a snippet in functions.php), unrelated to aaPanel's firewall entirely.

Fix it: lowest-risk steps first

Step 1 — Confirm it's actually being blocked, and where

First rule out the WordPress-level cause (#4/#3 above), since it's the quickest to check and doesn't require touching server firewall rules. Temporarily deactivate any WordPress security plugin (Wordfence, iThemes/Solid Security, All In One WP Security, etc.) and retest saving a post in Gutenberg. If the error disappears, the block is coming from that plugin's own settings, not aaPanel — check its firewall/API-restriction settings instead of continuing below.

If the error persists with security plugins deactivated, the block is happening before WordPress even sees the request — at the server/panel level. Confirm this directly: in aaPanel, go to Security (the firewall section in the left sidebar) and look for a Logs tab. Filter or scan for recent entries around the time you triggered the failed save, and look for blocked requests whose path contains /wp-json/. Finding one confirms aaPanel's firewall is the cause.

Step 2 — Check the anti-CC (rate-limiting) rule first

Rate-limiting is the lower-risk cause to fix, since it usually just needs a threshold adjustment rather than disabling a security rule outright. In aaPanel's Security section, find the CC or anti-CC protection tab (labeled as flood/frequency protection in some aaPanel versions). If it's enabled with a low request-count threshold, raise the allowed requests-per-time-window for this site, or add an exception, rather than disabling it site-wide — the block editor's autosave behavior alone can generate enough requests in a short window to trip an aggressive default.

Step 3 — Check the WAF rule set for a REST API false positive

If Step 1's logs show a block from the WAF/firewall rules specifically (not CC/rate-limiting), go to aaPanel's Security → Website Firewall (or WAF, depending on your aaPanel version and whether the free or Pro firewall module is installed) and open the rule log for the specific rule ID that triggered. aaPanel typically shows which rule category matched (for example, a rule aimed at blocking suspicious query parameters or unusual POST bodies).

Rather than disabling the WAF entirely, add a targeted exception for the /wp-json/ path on this specific site, or exclude the specific rule ID that's matching if aaPanel's interface allows per-rule exceptions. This keeps the rest of the firewall's protection intact while letting legitimate REST API traffic through. If your aaPanel installation only offers an all-or-nothing toggle for the WAF module (no granular per-path exception), temporarily disabling it just for this site while you confirm the diagnosis is reasonable — re-enable it once you've set up either a path exception or a more specific rule.

Step 4 — Whitelist your own IP if you're testing from a fixed location

If the block only happens from your own IP (for example, other editors on different networks aren't affected), aaPanel's Security → IP whitelist (or a similar allow-list option in the same section) lets you add your IP so it bypasses both the WAF and anti-CC rules. This is useful for confirming the diagnosis quickly, but isn't a real fix if other legitimate users or integrations from other IPs are also affected — treat it as a diagnostic step, then go back to Steps 2–3 for a fix that covers everyone.

Verify the fix

  1. In wp-admin, create or edit a post in the block editor and confirm it saves and publishes without the "not a valid JSON response" error.
  2. Visit yourdomain.com/wp-json/wp/v2/posts directly in a browser and confirm it returns JSON data rather than a blocked page.
  3. If a specific app/plugin integration was affected, reconnect or resync it and confirm normal operation over a few minutes, not just the first request.
  4. Recheck aaPanel's firewall logs under Security → Logs to confirm /wp-json/ requests are no longer appearing as blocked.

If you need to roll back

If adding a path exception or excluding a rule ID in Step 3 doesn't resolve it, or you're not confident about which rule to adjust, restore the WAF rule set to its previous state (aaPanel keeps the rule configuration you had before your edit) and instead use the IP whitelist from Step 4 as a temporary workaround while you investigate further or consult aaPanel's community forum with your specific rule ID and log entry — this keeps the firewall fully protective for everyone except the address you've explicitly trusted.

Related fixes

FAQ

Why would a firewall block requests to my own site's REST API?

Firewall and WAF rules are pattern-based, not aware of what "legitimate WordPress traffic" looks like specifically — they're built to catch common attack signatures across many types of websites, not just WordPress. A REST API request with certain query parameters or a rapid sequence of POST requests can structurally resemble patterns the rules are designed to flag, even though in your case it's just the block editor autosaving.

Is disabling aaPanel's firewall entirely a reasonable fix?

No — treat that as a last-resort diagnostic step only, and re-enable it immediately after confirming the cause. The firewall/WAF protects the whole server, not just this one site, so leaving it off exposes you to real risk far beyond the inconvenience you're trying to fix. A targeted path exception or rate-limit adjustment is almost always available instead.

Could this be a hosting-level firewall separate from aaPanel, like a cloud provider's security group?

Yes — if you're on a VPS from a provider that also offers its own network firewall (a security group, cloud firewall, or similar) in addition to aaPanel's own firewall, check that layer too if aaPanel's logs show nothing blocked. The symptom looks identical either way, but the fix location is different — aaPanel's panel only controls what's configured inside aaPanel itself.