ERR_CONNECTION_RESET: waarom de verbinding halverwege wegvalt

Wat de fout betekent

Anders dan bij een geweigerde verbinding of een time-out is de verbinding wél tot stand gekomen. De browser heeft zijn verzoek verstuurd, of was zelfs al een antwoord aan het ontvangen, en toen stuurde de andere kant een TCP-resetpakket: “stop, deze verbinding bestaat niet meer”. Chrome toont ERR_CONNECTION_RESET onder “Deze site is niet bereikbaar” met de regel “De verbinding is opnieuw ingesteld”; Firefox zegt “De verbinding werd herinitialiseerd”.

Het resetpakket kan van de server komen, maar ook van alles ertussenin: een firewall, een proxy, een load balancer, de VPN of de virusscanner van de bezoeker. Daarom begin je met de vraag wie het ziet: één bezoeker, of iedereen.

Veelvoorkomende oorzaken

1. Aan de kant van de bezoeker. Een VPN of proxy die de verbinding afbreekt, een virusscanner of firewall met HTTPS-inspectie, een router met een vastgelopen NAT-tabel, een browserextensie, een bedrijfsnetwerk dat bepaalde sites of protocollen blokkeert.
2. De webserver of PHP-FPM crasht midden in het antwoord. Een PHP-worker loopt vast door een geheugenlimiet of een fatale fout, of de OOM-killer van Linux stopt het proces: de verbinding wordt zonder antwoord gesloten.
3. Een firewall, fail2ban of een rate limit stuurt resets. Een regel met reject-with tcp-reset, een jail die je IP-adres na een paar mislukte logins blokkeert, of een limiet op het aantal verbindingen per adres.
4. De TLS-configuratie breekt de handshake af. Geen gemeenschappelijke protocolversie of cipher, een verkeerd certificaat voor die naam: de server sluit de verbinding in plaats van netjes een fout te geven. Vaak alleen in oudere browsers of apps.
5. Limieten op de grootte van verzoeken. client_max_body_size in nginx of LimitRequestBody in Apache is te laag voor een upload, of post_max_size in PHP: de server breekt de verbinding af zodra de limiet overschreden is.
6. Keepalive en time-outs. De proxy ervoor houdt verbindingen langer open dan de server erachter en hergebruikt een verbinding die de server al heeft gesloten.
7. Een proxy of load balancer ervoor die de origin niet meer bereikt, of een CDN dat de verbinding om een eigen reden sluit.

Als je bezoeker bent

1. Schakel VPN en proxy uit en probeer opnieuw; probeer ook via de mobiele verbinding van je telefoon.
2. Zet de HTTPS-inspectie of “webbescherming” van je virusscanner en firewall even uit.
3. Probeer een incognitovenster zonder extensies en een andere browser.
4. Herstart de router en leeg de DNS-cache (ipconfig /flushdns op Windows, sudo dscacheutil -flushcache op macOS, sudo resolvectl flush-caches op Linux).
5. Verschijnt de fout ook vanaf een ander netwerk en apparaat, dan ligt het aan de site en kan alleen de eigenaar het oplossen.

Als het je eigen site is: eerst controleren

Open de Website down checker: wordt de verbinding ook vanaf onze locatie in Europa verbroken, dan zit de oorzaak op de server of ervoor, niet bij één bezoeker. Daarna vanaf de opdrachtregel, met -v om te zien bij welke stap het misgaat:

# bij welke stap valt de verbinding weg?
curl -v --max-time 15 https://example.com/

# gebeurt het ook met HTTP, of alleen met HTTPS?
curl -v --max-time 15 http://example.com/

# alleen bij een groot verzoek?
curl -v -X POST --data-binary @groot-bestand.bin https://example.com/upload

Zo lees je het: Connection reset by peer meteen na “Connected to” wijst op een firewall of rate limit; een reset tijdens TLS handshake op de TLS-configuratie (oorzaak 4); een reset na > POST of midden in het ontvangen van de body op een crashende dienst of een limiet (oorzaak 2 en 5). Log daarna in via SSH:

# is een dienst gecrasht of herstart?
sudo journalctl -u nginx -u php8.4-fpm -n 100 --no-pager
sudo tail -n 50 /var/log/nginx/error.log

# heeft de OOM-killer toegeslagen?
sudo dmesg -T | grep -iE "killed process|out of memory"

# blokkeert fail2ban of de firewall mijn adres?
sudo fail2ban-client status
sudo iptables -S | grep -i reset

Oplossingen op je eigen server

1. De gecrashte dienst herstellen en de oorzaak wegnemen

Staat in het log upstream prematurely closed connection of recv() failed (104: Connection reset by peer), dan is PHP-FPM (of de applicatie erachter) weggevallen. Controleer de configuratie, herstart de dienst en lees waarom hij stopte:

sudo php-fpm8.4 -t && sudo systemctl restart php8.4-fpm
sudo tail -n 50 /var/log/php8.4-fpm.log

Allowed memory size exhausted in het PHP-log: verhoog memory_limit in de pool of in php.ini voor dat ene script, of repareer de plugin die zoveel geheugen vraagt. Heeft de OOM-killer toegeslagen, dan is de machine te krap: verminder pm.max_children, zet een cache voor de applicatie of geef de server meer geheugen.

2. Firewall, fail2ban en rate limits nakijken

# jouw adres vrijgeven
sudo fail2ban-client set nginx-http-auth unbanip 203.0.113.5

# regels die resets sturen
sudo iptables -S | grep -E "REJECT|tcp-reset"
sudo ufw status numbered

Een regel die bedoeld was voor één aanvaller blokkeert soms een heel netwerk of een monitoringdienst. Zet de uitzondering op het adres of de user agent die erdoor moet, in plaats van de regel weg te halen. Op een cloudserver controleer je ook de security group van de aanbieder.

3. De TLS-configuratie breed genoeg maken

# komt de handshake tot stand, en met welke versie?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>&1 | grep -E "Protocol|Cipher|error"

Laat de server TLS 1.2 en 1.3 aanbieden met actuele ciphers (ssl_protocols TLSv1.2 TLSv1.3; in nginx, SSLProtocol -all +TLSv1.2 +TLSv1.3 in Apache) en zorg dat elke naam een server-blok met certificaat heeft. Gaat het al mis vóór het certificaat, lees dan ERR_SSL_PROTOCOL_ERROR.

4. Limieten op uploads en verzoeken verhogen

Breekt de verbinding alleen bij uploads of grote formulieren af, dan moeten de limieten in webserver en PHP bij elkaar passen:

# nginx, in het server- of location-blok
client_max_body_size 64m;

# Apache
LimitRequestBody 67108864

En in php.ini of de pool: upload_max_filesize = 64M en post_max_size = 64M. Test daarna met sudo nginx -t && sudo systemctl reload nginx.

5. Keepalive tussen proxy en server afstemmen

Staat er een reverse proxy of load balancer voor, dan moet de time-out van de server erachter langer zijn dan die van de proxy, anders hergebruikt de proxy een verbinding die al dicht is. In nginx als proxy: proxy_http_version 1.1; met proxy_set_header Connection ""; en een keepalive_timeout op de upstream die hoger is dan keepalive aan de proxykant. Bij een CDN kijk je in het paneel naar de time-outs en de status van de origin.

Als het probleem bij je hostingprovider ligt

Op shared hosting beheer je firewall, PHP-pool en TLS niet zelf. Zie je de reset ook van buitenaf en vind je in je eigen logs niets, stuur dan dit bericht:

Goedemiddag, sinds ongeveer 15:00 uur (UTC) tonen browsers ERR_CONNECTION_RESET op mijn website example.com; curl -v meldt “Connection reset by peer” direct na het opzetten van de verbinding, ook vanaf verschillende netwerken. Ik heb zelf niets gewijzigd. Kunt u nagaan of een firewallregel, een limiet of een gecrasht PHP-proces aan uw kant de verbindingen naar mijn domein afbreekt?

Zodat het niet opnieuw gebeurt

Een verbinding die wegvalt is lastig te zien: bezoekers denken dat het aan hun netwerk ligt. Een HTTP-controle van buitenaf merkt elke reset bij de eerste ronde en waarschuwt je vóór je klanten. Op je eigen server waarschuwt de server monitoring met serveragent je als PHP-FPM of nginx stopt, het geheugen opraakt of een dienst steeds opnieuw herstart.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang herstart de Quick Fix de gecrashte dienst als zijn configuratietest slaagt, tegen een vaste prijs, 24 uur per dag, ook in het weekend; de Deep Fix neemt firewall, TLS-configuratie, limieten en proxy voor zijn rekening, per blok van 15 minuten; de schatting is de bovengrens.