Curlエラー52サーバーからの空の応答
あるサーバーでcronジョブをセットアップして、別のサーバーでホストされているPHPでバックアップスクリプトを実行しています。私が使用しているコマンドは次のような形式です。
curl -sS http://www.example.com/backup.php
最近、Cronの実行時にこのエラーが発生しました
curl: (52) Empty reply from server
これが何を意味するのか分かりません。ブラウザで直接リンクに移動すると、スクリプトが正常に実行され、小さなバックアップZipファイルが取得されます。
誰でもそれに関する情報を提供できますか？
これは、curlがHTTPSを実行するサーバーでプレーンHTTPを実行するように要求された場合に発生する可能性があります。
例：
$ curl http://google.com:443
curl: (52) Empty reply from server
Curlは、HTTPがリクエストに何も応答しないというエラーであるため、サーバーからの応答がない場合にこのエラーを返します。
あなたが抱えている問題は、あなたと問題のホストとの間に、ファイアウォールやプロキシなどのネットワークインフラストラクチャの一部があるということです。したがって、これを機能させるには、そのハードウェアの責任者と問題を議論する必要があります。
空の応答のもう1つの一般的な理由は、タイムアウトです。 cronジョブが実行されている場所からPHP /ターゲットサーバーへのすべてのホップを確認します。おそらく、デバイス/サーバー/ nginx/LB /プロキシが、予想よりも早くリクエストを終了する行に沿ってどこかに存在し、結果として空のレスポンスになります。
CPUまたはメモリの使用率が100％であるためにサーバーが応答しない場合に発生する可能性があります。
Sonarqube APIにアクセスしようとして、メモリ使用率がフルであるためにサーバーが応答しなかったときに、このエラーが発生しました
私の場合、サーバーのリダイレクトでした。 curl -Lは私の問題を解決しました。
SSL接続の場合、これはcurlおよびSafariリクエスト中にセグメンテーション違反を起こすnginxサーバーの古いバージョンの問題が原因である可能性があります。 このバグ はnginxのバージョン1.10付近で修正されましたが、インターネット上にはnginxの古いバージョンがまだたくさんあります。
Nginx管理者の場合：ssl_session_cache shared:SSL:1m;をhttpブロックに追加すると問題が解決するはずです。
OPが非SSLケースを要求していることは承知していますが、これは「サーバーからの空の応答」問題のトップページであるため、SSLの回答はここに残しますこの問題で私の頭を壁にぶつけていた多くの人の一人でした。
私の場合、これはPHP APCの問題が原因でした。最初に確認する場所は、Apacheエラーログです（Apacheを使用している場合）。
これが誰かを助けることを願っています。
私は前にこの問題を経験したことがあります。同じポート（3000）を使用する別のアプリケーションがあることがわかりました。
これを見つける簡単な方法：
ターミナルで、netstat -a -p TCP -n | grep 3000と入力します（「3000」に使用しているポートを置き換えます）。複数のリッスンがある場合、他の何かがすでにそのポートを占有しています。そのプロセスを停止するか、新しいプロセスのポートを変更する必要があります。
あなたはこのcurl -sS " http://www.example.com/backup.php "を試すことができますURLを「」に入れると、サーバーへのリクエストが完了するか、ヘッダーリクエストが完了すると仮定します。
Httpsのような安全なWebサイトにアクセスしようとすると発生します。
「s」を見逃したことを願っています
URLをcurl -sS -u "username：password"に変更してみてください https://www.example.com/backup.php
私の場合（curl 7.47.0）、これは、curlコマンドのヘッダーcontent-lengthにpostmanによって計算された値を手動で設定したためです（postmanを使用してcurlコマンドパラメーターを生成し、シェルにコピーします）。ヘッダーcontent-lengthを削除すると、正常に機能します。
私の場合、私はuwsgiを使用して、60秒以上http-timeoutプロパティを追加しましたが、いくつかの余分なスペースと設定ファイルが適切にロードされなかったために機能しませんでした。
試してみてください this -> cURLを経由する代わりに、Telnetでアクセスしようとしているサイトにpingを試してください。接続試行が返す応答は、cURLが接続しようとしたときに表示されるものとまったく同じになります（ただし、ユーザーからの助けにはなりません）。ここで、表示内容に応じて、いくつかの結論のうちの1つを引き出すことができます。
名前ベースの仮想ホストであるWebサイトに接続しようとしています。つまり、IPアドレス経由でアクセスできません。ホスト名に問題があります。入力ミスがある可能性があります。パラメーターにPOSTの代わりにGETを使用すると、より具体的な答えが得られることに注意してください。
この問題は、100-continueヘッダーに関連付けられている場合もあります。 curl_getinfo($ch, CURLINFO_HTTP_CODE)を実行してみて、結果を確認してください。