web-dev-qa-db-ja.com

Curl応答がハングする

仮想ボックスにサイトを設定しています。自分のマシンのブラウザから問題なくアクセスできますが、SSHでボックスにアクセスしているときにCURL経由でアクセスできません。

試してみると、curlが応答を表示して終了する前にハングします。

これは私が実行するものです：curl -vvv site1.dev/

これはそれが与える出力です：

* Hostname was NOT found in DNS cache
*   Trying 192.168.10.10...
* Connected to site1.dev (192.168.10.10) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.35.0
> Host: site1.dev
> Accept: */*
> 
< HTTP/1.1 200 OK
* Server nginx/1.9.7 is not blacklisted
< Server: nginx/1.9.7
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: no-cache
< Date: Fri, 08 Apr 2016 16:47:30 GMT
< 
* Connection #0 to Host site1.dev left intact
hi

リクエスト部分はすぐに送信されますが、応答は数秒間ハングし（120ishのように見えます）、curlは次のメッセージで終了します：* Connection #0 to Host site1.dev left intact

その後に、「hi」という応答の適切な本文が続きます。

私は少し迷っています-どんなポインタでもいただければ幸いです。

4月11日を編集：wgetを試しましたが、同様の結果が表示されました（応答がハングします）。ネットワーク構成の問題だと思います。

該当する場合は、仮想ボックスのポート構成の一部を次に示します。

==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 80 => 8000 (adapter 1)
    default: 443 => 44300 (adapter 1)
    default: 3306 => 33060 (adapter 1)
    default: 5432 => 54320 (adapter 1)
    default: 22 => 2222 (adapter 1)

4月12日を編集：

だから...私はこの浮浪者の箱を破壊し、新たに始めることにしました...これを行うことで問題が解決しました。

過去数か月の間に何かを変えた/壊したのではないかと思います。最初から、バニラボックスの設定で、この問題は修正されました。

networkingvirtualboxcurlnginx
3
Todd

おそらくnginxは着信要求のIP解決を行うように構成されており、実際に要求に応答する前に着信接続を解決するのに時間がかかっています。

いくつかのポインタがありますが、192.168.10.10で以下を確認する必要があります。

  1. /etc/resolv.conf内でネームサーバーが正しいことを確認します
  2. ＃1解決設定がプライマリおよびセカンダリネームサーバーに対して正しい場合は、192.168.10.10がホストを解決できることを確認してください。 （google.comへの単純なnslookupはこれの良いテストです。タイムアウトが発生した場合、これは問題の一部である可能性があります）
  3. Nginxサーバーがファイアウォールを介して外部または内部でネームサーバーをクエリできることを確認します（ポート53 tcp/udp）
  4. Nginx構成オプション内で潜在的なリゾルバー設定を探すか、該当する場合は解決タイムアウト設定を設定して、nginxを再起動します。
  5. それでも問題が解決しない場合は、192.168.10.10の/ etc/hosts内に着信要求接続のホストを追加してください。

Ya ..の仕組みを教えてください。

投稿いただきありがとうございます。

1
NotAdmin Dave

備考：time curl -vvv site1.dev/を使用すると、より詳細なタイミング情報を取得できます。

サーバーの応答にはConnection: keep-aliveが含まれていることに注意してください。これは、サーバーが HTTP keep-alive を使用するように構成されていることを意味します。

HTTPキープアライブまたはHTTP接続の再利用とも呼ばれるHTTP永続接続は、単一のTCP接続を使用して複数のHTTP要求/応答を送受信するのではなく、新しいすべての単一の要求/応答ペアに対する接続新しいHTTP/2プロトコルは同じ考え方を使用しており、複数の同時要求/応答を単一の接続で多重化できるようにします。

したがって、サーバーはより多くの要求を処理することを想定して接続を開いたままにします。このようにして、ブラウザは同じTCP接続を使用してHTMLページを受信し、新しい接続を確立する必要なくリンクされた画像をすぐに要求できます。

curl.1 man page はパラメータ--no-keepaliveを指定します：

TCP接続でのキープアライブメッセージの使用を無効にします。デフォルトではcurlが有効になっているためです。

NginxサーバーModule ngx_http_core_module keepalive_timeout も同様にパラメーター化できます。

Syntax:   keepalive_timeout timeout [header_timeout];
Default:  keepalive_timeout 75s;
Context:  http, server, location

最初のパラメーターは、キープアライブクライアント接続がサーバー側で開いたままになるタイムアウトを設定します。ゼロの値は、キープアライブクライアント接続を無効にします。オプションの2番目のパラメーターは、「Keep-Alive：timeout = time」応答ヘッダーフィールドに値を設定します。 2つのパラメーターが異なる場合があります。

「Keep-Alive：timeout = time」ヘッダーフィールドは、MozillaおよびKonquerorによって認識されます。 MSIEは、約60秒でキープアライブ接続を自動的に閉じます。

1
harrymc