Ошибка скручивания 52 Пустой ответ с сервера

У меня есть настройка задания cron на одном сервере для запуска резервной копии script в PHP, размещенной на другом сервере. Команда, которую я использовал, отформатирована следующим образом:

curl -sS http://www.example.com/backup.php

В последнее время я получаю эту ошибку, когда Cron запускает

curl: (52) Empty reply from server

Я понятия не имею, что это значит. Если я перейду к ссылке прямо в моем браузере, script работает отлично, и я получаю свой маленький резервный zip файл.

Может ли кто-нибудь предоставить информацию об этом?

Ответ 1

Это может случиться, если curl попросят сделать простой HTTP на сервере, который делает HTTPS.

Пример:

$ curl http://google.com:443
curl: (52) Empty reply from server

Ответ 2

Curl дает эту ошибку, если нет ответа с сервера, поскольку HTTP-сообщение не является ответом на запрос.

Я подозреваю, что проблема заключается в том, что между вами и хостом есть какая-то часть сетевой инфраструктуры, например брандмауэр или прокси. Поэтому, чтобы это сработало, вам потребуется обсудить эту проблему с людьми, ответственными за это оборудование.

Ответ 3

Это может произойти, если сервер не отвечает из-за 100% загрузки процессора или памяти.

Я получил эту ошибку, когда пытался получить доступ к API-интерфейсу sonarqube, и сервер не отвечал из-за использования полной памяти

Ответ 4

В моем случае это перенаправление сервера; curl -L решил мою проблему.

Ответ 5

Другой распространенной причиной пустого ответа является тайм-аут. Проверьте все переходы, с которых выполняется задание cron, на ваш PHP/целевой сервер. Возможно, где-то вдоль линии находится устройство/сервер/nginx/LB/proxy, которое завершает запрос раньше, чем вы ожидали, что приводит к пустому ответу.

Ответ 6

В моем случае это было вызвано проблемой PHP APC. Первым местом для поиска были журналы ошибок Apache (если вы используете Apache).

Надеюсь, это поможет кому-то.

Ответ 7

В случае SSL-соединений это может быть вызвано проблемой в более старых версиях сервера nginx, которая вызывает ошибки во время запросов curl и Safari. Эта ошибка была исправлена в версии 1.10 nginx, но в Интернете все еще есть много старых версий nginx.

Для администраторов nginx: добавление ssl_session_cache shared:SSL:1m; Блок http должен решить проблему.

Я знаю, что OP запрашивал случай не-SSL, но так как это верхняя страница в goole для проблемы "пустой ответ от сервера", я оставляю здесь ответ SSL, поскольку я был одним из многих, кто бился в мою голову против стены с этим вопросом.

Ответ 8

Это происходит, когда вы пытаетесь получить доступ к защищенному веб-сайту, например, Https.

Надеюсь, вы пропустили '

Попробуйте изменить URL-адрес на curl -sS -u "имя пользователя: пароль" https://www.example.com/backup.php

Ответ 9

вы можете попробовать этот curl -sS " http://www.example.com/backup.php" поместив ваш URL в ", который работал на меня, я не знаю точной причины, но я полагаю, что включение URL-адреса в" " завершает запрос на сервер или просто завершает запрос заголовка.

Ответ 10

У меня была эта проблема раньше. Выяснил, у меня было другое приложение, использующее тот же порт (3000).

Простой способ узнать это:

В терминале введите netstat -a -p TCP -n | grep 3000 netstat -a -p TCP -n | grep 3000 (замените порт, который вы используете на "3000"). Если имеется более одного прослушивания, то этот порт уже занимает что-то другое. Вы должны остановить этот процесс или изменить порт для вашего нового процесса.

Ответ 11

Попробуйте this → Вместо того, чтобы проходить через cURL, попробуйте выполнить ping-сайт, который вы пытаетесь связаться с Telnet. Ответ, который возвращает попытка подключения, будет именно тем, что видит cURL, когда он пытается подключиться (но который он бесполезно запутывает от вас). Теперь, в зависимости от того, что вы видите здесь, вы можете сделать один из нескольких выводов:

Вы пытаетесь подключиться к веб-сайту, на котором основан виртуальный хост на основе имени, что означает, что он не может быть достигнут через IP-адрес. Что-то не так с именем хоста - возможно, вы что-то ошиблись. Обратите внимание, что использование GET вместо POST для параметров даст вам более конкретный ответ.

Проблема также может быть связана с заголовком 100-continue. Попробуйте запустить curl_getinfo($ch, CURLINFO_HTTP_CODE) и проверьте результат.

Ответ 12

В моем случае (curl 7.47.0) это происходит потому, что я вручную устанавливаю content-length заголовка для команды curl со значением, которое вычисляется почтальоном (я использовал почтальон для генерации параметров команды curl и их копирования в оболочку). После того, как я удаляю заголовок content-length, он работает нормально.

Ответ 13

В моем случае я использовал uwsgi, добавил свойство http-timeout более чем на 60 секунд, но оно не работало из-за некоторого дополнительного места и файл конфигурации не загружался должным образом.

Ответ 14

Просто добавив это для дополнительной возможности, с чем я столкнулся.

Я пытался подключиться к серверу nginx через localhost, и он просто дал бы мне пустой ответ. Я выполнил каждую небольшую работу по устранению неполадок, а затем, наконец, сузил ее до проблемы IPv4 против 6. По сути, если у вас есть запись в /etc/hosts " ::1 localhost ", вам также необходимо настроить дополнительный прослушиватель nginx с listen [::]:80 (для IPv6), в дополнение к прослушиванию 80. Я думаю, что это скорее всего потому, что nginx был разработан для работы в linux, и он может выполнять двойное связывание, тогда как ОС на базе BSD, насколько мне известно, не могут. Кто-то, пожалуйста, поправьте меня, если это неправильно.