ERR_CONNECTION_TIMED_OUT: de server antwoordt niet op tijd

Wat de fout betekent

De browser heeft de naam opgezocht, een verbindingsverzoek naar poort 443 (of 80) gestuurd en gewacht. Er kwam niets terug: geen antwoord en geen weigering. Na een tijdje geeft Chrome het op en toont ERR_CONNECTION_TIMED_OUT onder “Deze site is niet bereikbaar”; Firefox zegt “De verbinding is verlopen”. Het verschil met ERR_CONNECTION_REFUSED is belangrijk: bij een geweigerde verbinding antwoordt de server actief “hier is niets”; bij een time-out antwoordt niemand. Geweigerd: de machine draait, de webserver niet. Time-out: de pakketten gaan onderweg verloren of de machine komt niet aan antwoorden toe. Breekt de verbinding pas af nadat die tot stand kwam? Dan is het een ERR_CONNECTION_RESET.

Veelvoorkomende oorzaken

1. Een firewall laat pakketten vallen. ufw, firewalld, iptables of de security group van de cloudaanbieder gebruikt drop in plaats van reject: het pakket verdwijnt geruisloos en de browser wacht voor niets. Typisch na een nieuwe server of een wijziging van regels.
2. De server of de dienst zit vast of is overvol. De machine antwoordt op ping, maar nginx, Apache of PHP-FPM heeft alle verbindingen bezet of het geheugen is op. Nieuwe verbindingen blijven in de wachtrij tot de browser opgeeft.
3. Verkeerd IP-adres in het DNS. Na een serververhuizing wijst het A-record nog naar de oude machine, die inmiddels uit staat: de naam wordt gevonden, maar daar antwoordt niemand.
4. Het netwerk van de bezoeker. Een router die de bestemming blokkeert, een weggevallen VPN, een bedrijfsproxy, een contentfilter of een provider met routeringsproblemen.
5. MTU of IPv6. Het domein heeft een AAAA-record, maar de server antwoordt niet via IPv6; of een tunnel verkleint de maximale pakketgrootte en TLS-verbindingen blijven halverwege steken.

Als je bezoeker bent

1. Open de site op je telefoon zonder wifi. Kom je zo wel binnen, dan zit het probleem in je netwerk, niet in de site.
2. Verbreek de VPN en schakel een handmatige proxy uit die je niet gebruikt.
3. Herstart de router en leeg de DNS-cache (ipconfig /flushdns op Windows, sudo dscacheutil -flushcache op macOS, sudo resolvectl flush-caches op Linux).
4. Probeer een incognitovenster en een andere browser.
5. Antwoordt de site ook niet vanaf een ander netwerk en een ander apparaat, dan kan alleen de eigenaar het oplossen.

Als het je eigen site is: eerst controleren

Open de Website down checker: antwoordt de server ook niet vanaf onze locatie in Europa, dan zit de storing niet in je netwerk. Daarna vanaf de opdrachtregel:

# naar welk adres wijst het domein?
dig +short example.com A
dig +short example.com AAAA

# antwoordt de server? (-v toont bij welke stap het stokt)
curl -v --max-time 10 -4 https://example.com/
curl -v --max-time 10 -6 https://example.com/

Komt curl -4 binnen en blijft curl -6 hangen, dan is IPv6 het probleem. Stopt curl bij “Trying 203.0.113.10:443…”, dan gaan de pakketten verloren voordat ze de webserver bereiken. Log in via SSH (antwoordt ook dat niet, ga dan naar het deel over de hostingprovider):

# wie luistert er op 80 en 443, en op welk adres?
sudo ss -tlnp | grep -E ':80 |:443 '

# firewallregels
sudo ufw status verbose

# belasting, geheugen, schijf
uptime
free -h
df -h

Oplossingen op je eigen server

1. De firewall openen

# ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

Op een cloudserver controleer je ook de security group van de aanbieder: die blokkeert voordat het pakket je machine bereikt en is van binnenuit onzichtbaar. Gebruik je fail2ban, controleer dan of hij niet je eigen IP-adres heeft geblokkeerd.

2. Een overvolle server lucht geven

Toont uptime een belasting ver boven het aantal cores, of free -h een leeg geheugen, dan neemt de server verbindingen te traag aan. Zoek het schuldige proces met top en lees het log van PHP-FPM: server reached pm.max_children betekent dat alle workers bezet zijn, vaak door een trage query of een golf bots. Herstart de betrokken dienst nadat je zijn configuratie hebt gecontroleerd:

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

Herhaalt het zich elke dag, verhoog dan het aantal workers als het geheugen het toelaat, zet een cache voor de applicatie en blokkeer nutteloze bots.

3. Het IP-adres in het DNS corrigeren

Vergelijk dig +short example.com A met hostname -I op de server. Komen ze niet overeen, corrigeer dan het A-record bij je DNS-aanbieder. Heeft de server geen publiek IPv6-adres, verwijder dan het AAAA-record: een AAAA zonder server erachter geeft precies deze fout voor een deel van de bezoekers.

4. Op alle adressen luisteren

In nginx heeft het server-blok listen 443 ssl; en listen [::]:443 ssl; nodig. Luistert hij alleen op 127.0.0.1, dan antwoordt er van buitenaf niemand. Na de wijziging: sudo nginx -t && sudo systemctl reload nginx.

Als het probleem bij je hostingprovider ligt

Op shared hosting heb je geen controle over de firewall of de belasting. Antwoordt de site niet van buitenaf en SSH evenmin, stuur dan dit bericht:

Goedemorgen, mijn website example.com antwoordt sinds ongeveer 9:30 uur (UTC) niet meer: browsers tonen ERR_CONNECTION_TIMED_OUT en poort 443 reageert niet. Het domein wijst naar 203.0.113.10, het IP-adres van mijn hosting. Ik heb zelf niets gewijzigd. Is de server van die machine overbelast of gestopt, of blokkeert een firewall de verbinding?

Zodat het niet opnieuw gebeurt

Een server die zwijgt is het geval waarbij de eigenaar het het laatst merkt: geen foutpagina, alleen stilte. Een controle van buitenaf merkt het bij de eerste mislukte poging. Op je eigen server waarschuwt de server monitoring met serveragent je eerder: als de belasting oploopt, het geheugen opraakt of de schijf volloopt.

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