Når et nettsted er nede, bør du først bekrefte at det er nede for alle og ikke bare for deg. Jobb deg deretter utenfra og inn: DNS, tilkoblingen, TLS-sertifikatet, CDN-et eller proxyen, webserveren og til slutt applikasjonen og det den er avhengig av. Feilen du ser, forteller som regel hvilket lag du bør starte med, og hvert steg nedenfor har en rask test som bekrefter eller utelukker det.
Skriv notater underveis: hva du sjekket, når og hva du så. Da går det raskere å overlevere feilrettingen, og postmortem-rapporten blir enklere å skrive.
Steg 1: Er det nede for alle, eller bare for deg?
Lim inn adressen i Is it down?-sjekkeren. Den henter siden fra Stockholm i Sverige, følger opptil fem omdirigeringer og regner alt under HTTP 500 som oppe. Prøv deretter nettstedet på mobilen med Wi-Fi slått av.
Virker det utenfra, men ikke for deg, ligger problemet nær deg: en VPN, en oppføring i hosts-filen, DNS-hurtigbufferen i ruteren, en nettleserutvidelse eller en brannmur som blokkerte IP-adressen din etter for mange mislykkede innlogginger. Prøv et privat vindu og et annet nettverk før du rører serveren.
Les feilmeldingen
Den nøyaktige feilen peker på laget som sviktet. Noter den før du begynner å endre ting.
Det du serSannsynlig lagStart medDNS_PROBE_FINISHED_NXDOMAIN, «finner ikke serverens IP-adresse»DNS eller domeneSteg 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTNettverk eller serverSteg 3«Tilkoblingen din er ikke privat», NET::ERR_CERT_DATE_INVALIDTLS-sertifikatSteg 4Cloudflare 521, 522, 525 eller 526, eller en feilside fra CDN-etCDN til opprinnelsesserverSteg 5500, 502, 503 eller 504Webserver eller applikasjonSteg 6En side som laster, men er tom eller viser en feilApplikasjon eller avhengighetSteg 7
Steg 2: Sjekk DNS og domenet
Hvis navnet ikke slås opp, spiller ingenting annet noen rolle. Spør DNS hva den svarer for domenet ditt, og sammenlign med serverens adresse:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Ikke noe svar i det hele tatt: sjekk om domeneregistreringen har utløpt med sjekkeren for domeneutløp. Et utløpt domene mister ofte navneserverne sine eller peker til registrarens parkeringsside.
Feil adresse: noen har endret en post, eller navneserverne er flyttet til en leverandør som ikke har postene dine. Sammenlign svaret med det du forventer i verktøyet DNS-oppslag.
Riktig for noen, feil for andre: en nylig endring er fortsatt på vei ut. Resolvere beholder det gamle svaret til TTL-en går ut, og det er DNS-propagering.
Guiden vår om DNS_PROBE_FINISHED_NXDOMAIN går gjennom DNS-årsakene én etter én.
Steg 3: Når du frem til serveren?
Med riktig adresse tester du om serveren tar imot tilkoblinger på webportene:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Connection refused: maskinen svarer, men ingenting lytter på porten. Webserveren har stoppet eller krasjet. Start den, og les loggen for å finne ut hvorfor.
Tidsavbrudd: pakkene havner ingen steder. Serveren er av, en brannmur eller sikkerhetsgruppe forkaster trafikken, eller nettverket imellom har en feil. Se på statussiden og konsollen til hostingleverandøren.
Ikke stol på ping alene. Mange verter blokkerer ICMP, så en server kan feile på ping og likevel levere nettstedet fint, eller svare på ping mens webserveren er nede.
Steg 4: Sjekk TLS-sertifikatet
Et sertifikatproblem tar ned nettstedet for alle på én gang, med en helsides advarsel i nettleseren, selv om selve serveren er i orden. Kjør verten gjennom SSL-sjekkeren, eller se fra kommandolinjen:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
De vanlige årsakene er et utløpt sertifikat etter en mislykket automatisk fornyelse, et sertifikat for et annet navn eller et manglende mellomsertifikat. SSL-sertifikatfeil forklart kobler hver nettleseradvarsel til løsningen.
Steg 5: Utelukk CDN-et eller proxyen
Står et CDN eller en reverse proxy foran nettstedet, kan en feilside komme fra proxyen og ikke fra serveren din. Cloudflares 52x-koder sier nøyaktig hvor det stoppet:
521: opprinnelsesserveren avviste tilkoblingen.
522: tilkoblingen til opprinnelsesserveren fikk tidsavbrudd.
525: TLS-håndtrykket med opprinnelsesserveren mislyktes.
526: sertifikatet på opprinnelsesserveren er ikke gyldig.
For å teste opprinnelsesserveren uten CDN-et sender du forespørselen rett til IP-adressen og beholder vertsnavnet. Bytt ut 203.0.113.10 med adressen til opprinnelsesserveren din:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Svarer opprinnelsesserveren som den skal, ser du på CDN-et: statussiden, brannmurregler du har endret nylig, og om det fortsatt har riktig adresse til opprinnelsesserveren. Feiler opprinnelsesserveren også, går du videre til serveren.
Steg 6: Sjekk webserveren og applikasjonen
En 5xx-statuskode betyr at forespørselen nådde frem til stacken din, og at noe der feilet. Koden snevrer det inn:
500: applikasjonen kastet en feil. Se 500 Internal Server Error.
502: webserveren fikk ikke et gyldig svar fra applikasjonsprosessen bak seg, ofte fordi den prosessen krasjet. Se 502 Bad Gateway.
503: tjenesten er overbelastet eller i vedlikeholdsmodus. Se 503 Service Unavailable.
504: applikasjonen brukte for lang tid på å svare. Se 504 Gateway Timeout.
Hver kode har sin egen side i oversikten over HTTP-statuskoder. På serveren finner tre sjekker de fleste årsakene:
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ør deretter hva som er endret. En deploy, en plugin-oppdatering, en konfigurasjonsendring eller en utløpt API-nøkkel den siste timen er den mest sannsynlige årsaken, og å rulle tilbake går ofte raskere enn å feilsøke i produksjon.
Steg 7: Sjekk avhengighetene
Nettstedet ditt kan være friskt mens noe det trenger, ikke er det. En database som er tom for tilkoblinger, en hurtigbufferserver som har stoppet, eller et driftsavbrudd hos en leverandør av betaling, e-post eller innlogging ødelegger sider som ellers laster. Sjekk statussidene til leverandørene dine, og slå opp de store på Is it down?, som følger kjente tjenester og de siste driftsavbruddene deres.
Når nettstedet er oppe, men ødelagt
Noen feil svarer med 200: en tom produktliste, en kasseknapp som ikke gjør noe, en feilmelding inne på en ellers normal side. Statuskoden fanger ikke opp slikt. Sjekk at siden inneholder det den skal, og gå gjennom den reisen som betyr noe, som å logge inn eller betale, slik en kunde ville gjort.
Mens du retter feilen: si fra
Legg ut en kort oppdatering så snart du vet at det er et problem, selv om alt du kan si er at du undersøker det, og lov når neste oppdatering kommer. Generatoren for statusoppdateringer skriver én for hver fase, og kommunikasjonsplanen for hendelser dekker hvem som sier hva, og hvor.
Gjør neste driftsavbrudd kortere
Det som tar lengst tid ved de fleste driftsavbrudd, er å oppdage dem. Med ekstern overvåking får du vite om problemet fra et varsel i stedet for fra en kunde, og du starter med bevis i stedet for gjetning. Dette får du med Uptimecheck:
Sjekker hvert minutt fra Stockholm, London og New York, der hver feil bekreftes fra en annen lokasjon før du varsles. Se oppetidsovervåking.
Bevis i hendelsen: adressen DNS pekte til, omdirigeringer, sertifikatet, headere og starten på svaret, pluss et skjermbilde når serveren svarte, eller en traceroute når den ikke gjorde det. Se hvordan hendelser og bevis fungerer.
Responstider delt opp i faser: DNS, tilkobling, TLS, server og nedlasting, så et tregt lag skiller seg ut før det feiler.
Påminnelser før utløp for sertifikater og domener, og varsler når DNS-poster endres.
Nøkkelordsjekker og flyter som fanger opp en side som svarer 200, men er ødelagt. Se flytovervåking.
Sier en monitor at nettstedet er nede mens det virker for deg, forklarer hvorfor en monitor er nede når nettstedet virker hvordan du tolker forskjellen.
Få vite det før kundene gjør det. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.