Let’s Encrypt a anunțat o schimbare importantă pentru certificatele SSL/TLS: începând cu 10 februarie 2027, certificatele emise sau reînnoite vor avea implicit o valabilitate de 64 de zile, în loc de cele 90 de zile utilizate în prezent.

Pentru utilizatorii serviciilor de găzduire NameBox, schimbarea nu înseamnă că certificatele vor trebui instalate manual mai des. Certificatele Let’s Encrypt sunt oferite gratuit pe pachetele de găzduire NameBox, iar administrarea lor este automatizată prin AutoSSL din cPanel.

Atât timp cât domeniul este configurat corect și poate fi validat, AutoSSL poate emite și instala certificatul automat, fără ca utilizatorul să fie nevoit să solicite separat activarea unui SSL.

Ce se schimbă la certificatele Let’s Encrypt?

În 2026, durata standard a unui certificat Let’s Encrypt este de:

90 de zile

Începând cu:

10 februarie 2027

durata implicită va deveni:

64 de zile

Schimbarea se aplică certificatelor noi și certificatelor reînnoite după această dată.

Let’s Encrypt estimează că ultimele certificate de 90 de zile vor expira până în 11 mai 2027.

Certificatele deja emise nu vor fi revocate doar pentru că perioada standard se modifică.

De ce reduce Let’s Encrypt perioada de valabilitate?

Certificatele cu durată mai scurtă reduc perioada în care un certificat sau o cheie compromisă poate fi utilizată.

Let’s Encrypt indică două motive importante:

• reducerea riscului asociat compromiterii unei chei private;
• reducerea impactului unui certificat emis incorect.

Direcția generală este către certificate cu durată mai scurtă și administrare complet automatizată.

De altfel, Let’s Encrypt a anunțat deja că perioada standard va continua să scadă în anii următori.

Trebuie reinstalat SSL-ul la 64 de zile?

Nu.

Acesta este unul dintre cele mai importante lucruri de reținut.

Let’s Encrypt a fost proiectat pentru emiterea și reînnoirea automată a certificatelor prin protocolul ACME.

Într-un mediu cPanel cu AutoSSL activ, procesul poate fi reprezentat astfel:

Prin urmare, reducerea duratei certificatului nu înseamnă automat mai multă muncă pentru proprietarul website-ului.

SSL Let’s Encrypt gratuit și automat la NameBox

Pe pachetele de găzduire NameBox oferim SSL Let’s Encrypt gratuit.

AutoSSL este utilizat pentru verificarea domeniilor și administrarea certificatelor, astfel încât utilizatorul nu trebuie să cumpere separat un certificat SSL pentru un website obișnuit și nici să solicite instalarea acestuia la fiecare activare sau reînnoire.

După ce domeniul este configurat către serverul NameBox și poate fi validat, sistemul verifică automat acoperirea SSL și poate solicita certificatul fără o cerere separată din partea clientului.

AutoSSL rulează periodic la nivelul serverului și verifică dacă domeniile eligibile beneficiază de un certificat valid.

Utilizatorul poate verifica situația certificatului din:

cPanel → Security → SSL/TLS Status

Dacă este necesară o verificare manuală, poate fi utilizată și opțiunea:

Run AutoSSL

În mod normal însă, emiterea și reînnoirea sunt procese automatizate.

Când nu poate fi instalat automat certificatul?

AutoSSL trebuie să poată demonstra că domeniul aparține contului pentru care se solicită certificatul.

Pot apărea probleme dacă:

• domeniul nu indică spre serverul NameBox;
• DNS-ul a fost modificat recent și propagarea nu s-a finalizat;
• un subdomeniu indică spre alt server;
• există o configurație CAA care nu permite emiterea certificatului;
• domeniul a fost exclus din AutoSSL;
• validarea domeniului nu poate fi finalizată.

În astfel de situații, reducerea perioadei la 64 de zile nu este problema propriu-zisă. Trebuie rezolvată cauza care împiedică validarea și reînnoirea automată.

Ce trebuie să facă utilizatorii NameBox?

Pentru majoritatea utilizatorilor, nu este necesară nicio modificare.

Dacă website-ul are deja un certificat Let’s Encrypt administrat prin AutoSSL și domeniul indică în continuare corect către server, sistemul se ocupă de procesul de reînnoire.

Este însă recomandat să verifici periodic:

• domeniul indică spre serverul corect;
• certificatul apare valid în cPanel;
• website-ul se deschide prin HTTPS;
• nu există erori AutoSSL;
• nu există configurații DNS sau CAA care împiedică emiterea.

Ce trebuie să verifice administratorii de servere?

Pentru serverele administrate manual sau pentru implementările ACME custom, schimbarea este mai importantă.

Let’s Encrypt recomandă evitarea scripturilor configurate rigid să reînnoiască certificatele după un anumit număr fix de zile.

De exemplu, un sistem construit în jurul ideii:

Certificat de 90 zile
→ renewal după 60 zile

trebuie reevaluat odată cu scurtarea perioadei de valabilitate.

Let’s Encrypt recomandă automatizarea procesului și utilizarea mecanismelor moderne prin care clientul ACME poate afla momentul potrivit pentru reînnoire.

Pentru utilizatorii cPanel cu AutoSSL, acest proces este administrat de sistem și nu trebuie implementat manual pentru fiecare domeniu.

Mai puține zile nu înseamnă un SSL mai slab

Un certificat valabil 64 de zile nu oferă o criptare mai slabă decât un certificat de 90 de zile.

Durata certificatului reprezintă perioada în care acesta este considerat valid, nu puterea algoritmului de criptare utilizat pentru conexiunea HTTPS.

Scurtarea duratei urmărește tocmai reducerea perioadei de expunere în cazul apariției unei probleme.

Ce urmează după certificatele de 64 de zile?

Schimbarea din 2027 este o etapă intermediară.

Let’s Encrypt intenționează ca, din 2028, durata implicită a certificatelor să fie redusă din nou, până la:

45 de zile

Acest lucru confirmă faptul că administrarea manuală a certificatelor SSL devine din ce în ce mai puțin practică, iar automatizarea reînnoirii devine esențială.

Automatizarea devine și mai importantă

Reducerea certificatelor Let’s Encrypt de la 90 la 64 de zile nu ar trebui să producă schimbări vizibile pentru utilizatorii care folosesc deja AutoSSL.

Pe serviciile de găzduire NameBox, certificatul Let’s Encrypt este disponibil gratuit, iar AutoSSL verifică și administrează automat certificatele domeniilor eligibile.

Astfel, dacă domeniul indică spre server și poate fi validat corect, certificatul poate fi emis și instalat automat chiar dacă utilizatorul nu solicită separat activarea SSL.

Începând din februarie 2027, certificatele vor trebui pur și simplu reînnoite mai frecvent în fundal, iar automatizarea existentă este tocmai mecanismul conceput pentru acest tip de schimbare.

Pentru mai multe informații poți consulta și articolul nostru despre certificatele SSL gratuite Let’s Encrypt sau ghidul Activare Let’s Encrypt direct din cPanel.

Pe pagina noastră HelpDesk găsiți multe alte tutoriale utile pentru a gestiona mai ușor contul dvs. cPanel.

The post Let’s Encrypt trece la certificate SSL de 64 de zile din 2027 appeared first on NAMEBOX.

cPanel Meridian este noua interfață de administrare introdusă în cPanel & WHM v138. Aceasta aduce un design modern, o navigare simplificată, mod întunecat și acces la funcții bazate pe inteligență artificială.

Spre deosebire de tema clasică Jupiter, Meridian organizează instrumentele în funcție de activitățile utilizatorului: administrarea website-urilor, emailurilor, fișierelor, bazelor de date, securității și performanței.

În continuare vedem ce aduce nou Meridian, cum o activezi, cum funcționează AI Assistant și cum poți reveni la Jupiter.

Ce este cPanel Meridian și ce aduce nou?

Meridian este o alternativă la interfața Jupiter, disponibilă începând cu versiunea cPanel 138. Scopul său este să simplifice administrarea unui cont de găzduire, fără să modifice serviciile sau configurațiile existente.

Principalele noutăți sunt:

• Dashboard modern: informații despre spațiul utilizat, trafic, domenii, certificate SSL și alte resurse ale contului.
• Navigare reorganizată: instrumentele sunt grupate după activități, într-un meniu lateral.
• Light Mode și Dark Mode: posibilitatea de a personaliza aspectul interfeței.
• Căutare rapidă: acces la instrumente folosind bara de căutare sau Ctrl + K / Cmd + K.
• AI Assistant: un asistent integrat care poate răspunde la întrebări despre contul cPanel, dacă funcția este activată.

Meridian nu este un nou panou de control separat de cPanel. Este o interfață diferită pentru administrarea aceluiași cont.

Meridian vs. Jupiter: care sunt diferențele?

Jupiter afișează instrumentele cPanel în categorii precum Files, Databases, Domains, Email sau Security. Meridian pune accent pe activitățile pe care utilizatorul dorește să le realizeze.

De exemplu, în Meridian poți accesa secțiunea Files pentru administrarea fișierelor sau Email pentru gestionarea adreselor de email, fără să cauți prin numeroase categorii.

În plus, dashboard-ul afișează informații despre cont și poate recomanda acțiuni precum configurarea unui website sau verificarea anumitor resurse.

Important: schimbarea dintre Jupiter și Meridian nu reprezintă o migrare. Website-urile, emailurile, bazele de date, certificatele SSL și fișierele rămân neschimbate. Trecerea la Meridian nu produce întreruperi ale website-ului și nu îi modifică performanța.

Cum activezi Meridian în cPanel?

Dacă Meridian este disponibil pentru contul tău, poți activa noua interfață direct din cPanel.

Activarea din partea superioară a interfeței

În tema Jupiter, identifică butonul „Try the new Meridian theme”, afișat în partea superioară a paginii.

Apasă butonul pentru a deschide prezentarea noii teme, apoi selectează „Try Meridian”.

Interfața se va schimba automat, fără să afecteze website-ul sau celelalte servicii ale contului.

Activarea din selectorul de teme

În Jupiter, poți schimba interfața și din secțiunea Theme, disponibilă în panoul cu informațiile contului, dacă administratorul serverului permite această opțiune.

Deschide lista temelor disponibile și selectează Meridian.

Cum revii de la Meridian la Jupiter?

În Meridian, identifică butonul „Classic cPanel Theme”, aflat în partea superioară a interfeței, și apasă-l pentru a reveni la Jupiter.

Alternativ, poți accesa Profile → Account Preferences → Theme și selecta Jupiter, dacă opțiunea este disponibilă.

Revenirea la Jupiter este permisă pentru conturile eligibile, în funcție de configurația furnizorului. Conturile create direct pe Meridian, care nu au utilizat niciodată Jupiter, pot necesita intervenția administratorului pentru schimbarea temei.

Cum este organizată noua interfață Meridian?

Meridian folosește un meniu lateral și un dashboard care oferă acces rapid la informațiile și instrumentele contului.

Principalele secțiuni sunt:

• Dashboard: prezentarea generală a contului, resurse utilizate și acțiuni recomandate.
• Websites & Apps: administrarea website-urilor, domeniilor și aplicațiilor.
• Email: administrarea adreselor de email, redirecționărilor și filtrelor.
• Files: acces la File Manager, utilizarea spațiului și instrumentele de backup disponibile.
• Databases: administrarea bazelor de date.
• Security: instrumentele de securitate disponibile pentru cont.
• Performance: informații și instrumente pentru monitorizarea resurselor.

În funcție de configurația serverului, meniul poate include și instrumente precum WordPress sau Softaculous Apps Installer.

Un exemplu este secțiunea Files, unde Meridian afișează informații despre spațiul ocupat, backup-uri și instrumente pentru administrarea fișierelor, într-o interfață unificată.

Funcțiile disponibile pot varia în funcție de pachetul de găzduire și de opțiunile activate de administrator.

Light Mode și Dark Mode în cPanel Meridian

Una dintre schimbările vizibile este posibilitatea de a utiliza interfața în modul luminos sau întunecat.

Din partea superioară a Meridian poți selecta Light Mode, Dark Mode sau modul automat, în funcție de preferințele de afișare disponibile.

Această opțiune modifică exclusiv aspectul panoului cPanel, nu tema WordPress sau designul website-ului găzduit.

AI Assistant în cPanel Meridian

Meridian introduce și posibilitatea utilizării cPanel AI Assistant, un asistent care poate răspunde la întrebări despre administrarea contului.

Atunci când funcția este disponibilă, aceasta poate fi accesată prin butonul „Ask AI”, aflat în partea dreaptă, jos, a interfeței.

De exemplu, utilizatorul poate întreba:

• Cât spațiu de stocare utilizează contul meu?
• Ce domenii am configurate?
• Câte adrese de email există?
• Unde pot administra bazele de date?
• Care este starea certificatelor SSL?

AI Assistant poate oferi explicații și informații contextuale despre cont. În configurațiile care permit acest lucru, poate realiza și anumite operațiuni, cu aprobarea utilizatorului.

Disponibilitatea AI Assistant nu este garantată prin simpla activare a Meridian. Funcția trebuie să fie activată separat de administratorul serverului.

Ce alte funcții AI sunt asociate cu Meridian?

Odată cu cPanel v138 au fost introduse și alte funcționalități asociate ecosistemului cPanel AI.

Printre acestea se numără Sitejet AI, pentru crearea asistată a website-urilor, AI App Hosting, pentru publicarea anumitor aplicații Node.js, și integrarea MCP (Model Context Protocol), care permite conectarea unor instrumente AI externe în condiții de acces controlat.

Aceste funcționalități pot necesita activare separată, licențe sau condiții suplimentare. Nu toate sunt disponibile automat pentru fiecare cont de găzduire.

Meridian este disponibil pentru clienții NameBox?

NameBox utilizează cPanel pentru administrarea serviciilor de găzduire web, alături de tehnologii precum CloudLinux și LiteSpeed Enterprise.

Meridian este o componentă a interfeței cPanel și nu modifică funcționarea acestor tehnologii.

Disponibilitatea noii teme depinde de versiunea cPanel instalată pe server și de configurația contului. Dacă opțiunea Meridian nu apare în interfață, aceasta poate să nu fie încă activată pentru serviciul respectiv.

Merită să treci de la Jupiter la Meridian?

Pentru utilizatorii noi, Meridian poate fi mai ușor de folosit datorită meniului reorganizat, dashboard-ului modern și accesului rapid la instrumentele principale.

Pentru utilizatorii experimentați, obișnuiți cu structura clasică cPanel, Jupiter poate rămâne o alegere practică, mai ales atunci când folosesc frecvent instrumente avansate.

Meridian nu accelerează automat website-ul și nu adaugă resurse suplimentare pachetului de găzduire. Principalul său avantaj este simplificarea administrării contului.

Dacă ai posibilitatea de a schimba tema, poți testa Meridian și decide care interfață se potrivește mai bine modului tău de lucru.

Pentru alte informații despre administrarea serviciilor de găzduire, consultă și secțiunea noastră de documentație NameBox.

The post cPanel Meridian și AI: Noua interfață cPanel și cum o activezi appeared first on NAMEBOX.

WordPress Heartbeat API este un mecanism integrat în WordPress care permite browserului să comunice periodic cu serverul fără ca utilizatorul să reîncarce pagina.

Este utilizat pentru funcții utile din WordPress, precum autosave, verificarea sesiunii de autentificare, blocarea unui articol atunci când acesta este editat de alt utilizator și diferite funcționalități implementate de pluginuri.

În anumite situații, aceste request-uri periodice pot contribui la creșterea consumului de CPU și a numărului de procese active, în special atunci când există mai mulți administratori conectați simultan, multe tab-uri WordPress deschise sau pluginuri care folosesc intensiv Heartbeat API.

Totuși, simpla existență a request-urilor către admin-ajax.php nu înseamnă automat că WordPress Heartbeat este cauza unui consum ridicat.

În acest articol vom vedea cum funcționează Heartbeat API, cum îl identificăm și cum putem verifica dacă are într-adevăr impact asupra resurselor website-ului.

Ce este WordPress Heartbeat API?

WordPress Heartbeat API este un sistem de comunicare periodică între browser și server.

Atunci când anumite pagini WordPress sunt deschise, JavaScript-ul din browser poate trimite periodic date către server.

Procesul poate fi reprezentat simplificat astfel:

Browser
   ↓
WordPress Heartbeat
   ↓
POST /wp-admin/admin-ajax.php
   ↓
PHP / WordPress
   ↓
Răspuns JSON
   ↓
Browser

Conform documentației oficiale WordPress, intervalele Heartbeat pot fi cuprinse între aproximativ 15 și 120 de secunde, în funcție de context și configurație.

Fiecare request trebuie procesat de WordPress și de PHP, iar pluginurile pot adăuga propriile operațiuni în cadrul Heartbeat API.

La ce este folosit Heartbeat API?

Heartbeat API nu există doar pentru a genera request-uri. WordPress îl utilizează pentru funcționalități importante.

Printre acestea se pot afla:

• salvarea automată a conținutului;
• post locking atunci când mai mulți utilizatori încearcă să editeze același articol;
• verificarea sesiunii de autentificare;
• actualizarea anumitor informații din wp-admin;
• comunicarea aproape în timp real între browser și server;
• funcționalități implementate de pluginuri și teme.

Din acest motiv, dezactivarea completă a Heartbeat API nu trebuie făcută automat doar pentru că apar request-uri către admin-ajax.php.

Ce este admin-ajax.php?

Request-urile Heartbeat sunt procesate prin:

/wp-admin/admin-ajax.php

Acest fișier este endpoint-ul AJAX clasic al WordPress.

Este important însă să facem o diferență:

admin-ajax.php nu este utilizat exclusiv de Heartbeat API.

Pluginurile și temele WordPress îl pot utiliza pentru numeroase operațiuni AJAX, precum:

• formulare;
• filtre de produse;
• căutări live;
• încărcarea unor informații fără refresh;
• operațiuni WooCommerce;
• funcționalități din wp-admin;
• request-uri personalizate ale pluginurilor.

Prin urmare, dacă observi sute sau mii de request-uri către:

admin-ajax.php

nu poți concluziona doar din URL că toate provin de la WordPress Heartbeat API.

Cum identifici request-urile WordPress Heartbeat?

Cea mai simplă metodă este utilizarea Developer Tools din browser.

Autentifică-te în WordPress și deschide:

Developer Tools → Network

Apoi filtrează request-urile după:

admin-ajax.php

Lasă pagina deschisă pentru câteva minute.

Dacă Heartbeat API este activ în acel context, vei observa request-uri POST periodice către:

/wp-admin/admin-ajax.php

Selectează unul dintre request-uri și verifică datele trimise.

Pentru Heartbeat vei putea identifica parametrul:

action=heartbeat

Acesta este un indicator mult mai precis decât simpla apariție a URL-ului admin-ajax.php.

De ce poate Heartbeat API să consume resurse?

Un request Heartbeat nu este doar un fișier static descărcat de browser.

Request-ul ajunge la WordPress, ceea ce presupune pornirea procesării PHP și încărcarea componentelor necesare aplicației.

În funcție de website, în timpul procesării pot fi încărcate:

• WordPress Core;
• pluginurile active;
• anumite componente ale temei;
• hook-uri adăugate de pluginuri;
• operațiuni asupra bazei de date.

Dacă un singur administrator are o pagină deschisă, impactul este în general redus.

Situația se poate schimba însă atunci când există:

• mai mulți administratori sau editori conectați;
• mai multe tab-uri wp-admin deschise simultan;
• un interval Heartbeat foarte redus;
• pluginuri care execută operațiuni complexe la fiecare Heartbeat;
• request-uri care durează mult;
• un website deja foarte solicitat.

Exemplu: mai multe tab-uri WordPress deschise

Să presupunem că un utilizator are deschise simultan:

Dashboard
Editare articol
Editare pagină
WooCommerce
Pagina unui plugin

Dacă mai multe dintre aceste pagini execută Heartbeat, browserul poate genera request-uri periodice către server din fiecare context.

Dacă există și mai mulți utilizatori conectați simultan, numărul request-urilor poate crește.

Acest lucru nu înseamnă neapărat că va exista o problemă de performanță, însă merită investigat atunci când este corelat cu un consum ridicat de CPU sau Entry Processes.

Heartbeat API și LiteSpeed Cache

Pe serverele shared NameBox este utilizat LiteSpeed Enterprise, iar website-urile WordPress pot utiliza LiteSpeed Cache.

Page Cache este foarte eficient pentru paginile publice care pot fi livrate direct din cache fără executarea completă a WordPress.

Heartbeat funcționează însă prin request-uri POST către:

/wp-admin/admin-ajax.php

Aceste request-uri dinamice nu trebuie confundate cu accesarea unei pagini publice aflate în cache.

LiteSpeed Cache nu poate transforma pur și simplu un request Heartbeat într-o pagină statică din cache, deoarece browserul comunică dinamic cu aplicația.

Din acest motiv, un website poate avea un cache excelent pentru frontend și totuși să înregistreze activitate PHP în wp-admin.

Pentru mai multe informații despre LiteSpeed poți consulta articolul LiteSpeed vs Apache: Care este mai rapid?.

Cum verifici consumul de resurse în cPanel?

Pe serverele NameBox care utilizează cPanel și CloudLinux, consumul unui cont poate fi verificat direct din cPanel.

Accesează:

cPanel → Metrics → Resource Usage

Aici poți verifica valori precum:

• CPU – consumul procesorului;
• PMEM – memoria fizică;
• I/O – viteza operațiunilor de citire și scriere;
• IOPS – numărul operațiunilor I/O;
• EP – Entry Processes;
• NPROC – numărul proceselor.

CloudLinux este componenta care izolează și monitorizează resursele contului. Heartbeat API este o funcție WordPress care poate genera request-uri PHP, iar aceste request-uri pot contribui la resursele măsurate de CloudLinux.

Pentru un ghid detaliat poți consulta Monitorizare resurse cPanel.

Cum corelezi Heartbeat cu Resource Usage?

Nu modifica WordPress Heartbeat doar pentru că observi un consum ridicat.

Mai întâi încearcă să corelezi evenimentele.

De exemplu:

10:00 → consum normal
10:15 → utilizator intră în wp-admin
10:20 → mai multe tab-uri WordPress deschise
10:25 → CPU crește
10:30 → wp-admin este închis
10:35 → CPU revine la normal

Un astfel de comportament justifică o investigație suplimentară.

Dacă spike-ul de CPU apare însă în fiecare noapte la ora 02:00, iar nimeni nu utilizează wp-admin, este mult mai probabil să trebuiască investigate cron job-uri, backup-uri, importuri sau alte procese.

Pentru diferențiere poți consulta și articolul Cron Jobs în cPanel: Ce sunt și cum funcționează?.

Cum verifici admin-ajax.php în access log?

Dacă ai acces root la un server cPanel, poți verifica request-urile direct în logurile domeniului.

Într-un mediu cPanel, logurile domeniilor pot fi găsite în:

/var/log/apache2/domlogs/

Pentru un domeniu:

grep 'admin-ajax.php' /var/log/apache2/domlogs/exemplu.ro | tail -100

Pentru request-uri POST:

grep '"POST /wp-admin/admin-ajax.php' /var/log/apache2/domlogs/exemplu.ro | tail -100

Pentru a număra request-urile identificate în log:

grep '"POST /wp-admin/admin-ajax.php' /var/log/apache2/domlogs/exemplu.ro | wc -l

Înlocuiește:

exemplu.ro

cu domeniul investigat.

Access log-ul standard nu conține în mod normal corpul POST al request-ului. Prin urmare, din această linie nu poți determina întotdeauna dacă request-ul admin-ajax.php este Heartbeat sau o altă operațiune AJAX.

Pentru identificarea exactă a:

action=heartbeat

este mai simplu să utilizezi Developer Tools sau instrumente de debugging la nivel de WordPress.

Pentru mai multe exemple de analiză a logurilor poți consulta articolul Raw Access Logs și AWStats în cPanel.

admin-ajax.php consumă mult? Nu presupune că este Heartbeat

Aceasta este una dintre cele mai importante verificări.

Să presupunem că identifici:

5.000 request-uri → /wp-admin/admin-ajax.php

Acestea pot proveni de la:

• Heartbeat API;
• WooCommerce;
• filtre de produse;
• pluginuri de căutare;
• formulare;
• page builders;
• pluginuri de statistică;
• pluginuri de securitate;
• alte funcționalități AJAX.

Reducerea Heartbeat nu va rezolva problema dacă majoritatea request-urilor provin de fapt de la un plugin.

Când merită să modifici WordPress Heartbeat?

Nu există un motiv să modifici Heartbeat API pe fiecare instalare WordPress.

Merită investigată frecvența atunci când:

• wp-admin generează un consum ridicat și constant;
• există mulți editori conectați simultan;
• se observă foarte multe request-uri Heartbeat;
• un plugin folosește Heartbeat pentru operațiuni costisitoare;
• request-urile admin-ajax.php se suprapun;
• Resource Usage indică spike-uri corelate cu activitatea wp-admin.

Dacă website-ul funcționează normal și nu există consum neobișnuit, nu este necesară optimizarea Heartbeat doar pentru a reduce numărul request-urilor.

Cum modifici intervalul Heartbeat fără să îl dezactivezi?

WordPress oferă filtrul:

heartbeat_settings

prin care intervalul poate fi modificat.

De exemplu:

add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

În acest exemplu, intervalul este setat la:

60 secunde

WordPress documentează intervale Heartbeat între 15 și 120 de secunde.

Codul trebuie adăugat într-un plugin custom sau într-o zonă corespunzătoare de cod a website-ului. Dacă este introdus în functions.php, este recomandată utilizarea unei teme child pentru a evita pierderea modificării la actualizarea temei.

Nu recomandăm modificarea intervalului fără să existe mai întâi o problemă identificată.

Cum controlezi Heartbeat din LiteSpeed Cache?

Dacă website-ul utilizează pluginul LiteSpeed Cache for WordPress, există și o metodă grafică.

Accesează în WordPress:

LiteSpeed Cache → Toolbox → Heartbeat

În această zonă pot exista setări separate pentru:

• Frontend Heartbeat;
• Backend Heartbeat;
• Editor Heartbeat.

LiteSpeed permite configurarea intervalului în intervalul:

15 – 120 secunde

În funcție de setare, valoarea:

0

poate dezactiva Heartbeat pentru zona respectivă.

Nu recomandăm setarea valorii 0 fără testare.

Documentația LiteSpeed avertizează că modificarea sau dezactivarea Heartbeat poate afecta task-uri WordPress declanșate prin AJAX.

Backend, Editor și Frontend Heartbeat

LiteSpeed Cache permite controlul separat pentru diferite zone tocmai pentru că impactul dezactivării poate fi diferit.

Editor Heartbeat

Este zona în care trebuie acordată cea mai mare atenție.

Editorul WordPress utilizează Heartbeat pentru funcții asociate cu:

• autosave;
• edit locking;
• sincronizarea anumitor informații;
• verificarea sesiunii.

Dezactivarea completă poate afecta experiența editorilor.

Backend Heartbeat

Acesta poate fi folosit în alte zone din wp-admin și de diferite pluginuri.

Dacă dorești să reduci frecvența, este preferabil să testezi mai întâi un interval mai mare în loc să îl dezactivezi complet.

Frontend Heartbeat

Unele pluginuri pot încărca Heartbeat și pe frontend pentru funcționalități dinamice.

Dacă un website nu utilizează astfel de funcții, impactul poate fi diferit față de editor, dar și această zonă trebuie testată înainte de dezactivare.

De ce nu recomandăm dezactivarea completă?

Poți găsi numeroase tutoriale care recomandă pur și simplu:

Disable WordPress Heartbeat

ca metodă de „optimizare”.

Această abordare este prea generală.

Heartbeat face parte din WordPress Core și poate fi utilizat atât de WordPress, cât și de pluginuri.

O dezactivare completă poate avea efecte precum:

• autosave-ul nu mai funcționează corect;
• edit locking nu mai funcționează normal;
• anumite notificări din wp-admin nu se actualizează;
• pluginurile care depind de Heartbeat pot avea probleme;
• funcționalitățile AJAX asociate pot fi afectate.

O soluție mai sigură este:

identificare → măsurare → reducere interval → testare

și nu:

consum mare → dezactivare completă

Heartbeat API și eroarea 508 Resource Limit Is Reached

Pe un server CloudLinux, fiecare cont poate avea limite pentru resurse precum CPU, memorie, I/O, procese și Entry Processes.

Request-urile Heartbeat sunt request-uri dinamice și necesită procesare.

Dacă există suficient de multe request-uri simultane sau acestea rulează lent, pot contribui la consumul contului.

Totuși, Heartbeat nu trebuie considerat automat cauza unei erori 508.

Eroarea poate fi asociată și cu:

• trafic ridicat;
• boți;
• pluginuri lente;
• request-uri AJAX diferite de Heartbeat;
• cron job-uri;
• importuri;
• interogări SQL lente;
• API-uri externe;
• procese PHP care rămân active prea mult.

Pentru o investigație completă poți consulta articolul Resource Limit Is Reached: Ce înseamnă eroarea 508?.

Heartbeat API și CPU ridicat în WordPress

Dacă observi CPU ridicat în Resource Usage, verifică dacă acesta coincide cu activitatea din wp-admin.

Un Heartbeat normal care se finalizează rapid nu ar trebui privit automat ca o problemă.

Este mai important timpul necesar pentru procesarea request-ului.

Dacă un plugin adaugă operațiuni complexe la fiecare Heartbeat, un simplu request poate implica:

• mai multe interogări SQL;
• procesarea unor date;
• actualizarea unor opțiuni;
• comunicarea cu un API extern;
• executarea unor hook-uri suplimentare.

În această situație, problema reală poate fi pluginul sau codul executat la Heartbeat, nu API-ul WordPress în sine.

Cum identifici dacă un plugin contribuie la problemă?

Dacă ai confirmat că Heartbeat generează consum ridicat, următorul pas este identificarea componentelor care se execută odată cu request-ul.

Poți verifica:

• pluginurile instalate recent;
• pluginurile care afișează informații în timp real;
• pluginurile de statistică;
• pluginurile de backup;
• pluginurile de securitate;
• pluginurile WooCommerce;
• funcții custom adăugate în functions.php;
• pluginuri care folosesc hook-urile Heartbeat.

Nu dezactiva toate pluginurile direct pe un website de producție fără un plan de testare.

Ideal, verificarea se realizează într-un mediu de test sau prin dezactivarea controlată a componentelor suspecte.

Heartbeat API nu este WP-Cron

WordPress Heartbeat API și WP-Cron sunt două mecanisme diferite.

Heartbeat API presupune comunicarea periodică dintre browser și server atunci când o pagină care folosește Heartbeat este deschisă.

WP-Cron este sistemul WordPress pentru executarea task-urilor programate.

De exemplu:

Heartbeat:
Browser → admin-ajax.php → WordPress

WP-Cron:
Request WordPress → wp-cron.php → task programat

Ambele pot genera procesare PHP, dar trebuie investigate separat.

Ce rol are CloudLinux?

CloudLinux nu generează și nu controlează WordPress Heartbeat.

Rolul său este diferit.

CloudLinux permite izolarea conturilor și monitorizarea sau limitarea unor resurse precum:

• CPU;
• memorie;
• I/O;
• IOPS;
• Entry Processes;
• numărul proceselor.

Dacă un website generează multe request-uri PHP, indiferent dacă provin de la Heartbeat, vizitatori, boți sau cron-uri, acestea pot fi reflectate în consumul afișat în Resource Usage.

Pentru o explicație mai detaliată poți consulta articolul Resurse pachet găzduire: CPU, RAM, I/O și Entry Processes.

Ce rol are LiteSpeed?

LiteSpeed Enterprise este web serverul utilizat pe infrastructura shared NameBox.

LiteSpeed poate servi foarte eficient paginile cache-uite și poate reduce numărul execuțiilor PHP necesare pentru traficul public.

Totuși, request-urile POST și operațiunile dinamice precum Heartbeat trebuie tratate separat de page cache.

Din acest motiv, optimizarea WordPress trebuie analizată ca un ansamblu:

• page cache;
• PHP;
• baza de date;
• pluginuri;
• AJAX;
• Heartbeat;
• cron job-uri;
• resursele contului.

Poți consulta și ghidul nostru despre optimizarea WordPress.

Checklist: Heartbeat chiar este cauza consumului?

Înainte să modifici configurația, verifică următoarele:

• Există multe request-uri către admin-ajax.php?
• Request-urile conțin action=heartbeat?
• La ce interval sunt trimise?
• Câți utilizatori sunt conectați în wp-admin?
• Există multe tab-uri WordPress deschise?
• CPU crește exact în perioada respectivă?
• Entry Processes cresc în același interval?
• Request-urile durează mult?
• Există pluginuri care folosesc Heartbeat?
• Problema dispare atunci când wp-admin nu mai este utilizat?

Dacă răspunsul este da la mai multe dintre aceste întrebări, modificarea frecvenței Heartbeat poate merita testată.

Ce configurație recomandăm ca punct de pornire?

Nu există o valoare universală pentru toate website-urile WordPress.

Pentru un website care prezintă consum neobișnuit, abordarea recomandată este:

• identifică mai întâi request-urile Heartbeat;
• corelează ora cu Resource Usage;
• identifică eventualele pluginuri implicate;
• nu dezactiva Heartbeat dacă nu este necesar;
• testează creșterea intervalului înainte de dezactivare;
• acordă o atenție specială Heartbeat-ului din editor;
• testează autosave și editarea articolelor după modificare.

Dacă utilizezi LiteSpeed Cache, poți începe verificarea din:

LiteSpeed Cache → Toolbox → Heartbeat

În loc să dezactivezi complet funcția, poți testa un interval mai mare și verifica ulterior Resource Usage.

Nu optimiza WordPress doar după numărul de request-uri

Două website-uri pot genera același număr de request-uri Heartbeat și pot avea un consum complet diferit.

Un request care se finalizează în câteva zeci de milisecunde nu are același impact ca unul care execută interogări lente și rămâne activ câteva secunde.

De aceea, investigația trebuie să coreleze:

număr request-uri
+
durată procesare
+
CPU
+
Entry Processes
+
pluginuri
+
bază de date

și nu doar numărul de accesări ale admin-ajax.php.

WordPress Heartbeat este util, dar trebuie monitorizat corect

WordPress Heartbeat API este o funcționalitate normală a WordPress și nu trebuie tratată automat ca o problemă de performanță.

În majoritatea cazurilor, request-urile periodice au un rol util și permit funcționarea corectă a unor componente din wp-admin.

Problemele pot apărea atunci când există multe sesiuni simultane, intervale foarte scurte sau pluginuri care execută operațiuni costisitoare la fiecare Heartbeat.

Pe infrastructura NameBox, consumul poate fi corelat cu datele din cPanel → Resource Usage, iar website-urile care utilizează LiteSpeed Cache pot controla separat Heartbeat pentru frontend, backend și editor.

Înainte să dezactivezi funcția, identifică exact request-urile, verifică impactul asupra CPU și proceselor și testează mai întâi reducerea frecvenței.

Pe pagina noastră HelpDesk găsiți multe alte tutoriale utile pentru a gestiona mai ușor contul dvs. cPanel.

The post WordPress Heartbeat API: Cum poate afecta consumul de resurse appeared first on NAMEBOX.

Security Headers sunt headere HTTP trimise de server către browser prin care pot fi definite reguli suplimentare de securitate pentru website. Acestea pot controla, de exemplu, dacă pagina poate fi încărcată într-un iframe, din ce surse pot fi încărcate scripturile și imaginile sau dacă browserul trebuie să folosească exclusiv HTTPS.

Pe un website găzduit într-un mediu cPanel + LiteSpeed Enterprise, mai multe dintre aceste headere pot fi configurate direct din fișierul .htaccess, fără acces root la server.

Totuși, nu toate Security Headers pot fi copiate într-o configurație universală. Unele, precum
X-Content-Type-Options, X-Frame-Options și Referrer-Policy, sunt relativ simplu de implementat pentru majoritatea website-urilor. Altele, în special Content-Security-Policy, Permissions-Policy și Strict-Transport-Security, trebuie configurate și testate în funcție de website.

O configurație greșită poate bloca JavaScript, CSS, fonturi, imagini, iframe-uri, servicii externe sau chiar subdomenii întregi. Din acest motiv, înainte de orice modificare este important să faci un backup al fișierului .htaccess.

Ce sunt HTTP Security Headers?

Atunci când browserul accesează un website, serverul trimite un răspuns HTTP care conține atât conținutul solicitat, cât și o serie de headere.

Un răspuns simplificat poate arăta astfel:

HTTP/2 200
content-type: text/html; charset=UTF-8
server: LiteSpeed
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin

Unele dintre aceste headere oferă browserului instrucțiuni suplimentare despre modul în care trebuie tratată pagina.

Security Headers pot ajuta la limitarea riscurilor asociate cu:

• clickjacking;
• MIME type sniffing;
• anumite forme de Cross-Site Scripting – XSS;
• încărcarea unor resurse din surse neautorizate;
• expunerea inutilă a informațiilor din Referer;
• utilizarea neautorizată a camerei, microfonului sau geolocației;
• downgrade-ul conexiunilor HTTPS către HTTP.

Security Headers reprezintă însă doar un nivel al securității website-ului. Acestea nu înlocuiesc actualizarea aplicației, parolele sigure, autentificarea cu doi factori, ModSecurity, Imunify360, backup-ul sau certificatul SSL.

Pentru mai multe informații despre protecția la nivel de web server poți consulta și articolul ModSecurity în cPanel și eroarea 403.

Cum verifici Security Headers trimise de website?

Înainte să modifici configurația este recomandat să verifici ce headere sunt deja trimise.

Dacă ai acces la Terminal, Linux, macOS, Windows Terminal sau SSH, poți utiliza:

curl -I https://exemplu.ro

Înlocuiește:

exemplu.ro

cu domeniul pe care dorești să îl verifici.

De exemplu, poți primi:

HTTP/2 200
content-type: text/html; charset=UTF-8
server: LiteSpeed
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin

Pentru a afișa doar headerele de securitate care ne interesează putem folosi:

curl -sI https://exemplu.ro | grep -iE 'content-security|x-frame|x-content-type|referrer-policy|permissions-policy|strict-transport'

Dacă dorești să verifici headerele folosind un request GET real, nu HEAD, poți utiliza:

curl -s -D - -o /dev/null https://exemplu.ro/

Verificarea din browser

Headerele pot fi verificate și fără Terminal.

În Google Chrome, Firefox sau Edge deschide:

Developer Tools → Network

Reîncarcă pagina, selectează documentul principal și verifică:

Headers → Response Headers

Aici vei putea vedea headerele trimise efectiv utilizatorului.

Cum modifici fișierul .htaccess din cPanel?

Pe un cont cPanel, fișierul .htaccess poate fi modificat direct din File Manager.

Autentifică-te în cPanel și accesează:

cPanel → Files → File Manager

Dacă ai nevoie de informații despre accesarea panoului poți consulta tutorialul Cum accesăm contul cPanel?.

Navighează către document root-ul website-ului. Pentru domeniul principal acesta este frecvent:

/public_html

Pentru un domeniu suplimentar poate exista un document root separat.

Dacă fișierul:

.htaccess

nu este vizibil, apasă:

Settings → Show Hidden Files (dotfiles)

și salvează setarea.

Fă un backup înainte de modificare

Înainte să editezi .htaccess este recomandat să îl descarci sau să creezi o copie.

De exemplu:

.htaccess-backup

Dacă apare o eroare după modificare, poți reveni rapid la configurația inițială.

În cazul unui website WordPress, este recomandat să nu introduci regulile personalizate între:

# BEGIN WordPress

# END WordPress

WordPress poate rescrie automat conținutul acestei secțiuni. Regulile personalizate pot fi adăugate înainte sau după blocul administrat de WordPress.

Pentru mai multe exemple de utilizare a fișierului .htaccess poți consulta și ghidul despre redirectarea HTTP către HTTPS.

Security Headers pe cPanel și LiteSpeed

Este important să separăm rolurile tehnologiilor utilizate pe server.

Pe infrastructura NameBox sunt utilizate tehnologii precum cPanel, LiteSpeed Enterprise, CloudLinux și Imunify360, însă fiecare are un rol diferit.

LiteSpeed Enterprise este serverul web care procesează request-urile HTTP/HTTPS și generează răspunsurile către browser. LiteSpeed oferă compatibilitate cu configurațiile Apache utilizate în mediile cPanel și permite configurarea Security Headers prin .htaccess.

cPanel oferă interfața prin care utilizatorul își poate administra fișierele și poate modifica .htaccess.

CloudLinux este utilizat pentru izolarea conturilor și administrarea resurselor precum CPU, memorie și I/O. CloudLinux nu este componenta care aplică Security Headers.

AlmaLinux este sistemul de operare pe care poate rula serverul, nu componenta care procesează aceste headere HTTP.

Pentru mai multe informații despre serverul web poți consulta articolul LiteSpeed vs Apache.

A. Security Headers relativ sigure pentru majoritatea website-urilor

Următoarele trei headere reprezintă un punct bun de plecare pentru multe website-uri.

Chiar și în cazul acestora este recomandată testarea după modificare.

X-Content-Type-Options: nosniff

Headerul:

X-Content-Type-Options: nosniff

îi spune browserului să respecte tipul MIME declarat de server prin Content-Type și să nu încerce să interpreteze o resursă ca fiind de alt tip.

Configurația poate fi adăugată în .htaccess astfel:

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>

De exemplu, un fișier JavaScript trebuie să fie trimis cu un Content-Type corespunzător pentru JavaScript, iar un fișier CSS trebuie să fie livrat ca text/css.

Este important de reținut că nosniff nu repară Content-Type-urile configurate greșit. Dacă serverul livrează o resursă cu un MIME type incorect, aceasta poate fi blocată de browser după activarea headerului.

X-Frame-Options: SAMEORIGIN sau DENY?

X-Frame-Options controlează dacă o pagină poate fi încărcată în interiorul unui frame sau iframe.

Headerul poate limita riscul atacurilor de tip clickjacking, unde un website este încărcat într-un iframe și suprapus cu alte elemente pentru a determina utilizatorul să realizeze acțiuni pe care nu le intenționa.

Două valori importante sunt:

SAMEORIGIN
DENY

SAMEORIGIN permite afișarea paginii într-un frame atunci când originea este aceeași.

Exemplu:

Header always set X-Frame-Options "SAMEORIGIN"

DENY nu permite încărcarea paginii într-un frame, indiferent de origine.

Header always set X-Frame-Options "DENY"

Pentru majoritatea website-urilor obișnuite, SAMEORIGIN este mai flexibil.

Dacă website-ul nu trebuie niciodată afișat într-un iframe, poate fi analizată utilizarea DENY.

Dacă aplicația trebuie integrată în iframe-uri de pe alte domenii, X-Frame-Options poate deveni prea restrictiv. În configurațiile moderne poate fi utilizată și directiva CSP:

frame-ancestors

care permite politici mai precise.

Referrer-Policy: strict-origin-when-cross-origin

Atunci când utilizatorul accesează un link către altă pagină, browserul poate trimite informații despre pagina de pe care a venit prin headerul:

Referer

Referrer-Policy permite controlarea cantității de informații transmise.

O valoare echilibrată pentru multe website-uri este:

strict-origin-when-cross-origin

Configurația:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

permite transmiterea mai multor informații pentru navigarea în cadrul aceleiași origini, dar limitează informațiile transmise către alte origini.

La trecerea de la HTTPS către o destinație HTTP mai puțin sigură, informația Referer nu este transmisă.

Exemplu .htaccess pentru cele trei headere de bază

Pentru multe website-uri, un punct de pornire poate fi:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Aceste headere sunt relativ ușor de implementat, dar configurația trebuie verificată după salvarea fișierului.

Nu adăuga automat și următoarele headere în același bloc fără să înțelegi efectul lor.

B. Security Headers care trebuie adaptate website-ului

Content-Security-Policy, Permissions-Policy și HSTS pot oferi protecții suplimentare importante, dar trebuie configurate în funcție de modul în care funcționează website-ul.

O regulă copiată de pe alt site poate produce probleme majore.

Content-Security-Policy – CSP

Content-Security-Policy este unul dintre cele mai puternice Security Headers disponibile browserelor moderne.

CSP permite administratorului să definească sursele din care pagina are voie să încarce diferite tipuri de conținut.

De exemplu, o politică poate spune:

JavaScript → doar de pe domeniul propriu
CSS → domeniul propriu + Google Fonts
Imagini → domeniul propriu + CDN
iframe → doar YouTube
API → doar anumite endpoint-uri

Browserul va putea bloca resursele care nu respectă politica.

Ce poate limita Content Security Policy?

O configurație CSP bine realizată poate reduce impactul unor vulnerabilități și atacuri precum:

• Cross-Site Scripting – XSS;
• injectarea de scripturi;
• încărcarea resurselor din surse neautorizate;
• anumite forme de clickjacking;
• executarea unor elemente injectate într-o pagină compromisă.

CSP nu repară însă vulnerabilitatea aplicației. Aceasta reprezintă un strat suplimentar de protecție aplicat de browser.

Directive importante CSP

O politică CSP este alcătuită din mai multe directive.

default-src

Definește politica implicită pentru tipurile de resurse care nu au o directivă mai specifică.

default-src 'self'

‘self’ reprezintă aceeași origine ca website-ul curent.

script-src

Controlează sursele din care poate fi încărcat și executat JavaScript.

script-src 'self'

O astfel de regulă este foarte restrictivă și poate bloca Google Analytics, Google Tag Manager, reCAPTCHA, scripturile procesatorilor de plăți sau JavaScript inline.

style-src

Controlează sursele CSS.

style-src 'self'

Poate afecta Google Fonts, stylesheet-uri externe și stiluri inline generate de WordPress, teme sau page builders.

img-src

Controlează sursele din care pot fi încărcate imaginile.

De exemplu:

img-src 'self' data: https:

Acest exemplu permite imagini din propria origine, data URI și surse HTTPS, dar trebuie analizat în funcție de website.

font-src

Controlează sursele fonturilor.

font-src 'self'

Dacă website-ul utilizează Google Fonts sau un CDN extern, politica trebuie adaptată.

connect-src

Controlează destinațiile către care pot fi realizate anumite conexiuni din browser, de exemplu prin Fetch, XMLHttpRequest sau WebSocket.

Este important pentru:

• API-uri;
• Google Analytics;
• servicii externe;
• aplicații JavaScript;
• servicii de monitorizare.

frame-src

Controlează sursele care pot fi încărcate într-un iframe.

Este relevant pentru servicii precum:

• YouTube;
• Google Maps;
• reCAPTCHA;
• procesatori de plăți;
• platforme video;
• widget-uri externe.

frame-ancestors

Controlează ce site-uri au voie să încarce pagina ta într-un iframe.

De exemplu:

frame-ancestors 'self'

are un rol similar cu X-Frame-Options SAMEORIGIN, dar permite configurații CSP mai flexibile.

form-action

Poate limita destinațiile către care formularele din pagină au voie să trimită date.

form-action 'self'

Acest lucru trebuie verificat dacă website-ul utilizează formulare care trimit utilizatorul către procesatori de plăți sau servicii externe.

De ce nu există o configurație CSP universală?

Fiecare website încarcă resurse diferite.

Un site simplu poate utiliza exclusiv fișiere locale, în timp ce un magazin online sau un website WordPress poate comunica cu zeci de servicii externe.

Printre serviciile care trebuie analizate se numără:

• Google Fonts;
• Google Analytics;
• Google Tag Manager;
• YouTube;
• Google Maps;
• Google reCAPTCHA;
• Cloudflare sau alte CDN-uri;
• Meta Pixel;
• chat-uri externe;
• procesatori de plăți;
• API-uri;
• fonturi și scripturi furnizate de teme sau pluginuri.

În WordPress, situația poate deveni și mai complexă deoarece o temă, un plugin sau un page builder poate adăuga JavaScript și CSS inline.

Pentru informații despre administrarea WordPress poți consulta articolul Cum instalez WordPress direct din cPanel?.

Ce se întâmplă dacă CSP este configurat greșit?

Să presupunem că introduci:

Content-Security-Policy: default-src 'self'

Această regulă poate părea sigură, însă un website care folosește servicii externe poate începe imediat să aibă probleme.

Pot fi blocate:

• scripturile Google Analytics;
• Google Tag Manager;
• Google Fonts;
• imagini de pe CDN;
• iframe-uri YouTube;
• reCAPTCHA;
• widget-uri externe;
• checkout-uri sau componente ale procesatorilor de plăți;
• request-uri API.

Website-ul poate continua să afișeze pagina HTML, dar anumite funcții pot să nu mai funcționeze.

Nu rezolva automat problemele CSP adăugând * sau ‘unsafe-inline’ peste tot. Aceste modificări pot reduce semnificativ protecția pe care CSP ar trebui să o ofere.

Testează CSP cu Content-Security-Policy-Report-Only

Înainte să aplici o politică restrictivă este recomandat să o testezi.

Pentru aceasta există:

Content-Security-Policy-Report-Only

În acest mod browserul poate identifica încălcările politicii fără să blocheze efectiv resursele.

De exemplu, pentru testare:

<IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self' https:; connect-src 'self'; frame-src 'self'"
</IfModule>

Acesta este doar un exemplu pentru testare și nu o politică recomandată universal.

După activare, deschide:

Developer Tools → Console

și navighează prin website.

Browserul poate afișa resursele care ar fi fost blocate dacă politica ar fi fost aplicată efectiv.

Testează în special:

• homepage-ul;
• formularele;
• wp-admin;
• login-ul;
• checkout-ul;
• plățile;
• video-urile;
• hărțile;
• reCAPTCHA;
• funcțiile JavaScript;
• pagini care comunică cu API-uri.

Dacă dorești centralizarea automată a rapoartelor CSP, trebuie configurat și un endpoint capabil să primească rapoartele împreună cu mecanismul Reporting API. Nu este suficient să introduci o adresă aleatorie în .htaccess.

Permissions-Policy

Permissions-Policy permite controlarea accesului paginii și al conținutului încorporat la anumite funcții ale browserului sau dispozitivului.

Printre acestea se numără:

• camera;
• microfonul;
• geolocația;
• anumite funcții asociate dispozitivului.

Dacă website-ul nu are nevoie de cameră, microfon sau geolocație, un exemplu este:

Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Această configurație dezactivează funcțiile respective.

Nu trebuie însă aplicată automat.

De exemplu, poate afecta:

• un website care permite realizarea unei fotografii cu camera;
• o platformă de videoconferință;
• o aplicație care utilizează microfonul;
• un magazin care detectează locația utilizatorului.

În plus, suportul pentru anumite directive Permissions-Policy poate varia între browsere, motiv pentru care configurația trebuie verificată înainte de producție.

Strict-Transport-Security – HSTS

Strict-Transport-Security, cunoscut și ca HSTS, îi spune browserului că website-ul trebuie accesat exclusiv prin HTTPS.

După ce browserul primește politica HSTS printr-o conexiune HTTPS, viitoarele încercări de acces prin HTTP sunt convertite automat către HTTPS de browser.

Un exemplu este:

Strict-Transport-Security: max-age=31536000

Valoarea:

31536000

reprezintă un an în secunde.

Când poate fi activat HSTS?

HSTS trebuie analizat doar după ce website-ul funcționează complet prin HTTPS.

Înainte de activare verifică:

• certificatul SSL este valid;
• HTTP redirecționează către HTTPS;
• toate paginile funcționează prin HTTPS;
• nu există probleme Mixed Content importante;
• serviciile website-ului nu depind de acces HTTP.

Pentru informații despre HTTPS poți consulta pagina de certificate SSL NameBox și articolul despre redirect HTTP către HTTPS.

Testează HSTS cu un max-age redus

Dacă dorești să testezi HSTS, poți începe cu o perioadă mai redusă înainte de a configura o valoare de un an.

De exemplu:

<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=86400"
</IfModule>

Această valoare reprezintă o zi.

După ce ai confirmat că HTTPS funcționează corect pentru website, politica poate fi reevaluată.

Pentru o perioadă de un an:

Header always set Strict-Transport-Security "max-age=31536000"

HSTS este luat în considerare de browser numai atunci când este primit printr-o conexiune HTTPS.

Ce face includeSubDomains?

Poți întâlni și configurația:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

includeSubDomains extinde politica HSTS către subdomenii.

De exemplu, pentru:

exemplu.ro

politica poate afecta și:

shop.exemplu.ro
mail.exemplu.ro
client.exemplu.ro
api.exemplu.ro

Nu activa includeSubDomains dacă nu ești sigur că toate subdomeniile sunt și vor rămâne disponibile prin HTTPS.

Un subdomeniu care funcționează doar prin HTTP poate deveni inaccesibil în browser după aplicarea politicii.

Ce este HSTS preload?

Poți întâlni configurații precum:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Preload permite introducerea domeniului într-o listă HSTS distribuită direct în browsere.

Astfel, browserul poate ști că domeniul necesită HTTPS chiar înainte de prima conexiune.

Nu recomandăm activarea preload doar pentru a obține un scor mai bun într-un instrument de testare Security Headers.

Înainte de preload trebuie să fii sigur că:

• domeniul funcționează exclusiv prin HTTPS;
• toate subdomeniile funcționează prin HTTPS;
• includeSubDomains poate fi activat în siguranță;
• înțelegi consecințele pe termen lung;
• infrastructura viitoare va păstra HTTPS pentru toate hostname-urile afectate.

Eliminarea unui domeniu dintr-o listă preload nu are efect instantaneu în toate browserele. De aceea, preload trebuie tratat ca o decizie importantă de infrastructură, nu ca o simplă linie adăugată în .htaccess.

Configurație .htaccess recomandată ca punct de pornire

Nu recomandăm adăugarea tuturor Security Headers într-un singur snippet universal.

Împărțim configurația în două categorii.

A. Headere relativ sigure pentru majoritatea website-urilor

Acesta poate reprezenta un punct de pornire:

<IfModule mod_headers.c>

    # Previne MIME type sniffing
    Header always set X-Content-Type-Options "nosniff"

    # Limitează afișarea website-ului în iframe-uri
    Header always set X-Frame-Options "SAMEORIGIN"

    # Limitează informațiile Referer transmise către alte origini
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

</IfModule>

După adăugare, salvează .htaccess și testează website-ul.

B. Headere care trebuie configurate și testate separat

Următoarele exemple nu trebuie copiate automat într-un website live.

Content-Security-Policy – testare:

<IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self' https:; connect-src 'self'; frame-src 'self'"
</IfModule>

După identificarea tuturor resurselor necesare, politica trebuie adaptată website-ului înainte de transformarea ei în:

Content-Security-Policy

Permissions-Policy:

<IfModule mod_headers.c>
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Folosește această configurație numai dacă website-ul nu are nevoie de funcțiile respective.

HSTS pentru testare:

<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=86400"
</IfModule>

După verificarea completă a HTTPS poate fi analizată o perioadă mai mare.

Nu adăuga includeSubDomains sau preload înainte să verifici toate subdomeniile.

Cum verifici Security Headers după modificare?

După salvarea fișierului .htaccess verifică website-ul:

curl -I https://exemplu.ro

Ar trebui să vezi, în funcție de configurația aplicată:

x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin

Dacă ai configurat și alte politici:

content-security-policy-report-only: ...
permissions-policy: ...
strict-transport-security: ...

Pentru filtrare rapidă:

curl -sI https://exemplu.ro | grep -iE 'content-security|x-frame|x-content-type|referrer-policy|permissions-policy|strict-transport'

Testează mai mult decât homepage-ul

Faptul că homepage-ul se afișează corect nu înseamnă că întregul website funcționează după modificarea Security Headers.

Testează și:

• paginile interne;
• formularele de contact;
• login-ul;
• wp-admin;
• Google Maps;
• video-urile YouTube;
• reCAPTCHA;
• Google Analytics;
• Tag Manager;
• chat-urile externe;
• checkout-ul unui magazin online;
• procesarea plăților;
• API-urile și AJAX;
• fonturile și imaginile externe.

Verifică Browser Console după activarea CSP

Pentru Content Security Policy, unul dintre cele mai utile instrumente este:

Developer Tools → Console

Dacă o resursă este refuzată de CSP, browserul poate afișa un mesaj asemănător cu:

Refused to load the script because it violates the following Content Security Policy directive...

Mesajul indică de regulă tipul resursei și directiva care a provocat problema.

Nu adăuga domeniul respectiv automat în whitelist. Verifică mai întâi dacă resursa este legitimă și dacă website-ul are într-adevăr nevoie de ea.

Ce faci dacă website-ul nu mai funcționează după modificarea .htaccess?

Dacă website-ul afișează o eroare imediat după modificare, primul pas este revenirea la configurația anterioară.

Înlocuiește fișierul cu backup-ul realizat înainte:

.htaccess-backup

sau elimină doar regulile nou adăugate.

Dacă apare o eroare 500, este posibil să existe o problemă de sintaxă în .htaccess.

Dacă pagina se deschide, dar anumite componente nu funcționează, verifică:

• Browser Console;
• Network;
• Content Security Policy;
• iframe-urile;
• fonturile;
• scripturile externe.

Nu confunda Security Headers cu permisiunile fișierelor

Security Headers și permisiunile Linux rezolvă probleme complet diferite.

Headerele HTTP controlează comportamentul browserului, în timp ce permisiunile stabilesc cine poate citi, scrie sau executa fișiere pe server.

Pentru mai multe informații poți consulta ghidul Permisiuni fișiere în cPanel: 644, 755 și 777.

Security Headers nu înlocuiesc securitatea serverului

Security Headers pot limita anumite riscuri la nivelul browserului, însă nu pot proteja singure un website compromis.

De exemplu, CSP nu înlocuiește:

• actualizarea WordPress;
• actualizarea pluginurilor și temelor;
• ModSecurity;
• Imunify360;
• parolele puternice;
• autentificarea 2FA;
• backup-ul;
• protecția accesului SSH sau cPanel.

Pe infrastructura NameBox, LiteSpeed Enterprise este utilizat ca server web, CloudLinux pentru izolarea și administrarea resurselor conturilor, iar Imunify360 și ModSecurity oferă niveluri suplimentare de securitate pentru aplicațiile web.

Security Headers completează aceste tehnologii prin reguli aplicate de browser după ce răspunsul HTTP a fost primit.

Ai grijă la headerele configurate în mai multe locuri

Un website poate avea Security Headers definite din mai multe surse:

• .htaccess;
• configurația web serverului;
• aplicația PHP;
• un plugin WordPress;
• un CDN sau reverse proxy;
• o platformă externă precum Cloudflare.

Dacă același header este configurat în mai multe locuri, pot apărea valori duplicate sau politici care nu corespund intenției administratorului.

De aceea, verificarea trebuie realizată întotdeauna pe răspunsul public final:

curl -I https://exemplu.ro

și nu doar prin examinarea fișierului .htaccess.

O configurație mai strictă nu este automat una mai bună

Scopul Security Headers nu este să activezi cât mai multe reguli doar pentru a obține un scor maxim într-un scanner online.

O politică trebuie să protejeze website-ul fără să îi afecteze funcționalitatea.

Pentru majoritatea website-urilor poți începe cu:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin

Apoi analizează separat dacă proiectul permite utilizarea:

• Content-Security-Policy;
• Permissions-Policy;
• Strict-Transport-Security.

Pentru CSP, începe cu Content-Security-Policy-Report-Only, identifică toate resursele utilizate și aplică politica numai după testare.

Pentru HSTS, verifică mai întâi că HTTPS funcționează corect pe întregul website și tratează includeSubDomains și mai ales preload cu atenție.

Dacă utilizezi serviciile de găzduire web NameBox, configurațiile .htaccess sunt procesate în mediul cPanel + LiteSpeed, iar Security Headers pot fi aplicate la nivelul website-ului fără modificarea configurației globale a serverului.

The post Security Headers în .htaccess: Cum protejezi un website appeared first on NAMEBOX.

Mail Queue Manager în WHM permite administratorului unui server cPanel să verifice mesajele care au rămas în coada serverului de email, să încerce din nou livrarea acestora, să elimine anumite mesaje sau să investigheze motivele pentru care un email nu a putut fi livrat.

Pe serverele cPanel & WHM, serviciul utilizat pentru trimiterea și recepționarea mesajelor prin SMTP este Exim. Atunci când un mesaj nu poate fi livrat imediat, acesta poate rămâne temporar în coada Exim pentru o nouă încercare.

În acest tutorial vom vedea cum utilizăm Mail Queue Manager din WHM, ce înseamnă mesajele Frozen sau Deferred și ce comenzi putem folosi din SSH pentru investigarea cozii de email.

Ce este Mail Queue Manager în WHM?

Mail Queue Manager WHM este interfața prin care poți administra mesajele aflate în coada Exim a serverului.

O poți accesa din:

WHM → Email → Mail Queue Manager

Din această interfață poți:

• vedea mesajele aflate în coadă;
• căuta după expeditor sau destinatar;
• identifica Message ID-ul;
• verifica dimensiunea mesajului;
• vedea statusul acestuia;
• încerca din nou livrarea;
• șterge un mesaj;
• debloca un mesaj Frozen.

Mail Queue Manager este destinat administratorilor serverului și necesită acces WHM cu privilegiile corespunzătoare.

Ce este coada de email Exim?

Atunci când serverul primește un email pentru expediere, Exim încearcă să îl livreze către serverul destinatar.

Într-o situație normală:

Expeditor
   ↓
Exim
   ↓
Server destinatar
   ↓
Mesaj livrat

Există însă situații în care serverul destinatar nu poate accepta imediat mesajul.

Atunci putem avea:

Expeditor
   ↓
Exim
   ↓
Livrarea nu poate fi finalizată
   ↓
Mesajul rămâne în Mail Queue
   ↓
Exim încearcă din nou ulterior

Prezența câtorva mesaje în coadă nu indică automat o problemă a serverului.

De ce rămân emailurile în Mail Queue?

Există numeroase motive pentru care un mesaj poate rămâne temporar în coada Exim.

Printre cele mai frecvente se numără:

• serverul destinatar nu răspunde;
• probleme DNS pentru domeniul destinatar;
• serverul remote aplică rate limiting;
• căsuța destinatarului este plină;
• adresa destinatarului nu este validă;
• serverul remote refuză temporar conexiunea;
• probleme de reputație ale IP-ului sau domeniului;
• limita de trimitere a domeniului a fost atinsă;
• mesajele au fost puse intenționat în Hold;
• un cont compromis generează cantități mari de email;
• există o problemă de configurare Exim.

Din acest motiv, înainte să ștergi sau să forțezi livrarea unui mesaj trebuie verificat motivul pentru care acesta a ajuns în coadă.

Cum accesezi Mail Queue Manager?

Autentifică-te în WHM și accesează:

WHM → Email → Mail Queue Manager

Dacă administrezi un VPS NameBox, accesul securizat în WHM se realizează în mod normal prin portul:

2087

De exemplu:

https://server.exemplu.ro:2087

După autentificare, caută:

Mail Queue Manager

în bara de căutare WHM.

Ce informații afișează Mail Queue Manager?

Lista mesajelor include informații utile pentru identificarea problemei.

Printre coloanele principale se află:

• Time Received – momentul înregistrării mesajului;
• Sender – expeditorul;
• Message ID – identificatorul unic Exim;
• Recipient(s) – destinatarul sau destinatarii;
• Size – dimensiunea mesajului;
• Status – starea mesajului;
• Action – operațiunile disponibile.

Message ID este foarte important atunci când dorești să urmărești un anumit mesaj în logurile Exim.

Un Message ID poate arăta astfel:

1xAbCd-000123-4EfG

Cum cauți un anumit email în Mail Queue Manager?

În partea de sus a interfeței poți utiliza funcția de căutare.

Poți căuta, de exemplu, după:

• expeditor;
• destinatar;
• Message ID;
• alte informații disponibile prin filtrele interfeței.

De exemplu, dacă suspectezi probleme pentru:

office@exemplu.ro

poți utiliza această adresă pentru filtrarea rezultatelor.

Mail Queue Manager permite și selectarea unei perioade de timp pentru raport.

Este important de reținut că funcția de căutare din Mail Queue Manager nu caută în corpul mesajului.

Ce înseamnă un email Deferred?

Un mesaj Deferred nu a putut fi livrat momentan, dar problema este considerată temporară.

De exemplu:

451 Temporary local problem

sau:

Connection timed out

Exim poate păstra mesajul în coadă și va încerca din nou livrarea conform mecanismului său de retry.

Un mesaj Deferred nu trebuie șters automat. Mai întâi trebuie analizat motivul amânării.

Ce înseamnă un email Frozen?

Dacă Exim nu reușește să livreze un mesaj după mai multe încercări sau acesta ajunge într-o situație în care livrarea nu mai poate continua normal, mesajul poate apărea cu status:

Frozen

Un mesaj Frozen nu va continua în același mod cu încercările normale de livrare până când situația este rezolvată sau mesajul este deblocat.

Dacă observi multe mesaje Frozen în server, nu este recomandat să le dai pur și simplu Unfreeze pe toate.

Trebuie verificată mai întâi cauza în:

/var/log/exim_mainlog

Cum faci Unfreeze unui email?

Din Mail Queue Manager WHM, mesajele Frozen au disponibilă opțiunea de deblocare.

Selectează mesajul și folosește:

Unfreeze

După deblocare, Exim poate încerca din nou procesarea mesajului.

Deblocarea nu rezolvă însă cauza inițială.

Dacă serverul destinatar continuă să refuze mesajul sau configurația DNS este greșită, emailul poate eșua din nou.

Cum încerci din nou livrarea unui mesaj?

Selectează mesajul dorit și folosește:

Deliver Message Now

sau, pentru mai multe mesaje:

Deliver Selected

WHM va încerca imediat livrarea și va afișa rezultatul operațiunii.

Dacă problema care a provocat blocarea mesajului există în continuare, livrarea va eșua din nou.

De aceea, această funcție trebuie utilizată după ce ai verificat cauza.

Ai grijă la Deliver All

Mail Queue Manager oferă și opțiunea:

Deliver All

Aceasta încearcă livrarea tuturor mesajelor aflate în coada serverului, nu doar a mesajelor afișate de filtrul curent.

Pe un server cu mii de mesaje aflate în queue, utilizarea acestei opțiuni fără investigație poate genera un volum foarte mare de conexiuni și tentative de livrare.

Este mai sigur să identifici mai întâi problema și să testezi un număr redus de mesaje.

Cum ștergi un email din Mail Queue Manager?

Dacă ai confirmat că un mesaj nu mai trebuie livrat, îl poți selecta și utiliza:

Delete Selected

Înainte de ștergere verifică:

• expeditorul;
• destinatarul;
• Message ID-ul;
• motivul pentru care mesajul este în coadă.

Ștergerea unui mesaj din coada Exim este definitivă.

Nu folosi Delete All fără să verifici coada

WHM oferă și opțiunea:

Delete All

Aceasta elimină toate mesajele din Mail Queue, inclusiv mesajele legitime.

Nu utiliza această funcție doar pentru a „goli coada”.

Dacă există mii de mesaje SPAM, identifică mai întâi contul sau scriptul care le generează și oprește sursa.

Altfel, coada se va umple din nou imediat.

Cum verifici Mail Queue din SSH?

Dacă ai acces root la server, poți administra și investiga Exim direct din SSH.

Comenzile de mai jos necesită privilegii administrative.

Verifică numărul total de mesaje din queue

exim -bpc

Rezultatul poate fi:

245

ceea ce înseamnă că există 245 de mesaje în coada Exim.

Afișează mesajele din queue

exim -bp

Această comandă afișează lista mesajelor existente în coadă.

Poți vedea informații precum:

• vechimea mesajului;
• dimensiunea;
• Message ID;
• expeditor;
• destinatar.

Cum găsești mesajele unui anumit expeditor?

Dacă dorești să identifici Message ID-urile mesajelor trimise de:

office@exemplu.ro

poți utiliza:

exiqgrep -f 'office@exemplu.ro' -i

Comanda este utilă atunci când suspectezi că o anumită adresă generează un volum mare de email.

Înainte să ștergi mesajele, verifică dacă acestea sunt legitime.

Cum verifici header-ele unui mesaj din queue?

Dacă ai Message ID-ul:

1xAbCd-000123-4EfG

poți verifica header-ele cu:

exim -Mvh 1xAbCd-000123-4EfG

Header-ele pot conține informații precum:

• From;
• To;
• Subject;
• Message-ID;
• Received;
• date despre originea mesajului.

Cum verifici conținutul unui mesaj?

Pentru corpul mesajului:

exim -Mvb 1xAbCd-000123-4EfG

Această comandă trebuie utilizată doar atunci când este necesară investigarea mesajului și administratorul are dreptul să acceseze conținutul acestuia.

Cum verifici logul intern al mesajului?

Exim permite afișarea logului asociat mesajului aflat în spool:

exim -Mvl 1xAbCd-000123-4EfG

Acesta poate oferi informații suplimentare despre procesarea mesajului.

Cum urmărești Message ID-ul în exim_mainlog?

Principalul log Exim pe un server cPanel este:

/var/log/exim_mainlog

Pentru un anumit Message ID:

grep '1xAbCd-000123-4EfG' /var/log/exim_mainlog

Poți vedea astfel traseul mesajului și eventualele erori primite de la serverul destinatar.

De exemplu, poți găsi răspunsuri precum:

421 Try again later

sau:

550 User unknown

sau:

Connection timed out

Mesajul de eroare primit este esențial pentru identificarea cauzei reale.

Cum urmărești Exim în timp real?

Pentru monitorizarea logului:

tail -f /var/log/exim_mainlog

Apoi poți realiza o trimitere de test și urmări în timp real ce se întâmplă.

Oprești comanda cu:

CTRL + C

Cum cauți activitatea unei anumite adrese de email?

Poți utiliza:

grep 'office@exemplu.ro' /var/log/exim_mainlog | tail -100

Această verificare este utilă pentru identificarea mesajelor trimise sau procesate pentru adresa respectivă.

Pentru serverele foarte active este recomandat să limitezi căutarea la intervalul relevant sau la logurile necesare.

Cum forțezi livrarea unui singur mesaj din SSH?

Dacă ai verificat cauza și dorești să forțezi o nouă încercare:

exim -M 1xAbCd-000123-4EfG

Această comandă încearcă imediat livrarea mesajului și poate ignora timpul normal de retry.

Nu are rost să o execuți repetat dacă serverul remote continuă să refuze mesajul.

Cum faci Unfreeze din SSH?

Pentru un mesaj Frozen:

exim -Mt 1xAbCd-000123-4EfG

Comanda face thaw/unfreeze mesajului.

După aceea, trebuie verificat dacă acesta poate fi livrat normal.

Cum ștergi un singur mesaj din SSH?

Dacă ai confirmat că mesajul trebuie eliminat:

exim -Mrm 1xAbCd-000123-4EfG

Atenție: această operațiune elimină mesajul din queue și nu trimite automat un bounce expeditorului.

Verifică întotdeauna Message ID-ul înainte de executarea comenzii.

Nu goli întreaga coadă Exim ca primă soluție

Există comenzi prin care administratorul poate șterge toate mesajele din coadă, însă nu recomandăm utilizarea lor ca metodă generică de depanare.

Coada poate conține simultan:

• mesaje SPAM;
• emailuri business legitime;
• facturi;
• notificări;
• mesaje primite;
• mesaje care așteaptă doar revenirea unui server remote.

Ștergerea completă poate produce pierderi de mesaje legitime.

Ce trebuie verificat dacă Mail Queue crește foarte repede?

Dacă numărul mesajelor crește de la câteva zeci la sute sau mii într-un timp scurt, trebuie identificată imediat sursa.

Începe cu:

exim -bpc

apoi:

exim -bp

Verifică dacă mesajele au:

• același expeditor;
• același domeniu;
• subiecte similare;
• destinatari aleatorii;
• un volum neobișnuit.

Dacă majoritatea mesajelor provin de la aceeași adresă, este posibil ca respectiva căsuță să fi fost compromisă.

Ce faci dacă o adresă compromisă trimite SPAM?

Prioritatea este oprirea sursei, nu doar ștergerea mesajelor din queue.

Din cPanel poți accesa:

cPanel → Email → Email Accounts → Manage

și suspenda temporar:

Sending Outgoing Mail

Apoi:

• schimbă parola adresei;
• verifică dispozitivele pe care este configurată;
• analizează logurile;
• verifică dacă mesajele sunt trimise prin SMTP sau de un script;
• elimină mesajele SPAM rămase în coadă;
• reactivează trimiterea doar după rezolvarea problemei.

Pentru mai multe informații poți consulta articolul nostru despre cum să previi trimiterea emailurilor SPAM din cPanel.

Spam trimis de website sau spam trimis prin SMTP?

Este important să identifici și modul în care mesajele ajung în Exim.

Un cont compromis poate trimite emailuri prin autentificare SMTP:

office@exemplu.ro
        ↓
SMTP AUTH
        ↓
Exim

Dar un website compromis poate genera mesaje direct prin PHP:

WordPress / script PHP
        ↓
sendmail / Exim
        ↓
Mail Queue

În al doilea caz, schimbarea parolei căsuței de email nu rezolvă problema.

Website-ul trebuie verificat pentru:

• malware;
• fișiere PHP suspecte;
• pluginuri vulnerabile;
• Cron Jobs malițioase;
• conturi administrative compromise.

Mesajele puse pe Hold pot apărea în queue

cPanel & WHM poate detecta un cont care trimite către un număr foarte mare de destinatari unici și, în funcție de configurația administratorului, poate pune mesajele outgoing în:

Hold

În WHM, aceste protecții pot fi configurate din:

WHM → Server Configuration → Tweak Settings → Mail

Acolo există setări pentru:

• limita de emailuri trimise pe oră;
• monitorizarea destinatarilor unici;
• mesaje failed sau deferred;
• acțiunea aplicată unui posibil spammer.

Nu modifica limitele doar pentru a face coada să dispară. Dacă există spam, creșterea limitei permite trimiterea unui volum și mai mare de mesaje.

Ce înseamnă dacă serverul remote aplică rate limiting?

Furnizori precum Google, Microsoft, Yahoo și alte platforme pot limita temporar numărul mesajelor acceptate de la un anumit server.

În log poți vedea mesaje SMTP de tip:

421

sau:

451

împreună cu o explicație furnizată de serverul destinatar.

În această situație, Exim poate păstra mesajele în coadă și încerca livrarea ulterior.

Forțarea repetată a tuturor mesajelor nu rezolvă problema de reputație sau rate limiting și poate agrava situația.

Ce verifici dacă mesajele către un singur domeniu rămân în queue?

Dacă problema apare doar pentru:

@exemplu-destinatar.ro

verifică:

• înregistrările MX ale domeniului;
• dacă serverul MX răspunde;
• mesajul din exim_mainlog;
• dacă există timeout;
• dacă serverul destinatar respinge IP-ul;
• dacă mesajul este blocat din cauza politicilor antispam.

Problema nu este neapărat la serverul de expediere.

Mail Queue Manager și Email Deliverability au roluri diferite

Mail Queue Manager WHM arată mesajele care așteaptă livrarea.

Email Deliverability este utilizat pentru verificarea unor elemente DNS și de autentificare pentru email, precum:

• SPF;
• DKIM;
• DMARC;
• anumite informații asociate configurației domeniului.

Dacă mesajele ajung în queue din cauza unor probleme de livrabilitate, trebuie analizate ambele componente.

Poți consulta și tutorialul nostru despre verificarea setărilor Email Deliverability în cPanel.

Verifică și Reverse DNS / PTR

Pentru un server VPS care trimite direct email, configurația IP-ului este importantă.

Verifică:

• PTR / Reverse DNS;
• hostname-ul serverului;
• Mail HELO / EHLO;
• SPF;
• DKIM;
• DMARC;
• reputația IP-ului.

Poți consulta ghidul nostru despre Reverse DNS și PTR Record pentru email.

Când trebuie verificat exim_paniclog?

Pe lângă:

/var/log/exim_mainlog

Exim utilizează și:

/var/log/exim_paniclog

Acest fișier este destinat erorilor grave ale serviciului Exim.

În mod normal, exim_paniclog nu ar trebui să conțină erori.

Dacă acesta conține intrări recente, problema trebuie investigată la nivelul serviciului Exim.

Mai există și:

/var/log/exim_rejectlog

unde pot fi găsite informații despre anumite mesaje respinse prin regulile Exim.

Checklist pentru un Mail Queue foarte mare

Dacă observi sute sau mii de mesaje în coadă, verifică în această ordine:

1. numărul total de mesaje cu exim -bpc;
2. expeditorii și destinatarii din exim -bp;
3. dacă există un expeditor dominant;
4. dacă mesajele sunt legitime sau SPAM;
5. statusul Frozen / Deferred;
6. Message ID-ul unui mesaj reprezentativ;
7. header-ele mesajului;
8. logul din /var/log/exim_mainlog;
9. mesajul SMTP returnat de serverul remote;
10. SPF, DKIM, DMARC și PTR;
11. limitele de trimitere;
12. eventuale conturi sau website-uri compromise.

Nu trata Mail Queue-ul fără să identifici cauza

O coadă mare de email este de cele mai multe ori un simptom, nu problema în sine.

Dacă ștergi toate mesajele fără să identifici sursa, acestea pot reapărea imediat.

Începe cu Mail Queue Manager WHM pentru o imagine generală, selectează un mesaj reprezentativ și urmărește Message ID-ul în:

/var/log/exim_mainlog

Dacă problema este un server remote indisponibil, Exim poate relua automat livrarea. Dacă este vorba despre SPAM, oprește mai întâi contul sau scriptul care generează mesajele.

Pe un server cPanel/WHM, combinația dintre Mail Queue Manager, logurile Exim și instrumentele de Email Deliverability permite identificarea majorității problemelor de trimitere fără să fie necesară golirea completă a cozii.

Pe pagina noastră HelpDesk găsiți multe alte tutoriale utile pentru a gestiona mai ușor contul dvs. cPanel și serviciile NameBox.

The post Mail Queue Manager în WHM appeared first on NAMEBOX.

Raw Access Logs în cPanel și AWStats sunt două instrumente utile atunci când dorești să afli cine accesează website-ul, ce pagini generează cele mai multe request-uri și dacă există boți sau IP-uri care produc trafic neobișnuit.

Un website poate deveni lent nu doar din cauza aplicației sau a resurselor disponibile, ci și atunci când primește un număr foarte mare de request-uri către pagini dinamice, wp-login.php, API-uri, pagini inexistente sau alte URL-uri.

În acest articol vom vedea cum folosim AWStats și Raw Access Logs în cPanel, cum interpretăm logurile și cum putem identifica rapid IP-uri, boți, erori HTTP și request-uri suspecte.

Ce sunt logurile de acces ale unui website?

De fiecare dată când un browser, un robot sau o aplicație face un request către server, acesta poate fi înregistrat în access log.

De exemplu, atunci când un vizitator accesează:

https://exemplu.ro/contact/

serverul poate salva informații precum:

• adresa IP;
• data și ora accesării;
• metoda HTTP – GET, POST etc.;
• URL-ul solicitat;
• codul HTTP returnat;
• dimensiunea răspunsului;
• pagina de referință;
• User-Agent-ul utilizatorului.

Aceste informații permit reconstruirea activității care a avut loc pe website și sunt foarte utile atunci când investigăm trafic ridicat sau erori.

AWStats sau Raw Access Logs?

Cele două instrumente folosesc informațiile despre traficul website-ului, dar sunt destinate unor verificări diferite.

Pentru o verificare rapidă poți începe cu AWStats. Dacă observi o anomalie, Raw Access Logs cPanel îți permite să investighezi request-urile individuale.

Cum accesezi AWStats în cPanel?

Autentifică-te în cPanel și accesează:

cPanel → Metrics → Awstats

Alege domeniul pe care dorești să îl analizezi și apasă:

View

AWStats procesează informațiile din logurile serverului și le prezintă într-o interfață mai ușor de analizat.

Ce informații poți vedea în AWStats?

AWStats poate afișa informații despre modul în care website-ul este accesat.

Printre cele mai utile se numără:

• traficul lunar;
• traficul zilnic;
• traficul pe intervale orare;
• paginile și URL-urile accesate;
• codurile HTTP;
• referrer-ele;
• browserele utilizate;
• sistemele de operare;
• originea geografică aproximativă a traficului.

Aceste informații pot ajuta la identificarea unor schimbări bruște în comportamentul traficului.

AWStats nu trebuie interpretat ca trafic în timp real

AWStats procesează logurile periodic, motiv pentru care statisticile nu trebuie tratate ca un sistem de monitorizare în timp real.

Poate exista un interval între momentul în care request-ul ajunge la server și momentul în care acesta apare în statisticile procesate.

Pentru o investigație precisă la o anumită oră este mai potrivit access log-ul.

Cum accesezi Raw Access Logs în cPanel?

Accesează:

cPanel → Metrics → Raw Access

Aici vei găsi domeniile asociate contului și logurile disponibile pentru descărcare.

cPanel oferă aceste loguri sub forma unor fișiere comprimate:

.gz

Descarcă fișierul corespunzător domeniului și dezarhivează-l pe calculator.

Fișierul rezultat poate fi deschis cu un editor de text capabil să lucreze cu fișiere de dimensiuni mai mari.

Poți arhiva automat Raw Access Logs?

În secțiunea Raw Access există și posibilitatea arhivării logurilor.

Opțiunea:

Archive log files to your home directory after the system processes statistics

permite păstrarea logurilor arhivate în:

/home/USERNAME/logs/

Poate fi configurată și perioada de retenție a logurilor, dacă această funcționalitate este permisă de configurația serverului.

Logurile pot ocupa mult spațiu pe website-uri cu trafic ridicat, motiv pentru care retenția trebuie aleasă în funcție de necesități.

Cum arată o linie dintr-un access log?

Un request poate avea o formă asemănătoare cu:

203.0.113.25 - - [23/Sep/2026:10:45:13 +0300] "GET /wp-login.php HTTP/1.1" 200 5321 "-" "Mozilla/5.0"

Putem extrage mai multe informații din această linie.

203.0.113.25

este IP-ul care a realizat request-ul.

[23/Sep/2026:10:45:13 +0300]

reprezintă data și ora.

GET

este metoda HTTP.

/wp-login.php

este URL-ul solicitat.

200

este codul HTTP returnat.

La final poate apărea și User-Agent-ul clientului care a realizat request-ul.

Ce înseamnă codurile HTTP din loguri?

Codurile HTTP sunt foarte utile atunci când analizăm logurile.

Un număr mare de 404 poate indica un crawler care încearcă URL-uri inexistente, iar numeroase răspunsuri 403 pot indica request-uri blocate de o regulă de securitate.

Dacă investighezi un 403, poți consulta și articolul nostru despre ModSecurity în cPanel și eroarea 403.

Cum identifici traficul suspect?

Nu există un singur indicator care să confirme automat că un request este malițios.

Totuși, anumite modele de trafic merită investigate:

• mii de request-uri într-un interval foarte scurt;
• același IP accesează repetitiv aceeași pagină;
• request-uri repetate către wp-login.php;
• accesări masive către xmlrpc.php;
• scanarea unui număr mare de URL-uri inexistente;
• request-uri către fișiere care nu aparțin aplicației;
• numeroase request-uri POST;
• accesări către endpoint-uri API într-un volum neobișnuit;
• un User-Agent necunoscut care generează foarte multe request-uri.

Acestea sunt doar indicii. Un import, un API, un serviciu de monitorizare sau un crawler legitim poate genera și el un volum ridicat.

Nu orice bot este malițios

Internetul este accesat permanent de boți.

Printre aceștia se află crawlere legitime ale motoarelor de căutare, servicii de monitorizare, instrumente SEO, aplicații externe și numeroase sisteme automatizate.

User-Agent-ul poate conține termeni precum:

Googlebot
bingbot
AhrefsBot
SemrushBot
crawler
spider
bot

Totuși, simpla apariție a unui nume în User-Agent nu demonstrează identitatea reală a clientului.

User-Agent-ul poate fi modificat sau falsificat, astfel încât blocarea unui IP doar pentru că acesta se identifică drept un anumit bot nu este întotdeauna o decizie corectă.

Când devine un bot o problemă?

Un crawler poate deveni problematic atunci când generează un volum foarte mare de request-uri sau accesează continuu pagini dinamice.

De exemplu:

Bot → /?s=produs1
Bot → /?s=produs2
Bot → /?s=produs3
Bot → /?s=produs4
...

Dacă fiecare request determină executarea PHP și interogarea bazei de date, consumul de resurse poate crește considerabil.

Acest lucru este diferit de accesarea repetată a unei pagini care poate fi livrată direct din cache.

LiteSpeed Cache și traficul generat de boți

Serverele shared NameBox utilizează LiteSpeed Web Server, iar website-urile compatibile pot utiliza LiteSpeed Cache.

Pentru o pagină disponibilă în cache, serverul poate evita o parte importantă din procesarea PHP și a bazei de date.

Totuși, nu toate request-urile pot fi cache-uite.

De exemplu:

• wp-login.php;
• wp-admin;
• checkout;
• API-uri;
• căutări dinamice;
• anumite filtre;
• request-uri POST.

Dacă un bot atacă astfel de endpoint-uri, faptul că website-ul utilizează cache nu elimină automat consumul generat.

Traficul suspect poate afecta resursele CloudLinux

Pe serverele shared NameBox, conturile sunt izolate prin CloudLinux și beneficiază de propriile limite de resurse.

Un volum mare de request-uri poate determina creșterea consumului pentru:

• CPU;
• RAM;
• I/O;
• Entry Processes;
• numărul proceselor simultane.

De aceea este util să corelezi informațiile din access log cu:

cPanel → Metrics → Resource Usage

Dacă observi un spike de CPU la ora 14:30 și logurile arată mii de request-uri în același interval, există un indiciu clar că cele două evenimente pot avea legătură.

Pentru mai multe informații poți consulta articolul Resurse pachet găzduire: CPU, RAM, I/O și Entry Processes.

Cum analizezi logurile direct din SSH?

Dacă administrezi un VPS sau un server cu acces root, analiza poate fi realizată direct din SSH.

Pe un server cPanel, logurile domeniilor sunt disponibile în mod uzual în:

/var/log/apache2/domlogs/

Pe serverele care utilizează LiteSpeed împreună cu cPanel, locațiile de log configurate pentru mediul Apache/cPanel sunt păstrate pentru compatibilitate.

Pentru a identifica logurile unui domeniu:

ls -lh /var/log/apache2/domlogs/exemplu.ro*

Înlocuiește:

exemplu.ro

cu domeniul pe care dorești să îl verifici.

Urmărește ultimele request-uri

Pentru ultimele 100 de linii:

tail -100 /var/log/apache2/domlogs/exemplu.ro

Pentru monitorizarea request-urilor în timp real:

tail -f /var/log/apache2/domlogs/exemplu.ro

Oprești monitorizarea cu:

CTRL + C

Pe un website cu trafic ridicat, această comandă poate genera foarte mult output.

Identifică IP-urile care generează cele mai multe request-uri

Pentru un log în formatul uzual cPanel poți utiliza:

awk '{print $1}' /var/log/apache2/domlogs/exemplu.ro | sort | uniq -c | sort -nr | head -20

Rezultatul poate avea forma:

8432 203.0.113.20
2140 198.51.100.15
981  192.0.2.44

Prima valoare reprezintă numărul de request-uri, iar a doua adresa IP.

Un IP aflat în top nu este automat un atacator. Verifică și ce URL-uri accesează.

Identifică cele mai accesate URL-uri

Poți identifica URL-urile solicitate cel mai frecvent cu:

awk '{print $7}' /var/log/apache2/domlogs/exemplu.ro | sort | uniq -c | sort -nr | head -20

De exemplu:

4200 /wp-login.php
2100 /xmlrpc.php
950  /
630  /wp-json/

Dacă observi mii de request-uri către aceeași zonă din website, aceasta trebuie investigată.

Identifică distribuția codurilor HTTP

Pentru a vedea câte răspunsuri de fiecare tip există:

awk '{print $9}' /var/log/apache2/domlogs/exemplu.ro | sort | uniq -c | sort -nr

Un rezultat poate fi:

15320 200
2310  404
760   301
420   403
25    500

Acest raport oferă o imagine rapidă asupra tipului de trafic și a erorilor generate.

Identifică request-urile care primesc 403

Pentru ultimele request-uri care au primit status 403:

awk '$9 == 403 {print}' /var/log/apache2/domlogs/exemplu.ro | tail -100

Dacă dorești să afli exact de ce o cerere a fost blocată de ModSecurity sau Imunify360, access log-ul nu este întotdeauna suficient. Trebuie verificat și evenimentul din sistemul de securitate.

Identifică erorile 404

Pentru ultimele request-uri către resurse inexistente:

awk '$9 == 404 {print}' /var/log/apache2/domlogs/exemplu.ro | tail -100

Un număr mare de erori 404 poate apărea din cauza:

• linkurilor greșite;
• resurselor șterse;
• unui website migrat;
• boților care încearcă URL-uri aleatorii;
• scanerelor automate care caută aplicații vulnerabile.

Caută request-uri către wp-login.php și xmlrpc.php

Pentru WordPress:

grep -E 'wp-login\.php|xmlrpc\.php' /var/log/apache2/domlogs/exemplu.ro | tail -100

Pentru a afla ce IP-uri accesează cel mai des aceste fișiere:

grep -E 'wp-login\.php|xmlrpc\.php' /var/log/apache2/domlogs/exemplu.ro | awk '{print $1}' | sort | uniq -c | sort -nr | head -20

Acest lucru poate ajuta la identificarea tentativelor repetitive de autentificare sau a traficului automatizat.

Caută request-urile POST

Pentru ultimele request-uri POST:

grep '"POST ' /var/log/apache2/domlogs/exemplu.ro | tail -100

Metoda POST este utilizată în mod normal pentru formulare, autentificări, checkout, API-uri și numeroase alte operațiuni legitime.

Prin urmare, un request POST nu este suspect doar pentru că folosește această metodă.

Devine relevant atunci când observi un volum neobișnuit, o anumită sursă sau un endpoint care nu ar trebui accesat repetitiv.

Caută boții după User-Agent

Pentru o verificare orientativă poți utiliza:

grep -iE 'bot|crawler|spider|slurp' /var/log/apache2/domlogs/exemplu.ro | tail -100

Această comandă găsește request-urile al căror User-Agent conține termeni utilizați frecvent de crawlere.

Rezultatul nu reprezintă însă o listă sigură de boți, deoarece User-Agent-ul poate fi falsificat.

Caută activitatea unui anumit IP

Dacă ai identificat adresa:

203.0.113.25

poți verifica ultimele request-uri cu:

grep '203.0.113.25' /var/log/apache2/domlogs/exemplu.ro | tail -100

Astfel poți vedea exact:

• ce URL-uri accesează;
• cât de des;
• ce status HTTP primește;
• ce User-Agent utilizează.

Nu analiza doar numărul total de request-uri

10.000 de request-uri către o pagină cache-uită și 10.000 de request-uri POST către o operațiune PHP complexă pot avea un impact complet diferit.

Atunci când analizezi traficul, trebuie să verifici:

• numărul request-urilor;
• URL-ul accesat;
• metoda HTTP;
• codul HTTP;
• intervalul de timp;
• dacă pagina este dinamică;
• consumul de resurse din același interval.

Traficul prin Cloudflare sau alte proxy-uri trebuie interpretat cu atenție

Dacă website-ul utilizează un CDN sau un reverse proxy, traficul ajunge mai întâi la serviciul respectiv și apoi la server.

În funcție de configurația serverului și a serviciului proxy, logurile pot afișa IP-ul real al clientului sau informații asociate infrastructurii proxy.

De aceea, înainte de blocarea unei adrese IP trebuie verificat dacă aceasta reprezintă într-adevăr utilizatorul final.

Raw Access Logs nu înlocuiesc logurile ModSecurity

Raw Access Logs cPanel arată request-ul și răspunsul oferit de server, dar nu conțin întotdeauna motivul exact pentru care un sistem de securitate a luat o anumită decizie.

De exemplu, dacă vezi:

POST /wp-admin/admin-ajax.php → 403

știi că request-ul a fost refuzat, însă pentru identificarea regulii ModSecurity trebuie verificat și logul sau evenimentul WAF corespunzător.

De aceea, access log-ul este punctul de plecare al investigației, nu întotdeauna sursa finală a diagnosticului.

Ce rol are Imunify360?

Pe infrastructura NameBox este utilizat Imunify360, care oferă mai multe niveluri de protecție pentru conturile de hosting.

Dacă un request este identificat ca malițios, acesta poate fi blocat înainte să ajungă la aplicație.

În access log poți vedea efectul request-ului, de exemplu un status 403, însă investigația completă poate necesita verificarea evenimentelor Imunify360 sau ModSecurity.

Cum corelezi logurile cu ora problemei?

Una dintre cele mai importante informații într-o investigație este ora exactă.

Să presupunem că website-ul a devenit lent la:

23.09.2026 14:35

Primul pas este să verifici Resource Usage pentru intervalul respectiv.

Apoi verifici access log-ul și cauți activitatea din aceeași perioadă.

Dacă observi:

14:34 → trafic normal
14:35 → mii de request-uri către /wp-login.php
14:36 → CPU / EP ridicat
14:40 → trafic normal

ai un indiciu mult mai util decât simpla observație că „website-ul a fost lent”.

Ce informații să trimiți echipei tehnice NameBox?

Dacă suspectezi trafic neobișnuit și ai nevoie de ajutor, transmite cât mai multe informații concrete:

• domeniul afectat;
• data problemei;
• ora aproximativă sau exactă;
• URL-ul afectat;
• mesajul de eroare, dacă există;
• adresa IP de pe care ai testat;
• operațiunea realizată înainte de apariția problemei.

Aceste date permit corelarea rapidă a evenimentului cu logurile serverului.

AWStats este util pentru imaginea generală, Raw Access pentru detalii

Cel mai simplu mod de lucru este să folosești cele două instrumente împreună.

Începe cu:

cPanel → Metrics → Awstats

pentru a observa tendințele generale ale traficului.

Dacă identifici un interval sau un comportament neobișnuit, continuă cu:

cPanel → Metrics → Raw Access

pentru a analiza request-urile individuale.

Dacă administrezi un VPS cu acces root, poți investiga direct logurile domeniului din:

/var/log/apache2/domlogs/

și poți utiliza comenzile tail, grep, awk, sort și uniq pentru a identifica rapid sursele traficului.

Analizează traficul înainte să blochezi IP-uri sau boți

Un volum mare de request-uri nu reprezintă automat un atac. Poate fi vorba despre un crawler legitim, un serviciu API, un webhook, un import sau un utilizator real care generează multe accesări.

Înainte să aplici o blocare, verifică sursa, URL-urile accesate, User-Agent-ul, metodele HTTP și impactul real asupra resurselor.

Pe infrastructura shared NameBox, LiteSpeed, CloudLinux, Imunify360 și ModSecurity lucrează la niveluri diferite pentru performanța, izolarea și securitatea conturilor. Logurile completează aceste sisteme oferind informațiile necesare pentru investigarea concretă a unei probleme.

Dacă observi trafic neobișnuit pe un website găzduit la NameBox și nu poți identifica sursa, poți transmite echipei tehnice domeniul și ora exactă a problemei pentru verificarea logurilor serverului.

The post Trafic website în cPanel: AWStats și Logs appeared first on NAMEBOX.

DNSSEC adaugă un nivel suplimentar de securitate sistemului DNS și permite verificarea autenticității răspunsurilor primite atunci când un utilizator încearcă să acceseze un domeniu.

Fără DNSSEC, un resolver DNS primește informații precum adresa IP asociată unui domeniu, însă protocolul DNS clasic nu a fost proiectat inițial cu un mecanism criptografic prin care să demonstreze că răspunsul primit este exact cel publicat de administratorul domeniului.

Prin utilizarea DNSSEC, informațiile din zona DNS sunt semnate digital, iar resolverele care fac validare pot verifica dacă răspunsul este autentic și dacă nu a fost modificat pe parcurs.

În acest articol explicăm ce este DNSSEC, cum funcționează DNSKEY și DS Record, ce înseamnă lanțul de încredere și de ce o configurație DNSSEC greșită poate face un domeniu inaccesibil.

Ce este DNSSEC?

DNSSEC vine de la:

Domain Name System Security Extensions

Este o extensie a sistemului DNS care utilizează semnături digitale și criptografie cu cheie publică pentru verificarea autenticității datelor DNS.

DNSSEC nu înlocuiește DNS-ul și nu modifică rolul înregistrărilor obișnuite precum:

• A;
• AAAA;
• CNAME;
• MX;
• TXT;
• CAA.

În schimb, adaugă informații suplimentare prin care un resolver poate verifica dacă răspunsurile DNS sunt legitime.

Dacă dorești să înțelegi mai întâi modul în care funcționează sistemul DNS, poți consulta ghidul nostru Ce este DNS și cum funcționează?.

De ce a fost creat DNSSEC?

DNS-ul tradițional a fost proiectat într-o perioadă în care securitatea internetului nu avea cerințele actuale.

În mod normal, atunci când introduci în browser:

www.exemplu.ro

resolverul DNS caută adresa IP asociată domeniului și poate primi, de exemplu:

www.exemplu.ro → 192.0.2.10

Problema este că DNS-ul tradițional nu oferă singur o dovadă criptografică prin care resolverul să poată confirma că răspunsul respectiv este autentic.

Un atacator care reușește să falsifice un răspuns DNS ar putea încerca să returneze:

www.exemplu.ro → 198.51.100.55

și astfel să direcționeze utilizatorul către un alt server.

DNSSEC a fost creat tocmai pentru a permite detectarea unor astfel de modificări.

Ce este DNS spoofing?

DNS spoofing reprezintă falsificarea informațiilor DNS astfel încât un utilizator să primească un răspuns diferit de cel publicat în zona DNS legitimă.

Un scenariu simplificat ar putea fi:

Utilizator
    ↓
Cere IP-ul pentru exemplu.ro
    ↓
Primește un răspuns DNS falsificat
    ↓
Este trimis către un server controlat de atacator

Un astfel de atac poate fi utilizat pentru:

• redirecționarea traficului;
• imitarea unui website legitim;
• furtul datelor introduse de utilizatori;
• interceptarea anumitor comunicații;
• alte forme de atac de tip man-in-the-middle.

DNSSEC ajută resolverul să detecteze dacă informațiile DNS au fost modificate sau nu pot fi validate criptografic.

Cum funcționează DNSSEC?

DNSSEC utilizează criptografie asimetrică.

Într-un sistem de criptografie cu cheie publică există două componente importante:

• o cheie privată;
• o cheie publică.

Cheia privată este utilizată pentru generarea semnăturilor digitale, iar cheia publică este publicată în DNS și poate fi utilizată de resolvere pentru verificarea acestor semnături.

Procesul poate fi reprezentat simplificat astfel:

Zona DNS
   ↓
Înregistrările sunt grupate în RRsets
   ↓
RRsets sunt semnate digital
   ↓
Semnăturile sunt publicate în DNS
   ↓
Resolverul primește datele + semnătura
   ↓
Verifică semnătura folosind cheia publică
   ↓
Răspuns valid sau invalid

DNSSEC criptează DNS-ul?

Nu.

Este o diferență foarte importantă.

DNSSEC nu criptează cererile și răspunsurile DNS.

Rolul său este verificarea:

• autenticității datelor;
• integrității răspunsului;
• lanțului de încredere dintre domeniu și zona DNS părinte.

Un observator al traficului poate vedea în continuare ce domeniu este solicitat atunci când este utilizat DNS tradițional.

Pentru criptarea comunicației dintre client și resolver există tehnologii separate precum:

• DNS over HTTPS – DoH;
• DNS over TLS – DoT.

DNSSEC și DoH/DoT rezolvă probleme diferite și pot fi utilizate împreună.

Ce este DNSKEY?

DNSSEC introduce mai multe tipuri de înregistrări DNS suplimentare.

Una dintre cele mai importante este:

DNSKEY

Înregistrarea DNSKEY publică cheia necesară pentru validarea semnăturilor DNSSEC ale zonei.

Resolverul utilizează această cheie pentru a verifica dacă informațiile primite sunt semnate corespunzător.

Ce este RRSIG?

Înregistrarea:

RRSIG

conține semnătura digitală asociată unui set de înregistrări DNS.

De exemplu, dacă domeniul are:

exemplu.ro. A 192.0.2.10

DNSSEC poate publica alături de setul respectiv o semnătură RRSIG.

Resolverul validează semnătura utilizând DNSKEY.

Ce este DS Record?

DS – Delegation Signer este una dintre cele mai importante componente ale DNSSEC.

Înregistrarea DS este publicată în zona DNS părinte și creează legătura dintre zona părinte și cheia DNSSEC a domeniului.

Pentru un domeniu:

exemplu.ro

înregistrarea DS trebuie publicată în zona părinte:

.ro

Înregistrarea DS conține informații care permit resolverului să verifice cheia DNSKEY utilizată de domeniu.

Un DS Record conține informații precum:

• Key Tag;
• Algorithm;
• Digest Type;
• Digest.

Aceste valori trebuie să corespundă cheii DNSSEC active în zona domeniului.

De ce este necesar DS Record?

Doar semnarea zonei DNS nu este suficientă pentru a obține un lanț complet de încredere.

Resolverul trebuie să poată verifica faptul că cheia publicată de domeniu este într-adevăr cheia legitimă.

Aici intervine înregistrarea DS de la nivelul registrarului sau al zonei părinte.

Procesul poate fi privit astfel:

ROOT
  ↓
.ro
  ↓
DS pentru exemplu.ro
  ↓
DNSKEY exemplu.ro
  ↓
RRSIG
  ↓
A / MX / TXT / alte înregistrări

Dacă fiecare element al lanțului poate fi validat, resolverul poate avea încredere în răspunsul DNS primit.

Ce este lanțul de încredere DNSSEC?

DNSSEC utilizează un mecanism cunoscut sub numele de:

Chain of Trust – lanț de încredere.

Validarea începe de la zona DNS root:

.

Resolverele DNSSEC au configurată o cheie root considerată de încredere.

De aici, resolverul poate verifica treptat fiecare nivel DNS.

Pentru un domeniu precum:

www.exemplu.ro

procesul simplificat este:

Root (.)
   ↓
.ro
   ↓
exemplu.ro
   ↓
www.exemplu.ro

Zona root validează delegarea către TLD, zona TLD validează delegarea către domeniu prin DS, iar domeniul utilizează DNSKEY și semnăturile sale pentru validarea înregistrărilor DNS.

Ce se întâmplă când resolverul verifică DNSSEC?

Să presupunem că un utilizator accesează:

https://exemplu.ro

Resolverul care suportă validare DNSSEC poate realiza următorii pași:

1. solicită informațiile DNS pentru domeniu;
2. primește înregistrarea și semnătura asociată;
3. verifică DNSKEY;
4. verifică DS-ul publicat în zona părinte;
5. continuă validarea până la root;
6. confirmă că răspunsul este autentic.

Dacă semnăturile și lanțul sunt valide, răspunsul este acceptat.

Dacă validarea eșuează, resolverul poate refuza să returneze răspunsul utilizatorului.

Ce se întâmplă dacă cineva modifică răspunsul DNS?

Dacă un atacator modifică:

192.0.2.10

în:

198.51.100.55

semnătura digitală nu va mai corespunde datelor.

Un resolver care validează DNSSEC va putea identifica faptul că informația nu este autentică și poate refuza răspunsul.

Acesta este principalul avantaj al DNSSEC.

DNSSEC protejează toate înregistrările DNS?

DNSSEC poate proteja autenticitatea datelor publicate în zona semnată, inclusiv seturi de înregistrări precum:

• A;
• AAAA;
• MX;
• TXT;
• CNAME;
• NS;
• CAA.

DNSSEC nu schimbă însă valoarea acestor înregistrări și nu împiedică administratorul să configureze greșit zona DNS.

Dacă administratorul publică intenționat sau accidental un IP greșit, DNSSEC poate confirma că acel răspuns este autentic, dar nu poate determina dacă configurația este corectă din punct de vedere operațional.

DNSSEC și cPanel

În cPanel, administrarea DNSSEC poate fi disponibilă din:

cPanel → Domains → Zone Editor

În dreptul domeniului poate exista opțiunea:

DNSSEC

cPanel permite crearea și administrarea cheilor DNSSEC atunci când infrastructura serverului este configurată corespunzător.

Este important de reținut că disponibilitatea funcției depinde de configurația furnizorului de hosting.

cPanel suportă DNSSEC pentru serverele DNS care utilizează PowerDNS.

Cum activezi DNSSEC în cPanel?

Dacă opțiunea DNSSEC este disponibilă, accesează:

cPanel → Domains → Zone Editor → DNSSEC

Pentru domeniul dorit poți selecta:

Create Key

cPanel va genera cheia DNSSEC și va afișa informațiile necesare pentru DS Record.

Printre acestea se pot afla:

Key Tag
Algorithm
Digest Type
Digest

Aceste informații trebuie ulterior configurate la registrarul domeniului.

Generarea cheii în cPanel nu este suficientă

Aceasta este una dintre cele mai importante reguli DNSSEC.

Dacă generezi cheia DNSSEC în cPanel, trebuie configurat și DS Record la registrarul domeniului.

Fără DS, zona poate fi semnată, însă nu există un lanț complet de încredere de la zona părinte către domeniu.

Fluxul corect este:

1. Generezi cheia DNSSEC
        ↓
2. Obții datele DS
        ↓
3. Configurezi DS la registrar
        ↓
4. Aștepți propagarea
        ↓
5. Verifici DNSSEC

Unde se configurează DS Record?

Înregistrarea DS nu se adaugă, în mod normal, ca un record obișnuit A sau TXT în aceeași zonă DNS a domeniului.

DS trebuie publicat în zona părinte, prin registrarul domeniului.

De exemplu:

Domeniu: exemplu.ro
Zona DNS: serverul DNS autoritativ
DS: registrar / zona .ro

Procedura exactă depinde de extensia domeniului și de registrarul utilizat.

NameBox este registrar acreditat ROTLD pentru domeniile .RO și oferă servicii de administrare a domeniilor și a zonelor DNS. Pentru o configurație DNSSEC, trebuie verificată disponibilitatea și procedura aplicabilă domeniului respectiv.

Ce se întâmplă dacă DS Record este greșit?

Aici trebuie acordată foarte multă atenție.

Dacă zona DNS utilizează o cheie, dar la registrar există un DS asociat unei alte chei, lanțul DNSSEC devine invalid.

Resolverele care validează DNSSEC pot considera răspunsurile:

BOGUS

și pot refuza rezolvarea domeniului.

Rezultatul poate fi că website-ul și serviciile asociate domeniului nu mai sunt accesibile pentru utilizatorii care folosesc resolvere cu validare DNSSEC.

Un DNSSEC configurat greșit poate face site-ul inaccesibil?

Da.

O configurație DNSSEC incorectă este diferită de situația în care DNSSEC nu este activ deloc.

Fără DNSSEC:

DNS funcționează fără validare criptografică

Cu DNSSEC configurat corect:

DNS funcționează + răspunsurile pot fi validate

Cu DNSSEC configurat greșit:

Validarea eșuează → domeniul poate deveni inaccesibil

Din acest motiv, DS Record și cheile DNSSEC trebuie gestionate cu atenție.

DNSSEC și migrarea unui website pe alt server

DNSSEC trebuie verificat în mod special înainte de migrarea zonei DNS către alt server.

Dacă vechiul server utilizează o anumită cheie DNSSEC și noul server generează o altă cheie, DS-ul existent la registrar nu va mai corespunde.

cPanel recomandă ca, înainte de transferul unui domeniu cu DNSSEC activ către alt server, DS-ul vechi să fie eliminat sau gestionat corespunzător, iar după migrare să fie publicat noul DS.

Un scenariu greșit ar fi:

Server vechi → DNSKEY A
Registrar     → DS pentru cheia A

Migrare

Server nou   → DNSKEY B
Registrar     → încă DS pentru cheia A

În această situație validarea DNSSEC poate eșua.

Nu șterge cheia DNSSEC înainte de DS Record

Dacă dorești dezactivarea DNSSEC, ordinea operațiunilor este importantă.

Nu este recomandat să ștergi mai întâi cheia de pe server și să lași DS-ul activ la registrar.

În această situație zona părinte spune resolverului că domeniul trebuie validat prin DNSSEC, dar zona nu mai poate furniza cheia corespunzătoare.

Ordinea corectă este, în general:

1. Elimină DS Record de la registrar
        ↓
2. Așteaptă propagarea modificării
        ↓
3. Dezactivează / elimină cheia DNSSEC din zona DNS

cPanel recomandă explicit eliminarea DS-ului de la registrar înainte de ștergerea cheii DNSSEC.

Cum verifici dacă un domeniu are DNSSEC activ?

Dacă ai acces la un sistem Linux sau macOS poți utiliza comanda:

dig DS exemplu.ro

Dacă domeniul are un DS publicat în zona părinte, rezultatul poate conține informațiile Delegation Signer.

Pentru DNSKEY:

dig DNSKEY exemplu.ro

Pentru a solicita informații DNSSEC:

dig +dnssec exemplu.ro

Înlocuiește:

exemplu.ro

cu domeniul pe care dorești să îl verifici.

Exemplu de răspuns DS

Un rezultat poate avea forma:

exemplu.ro. 3600 IN DS 12345 13 2 ABCDEF...

Valorile reprezintă, în ordine:

12345 → Key Tag
13    → Algorithm
2     → Digest Type
ABC... → Digest

Valorile sunt doar un exemplu și nu trebuie copiate pentru un domeniu real.

Ce înseamnă DNSSEC Secure, Insecure și Bogus?

În timpul validării poți întâlni mai multe stări.

Secure

Lanțul DNSSEC a fost validat corect.

Secure → semnăturile sunt valide

Insecure

Domeniul nu utilizează DNSSEC sau nu există un lanț DNSSEC către acesta.

Insecure → DNSSEC nu este activ pentru domeniu

Aceasta nu înseamnă automat că domeniul este compromis.

Bogus

Resolverul se aștepta la un răspuns DNSSEC valid, dar verificarea criptografică a eșuat.

Bogus → configurație DNSSEC invalidă sau răspuns nevalid

Aceasta este starea problematică și poate determina resolverul să refuze răspunsul DNS.

DNSSEC protejează împotriva phishing-ului?

Nu în mod direct.

DNSSEC poate ajuta la prevenirea redirecționării unui domeniu legitim prin falsificarea răspunsurilor DNS, dar nu poate împiedica un atacator să înregistreze un domeniu asemănător.

De exemplu, DNSSEC nu poate împiedica apariția unui domeniu precum:

nume-companie-secure.example

utilizat pentru phishing.

DNSSEC autentifică răspunsurile DNS ale domeniului protejat, nu verifică dacă website-ul este legitim sau dacă un alt domeniu este malițios.

DNSSEC protejează împotriva atacurilor DDoS?

Nu.

DNSSEC nu este o soluție de protecție DDoS.

Rolul său principal este verificarea autenticității și integrității datelor DNS.

Protecția DDoS necesită mecanisme separate la nivelul rețelei și infrastructurii.

DNSSEC înlocuiește certificatul SSL?

Nu.

DNSSEC și SSL/TLS protejează componente diferite.

Pentru o protecție cât mai bună, aceste tehnologii pot fi utilizate împreună.

DNSSEC afectează viteza website-ului?

DNSSEC adaugă informații suplimentare procesului de rezoluție DNS și necesită validarea semnăturilor criptografice.

În practică, impactul asupra experienței utilizatorului este de regulă redus, iar resolverele moderne sunt optimizate pentru astfel de verificări.

DNSSEC nu influențează timpul necesar PHP pentru generarea paginii, performanța bazei de date sau viteza serverului web.

DNSSEC modifică A, MX sau SPF?

Nu.

Activarea DNSSEC nu schimbă destinația website-ului sau serverul de email.

Înregistrări precum:

A
AAAA
MX
CNAME
TXT
SPF
DKIM
DMARC

continuă să funcționeze normal.

DNSSEC adaugă mecanismul necesar pentru validarea autenticității datelor DNS.

DNSSEC și administrarea zonei DNS

DNSSEC trebuie analizat împreună cu locul în care este administrată zona DNS.

Dacă domeniul utilizează nameserverele unui provider, cheile DNSSEC trebuie generate și administrate în infrastructura DNS autoritativă respectivă.

DS Record trebuie apoi configurat prin registrarul domeniului.

Dacă dorești să înțelegi cum funcționează administrarea înregistrărilor A, CNAME, MX sau TXT, poți consulta tutorialul nostru despre administrarea zonei DNS.

Ce trebuie verificat înainte de activarea DNSSEC?

Înainte de activare este recomandat să verifici:

• unde este administrată zona DNS;
• dacă serverele DNS suportă DNSSEC;
• dacă registrarul permite configurarea DS Record;
• dacă nameserverele domeniului sunt corecte;
• dacă domeniul urmează să fie migrat în perioada imediat următoare;
• cine va administra rotația și modificarea cheilor.

DNSSEC trebuie activat numai atunci când poți administra atât partea de zonă DNS, cât și DS-ul de la registrar.

Checklist pentru activarea DNSSEC

Procesul poate fi rezumat astfel:

1. verifică dacă serverele DNS suportă DNSSEC;
2. generează cheia DNSSEC;
3. obține valorile pentru DS Record;
4. configurează DS la registrar;
5. așteaptă propagarea;
6. verifică DNSKEY și DS;
7. testează lanțul de încredere;
8. monitorizează domeniul după activare.

DNSSEC adaugă un nivel suplimentar de securitate domeniului

DNSSEC nu schimbă modul în care un website este găzduit, nu criptează traficul DNS și nu înlocuiește SSL-ul, firewall-ul sau alte soluții de securitate.

Rolul său este foarte specific: să permită unui resolver să verifice criptografic dacă informațiile DNS primite sunt autentice și nu au fost modificate.

Acest lucru este realizat prin semnături digitale, DNSKEY și prin DS Record, care leagă domeniul de zona sa părinte și construiește lanțul de încredere până la root.

Configurarea trebuie însă făcută cu atenție. Un DS Record care nu mai corespunde cheii DNSSEC poate determina resolverele care validează DNSSEC să refuze răspunsurile și poate face domeniul inaccesibil.

Dacă domeniul și serviciile DNS sunt administrate prin NameBox și dorești să utilizezi DNSSEC, poți contacta echipa tehnică pentru verificarea configurației și a opțiunilor disponibile pentru domeniul respectiv.

Pentru administrarea domeniilor .RO, .COM, .EU și a altor extensii poți consulta și pagina de înregistrare și administrare domenii NameBox.

The post DNSSEC: Protecție pentru domeniul tău appeared first on NAMEBOX.

ModSecurity în cPanel reprezintă unul dintre nivelurile de protecție utilizate pentru filtrarea cererilor HTTP suspecte înainte ca acestea să ajungă la aplicația website-ului.

Pe infrastructura NameBox, această protecție lucrează împreună cu tehnologii precum LiteSpeed Web Server, Imunify360, CloudLinux și cPanel pentru a reduce riscul exploatării vulnerabilităților și al accesului neautorizat.

În anumite situații, însă, o cerere legitimă poate semăna cu un atac și poate fi blocată. Unul dintre simptomele întâlnite este eroarea 403 Forbidden.

În acest articol explicăm ce este ModSecurity, cum funcționează într-un server cPanel cu LiteSpeed și Imunify360, cum identifici un posibil false positive și de ce nu este recomandată dezactivarea permanentă a protecției.

Ce este ModSecurity?

ModSecurity este o tehnologie de tip Web Application Firewall – WAF utilizată pentru analizarea traficului HTTP și HTTPS care ajunge la website.

În loc să permită automat fiecare request, sistemul îl poate compara cu un set de reguli de securitate.

Procesul poate fi reprezentat simplificat astfel:

Vizitator
   ↓
Request HTTP / HTTPS
   ↓
LiteSpeed + ModSecurity / WAF
   ↓
Reguli de securitate
   ↓
Request permis sau blocat
   ↓
Website / WordPress / magazin online

Dacă o cerere corespunde unei reguli considerate periculoase, aceasta poate fi blocată înainte ca aplicația să o proceseze.

Ce tipuri de atacuri poate identifica ModSecurity?

Capacitatea exactă depinde de regulile instalate pe server, însă un WAF bazat pe ModSecurity poate analiza cereri asociate unor atacuri precum:

• SQL Injection;
• Cross-Site Scripting – XSS;
• Command Injection;
• Local File Inclusion;
• Remote File Inclusion;
• request-uri HTTP construite anormal;
• anumite încercări de exploatare a aplicațiilor web;
• upload-uri sau payload-uri suspecte.

ModSecurity nu „știe” automat dacă un utilizator este atacator. Acesta analizează request-ul pe baza regulilor de securitate existente.

Ce este un WAF?

WAF – Web Application Firewall este un sistem de protecție poziționat între utilizator și aplicația web.

Un firewall de rețea și un WAF nu sunt același lucru.

Un firewall clasic poate controla conexiuni și porturi precum:

22   → SSH
25   → SMTP
80   → HTTP
443  → HTTPS

Un WAF analizează ceea ce se transmite efectiv prin HTTP sau HTTPS.

De exemplu, două request-uri pot ajunge ambele pe portul 443, însă unul poate fi o accesare normală a unei pagini, iar celălalt poate conține un payload specific unui SQL Injection.

Cum funcționează ModSecurity împreună cu LiteSpeed?

Serverele shared NameBox utilizează LiteSpeed Web Server.

LiteSpeed include propriul motor de procesare compatibil cu regulile ModSecurity, astfel încât protecția WAF poate funcționa și într-un mediu LiteSpeed.

LiteSpeed este compatibil cu seturi de reguli precum:

• OWASP;
• Imunify360;
• Comodo;
• Atomicorp;
• reguli personalizate.

Într-un server cPanel, regulile ModSecurity sunt administrate în mod normal prin integrarea disponibilă în WHM, fără să fie necesară configurarea lor separat în interfața LiteSpeed.

Unde intervine Imunify360?

Imunify360 este o platformă de securitate pentru serverele de hosting și oferă mai multe componente de protecție.

Printre acestea se numără:

• Web Application Firewall;
• reguli de protecție pentru aplicațiile web;
• scanare malware;
• protecție împotriva anumitor atacuri automate;
• monitorizarea evenimentelor de securitate;
• protecție la nivelul fișierelor;
• mecanisme de reputație și filtrare.

Imunify360 poate utiliza un ruleset compatibil ModSecurity pentru identificarea request-urilor periculoase.

Astfel, într-o configurație cu LiteSpeed, fluxul poate fi simplificat astfel:

Internet
   ↓
LiteSpeed
   ↓
WAF / ModSecurity
   ↓
Reguli Imunify360
   ↓
Aplicația website-ului

LiteSpeed procesează request-ul, iar regulile de securitate pot decide dacă acesta trebuie permis sau blocat.

ModSecurity și Imunify360 sunt același lucru?

Nu.

ModSecurity reprezintă motorul sau mecanismul prin care pot fi evaluate regulile WAF.

Imunify360 este o platformă mai complexă de securitate care poate furniza și utiliza reguli WAF, dar include și alte componente precum scanarea malware.

O comparație simplificată ar fi:

ModSecurity = motor de analiză WAF

Imunify360 = platformă de securitate + reguli WAF + malware scanner + alte mecanisme

În infrastructurile moderne, motorul exact care execută regulile poate varia. Important pentru utilizator este că request-urile sunt analizate înainte de a ajunge la aplicație.

Ce rol are CloudLinux?

CloudLinux are un rol diferit față de ModSecurity și Imunify360.

Pe serverele shared NameBox, CloudLinux ajută la izolarea conturilor de găzduire și la controlul resurselor utilizate de fiecare cont.

De exemplu, poate controla sau monitoriza resurse precum:

• CPU;
• memorie RAM;
• I/O;
• IOPS;
• Entry Processes;
• numărul de procese.

CloudLinux nu înlocuiește ModSecurity.

Cele două tehnologii rezolvă probleme diferite:

LiteSpeed   → server web și performanță
ModSecurity → filtrarea request-urilor web
Imunify360  → securitate WAF + anti-malware
CloudLinux  → izolare conturi și control resurse
cPanel      → administrarea serviciilor

Cum poate ModSecurity genera eroarea 403?

Atunci când o regulă consideră că request-ul reprezintă un risc, serverul poate răspunde cu:

403 Forbidden

Acest lucru înseamnă că serverul a înțeles cererea, dar accesul a fost refuzat.

De exemplu, o cerere de tip POST poate conține un text asemănător cu o comandă SQL:

SELECT * FROM users

Într-un formular destinat programatorilor sau într-un articol tehnic, acest text poate fi perfect legitim.

Totuși, într-un alt context poate semăna cu o tentativă SQL Injection.

Dacă o regulă este foarte strictă, request-ul legitim poate fi blocat. Această situație este cunoscută sub numele de:

false positive.

Ce este un false positive?

Un false positive apare atunci când sistemul de securitate identifică o activitate legitimă drept potențial atac.

De exemplu, problema poate apărea atunci când:

• salvezi un articol cu fragmente de cod;
• trimiți un formular care conține anumite caractere speciale;
• un plugin trimite un request POST complex;
• un page builder salvează cantități mari de HTML sau JavaScript;
• un API transmite JSON cu anumite expresii;
• un import trimite date care coincid cu o regulă de securitate.

Acest lucru nu înseamnă că ModSecurity trebuie dezactivat complet.

Trebuie identificată regula care a blocat request-ul și analizat dacă este într-adevăr un false positive.

Nu orice eroare 403 este cauzată de ModSecurity

Este foarte important să nu presupunem automat că fiecare eroare 403 este provocată de ModSecurity.

Un 403 Forbidden poate apărea și din alte motive.

Printre acestea se numără:

• permisiuni incorecte ale fișierelor;
• reguli .htaccess;
• restricții configurate în aplicație;
• blocarea adresei IP;
• protecții Imunify360;
• firewall;
• reguli personalizate de securitate;
• accesarea unui director protejat;
• pluginuri WordPress de securitate.

Din acest motiv trebuie analizată cauza înainte de modificarea configurației.

Cum îți dai seama dacă ModSecurity blochează request-ul?

Un indiciu important este modul în care apare problema.

De exemplu:

• website-ul funcționează normal;
• wp-admin funcționează;
• poți naviga între pagini;
• dar o anumită operațiune produce 403.

Exemplu:

Accesezi wp-admin           → funcționează
Editezi articolul           → funcționează
Apeși Update                → 403 Forbidden

Într-o asemenea situație este posibil ca request-ul POST utilizat la salvare să fi fost blocat de o regulă WAF.

Totuși, confirmarea trebuie realizată în logurile serverului.

ModSecurity în cPanel

Dacă furnizorul permite această funcție, utilizatorul poate găsi ModSecurity în:

cPanel → Security → ModSecurity

Interfața permite activarea sau dezactivarea protecției pentru domeniile asociate contului.

cPanel recomandă explicit menținerea ModSecurity activ pentru toate domeniile și dezactivarea acestuia doar temporar atunci când este necesară depanarea unei probleme.

Este recomandat să dezactivezi ModSecurity?

Nu permanent.

Dezactivarea ModSecurity elimină regulile WAF aplicate domeniului și reduce nivelul de protecție al website-ului.

Dacă suspectezi un false positive, dezactivarea poate fi utilizată temporar ca test.

Un scenariu de diagnostic poate fi:

Operațiunea produce 403
        ↓
ModSecurity este dezactivat temporar
        ↓
Operațiunea este repetată
        ↓
Funcționează
        ↓
ModSecurity este reactivat
        ↓
Se verifică regula care a produs blocarea

Dacă problema dispare doar atunci când ModSecurity este dezactivat, avem un indiciu puternic că o regulă WAF trebuie investigată.

După test, protecția trebuie reactivată.

De ce nu trebuie lăsat ModSecurity dezactivat?

Un website poate conține vulnerabilități despre care administratorul nu știe încă.

De exemplu, un plugin WordPress poate avea o vulnerabilitate care permite trimiterea unui request malițios.

Un WAF poate bloca anumite tentative înainte ca acestea să ajungă la plugin.

Dacă ModSecurity este dezactivat permanent, acest nivel suplimentar de protecție nu mai există.

Din acest motiv, soluția corectă pentru un false positive este identificarea regulii și aplicarea unei excepții cât mai precise, nu dezactivarea întregului sistem de securitate.

Cum este identificată regula care a blocat request-ul?

La nivel de server, evenimentele ModSecurity pot fi analizate din WHM.

Administratorul serverului poate utiliza:

WHM → Security Center → ModSecurity Tools

Interfața permite verificarea evenimentelor generate de reguli.

Într-un astfel de eveniment pot exista informații precum:

• Rule ID;
• domeniul;
• URL-ul solicitat;
• IP-ul clientului;
• data și ora;
• motivul blocării;
• regula care a fost declanșată.

Aceste informații sunt mult mai utile decât dezactivarea aleatorie a protecțiilor.

Ce este Rule ID?

Fiecare regulă ModSecurity poate avea un identificator.

De exemplu:

Rule ID: 123456

Dacă o anumită regulă produce un false positive, administratorul poate analiza exact regula respectivă.

În funcție de situație, se poate decide:

• că request-ul este într-adevăr malițios;
• că aplicația trebuie modificată;
• că regula trebuie ajustată;
• că este necesară o excepție specifică.

Nu este recomandat să dezactivezi reguli fără să înțelegi ce protecție oferă.

Ce informații sunt utile când raportezi o eroare 403?

Dacă un request este blocat pe un serviciu NameBox, pentru identificarea rapidă a cauzei sunt utile următoarele informații:

• domeniul afectat;
• URL-ul exact unde apare problema;
• data și ora aproximativă;
• adresa IP de la care ai realizat operațiunea;
• operațiunea realizată înainte de apariția erorii;
• mesajul complet de eroare sau o captură de ecran.

Adresa IP poate fi verificată accesând:

https://ip.namebox.ro/

Ora exactă este foarte importantă deoarece permite corelarea request-ului cu evenimentul din logurile serverului.

Exemplu: WordPress afișează 403 când salvezi o pagină

Să presupunem că utilizezi WordPress și Elementor.

Poți:

• intra în wp-admin;
• deschide pagina;
• edita conținutul;

dar în momentul în care apeși:

Update

primești:

403 Forbidden

Nu trebuie să concluzionezi imediat că Elementor este defect.

Request-ul transmis de editor poate conține:

• HTML;
• CSS;
• JavaScript;
• JSON;
• URL-uri;
• fragmente de cod.

Una dintre aceste valori poate coincide cu o regulă de securitate.

Administratorul poate verifica Rule ID-ul asociat request-ului și poate stabili dacă avem un false positive.

Exemplu: formularul de contact returnează 403

Un alt scenariu poate apărea atunci când un utilizator introduce într-un formular un text care conține anumite expresii tehnice.

De exemplu:

Avem problema cu SELECT * FROM users

Pentru utilizator este doar text.

Pentru o regulă WAF poate semăna cu un fragment SQL.

Dacă regula consideră request-ul periculos, formularul poate fi blocat.

Acesta este motivul pentru care regulile trebuie analizate în context, nu eliminate fără verificare.

Imunify360 poate bloca și alte tipuri de activitate

Este important să nu asociem toate blocările cu ModSecurity.

Imunify360 include mai multe componente de securitate, iar o adresă IP sau un request poate fi afectat și de alte mecanisme.

Din acest motiv, atunci când investigăm un incident trebuie să diferențiem:

Request blocat de WAF
IP blocat
Fișier identificat ca malware
Login brute force
Regulă aplicație
Firewall

Fiecare situație necesită o verificare diferită.

Ce legătură are Imunify360 cu fișierele infectate?

ModSecurity analizează în principal request-urile web.

Imunify360 include și un malware scanner care poate verifica fișierele din conturile de găzduire.

Astfel, cele două componente oferă protecție în puncte diferite:

Request malițios
      ↓
WAF / ModSecurity
      ↓
Website

Fișier malițios existent în cont
      ↓
Imunify360 Malware Scanner

Un website poate avea ModSecurity activ și totuși să fie compromis printr-o vulnerabilitate necunoscută, o parolă furată sau un plugin vulnerabil.

De aceea securitatea trebuie realizată pe mai multe niveluri.

LiteSpeed Cache nu este o funcție de securitate

LiteSpeed și LiteSpeed Cache sunt asociate frecvent cu website-urile WordPress, însă trebuie făcută o diferență importantă.

LiteSpeed Web Server este serverul web care poate procesa inclusiv regulile WAF.

LiteSpeed Cache este o soluție de cache și optimizare a performanței.

LSCache nu înlocuiește ModSecurity sau Imunify360.

Rolurile sunt diferite:

LiteSpeed Web Server → server web
LSCache              → cache și performanță
ModSecurity / WAF    → filtrare request-uri
Imunify360           → protecție și malware
CloudLinux           → izolare și resurse

CloudLinux poate provoca eroare 403?

În mod obișnuit, atingerea limitelor CloudLinux nu generează un 403 ModSecurity.

Limitările de CPU, memorie, I/O sau Entry Processes pot duce mai degrabă la încetinirea website-ului, întreruperi temporare sau alte erori asociate resurselor.

Dacă primești 403, trebuie verificată separat cauza și nu trebuie presupus automat că limita de CPU sau RAM este responsabilă.

Cum verifici dacă problema este de la permisiuni?

O eroare 403 poate apărea și atunci când permisiunile fișierelor sau directoarelor sunt incorecte.

Pentru configurațiile obișnuite cPanel sunt utilizate frecvent:

Fișiere   → 0644
Directoare → 0755

Dacă ai acces SSH, poți verifica un fișier cu:

ls -l fisier.php

sau un director cu:

ls -ld public_html

Permisiunile trebuie verificate înainte de a modifica ModSecurity.

Verifică și fișierul .htaccess

Regulile din:

.htaccess

pot limita accesul anumitor IP-uri, directoare sau URL-uri.

De exemplu, pot exista reguli precum:

Require all denied

sau alte condiții care generează un răspuns 403.

Din acest motiv, atunci când ModSecurity nu apare în loguri trebuie verificată și configurația aplicației.

Protecția pe mai multe niveluri în infrastructura NameBox

Pe infrastructura de găzduire NameBox sunt utilizate mai multe tehnologii care au roluri complementare.

Aceste tehnologii nu se înlocuiesc între ele. Fiecare protejează o componentă diferită a serviciului.

De ce este important backup-ul dacă avem Imunify360?

Nicio soluție de securitate nu poate garanta blocarea tuturor incidentelor.

Un website poate fi compromis din cauze precum:

• plugin vulnerabil;
• parolă compromisă;
• cont WordPress compromis;
• cod custom vulnerabil;
• acces FTP sau SSH compromis;
• vulnerabilitate nouă pentru care nu există încă o regulă.

Din acest motiv, backup-ul reprezintă un nivel separat de protecție.

Infrastructura NameBox utilizează soluții de backup precum JetBackup și Synconix, care permit restaurarea datelor atunci când există un punct de backup disponibil.

Ce să faci dacă ModSecurity blochează o operațiune legitimă?

Dacă suspectezi un false positive, nu dezactiva permanent protecția.

Urmează această ordine:

1. notează URL-ul unde apare eroarea;
2. notează ora exactă;
3. verifică adresa IP de pe care ai realizat operațiunea;
4. repetă operațiunea o singură dată pentru a reproduce problema;
5. verifică dacă eroarea este 403;
6. transmite informațiile echipei tehnice;
7. administratorul verifică evenimentul și Rule ID-ul;
8. dacă este false positive, se analizează o excepție specifică.

Este preferabilă eliminarea unei singure reguli pentru situația justificată sau configurarea unei excepții precise decât dezactivarea întregului WAF.

Ce să NU faci când apare un 403?

Nu recomandăm să:

• dezactivezi permanent ModSecurity;
• setezi permisiuni 777;
• ștergi reguli .htaccess fără să știi ce fac;
• dezactivezi Imunify360;
• adaugi IP-uri în whitelist fără să verifici motivul blocării;
• dezactivezi toate pluginurile de securitate fără diagnostic;
• modifici simultan mai multe sisteme de protecție.

Dacă modifici cinci componente simultan și problema dispare, nu vei mai ști care dintre acestea era cauza.

ModSecurity protejează și WordPress?

Da. ModSecurity funcționează la nivelul serverului web și poate analiza request-urile înainte ca acestea să ajungă la WordPress.

Prin urmare, protecția nu depinde de instalarea unui plugin WordPress.

Acest lucru este util deoarece un request malițios poate fi blocat înainte ca WordPress sau pluginul vulnerabil să îl proceseze.

Totuși, ModSecurity nu înlocuiește actualizarea platformei.

WordPress, pluginurile și temele trebuie menținute actualizate.

ModSecurity protejează și magazinele online?

Da. Request-urile către WooCommerce, PrestaShop sau alte platforme sunt analizate în același mod.

În cazul magazinelor online există însă multe operațiuni dinamice:

• checkout;
• plăți;
• API-uri;
• importuri;
• webhook-uri;
• administrarea produselor;
• filtre complexe.

Acest lucru înseamnă că este cu atât mai important să nu dezactivezi arbitrar regulile WAF.

Dacă apare un false positive, trebuie identificată exact cererea și regula care o blochează.

ModSecurity este doar o componentă a securității

Un website sigur nu se bazează pe o singură tehnologie.

Protecția corectă presupune mai multe niveluri:

HTTPS
   ↓
LiteSpeed
   ↓
WAF / ModSecurity
   ↓
Imunify360
   ↓
Aplicație actualizată
   ↓
Parole sigure + 2FA
   ↓
CloudLinux
   ↓
Backup

Dacă unul dintre aceste niveluri nu este configurat corespunzător, celelalte pot reduce riscul, dar nu îl pot elimina complet.

ModSecurity trebuie menținut activ

ModSecurity în cPanel reprezintă un nivel important de protecție pentru website-urile găzduite pe server.

Împreună cu LiteSpeed și regulile de securitate Imunify360, acesta poate analiza request-urile HTTP și HTTPS și poate bloca anumite tentative înainte ca acestea să ajungă la aplicație.

Uneori poate apărea un false positive și o operațiune legitimă poate primi eroarea 403. În această situație, soluția corectă nu este dezactivarea permanentă a ModSecurity, ci identificarea request-ului și a regulii care a declanșat blocarea.

Pe infrastructura NameBox utilizăm cPanel, LiteSpeed, CloudLinux și Imunify360, alături de sisteme de backup și protecție la nivelul infrastructurii, astfel încât securitatea website-urilor să fie realizată pe mai multe niveluri.

Dacă un website găzduit la NameBox primește eroarea 403 Forbidden în timpul unei anumite operațiuni, transmite echipei tehnice URL-ul, ora apariției problemei și adresa IP de pe care ai realizat accesarea. Aceste informații ne ajută să verificăm logurile și să identificăm dacă blocarea provine de la ModSecurity sau de la o altă componentă de securitate.

The post ModSecurity în cPanel și eroarea 403 appeared first on NAMEBOX.

Instalarea WordPress din cPanel se poate realiza rapid prin Softaculous, fără să fie necesar să descarci manual arhiva WordPress, să creezi separat baza de date sau să încarci fișierele prin FTP.

WordPress este un sistem de administrare a conținutului – CMS – open-source, utilizat pentru realizarea de bloguri, website-uri de prezentare, magazine online și proiecte web complexe.

Pe serviciile de găzduire NameBox, WordPress poate fi instalat direct din cPanel prin Softaculous Apps Installer. În acest tutorial îți arătăm ce trebuie să verifici înainte de instalare și cum configurezi corect un website WordPress nou.

Ce este WordPress?

WordPress este o platformă open-source care permite crearea și administrarea unui website prin intermediul unei interfețe grafice.

După instalare, majoritatea operațiunilor pot fi realizate direct din zona de administrare:

https://domeniul-tau.ro/wp-admin/

Din WordPress poți administra:

• pagini și articole;
• imagini și alte fișiere media;
• meniuri;
• utilizatori;
• teme;
• pluginuri;
• comentarii;
• setările website-ului.

Funcționalitatea platformei poate fi extinsă prin teme și pluginuri disponibile în directorul oficial WordPress sau furnizate de dezvoltatori externi.

Ce tipuri de website-uri poți crea cu WordPress?

WordPress nu mai este de mult o platformă utilizată exclusiv pentru bloguri.

Poate fi folosit pentru realizarea unor proiecte precum:

• website-uri de prezentare;
• bloguri;
• website-uri corporate;
• portofolii;
• site-uri pentru agenții și freelanceri;
• platforme de conținut;
• magazine online prin WooCommerce.

Complexitatea proiectului și numărul de vizitatori influențează resursele de hosting necesare.

De ce ai nevoie pentru instalarea WordPress?

Înainte de instalare trebuie să ai:

• un nume de domeniu;
• un pachet de găzduire compatibil cu WordPress;
• acces la cPanel;
• domeniul configurat către serverul de găzduire;
• un certificat SSL activ pentru utilizarea HTTPS.

Pentru o instalare modernă WordPress este recomandată utilizarea unei versiuni PHP actuale, a unei versiuni moderne MySQL sau MariaDB și activarea HTTPS.

Verifică certificatul SSL înainte de instalare

Este recomandat să instalezi WordPress direct pe versiunea HTTPS a domeniului.

Înainte să începi, verifică dacă poți accesa:

https://domeniul-tau.ro

fără erori de certificat.

Pe pachetele de găzduire NameBox este disponibil certificatul SSL gratuit Let’s Encrypt, care poate fi administrat prin cPanel.

Dacă certificatul nu este încă activ, verifică:

cPanel → Security → SSL/TLS Status

După instalarea certificatului poți continua cu instalarea WordPress folosind protocolul HTTPS.

Pasul 1: Autentifică-te în cPanel

Accesează contul cPanel asociat pachetului de găzduire.

În mod obișnuit, cPanel poate fi accesat prin:

https://domeniul-tau.ro:2083/

sau:

https://domeniul-tau.ro/cpanel

Autentifică-te folosind utilizatorul și parola contului de găzduire.

Clienții NameBox pot accesa cPanel și din contul de client.

Pasul 2: Accesează Softaculous

După autentificarea în cPanel, navighează la secțiunea:

Software → Softaculous Apps Installer

În funcție de interfața disponibilă, poți găsi și opțiunea:

WordPress Manager by Softaculous

Selectează WordPress și apoi apasă butonul:

Install

Pasul 3: Alege domeniul pe care instalezi WordPress

În secțiunea Software Setup trebuie să alegi domeniul pe care dorești instalarea.

La protocol selectează:

https://

sau:

https://www.

în funcție de varianta principală pe care dorești să o utilizezi.

Dacă dorești ca website-ul să fie disponibil direct la:

https://domeniul-tau.ro/

lasă câmpul In Directory gol.

Nu completa:

wp

dacă nu dorești ca website-ul să fie instalat la:

https://domeniul-tau.ro/wp/

Pasul 4: Configurează numele website-ului

În secțiunea Site Settings completează:

Site Name – numele website-ului.

Site Description – o scurtă descriere.

De exemplu:

Site Name: Compania Mea
Site Description: Servicii profesionale în România

Aceste informații pot fi modificate ulterior din WordPress.

Pasul 5: Creează contul de administrator WordPress

În secțiunea Admin Account vei configura utilizatorul care va avea acces la administrarea website-ului.

Trebuie completate:

• Admin Username;
• Admin Password;
• Admin Email.

Nu utiliza un username simplu precum:

admin

Alege un nume de utilizator mai greu de anticipat.

Parola trebuie să fie lungă, unică și generată special pentru acest website.

Nu utiliza aceeași parolă pentru:

• WordPress;
• cPanel;
• adresa de email;
• alte website-uri.

Adresa setată în Admin Email trebuie să fie una funcțională, deoarece WordPress o poate utiliza pentru notificări și pentru recuperarea accesului.

Pasul 6: Alege limba WordPress

Din câmpul:

Select Language

poți alege limba în care dorești să fie instalată platforma.

Pentru interfața în limba română selectează:

Romanian

Limba poate fi modificată și după instalare din:

Setări → Generale → Limba site-ului

Pasul 7: Configurează actualizările automate

Softaculous poate oferi opțiuni pentru actualizarea automată a WordPress, pluginurilor și temelor.

Actualizările sunt importante pentru securitatea website-ului, deoarece versiunile vechi pot conține vulnerabilități cunoscute.

Totuși, pentru website-uri importante sau magazine online este recomandat să existe și un backup înaintea actualizărilor majore.

După actualizare, verifică funcționarea website-ului și compatibilitatea pluginurilor și temei.

Pasul 8: Selectează pluginurile și tema

Softaculous poate permite instalarea unor pluginuri sau teme împreună cu WordPress.

Nu este necesar să instalezi numeroase pluginuri încă de la început.

Adaugă doar componentele de care website-ul are nevoie și elimină pluginurile sau temele pe care nu le utilizezi.

Un număr mare de pluginuri nu înseamnă automat că website-ul va fi lent, însă fiecare componentă adăugată trebuie menținută actualizată și verificată din punct de vedere al calității și compatibilității.

Pasul 9: Pornește instalarea WordPress

După completarea setărilor, verifică încă o dată:

• domeniul ales;
• protocolul HTTPS;
• directorul de instalare;
• username-ul administratorului;
• parola;
• adresa de email;
• limba.

Apoi apasă:

Install

Softaculous va crea automat:

• fișierele WordPress;
• baza de date;
• utilizatorul bazei de date;
• configurația wp-config.php;
• contul de administrator.

După finalizarea procesului vor fi afișate URL-ul website-ului și linkul către panoul de administrare.

Cum accesezi WordPress după instalare?

Website-ul va fi disponibil la:

https://domeniul-tau.ro/

Zona de administrare poate fi accesată la:

https://domeniul-tau.ro/wp-admin/

Autentifică-te folosind username-ul și parola configurate în Softaculous.

Ce este WordPress Manager by Softaculous?

WordPress Manager by Softaculous permite administrarea instalațiilor WordPress direct din cPanel.

În funcție de configurația disponibilă, poți realiza operațiuni precum:

• accesarea instalației WordPress;
• actualizarea WordPress;
• gestionarea pluginurilor;
• gestionarea temelor;
• clonarea unei instalații;
• crearea unei instalații pentru testare;
• modificarea anumitor setări.

Este util mai ales atunci când administrezi mai multe website-uri WordPress în același cont de găzduire.

WordPress poate fi instalat și manual?

Da.

Softaculous simplifică procesul, însă WordPress poate fi instalat și manual.

În cazul unei instalări manuale trebuie să:

1. descarci WordPress de pe wordpress.org;
2. încarci fișierele pe server;
3. creezi baza de date;
4. creezi utilizatorul bazei de date;
5. acorzi drepturile necesare;
6. configurezi conexiunea cu baza de date;
7. rulezi procesul de instalare WordPress.

Pentru majoritatea utilizatorilor cPanel, instalarea prin Softaculous este mai simplă.

Ce versiune PHP este recomandată pentru WordPress în 2026?

WordPress recomandă în prezent utilizarea unei versiuni moderne PHP.

Înainte de instalare poți verifica versiunea PHP din:

cPanel → Software → MultiPHP Manager

Recomandarea actuală WordPress este:

PHP 8.3 sau o versiune ulterioară

Trebuie însă verificată și compatibilitatea temei și a pluginurilor utilizate.

Versiunile PHP vechi și ieșite din suport nu sunt recomandate pentru un website nou.

Ce bază de date recomandă WordPress?

Pentru o configurație modernă, WordPress recomandă:

MariaDB 10.11+

sau:

MySQL 8.0+

Softaculous creează automat baza de date necesară atunci când instalezi WordPress, astfel încât nu trebuie să o configurezi manual.

Activează LiteSpeed Cache după instalare

Pe serverele WordPress NameBox este utilizat LiteSpeed Enterprise.

Pentru WordPress poate fi utilizat pluginul LiteSpeed Cache, care permite folosirea mecanismului de cache disponibil la nivelul serverului.

Cache-ul poate reduce procesarea necesară pentru paginile care pot fi servite direct din cache și poate contribui la un timp de răspuns mai redus.

După activare, configurația trebuie adaptată website-ului. Nu este recomandat să activezi toate opțiunile de optimizare fără testare.

Redis poate fi utilizat pentru Object Cache

Pentru website-urile care efectuează multe operațiuni asupra bazei de date poate fi util și Redis Object Cache.

Redis păstrează în memorie anumite date utilizate frecvent de WordPress, reducând numărul operațiunilor repetate asupra bazei de date.

Este util în special pentru proiecte precum:

• WooCommerce;
• website-uri cu trafic ridicat;
• site-uri cu baze de date complexe;
• website-uri cu multe operațiuni dinamice.

Redis nu este necesar pentru fiecare website WordPress și trebuie configurat doar dacă serviciul este disponibil pentru contul respectiv.

Protejează noua instalare WordPress

Instalarea WordPress este doar primul pas.

Pentru securitatea website-ului este recomandat să:

• menții WordPress actualizat;
• actualizezi pluginurile și temele;
• elimini pluginurile neutilizate;
• folosești parole unice și complexe;
• activezi autentificarea cu doi factori unde este posibil;
• realizezi backup regulat;
• instalezi pluginuri și teme doar din surse de încredere.

Pe pachetele de găzduire WordPress NameBox este utilizată și soluția de securitate Imunify360, care ajută la identificarea și blocarea activității malițioase la nivelul conturilor de găzduire.

Backup-ul este important înainte de modificări

După ce website-ul începe să fie utilizat, backup-ul devine una dintre cele mai importante măsuri de protecție.

Este recomandat să existe copii de siguranță înainte de:

• actualizarea WordPress;
• actualizarea pluginurilor;
• schimbarea temei;
• modificări importante asupra website-ului;
• importuri sau migrări.

Pachetele WordPress NameBox includ soluții de backup, iar restaurarea poate fi realizată atunci când există un punct de backup corespunzător.

Poți instala WooCommerce pe WordPress?

Da.

WooCommerce este una dintre soluțiile utilizate pentru transformarea unui website WordPress într-un magazin online.

WooCommerce adaugă funcționalități precum:

• produse;
• categorii;
• coș de cumpărături;
• checkout;
• comenzi;
• metode de plată;
• metode de livrare.

Un magazin WooCommerce poate necesita mai multe resurse CPU și RAM decât un website simplu de prezentare, în special dacă are multe produse, importuri, filtre sau trafic ridicat.

De ce să alegi găzduire optimizată pentru WordPress?

WordPress poate rula pe numeroase configurații de hosting, însă infrastructura și resursele disponibile influențează performanța website-ului.

Pachetele de găzduire WordPress NameBox sunt construite pentru proiecte WordPress și includ tehnologii precum:

• cPanel;
• Softaculous;
• WP Toolkit;
• LiteSpeed Enterprise;
• LiteSpeed Cache;
• CloudLinux;
• Imunify360;
• backup automat;
• SSL Let’s Encrypt.

Redis Object Cache poate fi utilizat suplimentar pentru proiectele care au nevoie de optimizare la nivelul obiectelor și bazei de date.

Instalează WordPress în câteva minute din cPanel

În 2026, instalarea WordPress din cPanel prin Softaculous elimină majoritatea operațiunilor tehnice necesare unei instalări manuale.

Procesul poate fi rezumat astfel:

cPanel
  ↓
Softaculous Apps Installer
  ↓
WordPress
  ↓
Install
  ↓
Alegi domeniul și HTTPS
  ↓
Configurezi contul administrator
  ↓
Install

După instalare, accesează wp-admin, actualizează platforma și componentele instalate, configurează backup-ul și verifică securitatea website-ului.

Pentru un tutorial pas cu pas dedicat instalării poți consulta și documentația NameBox despre instalarea WordPress din cPanel prin Softaculous.

Dacă ai nevoie de un mediu pregătit pentru WordPress, poți consulta și pachetele de găzduire WordPress NameBox.

The post Cum instalez WordPress direct din cPanel? appeared first on NAMEBOX.

Certificatul SSL gratuit Let’s Encrypt este una dintre cele mai simple metode prin care poți activa HTTPS pentru un website. În 2026, certificatele Let’s Encrypt au o valabilitate standard de 90 de zile, însă reînnoirea lor poate fi realizată automat prin sistemul AutoSSL disponibil în cPanel.

Astfel, faptul că certificatul este valabil 90 de zile nu înseamnă că trebuie să comanzi sau să instalezi manual un certificat nou la fiecare trei luni.

Pe pachetele de găzduire NameBox, certificatul Let’s Encrypt este oferit gratuit și poate fi instalat și reînnoit automat prin cPanel, atât timp cât domeniul îndeplinește condițiile necesare pentru validare.

Ce este Let’s Encrypt?

Let’s Encrypt este o autoritate de certificare care oferă certificate SSL/TLS gratuite pentru securizarea website-urilor prin HTTPS.

Certificatul permite criptarea datelor transmise între browserul vizitatorului și server.

În loc ca website-ul să fie accesat prin:

http://exemplu.ro

acesta poate utiliza conexiunea securizată:

https://exemplu.ro

Let’s Encrypt emite certificate de tip DV – Domain Validation. Pentru emiterea certificatului trebuie verificat faptul că solicitantul controlează domeniul respectiv.

Cât timp este valabil un certificat Let’s Encrypt?

În 2026, un certificat Let’s Encrypt standard este valabil timp de:

90 de zile

Această perioadă poate părea scurtă în comparație cu certificatele comerciale utilizate în trecut, însă Let’s Encrypt a fost conceput pentru un proces automatizat de emitere și reînnoire.

Prin urmare, nu trebuie să aștepți expirarea certificatului și nici să instalezi manual un certificat nou la fiecare 90 de zile.

Ce se întâmplă după cele 90 de zile?

Dacă AutoSSL este activ și domeniul poate fi validat corect, cPanel verifică certificatul și încearcă reînnoirea acestuia înainte să expire.

Procesul poate fi rezumat astfel:

Let's Encrypt emite certificatul
        ↓
Certificatul este instalat
        ↓
Este valabil 90 de zile
        ↓
AutoSSL verifică periodic certificatul
        ↓
Certificatul se apropie de expirare
        ↓
AutoSSL solicită un certificat nou
        ↓
Noul certificat este instalat automat

Astfel, website-ul poate utiliza în permanență HTTPS fără ca proprietarul să reinstaleze manual certificatul la fiecare trei luni.

Când încearcă cPanel să reînnoiască certificatul?

AutoSSL nu așteaptă ca certificatul să expire.

Pentru certificatele Let’s Encrypt, cPanel încearcă reînnoirea atunci când certificatul se apropie de termenul de expirare.

În acest mod există suficient timp pentru ca sistemul să realizeze validarea și să instaleze noul certificat înainte ca cel existent să expire.

Verificările AutoSSL sunt realizate periodic la nivelul serverului, fără să fie necesară intervenția zilnică a utilizatorului.

Let’s Encrypt este inclus gratuit la NameBox

Pe pachetele de găzduire NameBox este disponibil un certificat SSL Let’s Encrypt gratuit.

Nu este necesară achiziționarea separată a certificatului pentru a activa HTTPS pe un domeniu găzduit într-un pachet compatibil.

Prin integrarea cu cPanel, procesul de emitere și reînnoire poate fi automatizat prin AutoSSL.

Certificatul Let’s Encrypt este potrivit pentru numeroase tipuri de proiecte, precum:

• website-uri de prezentare;
• bloguri;
• website-uri WordPress;
• magazine online;
• platforme web;
• subdomenii.

Ce este AutoSSL în cPanel?

AutoSSL este funcția cPanel care automatizează administrarea certificatelor SSL pentru domeniile găzduite pe server.

AutoSSL poate realiza automat operațiuni precum:

• verificarea domeniului;
• solicitarea certificatului;
• instalarea certificatului;
• monitorizarea datei de expirare;
• reînnoirea certificatului;
• înlocuirea certificatului care urmează să expire.

În versiunile moderne cPanel & WHM, Let’s Encrypt este utilizat ca furnizor AutoSSL.

Cum verifici certificatul Let’s Encrypt în cPanel?

Autentifică-te în contul cPanel și accesează:

cPanel → Security → SSL/TLS Status

În funcție de versiunea interfeței cPanel, informațiile pot fi disponibile și în:

cPanel → Security → SSL/TLS Certificates

În această secțiune poți verifica starea SSL pentru domeniile asociate contului.

Poți identifica dacă un domeniu este:

• securizat;
• nesecurizat;
• aproape de expirarea certificatului;
• exclus din AutoSSL;
• afectat de o problemă AutoSSL.

Cum rulezi manual AutoSSL?

În mod normal, AutoSSL rulează automat și nu este necesară intervenția utilizatorului.

Dacă ai adăugat recent un domeniu, ai modificat DNS-ul sau dorești să forțezi o nouă verificare, poți utiliza opțiunea:

Run AutoSSL

din:

cPanel → Security → SSL/TLS Status

Sistemul va verifica domeniile și va încerca emiterea sau reînnoirea certificatului atunci când sunt îndeplinite condițiile necesare.

De ce Let’s Encrypt nu se instalează automat?

Emiterea automată nu poate avea loc dacă domeniul nu poate fi validat.

Una dintre cele mai frecvente cauze este configurația DNS.

Domeniul trebuie să rezolve corect către serverul pe care este găzduit website-ul.

Problemele AutoSSL pot apărea, de exemplu, dacă:

• domeniul nu rezolvă către serverul NameBox;
• DNS-ul a fost modificat recent și propagarea nu s-a finalizat;
• anumite subdomenii incluse în certificat rezolvă către alt server;
• validarea domeniului nu poate fi finalizată;
• există înregistrări CAA care nu permit emiterea certificatului;
• domeniul a fost exclus din AutoSSL.

Dacă AutoSSL afișează o eroare, cauza trebuie remediată înainte ca certificatul să poată fi emis sau reînnoit.

Ce se întâmplă dacă domeniul nu mai rezolvă către server?

AutoSSL trebuie să poată demonstra controlul asupra domeniului atunci când solicită un certificat.

Dacă domeniul este mutat către alt server sau înregistrările DNS sunt configurate incorect, procesul de validare poate eșua.

Certificatul existent va continua să funcționeze până la expirare, însă sistemul poate să nu îl mai poată reînnoi.

Din acest motiv este important ca DNS-ul domeniului să rămână configurat corect.

Trebuie să plătești după primele 90 de zile?

Nu.

Cele 90 de zile reprezintă perioada de valabilitate a certificatului individual, nu o perioadă promoțională.

După reînnoire este emis un certificat nou, tot fără cost pentru certificatul Let’s Encrypt.

Procesul se repetă automat cât timp serviciul este activ și domeniul poate fi validat.

Prin urmare:

90 de zile ≠ perioadă gratuită de test

90 de zile = durata unui certificat Let's Encrypt

La reînnoire, acesta este înlocuit cu un certificat nou.

Este Let’s Encrypt suficient pentru un magazin online?

Pentru activarea HTTPS și criptarea conexiunii, un certificat Let’s Encrypt configurat corect poate fi utilizat inclusiv pentru un magazin online.

Certificatele Let’s Encrypt folosesc aceleași protocoale TLS moderne ca certificatele comerciale compatibile.

În cazul plăților cu cardul, datele cardului sunt de regulă procesate de serviciul de plată utilizat de magazin, iar website-ul trebuie să respecte și cerințele specifice soluției respective.

SSL-ul reprezintă o componentă a securității, nu o soluție completă pentru protecția magazinului.

Let’s Encrypt este certificat DV

Let’s Encrypt oferă certificate de tip:

DV – Domain Validation

Această validare confirmă controlul asupra domeniului.

Certificatul nu validează identitatea juridică a companiei din spatele website-ului.

Pentru proiectele care necesită alte tipuri de validare sau caracteristici comerciale pot exista certificate SSL premium.

NameBox oferă și certificate SSL premium, separat de certificatul Let’s Encrypt inclus gratuit în serviciile de găzduire.

Ai nevoie de IP dedicat pentru Let’s Encrypt?

Într-un mediu modern de hosting nu este necesar un IP dedicat doar pentru instalarea unui certificat Let’s Encrypt.

Serverele și browserele moderne utilizează SNI – Server Name Indication – ceea ce permite găzduirea mai multor certificate SSL pe aceeași adresă IP.

Prin urmare, un website găzduit pe un IP shared poate utiliza HTTPS fără probleme.

Certificatul este instalat, dar website-ul se deschide încă pe HTTP

Instalarea certificatului și redirecționarea către HTTPS sunt două operațiuni diferite.

Certificatul poate fi instalat corect, dar website-ul să fie disponibil în continuare și prin:

http://exemplu.ro

Pentru ca vizitatorii să fie trimiși automat către HTTPS trebuie configurată redirecționarea:

HTTP → HTTPS

În cPanel aceasta poate fi realizată din:

cPanel → Domains → Force HTTPS Redirect

Pentru mai multe informații poți consulta ghidul nostru despre redirectarea website-ului de la HTTP la HTTPS.

Verifică și erorile Mixed Content

După activarea HTTPS trebuie verificat dacă toate resursele website-ului sunt încărcate securizat.

De exemplu, pagina poate fi deschisă prin:

https://exemplu.ro

dar o imagine să fie încărcată prin:

http://exemplu.ro/imagine.jpg

În acest caz poate apărea o problemă de tip Mixed Content.

Trebuie verificate în special:

• imaginile;
• fișierele CSS;
• JavaScript;
• fonturile;
• iframe-urile;
• resursele externe.

Let’s Encrypt nu protejează website-ul împotriva malware-ului

Un certificat SSL are rolul de a securiza conexiunea dintre browser și server.

Acesta nu protejează automat website-ul împotriva:

• malware-ului;
• pluginurilor vulnerabile;
• parolelor compromise;
• atacurilor brute force;
• codului malițios;
• accesului neautorizat în aplicație.

Pentru protecția website-ului sunt necesare măsuri suplimentare precum actualizări regulate, parole puternice, autentificare 2FA, backup și soluții de securitate.

Ce trebuie să verifici după activarea Let’s Encrypt?

După emiterea certificatului verifică următoarele:

• website-ul se deschide prin HTTPS;
• certificatul apare valid în browser;
• HTTP redirecționează către HTTPS;
• nu există erori Mixed Content;
• domeniul este inclus în AutoSSL;
• DNS-ul domeniului indică spre serverul corect.

Certificat gratuit fără reinstalare manuală la fiecare 90 de zile

Principalul avantaj al integrării Let’s Encrypt cu cPanel este automatizarea.

În 2026, certificatul Let’s Encrypt este valabil 90 de zile, însă AutoSSL monitorizează certificatul și încearcă reînnoirea acestuia înainte de expirare.

Astfel, utilizatorul nu trebuie să comande un certificat nou și nici să îl reinstaleze manual la fiecare trei luni.

Pe pachetele de găzduire NameBox, Let’s Encrypt este disponibil gratuit și poate fi administrat prin cPanel.

Dacă domeniul este configurat corect și poate fi validat, AutoSSL se ocupă de emiterea și reînnoirea certificatului, iar website-ul poate utiliza în permanență o conexiune HTTPS securizată.

Notă: Let’s Encrypt a anunțat că perioada standard de valabilitate a certificatelor va fi redusă treptat în anii următori. Acest lucru nu schimbă principiul de funcționare: emiterea și reînnoirea sunt concepute pentru a fi automatizate.

The post Certificate SSL gratuite timp de 90 de zile appeared first on NAMEBOX.

Resetarea permisiunilor pentru fișierele și folderele unui domeniu poate fi necesară atunci când acestea au fost modificate accidental, după o migrare sau în urma unor operațiuni realizate asupra contului de găzduire.

Pe serverele Linux cu cPanel sunt utilizate frecvent permisiunile 0644 pentru fișiere și 0755 pentru foldere. Aceste valori permit aplicației să acceseze fișierele fără a acorda drepturi de scriere inutile altor utilizatori.

În acest tutorial vom vedea cum realizăm o resetare recursivă a permisiunilor unui domeniu direct din SSH.

Ce sunt permisiunile fișierelor și folderelor?

Pe un server Linux, fiecare fișier și folder are anumite drepturi de acces.

Acestea stabilesc ce operațiuni pot fi realizate de:

• Owner – proprietarul fișierului;
• Group – grupul din care face parte fișierul;
• Others – ceilalți utilizatori.

Drepturile de bază sunt:

Read    = 4
Write   = 2
Execute = 1

Din combinarea acestora rezultă valori precum:

644
755
700
600

Ce permisiuni sunt utilizate pentru un website?

Pentru fișierele și folderele obișnuite ale unui website găzduit într-un cont cPanel sunt întâlnite frecvent următoarele valori:

Fișiere:  0644
Foldere:  0755

Permisiunea 0644 permite proprietarului să citească și să modifice fișierul, iar ceilalți utilizatori îl pot doar citi.

Permisiunea 0755 permite proprietarului să citească, modifice și acceseze folderul, iar ceilalți utilizatori îl pot citi și traversa.

Aceste valori sunt folosite frecvent pentru fișierele și directoarele din public_html, însă anumite aplicații pot avea cerințe diferite. cPanel permite și modificarea individuală a permisiunilor direct din File Manager. :contentReference[oaicite:0]{index=0}

Când este necesară o resetare de permisiuni?

O resetare poate fi utilă atunci când permisiunile au fost modificate greșit.

De exemplu:

• fișierele au primit accidental permisiunea 777;
• folderele nu mai pot fi accesate;
• permisiunile au fost modificate recursiv;
• fișierele au fost migrate de pe un alt server;
• un script sau o aplicație a modificat permisiunile;
• website-ul afișează erori asociate accesului la fișiere.

Este important de reținut că nu orice eroare a website-ului este cauzată de permisiuni.

De exemplu, o eroare 500 Internal Server Error poate apărea și din cauza unui fișier .htaccess configurat greșit, unor erori PHP, pluginuri incompatibile sau limite de resurse. Permisiunile sunt doar una dintre cauzele posibile. Poți consulta și ghidul nostru despre Internal Server Error 500. :contentReference[oaicite:1]{index=1}

Conectarea la server prin SSH

Pentru resetarea permisiunilor în masă avem nevoie de acces SSH.

Pe Windows poți utiliza:

• Windows Terminal;
• PuTTY;
• Termius.

Pe Linux sau macOS poți utiliza direct aplicația Terminal.

Pentru serverele VPS, datele de conectare SSH sunt furnizate împreună cu informațiile serviciului. NameBox are și un tutorial separat pentru conectarea în SSH. :contentReference[oaicite:2]{index=2}

Identificăm document root-ul domeniului

Înainte să rulăm comenzile de resetare trebuie să identificăm folderul în care se află website-ul.

Pentru domeniul principal al unui cont cPanel acesta este frecvent:

/home/USERNAME/public_html/

Înlocuiește:

USERNAME

cu utilizatorul real al contului cPanel.

Pentru domeniile suplimentare, document root-ul poate fi diferit.

De exemplu:

/home/USERNAME/domeniu.ro/

În versiunile actuale de cPanel, un domeniu suplimentar poate avea propriul document root separat de public_html. :contentReference[oaicite:3]{index=3}

Navigăm în folderul website-ului

După conectarea în SSH, navigăm către document root-ul domeniului.

Pentru domeniul principal:

cd /home/USERNAME/public_html/

Pentru un domeniu suplimentar:

cd /home/USERNAME/domeniu.ro/

Înainte să continuăm verificăm locația curentă:

pwd

Comanda trebuie să returneze exact directorul website-ului asupra căruia dorim să lucrăm.

Putem verifica și conținutul folderului:

ls -la

Este foarte important să verifici directorul înainte să rulezi comenzile recursive.

Resetarea permisiunilor folderelor la 0755

Pentru a seta permisiunea 0755 pentru toate folderele din website folosim:

find . -type d -exec chmod 0755 {} \;

Comanda caută toate directoarele începând din locația curentă și aplică permisiunea 0755.

Mai exact:

find .

înseamnă că operațiunea începe din folderul curent.

-type d

selectează doar directoarele.

chmod 0755

setează permisiunea dorită.

Resetarea permisiunilor fișierelor la 0644

Pentru toate fișierele folosim:

find . -type f -exec chmod 0644 {} \;

Comanda selectează toate fișierele din folderul curent și subfoldere și setează permisiunea:

0644

După rularea celor două comenzi vom avea, în mod uzual:

Foldere → 0755
Fișiere → 0644

Comenzile complete pentru resetarea permisiunilor

Dacă website-ul se află în:

/home/USERNAME/public_html/

putem rula comenzile în următoarea ordine:

cd /home/USERNAME/public_html/
pwd
ls -la

După ce confirmăm că suntem în locația corectă:

find . -type d -exec chmod 0755 {} \;
find . -type f -exec chmod 0644 {} \;

La final putem verifica din nou:

ls -la

Putem verifica permisiunile unui singur fișier?

Da. Dacă problema apare doar la un singur fișier, nu este necesar să resetăm întregul website.

Pentru verificare putem utiliza:

ls -l index.php

sau:

stat index.php

Pentru a seta permisiunea unui singur fișier:

chmod 0644 index.php

Pentru un singur folder:

chmod 0755 nume-folder

Dacă problema este localizată, modificarea doar a elementului afectat este mai sigură decât o operațiune recursivă.

Nu utiliza chmod -R 777

Una dintre cele mai frecvente greșeli este utilizarea comenzii:

chmod -R 777 public_html

Această comandă oferă drepturi complete de citire, scriere și execuție tuturor utilizatorilor pentru fișierele și folderele website-ului.

Permisiunea 777 nu trebuie folosită ca soluție generală pentru:

• erori 500;
• probleme de upload;
• probleme WordPress;
• erori de scriere în directoare;
• fișiere care nu pot fi accesate.

Dacă o aplicație funcționează doar după setarea permisiunii 777, trebuie identificată cauza reală.

Permisiunile nu sunt același lucru cu ownership-ul

O resetare cu chmod modifică doar permisiunile.

Aceasta nu modifică proprietarul fișierelor.

De exemplu, un fișier poate avea permisiunea corectă:

0644

dar să aparțină unui utilizator greșit.

Ownership-ul poate fi verificat folosind:

ls -la

Un rezultat poate arăta astfel:

-rw-r--r-- 1 USERNAME USERNAME 418 index.php

În acest exemplu, fișierul aparține utilizatorului și grupului:

USERNAME

Dacă ownership-ul este greșit, nu executa automat comenzi de tip:

chown -R

fără să verifici configurația serverului. Modificarea greșită a proprietarului fișierelor poate provoca probleme suplimentare.

Putem modifica permisiunile direct din cPanel?

Da.

Dacă dorești să modifici doar câteva fișiere, poți utiliza:

cPanel → Files → File Manager

Selectează fișierul sau folderul dorit și apasă:

Permissions

cPanel permite modificarea drepturilor direct din File Manager, fără acces SSH. :contentReference[oaicite:4]{index=4}

Pentru un website cu sute sau mii de fișiere, resetarea prin SSH este însă mult mai rapidă.

Ce facem dacă website-ul tot nu funcționează?

Dacă permisiunile au fost resetate și website-ul continuă să afișeze erori, problema trebuie investigată separat.

Verifică:

• fișierul error_log;
• fișierul .htaccess;
• versiunea PHP;
• erorile aplicației;
• pluginurile și temele WordPress;
• ownership-ul fișierelor;
• consumul de resurse;
• logurile serverului.

Resetarea permisiunilor nu trebuie utilizată ca soluție universală pentru orice eroare a website-ului.

Verifică întotdeauna directorul înainte de resetare

Comenzile find și chmod sunt foarte utile pentru resetarea rapidă a permisiunilor, însă acestea lucrează recursiv asupra tuturor fișierelor și folderelor din locația curentă.

Înainte de rularea lor verifică întotdeauna:

pwd
ls -la

Pentru o configurație obișnuită de website pe cPanel, 0644 pentru fișiere și 0755 pentru foldere sunt valori utilizate frecvent, dar pot exista excepții în funcție de aplicație.

Dacă website-ul este găzduit la NameBox și nu ești sigur ce permisiuni trebuie modificate, poți contacta echipa tehnică pentru verificarea configurației înainte de aplicarea unor modificări recursive.

The post Cum realizam o resetare de permisiuni pentru fisierele si folderele unui domeniu appeared first on NAMEBOX.

Viteza website-ului este la fel de importantă ca designul acestuia. O interfață modernă, responsive și bine organizată poate oferi o experiență plăcută, dar dacă utilizatorul trebuie să aștepte prea mult până când pagina devine utilizabilă, designul nu mai este suficient.

În 2026, performanța unui website depinde de mai multe componente care lucrează împreună: aplicația, imaginile, JavaScript-ul, baza de date, cache-ul, procesorul, memoria RAM, stocarea și infrastructura de hosting.

Tehnologiile SSD și NVMe au schimbat semnificativ modul în care sunt construite serverele de hosting, însă alegerea unui storage rapid reprezintă doar o parte din optimizarea unui website.

Designul responsive este standard pentru website-urile moderne

În urmă cu mai mulți ani, un website responsive reprezenta un avantaj important. În prezent, adaptarea la telefon, tabletă și desktop este o cerință de bază.

Responsive Web Design permite paginii să își adapteze structura în funcție de dimensiunea ecranului utilizatorului.

Un website modern trebuie să ofere o experiență bună indiferent dacă este accesat de pe:

• telefon mobil;
• tabletă;
• laptop;
• monitor desktop.

Elementele trebuie să se redimensioneze corect, textele să rămână ușor de citit, iar meniurile și butoanele să poată fi utilizate confortabil inclusiv pe ecrane mici.

Totuși, un design responsive nu garantează automat și un website rapid.

Un website frumos poate fi în continuare foarte lent

Un design complex poate include imagini mari, animații, fonturi externe, scripturi JavaScript și numeroase componente interactive.

Dacă acestea nu sunt optimizate, pagina poate deveni dificil de utilizat chiar dacă din punct de vedere vizual arată foarte bine.

Printre elementele care pot afecta performanța se numără:

• imagini de dimensiuni foarte mari;
• numeroase fișiere JavaScript;
• CSS neutilizat;
• fonturi externe;
• widget-uri și servicii third-party;
• pluginuri slab optimizate;
• interogări lente către baza de date;
• cache configurat incorect;
• resurse insuficiente pe server.

De aceea, designul și performanța trebuie analizate împreună.

De ce contează viteza website-ului?

Utilizatorii se așteaptă ca paginile să răspundă rapid, în special atunci când navighează de pe telefon sau folosesc o conexiune mobilă.

Pentru un magazin online, o pagină lentă poate afecta inclusiv procesul de cumpărare.

Problemele pot apărea la:

• deschiderea paginii de produs;
• schimbarea variantelor;
• adăugarea în coș;
• încărcarea checkout-ului;
• procesarea formularelor;
• navigarea între categorii.

Performanța este importantă și pentru experiența generală a utilizatorilor și pentru modul în care motoarele de căutare evaluează pagina.

Core Web Vitals în 2026

Google utilizează Core Web Vitals pentru măsurarea unor aspecte importante ale experienței reale oferite de pagini.

Principalii indicatori sunt:

• LCP – Largest Contentful Paint, care măsoară timpul necesar pentru afișarea principalului element vizibil al paginii;
• INP – Interaction to Next Paint, care măsoară cât de rapid răspunde pagina la interacțiunea utilizatorului;
• CLS – Cumulative Layout Shift, care măsoară stabilitatea vizuală a paginii.

Pentru o experiență considerată bună, Google recomandă aproximativ:

LCP ≤ 2,5 secunde
INP ≤ 200 ms
CLS ≤ 0,1

Aceste valori trebuie analizate împreună cu restul website-ului. Un scor bun nu garantează automat o poziție mai bună în Google, iar performanța reprezintă doar o parte din experiența generală oferită utilizatorului.

Cum verifici viteza website-ului?

Unul dintre cele mai utile instrumente este Google PageSpeed Insights.

Acesta analizează pagina atât pentru dispozitive mobile, cât și pentru desktop și poate utiliza două tipuri de informații:

• date reale colectate de la utilizatori prin Chrome User Experience Report, atunci când există suficiente informații;
• teste de laborator realizate prin Lighthouse.

Pe lângă PageSpeed Insights poți utiliza și:

• Chrome DevTools;
• GTmetrix;
• WebPageTest;
• Google Search Console – Core Web Vitals.

Nu urmări doar un scor de 100. Mai important este să identifici cauza reală a problemei și să îmbunătățești experiența utilizatorilor.

Ce rol are hostingul în viteza website-ului?

Hostingul influențează partea de server a aplicației.

Atunci când un utilizator solicită o pagină dinamică, serverul poate fi nevoit să:

• citească fișierele aplicației;
• execute cod PHP;
• interogheze baza de date;
• citească sau să scrie date pe storage;
• genereze pagina;
• transmită răspunsul către browser.

Performanța acestor operațiuni poate fi influențată de:

• CPU;
• memoria RAM;
• viteza storage-ului;
• serverul web;
• baza de date;
• sistemul de cache;
• numărul de procese simultane.

Din acest motiv, simpla alegere a unui storage rapid nu poate compensa o aplicație foarte slab optimizată sau lipsa resurselor necesare.

Ce este stocarea SSD?

SSD – Solid State Drive utilizează memorie flash pentru stocarea datelor și nu conține componente mecanice precum hard disk-urile tradiționale.

Față de un HDD clasic, un SSD poate oferi:

• latență mai redusă;
• viteze mai mari de citire și scriere;
• un număr mai mare de operațiuni I/O;
• timpi de acces mai mici.

Pentru un server web, aceste avantaje sunt importante deoarece aplicațiile accesează permanent fișiere și baze de date.

Ce este NVMe?

NVMe – Non-Volatile Memory Express este un protocol creat special pentru dispozitivele de stocare bazate pe memorie flash și utilizează conexiunea PCI Express.

Față de SSD-urile SATA tradiționale, NVMe permite un număr mai mare de operațiuni simultane și o latență redusă.

Acest lucru poate fi important pentru aplicații care realizează frecvent operațiuni de citire și scriere.

De exemplu:

• magazine online;
• baze de date active;
• website-uri cu trafic ridicat;
• aplicații web;
• importuri de produse;
• platforme care procesează multe operațiuni simultan.

SSD vs NVMe pentru web hosting

Atât SSD, cât și NVMe reprezintă soluții moderne de stocare, iar ambele pot fi potrivite pentru găzduirea unui website.

Alegerea trebuie însă făcută în funcție de proiect.

Un website simplu de prezentare nu va deveni automat de câteva ori mai rapid doar pentru că este mutat de pe SSD pe NVMe.

NVMe nu înlocuiește CPU-ul și memoria RAM

O confuzie frecventă este asocierea NVMe cu toate componentele performanței serverului.

Aceste resurse au roluri diferite:

CPU  → execută operațiunile
RAM  → păstrează temporar datele utilizate
NVMe → stochează și livrează datele

De exemplu, dacă un website atinge constant limita procesorului, mutarea de pe SSD pe NVMe nu va rezolva automat problema CPU.

La fel, dacă o aplicație necesită mai multă memorie decât are disponibilă, storage-ul rapid nu poate înlocui memoria RAM.

LiteSpeed poate reduce timpul necesar livrării paginilor

Pe infrastructura shared NameBox utilizăm LiteSpeed Web Server.

Pentru website-urile WordPress poate fi utilizat și LiteSpeed Cache, care permite servirea unei versiuni cache-uite a paginii fără ca aplicația să reconstruiască integral conținutul pentru fiecare vizitator.

În cazul unui Cache HIT, o parte importantă din procesarea PHP și din interogările repetate către baza de date poate fi evitată.

Astfel, stocarea rapidă, serverul web și cache-ul pot lucra împreună pentru reducerea timpului de răspuns.

Nu toate paginile pot fi cache-uite

În special în cazul magazinelor online există pagini care trebuie generate dinamic.

De exemplu:

• coșul;
• checkout-ul;
• contul clientului;
• pagini personalizate pentru utilizator;
• anumite rezultate de căutare sau filtrare.

Pentru aceste pagini devin și mai importante performanța PHP, baza de date, memoria RAM și storage-ul.

Baza de date influențează viteza magazinelor online

Magazinele online efectuează un număr mare de operațiuni asupra bazei de date.

La deschiderea unei pagini pot fi solicitate informații despre:

• produs;
• preț;
• stoc;
• variante;
• categorii;
• review-uri;
• utilizator;
• coș.

O bază de date bine optimizată și un storage rapid pot reduce timpul necesar acestor operațiuni.

Totuși, dacă aplicația generează interogări SQL ineficiente, hardware-ul mai rapid poate doar să reducă parțial efectul problemei.

Pentru WordPress poți consulta și ghidul nostru despre optimizarea bazei de date WordPress.

Redis poate ajuta aplicațiile dinamice

Pentru anumite website-uri, Redis Object Cache poate păstra în memorie rezultatele unor operațiuni și interogări utilizate frecvent.

Astfel, aplicația nu mai trebuie să solicite aceleași informații permanent din baza de date.

Redis poate fi util în special pentru:

• WordPress;
• WooCommerce;
• magazine online;
• website-uri cu baze de date active;
• aplicații cu trafic ridicat.

Redis nu înlocuiește însă LiteSpeed Cache sau optimizarea bazei de date. Fiecare tehnologie rezolvă o componentă diferită a performanței.

Un server rapid nu poate repara singur un website neoptimizat

Este important să separăm performanța hostingului de performanța aplicației.

Chiar și pe un server puternic, un website poate rămâne lent dacă:

• imaginile sunt foarte mari;
• pluginurile execută operațiuni costisitoare;
• baza de date conține interogări lente;
• sunt încărcate prea multe scripturi externe;
• pagina execută multe request-uri;
• cache-ul nu este configurat;
• aplicația așteaptă API-uri externe.

Hostingul oferă fundația pe care rulează aplicația, dar website-ul trebuie optimizat separat.

Când este suficient hostingul shared?

Un website de prezentare, un blog sau chiar un magazin online mic sau mediu poate funcționa foarte bine într-un mediu shared dacă are suficiente resurse și este optimizat corespunzător.

Nu este necesar să alegi automat un VPS doar pentru că folosești WordPress, WooCommerce, PrestaShop sau o altă platformă eCommerce.

În oferta NameBox există atât pachete de găzduire cu stocare SSD, cât și pachete cu stocare NVMe, cPanel, LiteSpeed și CloudLinux.

Poți consulta configurațiile actuale pe pagina de găzduire web NameBox.

Când merită să treci la un VPS?

Un server VPS devine potrivit atunci când proiectul necesită mai mult control sau resurse decât poate oferi mediul shared.

De exemplu:

• consum ridicat și constant de CPU;
• nevoie de mai multă memorie RAM;
• aplicații cu multe operațiuni asupra storage-ului;
• configurații personalizate la nivel de server;
• servicii custom;
• aplicații business complexe;
• trafic ridicat și constant.

Serverele VPS NameBox sunt disponibile cu stocare SSD și NVMe și sunt colocate în centrul de date GTS din Cluj-Napoca.

Hostingul local poate reduce latența, dar nu este singurul factor

Pentru un website destinat în principal utilizatorilor din România, găzduirea serverului în România poate reduce distanța de rețea dintre utilizator și infrastructură.

Totuși, latența este influențată și de:

• operatorul utilizatorului;
• rutarea rețelei;
• DNS;
• utilizarea unui CDN;
• locația reală a vizitatorului.

Din acest motiv, locația serverului trebuie analizată împreună cu restul infrastructurii.

Cum alegi hostingul potrivit?

Nu alege un pachet doar după cantitatea de spațiu disponibil.

Pentru performanță trebuie analizate și:

• tipul de storage – SSD sau NVMe;
• CPU;
• memoria RAM;
• I/O;
• serverul web;
• sistemul de cache;
• backup-ul;
• nivelul de suport oferit.

Un website de prezentare și un magazin online cu mii de produse au cerințe foarte diferite.

Optimizează website-ul înainte să crești resursele

Dacă un website se încarcă greu, primul răspuns nu trebuie să fie automat un upgrade.

Verifică mai întâi:

• PageSpeed Insights;
• Core Web Vitals;
• TTFB;
• imaginile;
• scripturile JavaScript;
• cache-ul;
• baza de date;
• pluginurile;
• CPU și RAM;
• I/O și procesele active.

Dacă aplicația este bine optimizată și resursele disponibile sunt utilizate constant la capacitate ridicată, atunci trecerea la un pachet superior sau la un VPS poate fi justificată.

Designul, aplicația și hostingul trebuie să lucreze împreună

În 2026, un website performant nu este definit de o singură tehnologie.

Un design responsive este important pentru utilizatorii de mobil, un cod bine optimizat reduce cantitatea de muncă necesară browserului și serverului, cache-ul evită procesarea inutilă, iar storage-ul SSD sau NVMe permite accesul rapid la date.

La nivel de hosting, CPU-ul, RAM-ul, storage-ul și serverul web trebuie dimensionate în funcție de cerințele reale ale proiectului.

Infrastructura NameBox utilizează cPanel, LiteSpeed și CloudLinux, iar pachetele de hosting sunt disponibile cu stocare SSD sau NVMe. Serverele sunt găzduite în România, în centrul de date GTS din Cluj-Napoca.

Dacă website-ul tău a devenit lent, analiza trebuie începută înainte de upgrade. Identificarea componentei care produce întârzierea te ajută să alegi corect între optimizarea aplicației, creșterea resurselor, trecerea la NVMe sau migrarea către un server VPS.

The post Afla cum poti creste performanta site-ului tau appeared first on NAMEBOX.

Ai un website WordPress care încă funcționează pe HTTP? În 2026, trecerea la HTTPS nu mai este doar o opțiune recomandată pentru magazine online sau site-uri care procesează plăți. HTTPS este standardul actual pentru website-uri și protejează datele transmise între browserul vizitatorului și server.

Pentru migrarea corectă a unui site WordPress de la HTTP la HTTPS nu este suficient doar să instalezi un certificat SSL. Trebuie să verifici certificatul, să actualizezi adresele WordPress, să configurezi redirectul de la HTTP către HTTPS și să elimini eventualele resurse încărcate prin HTTP.

În acest ghid îți arătăm pașii necesari pentru o migrare WordPress HTTPS corectă pe un cont de găzduire cPanel.

Ce înseamnă trecerea de la HTTP la HTTPS?

HTTP este protocolul utilizat pentru transferul informațiilor dintre browser și server. HTTPS adaugă un strat de criptare prin TLS, protejând informațiile transmise între cele două părți.

În practică, adresa website-ului se modifică din:

http://exemplu.ro

în:

https://exemplu.ro

Deși în continuare folosim frecvent termenul certificat SSL, conexiunile moderne utilizează protocolul TLS.

De ce este important HTTPS în 2026?

HTTPS protejează informațiile transmise între website și vizitator, inclusiv date introduse în formulare, parole, informații personale sau date asociate comenzilor online.

HTTPS este important și pentru experiența utilizatorilor. Browserele moderne tratează website-urile HTTP ca fiind nesecurizate, în special atunci când sunt transmise informații sensibile.

Google recomandă utilizarea HTTPS și preferă, în mod normal, versiunea HTTPS atunci când trebuie să aleagă între două URL-uri echivalente HTTP și HTTPS.

Totuși, activarea unui certificat SSL nu trebuie privită ca o metodă prin care obții automat poziții mai bune în Google. Principalul motiv pentru utilizarea HTTPS este securizarea conexiunii și oferirea unei configurații web moderne și corecte.

Pasul 1: Fă un backup înainte de migrare

Înainte să modifici adresele WordPress sau configurația website-ului, este recomandat să ai un backup recent.

Backup-ul trebuie să includă cel puțin:

• fișierele website-ului;
• baza de date WordPress;
• fișierul wp-config.php;
• fișierul .htaccess, dacă acesta este utilizat.

Schimbarea HTTP → HTTPS este în general simplă, dar o configurație greșită poate produce redirect loops, resurse indisponibile sau probleme de autentificare în wp-admin.

Pasul 2: Verifică dacă certificatul SSL este activ

Nu modifica WordPress pentru HTTPS înainte să verifici dacă domeniul are un certificat SSL valid instalat.

Pe serviciile de găzduire NameBox, certificatul SSL poate fi verificat din:

cPanel → Security → SSL/TLS Status

În funcție de configurația contului, poți utiliza AutoSSL pentru instalarea și reînnoirea automată a certificatului.

Pachetele de găzduire NameBox includ certificat SSL gratuit Let’s Encrypt, care poate fi activat din cPanel. Pentru proiectele care necesită alte tipuri de certificate există și opțiuni SSL premium.

Înainte de următorul pas, deschide manual website-ul folosind HTTPS:

https://exemplu.ro

Dacă folosești și varianta cu WWW, verifică și:

https://www.exemplu.ro

Browserul nu trebuie să afișeze o eroare privind certificatul.

Pasul 3: Schimbă adresele WordPress din HTTP în HTTPS

După ce certificatul este activ, autentifică-te în panoul WordPress și accesează:

Setări → Generale

Verifică următoarele două câmpuri:

• Adresă WordPress (URL);
• Adresă site (URL).

Dacă acestea folosesc HTTP:

http://exemplu.ro

modifică-le în:

https://exemplu.ro

Salvează modificările.

După salvare este posibil să fii deconectat din panoul WordPress. Acest lucru este normal deoarece URL-ul de administrare se schimbă pe versiunea HTTPS.

Autentifică-te din nou folosind adresa HTTPS.

Nu poți modifica URL-urile din WordPress?

Dacă cele două câmpuri sunt blocate sau nu pot fi editate, este posibil ca adresele să fie definite direct în fișierul wp-config.php.

În astfel de situații trebuie verificate constante precum:

WP_HOME
WP_SITEURL

Nu modifica aceste valori dacă nu ești sigur de configurația website-ului, deoarece o adresă greșită poate face panoul WordPress inaccesibil.

Pasul 4: Configurează redirectul permanent de la HTTP la HTTPS

După activarea versiunii HTTPS, vizitatorii care accesează o adresă veche HTTP trebuie trimiși automat către versiunea securizată.

De exemplu:

http://exemplu.ro/despre-noi/

trebuie să redirecționeze către:

https://exemplu.ro/despre-noi/

Pentru această modificare trebuie utilizat un redirect permanent 301.

Pe un cont cPanel, redirectul poate fi configurat din:

cPanel → Domains → Redirects

sau prin fișierul .htaccess.

Pe serverele LiteSpeed, regulile uzuale de rescriere din .htaccess sunt compatibile cu această configurație.

Dacă website-ul are deja un mecanism care forțează HTTPS, nu adăuga mai multe redirecturi pentru aceeași operațiune. Regulile duplicate pot cauza redirecturi suplimentare sau chiar eroarea Too Many Redirects.

Pasul 5: Verifică URL-urile HTTP rămase în WordPress

Schimbarea URL-urilor din Setări → Generale nu înseamnă neapărat că toate adresele HTTP existente în baza de date vor fi modificate.

Un website mai vechi poate conține URL-uri HTTP salvate în:

• pagini și articole;
• widget-uri;
• setările temei;
• page buildere;
• meniuri;
• câmpuri personalizate;
• setările pluginurilor;
• imagini și alte fișiere media.

De exemplu, într-o pagină poate exista în continuare:

http://exemplu.ro/wp-content/uploads/imagine.jpg

în loc de:

https://exemplu.ro/wp-content/uploads/imagine.jpg

Pentru website-uri cu multe URL-uri vechi poate fi necesară o operațiune de search and replace în baza de date.

Înainte de această operațiune creează un backup și folosește un instrument compatibil cu structura bazei de date WordPress. Nu este recomandată înlocuirea manuală necontrolată direct în baza de date, deoarece anumite pluginuri sau teme pot utiliza date serializate.

Pasul 6: Verifică erorile Mixed Content

Una dintre cele mai întâlnite probleme după migrarea unui website la HTTPS este Mixed Content.

Aceasta apare atunci când pagina principală este încărcată prin HTTPS, dar anumite resurse sunt solicitate în continuare prin HTTP.

De exemplu:

Pagina:
https://exemplu.ro

Imagine:
http://exemplu.ro/imagine.jpg

Mixed Content poate fi provocat de:

• imagini;
• fișiere CSS;
• JavaScript;
• fonturi;
• iframe-uri;
• resurse externe;
• URL-uri introduse manual în temă sau pluginuri.

Pentru verificare, deschide website-ul în browser și folosește:

Developer Tools → Console

Dacă există resurse nesecurizate, browserul poate afișa mesaje care indică exact URL-ul încărcat prin HTTP.

Pasul 7: Verifică imaginile, CSS-ul și
JavaScript-ul

După migrare, navighează prin mai multe zone ale website-ului și verifică dacă toate elementele sunt afișate corect.

Testează cel puțin:

• homepage-ul;
• paginile principale;
• articolele;
• formularele de contact;
• meniurile;
• imaginile;
• zona de autentificare;
• coșul și checkout-ul, dacă este un magazin WooCommerce.

Dacă după activarea HTTPS website-ul apare fără stilizare sau anumite imagini dispar, verifică URL-urile resurselor înainte să presupui că există o problemă cu certificatul SSL.

Pasul 8: Verifică versiunea WWW și non-WWW

Este recomandat să alegi o singură variantă principală a domeniului.

De exemplu:

https://exemplu.ro

sau:

https://www.exemplu.ro

Cealaltă variantă trebuie să redirecționeze permanent către versiunea principală.

Evită situația în care website-ul poate fi accesat separat prin:

http://exemplu.ro
http://www.exemplu.ro
https://exemplu.ro
https://www.exemplu.ro

fără o redirecționare coerentă către o singură versiune.

Pasul 9: Verifică URL-urile canonice

După migrare, verifică dacă paginile website-ului folosesc versiunea HTTPS și în tag-ul canonical.

Un canonical vechi care indică spre HTTP poate transmite semnale contradictorii motoarelor de căutare.

Pentru o pagină HTTPS, canonical-ul ar trebui să indice în mod normal către versiunea HTTPS corespunzătoare.

Dacă folosești un plugin SEO pentru WordPress, acesta va genera de regulă automat canonical-ul pe baza adresei principale configurate în WordPress. Totuși, este recomandată verificarea după migrare.

Pasul 10: Actualizează sitemap-ul XML

După migrare, sitemap-ul website-ului trebuie să conțină URL-uri HTTPS.

Verifică dacă adresele din sitemap încep cu:

https://

și nu cu:

http://

Dacă sitemap-ul este generat de WordPress sau de un plugin SEO, acesta se actualizează de obicei după schimbarea adresei website-ului, însă merită verificat manual.

Pasul 11: Verifică Google Search Console

Trecerea de la HTTP la HTTPS modifică URL-urile website-ului, iar Google trebuie să descopere și să proceseze versiunile noi.

Dacă folosești o proprietate Search Console de tip URL-prefix, verifică și versiunea HTTPS a website-ului.

Dacă utilizezi o proprietate de tip Domain, aceasta acoperă protocoalele și subdomeniile asociate domeniului.

După migrare este recomandat să:

• verifici accesibilitatea versiunii HTTPS;
• trimiți sitemap-ul care conține URL-urile HTTPS;
• verifici câteva pagini importante prin URL Inspection;
• urmărești eventualele erori de indexare;
• verifici dacă URL-urile HTTP redirecționează cu 301 către HTTPS.

Pentru simpla trecere de la HTTP la HTTPS pe același domeniu nu este necesară folosirea instrumentului Change of Address.

Ce se întâmplă cu pozițiile în Google după trecerea la HTTPS?

Google tratează schimbarea HTTP → HTTPS ca pe o modificare a URL-urilor website-ului.

În timpul recrawl-ului și reindexării pot exista fluctuații temporare, în special pentru website-uri mari.

Dacă redirecturile 301 sunt configurate corect, URL-urile canonice sunt actualizate, sitemap-ul folosește HTTPS și nu există blocaje de crawling, Google poate transfera semnalele de la adresele HTTP către versiunile HTTPS.

Google precizează că redirecturile permanente precum 301 nu duc, prin ele însele, la pierderea PageRank.

SSL gratuit sau certificat SSL premium?

Pentru activarea HTTPS nu este obligatoriu să achiziționezi un certificat premium.

Un certificat SSL gratuit precum Let’s Encrypt oferă criptarea necesară pentru HTTPS și este suficient pentru numeroase website-uri WordPress.

Pe pachetele de găzduire NameBox este disponibil certificat SSL Let’s Encrypt gratuit, cu posibilitatea activării și reînnoirii prin cPanel.

În funcție de proiect, pot fi utilizate și certificate SSL premium, inclusiv certificate cu diferite tipuri de validare sau certificate Wildcard.

Important este ca certificatul utilizat să fie valid, instalat corect și să acopere hostname-urile prin care website-ul este accesat.

HTTPS nu securizează singur întregul website

Un certificat SSL criptează conexiunea dintre vizitator și server, dar nu înlocuiește celelalte măsuri de securitate.

HTTPS nu poate preveni singur:

• infectarea unui website WordPress;
• vulnerabilitățile pluginurilor;
• parolele slabe;
• accesul neautorizat în wp-admin;
• fișierele malițioase;
• compromiterea unui cont de administrator.

Pentru securitatea website-ului trebuie menținute actualizate WordPress, tema și pluginurile și trebuie utilizate parole puternice, backup-uri și soluții de securitate adecvate.

Checklist după migrarea WordPress la HTTPS

Înainte să consideri migrarea finalizată, verifică următoarele:

• certificatul SSL este valid;
• website-ul se deschide corect prin HTTPS;
• WordPress Address și Site Address folosesc HTTPS;
• HTTP redirecționează permanent către HTTPS;
• WWW și non-WWW sunt configurate coerent;
• nu există erori Mixed Content;
• imaginile, CSS-ul și JavaScript-ul se încarcă normal;
• formularele și autentificarea funcționează;
• canonical-urile indică spre HTTPS;
• sitemap-ul conține URL-uri HTTPS;
• Search Console vede corect noile adrese;
• nu există redirect loops sau erori 404 introduse în timpul migrării.

Migrarea la HTTPS trebuie făcută complet, nu doar activat certificatul

Față de modul în care se realiza migrarea în urmă cu câțiva ani, un website WordPress modern necesită mai multe verificări după instalarea certificatului SSL.

Activarea certificatului este doar primul pas. Pentru o migrare corectă trebuie actualizate adresele WordPress, configurat redirectul permanent de la HTTP către HTTPS, eliminate resursele Mixed Content și verificate elementele SEO precum canonical-urile și sitemap-ul.

Dacă website-ul este găzduit la NameBox, certificatul SSL poate fi verificat și administrat din cPanel, iar în cazul în care întâmpini probleme la activarea HTTPS sau la redirectarea website-ului, echipa tehnică poate verifica configurația serviciului de găzduire.

The post Cum migram un site WordPress pe HTTPS? appeared first on NAMEBOX.

Optimizarea SEO ajută motoarele de căutare să înțeleagă mai bine conținutul unui website și poate contribui la creșterea vizibilității acestuia în rezultatele Google. SEO nu înseamnă însă repetarea unui cuvânt cheie de cât mai multe ori sau modificarea zilnică a paginilor.

În 2026, optimizarea unui website presupune o combinație între conținut util, structură clară, performanță, accesibilitate pentru motoarele de căutare și o experiență bună pentru utilizatori.

Rezultatele nu apar întotdeauna imediat. Google trebuie să descopere, să acceseze și să proceseze paginile, iar poziționarea depinde de numeroși factori, inclusiv relevanța conținutului, concurența pentru căutarea respectivă, autoritatea website-ului și calitatea generală a paginii.

Ce înseamnă optimizarea SEO în 2026?

SEO – Search Engine Optimization – reprezintă procesul prin care îmbunătățești un website astfel încât paginile sale să poată fi descoperite, înțelese și afișate cât mai relevant în motoarele de căutare.

O strategie SEO modernă include mai multe componente:

• conținut relevant și util;
• identificarea intenției de căutare;
• titluri și heading-uri clare;
• linkuri interne;
• optimizarea imaginilor;
• structură tehnică corectă;
• website adaptat pentru dispozitive mobile;
• viteză și experiență bună pentru utilizatori;
• indexare și crawling corect;
• monitorizare prin Google Search Console și Google Analytics.

Google recomandă în primul rând crearea unui conținut util, de încredere și conceput pentru utilizatori, nu a unui conținut construit exclusiv pentru manipularea pozițiilor din motorul de căutare.

1. Înțelege ce caută utilizatorul

Înainte să alegi un cuvânt cheie, trebuie să înțelegi intenția de căutare.

Două expresii asemănătoare pot avea scopuri complet diferite.

De exemplu:

ce este găzduirea web

arată, în general, o intenție informațională. Utilizatorul dorește să înțeleagă un concept.

În schimb:

găzduire web România

poate indica o intenție comercială, utilizatorul fiind mai aproape de alegerea unui serviciu.

Conținutul paginii trebuie construit astfel încât să răspundă cât mai bine nevoii reale din spatele căutării.

Nu încerca să introduci aceeași expresie în fiecare paragraf. Folosește natural termenul principal, sinonime, expresii asociate și explicații relevante pentru subiect.

2. Optimizează titlul paginii

Titlul este unul dintre cele mai importante elemente prin care utilizatorii și motoarele de căutare pot înțelege subiectul unei pagini.

Fiecare pagină importantă ar trebui să aibă un titlu unic, clar și descriptiv.

Un titlu bun trebuie să:

• descrie corect conținutul paginii;
• includă natural subiectul sau expresia principală;
• fie diferit de titlurile celorlalte pagini;
• evite repetarea inutilă a cuvintelor cheie;
• fie suficient de atractiv pentru utilizator.

De exemplu, un titlu precum:

SEO, SEO România, optimizare SEO, servicii SEO, cel mai bun SEO

nu oferă o experiență bună și reprezintă o formă de keyword stuffing.

O variantă mai utilă ar putea fi:

Optimizare SEO pentru magazine online: Ghid practic

Nu există o limită fixă de caractere impusă de Google pentru elementul <title>. În rezultatele de căutare, titlul poate fi scurtat în funcție de spațiul disponibil și de dispozitiv.

Google poate, de asemenea, să afișeze un alt title link decât cel definit de tine dacă sistemele sale consideră că o altă formulare reprezintă mai bine pagina.

3. Scrie o meta description relevantă

Meta description este o scurtă descriere a conținutului paginii și poate fi utilizată de Google pentru fragmentul afișat sub titlu în rezultatele de căutare.

O descriere bună trebuie să rezume pagina și să îi ofere utilizatorului un motiv clar pentru a o accesa.

De exemplu:

Află cum optimizezi paginile unui magazin online pentru Google: titluri, conținut, imagini, linkuri interne și performanță.

Nu există o limită oficială fixă de 150 sau 160 de caractere. Google poate scurta descrierea în funcție de dispozitiv și poate utiliza uneori un fragment direct din conținutul paginii dacă acesta răspunde mai bine căutării utilizatorului.

Este recomandat însă ca descrierea să fie concisă, relevantă și unică pentru paginile importante.

4. Folosește corect H1, H2 și H3

Heading-urile ajută atât utilizatorii, cât și motoarele de căutare să înțeleagă structura paginii.

O structură simplificată poate arăta astfel:

H1 – Subiectul principal
H2 – Secțiune importantă
H3 – Subsecțiune
H2 – Următoarea secțiune
H3 – Detaliu al secțiunii

Heading-urile trebuie folosite pentru structurarea logică a informației, nu doar pentru a face textul mai mare.

Include expresii relevante atunci când se potrivesc natural, dar nu încerca să introduci cuvântul cheie principal în fiecare H2 sau H3.

5. Creează conținut pentru oameni, nu pentru densitatea cuvintelor cheie

Una dintre ideile SEO care s-au învechit este urmărirea unei densități exacte a cuvântului cheie.

Nu există un procent universal precum 1%, 2% sau 3% pe care trebuie să îl atingi pentru a obține o poziție bună.

Mai important este ca pagina să răspundă complet întrebării utilizatorului.

Conținutul bun poate include:

• explicații clare;
• exemple practice;
• informații originale;
• experiență reală;
• imagini sau capturi relevante;
• date actualizate;
• răspunsuri la întrebările care apar natural în jurul subiectului.

Google recomandă conținutul people-first: informații create în primul rând pentru a ajuta vizitatorul, nu pentru a manipula algoritmul.

Nu există nici un număr minim sau ideal de cuvinte impus de Google. Un articol trebuie să fie atât de lung cât este necesar pentru a explica subiectul corect și complet.

6. Folosește linkuri interne relevante

Linkurile interne conectează paginile aceluiași website și sunt importante atât pentru navigarea utilizatorilor, cât și pentru descoperirea conținutului de către motoarele de căutare.

De exemplu, într-un articol despre optimizarea unui magazin online poți crea un link către un ghid mai detaliat despre optimizarea SEO a magazinelor online.

Textul linkului trebuie să fie descriptiv.

Este mai util:

vezi ghidul pentru optimizarea WordPress

decât:

click aici

Google folosește linkurile pentru descoperirea paginilor, iar textul ancoră oferă informații suplimentare despre pagina către care este făcută legătura.

Nu este necesar să introduci zeci de linkuri interne doar pentru SEO. Adaugă-le acolo unde oferă utilizatorului acces la informații suplimentare relevante.

7. Optimizează imaginile

Imaginile pot contribui la experiența utilizatorului și pot fi descoperite inclusiv prin Google Images.

Pentru fiecare imagine importantă este recomandat să folosești:

• un fișier cu o denumire descriptivă;
• un format potrivit și o dimensiune optimizată;
• atribut ALT relevant;
• o imagine care are legătură reală cu pagina;
• rezoluție suficient de bună fără a încărca inutil website-ul.

De exemplu, în loc de:

IMG_58392.jpg

poți folosi:

optimizare-seo-magazin-online.webp

Iar atributul ALT poate fi:

Analiză SEO pentru un magazin online

Nu introduce o listă de cuvinte cheie în ALT. Acesta trebuie să descrie util și natural imaginea.

Atributul TITLE al imaginii nu trebuie confundat cu ALT și nu este necesar să îl completezi cu expresii SEO doar pentru a încerca să obții o poziționare mai bună.

8. Asigură-te că paginile pot fi accesate și indexate

Poți avea cel mai bun conținut, dar acesta nu va aduce trafic organic dacă Google nu îl poate accesa sau indexa.

Printre elementele tehnice care trebuie verificate se numără:

• robots.txt;
• meta robots;
• directivele noindex;
• URL-urile canonice;
• redirecturile;
• codurile HTTP;
• sitemap-ul XML;
• linkurile interne către paginile importante.

De exemplu, o pagină importantă setată accidental pe:

noindex

nu ar trebui să fie indexată de Google, indiferent cât de bine este optimizat textul acesteia.

9. Folosește un sitemap XML

Un sitemap XML ajută motoarele de căutare să descopere URL-urile importante ale website-ului.

Acesta este util mai ales pentru website-uri mari, magazine online sau site-uri care publică frecvent conținut nou.

Sitemap-ul poate fi trimis către Google prin:

Google Search Console → Sitemaps

Trimiterea unui sitemap nu garantează că toate URL-urile vor fi indexate. Google decide separat ce pagini accesează și include în index.

Sitemap-ul trebuie să conțină, în general, URL-urile canonice pe care dorești să le indexezi.

10. Monitorizează website-ul cu Google Search Console

Instrumentul cunoscut în trecut sub numele de Google Webmaster Tools se numește în prezent Google Search Console.

Search Console este unul dintre cele mai importante instrumente pentru SEO deoarece îți permite să urmărești modul în care Google vede website-ul.

Poți analiza:

• căutările prin care utilizatorii ajung pe site;
• numărul de click-uri;
• impresiile;
• CTR-ul;
• poziția medie;
• paginile indexate;
• problemele de crawling și indexare;
• Core Web Vitals;
• sitemap-urile;
• eventualele acțiuni manuale sau probleme de securitate.

Instrumentul URL Inspection permite verificarea unei pagini individuale și poate arăta dacă aceasta este indexată și ce URL consideră Google ca fiind canonical.

11. Folosește Google Analytics 4 pentru comportamentul utilizatorilor

Pentru analiza traficului poți utiliza Google Analytics 4 – GA4.

Google Analytics și Search Console au roluri diferite.

Search Console oferă informații despre performanța website-ului în Google Search, în timp ce Google Analytics urmărește ceea ce fac utilizatorii după ce ajung pe website.

În GA4 poți analiza, în funcție de configurație:

• numărul utilizatorilor;
• sursele de trafic;
• paginile vizitate;
• evenimentele;
• conversiile;
• comportamentul vizitatorilor.

Datele trebuie analizate împreună pentru a înțelege nu doar cât trafic primește website-ul, ci și dacă acel trafic generează rezultate.

12. Viteza website-ului și Core Web Vitals

Performanța este importantă atât pentru experiența utilizatorilor, cât și pentru SEO.

Google utilizează Core Web Vitals pentru evaluarea unor aspecte ale experienței reale oferite de pagină.

Principalii indicatori sunt:

• LCP – Largest Contentful Paint, pentru viteza de încărcare a conținutului principal;
• INP – Interaction to Next Paint, pentru capacitatea paginii de a răspunde la interacțiuni;
• CLS – Cumulative Layout Shift, pentru stabilitatea vizuală.

Totuși, un scor perfect de performanță nu garantează prima poziție în Google. Relevanța și calitatea conținutului rămân esențiale.

Dacă folosești WordPress, poți consulta și ghidul nostru despre optimizarea WordPress, unde explicăm mai detaliat performanța, cache-ul și Core Web Vitals.

13. Optimizează website-ul pentru dispozitive mobile

Website-ul trebuie să poată fi utilizat confortabil de pe telefon, tabletă și desktop.

O pagină adaptată pentru mobil trebuie să aibă:

• text ușor de citit;
• butoane suficient de mari;
• navigare simplă;
• elemente care nu ies din ecran;
• imagini responsive;
• încărcare rapidă;
• fără pop-up-uri care blochează inutil conținutul.

Nu crea o variantă simplificată a conținutului doar pentru utilizatorii de mobil. Informațiile importante trebuie să fie disponibile indiferent de dispozitiv.

14. Folosește date structurate atunci când sunt relevante

Datele structurate oferă motoarelor de căutare informații suplimentare despre tipul de conținut al unei pagini.

În funcție de website, pot exista tipuri de date structurate pentru:

• articole;
• produse;
• organizații;
• breadcrumb-uri;
• evenimente;
• rețete;
• alte tipuri de conținut suportate de Google.

Implementarea datelor structurate nu garantează apariția unui rich result. Pagina trebuie să respecte atât cerințele tehnice, cât și politicile Google pentru tipul respectiv de conținut.

15. Nu publica sau modifica texte doar pentru a părea „fresh”

Un alt mit SEO este că trebuie să publici sau să modifici paginile zilnic pentru ca Google să le considere mai importante.

Actualizarea conținutului este utilă atunci când informațiile s-au schimbat sau când poți aduce valoare nouă.

De exemplu, merită actualizat un articol dacă:

• informațiile tehnice s-au schimbat;
• interfața unui serviciu este diferită;
• anumite recomandări nu mai sunt valabile;
• poți adăuga informații sau exemple mai utile;
• există linkuri sau resurse care nu mai funcționează.

În schimb, schimbarea datei articolului sau modificarea câtorva cuvinte doar pentru a crea impresia de conținut nou nu reprezintă o strategie SEO.

16. Nu optimiza doar pentru Google clasic

În 2026, rezultatele Google includ și experiențe bazate pe inteligență artificială, pe lângă rezultatele organice tradiționale.

Acest lucru nu înseamnă că trebuie să construiești o strategie SEO complet diferită sau să urmărești diverse „trucuri GEO” ori „AEO”.

Google recomandă în continuare aceleași principii de bază: conținut original, util, bine structurat, accesibil tehnic și creat pe baza experienței și cunoștințelor reale.

Conținutul care oferă informații originale, exemple practice și răspunsuri complete are șanse mai bune să fie util atât în rezultatele clasice, cât și în noile experiențe de căutare.

17. SEO nu este o operațiune pe care o faci o singură dată

Optimizarea SEO trebuie privită ca un proces continuu.

După publicarea unei pagini, urmărește rezultatele și verifică dacă aceasta răspunde cu adevărat nevoilor utilizatorilor.

Poți analiza în Search Console:

• pentru ce căutări apare pagina;
• ce expresii generează click-uri;
• dacă impresiile cresc;
• ce poziții ocupă pagina;
• dacă apar probleme de indexare.

Pe baza informațiilor reale poți îmbunătăți ulterior titlul, structura, conținutul sau linkurile interne.

Ce ar trebui să eviți în SEO?

O strategie SEO bună nu se bazează pe trucuri rapide.

Evită practici precum:

• repetarea excesivă a cuvintelor cheie;
• texte scrise exclusiv pentru motoarele de căutare;
• generarea unui număr mare de pagini aproape identice;
• titluri și descrieri care nu corespund conținutului;
• linkuri interne introduse artificial;
• ALT-uri pline de cuvinte cheie;
• copierea conținutului de pe alte website-uri;
• schimbarea artificială a datei unui articol doar pentru a părea nou;
• urmărirea unui număr exact de cuvinte doar pentru SEO.

O strategie SEO bună începe cu utilizatorul

SEO s-a schimbat mult față de recomandările folosite în urmă cu zece ani. Nu mai este suficient să introduci un cuvânt cheie în titlu, descriere și de câteva ori în conținut.

În 2026, o pagină bine optimizată trebuie să răspundă unei intenții reale de căutare, să ofere informații utile și originale, să fie ușor de navigat și să poată fi accesată fără probleme de motoarele de căutare.

Folosește Google Search Console pentru a monitoriza vizibilitatea și indexarea, Google Analytics 4 pentru a înțelege comportamentul vizitatorilor și actualizează paginile atunci când ai informații noi sau poți îmbunătăți real experiența utilizatorului.

O optimizare SEO făcută corect nu urmărește doar poziția unei pagini pentru un anumit cuvânt cheie. Scopul final este ca utilizatorul să găsească rapid răspunsul de care are nevoie și website-ul să îi ofere o experiență suficient de bună încât să continue navigarea, să revină sau să devină client.

The post Sfaturi pentru promovare SEO appeared first on NAMEBOX.

Atunci când un server trimite un email, serverul destinatar nu verifică doar adresa expeditorului. Sunt analizate și informații despre serverul de trimitere, adresa sa IP, autentificarea domeniului și reputația sursei.

Una dintre aceste verificări este Reverse DNS, cunoscut și sub denumirea de rDNS. Aceasta utilizează un PTR Record pentru a identifica numele de host asociat unei adrese IP.

Configurarea corectă a Reverse DNS este importantă pentru serverele care trimit emailuri. Furnizori precum Gmail verifică existența unor înregistrări DNS forward și reverse valide pentru IP-urile de trimitere, iar o configurație incorectă poate contribui la limitarea sau respingerea mesajelor.

În acest articol explicăm ce este un PTR Record, care este diferența dintre DNS normal și Reverse DNS, cum îl poți verifica în cPanel și de ce PTR-ul trebuie analizat împreună cu SPF, DKIM și DMARC.

Ce este Reverse DNS?

În mod normal, sistemul DNS este utilizat pentru a transforma un nume de domeniu sau un hostname într-o adresă IP.

De exemplu:

mail.exemplu.ro → 192.0.2.25

Aceasta este o rezolvare DNS normală, numită și forward DNS.

Reverse DNS face operațiunea inversă. Pornind de la adresa IP, sistemul încearcă să identifice hostname-ul asociat acesteia:

192.0.2.25 → mail.exemplu.ro

Pentru această asociere este utilizată o înregistrare DNS de tip PTR.

Ce este un PTR Record?

PTR vine de la Pointer Record și este înregistrarea utilizată pentru rezolvarea unei adrese IP către un hostname.

Putem privi relația simplificat astfel:

A Record:
mail.exemplu.ro → 192.0.2.25

PTR Record:
192.0.2.25 → mail.exemplu.ro

În cazul unui server de email, configurația ideală presupune ca hostname-ul returnat de PTR să rezolve la rândul său către aceeași adresă IP.

Astfel avem:

IP → PTR → hostname
hostname → A Record → același IP

Această corespondență este cunoscută frecvent sub denumirea de forward-confirmed reverse DNS.

Care este diferența dintre A Record și PTR Record?

Deși cele două înregistrări pot face referire la aceleași elemente, direcția de rezolvare este diferită.

Pentru IPv6, principiul este același, însă hostname-ul este asociat prin forward DNS folosind o înregistrare AAAA.

De ce verifică serverele de email Reverse DNS?

Atunci când un server SMTP primește un mesaj, acesta poate verifica adresa IP a serverului care inițiază conexiunea.

Prin Reverse DNS, serverul destinatar poate afla ce hostname este asociat IP-ului respectiv.

Această informație poate fi utilizată împreună cu alte semnale pentru evaluarea mesajului și a infrastructurii de trimitere.

O configurație coerentă ar putea arăta astfel:

IP expeditor: 192.0.2.25
PTR: mail.exemplu.ro
A mail.exemplu.ro: 192.0.2.25

Dacă IP-ul nu are deloc un PTR sau hostname-ul returnat nu rezolvă corespunzător către IP-ul de trimitere, anumite servicii de email pot considera configurația incompletă sau suspectă.

Google Gmail verifică PTR Record?

Da. Google include existența unor înregistrări DNS forward și reverse valide în cerințele pentru expeditorii care trimit mesaje către adrese Gmail.

Google precizează că adresa IP publică a serverului SMTP de trimitere trebuie să aibă un PTR care indică spre un hostname, iar acel hostname trebuie să aibă un A Record sau AAAA Record care rezolvă înapoi către aceeași adresă IP.

Practic:

IP → PTR → hostname → A/AAAA → același IP

O configurație Reverse DNS greșită poate conduce inclusiv la limitarea temporară a mesajelor trimise către Gmail.

Acest lucru nu înseamnă însă că un PTR configurat corect garantează automat livrarea în Inbox.

PTR Record nu înlocuiește SPF, DKIM și DMARC

Reverse DNS reprezintă doar una dintre componentele utilizate în evaluarea mesajelor.

Pentru o configurație corectă de email trebuie analizate și mecanismele de autentificare ale domeniului.

SPF

SPF permite domeniului să indice ce servere sau adrese IP sunt autorizate să trimită email în numele său.

DKIM

DKIM aplică o semnătură criptografică mesajului, care poate fi verificată de serverul destinatar.

DMARC

DMARC verifică alinierea domeniului utilizat în mesaj cu autentificarea SPF și/sau DKIM și permite publicarea unei politici pentru mesajele care nu trec verificările.

PTR / Reverse DNS

PTR-ul identifică hostname-ul asociat IP-ului care efectuează conexiunea SMTP.

Prin urmare, o infrastructură de email bine configurată trebuie privită ca un ansamblu:

PTR / Reverse DNS
SPF
DKIM
DMARC
TLS
Reputația IP-ului
Reputația domeniului
Comportamentul de trimitere

Pentru verificarea SPF, DKIM și DMARC poți consulta și ghidul nostru Verificare setări Email Deliverability în cPanel.

Un PTR corect garantează că emailurile ajung în Inbox?

Nu.

Reverse DNS este doar unul dintre semnalele pe care serviciile de email le pot utiliza.

Livrabilitatea poate fi influențată și de:

• configurația SPF;
• semnătura DKIM;
• politica și alinierea DMARC;
• reputația IP-ului;
• reputația domeniului;
• prezența IP-ului pe blocklist-uri;
• numărul mesajelor trimise;
• rata de reclamații Spam;
• destinatari inexistenți;
• conținutul mesajelor;
• comportamentul general de trimitere.

De aceea, dacă un email ajunge în Spam, simpla modificare a PTR-ului nu trebuie tratată ca o soluție universală.

PTR Record se configurează în Zone Editor?

În majoritatea situațiilor, nu.

Aici apare una dintre cele mai frecvente confuzii.

Înregistrările A, CNAME, MX sau TXT ale unui domeniu sunt administrate în zona DNS autoritativă a domeniului. În cPanel, acestea pot fi gestionate prin Zone Editor atunci când serverul respectiv administrează zona DNS.

PTR-ul este diferit deoarece aparține zonei DNS inverse asociate adresei IP.

Autoritatea asupra acestei zone aparține în mod normal organizației care deține sau administrează blocul de adrese IP.

Din acest motiv, nu poți crea pur și simplu un PTR pentru IP-ul serverului introducând o nouă înregistrare în zona DNS obișnuită a domeniului.

Cine poate modifica Reverse DNS?

Modificarea unui PTR Record / Reverse DNS depinde de modul în care este administrată adresa IP.

În cazul serviciilor NameBox, configurarea sau modificarea PTR-ului se realizează de către echipa tehnică NameBox, la solicitarea clientului.

Dacă ai un VPS sau un server cu IP dedicat și dorești modificarea Reverse DNS, ne poți transmite hostname-ul care trebuie asociat adresei IP, iar noi putem verifica și efectua configurarea.

La alți furnizori, procedura poate fi diferită. Unele companii modifică PTR-ul la solicitarea clientului, în timp ce altele oferă posibilitatea configurării Reverse DNS direct din propriul panou de administrare.

Important este că PTR-ul trebuie configurat la nivelul infrastructurii care administrează adresa IP și nu se modifică, în mod obișnuit, ca o înregistrare DNS standard din zona domeniului.

Cum verifici Reverse DNS în cPanel?

În cPanel poți verifica informațiile de livrabilitate accesând:

cPanel → Email → Email Deliverability

Identifică domeniul dorit și apasă Manage.

În funcție de configurația serverului, cPanel poate afișa o secțiune:

Reverse DNS (PTR)

Aceasta permite verificarea PTR-ului și poate indica probleme atunci când configurația nu este corespunzătoare.

Este important de reținut că faptul că poți verifica PTR-ul în cPanel nu înseamnă automat că îl poți și modifica de acolo.

Dacă utilizatorul nu controlează IP-ul, modificarea trebuie efectuată de administratorul adresei IP.

Ce este Mail HELO și ce legătură are cu PTR-ul?

La inițierea unei conexiuni SMTP, serverul de trimitere se identifică folosind un hostname prin comanda HELO sau EHLO.

De exemplu:

EHLO server.exemplu.ro

Hostname-ul SMTP, DNS-ul forward și PTR-ul serverului ar trebui să formeze o configurație coerentă.

În secțiunea Email Deliverability, cPanel poate afișa inclusiv informații despre Mail HELO atunci când identifică nepotriviri relevante pentru configurația Reverse DNS.

Pe un server shared, hostname-ul HELO și PTR-ul pot aparține serverului de hosting și nu domeniului individual al fiecărui client. Acest comportament poate fi perfect normal.

PTR-ul trebuie să fie domeniul de pe care trimiți emailul?

Nu neapărat.

Aceasta este o altă confuzie frecventă.

Să presupunem că trimiți de la:

office@firma-exemplu.ro

Serverul poate utiliza IP-ul:

192.0.2.25

iar PTR-ul acelui IP poate fi:

mail.server-hosting.ro

Acest lucru nu este automat greșit.

Important este ca hostname-ul utilizat pentru infrastructura de email să fie configurat corect și să existe o rezolvare DNS coerentă pentru IP-ul respectiv.

Autorizarea domeniului firma-exemplu.ro pentru trimiterea mesajelor este tratată separat prin mecanisme precum SPF și DKIM.

Ce se întâmplă pe un server de hosting shared?

Pe un serviciu de găzduire shared, mai multe domenii pot trimite email folosind aceeași infrastructură și aceeași adresă IP de ieșire.

O singură adresă IP nu primește câte un PTR diferit pentru fiecare domeniu găzduit.

În mod normal, PTR-ul IP-ului de trimitere indică hostname-ul serverului de email.

Prin urmare, dacă domeniul tău este găzduit pe un server shared, nu trebuie să încerci să modifici PTR-ul serverului astfel încât acesta să devină:

mail.domeniul-meu.ro

doar pentru că trimiți email de pe domeniul respectiv.

Configurarea Reverse DNS a IP-ului shared este administrată la nivelul infrastructurii de hosting.

Dar pe un VPS cu IP dedicat?

Situația este diferită atunci când administrezi un VPS sau un server care trimite email direct folosind o adresă IP dedicată.

În acest caz este important să verifici:

IP VPS → PTR → hostname server
hostname server → A Record → IP VPS

De exemplu:

192.0.2.25 → mail.exemplu.ro
mail.exemplu.ro → 192.0.2.25

Dacă PTR-ul lipsește sau indică spre un hostname greșit, acesta trebuie configurat la nivelul furnizorului care administrează adresa IP.

Dacă serverul sau IP-ul este furnizat de NameBox și ai nevoie de verificarea Reverse DNS, poți solicita echipei tehnice verificarea configurației.

Cum verifici manual un PTR Record?

Pe Linux sau macOS poți verifica Reverse DNS folosind comanda:

dig -x 192.0.2.25 +short

Un rezultat corect poate arăta astfel:

mail.exemplu.ro.

După aceea trebuie verificată și direcția inversă:

dig A mail.exemplu.ro +short

Rezultatul ar trebui să includă IP-ul de trimitere:

192.0.2.25

Adresa 192.0.2.25 este folosită aici doar ca exemplu pentru documentație.

Cum verifici Reverse DNS în Windows?

În Windows poți folosi Command Prompt și comanda:

nslookup 192.0.2.25

Rezultatul ar trebui să indice hostname-ul configurat în PTR.

Apoi poți verifica hostname-ul:

nslookup mail.exemplu.ro

și să confirmi că acesta rezolvă către IP-ul așteptat.

Ce înseamnă dacă IP-ul nu are PTR?

Dacă verificarea Reverse DNS nu returnează niciun hostname, IP-ul poate să nu aibă o înregistrare PTR configurată.

Pentru un server care livrează direct email către alte servere SMTP, aceasta este o problemă care trebuie investigată.

Google solicită IP-urilor care trimit mesaje către Gmail să aibă DNS forward și reverse valid.

În anumite situații, lipsa PTR-ului sau nepotrivirea dintre PTR și forward DNS poate determina limitarea sau respingerea mesajelor.

Ce înseamnă dacă PTR-ul există, dar A Record-ul nu corespunde?

Putem avea o situație precum:

192.0.2.25 → mail.exemplu.ro

dar:

mail.exemplu.ro → 192.0.2.50

În acest caz, rezolvarea inversă și cea directă nu se confirmă reciproc.

Pentru o configurație corectă a serverului de trimitere, hostname-ul returnat de PTR trebuie să rezolve prin A sau AAAA către adresa IP corespunzătoare.

Poți avea mai multe domenii pe același PTR?

Un server de hosting poate administra emailurile pentru sute sau mii de domenii, dar acest lucru nu înseamnă că fiecare domeniu trebuie să fie hostname-ul PTR al serverului.

PTR-ul identifică infrastructura asociată IP-ului.

Domeniile individuale sunt validate prin propriile mecanisme DNS și de autentificare, inclusiv SPF și DKIM.

Această distincție este foarte importantă mai ales pe serviciile de hosting shared.

Reverse DNS și reputația IP-ului sunt lucruri diferite

Un IP poate avea Reverse DNS configurat perfect și totuși să aibă o reputație slabă.

De exemplu, dacă de pe acel IP au fost trimise cantități mari de spam, existența unui PTR nu va elimina automat problemele de livrabilitate.

La fel, un IP care apare pe o blocklist nu este delistat doar pentru că PTR-ul a fost configurat.

Reverse DNS reprezintă o condiție tehnică importantă, însă reputația este construită în timp pe baza modului în care este utilizată infrastructura de email.

Ce trebuie verificat dacă emailurile ajung în Spam?

Dacă mesajele nu sunt livrate corespunzător, nu verifica doar PTR-ul.

În cPanel începe cu:

cPanel → Email → Email Deliverability

Apoi verifică împreună:

• PTR / Reverse DNS pentru IP-ul de trimitere;
• SPF;
• DKIM;
• DMARC;
• hostname-ul serverului;
• Mail HELO;
• IP-ul real prin care mesajul este trimis;
• eventuale blocklist-uri;
• mesajul de eroare returnat de serverul destinatar;
• reputația domeniului și a IP-ului.

Ghidul nostru despre Email Deliverability în cPanel explică verificarea înregistrărilor principale de autentificare.

Reverse DNS nu este același lucru cu MX Record

PTR-ul este uneori confundat cu MX-ul, însă cele două au roluri complet diferite.

MX Record spune ce server trebuie să primească emailurile pentru un domeniu.

PTR Record permite identificarea hostname-ului asociat unei adrese IP.

De exemplu:

MX:
exemplu.ro → mail.exemplu.ro

A:
mail.exemplu.ro → 192.0.2.25

PTR:
192.0.2.25 → mail.exemplu.ro

Pentru o explicație mai amplă despre înregistrările DNS poți consulta articolul Ce este DNS și cum funcționează?.

Întrebări frecvente despre Reverse DNS și PTR

Pot seta PTR Record din cPanel Zone Editor?

În mod normal, nu. PTR-ul este administrat în zona Reverse DNS a adresei IP, iar controlul acesteia aparține de regulă furnizorului sau organizației care administrează IP-ul. cPanel poate însă afișa și verifica informația în Email Deliverability.

Fiecare domeniu trebuie să aibă propriul PTR?

Nu. Pe un server shared, mai multe domenii pot utiliza aceeași adresă IP de trimitere, iar PTR-ul IP-ului poate indica hostname-ul serverului.

Un PTR corect rezolvă problemele cu Spam-ul?

Nu în mod automat. Trebuie verificate și SPF, DKIM, DMARC, reputația IP-ului, reputația domeniului și comportamentul de trimitere.

Este PTR obligatoriu pentru Gmail?

Google solicită expeditorilor care trimit către conturi Gmail să utilizeze înregistrări DNS forward și reverse valide pentru IP-urile de trimitere.

Ce fac dacă PTR-ul serverului este greșit?

Dacă nu deții controlul asupra adresei IP, trebuie contactat furnizorul care administrează IP-ul. Dacă folosești un serviciu NameBox și suspectezi o problemă de Reverse DNS, poți solicita o verificare echipei tehnice.

Un Reverse DNS corect este o piesă din configurația completă de email

Pentru un server care trimite direct email, Reverse DNS trebuie configurat astfel încât IP-ul de trimitere să poată fi asociat unui hostname valid, iar acel hostname să rezolve înapoi către IP-ul corespunzător.

PTR-ul nu înlocuiește SPF, DKIM sau DMARC și nici nu garantează livrarea în Inbox. Este însă o componentă importantă a unei infrastructuri SMTP configurate corect și unul dintre elementele verificate de furnizorii moderni de email.

Dacă întâmpini probleme de livrare, verifică mai întâi Email Deliverability în cPanel și analizează configurația în ansamblu. PTR, SPF, DKIM, DMARC și reputația IP-ului trebuie evaluate împreună înainte de a stabili cauza problemei.

The post Reverse DNS și PTR Record: De ce contează pentru livrarea emailurilor? appeared first on NAMEBOX.