När en webbplats ligger nere ska du först bekräfta att den ligger nere för alla och inte bara för dig. Arbeta dig sedan utifrån och in: DNS, anslutningen, TLS-certifikatet, CDN:et eller proxyn, webbservern och till sist applikationen och dess beroenden. Felet du ser visar oftast vilket lager du ska börja med, och varje steg nedan har ett snabbt test som avgör om felet ligger där eller inte.
Anteckna medan du arbetar: vad du kontrollerade, när och vad du såg. Det gör det snabbare att lämna över åtgärden och lättare att skriva postmortem.
Steg 1: Ligger den nere för alla, eller bara för dig?
Klistra in adressen i Is it down?-kontrollen. Den hämtar sidan från Stockholm, följer upp till fem omdirigeringar och räknar allt under HTTP 500 som uppe. Testa sedan sajten i mobilen med wifi avstängt.
Fungerar den utifrån men inte för dig ligger problemet nära dig: en VPN, en rad i hosts-filen, routerns DNS-cache, ett webbläsartillägg eller en brandvägg som blockerade din IP-adress efter för många misslyckade inloggningar. Testa ett privat fönster och ett annat nätverk innan du rör servern.
Läs felmeddelandet
Det exakta felet pekar ut lagret som slutade fungera. Skriv ner det innan du börjar ändra något.
Det du serTroligt lagerBörja vidDNS_PROBE_FINISHED_NXDOMAIN, ”serverns IP-adress gick inte att hitta”DNS eller domänSteg 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTNätverk eller serverSteg 3”Anslutningen är inte privat”, NET::ERR_CERT_DATE_INVALIDTLS-certifikatSteg 4Cloudflare 521, 522, 525 eller 526, eller en felsida från CDN:etCDN till ursprungsserverSteg 5500, 502, 503 eller 504Webbserver eller applikationSteg 6En sida som laddas men är tom eller visar ett felApplikation eller beroendeSteg 7
Steg 2: Kontrollera DNS och domänen
Om namnet inte går att slå upp spelar inget annat någon roll. Fråga DNS vad den svarar för din domän och jämför med serverns adress:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Inget svar alls: kontrollera om domänregistreringen har gått ut med verktyget för domänens utgångsdatum. En utgången domän tappar ofta sina namnservrar eller pekar på registrarens parkeringssida.
Fel adress: någon har ändrat en post, eller så har namnservrarna flyttats till en leverantör som saknar dina poster. Jämför svaret med det du förväntar dig med verktyget DNS-uppslag.
Rätt för vissa, fel för andra: en nyligen gjord ändring sprids fortfarande. Resolvrar behåller det gamla svaret tills dess TTL har löpt ut, det som kallas DNS-propagering.
Vår guide om DNS_PROBE_FINISHED_NXDOMAIN går igenom DNS-orsakerna en i taget.
Steg 3: Når du servern?
När adressen stämmer testar du om servern tar emot anslutningar på webbportarna:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Anslutningen nekas: maskinen svarar, men inget lyssnar på porten. Webbservern har stoppats eller kraschat. Starta den och läs loggen för att ta reda på varför.
Tidsgränsen överskrids: paketen kommer ingenstans. Servern är avstängd, en brandvägg eller säkerhetsgrupp släpper inte igenom trafiken, eller så är det fel i nätverket däremellan. Titta på webbhotellets statussida och kontrollpanel.
Lita inte enbart på ping. Många servrar blockerar ICMP, så en server kan misslyckas med ping och ändå leverera webbplatsen utan problem, eller svara på ping medan webbservern ligger nere.
Steg 4: Kontrollera TLS-certifikatet
Ett certifikatproblem slår ut sajten för alla på en gång, med en helsidesvarning i webbläsaren, trots att själva servern fungerar. Kör värden genom SSL-kontrollen, eller titta från kommandoraden:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
De vanligaste orsakerna är ett certifikat som gått ut efter en misslyckad automatisk förnyelse, ett certifikat för ett annat namn eller ett saknat mellanliggande certifikat. SSL-certifikatfel förklarade kopplar varje webbläsarvarning till sin lösning.
Steg 5: Uteslut CDN:et eller proxyn
Om ett CDN eller en omvänd proxy ligger framför sajten kan felsidan komma från proxyn och inte från din server. Cloudflares 52x-koder säger exakt var det gick sönder:
521: ursprungsservern nekade anslutningen.
522: anslutningen till ursprungsservern överskred tidsgränsen.
525: TLS-handskakningen med ursprungsservern misslyckades.
526: ursprungsserverns certifikat är inte giltigt.
För att testa ursprungsservern utan CDN:et skickar du förfrågan direkt till dess IP-adress men behåller värdnamnet. Byt ut 203.0.113.10 mot ursprungsserverns adress:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Svarar ursprungsservern som den ska, titta på CDN:et: dess statussida, brandväggsregler du nyligen ändrat och om det fortfarande har rätt adress till ursprungsservern. Misslyckas även ursprungsservern går du vidare till servern.
Steg 6: Kontrollera webbservern och applikationen
En 5xx-statuskod betyder att förfrågan nådde din stack och att något där gick fel. Koden ringar in felet:
500: applikationen kastade ett fel. Se 500 Internal Server Error.
502: webbservern fick inget giltigt svar från applikationsprocessen bakom den, ofta för att processen kraschat. Se 502 Bad Gateway.
503: tjänsten är överbelastad eller i underhållsläge. Se 503 Service Unavailable.
504: applikationen tog för lång tid på sig att svara. Se 504 Gateway Timeout.
Varje kod har en egen sida i referensen över HTTP-statuskoder. På servern hittar tre kontroller de flesta orsakerna:
df -h # a full disk stops databases, logs and uploads
free -m # out of memory kills processes
tail -n 50 /var/log/nginx/error.log # or your web server and app logs
Fråga dig sedan vad som har ändrats. En driftsättning, en pluginuppdatering, en ändrad konfiguration eller en utgången API-nyckel den senaste timmen är den troligaste orsaken, och att rulla tillbaka går ofta snabbare än att felsöka i produktion.
Steg 7: Kontrollera beroendena
Din sajt kan må bra medan något den behöver inte gör det. En databas som har slut på anslutningar, en cacheserver som stannat eller en betal-, e-post- eller inloggningsleverantör med driftstörning slår ut sidor som annars laddas. Kontrollera leverantörernas statussidor, och slå upp de stora på Is it down?, som följer kända tjänster och deras senaste avbrott.
När sajten är uppe men trasig
Vissa fel svarar med 200: en tom produktlista, en kassaknapp som inte gör något, ett felmeddelande mitt på en vanlig sida. En statuskod fångar inte sådant. Kontrollera att sidan innehåller det den ska, och gå igenom det flöde som betyder något, till exempel inloggning eller betalning, på samma sätt som en kund.
Medan du åtgärdar felet: berätta för andra
Publicera en kort uppdatering så fort du vet att det finns ett problem, även om du bara kan säga att du undersöker saken, och lova när nästa uppdatering kommer. Generatorn för statusuppdateringar skriver en för varje skede, och kommunikationsplanen för incidenter tar upp vem som säger vad och var.
Gör nästa avbrott kortare
Den långsammaste delen av de flesta avbrott är att få veta att de pågår. Med extern övervakning får du veta det genom ett larm i stället för från en kund, och du börjar med belägg i stället för gissningar. Det här ger Uptimecheck dig:
Kontroller varje minut från Stockholm, London och New York, där varje fel bekräftas från en andra plats innan du larmas. Se upptidsövervakning.
Belägg i incidenten: adressen som DNS pekade på, omdirigeringar, certifikatet, headers och början av svaret, plus en skärmbild när servern svarade eller en traceroute när den inte gjorde det. Se så fungerar incidenter och belägg.
Svarstider uppdelade i faser: DNS, anslutning, TLS, server och nedladdning, så att ett långsamt lager syns innan det slutar fungera.
Påminnelser före utgångsdatum för certifikat och domäner, och larm när DNS-poster ändras.
Nyckelordskontroller och flöden som fångar en sida som svarar 200 men är trasig. Se flödesövervakning.
Om en övervakning säger nere medan sajten fungerar för dig förklarar varför en övervakning är nere när sajten fungerar hur du tolkar skillnaden.
Få veta det före dina kunder. Prova Uptimecheck gratis i 14 dagar, inget kreditkort behövs.