Site-ul este down: verifici mai întâi DNS-ul sau hosting-ul? Un workflow practic de depanare

Când un site pică, verifică mai întâi DNS-ul, apoi serverul de hosting, apoi SSL, CDN și cache-ul, în această ordine. DNS-ul este punctul de intrare pentru orice cerere. Dacă domeniul nu rezolvă la IP-ul corect, nicio inspecție de log-uri de server nu va remedia pana. Secvența pe care o folosesc sysadminii este de la margine spre aplicație: confirmă DNS-ul, confirmă că serverul răspunde, confirmă că certificatul este valid, confirmă că CDN-ul funcționează corect, apoi confirmă că cache-ul aplicației nu servește erori vechi. Fiecare pas fie elimină un strat, fie identifică defecțiunea.

Dacă administrezi site-uri pentru clienți sau tocmai ai fost sunat la 2 noaptea, tentația este să deschizi un tichet la registrar, la host și la CDN simultan. Rezistă acestei tentații. Verificarea structurată de mai jos este ceea ce rulăm înainte să escaladăm orice problemă către un furnizor, și de obicei indică exact acel furnizor de care ai cu adevărat nevoie.

De ce contează ordinea straturilor

Orice cerere web trece prin straturi într-o secvență fixă: rezoluție DNS, rutare de rețea, răspuns server, handshake TLS, edge CDN și stiva aplicației. O defecțiune la primul strat înseamnă că cererea nu ajunge niciodată la al doilea. Cel mai mare risipitor de timp în triajul unei pane este depanarea stratului greșit. Clientul care repornește serverul WordPress timp de două ore pentru că „cache-ul este stricat", când problema reală este un domeniu expirat la registrar, este exemplul clasic.

Ordinea straturilor corespunde și diferiților furnizori și diferitelor căi de remediere. Problemele DNS indică spre registrar sau host-ul DNS. Problemele de server indică spre furnizorul de hosting. Problemele SSL indică spre autoritatea de certificare sau administratorul serverului. Problemele CDN indică spre panoul de control al CDN-ului. Problemele de cache indică spre aplicație. A ști care strat este defect îți spune ce tichet să deschizi, ceea ce economisește timp și evită escaladările duplicate.

Stratul 1: Rezoluție DNS

DNS-ul este primul pentru că nimic altceva nu poate funcționa fără el. Trei sub-verificări acoperă majoritatea panelor legate de DNS. Pentru o prezentare mai amplă a defecțiunilor DNS și a modului în care se manifestă în browser, consultă ghidul nostru de depanare DNS_PROBE_FINISHED_NXDOMAIN, care acoperă cele mai frecvente șase cauze pentru care un domeniu nu rezolvă.

Este domeniul încă înregistrat?

Domeniile expirate sunt o cauză frecventă a tichetelor „site-ul este down" care ajung escalate la registrari. Rulează:

whois example.com | grep -i "Registry Expiry"

Dacă data de expirare este în trecut, domeniul a expirat la registru. Remedierea este reînnoirea. Unele registre acordă o perioadă de grație pentru răscumpărare, altele nu.

Rezolvă domeniul?

Interogează de pe o mașină din afara propriei rețele pentru a evita rezultatele din cache:

dig +short example.com @8.8.8.8
dig +short www.example.com @1.1.1.1
dig +short example.com AAAA @8.8.8.8

Lipsa unui răspuns înseamnă unul din trei lucruri: domeniul nu are nicio înregistrare A sau AAAA, nameserverele listate la registrar sunt greșite, sau nameserverele autoritare nu funcționează. Verifică lanțul de delegare:

dig +short NS example.com @8.8.8.8
dig +short example.com @ns1.yourprovider.com

Dacă nameserverele delegate de registru nu corespund cu ce spune host-ul DNS, ai o nepotrivire de delegare. Acest lucru se întâmplă după o migrare când cineva actualizează zona la noul furnizor DNS, dar uită să actualizeze înregistrările nameserver la registrar. Pentru mecanica completă a motivului pentru care aceasta se strică și cum să verifici propagarea pe internetul global, consultă ghidul nostru de propagare DNS, care acoperă cum să interogezi direct nameserverele autoritare și să urmărești modificările înregistrărilor pe mai mulți resolveri publici.

Indică înregistrarea spre IP-ul corect?

Compară rezoluția DNS cu IP-ul pe care panoul de control al hosting-ului spune că se află site-ul. Pe hosting partajat, înregistrarea A ar trebui să indice spre IP-ul principal al serverului. Pe un VPS, ar trebui să indice spre IP-ul tău de VPS. O defecțiune frecventă după o migrare: DNS-ul indică încă spre IP-ul vechiului server, iar fostul furnizor fie a închis contul, fie a reallocat IP-ul.

Pe hosting partajat în special, acest mod de defecțiune este mai grav decât realizează majoritatea operatorilor. Când un host partajat își renumerotează serverul, actualizează automat propriile înregistrări nameserver. Clienții care folosesc nameserverele host-ului nu sesizează nicio întrerupere. Clienții care păstrează DNS-ul la un registrar terț și indică înregistrările A spre IP-ul original se trezesc cu site-ul mort, fără nicio avertizare. Am documentat un caz real în Furnizorul de hosting mi-a schimbat IP-ul fără să mă anunțe, unde o înregistrare A care indica spre un IP de hosting partajat renumerotat a pus jos un site care funcționase timp de doi ani fără nicio pană.

Punct operațional de reținut: resolverii DNS memorează răspunsurile în cache pe durata TTL. Reducerea unui TTL de la 3600 la 300 chiar înainte de o migrare ajută doar dacă faci modificarea cu cel puțin un ciclu TTL complet înainte. Resolverii recursivi care fac cache vor continua să servească înregistrarea veche până când aceasta expiră din cache-ul lor, indiferent de ce spune acum zona autoritară.

Stratul 2: Răspunsul serverului de hosting

Dacă DNS-ul rezolvă la IP-ul corect, următoarea întrebare este dacă serverul de la acel IP răspunde efectiv. Pentru o fișă completă de triaj de rețea strat cu strat, care acoperă interfețe, rute, vecini, sockets și capturi de pachete pe un VPS Linux, consultă ghidul nostru de comenzi pentru depanarea rețelei.

Este serverul accesibil la nivelul rețelei?

ping -c 4 your.server.ip
traceroute your.server.ip
mtr -r -c 10 your.server.ip

Lipsa răspunsului la ping nu înseamnă automat că serverul este down. Multe servere de producție blochează ICMP în mod implicit. Dar dacă ping-ul funcționa ieri și se oprește azi, ceva pe calea de rețea s-a schimbat. traceroute arată unde moare calea. Dacă traseul ajunge la granița centrului de date și se oprește, problema este în interiorul centrului de date, nu pe internetul public.

Ascultă serverul pe porturile corecte?

nmap -p 80,443,22,53 your.server.ip
curl -I -k https://your.server.ip -H "Host: example.com"

Portul 80 sau 443 închis pe un VPS înseamnă de obicei că serverul web (NGiNX, Apache sau ambele) nu rulează. Portul 22 închis poate însemna că SSH s-a oprit sau că o regulă de firewall s-a schimbat. Dacă poți intra în continuare prin SSH, verifică din interior:

ss -tlnp | grep -E ':(80|443|22|53)\s'
systemctl status nginx apache2 sshd

Este serverul suprasolicitat?

Aceasta este verificarea pe care cei mai mulți non-sysadmini o sar. Un server web care este în viață, dar fixat la 100% CPU sau fără memorie disponibilă, va respinge conexiunile înainte să servească o pagină. Din experiența noastră pe stack-uri de hosting de producție, aproximativ 60% din tichetele de suport etichetate „site-ul este down" sunt de fapt blocaje de performanță deghizate în pane: serverul funcționează, dar este prea suprasolicitat pentru a finaliza un handshake TLS pe portul 443. Pentru metodologia completă din spatele acestui număr, consultă Realitatea tichetelor „serverul meu este lent".

Rulează verificarea standard a resurselor:

uptime
free -m
top -b -n 1 | head -20
df -h

Un load average mult mai mare decât numărul de core-uri, combinat cu memorie liberă redusă și utilizare mare de swap, înseamnă că serverul se zbate. Pe un VPS de 2 GB care rulează WordPress cu WooCommerce, vei epuiza worker-ii PHP-FPM și conexiunile MySQL cu mult înainte de a epuiza RAM-ul. Verifică lista de procese și log-urile relevante:

tail -100 /var/log/nginx/error.log
tail -100 /var/log/apache2/error.log
tail -100 /var/log/syslog
journalctl -u php8.3-fpm --since "30 min ago"

Log-urile de erori îți vor spune în text clar ce a eșuat. Erorile fatale PHP, kill-urile out-of-memory de la OOM killer și refuzurile de conexiune la baza de date apar toate aici cu timestamp-uri. Dacă NGiNX returnează 502 Bad Gateway, problema este aproape întotdeauna backend-ul PHP-FPM care refuză sau nu reușește să răspundă. Pentru calea completă de diagnostic de la statusul serviciului prin ajustarea buffer-elor până la metricile TCP de kernel, consultă ghidul nostru NGiNX 502 Bad Gateway.

O comandă identifică dacă un singur client bombardează serverul și consumă fiecare worker PHP:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Rezultatul ordonează IP-urile clienților după numărul de cereri. Un IP în vârf cu mii de cereri în ultima oră este vinovatul, de obicei lovind wp-login.php sau xmlrpc.php pe o instalare WordPress.

Stratul 3: Certificat SSL

Dacă DNS-ul rezolvă și serverul răspunde, dar browserul afișează o eroare de certificat, cererea nu se finalizează niciodată din perspectiva utilizatorului. Defecțiunile SSL arată ca o pană chiar și când serverul este sănătos.

Verifică certificatul din linia de comandă:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer -subject

Aceasta arată fereastra de valabilitate, autoritatea emitentă și numele subiectului. Defecțiuni frecvente:

• Certificatul a expirat. Reînnoirile SSL gratuite eșuează când provocarea ACME nu poate accesa calea ascunsă /.well-known/acme-challenge/ din cauza unei reguli de redirecționare sau a unui CDN aflat în fața origin-ului.
• Hostname-ul de pe certificat nu corespunde domeniului solicitat. Se întâmplă după migrarea pe un server nou care nu avea AutoSSL provizionat încă.
• Lanțul este incomplet. Browserul afișează site-ul ca nesigur. De obicei un certificat intermediar lipsă în directiva ssl_certificate a NGiNX.

Dacă eroarea de browser este specific ERR_SSL_VERSION_OR_CIPHER_MISMATCH, serverul și browserul nu au putut cădea de acord asupra unei versiuni TLS sau a unui cipher suite. Pentru lista completă de verificări pentru a rezolva aceasta, consultă ghidul nostru de nepotrivire cipher SSL.

Planurile de găzduire web ServerSpan includ AutoSSL gratuit, iar reînnoirile sunt monitorizate activ în loc să se bazeze pe cron-ul implicit pentru reîncercări silențioase. Dacă host-ul tău actual lasă un certificat să expire și apoi așteaptă ca clientul să observe, host-ul nu îți monitorizează infrastructura. Poți verifica ce este inclus pe pagina planurilor de găzduire web.

Stratul 4: Configurația CDN

Dacă site-ul se încarcă direct, dar eșuează prin CDN, origin-ul este sănătos și stratul CDN este problema.

Compară origin-ul direct față de răspunsul CDN:

curl -I -k https://origin.ip -H "Host: example.com"
curl -I https://example.com

Dacă origin-ul returnează 200 și CDN-ul returnează 502 sau 504, CDN-ul nu poate ajunge la origin. Cauze: firewall-ul origin-ului blochează intervalele de IP ale CDN-ului, serverul origin s-a mutat și CDN-ul indică încă spre IP-ul vechi, sau health check-ul CDN-ului este configurat pe calea greșită.

Dacă CDN-ul returnează 403 sau 521, origin-ul refuză conexiunea pentru că CDN-ul prezintă un header Host greșit sau un SNI greșit. Deriva de configurație CDN este cel mai frecvent mod de defecțiune aici. Cineva a schimbat hostname-ul origin-ului în panoul CDN, dar nu a actualizat vhost-ul corespunzător de pe server.

Punct operațional: CDN-ul va continua să servească ultima stare din cache a origin-ului după ce repari origin-ul însuși. Dacă ai curățat cache-ul defect și site-ul afișează în continuare eroarea, golește cache-ul CDN-ului și așteaptă propagarea. Header-ele Cache-Control îi spun CDN-ului cât timp să păstreze un răspuns 5xx vechi, iar mulți CDN-i implicit mențin câteva minute. Într-o pană reală, suprascrie aceasta cu o golire manuală, nu cu o așteptare de TTL.

Stratul 5: Cache-ul aplicației

Dacă fiecare strat până aici este sănătos, problema este în stiva aplicației: WordPress, stratul PHP, baza de date sau cache-ul de pagini.

Un hard refresh elimină cache-ul browserului:

curl -I -H "Cache-Control: no-cache" https://example.com

Dacă aceasta returnează o pagină din cache, plugin-ul de cache de pagini din WordPress sau cache-ul NGiNX fastcgi servesc conținut vechi. Curăță-l din panoul de control al plugin-ului, sau pe un VPS cu acces direct la shell:

rm -f /var/cache/nginx/example.com/*
systemctl reload nginx

Dacă pagina este cu adevărat spartă după o curățare a cache-ului, problema este aplicația în sine. White screen of death în WordPress este aproape întotdeauna o eroare fatală PHP dintr-un conflict de plugin sau temă. Verifică:

tail -100 /var/log/php/8.3/fpm/error.log
wp config get WP_DEBUG --path=/var/www/example.com

Sau activează temporar WP_DEBUG în wp-config.php și reîncarcă pagina. Eroarea fatală se va afișa pe ecran cu o cale de fișier și un număr de linie.

Fluxul de diagnostic în 60 de secunde

Când nu ai timp și trebuie să faci triaj rapid, rulează exact această secvență:

1. dig +short example.com @8.8.8.8 confirmă că DNS-ul rezolvă la IP-ul corect.
2. curl -I https://example.com confirmă că serverul răspunde și returnează un răspuns 2xx sau 3xx.
3. echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates confirmă că SSL este valid.
4. Verifică direct origin-ul dacă există un CDN în față confirmă că origin-ul funcționează și CDN-ul este punctul de defecțiune.
5. Curăță cache-ul aplicației confirmă că pagina servită este proaspătă.

Primul pas taie arborele de depanare în jumătate. Dacă DNS-ul este defect, fiecare pas următor este irelevant. Dacă DNS-ul funcționează, restul durează 30 de secunde și te îndreptă spre furnizorul potrivit.

Când problema traversează straturi

Ordinea straturilor funcționează în majoritatea panelor. Cele care o înfrâng traversează de obicei straturi. Două tipare pe care le vedem frecvent:

Tiparul 1: Handshake TLS care epuizează worker-ii PHP

Un health check prost configurat de la un serviciu de monitorizare, un CDN sau un load balancer poate ține conexiunile TLS deschise fără a finaliza cererea HTTP. Fiecare conexiune deschisă ocupă un worker PHP-FPM. În câteva minute, toți worker-ii sunt ocupați și site-ul pare down. Soluția nu este mai mulți worker-i; soluția este limitarea clientului care se comportă greșit la nivelul NGiNX:

limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
limit_conn conn_per_ip 10;

Tiparul 2: TTL DNS care expiră în mijlocul unei pane

Un site face failover la un IP de rezervă prin DNS, dar răspunsul vechi este în cache la fiecare resolver recursiv pentru TTL-ul original. Jumătate din vizitatorii tăi lovesc IP-ul mort și jumătate lovesc IP-ul nou. Soluția este să scazi TTL-ul pe o înregistrare stabilă cu săptămâni înainte să ai nevoie de ea, nu în timpul failover-ului.

Ambele tipare sparg modelul simplu „repară stratul X" pentru că simptomul (site-ul este down) și cauza principală (epuizare TLS sau caching DNS) se află la straturi diferite față de locul în care utilizatorul experimentează defecțiunea.

Când să oprești depanarea și să chemi un sysadmin

Workflow-ul de mai sus rezolvă majoritatea panelor în sub zece minute. Dacă ai rulat fiecare verificare și cauza tot nu este evidentă, trei situații justifică escaladarea la un administrator de sistem în loc să continui:

• Serverul repornește, dar același serviciu continuă să crape în câteva minute. Aceasta indică o problemă mai profundă: o tabelă de baze de date coruptă, un cron job scăpat de sub control, un site compromis exploatat pentru trafic de ieșire, sau o defecțiune hardware.
• Pana coincide cu un vârf de trafic pe care nu îl poți explica. S-ar putea să fii sub un atac de aplicație Layer 7, iar soluția nu este în log-ul serverului web; este într-o regulă WAF sau la un furnizor de mitigare upstream.
• Rulezi verificările de mai sus și comenzile însele dau timeout. S-ar putea să nu ai acces la host, sau furnizorul de hosting are o problemă de rețea. Deschide un tichet la host cu rezultatele diagnosticului atașate.

Dacă nu ai un sysadmin de gardă, exact acest tip de muncă este ceea ce echipa noastră acoperă. Serviciul de administrare Linux ServerSpan acoperă configurarea serverelor, depanarea, optimizarea performanței și rezolvarea erorilor, cu administratori certificați și suport 24/7 pentru sistemele critice. Pentru echipele care vor fluxul de diagnostic de mai sus rulat pentru ele înainte ca un tichet să fie deschis vreodată, planurile noastre de VPS administrat includ monitorizare proactivă în mod implicit, de la planul de container partajat ct.Entry până la nivelul KVM dedicat vm.Go. Dacă configurația ta actuală de hosting este sursa recurentă a acestor tichete, vorbește cu echipa noastră despre setup-ul tău și îți vom spune sincer dacă o migrare este decizia corectă.