Как устранить неполадки подключения, когда curl получает * пустой ответ *

27

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

chad-integration:~ # curl -v 111.222.159.30
* About to connect() to 111.222.159.30 port 80 (#0)
*   Trying 111.222.159.30... connected
* Connected to 111.222.159.30 (111.222.159.30) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: 111.222.159.30
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host 111.222.159.30 left intact
curl: (52) Empty reply from server
* Closing connection #0

Итак, я понимаю, что пустой ответ означает, что curl не получил никакого ответа от сервера. Нет проблем, это именно то, что я пытаюсь выяснить.

Но какую более конкретную информацию я могу получить из cURL здесь?

Он был в состоянии успешно «соединиться», так что это не подразумевает двунаправленную связь? Если так, то почему ответ также не приходит? Обратите внимание, я проверил, что мой сервис работает и возвращает ответы.

Обратите внимание, я немного зеленоват на этом уровне сетей, поэтому не стесняйтесь предоставлять некоторые общие материалы по ориентации.

tcp curl

— Чад
источник

1

Я получал ту же ошибку, но в моем случае это было программное обеспечение VPN, которое перехватывало и блокировало определенный сетевой трафик. См. Здесь для получения дополнительной информации: stackoverflow.com/a/24189367/703200

— Крис Бартли

16

Вероятно, вам придется устранять неполадки на стороне сервера, а не на стороне клиента. Я считаю, что вы путаете «пустой ответ» с «нет ответа». Они не означают одно и то же. Скорее всего, вы получаете ответ, который не содержит никаких данных.

Вы можете проверить это, просто используя telnet вместо curl:

telnet 111.222.159.30 80

После подключения вставьте следующее (взято из вывода curl):

GET / HTTP/1.1
User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Host: 111.222.159.30
Accept: */*

Вы должны увидеть ответ именно так, как его видит curl.

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

Вы можете проверить это на стороне клиента, просто изменив строку «Хост» выше; замените www.example.com сайтом, на который вы пытаетесь перейти:

GET / HTTP/1.1
User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Host: www.example.com
Accept: */*

— yoonix
источник

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

— Чад

И что касается пустого ответа = нет ответа, я получил его от stackoverflow.com/questions/5929971/… , но я готов рассмотреть второе мнение;)

— Чад

1

Вам по-прежнему нужно устранять неполадки со стороны сервера. Если сервер не отправляет данные, клиент не будет знать, почему. Он только знает, что не понял. Что касается пустого против нет, я нашел сервер, который curl жаловался на «пустой» ответ, и я определенно получил ответ. * Empty reply from serverиз curl, connect напрямую показал все соответствующие заголовки http с телом, состоящим исключительно из . Если он работает с curl в другом месте, а не в одной конкретной сети, я бы посмотрел на различия в этой сети. Возможно, плохо ведущий прокси?

— yoonix

7

Скручивание в порядке, но не дает много отзывов, когда что-то идет не так. (Как вы можете сказать) wget может дать вам больше информации, но, как упоминает yoonix, серверная часть (т. Е. Журналы ошибок веб-сервера) - это то, что нужно искать.

wget -S -O /dev/null http://www.example.com

Вы также можете установить имена хостов с

wget -s -O /dev/null --header="Host: foo.bar" http://www.example.com

— GeoSword
источник

2

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

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

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

— Феликс
источник

1

Примечание (поскольку я видел, что вы опубликовали этот же ответ в другом вопросе cURL): эти вопросы касаются cURL, двоичного файла CLI, а не реализации PHP-оболочки, на которую вы ссылаетесь. Другими словами, getinfoдля CLI cURL не существует такого понятия, как флаг или функция. @see curl.haxx.se

— кен

0

В некоторых случаях под Windows WSL. Запуск curl внутри bash вызовет ту же ошибку, и это потому, что Kasperksy блокирует его подключение к HTTP / s.

Об этой ошибке сообщалось здесь .

Быстрое решение состоит в том, чтобы отключить защиту Kaspersky на порте, к которому вы пытаетесь подключиться на сервере (tcp 80 для примера).

Это можно сделать, зайдя в «Касперский» - «Настройки» - «Настройки сети» - отметьте «Мониторинг только выбранных портов» - Выберите порты - дважды нажмите на порт (80) и выберите неактивный

— AK_
источник