Articole
    Home » Cum depanezi un site indisponibil găzduit pe Linux – Ghid complet
Cum depanezi un site indisponibil găzduit pe Linux – Ghid complet

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:

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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
      

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.

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 sau tmux când faci troubleshooting, să nu pierzi sesiunea SSH dacă pică conexiunea.
  • Geek tip: Automatizează restartul serviciilor cu monit sau systemd 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. 😉

Leave a reply

Your email address will not be published. Required fields are marked