The REST API encountered an unexpected result

I always get different errors. This is info from Site Health in WordPress status for all users on HestiaCP. I have only WordPress sites on the production server. These problems occurred with the latest version of HestiaCP v1.9.2 - Ubuntu 22.04 (x86_64) - Apache2 + NGINX + FPM-PHP 8.1. Maybe my firewall settings cause this problems for REST API?

The 403 Forbidden error could be caused by a server firewall or security plugin. I don’t have any security plugin on the sites. How to fix this?

The REST API is one way that WordPress and other applications communicate with the server. For example, the block editor screen relies on the REST API to display and save your posts and pages.
    The REST API is one way that WordPress and other applications communicate with the server. For example, the block editor screen relies on the REST API to display and save your posts and pages.

    When testing the REST API, an unexpected result was returned:
The REST API is one way that WordPress and other applications communicate with the server. For example, the block editor screen relies on the REST API to display and save your posts and pages.

When testing the REST API, an unexpected result was returned:
#### The REST API encountered an unexpected result Performance

The REST API is one way that WordPress and other applications communicate with the server. For example, the block editor screen relies on the REST API to display and save your posts and pages.

When testing the REST API, an unexpected result was returned:

Hi, look somewhere you have an incorrectly configured network, or DNS. Or it blocks, for example, cloudflare/fail2ban

I think this is problem with CloudFlare. How to skip REST API from CF WAF?

Look in the list of locks of the CF logs, it can be seen that and why, then you can apply the rule. I do not see logs, it’s hard to say)

Mhm, look at this URL API; it gives me a 404 error. Is this something to do with the server?

REST API Endpoint: https://www.samponzapse.com/wp-json/wp/v2/types/post?context=edit

This one is from cPanel and there is no error, also that domain are on the cloudflare dns.

REST API Endpoint: https://kesezausisivac.rs/wp-json/wp/v2/types/post?context=edit

Show the logs WAF CF

Here is CF WAF:

https://pastebin.com/eyEYrwSw

Disable WAF, I think it will be easier to understand, and look at the result)
Very similar to the botFight

    "action": "managed_challenge",
    "clientASNDescription": "HETZNER-AS",
    "clientAsn": "24940",
    "clientCountryName": "DE",
    "clientIP": "2a01:4f8:140:146c::2",
    "clientRefererHost": "",
    "clientRequestHTTPHost": "www.samponzapse.com",
    "clientRequestHTTPMethodName": "GET",
    "clientRequestHTTPProtocol": "HTTP/1.1",
    "clientRequestPath": "/wp-json/wp/v2/types/post",
    "clientRequestQuery": "?context=edit",
    "datetime": "2025-02-25T18:05:46Z",
    "ref": "",
    "rayName": "9179a01f1de19b31",
    "ruleId": "bot_fight_mode",
    "rulesetId": "",
    "source": "botFight",
    "userAgent": "WordPress/6.7.2; https://www.samponzapse.com",
    "matchIndex": 0,
    "metadata": [],
    "sampleInterval": 

Cloudflare proxy for A and CNAME for www are temporarily disabled.

And I’m still getting the same error:

https://www.samponzapse.com/wp-json/wp/v2/types/post?context=edit

The idea came, did you change the domain everywhere in the configuration files WP?

Yes, everything is changed in the configuration files for WP.

I also did re-save permalinks.

I would have done so if there is a backup copy of Hestia with all sites, I would raise a new server for example Ubuntu 24, or Debian 12 and launched a backup. If on 1.8.12 everything was fine, I am sure that it would solve the problem

I don’t have too much time for that. Everything worked fine for me on the 1.8.12 version. Now I have problems with 1.9.2.

/var/cache/nginx/samponzapse.com permission is 700, or I need to change to 755?

Sorry, no more ideas, I tested Hestia many times, and encountered errors updating from 1.8.12 to 1.9. The reasons were different, I did as I wrote above, and after that everything was fine. I also used Ubuntu 24(this is now fixed) and got an error changing the language, so I safely returned to Debian, which I’m very happy about)