- Home »

Cum depanezi un site indisponibil găzduit pe Linux – Ghid complet
Site-ul tău nu e disponibil? Panică sau troubleshooting? 😬
Oricine are un site știe sentimentul acela când primești un mesaj pe WhatsApp sau un mail de la un client (sau, și mai rău, de la șef): „Site-ul nu merge!”. Dacă ești SEO, webmaster, admin sau doar pasionat de tech, știi că downtime-ul e cel mai mare coșmar. Nu doar că pierzi trafic și conversii, dar Google nu iartă: crawlerele pot marca site-ul ca nesigur sau inactiv, ceea ce înseamnă că poți pierde poziții valoroase în SERP. Deci, ce faci când serverul tău Linux nu mai servește paginile? 🕵️♂️
Pasul 1: Confirmă problema (nu te baza doar pe „nu merge la mine”)
- Începe cu verificări simple: deschide site-ul din browserul tău, apoi folosește un alt device sau conexiune (de exemplu, 4G vs Wi-Fi).
- Folosește tool-uri externe pentru a verifica dacă site-ul e jos doar pentru tine sau pentru toată lumea:
- Down For Everyone Or Just Me
- Pingdom
- Uptime Robot (dacă ai deja monitorizare setată, primești notificări instant)
Comandă rapidă:
ping nume-domeniu.com
curl -I https://nume-domeniu.com
Dacă primești răspuns sau cod de status HTTP, serverul încă răspunde. Dacă nu, e ceva mai grav.
Pasul 2: Diagnosticare rapidă pe serverul Linux 🐧
Ai acces SSH? Perfect, hai să vedem ce se întâmplă. Dacă nu, contactează urgent providerul de hosting.
- Verifică dacă serverul e online:
- Poți face ping către server (din altă rețea)
- Dacă ai VPS sau server dedicat, încearcă să te conectezi prin SSH:
ssh user@IP-server
- Dacă nu merge, poate fi o problemă de rețea sau serverul e complet căzut.
- Verifică serviciile web:
- Cel mai des, serverele folosesc Apache sau Nginx. Verifică dacă rulează:
# Pentru Apache sudo systemctl status apache2 # Pentru Nginx sudo systemctl status nginx
- Dacă serviciul e oprit, pornește-l:
sudo systemctl start apache2 sudo systemctl start nginx
- Vezi dacă serviciul repornește fără erori.
- Cel mai des, serverele folosesc Apache sau Nginx. Verifică dacă rulează:
- Verifică logurile! (Aici e cheia 👀)
- Apache:
/var/log/apache2/error.log
- Nginx:
/var/log/nginx/error.log
- Poți folosi tail pentru a vedea ultimele linii:
tail -n 50 /var/log/apache2/error.log tail -n 50 /var/log/nginx/error.log
- Logurile spun aproape întotdeauna ce s-a întâmplat: eroare de configurare, lipsă resurse, atac DDoS, etc.
- Apache:
- Verifică spațiul pe disc:
- Un motiv comun pentru downtime: serverul a rămas fără spațiu!
df -h
- Dacă vezi ceva de genul
/dev/sda1 100%
, trebuie să eliberezi spațiu rapid.
- Un motiv comun pentru downtime: serverul a rămas fără spațiu!
- Verifică încărcarea serverului:
- Poate cineva a dat un crawl masiv sau ai un script care consumă resurse:
top htop # (dacă ai instalat)
- Caută procese suspecte sau load average peste 5-10 (depinde de server).
- Poate cineva a dat un crawl masiv sau ai un script care consumă resurse:
- Verifică conexiunile la bazele de date:
- WordPress sau alte CMS-uri? Poate baza de date e căzută:
sudo systemctl status mysql sudo systemctl status mariadb
- Pornește serviciul dacă e oprit:
sudo systemctl start mysql sudo systemctl start mariadb
- WordPress sau alte CMS-uri? Poate baza de date e căzută:
Pasul 3: Probleme de DNS sau SSL? 🔒
- DNS: Dacă ai schimbat recent nameserver-ele sau ai migrat site-ul, propagarea DNS poate dura. Verifică cu:
nslookup nume-domeniu.com dig nume-domeniu.com
- Dacă IP-ul nu e cel corect, așteaptă propagarea sau corectează setările DNS.
- SSL: Un certificat expirat sau configurat greșit poate bloca accesul.
- Verifică cu:
sudo certbot certificates
- Reînnoiește certificatul dacă e nevoie:
sudo certbot renew
- Poți verifica SSL și cu SSL Labs.
- Verifică cu:
Pasul 4: Comunică cu vizitatorii și Google! 📣
- Dacă downtime-ul durează, pune un mesaj de tip „maintenance page” (cu cod 503, nu 200!), astfel încât Google să nu te penalizeze.
# Exemplu pentru Nginx: location / { return 503; error_page 503 @maintenance; } location @maintenance { rewrite ^(.*)$ /maintenance.html break; } # Pentru Apache: Redirect 503 /maintenance.html
- Anunță utilizatorii pe social media sau newsletter dacă ai downtime prelungit.
- Notifică Google Search Console (dacă ai downtime planificat, folosește instrumentul de „temporarily remove” sau „site move”).
Pasul 5: Prevenție și monitorizare (ca un adevărat sysadmin 🦾)
- Setează monitorizare automată (Pingdom, UptimeRobot, StatusCake) – primești alertă SMS/email dacă site-ul pică.
- Backup-uri automate! – dacă ceva merge prost, să poți restaura rapid.
- Actualizează regulat serverul și aplicațiile (WordPress, plugin-uri, Nginx/Apache, PHP, MySQL).
- Folosește firewall și limitare brute-force (fail2ban, ufw, etc.).
- Testează periodic paginile de eroare și asigură-te că nu trimit coduri greșite (de ex. 200 în loc de 503).
Exemple de scenarii și soluții rapide
1. Spațiu pe disc plin
df -h
du -sh /var/log/*
rm -f /var/log/vechi.log # sau logrotate manual
2. Certificat SSL expirat
sudo certbot renew
sudo systemctl reload nginx # sau apache2
3. Atac DDoS sau crawl excesiv
- Verifică IP-urile suspecte:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
- Blochează IP-urile cu iptables sau fail2ban.
4. Serverul răspunde, dar site-ul e lent sau dă 500
- Verifică logurile de eroare (probabil PHP sau baza de date are probleme).
- Repornește serviciile (Nginx/Apache, PHP-FPM, MySQL).
Bonus: Greșeli de începător, mituri și sfaturi „geeky”
- Mit: „Dacă site-ul meu e pe un VPS, nu poate cădea.” – FALS! Orice server poate avea downtime (hardware, software, atacuri, update-uri fail).
- Greșeală: Să nu faci backup sau să salvezi backup-ul pe același server (dacă pică tot, la revedere date!).
- Mit: „Un certificat SSL se reînnoiește singur.” – Doar dacă ai scripturi automate corect configurate!
- Greșeală: Să nu setezi pagini de eroare corecte (503 pentru mentenanță, nu 200 sau 404!).
- Greșeală: Să nu verifici logurile. Logurile sunt prietenul tău cel mai bun în troubleshooting!
- Geek tip: Folosește
screen
sautmux
când faci troubleshooting, să nu pierzi sesiunea SSH dacă pică conexiunea. - Geek tip: Automatizează restartul serviciilor cu
monit
sausystemd
pentru uptime maxim.
Concluzie: Fii pregătit, nu reacționează doar la criză! 🚀
Downtime-ul nu e o chestie de „dacă”, ci de „când”. Dacă site-ul tău e important (și sigur e, dacă citești asta), investește în monitorizare, backup și practici bune de administrare. Nu intra în panică la primul semn de downtime – urmează pașii de mai sus, citește logurile, comunică transparent cu utilizatorii și Google, și învață din fiecare incident.
Recomandare finală? Automatizează tot ce poți, citește loguri, fă backup și monitorizează constant. Așa vei dormi mai liniștit, iar site-ul tău va fi mai rezilient decât al concurenței. 😉