Если после включения кэширования у вас внезапно начали падать запросы к /wp-json/ с 404, проблема обычно не в самом REST API, а в том, как сервер, плагин кэша или правила перезаписи обрабатывают «красивые» URL. На практике это всплывает после переноса сайта на VDS, смены nginx-конфига, включения page cache или агрессивной оптимизации через плагин.
Сценарий типичный: админка открывается, фронтенд работает, но блоки редактора, формы, интеграции с внешними сервисами или мобильное приложение начинают получать пустой ответ, редирект или 404 на адресах вида /wp-json/wp/v2/posts. Ниже — как быстро локализовать причину и исправить её без лишнего отключения кэша.
Как понять, что ломается именно REST API, а не весь сайт
Сначала проверьте, что ошибка действительно связана с wp-json. Откройте в браузере или через curl базовый endpoint:
curl -I https://example.com/wp-json/Нормальный ответ — 200 или 301/302 с последующим переходом на рабочий JSON-ответ. Если вы видите 404, 403 или редирект на главную, значит запрос не доходит до WordPress как до приложения.
Полезно сравнить несколько запросов:
curl -I https://example.com/wp-json/wp/v2/types/post
curl -I https://example.com/?rest_route=/wp/v2/types/postЕсли вариант с ?rest_route= работает, а красивый URL нет, почти наверняка проблема в rewrite-правилах, nginx/apache-конфиге или в кэше, который перехватывает запрос раньше WordPress.
Что смотреть в логах
На VDS и выделенных серверах не полагайтесь только на браузер. Проверьте:
- access log веб-сервера — есть ли запрос на
/wp-json/и какой код ответа возвращается; - error log PHP-FPM и веб-сервера — нет ли ошибок переписывания или ограничений доступа;
- логи плагина кэша — некоторые плагины умеют исключать REST API, но не всегда делают это корректно после обновления.
Почему кэш ломает wp-json: основные причины
Чаще всего встречаются три сценария. Первый — кэширование HTML-страниц по слишком широкому правилу, когда под раздачу попадает и /wp-json/. Второй — неверные правила try_files или location в nginx, из-за которых запрос уходит не в index.php, а в статическую обработку. Третий — плагин безопасности или оптимизации, который блокирует REST API целиком или для части маршрутов.
Если сайт работает на WordPress с WooCommerce, проблема заметнее: корзина, checkout, автосохранение в редакторе и некоторые интеграции используют REST-запросы постоянно. Поэтому «починить потом» обычно означает получить побочные ошибки в самых неудобных местах.
| Подход | Что делает | Плюс | Минус |
|---|---|---|---|
| Плагин кэша | Исключает REST API из page cache | Быстро внедрить | Не всегда решает серверный rewrite |
| Правка nginx/apache | Передаёт /wp-json/ в WordPress | Решает корень проблемы | Нужен доступ к конфигу |
| Код в теме/плагине | Проверяет и отключает конфликтующие фильтры | Точечно и прозрачно | Не исправит ошибку веб-сервера |
Пошаговое решение
1. Исключите wp-json из кэша на уровне плагина
Если используете плагин page cache, найдите настройки исключений. Обычно нужно добавить пути, связанные с REST API, в список не кэшируемых URL. Ищите поля вроде Never cache the following pages, Exclude URLs или Do not cache REST requests.
Если плагин поддерживает регулярные выражения, не делайте исключение слишком широким. Достаточно исключить именно REST-путь, а не весь сайт с параметром wp-json в любом месте.
2. Проверьте nginx-конфиг
На VDS с nginx типичная ошибка — отсутствие корректной обработки «красивых» URL. Для WordPress базовый блок обычно выглядит так:
location / {
try_files $uri $uri/ /index.php?$args;
}Если у вас есть отдельные правила для статики, CDN или кэша, убедитесь, что /wp-json/ не перехватывается раньше этого блока. Иногда помогает явное исключение:
location ^~ /wp-json/ {
try_files $uri $uri/ /index.php?$args;
}Это не универсальный рецепт для всех конфигураций, но в реальных установках он часто возвращает REST API в рабочее состояние, если проблема была именно в маршрутизации.
3. Пересохраните постоянные ссылки
После переноса сайта или изменения структуры URL WordPress может не обновить rewrite-правила автоматически. Зайдите в Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок. Это принудительно обновит правила маршрутизации.
Если у вас есть доступ к WP-CLI, можно сделать это без входа в админку:
wp rewrite flush --hardКоманда полезна после миграции, но не запускайте её регулярно на боевом сайте без необходимости: это операция для разовой починки, а не для cron-задачи.
4. Проверьте, не блокирует ли REST API плагин безопасности
Некоторые плагины умеют отключать REST API для неавторизованных пользователей или для всех, кроме админов. Это может быть оправдано на закрытом сайте, но на публичном проекте ломает интеграции и фронтенд-функции. Временно отключите такой плагин и повторите запрос к /wp-json/. Если ошибка исчезла, ищите конкретную настройку блокировки, а не держите плагин выключенным.
5. Если нужен точечный обход, проверьте ответ через код
Иногда полезно убедиться, что WordPress вообще видит REST-запрос. Для диагностики можно добавить временный сниппет в mu-plugin или в functions.php дочерней темы:
add_action('rest_api_init', function () {
error_log('REST API initialized: ' . home_url('/wp-json/'));
});Это не лечит проблему, но помогает понять, доходит ли выполнение до WordPress. Если лог не появляется, значит запрос режется раньше — на уровне сервера, CDN или кэширующего слоя.
Как проверить, что решение сработало
После правок проверьте не только главную страницу, но и конкретные REST-эндпоинты. Минимальный набор проверок такой:
https://site.ru/wp-json/возвращает JSON, а не 404;https://site.ru/wp-json/wp/v2/postsотвечает списком записей или пустым массивом, но не ошибкой маршрутизации;- в редакторе Gutenberg не появляются ошибки загрузки блоков;
- WooCommerce-страницы, если они есть, не теряют поведение корзины и checkout;
- в логах сервера больше нет повторяющихся 404 на
/wp-json/.
Если после исправления nginx-конфига всё ещё видите 404, очистите кэш плагина, серверный кэш и, если используется CDN, purge для соответствующего домена. Иногда старое правило живёт именно там.
Частые ошибки и как их исправить
Слишком широкое исключение из кэша
Ошибка выглядит безобидно: «исключим всё, где есть json». На практике это может выключить кэш для лишних URL и не решить проблему с маршрутизацией. Исключайте только /wp-json/ и связанные REST-пути.
Редирект на главную вместо 404
Такое часто делает не WordPress, а CDN, security-плагин или правило в nginx. Если запрос на /wp-json/ уходит на главную, проверьте редиректы в .htaccess, конфиге nginx и настройках плагина, который «скрывает» технические URL.
Сломали REST API ради безопасности
Полное отключение REST API через код или плагин — плохая идея для большинства сайтов. Это может сломать редактор, мобильные приложения, интеграции и часть плагинов. Если нужно ограничить доступ, делайте это точечно: по ролям, по конкретным endpoint’ам или по IP, а не рубите всё подряд.
Не обновили правила после миграции
После переноса сайта на новый сервер или домен старые rewrite-правила могут остаться в базе. В таких случаях помогает повторное сохранение постоянных ссылок и проверка конфигурации веб-сервера. Если сайт переносили вручную, не забывайте о правах на .htaccess и о том, что nginx не читает его вообще.
Практические советы по безопасности и производительности
Если вы настраиваете кэш на боевом сайте, не пытайтесь «лечить» REST API отключением всего кэширования. Лучше разделить слои:
- page cache — для обычных HTML-страниц;
- object cache — для запросов к базе и повторяющихся вычислений;
- исключения — для
/wp-json/, корзины, checkout и личных кабинетов; - серверные правила — отдельно для nginx/apache и отдельно для CDN.
На хостинге с управляемым стеком полезно сначала проверить, не включён ли у провайдера дополнительный кэш на уровне Nginx FastCGI cache или reverse proxy. Если да, исключение REST API нужно делать и там тоже. Иначе плагин кэша будет настроен правильно, а 404 останется на серверном слое.
Если вы используете WP-CLI и часто меняете конфигурацию, держите под рукой проверку маршрута:
wp eval 'echo wp_remote_retrieve_response_code( wp_remote_get( home_url( "/wp-json/" ) ) );'Команда показывает, какой код ответа возвращает сам сайт изнутри. Это удобно, когда внешний браузер может врать из-за CDN или локального кеша.
В ситуациях, где кэш нужен, но REST API должен работать стабильно, имеет смысл рассмотреть плагин, который аккуратно управляет исключениями и дублями. Например, Clearfy Pro уместен там, где нужно убирать лишние дубли и не трогать рабочие системные маршруты: https://wpshop.ru/plugins/clearfy. Но даже с таким инструментом серверный конфиг всё равно нужно проверить вручную.
Главная мысль простая: если wp-json отдаёт 404 после включения кэша, не начинайте с отключения всего подряд. Сначала отделите серверный rewrite от плагина кэша, потом проверьте исключения и только после этого трогайте безопасность и CDN. Так вы быстрее найдёте точку поломки и не потеряете производительность на всём сайте.