web-dev-qa-db-ja.com

curlが*空の応答*を受け取ったときに接続をトラブルシューティングする方法

Webサーバーへのカールリクエストが機能しない理由をトラブルシューティングする方法を知りたい。私の環境に依存するヘルプを探しているのではなく、通信のどの部分が失敗しているか、ポート番号などに関する情報を収集する方法を知りたいだけです。

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からどのような具体的な情報を取得できますか？

正常に「接続」できたので、双方向通信は必要ではないでしょうか。もしそうなら、なぜ応答も来ないのですか？注：サービスが稼働中であり、応答を返すことを確認しました。

注、私はこのレベルのネットワーキングでは少し環境にやさしいので、一般的なオリエンテーションの資料を提供してください。

tcpcurl
28
chad

クライアント側ではなく、サーバー側からこれをトラブルシューティングする必要があるでしょう。 「空の応答」と「応答なし」を混同していると思います。同じことではありません。データが含まれていない返信を受け取っている可能性があります。

Curlを経由する代わりに、単にtelnetを使用してこれをテストできます。

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と同じように応答が表示されます。

空の応答が返される理由の1つとして、名前ベースの仮想ホストであるWebサイトにアクセスしようとしていることが考えられます。その場合は、サーバーの構成（ヒットしようとしているサイトがデフォルトとして構成されている）によっては、少し作業を行わないとIPアドレスでサイトにアクセスできません。

上記の「Host」行を変更するだけで、クライアント側でテストできます。 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: */*
17
yoonix

Curlは問題ありませんが、問題が発生してもあまりフィードバックを提供しません。 （ご存知のとおり）wgetはより多くの情報を提供する場合がありますが、yoonixが言及しているように、サーバー側（つまり、Webサーバーのエラーログ）は調べる場所です。

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

ホスト名も設定できます

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

試してみてください this -> cURLを経由する代わりに、Telnetで到達しようとしているサイトにpingを実行してみてください。接続試行が返す応答は、cURLが接続しようとしたときに表示されるものとまったく同じです（ただし、不明確に難読化されます）。さて、ここに表示される内容に応じて、いくつかの結論のうちの1つを引き出す可能性があります。

名前ベースの仮想ホストであるWebサイトに接続しようとしている。つまり、IPアドレスを介してアクセスできない。ホスト名に問題があります–入力ミスの可能性があります。パラメータにPOSTの代わりにGETを使用すると、より具体的な答えが得られます。

この問題は、100-continueヘッダーに関連している可能性もあります。 curl_getinfo（$ ch、CURLINFO_HTTP_CODE）を実行して、結果を確認してください。

2
Felix

WindowsのWSLでのいくつかの状況。 bash内でcurlを実行すると同じエラーが発生します。これは、KasperksyがHTTP/sへの接続をブロックしているためです。

このバグは報告されています ここ 。

簡単な解決策は、サーバーで到達しようとしているポートでKasperskyの保護を無効にすることです（例：tcp 80）。

これは、カスペルスキー-設定-ネットワーク設定-[選択したポートのみを監視する]にチェックを入れて実行します-ポートを選択-ポート（80）でダブルクリックして非アクティブを選択します

enter image description here

0
AK_