Når et website er nede, skal du først bekræfte, at det er nede for alle og ikke kun for dig. Arbejd derefter udefra og ind: DNS, forbindelsen, TLS-certifikatet, CDN’et eller proxyen, webserveren og til sidst applikationen og dens afhængigheder. Den fejl, du ser, fortæller som regel, hvilket lag du skal starte med, og hvert trin nedenfor har en hurtig test, der udelukker eller bekræfter det.
Tag noter undervejs: hvad du tjekkede, hvornår, og hvad du så. De gør rettelsen hurtigere at overdrage og postmortem-rapporten lettere at skrive.
Trin 1: Er det nede for alle, eller kun for dig?
Indsæt adressen i Is it down?-tjekkeren. Den henter siden fra Stockholm i Sverige, følger op til fem omdirigeringer og regner alt under HTTP 500 som oppe. Prøv derefter websitet på din telefon med Wi-Fi slået fra.
Hvis det virker udefra, men ikke for dig, ligger problemet tæt på dig: en VPN, en linje i hosts-filen, din routers DNS-cache, en browserudvidelse eller en firewall, der har blokeret din IP-adresse efter for mange mislykkede login. Prøv et privat vindue og et andet netværk, før du rører serveren.
Læs fejlmeddelelsen
Den præcise fejl peger på det lag, der fejlede. Skriv den ned, før du begynder at ændre noget.
Det ser duSandsynligt lagStart vedDNS_PROBE_FINISHED_NXDOMAIN, “serverens IP-adresse blev ikke fundet”DNS eller domæneTrin 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTNetværk eller serverTrin 3“Din forbindelse er ikke privat”, NET::ERR_CERT_DATE_INVALIDTLS-certifikatTrin 4Cloudflare 521, 522, 525 eller 526, eller en fejlside fra et CDNCDN til originTrin 5500, 502, 503 eller 504Webserver eller applikationTrin 6En side, der indlæses, men er tom eller viser en fejlApplikation eller afhængighedTrin 7
Trin 2: Tjek DNS og domænet
Hvis navnet ikke kan slås op, betyder intet andet noget. Spørg DNS, hvad den svarer for dit domæne, og sammenlign med din servers adresse:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Intet svar overhovedet: tjek, om domæneregistreringen er udløbet, med værktøjet til domæneudløb. Et udløbet domæne mister ofte sine navneservere eller peger på registrarens parkeringsside.
Den forkerte adresse: nogen har ændret en record, eller navneserverne er flyttet til en udbyder uden dine records. Sammenlign svaret med det, du forventer, med værktøjet DNS-opslag.
Rigtigt for nogle, forkert for andre: en nylig ændring er stadig ved at brede sig. Resolvere beholder det gamle svar, indtil dets TTL udløber, og det kaldes DNS-propagering.
Vores guide til DNS_PROBE_FINISHED_NXDOMAIN gennemgår DNS-årsagerne én for én.
Trin 3: Kan du nå serveren?
Med den rigtige adresse kan du teste, om serveren tager imod forbindelser på webportene:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Connection refused: maskinen svarer, men intet lytter på porten. Webserveren er stoppet eller gået ned. Start den, og læs dens log for at finde ud af hvorfor.
Timeout: pakkerne forsvinder. Serveren er slukket, en firewall eller security group smider trafikken væk, eller netværket imellem har en fejl. Se på din hostingudbyders statusside og konsol.
Stol ikke på ping alene. Mange hosts blokerer ICMP, så en server kan fejle ping og stadig levere websitet fint, eller svare på ping, mens webserveren er nede.
Trin 4: Tjek TLS-certifikatet
Et certifikatproblem tager websitet ned for alle på én gang, med en helsides advarsel i browseren, mens selve serveren er fin. Kør hosten gennem SSL-tjekkeren, eller se efter fra kommandolinjen:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
De typiske årsager er et udløbet certifikat efter en mislykket automatisk fornyelse, et certifikat til et andet navn eller et manglende mellemcertifikat. SSL-certifikatfejl forklaret kobler hver browseradvarsel til dens løsning.
Trin 5: Udeluk CDN’et eller proxyen
Hvis et CDN eller en reverse proxy sidder foran websitet, kan en fejlside komme fra proxyen og ikke fra din server. Cloudflares 52x-koder siger præcist, hvor det gik galt:
521: origin-serveren afviste forbindelsen.
522: forbindelsen til origin fik timeout.
525: TLS-handshaket med origin fejlede.
526: origins certifikat er ikke gyldigt.
For at teste origin uden CDN’et sender du forespørgslen direkte til dens IP-adresse og beholder værtsnavnet. Erstat 203.0.113.10 med din origins adresse:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Hvis origin svarer fint, så se på CDN’et: dets statusside, firewallregler, du har ændret for nylig, og om det stadig har den rigtige adresse til origin. Hvis origin også fejler, så gå videre til serveren.
Trin 6: Tjek webserveren og applikationen
En 5xx-statuskode betyder, at forespørgslen nåede din stack, og at noget dér fejlede. Koden indsnævrer det:
500: applikationen kastede en fejl. Se 500 Internal Server Error.
502: webserveren kunne ikke få et gyldigt svar fra applikationsprocessen bag den, ofte fordi den proces er gået ned. Se 502 Bad Gateway.
503: tjenesten er overbelastet eller i vedligeholdelsestilstand. Se 503 Service Unavailable.
504: applikationen var for længe om at svare. Se 504 Gateway Timeout.
Hver kode har sin egen side i opslagsværket over HTTP-statuskoder. På serveren finder tre tjek de fleste årsager:
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
Spørg derefter, hvad der er ændret. Et deploy, en plugin-opdatering, en ændret konfiguration eller en udløbet API-nøgle inden for den seneste time er den mest sandsynlige årsag, og det er ofte hurtigere at rulle ændringen tilbage end at fejlsøge live.
Trin 7: Tjek afhængighederne
Dit website kan være sundt, mens noget, det har brug for, ikke er. En database, der er løbet tør for forbindelser, en cacheserver, der er stoppet, eller en betalings-, e-mail- eller loginudbyder med et nedbrud ødelægger alle sider, der ellers indlæses. Tjek dine udbyderes statussider, og slå de store op på Is it down?, som følger kendte tjenester og deres seneste nedbrud.
Når websitet er oppe, men i stykker
Nogle fejl svarer med 200: en tom produktliste, en betalingsknap, der ikke gør noget, en fejlbesked inde i en ellers normal side. Dem fanger en statuskode ikke. Tjek, at siden indeholder det, den skal, og gå den vigtige rejse igennem, f.eks. login eller betaling, sådan som en kunde ville.
Mens du retter det: fortæl det til folk
Læg en kort opdatering ud, så snart du ved, at der er et problem, også selvom du kun kan sige, at du undersøger det, og lov, hvornår næste opdatering kommer. Generatoren til statusopdateringer skriver én til hver fase, og kommunikationsplanen for hændelser dækker, hvem der siger hvad og hvor.
Gør det næste nedbrud kortere
Den langsomste del af de fleste nedbrud er at opdage dem. Med ekstern overvågning hører du om problemet fra en alarm i stedet for fra en kunde, og du starter med beviser i stedet for gæt. Det her får du med Uptimecheck:
Tjek hvert minut fra Stockholm, London og New York, hvor hver fejl bekræftes fra en anden lokation, før du får en alarm. Se oppetidsovervågning.
Beviser i hændelsen: den adresse, DNS pegede på, omdirigeringer, certifikatet, headers og starten af svaret, plus et skærmbillede, når serveren svarede, eller en traceroute, når den ikke gjorde. Se hvordan hændelser og beviser fungerer.
Svartider opdelt i faser: DNS, connect, TLS, server og download, så et langsomt lag skiller sig ud, før det fejler.
Påmindelser før udløb for certifikater og domæner, og alarmer, når DNS-records ændres.
Søgeordstjek og flows, der fanger en side, som svarer 200, men er i stykker. Se flowovervågning.
Hvis en monitor siger nede, mens websitet virker for dig, forklarer hvorfor en monitor er nede, når dit website virker, hvordan du læser forskellen.
Få det at vide før dine kunder. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.