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.
| AWStats | Raw Access Logs |
|---|---|
| Statistici agregate | Request-uri individuale |
| Interfață grafică | Fișier text |
| Util pentru analiza generală | Util pentru investigații detaliate |
| Trafic lunar, zilnic și orar | Data și ora fiecărui request |
| Coduri HTTP și informații despre vizitatori | IP, URL, metodă, status, User-Agent etc. |
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.
| Cod | Semnificație |
|---|---|
| 200 | Request procesat cu succes |
| 301 / 302 | Redirect |
| 403 | Acces refuzat |
| 404 | Resursa solicitată nu există |
| 429 | Prea multe request-uri / rate limiting |
| 500 | Eroare internă a aplicației sau serverului |
| 503 | Serviciu temporar indisponibil |
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.