Ответ 1
Это может случиться, если curl попросят сделать простой HTTP на сервере, который делает HTTPS.
Пример:
$ curl http://google.com:443
curl: (52) Empty reply from server
У меня есть настройка задания cron на одном сервере для запуска резервной копии script в PHP, размещенной на другом сервере. Команда, которую я использовал, отформатирована следующим образом:
curl -sS http://www.example.com/backup.php
В последнее время я получаю эту ошибку, когда Cron запускает
curl: (52) Empty reply from server
Я понятия не имею, что это значит. Если я перейду к ссылке прямо в моем браузере, script работает отлично, и я получаю свой маленький резервный zip файл.
Может ли кто-нибудь предоставить информацию об этом?
Это может случиться, если curl попросят сделать простой HTTP на сервере, который делает HTTPS.
Пример:
$ curl http://google.com:443
curl: (52) Empty reply from server
Curl дает эту ошибку, если нет ответа с сервера, поскольку HTTP-сообщение не является ответом на запрос.
Я подозреваю, что проблема заключается в том, что между вами и хостом есть какая-то часть сетевой инфраструктуры, например брандмауэр или прокси. Поэтому, чтобы это сработало, вам потребуется обсудить эту проблему с людьми, ответственными за это оборудование.
Это может произойти, если сервер не отвечает из-за 100% загрузки процессора или памяти.
Я получил эту ошибку, когда пытался получить доступ к API-интерфейсу sonarqube, и сервер не отвечал из-за использования полной памяти
В моем случае это перенаправление сервера; curl -L
решил мою проблему.
Другой распространенной причиной пустого ответа является тайм-аут. Проверьте все переходы, с которых выполняется задание cron, на ваш PHP/целевой сервер. Возможно, где-то вдоль линии находится устройство/сервер/nginx/LB/proxy, которое завершает запрос раньше, чем вы ожидали, что приводит к пустому ответу.
В моем случае это было вызвано проблемой PHP APC. Первым местом для поиска были журналы ошибок Apache (если вы используете Apache).
Надеюсь, это поможет кому-то.
В случае SSL-соединений это может быть вызвано проблемой в более старых версиях сервера nginx, которая вызывает ошибки во время запросов curl и Safari. Эта ошибка была исправлена в версии 1.10 nginx, но в Интернете все еще есть много старых версий nginx.
Для администраторов nginx: добавление ssl_session_cache shared:SSL:1m;
Блок http
должен решить проблему.
Я знаю, что OP запрашивал случай не-SSL, но так как это верхняя страница в goole для проблемы "пустой ответ от сервера", я оставляю здесь ответ SSL, поскольку я был одним из многих, кто бился в мою голову против стены с этим вопросом.
Это происходит, когда вы пытаетесь получить доступ к защищенному веб-сайту, например, Https.
Надеюсь, вы пропустили '
Попробуйте изменить URL-адрес на curl -sS -u "имя пользователя: пароль" https://www.example.com/backup.php
вы можете попробовать этот curl -sS " http://www.example.com/backup.php" поместив ваш URL в ", который работал на меня, я не знаю точной причины, но я полагаю, что включение URL-адреса в" " завершает запрос на сервер или просто завершает запрос заголовка.
У меня была эта проблема раньше. Выяснил, у меня было другое приложение, использующее тот же порт (3000).
Простой способ узнать это:
В терминале введите netstat -a -p TCP -n | grep 3000
netstat -a -p TCP -n | grep 3000
(замените порт, который вы используете на "3000"). Если имеется более одного прослушивания, то этот порт уже занимает что-то другое. Вы должны остановить этот процесс или изменить порт для вашего нового процесса.
Попробуйте this → Вместо того, чтобы проходить через cURL, попробуйте выполнить ping-сайт, который вы пытаетесь связаться с Telnet. Ответ, который возвращает попытка подключения, будет именно тем, что видит cURL, когда он пытается подключиться (но который он бесполезно запутывает от вас). Теперь, в зависимости от того, что вы видите здесь, вы можете сделать один из нескольких выводов:
Вы пытаетесь подключиться к веб-сайту, на котором основан виртуальный хост на основе имени, что означает, что он не может быть достигнут через IP-адрес. Что-то не так с именем хоста - возможно, вы что-то ошиблись. Обратите внимание, что использование GET вместо POST для параметров даст вам более конкретный ответ.
Проблема также может быть связана с заголовком 100-continue. Попробуйте запустить curl_getinfo($ch, CURLINFO_HTTP_CODE)
и проверьте результат.
В моем случае (curl 7.47.0) это происходит потому, что я вручную устанавливаю content-length
заголовка для команды curl со значением, которое вычисляется почтальоном (я использовал почтальон для генерации параметров команды curl и их копирования в оболочку). После того, как я удаляю заголовок content-length
, он работает нормально.
В моем случае я использовал uwsgi, добавил свойство http-timeout более чем на 60 секунд, но оно не работало из-за некоторого дополнительного места и файл конфигурации не загружался должным образом.
Просто добавив это для дополнительной возможности, с чем я столкнулся.
Я пытался подключиться к серверу nginx
через localhost
, и он просто дал бы мне пустой ответ. Я выполнил каждую небольшую работу по устранению неполадок, а затем, наконец, сузил ее до проблемы IPv4 против 6. По сути, если у вас есть запись в /etc/hosts
" ::1 localhost
", вам также необходимо настроить дополнительный прослушиватель nginx
с listen [::]:80
(для IPv6), в дополнение к прослушиванию 80. Я думаю, что это скорее всего потому, что nginx
был разработан для работы в linux, и он может выполнять двойное связывание, тогда как ОС на базе BSD, насколько мне известно, не могут. Кто-то, пожалуйста, поправьте меня, если это неправильно.