Помилка Curl 52 Порожня відповідь із сервера

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

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

Останнім часом я отримую цю помилку, коли запускається Cron

curl: (52) Empty reply from server

Я поняття не маю, що це означає. Якщо я переходжу за посиланням безпосередньо у своєму браузері, сценарій працює нормально, і я отримую свій маленький резервний zip-файл.

Хтось може надати якусь інформацію про це?

Це може статися, якщо curl попросить зробити звичайний HTTP на сервері, який робить HTTPS.

Приклад:

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

Curl видає цю помилку, коли немає відповіді від сервера, оскільки помилкою є те, що HTTP нічого не відповідає на запит.

Я підозрюю, що проблема у вас полягає в тому, що між вами та відповідним хостом існує якась мережна інфраструктура, наприклад брандмауер або проксі. Тому, щоб це працювало, вам потрібно буде обговорити проблему з людьми, відповідальними за це обладнання.

У моєму випадку це було перенаправлення сервера; curl -Lвирішив мою проблему.

Це може статися, коли сервер не реагує через 100% використання процесора або пам'яті.

Я отримав цю помилку, коли намагався отримати доступ до API sonarqube, а сервер не реагував через повне використання пам'яті

Ще однією поширеною причиною порожньої відповіді є час очікування. Перевірте всі стрибки, звідки виконується завдання cron, на ваш PHP / цільовий сервер. Ймовірно, десь по лінії є пристрій / сервер / nginx / LB / проксі, який припиняє запит раніше, ніж ви очікували, що призводить до порожньої відповіді.

У випадку SSL-з'єднань це може бути спричинено проблемою у старих версіях сервера nginx, яка segfault під час запитів curl та Safari. Ця помилка була виправлена ​​навколо версії 1.10 nginx, але в Інтернеті є ще багато старих версій nginx.

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

Мені відомо, що OP запитував не-SSL-випадок, але оскільки це головна сторінка в goole для питання "порожня відповідь із сервера", я залишаю тут відповідь SSL, оскільки я був одним із багатьох, хто б'ється головою до стіни цим випуском.

У моєму випадку це було викликано проблемою PHP APC. Перше місце, яке слід шукати, - це журнали помилок Apache (якщо ви використовуєте Apache).

Сподіваюся, це комусь допомагає.

ця помилка також може статися, якщо сервер обробляє дані. Зазвичай це трапляється зі мною, коли я публікую деякі файли на веб-сайтах REST API, які містять багато записів і займають багато часу для створення та повернення записів

Ви можете спробувати цей curl -sS " http://www.example.com/backup.php ", поставивши свою URL-адресу в "" що працювало для мене. Я не знаю точної причини, але я вважаю, що розміщення URL-адреси в " "виконує запит до сервера або просто заповнює запит заголовка.

У мене була така проблема раніше. З’ясував, що у мене була інша програма, що використовує той самий порт (3000).

Простий спосіб це дізнатись:

У терміналі введіть netstat -a -p TCP -n | grep 3000(замініть порт, яким ви користуєтесь, на «3000»). Якщо слухається більше одного, щось інше вже займає цей порт. Вам слід зупинити цей процес або змінити порт для нового процесу.

У моєму випадку (curl 7.47.0) це тому, що я встановив заголовок content-lengthна команду curl вручну зі значенням, яке обчислюється листоношею (я використовував листоношу для генерації параметрів команди curl та копіювання їх у оболонку). Після видалення заголовка content-lengthвін працює нормально.

Спробуйте це -> Замість того, щоб проходити через cURL, спробуйте пінгувати сайт, до якого ви намагаєтесь зайти за допомогою Telnet. Відповідь, яку повертає ваша спроба підключення, буде точно такою, яку бачить cURL, коли вона намагається підключитися (але яку вона безпомічно затуляє від вас). Тепер, залежно від того, що ви бачите тут, ви можете зробити один із кількох висновків:

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

Випуск також може бути пов’язаний із заголовком 100 продовжень. Спробуйте запустити curl_getinfo($ch, CURLINFO_HTTP_CODE)і перевірте результат.

Моя справа була пов’язана із закінченням терміну дії сертифіката SSL

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

Це трапляється, коли ви намагаєтесь отримати доступ до безпечного веб-сайту, наприклад Https.

Сподіваюся, ви пропустили "s"

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