Server nede: hvad du skal tjekke først, og i hvilken rækkefølge

Denne guide handler om selve serveren: en VPS, en dedikeret server eller en cloudserver, som du driver. Fejler kun én enkelt hjemmeside, og alt andet på maskinen virker, eller ligger din hjemmeside på delt hosting, så start i stedet med guiden Hjemmesiden er nede: hvad du skal gøre. Her ser vi på maskinen: svarer den overhovedet, kan du komme ind, og hvad stoppede.

Trin 1: hvad er egentlig nede?

“Serveren er nede” kan betyde tre vidt forskellige ting, og hver har sin egen rettelse. Find først ud af det udefra, fra et netværk, der ikke er dit. For hjemmesider på serveren fortæller tjekket af, om hjemmesiden er nede dig på få sekunder, om navnet kan slås op, om porten svarer, og hvilken statuskode der kommer tilbage. For selve maskinen bruger du ping og en porttest fra din egen computer:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Læs resultaterne samlet:

• Ingen ping, ingen SSH, ingen webport: maskinen er slukket, frosset, eller netværket foran den er nede. Gå til trin 2.
• Ping svarer, SSH gør ikke: maskinen kører, men SSH er blokeret, stoppet, eller serveren er for overbelastet til at svare. Gå til trin 3.
• SSH virker, hjemmesiden gør ikke: serveren er i orden, en tjeneste er ikke. Gå til trin 4.

Nogle servere dropper ping med vilje. Har ping aldrig virket, så støt dig til porttestene.

Trin 2: intet svarer

Åbn din udbyders kontrolpanel eller cloud-konsol, før du gør andet. Tre spørgsmål afgør de fleste sager på et minut:

1. Kører serveren? En stoppet instans, en suspenderet konto eller en mislykket betaling ser udefra nøjagtig ud som et nedbrud.
2. Findes der en kendt hændelse? Tjek udbyderens statusside for din region eller dit datacenter.
3. Hvad viser konsollen? Web- eller seriekonsollen viser maskinens skærm, selv uden netværk. En kernel panic, “Out of memory: Killed process” i en løkke eller en opstart, der hænger ved et filsystemtjek, fortæller hver især, hvor problemet er.

Er maskinen frosset, bringer en genstart fra konsollen den som regel tilbage. Før du genstarter, så tag et skærmbillede af konsollen: når den er genstartet, er beviserne væk. Starter den ikke, tilbyder de fleste udbydere et rescue-system, hvorfra du kan montere disken, læse logs og reparere /etc/fstab eller en ødelagt netværkskonfiguration.

Trin 3: ping svarer, SSH gør ikke

Maskinen lever, så årsagen sidder på den. Brug konsollen til at logge ind, og tjek så de sædvanlige mistænkte:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

En firewallregel tilføjet i hast, din egen IP-adresse spærret efter nogle forkerte adgangskoder eller en ændring af SSH-konfigurationen, der fejlede sin test, er de hyppigste låse. Ophæv spærringen af din adresse med sudo fail2ban-client set sshd unbanip YOUR_IP, og kør altid sudo sshd -t, før du genstarter SSH. Kører SSH, men er bare meget langsom, er serveren overbelastet: gå til trin 4.

Trin 4: du er inde, læs nu fire tal

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Belastning (uptime): langt over antallet af CPU-kerner betyder, at maskinen er overbelastet. top eller htop viser, hvilken proces der er ansvarlig.
• Hukommelse (free -m): ingen ledig hukommelse og ingen swap, plus “Killed process” i dmesg, betyder, at kernen stoppede en proces for at overleve. Som regel var det databasen eller PHP.
• Disk (df -h): en fuld disk er den hyppigste årsag til serverproblemer. Databaser holder op med at skrive, logs stopper, sessioner fejler. df -i tjekker inodes: en disk kan være “fuld” med gigabyte ledige, hvis millioner af små filer opbruger alle inodes.
• I/O-fejl eller et skrivebeskyttet filsystem i dmesg: selve disken har et problem. Stop med at skrive, tag en backup, hvis du stadig kan, og kontakt din udbyder.

For at frigøre plads sikkert starter du med systemjournalen og gamle arkiver:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Slet aldrig databasefiler eller hjemmesidefiler for at skabe plads.

Trin 5: hvilken tjeneste stoppede, og hvorfor

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed opregner hver tjeneste, der stoppede med en fejl. Tjenestens journal nævner årsagen: en port, der allerede er i brug, en syntaksfejl i en konfigurationsfil, et manglende certifikat, ingen plads tilbage. Test konfigurationen før hver genstart (nginx -t, apachectl configtest, php-fpm -t), og start den derefter med sudo systemctl restart SERVICE. En genstart uden testen kan tage en tjeneste ned, der stadig halvvejs virkede.

Trin 6: hvad er ændret?

Nedbrud har årsager, og årsagen er som regel den seneste ændring. Led efter den:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Automatiske opdateringer, en ny kernel, der venter på en genstart, en udrulning, et cronjob, der fyldte disken med backups, et udløbet certifikat eller en konfigurationsændring foretaget af en anden: passer en af disse linjer med tidspunktet, hvor nedbruddet begyndte, har du dit spor.

Når de samme serverproblemer vender tilbage

En server, der gik ned én gang på grund af en fuld disk eller en stoppet database, gør det igen. Tjek udefra fortæller dig, hvornår den er nede; tjek indefra fortæller dig det før. Serveragenten melder belastning, hukommelse, diske og tjenester indefra maskinen og giver dig besked, når en disk passerer din tærskel, eller en tjeneste, du har afkrydset, stopper, mens der stadig er tid til at handle. Servermonitorering med agenten er en del af de betalte abonnementer.

Når du ikke vil gøre det klokken 3 om natten

Er din server nede, og vil du hellere have den rettet end fejlfinde selv, så klarer en Quick Fix de almindelige årsager til fast pris: den genstarter en stoppet tjeneste, når dens konfigurationstest er bestået, frigør en fuld disk og fornyer et udløbet certifikat, med en sikkerhedskopi først. Er det ikke nok, tager en Deep Fix over døgnet rundt, afregnet i blokke af 15 minutter, med prisen vist, før du bestiller. Begge virker via Responderen, SSH som root eller SSH-adgang til dit webhotel. Detaljer på siden server nede: reparation og akut serverhjælp.