Довідник помилок / The REST API encountered an error

Помилка The REST API encountered an error

WordPress звертається сам до себе через власний REST API: блоковий редактор через нього зберігає записи, а Інструменти > Стан сайту (Site Health) перевіряють його так, що сервер сам запитує свою ж адресу /wp-json/wp/v2/types/post?context=edit від імені залогіненого адміністратора. Це повідомлення означає, що у відповідь прийшов не звичайний JSON, а 403, 404, 500, тайм-аут або відповідь із зайвим виводом усередині. Бачать його власники сайтів і редактори у Стані сайту, зазвичай разом із «Updating failed. The response is not a valid JSON response.» у редакторі. Майже всі поради в мережі зводяться до «вимикайте плагіни по одному», і цього можна не робити: те, що ваш сайт віддає на зовнішній запит, уже звужує причину до однієї з чотирьох, а перевірка на цій сторінці дає цю відповідь за кілька секунд.

Перевірте свій сайт

>

Через що виникає

Найчастіше запит блокують ще до того, як він дійде до WordPress: плагін безпеки з опцією «вимкнути REST API», правило фаєрвола на хостингу (на shared це зазвичай ModSecurity) або WAF і бот-захист Cloudflare. Далі за поширеністю йдуть зламані правила перезапису, коли сайт працює, а /wp-json/ віддає 404; так буває після переїзду, правок .htaccess або на nginx без потрібного try_files. Фатальна помилка PHP чи вичерпання памʼяті в плагіні, який чіпляється до rest_api_init, дає 500. Найрідший випадок водночас найвпертіший: ззовні API відповідає ідеально, і падає тільки запит сервера до самого себе через локальний DNS, вихідний фаєрвол, HTTP-авторизацію на тестовому сайті або хостинг, який не дозволяє зʼєднання з власною IP-адресою.

Як виправити

  1. Запустіть перевірку на цій сторінці для https://вашсайт.com/wp-json/wp/v2/ і подивіться на код відповіді: 200 означає, що API відповідає зовнішньому світу, 403 - що його щось блокує, 404 - що зник маршрут або правила перезапису, 500 - що PHP падає всередині WordPress. Гляньте також на кінцеву адресу після редиректів і на заголовок Server: несподіваний редирект або значення cloudflare покажуть, хто ще стоїть на шляху запиту.
  2. Перш ніж міняти те, на що вказала перевірка, зробіть повний бекап файлів і бази даних, бо ймовірні виправлення чіпають .htaccess, налаштування плагінів і правила фаєрвола на живому сайті, а ви маєте мати шлях назад.
  3. Якщо отримали 403, запит не дійшов до WordPress: вимкніть опцію «disable REST API» або посилений захист REST у плагіні безпеки (у Wordfence, Solid Security і подібних вона є), попросіть хостинг перевірити лог ModSecurity за вашою IP на хвилину запуску перевірки, а в Cloudflare відкрийте Security > Events, знайдіть правило, яке спрацювало на /wp-json/, і додайте для цього шляху виняток (skip).
  4. Якщо отримали 404, відкрийте адресу в браузері: JSON із rest_no_route означає, що WordPress відповів, а маршрути прибрав плагін чи вставлений сніпет; HTML-сторінка 404 означає, що зламані правила перезапису. У другому випадку зайдіть у Налаштування > Постійні посилання і натисніть «Зберегти», нічого не змінюючи, щоб правила перебудувалися; якщо https://вашсайт.com/?rest_route=/wp/v2/ віддає JSON, а /wp-json/ і далі 404, бракує саме блоку перезапису WordPress у .htaccess або рядка try_files у конфізі nginx.
  5. Відповідь 401 із JSON на кшталт {"code":"rest_not_logged_in"} - це не поломка: API живий і просто просить авторизацію, що нормально для захищених маршрутів, тож шукайте плагін членства, режим обслуговування або парольний захист, який поширив цю вимогу на весь API. А от 500 - справжня поломка всередині PHP: подивіться лог помилок PHP на хостингу, знайдіть фатальну помилку або рядок про вичерпання памʼяті і полагодьте чи вимкніть плагін, який там названий.
  6. Якщо перевірка дала 200, відкрийте ту саму адресу в браузері й подивіться, що йде перед першою фігурною дужкою: попередження PHP, зайвий HTML або порожній рядок через BOM у wp-config.php чи файлі плагіна дають варіант «did not behave correctly», і цей файл треба почистити. Якщо ж JSON чистий, публічний API у порядку і падає лише запит сервера до самого себе: надішліть хостингу точний текст зі Стану сайту, де названо помилку cURL (наприклад «cURL error 28: Operation timed out»), і попросіть підтвердити, що сервер може достукатися до власного домену через HTTPS.

Схожі помилки