Curl-Fehler 52 Leere Antwort vom Server

Ich habe einen Cron-Job auf einem Server eingerichtet, um ein Sicherungsskript in PHP auszuführen, das auf einem anderen Server gehostet wird. Der Befehl, den ich verwendet habe, ist wie folgt formatiert:

curl -sS http://www.example.com/backup.php

In letzter Zeit habe ich diesen Fehler erhalten, wenn der Cron läuft

curl: (52) Empty reply from server

Ich habe keine Ahnung, was das bedeutet. Wenn ich direkt in meinem Browser auf den Link gehe, läuft das Skript einwandfrei und ich erhalte meine kleine Backup-Zip-Datei.

Kann jemand irgendwelche Informationen darüber geben?

Dies kann passieren, wenn curl aufgefordert wird, einfaches HTTP auf einem Server auszuführen, der HTTPS ausführt.

Beispiel:

$ curl http://google.com:443
curl: (52) Empty reply from server

Curl gibt diesen Fehler aus, wenn keine Antwort von einem Server erfolgt, da es ein Fehler für HTTP ist, auf eine Anfrage nichts zu antworten.

Ich vermute, das Problem, das Sie haben, besteht darin, dass sich zwischen Ihnen und dem betreffenden Host eine Netzwerkinfrastruktur wie eine Firewall oder ein Proxy befindet. Damit dies funktioniert, müssen Sie das Problem daher mit den für diese Hardware verantwortlichen Personen besprechen.

In meinem Fall war es eine Serverumleitung; curl -Llöste mein Problem.

Dies kann passieren, wenn der Server aufgrund einer 100% igen CPU- oder Speicherauslastung nicht reagiert.

Ich habe diesen Fehler erhalten, als ich versucht habe, auf die Sonarqube-API zuzugreifen, und der Server aufgrund der vollen Speicherauslastung nicht reagiert hat

Ein weiterer häufiger Grund für eine leere Antwort ist das Timeout. Überprüfen Sie alle Hops, von denen aus der Cron-Job ausgeführt wird, auf Ihren PHP / Zielserver. Es gibt wahrscheinlich irgendwo auf der Linie ein Gerät / einen Server / nginx / LB / einen Proxy, der die Anforderung früher als erwartet beendet, was zu einer leeren Antwort führt.

Bei SSL-Verbindungen kann dies durch Probleme in älteren Versionen des Nginx-Servers verursacht werden, die bei Curl- und Safari-Anforderungen fehlerhaft auftreten. Dieser Fehler wurde um Version 1.10 von Nginx behoben, aber es gibt immer noch viele ältere Versionen von Nginx im Internet.

Für Nginx-Administratoren: Hinzufügen ssl_session_cache shared:SSL:1m;zuhttp Block sollte das Problem lösen.

Ich bin mir bewusst, dass OP nach einem Nicht-SSL-Fall gefragt hat, aber da dies die oberste Seite in goole für das Problem "Leere Antwort vom Server" ist, lasse ich die SSL-Antwort hier, da ich einer von vielen war, die mir den Kopf geschlagen haben gegen die Wand mit diesem Problem.

In meinem Fall wurde dies durch ein PHP-APC-Problem verursacht. Der erste Ort, an dem Sie nachsehen müssen, sind die Apache-Fehlerprotokolle (wenn Sie Apache verwenden).

Hoffe das hilft jemandem.

Sie können diese Locke -sS " http://www.example.com/backup.php " ausprobieren, indem Sie Ihre URL in "" eingeben , was für mich funktioniert hat. Ich kenne den genauen Grund nicht, aber ich nehme an, dass Sie die URL in ". "Vervollständigt die Anforderung an den Server oder schließt nur die Header-Anforderung ab.

Ich hatte dieses Problem schon einmal. Ich fand heraus, dass ich eine andere Anwendung hatte, die denselben Port (3000) verwendete.

Einfacher Weg, dies herauszufinden:

Geben Sie im Terminal Folgendes ein netstat -a -p TCP -n | grep 3000(ersetzen Sie den '3000' durch den von Ihnen verwendeten Port). Wenn mehr als eine Person lauscht, belegt bereits etwas anderes diesen Port. Sie sollten diesen Prozess stoppen oder den Port für Ihren neuen Prozess ändern.

In meinem Fall (Curl 7.47.0) habe ich den Header content-lengthfür den Curl-Befehl manuell mit einem Wert festgelegt, der vom Postboten berechnet wird (ich habe den Postboten verwendet, um Curl-Befehlsparameter zu generieren und sie in die Shell zu kopieren). Nachdem ich den Header gelöscht habe content-length, funktioniert es normal.

Dieser Fehler kann auch auftreten, wenn der Server die Daten verarbeitet. Es passiert mir normalerweise, wenn ich einige Dateien auf REST-API-Websites poste, die viele Einträge enthalten und lange für die Erstellung und Rückgabe von Datensätzen benötigen

Versuchen Sie dies -> Statt durch cURL, versuchen Sie die Seite Pingen Sie versuchen , mit Telnet zu erreichen. Die Antwort, die Ihr Verbindungsversuch zurückgibt, ist genau die, die cURL sieht, wenn es versucht, eine Verbindung herzustellen (die es jedoch nicht hilfreich von Ihnen verschleiert). Je nachdem, was Sie hier sehen, können Sie nun eine von mehreren Schlussfolgerungen ziehen:

Sie versuchen, eine Verbindung zu einer Website herzustellen, bei der es sich um einen namensbasierten virtuellen Host handelt. Dies bedeutet, dass diese nicht über die IP-Adresse erreichbar ist. Mit dem Hostnamen ist ein Fehler aufgetreten - möglicherweise haben Sie etwas falsch geschrieben. Beachten Sie, dass Sie durch die Verwendung von GET anstelle von POST für Parameter eine konkretere Antwort erhalten.

Das Problem kann auch mit dem 100-Continue-Header verbunden sein. Versuchen Sie es curl_getinfo($ch, CURLINFO_HTTP_CODE)und führen Sie das Ergebnis aus.

Mein Fall war auf das Ablaufen des SSL-Zertifikats zurückzuführen

Dies passiert, wenn Sie versuchen, auf eine sichere Website wie Https zuzugreifen.

Ich hoffe du hast 's' verpasst

Versuchen Sie, die URL in curl -sS -u "Benutzername: Passwort" zu ändern. Https://www.example.com/backup.php

In meinem Fall habe ich uwsgi verwendet und die Eigenschaft http-timeout für mehr als 60 Sekunden hinzugefügt, aber es funktionierte nicht, da zusätzlicher Speicherplatz vorhanden war und die Konfigurationsdatei nicht richtig geladen wurde.

Ich hatte dieses Problem und habe übersehen, dass http für sichere Verbindungen verwendet wird. Ersetzen Sie http durch https und es sollte gut funktionieren.

curl -sS https://www.example.com/backup.php