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

Я хочу знать, как приступить к устранению неполадок, почему запрос 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 здесь?

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

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

Источник

4 ответа

Решение

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

Вы можете проверить это, просто используя 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: */*
Источник

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

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

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

wget -s -O /dev/null --header="Host: foo.bar" http://www.example.com
Источник

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

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

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

Источник

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

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

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

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

Источник
Другие вопросы по тегам