Приветствуем вас! Вы видите ошибку cURL 28: Превышено время ожидания соединения на вашем сайте WordPress? Ошибка cURL 28 — распространенная проблема WordPress REST API, которая может повлиять на производительность вашего веб-сайта и привести к его непредсказуемому поведению.
В этой статье мы покажем вам, как легко исправить проблему cURL error 28 на вашем веб-сайте WordPress.
Что такое cURL в WordPress?
CURL — это программная утилита, используемая WordPress и многими другими веб-приложениями для отправки и получения запросов данных с использованием URL-адресов.
WordPress использует cURL для обработки нескольких запросов API. Он доступен как расширение языка программирования PHP, и ваша хостинговая компания WordPress позаботится об этом.
Библиотека cURL играет решающую роль в том, как WordPress работает за кулисами. Если он не настроен должным образом, ваш веб-сайт не будет работать должным образом.
Что вызывает ошибку cURL 28 в WordPress?
Неспособность своевременно ответить на запросы данных сервера вызывает ошибку 28 cURL в WordPress.
WordPress использует REST API (метод программирования) для отправки и получения запросов данных. Если время ожидания этих запросов истекло, вы увидите это как критическую проблему в отчете о работоспособности сайта с заголовком «Ошибка REST API».
Расширение ошибки покажет вам дополнительную информацию, включая сообщение об ошибке:
Error: cURL error 28: Operation timed out after x milliseconds with x bytes received (http_request_failed)
Вы также можете увидеть другую связанную проблему с заголовком «Ваш сайт не может выполнить запрос обратной связи». В нем будет аналогичное сообщение об ошибке со следующим описанием.
«Запрос обратной связи к вашему сайту не удался, это означает, что функции, использующие их, в настоящее время не работают должным образом».
Что может вызвать тайм-аут cURL?
Ряд сценариев может вызвать тайм-аут cURL в WordPress:
- Например, плагин брандмауэра WordPress может блокировать запрос REST API, считая его подозрительным действием.
- Если ваш DNS-сервер работает некорректно, это также может вызвать сбой HTTP-запросов и вызвать ошибку тайм-аута cURL в WordPress.
- Плохо настроенный хостинг-сервер может просто иметь очень низкий порог тайм-аута, что может помешать правильной работе определенных процессов WordPress.
Давайте посмотрим, как устранить и исправить данную проблему.
1. Временно отключите брандмауэр WordPress
Если вы используете брандмауэр WordPress или плагин безопасности, временно отключите его.
После этого вам нужно посетить страницу отчета о работоспособности сайта WordPress, чтобы узнать, решена ли ваша проблема.
Если да, то вам нужно проверить журналы брандмауэра WordPress, чтобы узнать, какие запросы API были заблокированы. Это либо определит источник проблемы, либо вы можете настроить параметры брандмауэра, чтобы не блокировать законные запросы API.
2. Отключите все плагины WordPress
Плагины WordPress создают собственные запросы API для отправки и получения данных. Если эти вызовы слишком часты или для выполнения требуется слишком много времени, это может вызвать ошибку cURL в отчете о работоспособности вашего сайта.
Самый простой способ выяснить это — отключить все плагины WordPress. Просто перейдите на страницу «Плагины»-«Установленные» и выберите все плагины.
После этого щелкните раскрывающееся меню «Массовые действия», чтобы выбрать «Деактивировать», а затем нажмите кнопку «Применить».
Теперь вы можете посетить отчет о работоспособности сайта, чтобы узнать, исчезла ли проблема. Если это устранило проблему, вы можете активировать свои плагины один за другим, пока проблема не появится снова.
Это поможет вам найти плагин, который может вызывать проблему.
3. Убедитесь, что ваш хостинг-сервер использует новейшее программное обеспечение
Следующий шаг — убедиться, что ваш хостинг-сервер WordPress использует последние версии PHP, библиотеки cURL и OpenSSL.
Вы можете проверить это, просмотрев вкладку системной информации на странице «Инструменты»-«Здоровье сайта».
Просто перейдите на вкладку «Информация» и разверните раздел «Сервер». Отсюда вы можете получить информацию о программном обеспечении, установленном на вашем хостинг-сервере WordPress.
В идеале ваш сервер должен использовать PHP 7.4.13 или выше, curl 7.74.0 или выше и OpenSSL 1.1.1 или выше.
Если это не так, вам необходимо связаться с вашей хостинговой компанией и попросить их обновить программное обеспечение для вашей учетной записи хостинга.
4. Устранение проблем с небезопасным контентом SSL
Если ваш сайт использует HTTPS / SSL, но он не настроен должным образом, это также может привести к тому, что ваш веб-сервер заблокирует небезопасные запросы cURL.
Точно так же, если ваш веб-сайт не использует HTTPS / SSL, но он сделал вызов API с использованием URL-адреса HTTP, то эти запросы тоже не будут выполнены, и вместо этого вы можете увидеть следующую ошибку cURL:
Ошибка: ошибка cURL 7: не удалось подключиться к порту localhost 443: в соединении отказано (http_request_failed)
Чтобы исправить это, вы можете попросить своего хостинг-провайдера переустановить сертификат SSL для вашего сайта.
5. Обратитесь за помощью к поставщику услуг хостинга
Если описанные выше действия не помогли устранить ошибку cURL 28 то, проблема, скорее всего, связана с средой хостинга.
Есть много факторов, которые могут контролироваться и исправляться только вашей хостинговой компанией. Например, если их DNS-серверы не могут своевременно разрешать запросы, это приведет к тайм-ауту запросов cURL.
Другой сценарий может заключаться в более медленном подключении или сетевых проблемах с вашим хост-сервером.
Просто отправьте им запрос в службу поддержки с подробными сведениями об ошибке, и их технический персонал сможет устранить неполадки и применить исправление для ее решения. Ну что, у нас на этом все. Всем пока!
С уважением Вячеслав и Валерия!
Понравился материал? Поделитесь с друзьями!
Интересное на блоге
Просмотр 15 ответов — с 1 по 15 (всего 16)
Хостер говорит что ничего не блокирует…
@portass Этот хостер случайно не Бегет?
-
Ответ изменён 1 месяц, 1 неделя назад пользователем
medmall.
@igor-san если так, то почему ошибка иногда пропадает? То блокирует, а то вдруг на время разблокирует?
@medmall да,бегает, я так понял у многих проблемы. Плагины не обновляются,админка дико тупит…
@portass да, есть такая проблема: и админка тупит, и плагины не обновляются, невозможно установить новый из адмминки, не обновляются темы и переводы; «здоровье сайта» периодически показывает критическую проблему «Ошибка Ваш сайт не смог подключиться к WordPress.org по 198.143.164.251, и вернул ошибку: cURL error 28: Connection timed out after 10001 milliseconds»! Проблема, кстати, плавающая — прошедшим вечером и ночью после кучи попыток удалось обновиться.
@medmall А что с бегет не так уже?
@fletot21 в первом посте и моём посте выше как раз и написано, что сейчас с Бегетом не так.
@medmall честно говоря я поменял много хостингов, Бегет хоть и дороже но мне понравился качеством услуг и адекватной техподдержкой. Но походу наступил момент когда нужно искать нового хостера.
Но походу наступил момент когда нужно искать нового хостера.
я бы все-таки подождал числа 20го, потом бы решал.
portass это он сейчас стал дороже, буквально год назад было ещё норм. Косячили они всегда, ТП действительно адекватная, пусть и подтупливает иногда. А хорошо там, где нас нет.
Я в соседней теме отписался, что проблема с обновлениями вроде как исчезла. Недели хватило на решение проблемы — учитывая календарь — норм;)
@medmall Да, работает, молчу бо боюсь сглазить))). А что же все таки это было? Чисто ради интереса
Модератор
Yui
(@fierevere)
ゆい
Рад интереса?
Из за избытка трафика определяемого как вредоносный, IP Бегета периодически блокировались на SingleHop (это Датацентр, который хостит WordPress.org, но не является нашим).
Со стороны Бегет требовалось разобраться с вредоносным трафиком и/или пообщаться с сетевиками SingleHop.
@fierevere Как я понял, проблему бегет так и не решил?
Просмотр 15 ответов — с 1 по 15 (всего 16)
Если Вы получили следующую ошибку: «cURL error 28: Resolving timed out after 5515 milliseconds (http_request_failed)», при диагностике «здоровья» своего сайта на WordPress, то в этой теме Вы получите ответ с чем связана данная проблема, а главное как ее решить!
Начнем с того, что разберемся с чем связанная данная ошибка! В последнее время у многих пользователей возникли проблемы с разрешением DNS от Google, что действительно подчеркнуло необходимость распределенного Интернета! Имея это в виду, я хотел написать руководство по обновлению преобразователей DNS до настраиваемого поставщика DNS. В связи с чем мы будем использовать OpenDNS для решения этой проблемы, вместо DNS Google. Но вы можете использовать любые другие «открытые» DNS сервера, какие можно узнать здесь.
И так после того как мы разобрались с чем связана проблема, можно приступить к ее устранению! Заменим открытые DNS адреса google на DNS OpenDNS. Для debian и основанных на ней ОС, открываем сетевой конфиг:
# nano /etc/network/interfaces
P.S. Я использую редактор nano, вы можете использовать любой другой, какой вам удобен!
В строке dns-nameservers удаляем DNS адреса google 8.8.8.8 и 8.8.4.4, вместо них пишем 208.67.222.222, 208.67.220.220. Так же можно прописать DNS адреса Вашего провайдера, после чего сохраняем изменения и перезагружаем нетворк скрипт:
# systemctl restart network.service
либо:
# service netowrk restart
Для RHEL систем и ее производных, так же открываем конфиг сетевых настроек:
# nano /etc/sysconfig/network-scripts/ifcfg-eth0
либо:
# /etc/sysconfig/network-scripts/ifcfg-enp1s0
В зависимости от того как называется в вашей ОС сетевой интерфейс, можно посмотреть набрав команду ifconfig в консоли.
В конфиге меняем соответствующие поля:
DNS1=8.8.8.8
DNS2=8.8.4.4На те какие Вы выбрали в самом начале, в моем случае на OpenDNS сервера:
DNS1=208.67.222.222
DNS2=208.67.220.220После чего так же перезагружаем нетворк скрипт:
# systemctl restart network.service
Проблема решена, можно убедиться в этом проведя очередную диагностику «здоровья» в панели управления WordPress