Site-ul Web Este Inactiv, dar Serverul Este Accesibil? Urmărește Defecțiunea de la DNS la Aplicație

“SSH funcționează, site-ul nu” — Începeți cu întrebarea corectă

Alertele încep să se declanșeze, utilizatorii spun că site-ul este mort, și primul test te liniștește ciudat: SSH te lasă să intri. Acel moment pare liniștitor pentru că serverul nu a dispărut. Dar este și locul unde o mulțime de troubleshooting prost începe, pentru că “pot să mă conectez încă” nu este același lucru cu “site-ul web ar trebui să funcționeze.”

Întrebarea utilă nu este “ce pot reporni mai întâi?” Este “care strat a eșuat mai întâi?” O sesiune SSH funcțională dovedește că mașina este accesibilă pe portul 22. Nu dovedește că domeniul se rezolvă corect. Nu dovedește:

• porturile 80 și 443 sunt accesibile
• HTTPS este sănătos
• aplicația din spatele serverului web răspunde

Acest ghid este construit în jurul acestei distincții și rămâne concentrat pe diagnostic mai degrabă decât să încerce să devină un manual complet nginx, DNS, TLS, Docker sau bază de date.

⚠️ Avertisment: Repornirea oarbă a nginx, Docker, PHP-FPM sau a întregului VPS în primele minute ale unui incident poate șterge indiciile de care ai nevoie. Colectează o rundă de dovezi mai întâi, apoi schimbă doar stratul care a eșuat de fapt.

Harta de Triaj de o Minut

Înainte de a aprofunda, orientează-te. Forma defecțiunii te spune adesea care strat merită atenție mai întâi, chiar și atunci când nu cunoști încă cauza rădăcinii.

Tratează următorul tabel ca o scurtătură de triaj, nu ca un verdict final.

Ceea ce contează este prima etapă ruptă. Dacă DNS eșuează, straturile ulterioare sunt zgomot. Dacă 443 răspunde dar TLS se rupe, aplicația nu este încă prima ta întrebare. Modelul mental de mai jos este ceea ce face ca acea secvență să pară logică în loc de aleatorie.

De ce SSH nu dovedește că site-ul funcționează

SSH și traficul web sunt căi diferite cu sarcini diferite. SSH pe portul 22 dovedește că poți ajunge la mașină prin ușa sa de gestionare la distanță. Un site web depinde de porturile 80 și 443, plus straturile din spatele lor. Acestea sunt teste separate, deci “server accesibil” și “site web accesibil” nu sunt afirmații interschimbabile.

Cel mai ușor mod de a-ți imagina este ca o clădire de birouri. DNS ajută un vizitator să găsească adresa clădirii. Porturile 80 și 443 sunt receptia pentru vizitatorii publici. Serverul web este recepționerul care acceptă cererea și decide unde merge mai departe. Aplicația este biroul care face munca reală. O bază de date sau o altă dependență poate fi mai adânc în clădire. SSH este o intrare complet diferită. Este util pentru personal, dar nu dovedește că receptia este deschisă sau că transferul biroului funcționează.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

Când oamenii spun că un serviciu “ascultă”, înseamnă că acceptă de fapt conexiuni pe punctul final așteptat. Aceasta este distincția care transformă un moment vag “serverul este activ” într-o cale de cerere trasabilă.

Asta contează pentru că HTTPS poate eșua înainte ca aplicația să răspundă vreodată, iar eșecurile proxy sau ale aplicației pot apărea după ce frontend-ul este deja accesibil. Deci următoarea mișcare este întotdeauna aceeași: privește din exterior mai întâi și găsește ultima etapă reușită a cererii.

Pasul 1: Reproduceți Eșecul din Afara Serverului

Începeți din partea clientului, nu din interiorul VPS. Dacă este posibil, testați mai întâi din altă rețea sau dispozitiv pentru a nu confunda o cache DNS locală, o intrare veche în /etc/hosts sau o problemă de firewall/VPN local cu o reală întrerupere a serverului.

Utilizați o cerere externă detaliată pentru a vedea cât de departe ajunge cererea înainte să se întrerupă:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v nu este un instrument doar pentru experți aici. Citiți-o ca o urmă de progres. Dacă nu rezolvă niciodată numele, vă aflați în ramura DNS. Dacă se conectează și apoi spune Connection refused, gazda a răspuns dar nimic util nu acceptă trafic acolo. Dacă se blochează până la timeout, gândiți-vă la filtrare, rutare sau o blocare mai profundă mai târziu în calea cererii. Dacă primiți un răspuns HTTP, chiar și o pagină de eroare, ați trecut deja peste stratul de conexiune și într-o ramură mai înaltă.

💡 Sfat: Comparați IPv4 și IPv6 devreme. Un înregistrare AAAA uitată poate face ca întreruperea să pară inconsistentă deoarece unii clienți preferă IPv6 mai întâi și alții nu.

Rulați același test o dată per familie de protocoale când dual stack este în joc:

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

Dacă IPv4 funcționează și IPv6 eșuează, sau invers, ați restrâns deja incidentul mai rapid decât o repornire a serviciului ar putea face. Dacă eșecul începe la rezoluția numelor sau alegerea destinației, DNS este următoarea ramură curată de verificat.

Pasul 2: Verificați DNS și Confirmați Destinația Corectă

Înainte de a depana nginx, confirmați că domeniul trimite efectiv vizitatori pe serverul pe care credeți că se află. Acest lucru este deosebit de important după migrări, schimbări de IP, ajustări CDN sau edite parțiale de înregistrări.

Verificați mai întâi înregistrările publice:

dig +short A example.com
dig +short AAAA example.com

Aceste două linii răspund la o întrebare foarte practică: unde crede internetul că se află example.com chiar acum? O formă comună de eșec este aceea că SSH prin IP ajunge la noul VPS, dar domeniul încă indică adresa veche. Alta este aceea că înregistrarea A a fost actualizată, dar înregistrarea AAAA încă indică ceva învechit. În acest caz, doar o parte din traficul dvs. eșuează.

📝 Notă: curl --resolve este mai sigur decât schimbarea DNS-ului public în mijlocul unui incident. Vă permite să testați originea pe care intenționați să o utilizați, păstrând în același timp hostname-ul și SNI intacte.

Utilizați curl --resolve pentru a forța un test împotriva IP-ului pe care îl așteptați fără a atinge înregistrările publice:

curl --resolve example.com:443:203.0.113.10 https://example.com/

Dacă aceasta funcționează în timp ce domeniul public încă eșuează, serverul poate fi în regulă și DNS poate fi încă stratul defect. O notă CDN limitată merită să fie ținută în minte aici. Dacă originea dvs. este blocată pentru a accepta trafic doar din intervale IP CDN, un test direct-origin poate eșua pur și simplu pentru că originea așteaptă trafic de margine, nu cereri publice arbitrare. Odată ce destinația este confirmată, următoarea întrebare este dacă ceva util răspunde pe 80 sau 443 acolo.

Pasul 3: Verificați Ce Ascultă pe 80/443

Acum treceți pe server și puneți o întrebare precisă: există cu adevărat ceva care acceptă conexiuni web pe porturile așteptate? Mașina poate fi vie, SSH poate funcționa și chiar nginx poate fi instalat. Totuși, porturile web publice pot să nu aibă niciun listener util.

Verificați mai întâi listenerele:

sudo ss -ltnp

Ieșire goală pentru :80 sau :443 înseamnă că nimic util nu ascultă acolo. Un listener pe 127.0.0.1 înseamnă că serviciul acceptă conexiuni doar de pe mașina locală. Un listener pe 0.0.0.0 înseamnă că este legat pe interfețele IPv4. [::] de obicei înseamnă interfețe IPv6. Nu presupuneți că legarea IPv6 garantează automat calea IPv4 de care aveți nevoie.

Apoi utilizați un mic pachet de sănătate nginx înainte de a schimba ceva:

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• Dacă systemctl spune active (running), asta doar dovedește că procesul serviciului există
• nginx -t vă spune dacă configurația este validă
• journalctl arată dacă o reîncărcare recentă a eșuat, un fișier de certificat a dispărut, sau un vhost s-a rupt la pornire.

Pentru cititorii Apache, sintaxa echivalentă de verificare este apachectl configtest. Odată ce știți că ceva ascultă, următoarea dovadă este mai specifică: răspunde site-ul corect local când eliminați rețeaua externă din ecuație?

💡 Sfat: Testați mai întâi configurația, apoi preferați reload în loc de o repornire oarbă atunci când este cazul. O reîncărcare validează noua configurație și păstrează vechii workeri dacă noua configurație este rea; o repornire oarbă este mult mai dură în mijlocul unui incident.

Pasul 4: Testați Site-ul Local cu Host-ul și SNI Corect

Aceasta este cea mai importantă bifurcație din întreaga investigație. Un simplu curl 127.0.0.1 poate fi înșelător. Multe servere găzduiesc mai multe site-uri și aleg răspunsul pe baza header-ului Host sau, pentru HTTPS, SNI. Nu întrebați dacă ceva răspunde local. Întrebați dacă calea corectă a site-ului răspunde local.

Utilizați teste locale care păstrează logica hostname-ului:

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Un succes semnificativ este pagina așteptată, redirecționarea așteptată sau răspunsul aplicației așteptat din site-ul corect. Nu este host-ul nginx implicit, certificatul greșit sau un generic “a returnat HTML”. De aici sunt trei rezultate clare: succes local, comportament local cu site greșit sau certificat implicit, sau eșec/timeout local. Un rezultat local bun vă îndreaptă spre firewall, furnizor, CDN sau verificări de rutare. Un rezultat local rău vă ține în interiorul stack-ului, în ramurile upstream sau TLS.

Pasul 5: Dacă funcționează local dar nu extern, urmărește calea rețelei

Odată ce testul local este bun, încetează să mai pui la îndoială nginx pentru o clipă. Stiva site-ului este probabil vie pe server, iar piesa lipsă se află de obicei undeva între vizitator și acel serviciu local care funcționează. Începe cu firewall-ul gazdei pentru că este cea mai apropiată limită externă pe care o controlezi.

Inspectează regulile din partea gazdei cu instrumentul pe care sistemul tău îl folosește de fapt, și fă o verificare rapidă de bun simț pentru blocarea auto-inflictă în timp ce ești acolo:

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

Acea ieșire arată doar stratul guest OS. Nu arată filtrarea din partea furnizorului, grupurile de securitate sau regulile firewall-ului la nivel de panou care trăiesc în afara VPS-ului în sine. Pe un VPS AlexHost, de exemplu, firewall-ul mașinii și orice controale de rețea la nivel de panou sunt întrebări separate. Ambele contează atunci când testele locale funcționează dar vizitatorii publici încă eșuează.

⚠️ Avertisment: Dacă Docker publică porturi pe gazdă, nu presupune că ieșirea UFW spune toată povestea. Docker poate ruta traficul containerului publicat prin NAT înainte de lanțurile obișnuite ale UFW. Asta înseamnă că “UFW arată bine” nu înseamnă întotdeauna că calea pachetului este bună.

CDN-urile și load balancer-ele merită propria ramură aici și ele. Originea poate fi sănătoasă și totuși inaccesibilă direct pentru că doar intervalele IP de margine sunt autorizate să vorbească cu ea. Atunci când ai nevoie de dovezi dacă pachetele ajung deloc, folosește tcpdump ca instrument da-sau-nu:

📝 Notă: Un test direct-origin eșuat în spatele unei liste de permisiuni CDN de obicei indică politica marginii, nu o origine moartă. În acea configurație, originea este proiectată să aibă încredere în calea CDN, nu în fiecare vizitator direct.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Dacă nu vezi deloc pachete SYN, traficul nu ajunge pe server. Dacă SYN-urile sosesc și nu pleacă SYN-ACK, serverul sau calea firewall-ului încă blochează transferul. Dacă niciun model nu pare să fie blocantul, eșecurile rămase de obicei se află în spatele frontend-ului în transferul upstream.

Pasul 6: Dacă Frontend-ul Răspunde dar Site-ul Este Încă Defect, Urmărește Upstream

În această ramură, serverul web este accesibil, dar următorul hop din spatele acestuia nu este suficient de sănătos pentru a completa cererea. Aici, “upstream” înseamnă serviciul căruia nginx îi transmite cererea mai departe: un proces de aplicație, o execuție susținută de socket, un container, sau o altă dependență internă.

Paginile statice funcționând în timp ce login, căutare, checkout, sau rutele API eșuează este un indiciu puternic că frontend-ul este prezent și eșecul începe la transferul din spatele acestuia.

📝 Notă: Tratează 502 ca “următorul hop a răspuns prost” și 504 ca “următorul hop a răspuns prea lent.” Ambele sunt semne să urmărești calea upstream mai degrabă decât să te oprești la frontend.

Inspectează transferul activ, apoi testează upstream-ul direct:

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

În ieșirea nginx, caută directive cum ar fi proxy_pass, fastcgi_pass, sau uwsgi_pass. Verifici dacă nginx indică către ținta corectă, peste protocolul corect, pe portul sau socketul corect. Dacă sunt implicați containere, adaugă o scurtă verificare de sănătate a containerului în loc să ghicești:

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Dacă testul direct al aplicației eșuează, problema este din spatele serverului web. Dacă funcționează direct dar eșuează prin nginx, configurația transferului este ramura de inspectat. Accesibilitatea bazei de date contează doar ca o verificare de dependență aici, nu ca o analiză separată aprofundată. Dacă acest model de eșec upstream continuă să se repete, acela este momentul potrivit pentru a trece la un ghid de depanare dedicat în loc să transformi un incident în speculații.

Pasul 7: Izolați erorile TLS și de certificat

Această ramură este mai îngustă: ceva răspunde pe 443, dar browserul încă nu poate completa o sesiune HTTPS curată și de încredere. O conexiune TCP reușită la portul 443 nu dovedește că certificatul, potrivirea numelui de gazdă sau calea handshake-ului este sănătoasă.

Inspectați ce certificat este de fapt servit:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

Aici este locul în care prindeți formele comune de eșec: gazdă greșită, certificat expirat, lanț incomplet sau o reînnoire care nu s-a terminat curat. În cuvinte simple, SNI spune serverului ce nume de gazdă ați intenționat. -verify_hostname verifică dacă certificatul pe care l-a servit se potrivește cu acel nume de gazdă. După recuperare, validați calea de reînnoire pentru ca aceasta să nu devină următoarea întrerupere:

⚠️ Avertisment: Dacă vă bazați pe validarea HTTP-01 pentru reînnirea certificatului, portul de intrare 80 trebuie să fie accesibil. O regulă de firewall sau furnizor care blochează 80 poate rupe în liniște reînnirile cu mult înainte ca utilizatorii să raporteze că HTTPS arată mort.

sudo certbot renew --dry-run

Pasul 8: Verificați Presiunea Resurselor Înainte să Declarați Eșecul Aleatoriu

Unele incidente nu sunt deloc eșecuri de accesibilitate. Calea este din punct de vedere tehnic intactă, dar serverul este prea epuizat, blocat sau supraîncărcat pentru a răspunde la timp. Atunci este când un site poate arăta „parțial viu” dintr-un unghi și totuși poate părea mort pentru utilizatori.

Executați un mic pachet de resurse pentru prima trecere:

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Citiți rezultatele în modele, nu izolat.

• df -h arată epuizarea obișnuită a discului.
• df -i detectează epuizarea inode-urilor, unde spațiul pare să existe, dar sistemul de fișiere nu poate crea mai multe intrări.
• free -h contează cel mai mult atunci când memoria disponibilă se prăbușește și activitatea swap crește.
• uptime poate arăta o sarcină ridicată chiar și atunci când CPU nu este la maxim, ceea ce adesea înseamnă că sarcinile așteaptă pe presiunea discului sau memoriei mai degrabă decât calcul activ.
• Liniile din jurnalul kernel despre evenimente OOM vă spun dacă sistemul a început să ucidă procese pentru a supraviețui.

Graficele furnizorului pot confirma cronologia. Pe un VPS AlexHost, pot fi utile pentru a verifica dacă vârfurile în RAM, disc sau I/O se aliniază cu întreruperea. Dar dovezile din terminal ar trebui să conducă în continuare diagnosticul. Această secțiune nu este un ghid de reglare; este ramura care vă spune că site-ul poate eșua sub presiune mai degrabă decât să eșueze în rutare.

Gândește-te în Straturi, Nu în Panică

Când SSH funcționează dar site-ul nu se deschide, ține lanțul scurt și repetabil:

1. reproduceți eșecul extern
2. identificați ultima etapă reușită
3. confirmați DNS și destinația
4. verificați un listener real pe 80/443
5. testați site-ul corect local
6. ramificați-vă în cale de rețea, upstream, TLS sau resurse

💡 Sfat: Nu închideți ultima sesiune SSH care funcționează până nu ați confirmat că o nouă conectare încă funcționează și mai aveți o cale de acces de rezervă, cum ar fi accesul consolei furnizorului. În timpul unui incident live, păstrarea controlului contează la fel de mult ca și repararea primului simptom.

Păstrați obiceiurile ușoare: monitorizați extern, păstrați jurnale și testați certificatele cu certbot renew –dry-run. Securizați accesul cu copii de rezervă și o cale de consolă. Instrumentele furnizorului — firewall, grafice, consolă (inclusiv AlexHost) — ar trebui să susțină depanarea, nu să o înlocuiască. Concentrați-vă pe repararea primului strat defect, astfel încât fiecare incident să fie gestionat cu dovezi mai clare și mai puțină panică.