cURL Error 28 у WordPress: чому виникає помилка тайм-ауту та як її виправити

cURL Error 28 — одна з найпоширеніших проблем WordPress, пов'язана з тим, що сервер не встигає отримати відповідь на запит HTTP за відведений час.

Найчастіше помилка з'являється у розділі «Інструменти → Здоров'я сайту» та супроводжується повідомленнями:

cURL error 28: Operation timed out

або:

cURL error 28: Connection timed out

Також WordPress може повідомити:

REST API виявив помилку

або:

Ваш сайт не зміг виконати запит loopback.

Здається, що проблема пов'язана безпосередньо з cURL. На практиці причина може бути зовсім в іншому місці: в DNS, SSL, брандмауері, CDN, налаштуваннях PHP, хостингу , плагіні або навіть в неправильній конфігурації самого сервера.

У цій статті розберемо, що означає cURL Error 28, чому WordPress видає цю помилку та як послідовно знайти та усунути її причину.

Коротка відповідь

cURL Error 28 означає, що HTTP-запит WordPress не отримав відповіді протягом встановленого часу очікування.

Щоб виправити помилку, перевірте:

1. REST API та loopback-запити WordPress.
2. Плагіни безпеки та firewall.
3. Усі встановлені плагіни.
4. SSL-сертифікат та HTTPS.
5. DNS та налаштування домену.
6. CDN та Cloudflare.
7. PHP, cURL та OpenSSL на сервері.
8. Ліміти пам'яті та часу виконання PHP.
9. Логи сервера.
10. Налаштування хостингу та блокування вихідних з'єднань.

Якщо помилка зникає після відключення конкретного плагіна або firewall, причина практично точно знаходиться саме там.

Що таке cURL і навіщо він потрібний WordPress

cURL (Client URL) — технологія, що дозволяє програмам встановлювати з'єднання та обмінюватися даними з іншими серверами за різними мережевими протоколами.

WordPress активно використовує HTTP-запити для взаємодії:

• із власним REST API;
• з WordPress.org;
• із зовнішніми API;
• із сервісами оновлень;
• з платіжними системами;
• з CDN;
• із зовнішніми сервісами плагінів;
• під час виконання фонових завдань;
• під час роботи WP-Cron.

WordPress для виконання HTTP-запитів використовується HTTP API, який у відповідних серверних умовах може працювати через розширення cURL. Документація WordPress також показує, що внутрішні перевірки REST API та loopback використовують HTTP-запити.

Тому cURL Error 28 - це не обов'язково "поломка cURL".

Найчастіше це означає:

WordPress відправив запит → сервер або зовнішній сервіс не відповів вчасно → встановлений timeout закінчився → WordPress повернув Error 28.

Як виглядає cURL Error 28 у WordPress

Найчастіше помилку можна побачити тут:

WordPress → Інструменти → Здоров'я сайту → Стан

Наприклад:

The REST API encountered an error.

Error: cURL error 28: Operation timed out after
10001 milliseconds with 0 bytes received
(http_request_failed)

Інший варіант:

The loopback request to your site failed,
this means features relying on them are not currently working as expected.

Error: cURL error 28: Connection timed out
(http_request_failed)

WordPress дійсно перевіряє як доступність API REST, так і можливість виконувати loopback-запити.

Що таке loopback-запит і чому він важливий

Loopback-запит - це запит, який WordPress надсилає самому собі.

Спрощено:

WordPress
↓
HTTP-запрос
↓
собственный домен
↓
WordPress


Такі запити використовуються, наприклад, для:

• запуску запланованих завдань;
• роботи WP-Cron;
• перевірки оновлень;
• деяких операцій з плагінами та темами;
• перевірки коректності роботи REST API;
• виконання фонових процесів

WordPress прямо вказує, що loopback-запити використовуються для запланованих подій та перевірки стабільності коду під час роботи з плагінами та темами.

При цьому важливо розуміти:

Помилка loopback не обов'язково означає, що сайт недоступний для відвідувачів.

Головна сторінка може чудово відкриватися у браузері, а сервер при цьому не зможе коректно звернутися до власного домену.

Чому виникає cURL Error 28

Причин помилки досить багато. Основні можна поділити на кілька груп.

1. Занадто довга відповідь сервера

Запит надіслано, але сервер не встиг обробити його за встановлений час.

2. Firewall блокує запит

Система безпеки може прийняти внутрішній запит WordPress за підозрілу активність.

3. Проблеми з DNS

Сервер не може коректно дозволити доменне ім'я в IP-адресу.

4. Помилка SSL

З'єднання HTTPS не встановлюється або неправильно обробляється.

5. Проблемний плагін

Плагін може перехоплювати HTTP-запити, змінювати налаштування безпеки або створювати надто довгі операції.

6. CDN або проксі

Cloudflare та інші проміжні сервіси можуть впливати на з'єднання між WordPress та власним доменом.

7. Обмеження хостингу

Сервер може мати обмеження щодо CPU, пам'яті, PHP execution time або вихідним з'єднанням.

8. Застаріле програмне забезпечення

Проблеми можуть виникнути через стару версію PHP, cURL або OpenSSL.

Як виправити cURL Error 28: покрокова інструкція

Не варто відразу змінювати налаштування сервера.

Краще йти від найбільш імовірної та безпечної причини до складнішої.

Спосіб 1. Перевірити, що саме повідомляє «Здоров'я сайту»

Відкрийте:

Консоль WordPress → Інструменти → Здоров'я сайту → Стан

Знайдіть повідомлення:

«REST API виявив помилку»

або:

"Ваш сайт не зміг виконати loopback-запит".

Розкрийте подробиці.

Особливу увагу зверніть на:

• URL-адреса запиту;
• час очікування;
• HTTP-код;
• кількість одержаних байт;
• текст помилки;
• наявність одночасно кількох проблем.

Це важливо, тому що:

cURL Error 28 – це симптом, а не діагноз.

Наприклад:

cURL error 28
timeout after 10000 ms
0 bytes received


и

cURL error 28
timeout after 10000 ms
125 KB received


можуть вказувати на різні проблеми.

Спосіб 2. Тимчасово вимкніть firewall WordPress

Плагіни безпеки можуть блокувати внутрішні запити HTTP.

Особливо уважно перевірте:

• Wordfence;
• firewall-плагіни;
• антибот-захист;
• плагіни обмеження REST API;
• системи блокування ІР;
• серверний ModSecurity.

Як перевірити

1. Зробіть резервну копію.
2. Тимчасово вимкніть firewall.
3. Відкрийте Інструменти → Здоров'я сайту.
4. Повторіть перевірку.
5. Порівняйте результат.

Якщо cURL Error 28 зникла, причина, ймовірно, пов'язана з системою безпеки.

Важливо

Не залишайте Firewall відключеним на робочому сайті.

Якщо проблема дійсно в ньому, краще знайти правило, яке блокує запит і додати коректний виняток.

Спосіб 3. Вимкніть плагіни

Якщо firewall не винен, наступний кандидат – плагіни.

Це особливо актуально, якщо помилка з'явилася після:

• встановлення нового плагіна;
• оновлення WordPress;
• оновлення PHP;
• оновлення плагіна;
• зміни налаштувань безпеки;
• підключення CDN.

Якщо доступна адмінка

Перейдіть:

Плагіни → Встановлені плагіни

Вимкніть усі плагіни.

Після цього знову запустіть перевірку здоров'я сайту.

Якщо помилка зникла, вмикайте плагіни по одному.

Після кожної активації перевіряйте API REST.

Так можна визначити винуватця.

Якщо доступу до WordPress немає

Можна вимкнути плагіни через файловий менеджер або SFTP.

Відкрийте:
/wp-content/

та знайдіть каталог:
plugins

Тимчасово перейменуйте його, наприклад:
plugins

в:
plugins-disabled

WordPress перестане завантажувати плагіни.

Після перевірки поверніть вихідну назву.

важливе уточнення

Не видаляйте каталог.

Нам потрібно лише тимчасово вимкнути плагіни.

Спосіб 4. Перевірте REST API вручну

REST API – один із ключових компонентів сучасного WordPress.

Спробуйте відкрити :
https://example.com/wp-json/

Замініть example.com на свій домен.

Якщо REST API працює, ви повинні отримати відповідь JSON.

Якщо натомість з'являється:

• timeout;
• 403;
• 404;
• 500;
• 502;
• 503;
• помилка SSL;

проблему потрібно шукати вже не лише у cURL.

WordPress використовує REST API для різних операцій, у тому числі для роботи редактора та адміністративних функцій.

Спосіб 5. Перевірте loopback-запит

WordPress має окрему перевірку loopback.

Вона дозволяє визначити, чи здатний сайт звертатися сам до себе.

Якщо loopback не працює, потенційні причини включають:

• firewall;
• DNS;
• SSL-сертифікат;
• серверну конфігурацію;
• неправильний hosts;
• CDN;
• HTTP-автентифікацію;
• плагіни;
• обмеження хостингу.

WordPress виконує loopback-перевірку з timeout у 10 секунд у відповідному тесті Site Health.

Тому повідомлення виду:
cURL error 28:
Connection timed out after 10000 milliseconds

Цілком може бути результатом саме цієї перевірки.

Спосіб 6. Перевірте DNS

DNS відповідає за перетворення доменного імені на IP-адресу.

Спрощено:
example.com
↓
DNS
↓
123.123.123.123
↓
сервер


Якщо сервер не може коректно дозволити власний домен, запит loopback може завершитися timeout.

Що перевірити

Впевніться, що:

• A запис вказує на правильний IP;
• AAAA-запис не вказує на непрацюючий IPv6;
• DNS-записи нещодавно не змінювалися;
• домен дійсно вказує на потрібний сервер;
• DNS не працює з помилками.

Окремо перевірте IPv6

Це досить часто причина мережевих проблем, яку легко пропустити.

Наприклад:
A example.com → IPv4
AAAA example.com → IPv6


Якщо IPv6 настроєно неправильно, сервер може намагатися встановити з'єднання через IPv6 і чекати на відповідь.

В результаті з'являється timeout.

Якщо після видалення або виправлення некоректного запису AAAA проблема зникає, причина була в IPv6-маршрутизації.

Спосіб 7. Перевірте SSL та HTTPS

Помилка може виникати під час неправильної роботи HTTPS.

перевірте:

• термін дії сертифіката;
• відповідність сертифіката домену;
• ланцюжок сертифікатів;
• налаштування TLS;
• редиректи HTTP → HTTPS;
• роботу HTTPS із самого сервера.

Особливо уважно перевіряйте ситуацію, коли сайт використовує:

Cloudflare
↓
HTTPS
↓
origin server


або іншу CDN/прокси-схему.

Якщо SSL працює в браузері, це ще не гарантує, що серверні запити HTTP працюють коректно.

Спосіб 8. Перевірте Cloudflare та інші CDN

Якщо використовується Cloudflare або інша CDN, тимчасово виключіть її.

Наприклад, можна перевірити:

• чи працює запит безпосередньо до origin-сервера;
• чи не блокує WAF внутрішній запит;
• чи немає проблем із SSL mode;
• чи не змінюється HTTP-заголовок;
• чи правильно настроєно DNS;
• чи не виникає проблема лише при проксуванні.

Практичний тест:

Якщо помилка з'являється лише при включеному CDN, а після обходу CDN зникає, шукайте причину в проксі, WAF або DNS.

Спосіб 9. Перевірте налаштування PHP

Старий або неправильно налаштований PHP може спричинити проблеми з HTTP-запитами.

Відкрийте:

Інструменти → Здоров'я сайту → Інформація → Сервер

перевірте:

• версію PHP;
• PHP memory limit;
• max execution time;
• максимальний розмір вхідних даних;
• наявність необхідних розширень.

Також важливо перевірити версії:

• CURL;
• OpenSSL;
• PHP.

WordPress рекомендує підтримувати актуальне серверне програмне забезпечення, а Site Health спеціально відображає інформацію про конфігурацію PHP та інших компонентів.

Спосіб 10. Перевірте ліміт пам'яті WordPress

Якщо PHP або WordPress не вистачає пам'яті, деякі операції можуть виконуватися надто довго або аварійно завершуватися.

Перевірте значення:
WP_MEMORY_LIMIT

у конфігурації WordPress.

Також зверніть увагу на PHP:
memory_limit

Недолік пам'яті особливо вірогідний на сайтах:

• WooCommerce;
• факір;
• великою кількістю плагінів;
• імпортом товарів;
• складними REST-запитами;
• великою кількістю cron-завдань.

Спосіб 11. Перевірте WP-Cron

Якщо cURL Error 28 з'являється разом із повідомленням про проблеми loopback, перевірте WP-Cron.

WordPress використовує HTTP-механізм для запуску запланованих завдань.

Проблеми з WP-Cron можуть виникати через:

• блокування wp-cron.php;
• firewall;
• Basic Auth;
• CDN;
• неправильного DNS;
• проблем із SSL;
• серверних обмежень.

Перевірити можна запитом:
https://example.com/wp-cron.php

Однак не варто робити висновок тільки з браузерного відкриття цього URL: серверний loopback і звичайний запит браузера - не те саме.

Спосіб 12. Перевірте файл hosts на сервері

Це вже більш просунута діагностика, але іноді саме тут є причина.

Сервер повинен коректно дозволяти власне доменне ім'я.

У Linux використовується файл:
/etc/hosts

Якщо hostname або домен неправильно настроєний, сервер може не зуміти звернутися до власного сайту.

Особливо актуально це для:

• ВПС;
• виділених серверів;
• нестандартних конфігурацій Nginx/Apache;
• серверів із кількома сайтами;
• складної конфігурації IPv4/IPv6.

Спосіб 13. Перевірте, чи вихідні з'єднання не блокуються.

Іноді проблема не на вході, а на виході.

Сайт повинен мати можливість надсилати HTTP/HTTPS-запити у зовнішній інтернет.

перевірте:

• Firewall сервера;
• правила вихідного трафіку;
• ModSecurity;
• мережеві ACL;
• налаштування контейнера;
• обмеження VPS;
• правила хостинг-провайдера.

Це особливо важливо, якщо WordPress не може підключитися не тільки до власного REST API, а й до:

• WordPress.org;
• API плагінів;
• зовнішнім сервісам;
• систем оновлень.

WordPress Site Health окремо перевіряє можливість зв'язку із серверами WordPress.org та наявність блокування HTTP-запитів.

Спосіб 14. Перевірте серверні логи

Якщо попередні способи не допомогли, настав час переходити до логів.

перевірте:

PHP error log

Шукайте:
Maximum execution time exceeded
Allowed memory size exhausted
Fatal error


Nginx

перевірте:
error.log
access.log


Apache

перевірте:
error.log
access.log


брандмауер

Шукайте:
blocked
denied
timeout
mod_security
403


Cloudflare

Перевірте події WAF та Firewall.

Як швидко визначити винуватця

Ось практична схема діагностики.

Як зрозуміти причину по тексту помилки

Сам текст помилки може дати корисну підказку.

0 bytes received

Сервер не встиг повернути дані.

Найчастіше варто перевіряти:

• DNS;
• firewall;
• мережне з'єднання;
• SSL-сертифікат;
• серверну доступність.

Could not resolve host

Проблема практично пов'язана з DNS або роздільною здатністю імені.

Failed to connect

З'єднання не було встановлено.

Перевіряйте:

• порт;
• firewall;
• сервер;
• IPv4/IPv6;
• dns.

Operation timed out

З'єднання чи отримання відповіді зайняло надто багато часу.

SSL certificate problem

Шукайте причину у SSL/TLS.

Connection refused

Сервер відхилив з'єднання.

Це вже відрізняється від timeout: сервіс відповідає на мережевому рівні відмовою.

Чи потрібно збільшувати timeout?

Іноді – так.

Але збільшення часу не є повноцінним виправленням проблеми.

Припустимо, запит стабільно виконується за 15 секунд, а timeout встановлено в 10 секунд.

Збільшення ліміту може вирішити проблему.

Але якщо запит повинен займати 10 секунд через:

• нескінченного циклу;
• повільного API;
• перевантаженого сервера;
• неправильного DNS;
• блокування firewall;

то збільшення часуout тільки замаскує справжню причину.

Тому спочатку потрібно зрозуміти:

чому запит не встигає завершитись?

Коли cURL Error 28 можна не вважати критичною

Не кожен одиничний timeout означає серйозну проблему.

Наприклад, помилка може бути тимчасовою:

• зовнішній API був недоступний;
• сервер був перевантажений;
• DNS коротко не відповідав;
• CDN тимчасово зазнавав збою.

Якщо після повторної перевірки помилка зникає і не з'являється, можливо, втручання не потрібно.

Однак постійний cURL Error 28 у Site Health ігнорувати не варто.

Він може означати, що частина фонових функцій WordPress не працює.

Як перевірити сайт після виправлення

Після внесення змін:

1. Поверніть усі вимкнені компоненти.
2. Очистіть кеш.
3. Очистіть кеш CDN.
4. Відкрийте Інструменти → Здоров'я сайту.
5. Запустіть перевірку повторно.
6. Перевірте REST API.
7. Перевірте loopback.
8. Перевірте WP-Cron.
9. Перевірте роботу редактора WordPress.
10. Переконайтеся, що оновлення WordPress та плагінів працюють.

Якщо помилка з'явилася знову після включення конкретного компонента, ви знайшли ймовірну причину.

Чек-лист: cURL Error 28 за 10 хвилин

Якщо потрібно швидко перевірити сайт, дійте так:

1. Відкрийте

Інструменти → Здоров'я сайту

2. Запишіть повний текст помилки

Особливо:
timeout
HTTP code
URL
bytes received


3. Перевірте REST API

https://ваш-домен.ru/wp-json/


4. Перевірте loopback

Перегляньте відповідний тест Site Health.

5. Тимчасово вимкніть firewall

Перевіряємо повторно.

6. Вимкніть плагіни

Якщо помилка зникла, вмикайте їх по одному.

7. Перевірте DNS

Особливо A та AAAA.

8. Перевірте SSL

Переконайтеся, що HTTPS працює правильно.

9. Якщо використовується CDN

Перевірте веб-сайт безпосередньо через origin.

10. Якщо нічого не допомогло

Передайте хостеру повний текст помилки та час її виникнення.

Що написати на підтримку хостингу

Щоб не отримати стандартну відповідь "у нас сервер працює", передайте технічні дані.

Можна написати:

На сайті WordPress постійно з'являється помилка cURL Error 28 під час перевірки REST API/loopback-запиту.

Повний текст помилки:

cURL error 28: Operation timed out after XXXXX milliseconds

Помилка з'являється у розділі «Інструменти → Здоров'я сайту».

Прохання перевірити:

- Можливість loopback-запитів до власного домену;
- DNS-дозвіл домену з сервера;
- Вихідні HTTPS-з'єднання;
- Firewall / ModSecurity;
- IPv4/IPv6;
- SSL/TLS;
- PHP/cURL/OpenSSL;
- серверні обмеження CPU/RAM;
— логи Nginx/Apache та PHP у момент виникнення помилки.

Такий запит значно корисніший за звичайне повідомлення:

"У мене cURL 28, виправте".

Часті помилки під час спроби виправити cURL Error 28

Не вимикайте SSL-перевірку

Іноді в інтернеті радять встановити:
CURLOPT_SSL_VERIFYPEER = false

або вимкнути перевірку SSL іншими способами.

Для робочого сайту це погана практика.

Так можна приховати справжню проблему із сертифікатом та одночасно послабити безпеку з'єднання.

Не збільшуйте timeout наосліп

Якщо сервер відповідає 60 секунд замість 10, збільшення timeout не робить сайт швидше.

Спочатку потрібно визначити причину повільної операції.

Не відключайте всі системи безпеки назавжди

Firewall потрібно відключати лише тимчасово для діагностики.

Після тесту обов'язково увімкніть його назад.

Не видаляйте плагіни під час діагностики

Спочатку достатньо їх вимкнути.

Це дозволить зберегти налаштування та швидко визначити винуватця.

cURL Error 28 та cURL Error 7 — у чому різниця?

Ці помилки часто плутають.

cURL Error 7 зазвичай означає, що cURL не зміг встановити з'єднання із сервером.

cURL Error 28 пов'язаний із перевищенням часу очікування операції.

Спрощено:
Error 7
↓
соединение не установлено

Error 28
↓
операция слишком долго не завершается


Тому способи діагностики частково перетинаються, але шукати причину потрібно по-різному.

Чи впливає cURL Error 28 на SEO?

Сам собою cURL Error 28 не є прямим SEO-фактором.

Але наслідки проблеми можуть опосередковано впливати на сайт.

Наприклад, якщо через помилку:

• перестав працювати WP-Cron;
• не виконуються фонові задачі;
• не оновлюються плагіни;
• ламається REST API;
• не працює частина функціональності;
• сайт періодично стає недоступним;

це може призвести до технічних проблем, які мають значення для пошукового просування.

Тому усувати потрібно не сам текст помилки, а її причину.

Чи може cURL Error 28 з'явитися через плагін?

Так.

Особливо підозрілі плагіни, які працюють з:

• ВОГНЯ;
• Безпекою;
• CDN;
• кешуванням;
• резервними копіями;
• зовнішніми сервісами;
• WooCommerce;
• імпортом/експортом;
• cron-завдання.

Найпростіший спосіб перевірки – тимчасово відключити плагіни і потім активувати їх по одному.

Чи може Cloudflare викликати cURL Error 28?

Так, така ситуація можлива.

Але не можна автоматично вважати Cloudflare винуватцем.

Необхідно визначити, на якій ділянці виникає timeout:
WordPress
↓
DNS
↓
Cloudflare
↓
Origin Server

або:
WordPress
↓
Origin Server


Якщо пряме з'єднання працює, а через CDN виникає timeout, тоді потрібно дослідити Cloudflare, WAF, DNS та SSL.

Чи потрібно звертатися до хостера?

Так, якщо проблема знаходиться на рівні сервера.

Особливо якщо:

• DNS налаштований правильно;
• плагіни відключені;
• firewall перевірено;
• SSL працює;
• REST API коректний;
• проблема відтворюється постійно;
• сервер не може виконати loopback.

Хостинг має доступ до інформації, якої зазвичай немає у власника сайту:

• системним логам;
• firewall;
• мережевої конфігурації;
• обмежень контейнера/VPS;
• PHP-FPM;
• Nginx/Apache;
• DNS;
• маршрутизації;
• вихідним з'єднанням.

FAQ: питання, що часто ставляться про cURL Error 28

Як запобігти появі cURL Error 28

Цілком виключити мережеві помилки неможливо, але ймовірність їх появи можна зменшити.

рекомендується:

• використати актуальну версію WordPress;
• підтримувати PHP у актуальному стані;
• регулярно оновлювати плагіни та теми;
• не встановлювати сумнівні плагіни;
• контролювати навантаження на сервер;
• стежити за станом DNS;
• своєчасно продовжувати SSL;
• правильно налаштовувати CDN;
• контролювати WP-Cron;
• періодично перевіряти Site Health;
• стежити за логами;
• використовувати хостинг з нормальними ресурсами та технічною підтримкою.

WordPress рекомендує регулярно використовувати Site Health саме для виявлення проблем із конфігурацією, оновленнями, безпекою та серверним оточенням.

Підсумок

cURL Error 28 – це помилка тайм-ауту, а не конкретна несправність одного компонента WordPress.

Тому немає універсальної кнопки «виправити cURL 28».

Найефективніша стратегія — рухатися від простого до складного:
Site Health
↓
REST API
↓
Firewall
↓
Плагины
↓
DNS
↓
SSL
↓
CDN / Cloudflare
↓
PHP / cURL / OpenSSL
↓
IPv4 / IPv6
↓
WP-Cron / loopback
↓
Серверные логи
↓
Хостинг


Найчастіше такий алгоритм дозволяє досить швидко визначити джерело проблеми.

І головне: не намагайтеся лікувати cURL Error 28 збільшенням timeout або вимкненням перевірки SSL, доки не встановлено причину збою. Правильне рішення – визначити, на якій ділянці HTTP-запит перестає відповідати, та усунути саме цю проблему.

Джерела

При написанні статті використовувалися такі джерела та документації:

1. Kinsta - cURL Error 28: Operation Timed Out - How to Fix It
   Вихідний матеріал, на основі якого визначалася тема, основні проблеми та базові способи діагностики.
   Kinsta - cURL Error 28
2. WordPress.org - Site Health screen
   Офіційна документація по розділу Tools → Site Healthвключаючи REST API, loopback-запити, HTTP-запити, сервер, PHP, cURL та інші параметри.
3. WordPress.org — Site Health: keep your website healthy
   Офіційний опис призначення Site Health та діагностичних перевірок WordPress.
4. Developer.WordPress.org — WP_Site_Health::can_perform_loopback()
   Дуже важливе технічне джерело розділу про loopback. Документація показує, що WordPress виконує запит до wp-cron.php та використовує timeout 10 секунд за відповідної перевірки.
5. Developer.WordPress.org — WP_Site_Health::get_test_loopback_requests()
   Офіційне пояснення того, навіщо WordPress потрібні loopback-запити: запуск запланованих подій та перевірка стабільності коду під час редагування плагінів та тем.
6. Developer.WordPress.org - WP_REST_Site_Health_Controller
   Використовувався для перевірки того, які перевірки Site Health виконує WordPress: loopback, HTTPS, зв'язок з WordPress.org, background updates та ін.
7. Developer.WordPress.org — Site Health REST API tests
   Документація REST API для тестів Site Health, включаючи loopback-requests, https-status и dotorg-communication.
8. Developer.WordPress.org — Making HTTP requests
   Офіційна документація WordPress HTTP API: wp_remote_get(), wp_remote_post(), wp_remote_request() та робота WordPress з HTTP-запитами.
9. Developer.WordPress.org - WP_Http_Curl::request()
   Використовувався для технічної частини, як WordPress використовує cURL як HTTP-транспорт. Документація також показує настройки запиту, включаючи timeout.
10. curl.se - libcurl Error Codes
    Офіційна документація libcurl. Саме тут визначено, що код 28 = CURLE_OPERATION_TIMEDOUT, тобто операція перевищила встановлений період очікування. Також звідси взяті різницю між помилками 6, 7, 28, 60 та інші.

Олексій Шевченко

редактор wpcafe

Вивчає сайтобудування з 2008 року. Практикуючий вебмайстер, що спеціалізується на створенні сайтів WordPress. Задати питання Олексію можна на https://profiles.wordpress.org/wpthemeus/