numan00

The issue isn’t actually coming from WordPress; it’s coming from your server configuration.

WordPress (specifically the REST API and block editor) uses preflight requests (OPTIONS) as part of modern browser security (CORS). The endpoint you’re seeing:

/wp-json/batch/v1

relies on OPTIONS to validate the request before sending the actual POST. If your server drops OPTIONS (like your nginx rule returning 444), the browser will fail with NS_ERROR_NET_RESET, and WordPress will show “Could not get a valid response from the server.” Why you can’t disable OPTIONS in WordPress

There is no supported way to stop WordPress from sending OPTIONS requests because:

• It’s required by browsers (not WordPress itself)
• It’s part of the REST API spec
• Gutenberg, widgets, and admin AJAX rely on it

Trying to disable it will break core functionality (as you’re already seeing). Recommended Fix (Best Practice)

Instead of blocking OPTIONS globally, allow it only for REST API routes:

location /wp-json/ {
if ($request_method = OPTIONS) {
add_header Access-Control-Allow-Origin “*”;
add_header Access-Control-Allow-Methods “GET, POST, OPTIONS, PUT, DELETE”;
add_header Access-Control-Allow-Headers “Authorization, Content-Type”;
return 204;
}
}

Or modify your global rule:

if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$ ) {
return 444;
} Security Note

Blocking OPTIONS entirely is overly aggressive and breaks legitimate browser behavior. A better approach is:

• Allow OPTIONS
• Restrict origins if needed
• Use rate limiting / WAF for protection

Alternative (Not Recommended)

You could disable the REST API or block /wp-json/, but:

• Widgets editor will break
• Gutenberg will break
• Future updates may fail

So this isn’t a viable production solution. Related Resource

You might find this helpful when dealing with WordPress technical configurations and performance/security setups:
https://gotechanic.com/