Ik heb een cronjob-configuratie op de ene server om een back-upscript in PHP uit te voeren dat op een andere server wordt gehost.
Het commando dat ik heb gebruikt is
curl -sS http://www.example.com/backup.php
De laatste tijd krijg ik deze foutmelding wanneer de Cron wordt uitgevoerd:
curl: (52) Empty reply from server
Als ik rechtstreeks naar de link in mijn browser ga, werkt het script prima en krijg ik mijn kleine back-up ZIP-bestand.
Antwoord 1, autoriteit 100%
Dit kan gebeuren als curl wordt gevraagd om gewone HTTP uit te voeren op een server die HTTPS gebruikt.
Voorbeeld:
$ curl http://google.com:443
curl: (52) Empty reply from server
Antwoord 2, autoriteit 55%
Curl geeft deze fout wanneer er geen antwoord is van een server, aangezien het een fout is voor HTTP om niets op een verzoek te reageren.
Ik vermoed dat het probleem dat je hebt is dat er een stukje netwerkinfrastructuur is, zoals een firewall of een proxy, tussen jou en de betreffende host. Om dit te laten werken, moet u het probleem daarom bespreken met de mensen die verantwoordelijk zijn voor die hardware.
Antwoord 3, autoriteit 12%
Het kan gebeuren wanneer de server niet reageert vanwege 100% CPU- of geheugengebruik.
Ik kreeg deze foutmelding toen ik probeerde toegang te krijgen tot de sonarqube API en de server reageerde niet vanwege het volledige geheugengebruik
Antwoord 4, autoriteit 10%
In mijn geval was het serveromleiding; curl -L heeft mijn probleem opgelost.
Antwoord 5, autoriteit 9%
Een andere veelvoorkomende reden voor een leeg antwoord is een time-out. Controleer alle hops van waaruit de cron-taak wordt uitgevoerd naar uw PHP/doelserver. Er is waarschijnlijk ergens langs de lijn een apparaat/server/nginx/LB/proxy die het verzoek eerder beëindigt dan u had verwacht, wat resulteert in een lege reactie.
Antwoord 6, autoriteit 6%
In het geval van SSL-verbindingen kan dit worden veroorzaakt door een probleem in oudere versies van de nginx-server die seg-fault tijdens curl- en Safari-verzoeken. Deze bug is verholpen rond versie 1.10 van nginx, maar er zijn nog veel oudere versies van nginx op internet.
Voor nginx-beheerders: het toevoegen van ssl_session_cache shared:SSL:1m; aan het http-blok zou het probleem moeten oplossen.
Ik ben me ervan bewust dat OP om een niet-SSL-zaak vroeg, maar aangezien dit de bovenste pagina in goole is voor het probleem “leeg antwoord van server”, laat ik het SSL-antwoord hier achter omdat ik een van de velen die met dit probleem mijn hoofd tegen de muur sloegen.
Antwoord 7, autoriteit 5%
In mijn geval werd dit veroorzaakt door een PHP APC-probleem. De eerste plaats om te zoeken zijn de Apache-foutlogboeken (als u Apache gebruikt).
Ik hoop dat dit iemand helpt.
Antwoord 8, autoriteit 3%
deze fout kan ook optreden als de server de gegevens verwerkt.
Het overkomt me meestal wanneer ik een aantal bestanden post op REST API-websites die veel vermeldingen hebben en het lang duurt voordat de records worden gemaakt en geretourneerd
Antwoord 9, autoriteit 3%
Ik kwam deze fout sporadisch tegen en begreep het niet. Googlen heeft niet geholpen.
Ik ben er eindelijk achter gekomen. Ik gebruik een paar docker-containers, waaronder NGINX en Apache. Het voorliggende commando adresseert een specifieke container, met Apache. Het bleek dat ik ook een cron-klus heb waarbij ik soms zwaar werk doe op dezelfde container. Afhankelijk van de belasting die deze cron-job op deze container plaatst, was het niet in staat om mijn opdracht tijdig te beantwoorden, wat resulteerde in error 52 empty reply from server of zelfs 502 Bad Gateway.
Ik ontdekte en verifieerde dit met gewone curl toen ik merkte dat het proces dat ik onderzocht minder dan 2 seconden duurde en plotseling kreeg ik een 52-fout en vervolgens een 502-fout en dan weer minder dan 2 seconden – dus het was zeker niet mijn code die ongewijzigd was. Met behulp van ps aux in de container zag ik het andere proces lopen en begreep ik het.
Eigenlijk had ik last van 502 Bad Gateway van NGINX met langlopende taken en kon het niet repareren met de juiste parameters, dus gaf ik het uiteindelijk op en veranderde deze dingen naar Apache. Daarom was ik nog meer verbaasd over deze fouten.
De remedie is eenvoudig. Ik heb zojuist nog enkele exemplaren van deze container gestart met docker service scale en dat was het dan. docker laadt op zichzelf.
Nou, er is meer aan de hand, zoals een ander voorbeeld liet zien. Deze keer deed ik wat repetitieve klussen.
Ik kwam erachter dat ik na een tijdje geen geheugen meer had dat door PHP werd gebruikt en dat niet kan worden teruggevorderd, dus het proces stierf.
Waarom? Met meer dan een dozijn containers op een 8 GB RAM-machine, dacht ik aanvankelijk dat het een goed idee zou zijn om het RAM-gebruik op PHP-containers te beperken tot 50 MB.
Stom! Ik was het vergeten, maar swarmpit gaf me een hint. Ik roep ini_set("memory_limit",-1); aan in de constructor van mijn klas, maar dat ging maar tot die 50 MB.
Dus ik heb die beperkingen uit mijn opstelbestand verwijderd. Nu kunnen die containers tot 8 GB gebruiken. Het proces draait nu al uren met Apache en het lijkt erop dat het probleem is opgelost, het geheugengebruik stijgt tot ruim boven de 100 MB.
Nog een waarschuwing: om foutopsporingsberichten gemakkelijk te krijgen en te lezen, begon ik het proces in Opera onder Windows. Dat is prima met fouten die snel verschijnen.
Als er echter voor de laatste wordt gezorgd, loopt het proces natuurlijk door en loopt het geheugengebruik in de browser op, waardoor mijn lokale machine uiteindelijk onbruikbaar wordt. Dus als dat gebeurt, sluit dit tabblad dan af en het proces blijft goed doorgaan.
Antwoord 10
je kunt deze curl proberen -sS “http://www.example.com/backup.php”
door uw URL in “” te plaatsen die voor mij werkte, weet ik de exacte reden niet, maar ik veronderstel dat het plaatsen van de url in “” het verzoek aan de server voltooit of alleen het headerverzoek voltooit.
Antwoord 11
Ik heb dit probleem eerder gehad. Ik kwam erachter dat ik een andere applicatie had die dezelfde poort gebruikte (3000).
Eenvoudige manier om hier achter te komen:
Typ in de terminal netstat -a -p TCP -n | grep 3000 (vervang de poort die je gebruikt voor de ‘3000’). Als er meer dan één luistert, bezet iets anders die poort al. U moet dat proces stoppen of de poort voor uw nieuwe proces wijzigen.
Antwoord 12
In mijn geval (curl 7.47.0), is dat omdat ik de header content-length op curl-commando handmatig heb ingesteld met een waarde die wordt berekend door postbode (ik gebruikte postbode om curl-commando te genereren parameters en kopieer ze naar shell). Nadat ik header content-length heb verwijderd, werkt het normaal.
Antwoord 13
De vraag is naar mijn mening heel open. Ik zal precies vertellen wat ik probeerde te bereiken en hoe ik het probleem heb opgelost
Context
Java-app draait op poorten 8999 en 8990. App wordt uitgevoerd als een docker-compose-stack in een AWS EC2 Ubuntu 20-server.
Ik heb een Network Load Balancer toegevoegd die verkeer moet ontvangen op TLS-poort 443 onder een AWS ACM-certificaat. Het doorstuurmechanisme moet als volgt zijn
- poort TLS 443 van NLB –> TCP-poort 8990 in de EC2-instantie
- poort TCP 22 van NLB –> TCP-poort 8999 in de EC2-instantie
Ik kreeg de fout van de curl CLI
Oplossing
Ik realiseerde me dat er een privé AWS VPC is die het verkeer afhandelt. De AWS EC2-instantie wordt uitgevoerd in een privésubnet. De AWS EC2-instantie had beveiligingsgroepsregels die het verkeer blokkeerden. De oplossing was om al het verkeer 0.0.0.0/0 naar de EC2-instantie te openen op poorten 8990 en 8999
Binnen AWS Load balancers zag ik mijn doelgroepen met gezonde controles en na wat reboots van de client en het wissen van de DNS-cache kon ik via HTTPS toegang krijgen tot de applicatie.
Antwoord 14
Probeer dit -> Probeer in plaats van via cURL te gaan de site die u probeert te bereiken met Telnet te pingen. Het antwoord dat uw verbindingspoging retourneert, is precies wat cURL ziet wanneer het verbinding probeert te maken (maar dat het u op een nutteloze manier verdoezelt). Afhankelijk van wat u hier ziet, kunt u een van de volgende conclusies trekken:
U probeert verbinding te maken met een website die een op naam gebaseerde virtuele host is, wat betekent dat deze niet bereikbaar is via een IP-adres. Er is iets misgegaan met de hostnaam. Mogelijk hebt u iets verkeerd getypt. Merk op dat het gebruik van GET in plaats van POST voor parameters u een meer concreet antwoord zal geven.
Het probleem kan ook te maken hebben met de kop 100-continue. Probeer curl_getinfo($ch, CURLINFO_HTTP_CODE) uit te voeren en controleer het resultaat.
Antwoord 15
Mijn geval was te wijten aan het verlopen van het SSL-certificaat
Antwoord 16
In mijn geval gebruikte ik uwsgi, voegde de eigenschap http-timeout toe voor meer dan 60 seconden, maar het werkte niet vanwege wat extra ruimte en het configuratiebestand werd niet goed geladen.
Antwoord 17
Het gebeurt wanneer u probeert toegang te krijgen tot een beveiligde website zoals HTTPS.
Ik hoop dat je ‘s’ hebt gemist
Probeer de URL te wijzigen in curl -sS -u “gebruikersnaam:wachtwoord” https://www.example. com/backup.php