Ligt een website plat, controleer dan eerst of hij voor iedereen plat ligt en niet alleen voor jou. Werk daarna van buiten naar binnen: DNS, de verbinding, het TLS-certificaat, de CDN of proxy, de webserver en tot slot de applicatie en de diensten waar die van afhangt. De foutmelding die je ziet, vertelt je meestal bij welke laag je moet beginnen, en bij elke stap hieronder hoort een snelle test die die laag uitsluit of aanwijst.
Maak onderweg aantekeningen: wat je hebt gecontroleerd, hoe laat en wat je zag. Dan kun je de oplossing sneller overdragen en is de postmortem makkelijker te schrijven.
Stap 1: ligt hij plat voor iedereen, of alleen voor jou?
Plak het adres in de Is it down?-checker. Die vraagt de pagina op vanuit Stockholm (Zweden), volgt maximaal vijf redirects en telt alles onder HTTP 500 als up. Probeer de site daarna op je telefoon met wifi uit.
Werkt hij van buitenaf wel, maar bij jou niet, dan zit het probleem dicht bij jou: een VPN, een regel in je hosts-bestand, de DNS-cache van je router, een browserextensie of een firewall die je IP-adres heeft geblokkeerd na te veel mislukte inlogpogingen. Probeer een privévenster en een ander netwerk voordat je aan de server zit.
Lees de foutmelding
De precieze foutmelding wijst naar de laag die faalt. Schrijf hem op voordat je dingen gaat veranderen.
Wat je zietWaarschijnlijke laagBegin bijDNS_PROBE_FINISHED_NXDOMAIN, “IP-adres van de server is niet gevonden”DNS of domeinStap 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTNetwerk of serverStap 3“Je verbinding is niet privé”, NET::ERR_CERT_DATE_INVALIDTLS-certificaatStap 4Cloudflare 521, 522, 525 of 526, of een foutpagina van de CDNCDN naar originStap 5500, 502, 503 of 504Webserver of applicatieStap 6Een pagina die laadt maar leeg is of een fout toontApplicatie of afhankelijkheidStap 7
Stap 2: controleer DNS en het domein
Als de naam niet resolvet, doet de rest er niet toe. Vraag DNS wat het voor je domein antwoordt en vergelijk dat met het adres van je server:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Helemaal geen antwoord: controleer met de domeinverloopchecker of de domeinregistratie is verlopen. Een verlopen domein raakt vaak zijn nameservers kwijt of verwijst naar de parkeerpagina van de registrar.
Het verkeerde adres: iemand heeft een record aangepast, of de nameservers zijn verhuisd naar een provider zonder jouw records. Vergelijk het antwoord met wat je verwacht met de tool DNS lookup.
Goed voor de een, fout voor de ander: een recente wijziging is nog niet overal doorgevoerd. Resolvers houden het oude antwoord vast tot de TTL verloopt; dat is DNS-propagatie.
Onze gids over DNS_PROBE_FINISHED_NXDOMAIN loopt de DNS-oorzaken een voor een langs.
Stap 3: kun je de server bereiken?
Klopt het adres, test dan of de server verbindingen accepteert op de webpoorten:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Connection refused: de machine antwoordt, maar er luistert niets op de poort. De webserver is gestopt of gecrasht. Start hem en lees de log om te achterhalen waarom.
Timed out: pakketten komen nergens aan. De server staat uit, een firewall of security group laat het verkeer vallen, of er is een storing in het netwerk ertussen. Kijk op de statuspagina en in de console van je hostingprovider.
Vertrouw niet alleen op ping. Veel hosts blokkeren ICMP, dus een server kan niet op ping reageren en de website prima serveren, of wel op ping reageren terwijl de webserver plat ligt.
Stap 4: controleer het TLS-certificaat
Een certificaatprobleem haalt de site voor iedereen tegelijk onderuit, met een paginavullende browserwaarschuwing, terwijl de server zelf prima draait. Haal de host door de SSL-checker, of kijk via de commandline:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
De gebruikelijke oorzaken zijn een verlopen certificaat na een mislukte automatische verlenging, een certificaat voor een andere naam of een ontbrekend intermediair certificaat. SSL-certificaatfouten uitgelegd koppelt elke browserwaarschuwing aan de oplossing.
Stap 5: sluit de CDN of proxy uit
Staat er een CDN of reverse proxy voor de site, dan kan een foutpagina van de proxy komen en niet van je server. De 52x-codes van Cloudflare zeggen precies waar het misging:
521: de originserver weigerde de verbinding.
522: de verbinding met de origin kreeg een time-out.
525: de TLS-handshake met de origin mislukte.
526: het certificaat van de origin is niet geldig.
Om de origin zonder de CDN te testen, stuur je het verzoek rechtstreeks naar het IP-adres en houd je de hostnaam aan. Vervang 203.0.113.10 door het adres van je origin:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Antwoordt de origin gewoon, kijk dan naar de CDN: de statuspagina, firewallregels die je onlangs hebt aangepast en of hij nog het juiste adres van de origin heeft. Faalt de origin ook, ga dan door naar de server.
Stap 6: controleer de webserver en de applicatie
Een 5xx-statuscode betekent dat het verzoek je stack heeft bereikt en dat daar iets misging. De code maakt het kleiner:
500: de applicatie gaf een fout. Zie 500 Internal Server Error.
502: de webserver kreeg geen geldig antwoord van het applicatieproces erachter, vaak omdat dat proces is gecrasht. Zie 502 Bad Gateway.
503: de dienst is overbelast of staat in onderhoudsmodus. Zie 503 Service Unavailable.
504: de applicatie deed er te lang over om te antwoorden. Zie 504 Gateway Timeout.
Elke code heeft een eigen pagina in het overzicht van HTTP-statuscodes. Op de server vinden drie checks de meeste oorzaken:
df -h # een volle schijf stopt databases, logs en uploads
free -m # bij geheugentekort worden processen beëindigd
tail -n 50 /var/log/nginx/error.log # of de logs van je webserver en app
Vraag je daarna af wat er is veranderd. Een deploy, een plugin-update, een configuratiewijziging of een verlopen API-sleutel in het afgelopen uur is de meest waarschijnlijke oorzaak, en terugdraaien gaat vaak sneller dan live debuggen.
Stap 7: controleer de afhankelijkheden
Je site kan gezond zijn terwijl iets waar hij van afhangt dat niet is. Een database zonder vrije verbindingen, een cacheserver die is gestopt, of een storing bij een betaal-, e-mail- of loginprovider: ze breken allemaal pagina’s die verder gewoon laden. Kijk op de statuspagina’s van je providers en zoek de grote op via Is it down?, dat bekende diensten en hun recente storingen bijhoudt.
Als de site up is maar niet werkt
Sommige fouten antwoorden gewoon met 200: een lege productlijst, een afrekenknop die niets doet, een foutmelding midden in een normale pagina. Een statuscode vangt die niet op. Controleer of de pagina bevat wat erop hoort, en doorloop de route die ertoe doet, zoals inloggen of betalen, zoals een klant dat zou doen.
Terwijl je het oplost: laat het weten
Plaats een korte update zodra je weet dat er een probleem is, ook als je alleen kunt zeggen dat je het onderzoekt, en beloof wanneer de volgende update komt. De statusupdategenerator schrijft er een voor elke fase, en het communicatieplan voor incidenten beschrijft wie wat zegt en waar.
Maak de volgende storing korter
Het traagste deel van de meeste storingen is erachter komen dat ze er zijn. Met externe monitoring hoor je het via een melding in plaats van via een klant, en begin je met bewijs in plaats van gissingen. Dit krijg je met Uptimecheck:
Elke minuut checks vanuit Stockholm, Londen en New York, waarbij elke fout vanaf een tweede locatie wordt bevestigd voordat je een melding krijgt. Zie uptime monitoring.
Bewijs in het incident: het adres waarnaar DNS resolvede, redirects, het certificaat, headers en het begin van het antwoord, plus een screenshot als de server antwoordde of een traceroute als dat niet zo was. Zie hoe incidenten en bewijs werken.
Responstijden opgesplitst in fasen: DNS, verbinden, TLS, server en download, zodat een trage laag opvalt voordat hij faalt.
Herinneringen voordat iets verloopt voor certificaten en domeinen, en meldingen als DNS-records veranderen.
Keyword-checks en flows die een pagina opmerken die met 200 antwoordt maar niet werkt. Zie flow monitoring.
Zegt een monitor dat je site down is terwijl hij bij jou werkt? Waarom een monitor down meldt terwijl je site werkt legt uit hoe je het verschil leest.
Weet het eerder dan je klanten. Probeer Uptimecheck 14 dagen gratis, geen creditcard nodig.