Site-ul nu se deschide

Când site-ul de pe serverul dvs. BLACKBOX nu se deschide, parcurgeți verificările de mai jos în ordine: fiecare exclude o cauză. Comenzile din pașii 1, 2 și 9 și cele trei teste cu curl de la final se rulează pe calculatorul dvs.; celelalte, pe server, prin SSH ca root. Adresa serverului este în câmpul „IP” al cardului din pagina „Serverele mele” a panoului app.blackbox.md (app.blackbox.md/my-servers, bara laterală → „Infrastructură” → „Serverele mele”). Panoul nu are setări pentru serverul web, firewall sau certificate.

Disponibil pentru: oricine are acces root prin SSH la un server BLACKBOX. Alte porturi în filtrarea din rețea: la cerere, prin suport.

În comenzi, înlocuiți DOMENIU cu domeniul dvs. și IP_SERVER cu adresa serverului.

Pe scurt: după mesajul din browser

Pasul 1. DNS: domeniul indică serverul

Pe Linux sau macOS:

dig +short DOMENIU
dig +short www.DOMENIU
dig +short DOMENIU AAAA

Pe Windows:

nslookup DOMENIU

Primele două comenzi trebuie să afișeze IP_SERVER (dacă www este un CNAME, întâi apare numele spre care indică, de exemplu DOMENIU.). A treia nu trebuie să afișeze nimic; adrese Cloudflare apar doar când proxy-ul Cloudflare este activ. O înregistrare AAAA rămasă de la vechea găzduire trimite o parte din vizitatori la alt server: ștergeți-o.

Pasul 2. Serverul rulează

ssh root@IP_SERVER

Dacă vă conectați, serverul este pornit și accesibil din rețea. Dacă nu: Nu mă pot conecta prin SSH. Panoul nu arată dacă serverul este pornit; dacă l-ați oprit cu „Oprește”, porniți-l cu „Pornește” de pe cardul lui (Repornirea, oprirea și pornirea serverului).

Pasul 3. Serverul web rulează și ascultă pe 80 și 443

1. Verificați serviciul. Pentru Apache scrieți apache2 (Ubuntu, Debian) sau httpd (AlmaLinux, CentOS Stream) în loc de nginx. Rândul Active: trebuie să arate active (running).

   systemctl status nginx

2. Dacă arată inactive (dead) sau failed, testați configurația („syntax is ok”, „test is successful”; altfel apar fișierul și rândul cu eroarea), apoi porniți serviciul și activați-l la pornirea serverului:

   nginx -t
   systemctl enable --now nginx

   La Apache, testul afișează „Syntax OK”:

   # Ubuntu și Debian
   apache2ctl configtest
   # AlmaLinux și CentOS Stream
   apachectl configtest

3. Verificați cine ascultă pe porturile 80 și 443:

   ss -tlnp | grep -E ':80|:443'

Dacă pe IP se deschide site-ul, dar pe domeniu apare pagina implicită, server_name (nginx) sau ServerName/ServerAlias (Apache) nu conțin DOMENIU și www.DOMENIU. Un disc plin provoacă și el erori: Discul serverului este plin.

Pasul 4. Firewall-ul din sistem permite 80 și 443

BLACKBOX nu activează firewall-ul din sistem pe un server nou. Dacă l-ați activat dvs., verificați-l.

Ubuntu și Debian

ufw status

Status: inactive înseamnă că ufw nu blochează nimic. Dacă este active, în listă trebuie să apară 80 și 443 (de exemplu 80,443/tcp ALLOW Anywhere, Nginx Full sau Apache Full). Altfel:

ufw allow 80,443/tcp

AlmaLinux și CentOS Stream

firewall-cmd --list-all

„FirewallD is not running” înseamnă că firewalld nu blochează nimic. Dacă rulează, în rândul services: trebuie să apară http și https. Altfel:

firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload

Atenție Clienții nu au consolă web sau VNC: serverul se administrează doar prin SSH. Nu ștergeți regula pentru portul 22 și păstrați o a doua sesiune SSH deschisă cât modificați firewall-ul. Detalii: Firewall: filtrarea din rețea și ufw/firewalld pe server.

Pasul 5. Portul este deschis în filtrarea din rețea

Traficul spre server trece și prin filtrarea din rețea administrată de BLACKBOX. Pe un server nou, ea lasă să treacă SSH (22), HTTP (80), HTTPS (443) și ping; panoul nu are setări de firewall. O aplicație pe alt port, de exemplu 3000, 8000 sau 8080, nu este accesibilă din internet, chiar dacă portul este permis în ufw sau firewalld: cererea se termină cu timeout. Aveți două variante:

• recomandat: puneți nginx în față, pe 80 și 443: Aplicații Node.js, Python și alte servicii: nginx ca reverse proxy;
• cereți suportului să deschidă portul: indicați adresa IP a serverului, numărul comenzii (BBX-…), portul, protocolul (TCP sau UDP) și la ce vă trebuie.

Pasul 6. Aplicația ascultă pe adresa potrivită

Verificați adresa pe care ascultă aplicația (aici, portul 3000) și dacă răspunde pe server:

ss -tlnp | grep ':3000'
curl -I http://127.0.0.1:3000

• 127.0.0.1:3000: aplicația primește doar conexiuni de pe server. Corect în spatele nginx (proxy_pass http://127.0.0.1:3000), dar direct din exterior nu este accesibilă.
• 0.0.0.0:3000 sau *:3000: aplicația primește conexiuni din exterior, dacă portul este deschis și în rețea (pasul 5).
• Niciun rând: aplicația nu rulează sau folosește alt port; vedeți jurnalele ei.

Dacă aplicația răspunde pe 127.0.0.1, dar site-ul dă 502 Bad Gateway, verificați adresa și portul din proxy_pass. Pe AlmaLinux și CentOS Stream, „(13: Permission denied)” în /var/log/nginx/error.log înseamnă că SELinux blochează legătura:

setsebool -P httpd_can_network_connect 1

Un container publicat cu -p 127.0.0.1:8080:80 ascultă, la fel, doar local: Instalarea Docker și Docker Compose.

Pasul 7. Certificatul HTTPS este valid

certbot certificates

La certificatul site-ului, Domains: trebuie să conțină DOMENIU (și www.DOMENIU, dacă îl folosiți), iar Expiry Date: trebuie să se termine cu (VALID: … days), nu cu (INVALID: EXPIRED). „No certificates found.” înseamnă că pe server nu s-a emis niciun certificat. Dacă a expirat, testați reînnoirea, reînnoiți-l și reîncărcați serverul web (la Apache, apache2 sau httpd în loc de nginx):

certbot renew --dry-run
certbot renew
systemctl reload nginx

Testul 2 cu curl arată ce certificat primește de fapt vizitatorul. Dacă apare tot cel vechi, serverul web nu a fost reîncărcat sau configurația pentru 443 indică alte fișiere. Erorile certbot: Server web cu HTTPS: nginx sau Apache și Let's Encrypt. Certificat comercial: Certificate SSL: gratuite (Let's Encrypt) și comerciale.

Pasul 8. Erorile Cloudflare

Dacă domeniul trece prin proxy-ul Cloudflare (caseta „Proxy” bifată la înregistrare în pagina „DNS” a panoului sau proxy-ul activat direct în contul Cloudflare), Cloudflare se conectează la serverul dvs. și afișează propria pagină de eroare când nu reușește.

Modul SSL se alege în contul Cloudflare, la „SSL/TLS”; pagina „DNS” a panoului nu îl schimbă. Alegeți „Full (strict)” după ce serverul are un certificat valid (documentația Cloudflare despre modurile SSL). Ca să verificați serverul fără Cloudflare, rulați testul 3 cu curl sau debifați temporar „Proxy”.

Pasul 9. Cache-ul browserului și HSTS

• Deschideți site-ul într-o fereastră privată, în alt browser sau de pe altă rețea (de exemplu cu datele mobile) și comparați cu testele cu curl de mai jos.

• După o schimbare de DNS, pe Windows goliți cache-ul DNS:

  ipconfig /flushdns

• HSTS: un site care a trimis antetul Strict-Transport-Security se deschide doar prin HTTPS, iar browserul nu vă lasă să treceți peste o eroare de certificat. Soluția este un certificat valid (pasul 7).

Trei teste cu curl

Rulați-le pe calculatorul dvs. În Windows PowerShell scrieți curl.exe în loc de curl.

1. Serverul web răspunde pe IP, fără DNS:

   curl -I http://IP_SERVER

   Orice răspuns HTTP (200, 301, 403, 404): serverul, rețeaua și portul 80 sunt în regulă. Eroare imediată (Connection refused, Couldn't connect to server): nimic nu ascultă pe 80 (pasul 3). Timeout după o așteptare lungă: pachetele sunt oprite (pașii 2, 4, 5).

2. Ce primește un vizitator:

   curl -vk https://DOMENIU

   -k continuă chiar dacă certificatul nu este valid. Connected to DOMENIU (…) port 443 arată adresa la care a ajuns cererea. subject: și expire date: arată numele din certificat și data expirării (curl pe Windows poate să nu le afișeze). Rândul < HTTP… arată codul de răspuns.

3. Serverul dvs., ocolind DNS-ul și Cloudflare (--resolve trimite cererea direct la IP_SERVER, cu numele domeniului):

   curl -I --resolve DOMENIU:443:IP_SERVER https://DOMENIU

Sfat Dacă testul 3 reușește, dar testul 2 nu, serverul este în regulă: problema este în DNS (pasul 1) sau în Cloudflare (pasul 8). Dacă testul 3 dă o eroare de certificat, reparați certificatul (pasul 7).

Jurnalele

Ultimele rânduri ale jurnalului serverului web și ale serviciului:

tail -n 50 /var/log/nginx/error.log
journalctl -u nginx -n 50 --no-pager

Jurnalele aplicației: pentru un serviciu systemd, prima comandă; pentru un container, a doua; pentru Docker Compose, a treia, din directorul proiectului.

journalctl -u NUME_SERVICIU -n 100 --no-pager
docker logs --tail 100 NUME_CONTAINER
docker compose logs --tail 100

Când scrieți suportului

Dacă toate verificările trec și site-ul tot nu se deschide din exterior, scrieți-ne: Deschiderea unui tichet de suport. Includeți domeniul, adresa IP a serverului, numărul comenzii (BBX-…), rezultatul celor trei teste cu curl și ce ați verificat deja.

Întrebări frecvente

Site-ul a funcționat, apoi s-a oprit fără să schimb nimic. Cauzele frecvente sunt un certificat expirat (pasul 7), un disc plin (Discul serverului este plin) și o aplicație oprită (pașii 3 și 6). Dacă problema a apărut după o repornire, probabil serviciul nu era activat la pornire: activați-l pentru serverul web și pentru aplicație, ca la pasul 3.

Site-ul merge pe telefon, dar nu pe calculatorul meu. Cauza este pe calculator sau în rețeaua dvs.: cache-ul DNS sau al browserului, ori o intrare veche pentru domeniu în fișierul hosts (C:\Windows\System32\drivers\etc\hosts pe Windows, /etc/hosts pe Linux și macOS). Vedeți pasul 9.

Am un plan „VPS hosting” cu panou de control. Dacă pe server rulează un panou de control, site-urile, serverul web și certificatele se administrează din el; nu instalați alt server web peste el. Testele cu dig și curl rămân valabile. Ce panou este instalat și cum intrați în el aflați de la suport: Planurile „VPS hosting” cu panou de control.