modul 00 / cum ajunge un site la utilizator
călătoria unei cereri web
Înainte de a cumpăra un hosting sau de a configura ceva, merită să înțelegi ce se întâmplă exact când cineva scrie o adresă în browser. Aproape toate problemele pe care le vei depana sunt undeva pe acest traseu.
traseul, pas cu pas
- Utilizatorul scrie romeo.studio în browser.
- DNS — browserul întreabă „ce adresă IP are acest domeniu?" și primește ceva de forma 203.0.113.45.
- Conexiune — browserul deschide o conexiune către acel IP, pe portul 443 (HTTPS).
- Cerere — trimite o cerere HTTP: „dă-mi pagina /despre".
- Serverul primește cererea, o procesează (fie servește un fișier gata făcut, fie construiește pagina pe loc) și trimite un răspuns.
- Browserul primește HTML-ul, apoi cere resursele suplimentare (CSS, JS, imagini) și afișează pagina.
Browser ──DNS?──► Server DNS
◄──IP────
Browser ──GET /despre──► Server web (hostingul tău)
◄──200 OK + HTML──
cele trei piese pe care le plătești
| Piesă | Ce e | Analogia |
|---|
| Domeniul | Numele: romeo.studio | Adresa poștală |
| DNS | Sistemul care leagă numele de IP | Cartea de telefon |
| Hostingul | Serverul unde stau fișierele | Casa propriu-zisă |
Sunt servicii separate și pot fi la furnizori diferiți. Poți cumpăra domeniul dintr-un loc, ține DNS-ul în altul și hostingul în al treilea. Această separare încurcă la început, dar e și ce-ți dă flexibilitate: poți schimba hostingul fără să schimbi domeniul.
de ce contează traseul
Când un site „nu merge", prima întrebare de diagnostic e unde s-a rupt lanțul: domeniul a expirat? DNS-ul arată spre alt server? serverul e oprit? aplicația dă eroare? Fiecare pas are simptome diferite, iar dacă știi traseul, elimini rapid trei sferturi din posibilități. Cei care nu-l știu ghicesc la întâmplare ore în șir.
de reținut
O cerere web trece prin: DNS (nume → IP) → conexiune la server → cerere HTTP → răspuns → afișare. Cele trei piese pe care le plătești sunt domeniul (numele), DNS-ul (cartea de telefon) și hostingul (casa) — servicii separate, posibil la furnizori diferiți. Cunoașterea traseului e cea mai valoroasă unealtă de depanare pe care o vei avea.
modul 00 / cum ajunge un site la utilizator
ce e un server & static vs dinamic
ce e, de fapt, un server
Un server e un calculator care rulează non-stop și răspunde la cereri. Nu are nimic magic — diferența față de laptopul tău e că e pornit permanent, are o conexiune bună și o adresă IP publică pe care lumea o poate accesa.
Pe el rulează un server web (programul propriu-zis): Nginx sau Apache sunt cele mai răspândite. Rolul lui: primește cereri HTTP și decide ce trimite înapoi.
site static vs site dinamic — distincția fundamentală
| Static | Dinamic |
|---|
| Ce trimite serverul | Fișiere gata făcute (HTML, CSS, JS) | Pagini construite la fiecare cerere |
| Are nevoie de | Doar spațiu și un server web | Un limbaj (PHP, Node…) + de obicei o bază de date |
| Viteză | Foarte rapid | Depinde de cod și bază de date |
| Securitate | Suprafață mică de atac | Mai multe puncte vulnerabile |
| Cost | Adesea gratuit | Mai mare |
| Exemple | Portofoliu, prezentare, documentație, blog generat | WordPress, magazin online, aplicație cu conturi |
greșeala costisitoare
Foarte mulți oameni plătesc hosting cu PHP și bază de date pentru un site de prezentare care ar putea fi perfect static. Un site static poate fi găzduit gratuit (Cloudflare Pages, Netlify, GitHub Pages), încarcă mai repede, nu poate fi spart prin plugin-uri vulnerabile și nu are nevoie de actualizări de securitate. Întreabă-te mereu întâi: chiar am nevoie de dinamic?
când ai nevoie cu adevărat de dinamic
- Utilizatorii se autentifică și au conturi.
- Conținutul se schimbă des și e editat de oameni non-tehnici (un CMS).
- Ai nevoie de căutare complexă, filtre, coș de cumpărături, plăți.
- Conținutul e personalizat per vizitator.
Un formular de contact nu te obligă la hosting dinamic — există servicii care preiau formularele de pe site-uri statice.
termeni pe care îi vei întâlni
| Termen | Înseamnă |
|---|
| Uptime | Procentul din timp în care serverul e disponibil (99,9% e standardul decent) |
| Lățime de bandă | Volumul de date transferat lunar |
| Spațiu | Cât loc au fișierele tale |
| TTFB | Timpul până la primul byte — cât de repede începe serverul să răspundă |
de reținut
Un server e doar un calculator pornit permanent, cu IP public, care rulează un server web (Nginx/Apache). Distincția care contează cel mai mult economic e static vs dinamic: un site static (fișiere gata făcute) poate fi găzduit gratuit, e mai rapid și mult mai greu de spart. Ai nevoie de dinamic doar dacă ai conturi, CMS, coș sau conținut personalizat — nu doar pentru un formular de contact.
modul 01 / domenii & DNS
domenii: cum le cumperi & cum le păstrezi
Un domeniu e numele prin care lumea îți găsește site-ul. Nu îl cumperi definitiv — îl închiriezi anual de la un registrar (firmă acreditată să înregistreze domenii).
anatomia unui domeniu
academy.romeo.studio
│ │ └─ TLD (extensia): .studio
│ └──────── domeniul propriu-zis: romeo
└──────────────── subdomeniu: academy
- TLD — extensia: .com, .ro, .md, .studio. Unele au cerințe speciale (ex: TLD-uri naționale pot cere prezență locală).
- Subdomeniile sunt gratuite — odată ce ai romeo.studio, poți crea oricâte (academy., blog., test.) fără costuri suplimentare.
reguli practice la alegere
- Scurt și ușor de dictat la telefon — dacă trebuie să explici cum se scrie, e prea complicat.
- Evită cratimele și cifrele — sursă constantă de confuzie.
- Verifică-l pe toate canalele — să nu fie deja o marcă înregistrată.
- TLD-ul contează mai puțin decât crezi pentru SEO; contează pentru încredere și context.
trei lucruri care te pot costa domeniul
- Reînnoirea automată dezactivată — domeniul expiră, cineva îl cumpără, iar recuperarea e scumpă sau imposibilă. Activeaz-o.
- Email de contact vechi — notificările de expirare ajung într-o căsuță pe care n-o mai citești.
- Domeniul înregistrat pe numele altcuiva (o agenție, un fost coleg) — juridic, nu e al tău. Verifică mereu că tu ești proprietarul înregistrat, nu doar cel care plătește.
protecția datelor & blocarea transferului
- WHOIS privacy — ascunde datele tale personale din registrul public. De obicei gratuită.
- Blocarea transferului — împiedică mutarea domeniului la alt registrar fără acordul tău. Ține-o activă.
de reținut
Un domeniu se închiriază anual de la un registrar — subdomeniile sunt gratuite odată ce ai domeniul principal. Alege ceva scurt, ușor de dictat, fără cratime. Cele trei riscuri reale: reînnoire automată dezactivată, email de contact învechit și — cel mai grav — domeniul înregistrat pe numele altcuiva. Verifică întotdeauna că tu ești proprietarul, nu doar plătitorul.
modul 01 / domenii & DNS
DNS: înregistrările pe care le vei folosi
DNS (Domain Name System) e sistemul care traduce numele în adrese IP. Practic, e cartea de telefon a internetului — și locul unde se fac cele mai multe greșeli de configurare.
nameservers — cine comandă
Nameserver-ele sunt serverele care dețin înregistrările DNS ale domeniului tău. Setate la registrar, ele spun „autoritatea pentru acest domeniu e aici". E prima decizie: DNS-ul poate fi la registrar, la firma de hosting sau la un serviciu specializat (ex: Cloudflare).
confuzia numărul unu
Oamenii modifică înregistrările DNS în panoul hostingului, dar nameserver-ele domeniului arată spre altcineva (registrar sau Cloudflare). Rezultat: modificările nu au niciun efect, iar omul crede că „DNS-ul nu se propagă". Regula: modifici acolo unde arată nameserver-ele. Verifică întâi unde e autoritatea, apoi editează.
tipurile de înregistrări
| Tip | Ce face | Exemplu |
|---|
| A | Nume → adresă IPv4 | romeo.studio → 203.0.113.45 |
| AAAA | Nume → adresă IPv6 | romeo.studio → 2001:db8::1 |
| CNAME | Nume → alt nume (alias) | academy → studio-academy.pages.dev |
| MX | Unde se livrează emailul | → serverele de mail |
| TXT | Text liber: verificări, SPF, DKIM | v=spf1 include:… |
| NS | Cine e autoritatea DNS | ns1.exemplu.com |
A vs CNAME — când folosești care
- A — când știi adresa IP a serverului (hosting clasic, VPS).
- CNAME — când furnizorul îți dă un nume, nu un IP (platforme moderne: Pages, Netlify, Vercel). Avantaj: dacă furnizorul își schimbă IP-urile, nu trebuie să faci nimic.
Regulă importantă: nu poți pune CNAME pe domeniul rădăcină (romeo.studio, fără www) în DNS clasic — doar pe subdomenii. Multe servicii moderne rezolvă asta prin mecanisme proprii (CNAME flattening), dar e o sursă clasică de confuzie.
TTL & propagarea
TTL (time to live) spune cât timp poate fi păstrată în memorie o înregistrare, în secunde. Un TTL de 3600 înseamnă că serverele pot ține răspunsul o oră înainte să întrebe din nou.
„propagarea DNS" — ce e de fapt
Nu e o undă care se răspândește prin lume. Serverele DNS din diverse locuri au copii în memorie cu vechimi diferite; ele expiră treptat, conform TTL-ului. De aceea unii văd site-ul nou și alții pe cel vechi.
Trucul profesionist: cu 24 de ore înainte de o migrare, scazi TTL-ul la 300 de secunde. La schimbare, toată lumea vede noua valoare în 5 minute în loc de 24 de ore. După ce s-a stabilizat, îl ridici înapoi.
de reținut
Nameserver-ele decid cine deține DNS-ul — modifică înregistrările acolo unde arată ele, altfel schimbările n-au efect (greșeala numărul unu). Înregistrările esențiale: A (nume→IP), CNAME (nume→nume, ideal pentru platforme moderne), MX (email), TXT (verificări și SPF). Iar „propagarea" e doar expirarea copiilor din memorie conform TTL — scade-l înainte de migrări.
modul 02 / tipuri de hosting & cum alegi
tipurile de hosting
„Hosting" acoperă lucruri foarte diferite ca preț, control și responsabilitate. Alegerea greșită înseamnă fie bani aruncați, fie un site care cade la primul val de vizitatori.
comparația principalelor tipuri
| Tip | Cum funcționează | Pentru cine |
|---|
| Static | Fișiere servite dintr-o rețea globală; adesea gratuit | Prezentare, portofoliu, documentație, blog generat |
| Shared | Multe site-uri pe același server, resurse împărțite | Site-uri mici WordPress, buget minim |
| VPS | O felie garantată dintr-un server, cu acces root | Aplicații serioase, control total |
| Managed | Specializat (ex: WordPress), cu întreținere inclusă | Cine vrea performanță fără administrare |
| Cloud | Resurse scalabile, plătești ce consumi | Trafic variabil, aplicații care cresc |
| Dedicat | Un server fizic întreg, doar al tău | Cerințe mari sau de conformitate |
shared hosting: ce trebuie să știi
- Ieftin și simplu — panou de control, instalare WordPress dintr-un clic, potrivit pentru început.
- „Nelimitat" nu există — ofertele cu spațiu și trafic „nelimitate" au limite reale ascunse în termeni (număr de fișiere, procese, CPU). Le atingi exact când site-ul începe să meargă bine.
- Vecinii contează — dacă alt site de pe același server consumă mult, resimți și tu.
- Control limitat — nu poți instala orice, versiunile sunt impuse.
VPS: control cu responsabilitate
Primești o felie garantată dintr-un server și acces root. Poți instala orice. În schimb, tu ești administratorul: actualizări de securitate, configurare, backup, monitorizare. Dacă nu ai aceste competențe (sau timp), un VPS prost întreținut e mai riscant decât un shared bine gestionat. Acesta e subiectul cursului de hosting avansat.
alegerea care se ratează cel mai des
Pentru un site static — prezentare, portofoliu, documentație — hostingul specializat (Cloudflare Pages, Netlify, GitHub Pages) e gratuit, servit dintr-o rețea globală (deci rapid oriunde în lume), cu HTTPS automat și fără nimic de întreținut. Mulți plătesc ani în șir pentru shared hosting cu PHP și MySQL pentru un site care n-are nevoie de niciunul. Începe prin a stabili dacă site-ul tău e static — restul deciziei devine simplu.
de reținut
Static (gratuit, rapid, zero întreținere) → prezentare și documentație. Shared (ieftin, simplu, limite reale în spatele cuvântului „nelimitat") → site-uri mici cu CMS. VPS (control total, dar tu ești administratorul) → aplicații serioase. Managed/cloud → performanță și scalare fără administrare. Prima întrebare care simplifică toată decizia: site-ul meu chiar are nevoie de server dinamic?
modul 02 / tipuri de hosting & cum alegi
criterii de alegere & ce te costă cu adevărat
criteriile care contează
| Criteriu | De ce contează |
|---|
| Locația serverelor | Mai aproape de vizitatori = latență mai mică. Pentru public din Moldova/România, servere europene |
| Uptime garantat | 99,9% e decent (≈8 ore/an oprire); 99,99% e foarte bun |
| Backup | Automat, zilnic, cu restaurare ușoară — verifică dacă e inclus sau costă separat |
| Suport | Timp real de răspuns, în limba în care poți explica problema |
| HTTPS inclus | Trebuie să fie gratuit și automat; dacă se plătește separat, e semnal prost |
| Migrare ușoară | Cât de simplu poți pleca — evită capcanele de blocare |
capcane de preț
- Prețul promoțional — 1 €/lună primul an, apoi de patru ori mai mult. Uită-te mereu la prețul de reînnoire.
- Angajament pe 3 ani pentru prețul afișat — plătești tot în avans.
- Extra-uri obligatorii — backup, certificat, protecție anti-spam, taxate separat.
- Depășirea limitelor — taxe suplimentare când crești.
costul ascuns pe care nimeni nu-l calculează
Timpul tău. Un VPS la 5 €/lună pare mai ieftin decât un managed la 25 €. Dar dacă petreci 4 ore pe lună cu actualizări, configurări și depanare, ai plătit de fapt mult mai mult — și porți și riscul unei breșe de securitate. Alege în funcție de ce vrei să administrezi, nu doar de prețul afișat.
drumul recomandat
- Site static? → hosting static gratuit. Oprește-te aici, e suficient.
- WordPress mic? → shared decent sau managed ieftin.
- Aplicație proprie / trafic serios? → VPS sau cloud.
- Nu vrei să administrezi nimic? → managed, plătești liniștea.
semne că trebuie să schimbi hostingul
- Site-ul e constant lent, deși ai optimizat imaginile și caching-ul.
- Cade în vârfurile de trafic — exact când ai nevoie de el.
- Atingi limitele (procese, CPU) și primești avertismente.
- Suportul nu răspunde sau răspunde inutil.
- Nu poți instala ce ai nevoie (o versiune de PHP, o extensie).
de reținut
Alege după locația serverelor (aproape de public), uptime, backup inclus, HTTPS gratuit și ușurința de a pleca. Atenție la prețul de reînnoire, nu la cel promoțional. Iar costul cel mai des ignorat e timpul tău: un VPS ieftin pe care îl administrezi 4 ore pe lună e mai scump decât un managed. Drumul simplu: static gratuit → shared/managed pentru CMS → VPS/cloud pentru aplicații serioase.
modul 03 / panouri de control, fișiere & permisiuni
panouri de control & transferul fișierelor
Odată ce ai hosting, trebuie să pui fișierele pe server. Există câteva moduri, cu compromisuri diferite între comoditate și control.
panoul de control
Majoritatea hostingurilor partajate oferă o interfață web (cPanel, Plesk, DirectAdmin sau una proprie) de unde faci aproape tot:
| Secțiune | Ce faci acolo |
|---|
| File Manager | Încarci, editezi, ștergi fișiere direct din browser |
| Baze de date | Creezi baze MySQL, utilizatori, parole |
| Email | Căsuțe pe domeniul tău, redirecționări |
| Domenii | Domenii adiționale, subdomenii, redirecționări |
| SSL/TLS | Instalezi certificatul (ideal, automat) |
| Backup | Creezi și restaurezi copii |
FTP vs SFTP
| FTP | SFTP |
|---|
| Criptare | Niciuna — parola circulă în clar | Criptat (peste SSH) |
| Port tipic | 21 | 22 |
| Recomandare | ❌ De evitat | ✅ Folosește-l |
de ce FTP simplu e periculos
FTP trimite utilizatorul și parola în text clar. Oricine ascultă traficul (rețea publică, wifi de cafenea) le poate citi. Folosește SFTP sau FTPS. Dacă furnizorul tău oferă doar FTP simplu, e un semnal serios despre calitatea lui.
clienți & metode moderne
- FileZilla, Cyberduck, WinSCP — clienți grafici clasici pentru SFTP.
- Git deploy — modern și mult mai bun: publici prin push, ai istoric și poți reveni ușor la o versiune anterioară.
- CI/CD — publicare automată la fiecare modificare (subiectul cursului avansat).
Transferul manual prin FTP e sursa clasică a problemei „pe server e altă versiune decât la mine și nimeni nu știe de ce". Cu Git, întrebarea dispare.
de reținut
Panoul de control (cPanel/Plesk) e centrul: fișiere, baze de date, email, domenii, SSL, backup. Pentru transfer, folosește SFTP, niciodată FTP simplu — acesta trimite parola în clar. Iar dacă poți, treci la publicare prin Git: obții istoric, reversibilitate și scapi definitiv de întrebarea „ce versiune e pe server?".
modul 03 / panouri de control, fișiere & permisiuni
structura, permisiuni & .htaccess
unde pui fișierele
Serverul servește dintr-un folder anume, numit document root. Numele diferă:
public_html/ # cPanel (cel mai frecvent)
www/ sau htdocs/ # alte panouri
/var/www/html/ # server Linux clasic
Ce pui acolo devine public. Un fișier public_html/despre.html e accesibil la site.ro/despre.html. Fișierul index.html (sau index.php) e cel servit automat când cineva deschide un folder.
regula de aur a securității fișierelor
Nu pune niciodată în document root ce nu trebuie să fie public: copii de siguranță (backup.zip), fișiere de configurare cu parole, exporturi de bază de date (.sql), arhive vechi. Sunt accesibile oricui ghicește numele — și există scripturi automate care exact asta fac, toată ziua. Un backup.zip uitat în public_html e una dintre cele mai frecvente cauze de compromitere.
permisiuni
Pe Linux, fiecare fișier are permisiuni pentru trei categorii: proprietar, grup, alții. Notate cu cifre:
| Valoare | Înseamnă | Se folosește pentru |
|---|
| 644 | Proprietarul scrie, restul citesc | Fișiere obișnuite |
| 755 | Proprietarul scrie, restul citesc și intră | Foldere |
| 600 | Doar proprietarul | Fișiere de configurare cu parole |
| 777 | Oricine poate orice | ❌ Niciodată |
777 — „soluția" care creează problema
Când ceva nu funcționează, primul sfat găsit pe forumuri e „pune 777". Uneori pare că rezolvă — dar înseamnă că orice proces de pe server poate modifica acel fișier, inclusiv un script rău intenționat urcat prin altă breșă. E o rețetă clasică pentru compromiterea site-ului. Regula sănătoasă: 644 pentru fișiere, 755 pentru foldere, iar dacă tot nu merge, problema e proprietarul fișierului, nu permisiunile.
.htaccess — configurare pe Apache
Pe serverele Apache (majoritatea shared hosting), fișierul .htaccess îți permite să configurezi comportamentul fără acces la server:
# forțez HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# pagină de eroare proprie
ErrorDocument 404 /404.html
# blochez accesul la un fișier sensibil
<Files ".env">
Require all denied
</Files>
- Redirecționări — vechi → nou, cu cod 301 (permanent, transferă valoarea SEO).
- Forțarea HTTPS și a variantei cu sau fără www (alege una și fii consecvent).
- Protejarea fișierelor sensibile.
- Atenție: o greșeală de sintaxă în .htaccess dărâmă tot site-ul cu eroare 500. Păstrează o copie înainte de a-l modifica.
de reținut
Fișierele publice merg în document root (public_html) — și nimic care nu trebuie să fie public nu are ce căuta acolo: backup-uri, .sql, configurări cu parole sunt găsite de scripturi automate. Permisiuni: 644 pentru fișiere, 755 pentru foldere, niciodată 777. Iar .htaccess îți dă redirecționări, forțarea HTTPS și protecție — dar o greșeală de sintaxă oprește tot site-ul, deci fă o copie înainte.
modul 04 / HTTPS & certificate SSL
ce face HTTPS & cum obții certificatul
HTTPS criptează traficul dintre browser și server. Nu mai e opțional: browserele marchează site-urile fără HTTPS drept „nesigure", iar motoarele de căutare le penalizează.
ce garantează, de fapt
| Garanție | Înseamnă |
|---|
| Confidențialitate | Nimeni de pe traseu nu poate citi ce se transmite (parole, date de card) |
| Integritate | Nimeni nu poate modifica conținutul pe drum (ex: injecta reclame) |
| Autenticitate | Confirmă că vorbești chiar cu serverul acelui domeniu |
ce NU garantează HTTPS
Lacătul verde nu înseamnă că site-ul e de încredere — înseamnă doar că legătura e criptată. Un site de escrocherie poate avea perfect HTTPS (și îl are, aproape întotdeauna). HTTPS protejează transportul, nu conținutul. Aceasta e una dintre cele mai răspândite confuzii în rândul utilizatorilor.
obținerea certificatului
- Let's Encrypt — autoritate gratuită, standard în industrie. Certificatele durează 90 de zile și se reînnoiesc automat.
- Majoritatea hostingurilor moderne îl instalează și reînnoiesc singure — nu trebuie să faci nimic.
- Platformele statice (Pages, Netlify) îl configurează automat la adăugarea domeniului.
Certificatele plătite (DV) nu oferă nicio criptare suplimentară față de Let's Encrypt — aceeași protecție tehnică. Diferă doar prin garanții comerciale și, la tipurile OV/EV, prin verificarea identității organizației. Pentru majoritatea site-urilor, plata unui certificat nu are sens.
problema clasică: reînnoirea eșuată
Certificatele Let's Encrypt fiind valabile 90 de zile, dacă reînnoirea automată se strică, site-ul afișează brusc o avertizare de securitate care sperie toți vizitatorii. Verifică periodic că reînnoirea funcționează — sau folosește o monitorizare care te anunță cu 14 zile înainte de expirare.
de reținut
HTTPS asigură confidențialitate, integritate și autenticitate — dar nu garantează că site-ul e cinstit; lacătul se referă la legătură, nu la conținut. Certificatele sunt gratuite prin Let's Encrypt, valabile 90 de zile, reînnoite automat de majoritatea hostingurilor. Certificatele plătite nu criptează mai bine. Riscul practic de urmărit: reînnoirea automată care se strică în tăcere.
modul 04 / HTTPS & certificate SSL
redirecționare, conținut mixt & antete
nu e suficient să ai certificat
După instalare, site-ul e accesibil și pe HTTP, și pe HTTPS — două versiuni paralele. Trebuie să forțezi o singură variantă.
# .htaccess — tot traficul spre HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
301 = redirecționare permanentă. Contează pentru SEO: transferă valoarea către noua adresă. Un 302 (temporar) folosit din greșeală îți fragmentează site-ul în ochii motoarelor de căutare.
alege o singură variantă canonică
Tehnic, acestea sunt patru adrese diferite:
http://site.ro https://site.ro
http://www.site.ro https://www.site.ro
Alege una (de obicei https://site.ro) și redirecționează celelalte trei către ea. Altfel, conținutul apare duplicat, statisticile se împart, iar motoarele de căutare se încurcă.
conținut mixt (mixed content)
Cea mai frecventă problemă după activarea HTTPS: pagina e servită pe HTTPS, dar încarcă resurse (imagini, scripturi, stiluri) pe HTTP. Browserul le blochează sau afișează avertizare — și lacătul dispare.
unde se ascunde conținutul mixt
Rareori în HTML-ul vizibil. De obicei stă în: baza de date (adrese absolute salvate în articole vechi), fișiere CSS (fundaluri cu http://), scripturi externe vechi, sau setările CMS-ului (adresa site-ului configurată cu http). La WordPress, remedierea tipică e o căutare-înlocuire în baza de date, urmată de actualizarea adresei site-ului în setări. Consola browserului îți arată exact ce resurse sunt problematice.
antete de securitate
| Antet | Ce face |
|---|
| HSTS | Spune browserului să folosească doar HTTPS pentru acest domeniu, chiar de la prima încercare |
| X-Content-Type-Options | Împiedică browserul să „ghicească" tipul fișierelor |
| X-Frame-Options | Împiedică încorporarea site-ului în iframe (protecție clickjacking) |
| Content-Security-Policy | Controlează ce resurse pot fi încărcate — cel mai puternic, dar și cel mai delicat de configurat |
Atenție la HSTS: odată activat cu o durată lungă, browserele refuză HTTP pentru acel domeniu chiar dacă tu vrei altfel. Începe cu o durată mică până ești sigur că totul funcționează pe HTTPS.
de reținut
Certificatul singur nu ajunge: redirecționează totul spre HTTPS cu 301 și alege o singură variantă canonică (cu sau fără www) — altfel ai patru site-uri paralele. Problema clasică de după activare e conținutul mixt, ascuns de obicei în baza de date și în CSS, nu în HTML-ul vizibil; consola browserului îl identifică. Adaugă apoi antete de securitate, cu grijă la HSTS, care e greu de anulat.
modul 05 / email pe domeniu propriu
configurarea emailului & înregistrările MX
Un email pe domeniul propriu (contact@firma.md) e diferit de site — sunt servicii separate, controlate de înregistrări DNS diferite. Poți avea site-ul pe un server și emailul complet în altă parte.
opțiuni
| Opțiune | Compromis |
|---|
| Emailul inclus în hosting | Gratuit, dar adesea cu livrabilitate slabă și spațiu mic |
| Serviciu dedicat (Google Workspace, Zoho, Fastmail) | Plătit, dar fiabil, cu filtre bune și livrabilitate mult mai bună |
| Redirecționare | contact@ ajunge în Gmail-ul personal — simplu, dar trimiterea „de la" domeniu cere configurare |
de ce emailul de la hosting dezamăgește des
Serverele de shared hosting găzduiesc sute de site-uri. Dacă unul dintre ele e compromis și trimite spam, întreaga adresă IP ajunge pe liste negre — inclusiv emailurile tale legitime. Pentru email de business, un serviciu dedicat merită costul: reputația IP-ului nu depinde de vecinii tăi.
înregistrările MX
MX (Mail Exchange) spune internetului unde se livrează emailul pentru domeniul tău:
Tip Nume Valoare Prioritate
MX @ mx1.furnizor.com 10
MX @ mx2.furnizor.com 20
- Prioritatea mai mică = încercat primul. Al doilea server e rezervă.
- Când schimbi furnizorul de email, înlocuiești complet înregistrările MX vechi — nu le lași alături de cele noi.
greșeala care pierde emailuri
Păstrarea MX-urilor vechi lângă cele noi. Emailurile se împart aleatoriu între cele două sisteme: unele ajung în noua căsuță, altele într-una pe care nimeni n-o mai verifică. Simptomul e derutant — „primesc unele mesaje, altele nu". Șterge întotdeauna înregistrările MX vechi.
de reținut
Emailul e un serviciu separat de site, dirijat prin înregistrările MX (prioritatea mai mică = încercat primul). Emailul inclus în shared hosting suferă des de livrabilitate slabă, pentru că reputația IP-ului e împărțită cu toți vecinii — pentru business, un serviciu dedicat merită costul. Iar când migrezi, șterge complet MX-urile vechi, altfel emailurile se împart aleatoriu între două sisteme.
modul 05 / email pe domeniu propriu
SPF, DKIM & DMARC: de ce ajungi în spam
Emailul a fost proiectat fără verificarea expeditorului — oricine poate pretinde că trimite de la adresa ta. Trei înregistrări DNS rezolvă asta, iar fără ele mesajele tale ajung în spam, oricât de legitime ar fi.
cele trei mecanisme
| Înregistrare | Răspunde la întrebarea |
|---|
| SPF | „Ce servere au voie să trimită email în numele acestui domeniu?" |
| DKIM | „E mesajul semnat criptografic și nemodificat pe drum?" |
| DMARC | „Ce să facă serverul destinatar dacă verificările pică?" |
SPF — lista serverelor permise
Tip Nume Valoare
TXT @ v=spf1 include:_spf.furnizor.com ~all
- include: — autorizezi serverele acelui furnizor.
- ~all — restul sunt suspecte (soft fail); -all = respinge categoric.
- Doar o singură înregistrare SPF per domeniu. Dacă ai două, ambele devin invalide — greșeală frecventă când adaugi un serviciu nou fără a-l combina cu cel existent.
DKIM — semnătura criptografică
Furnizorul de email semnează fiecare mesaj cu o cheie privată; cheia publică stă în DNS. Destinatarul verifică semnătura și confirmă că mesajul chiar vine de la tine și n-a fost modificat. Furnizorul îți dă valoarea exactă de adăugat — o copiezi ca atare.
DMARC — politica
Tip Nume Valoare
TXT _dmarc v=DMARC1; p=none; rua=mailto:rapoarte@site.ro
| Politică | Efect |
|---|
| p=none | Doar raportează — pentru început, ca să vezi ce se întâmplă |
| p=quarantine | Mesajele suspecte merg în spam |
| p=reject | Sunt respinse complet |
ordinea corectă de implementare
Începe cu p=none și citește rapoartele câteva săptămâni. Vei descoperi servicii care trimit legitim în numele tău și de care ai uitat: platforma de facturare, formularul de pe site, unealta de newsletter. Abia după ce toate sunt autorizate în SPF și DKIM, treci la quarantine, apoi la reject. Dacă sari direct la reject, îți blochezi propriile emailuri legitime — o cauză frecventă de „nu mai primește nimeni facturile noastre".
alte cauze de spam
- IP cu reputație proastă (vezi lecția anterioară).
- Conținut suspect — MAJUSCULE, prea multe semne de exclamare, cuvinte tipice de spam.
- Lipsa dezabonării la newslettere.
- Liste cumpărate — cea mai rapidă cale de a-ți distruge reputația.
de reținut
SPF (ce servere au voie), DKIM (semnătură criptografică) și DMARC (ce se face la eșec) decid dacă emailurile tale ajung în inbox sau în spam — fără ele, chiar și mesajele legitime sunt filtrate. Reguli practice: o singură înregistrare SPF per domeniu, iar DMARC se implementează gradual — p=none → quarantine → reject. Saltul direct la reject îți blochează propriile emailuri.
modul 06 / baze de date & aplicații dinamice
baze de date pe hosting
Un site dinamic (WordPress, magazin, aplicație cu conturi) are nevoie de o bază de date: acolo stau articolele, produsele, utilizatorii, comenzile. Fișierele PHP conțin logica; baza de date conține conținutul.
crearea unei baze de date
În panoul de control, pașii sunt aceiași aproape peste tot:
- Creezi baza de date — îi dai un nume (ex: firma_wp).
- Creezi un utilizator cu o parolă puternică.
- Atribui utilizatorul bazei, cu permisiunile necesare.
- Notezi cele patru valori de care are nevoie aplicația.
reguli de securitate pentru baza de date
- Un utilizator per aplicație, nu unul pentru tot. Dacă o aplicație e compromisă, nu cade și restul.
- Parolă lungă și unică — nu una refolosită de la panou.
- Doar permisiunile necesare — o aplicație care doar citește nu are nevoie de drept de ștergere.
- Fișierul cu aceste date (wp-config.php, .env) e cel mai sensibil de pe server. Permisiuni 600 și niciodată accesibil public.
phpMyAdmin & administrarea
Majoritatea hostingurilor oferă phpMyAdmin — interfață web pentru baza de date. Îl folosești ca să:
- Exporți baza (backup înainte de orice modificare majoră).
- Imporți o bază la migrare.
- Rulezi interogări (ex: căutare-înlocuire pentru conținut mixt).
- Verifici dimensiunea tabelelor.
Un export de bază de date e un fișier .sql. Nu-l lăsa niciodată în public_html — conține tot conținutul site-ului, inclusiv date de utilizatori.
versiunea de PHP
- Se schimbă din panou, de obicei cu un singur clic.
- Versiunile vechi nu mai primesc actualizări de securitate — rularea unui PHP ieșit din suport e un risc real, nu teoretic.
- Înainte de a schimba versiunea: fă backup și, ideal, testează pe o copie. O aplicație veche poate să nu funcționeze pe o versiune mult mai nouă.
de reținut
Un site dinamic separă logica (fișiere) de conținut (baza de date). Creezi baza, un utilizator dedicat cu parolă unică și doar permisiunile necesare, apoi conectezi aplicația prin cele patru valori. Fișierul de configurare e cel mai sensibil de pe server. Ține versiunea de PHP în suport — una ieșită din actualizări e o vulnerabilitate deschisă — și fă backup înainte de a o schimba.
modul 06 / baze de date & aplicații dinamice
instalarea unui CMS & mediul de test
instalarea, pas cu pas
Majoritatea panourilor oferă instalare automată dintr-un clic. Manual, pașii sunt:
- Descarci arhiva oficială (de la sursa oficială, niciodată versiuni „nulled" sau modificate).
- O urci în public_html și o dezarhivezi.
- Creezi baza de date și utilizatorul.
- Deschizi site-ul în browser și completezi asistentul de instalare.
- Ștergi fișierele de instalare rămase.
temele și plugin-urile „gratuite" piratate
O temă premium descărcată gratuit de pe un site dubios e cea mai eficientă metodă de a-ți infecta site-ul. Sunt aproape întotdeauna modificate cu cod ascuns: uși din spate, redirecționări către escrocherii, spam injectat. „Economia" de 50 € te costă site-ul, reputația domeniului și, adesea, poziția în căutări. Instalează doar din surse oficiale.
primele setări obligatorii
- Utilizator administrator cu nume propriu — nu „admin", care e prima țintă a atacurilor automate.
- Parolă lungă și unică + autentificare în doi pași dacă e disponibilă.
- Adresa site-ului setată cu https:// și varianta canonică aleasă.
- Actualizări automate pentru corecțiile de securitate.
- Plugin de backup configurat din prima zi, nu după primul incident.
- Șterge ce nu folosești — temele și plugin-urile inactive tot pot conține vulnerabilități.
mediul de test (staging)
Un staging e o copie a site-ului, pe un subdomeniu, unde încerci modificări fără risc:
site.ro → producție (vizitatorii)
test.site.ro → staging (experimentele tale)
- Testezi acolo actualizările majore, temele noi, schimbările de versiune PHP.
- Blochează indexarea — altfel motoarele de căutare indexează copia și îți fac conținut duplicat. Protejează-l cu parolă.
- Multe hostinguri oferă creare de staging dintr-un clic.
regula care previne majoritatea dezastrelor
Nu actualiza niciodată direct în producție ceva important — o temă, un plugin critic, versiunea de PHP. Testează pe staging, verifică, apoi aplică. Iar înainte de orice modificare majoră: backup complet, verificat. „Am dat update și s-a stricat tot" e o poveste care se aude săptămânal — și e evitabilă în două minute.
de reținut
Instalează CMS-ul doar din surse oficiale — temele piratate vin aproape întotdeauna cu cod ascuns. Setările obligatorii din prima zi: administrator cu nume propriu (nu „admin"), parolă unică, HTTPS, actualizări automate, backup configurat, ștergerea a ce nu folosești. Și cea mai valoroasă practică: un mediu de staging protejat cu parolă, unde testezi înainte de a atinge producția.
modul 07 / performanță: caching, CDN & optimizări
straturile de caching
Caching înseamnă păstrarea unui rezultat gata calculat, ca să nu-l refaci la fiecare cerere. E cea mai eficientă optimizare disponibilă — și e organizat pe straturi.
straturile, de la utilizator spre server
| Strat | Ce păstrează | Cine îl controlează |
|---|
| Browser | Fișiere descărcate (CSS, JS, imagini) | Antete trimise de server |
| CDN | Copii ale conținutului, aproape de vizitator | Configurarea CDN-ului |
| Server / pagini | Pagini HTML generate | Plugin sau configurare server |
| Obiecte | Rezultate de interogări repetate | Redis/Memcached |
| Bază de date | Interogări frecvente | Configurarea bazei |
caching-ul de pagini — cel mai mare câștig
Pentru un site dinamic, fiecare vizită înseamnă: rulează cod → interoghează baza → construiește HTML. Cu caching de pagini, prima vizită face toată munca, iar următoarele primesc HTML gata făcut. Diferența e adesea de la 800 ms la 50 ms.
de ce sunt site-urile statice atât de rapide
Pentru că sunt, prin natura lor, „cache permanent": pagina e deja construită, serverul doar o trimite. Tot efortul de caching pe un site dinamic încearcă, în esență, să reproducă ce un site static are din start. Încă un argument pentru întrebarea din modulul 0: chiar ai nevoie de dinamic?
invalidarea — partea grea
Cea mai frecventă frustrare: „am modificat pagina, dar tot vechea versiune apare". Cauza e un strat de cache care încă servește copia veche. De aceea:
- La modificări de conținut, golește cache-ul (plugin, panou, CDN).
- Verifică toate straturile — poate fi cache-ul de pagini, al CDN-ului sau al browserului tău.
- Testează în fereastră privată, ca să elimini cache-ul propriului browser.
- Pentru fișiere statice, folosește versionare în nume (stil.v3.css): browserul îl vede ca fișier nou și îl descarcă sigur.
antete de cache pentru fișiere
# .htaccess — fișierele statice se păstrează mult
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType text/html "access plus 0 seconds"
</IfModule>
Logica: fișierele care nu se schimbă (imagini, CSS, JS versionat) se păstrează un an; HTML-ul, care se schimbă, nu se cachează în browser sau doar foarte scurt.
de reținut
Caching-ul e organizat pe straturi (browser → CDN → pagini → obiecte → bază de date), iar cel mai mare câștig pentru un site dinamic e caching-ul de pagini: HTML gata făcut în loc de reconstrucție la fiecare vizită. Partea grea e invalidarea — „am modificat dar apare tot vechiul" înseamnă aproape mereu un strat de cache neactualizat. Regula pentru fișiere: statice un an, HTML deloc, cu versionare în nume.
modul 07 / performanță: caching, CDN & optimizări
CDN, compresie & imagini
CDN — conținutul mai aproape de vizitator
Un CDN (rețea de distribuție a conținutului) păstrează copii ale site-ului tău în zeci de locații din lume. Vizitatorul primește conținutul de la cel mai apropiat punct, nu de la serverul tău.
Fără CDN: vizitator (Chișinău) ──────► server (SUA) ~200ms
Cu CDN: vizitator (Chișinău) ──► punct CDN (Frankfurt) ~30ms
- Latență mult mai mică pentru vizitatorii îndepărtați.
- Mai puțină încărcare pe serverul tău.
- Protecție împotriva atacurilor de tip DDoS și filtrare de trafic rău intenționat.
- Există opțiuni gratuite generoase (ex: nivelul gratuit Cloudflare) — pentru multe site-uri e cea mai bună îmbunătățire raportată la efort.
compresia
| Metodă | Ce face |
|---|
| Gzip / Brotli | Comprimă text (HTML, CSS, JS) la transfer — reduce adesea 60–80% |
| Minificare | Elimină spații și comentarii din cod |
Brotli e mai eficient decât Gzip și e suportat de toate browserele moderne. Majoritatea hostingurilor și CDN-urilor îl activează automat — verifică că e pornit, e câștig gratuit.
imaginile — de obicei cea mai mare problemă
Pe un site tipic, imaginile sunt majoritatea greutății paginii. Cinci reguli care rezolvă aproape tot:
- Dimensiunea potrivită — nu urca o fotografie de 4000px pentru a o afișa la 800px. E cea mai frecventă și mai costisitoare greșeală.
- Format modern — WebP sau AVIF în locul JPEG/PNG; reducere de 25–50% la aceeași calitate.
- Comprimare — calitate 80% e vizual identică cu 100%, la jumătate din dimensiune.
- Încărcare amânată (lazy loading) — imaginile de sub „fold" se descarcă abia când e nevoie.
- Dimensiuni declarate în HTML — rezervă spațiul, deci pagina nu „sare" la încărcare.
testul rapid de performanță
Deschide instrumentele de dezvoltare ale browserului, fila Network, și reîncarcă pagina. Sortează după dimensiune. Aproape sigur, primele trei linii sunt imagini — și aproape sigur, cel puțin una are câțiva megabytes fără motiv. Rezolvarea imaginilor rezolvă de obicei jumătate din problema de viteză, fără să atingi serverul.
ce măsori
| Metrică | Ce înseamnă |
|---|
| TTFB | Cât durează până serverul începe să răspundă (sub 200ms e bine) |
| LCP | Când apare elementul principal (sub 2,5s) |
| CLS | Cât „sare" layout-ul la încărcare (aproape zero) |
| Greutate totală | Câți MB descarcă vizitatorul |
de reținut
Un CDN aduce conținutul aproape de vizitator (latență mult mai mică, protecție DDoS) și există opțiuni gratuite excelente. Activează Brotli/Gzip — e câștig gratuit. Dar cea mai mare problemă de viteză sunt aproape întotdeauna imaginile: dimensiune potrivită, format modern, comprimare, lazy loading. Testul de 30 de secunde: fila Network, sortare după dimensiune — vei găsi vinovatul imediat.
modul 08 / securitate & backup
atacuri frecvente & apărarea de bază
Site-urile mici sunt atacate constant — nu pentru că cineva le vizează personal, ci pentru că scripturi automate scanează tot internetul, caută vulnerabilități cunoscute și le exploatează în masă. „Site-ul meu e prea mic ca să intereseze pe cineva" e cea mai periculoasă presupunere.
ce urmăresc atacatorii
| Scop | Ce fac cu site-ul tău |
|---|
| Spam | Trimit mesaje în masă de pe serverul tău (și îți distrug reputația IP) |
| SEO parazit | Injectează linkuri ascunse către site-urile lor |
| Distribuție de programe rele | Site-ul tău infectează vizitatorii |
| Resurse | Folosesc serverul pentru minare sau atacuri |
| Date | Fură baza de utilizatori |
| Șantaj | Criptează totul și cer bani |
vectorii de atac frecvenți
- Software neactualizat — cea mai frecventă cauză. Vulnerabilitățile sunt publice; scripturile le caută automat.
- Parole slabe sau refolosite — atacuri de tip forță brută pe pagina de autentificare.
- Plugin-uri/teme piratate — vin cu uși din spate incluse.
- Formulare nevalidate — injecție SQL, încărcare de fișiere periculoase.
- Fișiere expuse — backup-uri, .env, .sql lăsate în public_html.
- Permisiuni 777 — orice proces poate modifica orice.
80% din protecție vine din patru obiceiuri
- Actualizează — CMS, plugin-uri, teme, PHP. Automat, dacă se poate.
- Parole unice și lungi + autentificare în doi pași. Un gestionar de parole rezolvă tot.
- Șterge ce nu folosești — plugin-uri inactive, teme vechi, instalări uitate pe subdomenii. Codul care nu rulează tot poate fi exploatat.
- Backup automat, verificat — nu previne atacul, dar transformă un dezastru într-o oră de muncă.
Restul (firewall-uri, scanere) sunt utile, dar secundare față de acestea patru.
măsuri suplimentare utile
- Limitarea încercărilor de autentificare — blochează atacurile prin forță brută.
- Ascunderea paginii de administrare la o adresă neobișnuită — nu e securitate reală, dar elimină zgomotul automat.
- WAF (firewall pentru aplicații web) — filtrează cererile rău intenționate; inclus în multe CDN-uri.
- Dezactivarea editării de fișiere din panoul CMS — dacă cineva intră, nu poate edita cod direct din interfață.
- Monitorizarea modificărilor de fișiere — te anunță când apare ceva nou pe server.
de reținut
Site-urile mici sunt atacate automat, în masă — nu pentru că interesează pe cineva. Cei mai frecvenți vectori: software neactualizat, parole slabe, plugin-uri piratate, fișiere expuse. Iar 80% din protecție vine din patru obiceiuri: actualizezi, folosești parole unice cu 2FA, ștergi ce nu folosești, ai backup automat verificat. Restul măsurilor sunt utile, dar secundare.
modul 08 / securitate & backup
backup-uri pe care te poți baza
Un backup e util doar dacă chiar poți restaura din el. Foarte mulți descoperă abia în ziua incidentului că backup-ul lor era incomplet, corupt sau vechi de opt luni.
ce trebuie să conțină
| Componentă | De ce |
|---|
| Fișierele | Cod, teme, imagini încărcate |
| Baza de date | Tot conținutul — fără ea, fișierele sunt inutile |
| Configurările | .htaccess, fișiere de configurare, setări de server |
| Emailul | Dacă e găzduit tot acolo |
Un backup doar cu fișiere, fără baza de date, e practic inutil pentru un site dinamic — și e o greșeală surprinzător de comună.
regula 3-2-1
3 copii ale datelor
2 tipuri diferite de stocare
1 copie în altă locație fizică
de ce nu e suficient backup-ul de la hosting
Multe hostinguri fac backup-uri automate — util, dar insuficient ca unică plasă de siguranță:
- Dacă serverul cedează grav sau contul e suspendat, pierzi și site-ul, și backup-urile.
- Dacă hostingul are o problemă de facturare sau administrativă, nu ai acces la nimic.
- Perioada de păstrare e adesea scurtă (7 zile) — un site infectat de trei săptămâni nu mai are copie curată.
Ține întotdeauna cel puțin o copie în afara hostingului — spațiu cloud propriu sau calculatorul tău.
frecvența
| Tip de site | Frecvență |
|---|
| Prezentare, se schimbă rar | Săptămânal |
| Blog cu articole regulate | Zilnic |
| Magazin cu comenzi | Zilnic + baza de date mai des |
| Înainte de orice modificare majoră | Întotdeauna, manual |
Întrebarea care stabilește frecvența: cât conținut îmi permit să pierd? Dacă răspunsul e „o zi", faci backup zilnic.
testarea restaurării — pasul pe care toți îl sar
Un backup netestat nu e un backup, e o speranță. Cel puțin o dată la câteva luni:
- Ia cea mai recentă copie.
- Restaureaz-o pe un subdomeniu de test.
- Verifică: site-ul pornește? conținutul e complet? imaginile sunt acolo? te poți autentifica?
- Notează cât a durat — vei ști la ce să te aștepți în ziua incidentului.
de reținut
Un backup complet include fișiere + bază de date + configurări — doar fișierele sunt inutile pentru un site dinamic. Aplică 3-2-1 și ține obligatoriu o copie în afara hostingului: dacă pierzi contul, pierzi și backup-urile lui. Frecvența se decide întrebând „cât conținut îmi permit să pierd?". Iar pasul pe care toți îl sar: testează restaurarea — un backup netestat e doar o speranță.
modul 09 / monitorizare, depanare, migrare · proiect & test final
monitorizare & depanarea problemelor frecvente
monitorizare: află tu primul, nu de la clienți
| Ce monitorizezi | De ce |
|---|
| Disponibilitate | Ești anunțat în minute dacă site-ul cade |
| Expirarea certificatului | Eviți avertizarea bruscă de securitate |
| Expirarea domeniului | Cea mai evitabilă catastrofă |
| Timp de răspuns | Detectezi degradarea treptată |
| Modificări de fișiere | Semnal timpuriu de compromitere |
Există servicii gratuite de monitorizare a disponibilității care te anunță pe email sau telefon. E o configurare de cinci minute care îți economisește ore de explicații jenante.
codurile de stare — ce îți spun
| Cod | Înseamnă | Unde cauți |
|---|
| 200 | Totul bine | — |
| 301 / 302 | Redirecționare (permanentă / temporară) | .htaccess, setări CMS |
| 403 | Acces interzis | Permisiuni, reguli .htaccess |
| 404 | Pagina nu există | Adresă greșită, fișier șters, rescrieri |
| 500 | Eroare în aplicație/server | Jurnalele de erori — acolo e răspunsul |
| 502 / 504 | Serverul din spate nu răspunde | Proces oprit, timp depășit |
| 503 | Serviciu indisponibil | Supraîncărcare sau mentenanță |
metoda de diagnostic care funcționează
Când ceva nu merge, parcurgi traseul din modulul 0, în ordine, și elimini pe rând:
- Domeniul e valid și neexpirat?
- DNS-ul arată spre IP-ul corect? (verifici cu un instrument de interogare DNS)
- Serverul răspunde? (dacă IP-ul răspunde dar domeniul nu, e problemă DNS)
- HTTPS — certificatul e valid?
- Aplicația — ce zic jurnalele de erori?
Această ordine îți spune în cinci minute unde e problema. Fără ea, oamenii schimbă la întâmplare setări timp de ore și adesea strică și altceva.
probleme frecvente & cauze tipice
| Simptom | Cauze frecvente |
|---|
| Ecran alb | Eroare PHP cu afișarea dezactivată — caută în jurnale |
| „Site-ul merge la mine, la client nu" | Cache (browser sau CDN), DNS încă neexpirat local |
| Lacătul dispărut | Conținut mixt (modulul 4) |
| Emailuri în spam | SPF/DKIM/DMARC lipsă sau greșite (modulul 5) |
| Modificările nu apar | Cache neinvalidat pe un strat |
| Site brusc foarte lent | Trafic anormal, plugin nou, bază de date supraîncărcată |
jurnalele de erori — prietenul tău
În panoul de control există aproape întotdeauna o secțiune de Error Log. Acolo scrie exact ce fișier și ce linie a produs eroarea 500. E prima verificare, nu ultima — și rezolvă majoritatea problemelor în câteva minute.
de reținut
Configurează monitorizare pentru disponibilitate, certificat și domeniu — vrei să afli tu primul, nu de la clienți. Învață codurile de stare: îți spun unde să cauți. Și, cel mai important, folosește metoda de eliminare pe traseu (domeniu → DNS → server → HTTPS → aplicație) în loc să schimbi setări la întâmplare. Pentru erorile 500, răspunsul e aproape întotdeauna în jurnalele de erori.
modul 09 / monitorizare, depanare, migrare · proiect & test final
migrarea unui site & proiect ghidat
migrarea fără întreruperi
Mutarea unui site la alt hosting sperie, dar e previzibilă dacă respecți ordinea. Cheia: site-ul nou trebuie să funcționeze complet înainte să schimbi DNS-ul.
- Pregătire — cu 24–48h înainte, scazi TTL-ul DNS la 300 de secunde.
- Backup complet al site-ului vechi (fișiere + bază de date), verificat.
- Configurezi hostingul nou — aceeași versiune PHP, aceleași extensii.
- Urci fișierele și imporți baza de date.
- Testezi pe noul server fără DNS — prin fișierul hosts local sau printr-o adresă temporară. Verifici totul: pagini, formulare, autentificare, imagini.
- Îngheți conținutul — anunți că nu se mai fac modificări pe site-ul vechi.
- Sincronizezi ultima dată baza de date și fișierele noi.
- Schimbi DNS-ul către noul IP.
- Emiți certificatul pe noul server și verifici HTTPS.
- Păstrezi vechiul hosting activ încă 1–2 săptămâni, ca plasă de siguranță.
greșelile clasice la migrare
- Schimbi DNS-ul întâi și configurezi după — vizitatorii aterizează pe un site incomplet.
- Uiți emailul — muți site-ul, dar înregistrările MX rămân spre vechiul server, care apoi e închis. Emailurile dispar.
- Ștergi vechiul hosting imediat — descoperi peste trei zile că lipsea ceva.
- Uiți cron-urile și sarcinile programate.
- Nu verifici versiunea PHP — site-ul pică pe noul server dintr-un motiv care n-are legătură cu migrarea.
proiect ghidat: pune un site online, cap-coadă
Pui tot cursul la lucru publicând un site real, corect configurat, de la zero.
planul, pe modulele cursului
- Decizia (mod. 0, 2): stabilește dacă site-ul tău e static sau dinamic și alege tipul de hosting potrivit — justifică alegerea.
- Domeniul (mod. 1): înregistrează-l, activează reînnoirea automată, blocarea transferului și protecția datelor. Verifică că tu ești proprietarul.
- DNS (mod. 1): configurează înregistrările A sau CNAME; identifică unde sunt nameserver-ele înainte de a edita ceva.
- Publicarea (mod. 3): urcă site-ul prin SFTP sau, ideal, prin Git. Verifică permisiunile (644/755) și că nimic sensibil nu e în document root.
- HTTPS (mod. 4): certificat gratuit, redirecționare 301 spre o singură variantă canonică, verificarea conținutului mixt în consolă, antete de securitate.
- Email (mod. 5): configurează MX, apoi SPF, DKIM și DMARC (începe cu p=none). Trimite un test și verifică unde ajunge.
- Aplicația (mod. 6), dacă e dinamică: bază de date cu utilizator dedicat, CMS din sursă oficială, administrator cu nume propriu, staging protejat cu parolă.
- Performanță (mod. 7): caching, CDN, Brotli, imagini optimizate. Verifică în fila Network.
- Securitate & backup (mod. 8): actualizări automate, 2FA, backup automat cu o copie în afara hostingului, restaurare testată.
- Monitorizare (mod. 9): alertă de disponibilitate, expirare certificat și domeniu.
definiția lui „gata"
- Site-ul răspunde pe o singură adresă canonică, cu HTTPS și fără conținut mixt.
- Emailul ajunge în inbox, nu în spam — SPF, DKIM, DMARC configurate.
- Nimic sensibil nu e accesibil public (fără .sql, .env sau backup-uri în document root).
- Backup automat funcțional, cu restaurare testată cel puțin o dată.
- Monitorizare activă pentru disponibilitate și expirări.
- Poți explica, pas cu pas, ce se întâmplă între momentul în care cineva scrie adresa și momentul în care vede pagina.
felicitări
Ai parcurs hostingul cap-coadă: traseul unei cereri, domenii și DNS, tipuri de hosting, panouri și permisiuni, HTTPS, email cu SPF/DKIM/DMARC, baze de date, performanță, securitate și backup, monitorizare, depanare și migrare — combinate într-un site publicat corect. Ai acum ceva ce mulți dezvoltatori nu au: înțelegi întregul traseu, deci poți diagnostica în loc să ghicești. Urmează testul final: 20 de întrebări din tot cursul. Prag: 70%. Succes!