I have been fighting a problem with WordPress. I was writing Posts in the tool and getting an error when I hit Save Draft,
“The response is not a valid JSON response.”
The issue is to do with the way NearlyFreeSpeech.net uses FastCGI and it breaks WordPress JSON queries.
To diagnose if you have this problem open your browser’s Developer Tools, head to the Network tab, and inspect the failed /wp-json/wp/v2/posts/... request, you discover something bizarre. The server didn’t throw a 404 Not Found or a 500 Internal Server Error. Instead, it returned a 200 OK status code, but the response payload is the complete HTML of your site’s homepage.
Because the block editor expects a clean JSON object back from the WordPress REST API, feeding it the raw HTML of your homepage causes it to panic.
If you are running your site behind Cloudflare and hosting on a unique FastCGI/Proxy environment (like NearlyFreeSpeech), here is exactly why this happens and how to fix it.
The Diagnostic Journey: Ruling Out the Usual Suspects
When this error pops up, standard WordPress troubleshooting advice will tell you to deactivate your plugins, check your .htaccess rules, or flush your Cloudflare cache.
While those are great starting points, you can quickly isolate the root cause with two diagnostic tests.
Test 1: Check the Cloudflare Headers
Open your browser DevTools, click the failed network request, and look at the response headers. If you see cf-cache-status: DYNAMIC, Cloudflare isn’t serving a cached page—it is passing the request straight through to your origin server. Cloudflare is innocent.
Test 2: The Raw REST API Test
WordPress has a fallback query parameter for environments where URL rewriting breaks. Paste this URL into your browser (replacing your domain):
[https://yourdomain.com/?rest_route=/](https://yourdomain.com/?rest_route=/)
- If it loads your homepage: Your WordPress installation or a plugin is actively broken.
- If it returns a massive wall of raw text (JSON): Your REST API works perfectly, but your server is failing to route the “pretty”
/wp-json/URLs correctly.
The Root Cause: FastCGI Clobbering the Request URI
If Test 2 successfully returned JSON data, your database, permalink settings, and .htaccess file are likely pristine. The breakdown is happening at the server architecture level.
Environments like NearlyFreeSpeech use a highly secure, high-performance combination of front-end reverse proxies and back-end FastCGI PHP processes. When you request a pretty URL like /wp-json/, Apache processes your .htaccess file and routes it internally to index.php.
However, during this handshake, the FastCGI environment variables can get clobbered. Specifically, $_SERVER['REQUEST_URI'] gets overwritten and reset to just /index.php.
By the time the request hits WordPress, the core application looks at the environment variables and thinks, “Ah, the user is just requesting the root index file. Let me serve them the homepage template.” Because it assumes you’re just browsing the site, it throws a standard 200 OK and renders your homepage, leaving the block editor completely stranded.
The Solution: The wp-config.php Environment Patch
To fix this, we need to instruct WordPress to check alternative environment variables where the server secretly backs up the original URL path before it gets stripped by FastCGI.
- Connect to your server via SSH or SFTP.
- Open your
wp-config.phpfile located in your root directory. - Scroll down right before the line that reads:
/* That's all, stop editing! Happy publishing. */ - Paste the following environment normalization snippet:
PHP
/**
* Advanced Environment Normalization for CGI/FastCGI Rewriting
* Fixes pretty permalinks & REST API routing behind Cloudflare + Proxies
*/
if (empty($_SERVER['REQUEST_URI']) || $_SERVER['REQUEST_URI'] === '/index.php') {
if (!empty($_SERVER['REDIRECT_URL'])) {
$_SERVER['REQUEST_URI'] = $_SERVER['REDIRECT_URL'];
if (!empty($_SERVER['REDIRECT_QUERY_STRING'])) {
$_SERVER['REQUEST_URI'] .= '?' . $_SERVER['REDIRECT_QUERY_STRING'];
}
}
}
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
What this code does:
- Restores the URI: It checks if
REQUEST_URIhas been reduced to just/index.php. If it has, it grabs the original, intended path fromREDIRECT_URLand hooks the query strings back onto it. - Fixes the SSL Handshake: The second block ensures that WordPress recognizes the request as securely encrypted over HTTPS via Cloudflare’s forwarding headers, preventing an internal HTTP/HTTPS mismatch.
Save the file, refresh your WordPress editor, and try saving your draft again. The block editor will now seamlessly communicate with the REST API, and your “Not a valid JSON response” errors will be gone for good.
This is probably not the best long-term fix so I will update if I find a better solution.
