ERR_EMPTY_RESPONSE: oorzaken en oplossingen
ERR_EMPTY_RESPONSE betekent dat de verbinding werd geaccepteerd maar de server nul bytes terugstuurde, in plaats van een echt HTTP-antwoord of zelfs een foutpagina. De TCP-handshake lukte; wat het verzoek had moeten beantwoorden deed dat nooit.
Wat ERR_EMPTY_RESPONSE betekent
Deze fout zit later in de levenscyclus van het verzoek dan een geweigerde of getimede verbinding. De browser maakt succesvol verbinding met de server, en bij een HTTPS-verzoek wordt meestal ook de TLS-handshake afgerond, maar nadat het verzoek is verstuurd sluit de verbinding zonder HTTP-statusregel, zonder headers, en zonder body. Dat verschilt van een 500- of 502-foutpagina, die nog steeds een compleet HTTP-antwoord is; hier valt er niets te parseren omdat er niets terugkwam.
Dit maakt ERR_EMPTY_RESPONSE lastiger te diagnosticeren vanaf de clientkant dan de meeste verbindingsfouten, aangezien elke laag tot en met de transportverbinding correct werkte. De fout zit specifiek bij wat het HTTP-antwoord genereert: het applicatieproces, het framework dat het verzoek afhandelt, of een proxy ervoor die de socket sloot in plaats van een goede foutpagina door te geven of te genereren.
Hoe de fout verschijnt
Chrome toont "This site can't be reached ... ERR_EMPTY_RESPONSE" zodra de verbinding sluit zonder data. curl rapporteert dezelfde situatie in duidelijke bewoordingen:
curl -v https://example.com/api/generate
* Connected to example.com (203.0.113.10) port 443
> GET /api/generate HTTP/1.1
> Host: example.com
*
* Empty reply from server
curl: (52) Empty reply from server
"Empty reply from server" is de exacte bewoording van curl voor deze situatie, en het is het duidelijkste signaal dat de verbinding zelf werkte terwijl wat een antwoord had moeten genereren dat niet deed.
Wat ERR_EMPTY_RESPONSE veroorzaakt
- Een workerproces crashte tijdens het afhandelen van het verzoek. Een onafgehandelde uitzondering, een out-of-memory kill, of een segmentation fault kunnen de verbinding sluiten voordat er enig antwoord is geschreven.
- De applicatie kreeg een timeout achter een proxy die stilzwijgend sluit. Sommige reverse-proxyconfiguraties sluiten de clientverbinding zonder een foutpagina te sturen wanneer de backend te lang duurt, in plaats van een echte 502 of 504 terug te geven.
- Platte HTTP wordt geserveerd op de HTTPS-poort, of andersom. Een client die TLS spreekt tegen een poort die platte HTTP serveert, of andersom, krijgt geen geldig antwoord dat de protocollaag van de client kan parseren, en dit komt vaak naar boven als een leeg antwoord in plaats van een duidelijke protocolfout.
- Een browserextensie of lokale proxy verstoort het antwoord. Adblockers, privacy-extensies, of een bedrijfsproxy die een antwoord inspecteert en soms verkeerd afhandelt, kunnen het terugbrengen tot niets.
- Een healthcheck van een loadbalancer markeert de backend als ongezond midden in het verzoek, waarbij de verbinding met die backend wordt gesloten voordat het antwoord klaar is.
Hoe u vaststelt wiens fout het is
Schakel eerst browserextensies uit of probeer een incognitovenster; een client-side extensie is een van de vaker voorkomende en makkelijkst uit te sluiten oorzaken. Houdt het lege antwoord aan met extensies uit, test dan vanaf een tweede apparaat of netwerk om een lokale proxy uit te sluiten. Gebeurt het consequent vanaf meerdere externe locaties, dan is de server of een applicatiecrash de oorzaak. Een HTTP-controle vanaf meerdere meetpunten tegelijk bevestigt of het lege antwoord overal optreedt of gebonden is aan één client, extensie, of netwerk.
Hoe u ERR_EMPTY_RESPONSE oplost
Bent u de bezoeker
- Probeer een incognito- of privévenster met extensies uitgeschakeld om een adblocker of privacy-extensie uit te sluiten die het antwoord verstoort.
- Schakel elke lokale proxy of VPN uit en probeer opnieuw, aangezien sommige antwoorden onderscheppen en soms verkeerd afhandelen in plaats van door te laten.
- Wis de browsercache voor de site; een gecachete, beschadigde verbindingsstatus kan af en toe als deze fout terugkeren bij een nieuwe poging.
- Wacht en laad opnieuw. Is de oorzaak een gecrasht workerproces op de server, dan herstart een procesbeheerder het doorgaans binnen enkele seconden.
Beheert u de site
- Controleer applicatielogs op een crash op hetzelfde tijdstip als het mislukte verzoek; een onafgehandelde uitzondering of een out-of-memory kill is de meest voorkomende oorzaak en laat meestal een duidelijk spoor achter.
- Bevestig dat het juiste protocol aan elke poort gebonden is. Verifieer dat poort 443 daadwerkelijk TLS serveert en poort 80 platte HTTP, niet andersom, met een directe controle:
curl -v https://example.com:443/ curl -v http://example.com:80/ - Bekijk het timeoutgedrag van de reverse proxy. Op nginx zou een backend die
proxy_read_timeoutoverschrijdt nog steeds een 504 moeten teruggeven, dus een leeg antwoord in plaats van een echte foutpagina betekent meestal dat iets lager in de stack de verbinding sluit. - Controleer logs van loadbalancer en healthchecks op een backend die rond het moment van de storing als ongezond werd gemarkeerd, wat lopende verbindingen naar die instantie kan sluiten.
- Herstart de betrokken worker of dienst als een crash is bevestigd, en houd de logs nauwlettend in de gaten na de herstart voor een herhaling van dezelfde fout.
Hoe u ERR_EMPTY_RESPONSE voorkomt
Een workercrash onder specifieke omstandigheden, zoals een bepaalde requestpayload of een geheugenpiek, kan onregelmatig genoeg zijn om een handmatige test te doorstaan terwijl hij toch volgens een patroon faalt voor echte bezoekers. Doorlopende HTTP-monitoring die de statuscode en de responsbody op regelmatige intervallen controleert vanaf 300+ meetpunten in 158 steden vangt een patroon van lege antwoorden op dat een enkele handmatige controle waarschijnlijk zou missen, met meldingen via e-mail, sms, spraakoproep, Slack, Telegram en meer.
Gerelateerde fouten
- ERR_CONNECTION_RESET beëindigt ook een werkende verbinding vroegtijdig, maar met een expliciete reset in plaats van een stille sluiting.
- 502 Bad Gateway is een echt HTTP-foutantwoord van een proxy, anders dan het lege antwoord dat deze fout beschrijft.
- This site can't be reached behandelt de volledige verzameling verbindingsfouten die Chrome onder één kop groepeert.
Veelgestelde vragen
Is ERR_EMPTY_RESPONSE hetzelfde als een 502-fout?
Nee. Een 502 is een compleet HTTP-antwoord met een statusregel, headers, en meestal een body, opzettelijk verstuurd door een proxy. ERR_EMPTY_RESPONSE betekent dat er helemaal geen HTTP-antwoord werd verstuurd, alleen een gesloten verbinding.
Waarom gebeurt dit alleen op één specifieke pagina?
Een pagina die deze fout consequent veroorzaakt, terwijl andere prima laden, wijst meestal op een crash in het codepad dat die specifieke pagina of API-endpoint gebruikt, in plaats van een algemeen server- of netwerkprobleem.
Kan een adblocker deze fout echt veroorzaken?
Ja. Sommige adblockers en privacy-extensies onderscheppen en herschrijven antwoorden, en een bug of een agressieve regel kan af en toe een legitiem antwoord terugbrengen tot niets in plaats van het netjes te blokkeren.
Betekent ERR_EMPTY_RESPONSE dat mijn data verloren is gegaan?
Niet per se bij een GET-verzoek, maar controleer bij een formulierinzending of een API-aanroep die data wijzigt of de actie daadwerkelijk voltooid is op de server voordat u opnieuw probeert, aangezien de client aan een leeg antwoord niet kan zien of het verzoek is verwerkt.
Waarom zegt curl "Empty reply from server" in plaats van een foutcode?
Omdat er geen HTTP-antwoord is om een statuscode uit te lezen. De eigen bewoording van curl beschrijft de gebeurtenis op transportniveau, een gesloten verbinding zonder data, wat één laag onder het HTTP-protocol zelf ligt.
Kan mijn eigen netwerk de verbinding sluiten in plaats van de server?
Het komt minder vaak voor dan een oorzaak aan de serverkant, maar het gebeurt wel. Een bedrijfsproxy of firewall die langlopende verbindingen beëindigt na een vaste inactieve periode kan hetzelfde symptoom opleveren; hetzelfde verzoek testen vanaf een ander netwerk sluit dit snel uit.