Ce este directorul `www` și `public_html` în contul tău de hosting?

Directorul `public_html` este rădăcina documentelor a site-ului dvs. — folderul de pe server din care serverul dvs. web (Apache, Nginx, LiteSpeed) citește și servește toate fișierele accesibile public atunci când un vizitator încarcă domeniul dvs. Directorul `www`, în majoritatea mediilor shared și bazate pe cPanel, este pur și simplu un link simbolic (symlink) care indică spre `public_html`, existând pentru compatibilitate istorică, nu ca o locație de stocare independentă.

Înțelegerea acestei distincții nu este cosmetică. Plasarea greșită a fișierelor în afara `public_html`, configurarea incorectă a rădăcinii documentelor sau neînțelegerea relației symlink poate duce la implementări defectuoase, erori 403 Forbidden sau expunerea publică neintențională a fișierelor de configurare sensibile.

Rolul `public_html` ca Rădăcină a Documentelor

Când o cerere HTTP ajunge la serverul dvs., daemonul serverului web consultă configurația sa pentru a determina ce director corespunde domeniului solicitat. Acel director se numește rădăcina documentelor. În practic toate mediile de shared hosting și în majoritatea configurațiilor VPS Hosting care rulează cPanel sau panouri de control similare, acea rădăcină a documentelor este `public_html`.

Calea absolută pe un server cPanel tipic arată astfel:

“`

/home/username/public_html/

“`

Orice fișier plasat în acest director devine accesibil public prin domeniul dvs. Maparea este directă:

Ultimul rând este critic. Fișierele plasate deasupra `public_html` în arborele de directoare — direct în `/home/username/` — sunt invizibile pentru serverul web și nu pot fi accesate prin HTTP. Aceasta este locația corectă pentru fișierele sensibile, cum ar fi credențialele bazei de date, fișierele `.env` și cheile API pe care aplicația dvs. le citește la runtime, dar care nu trebuie niciodată servite public.

Fișierele Index Implicite și Rezolvarea Directoarelor

Când un vizitator solicită un URL de director (ex., `https://example.com/`), serverul web caută un fișier index implicit în acel director. Ordinea standard de rezolvare în directiva `DirectoryIndex` a Apache este de obicei:

“`

index.html > index.htm > index.php > index.cgi

“`

Dacă niciunul dintre aceste fișiere nu există și listarea directoarelor nu este dezactivată explicit, serverul poate returna un 403 Forbidden sau poate expune o listare a directoarelor — un risc de securitate semnificativ. Asigurați-vă întotdeauna că există un fișier index valid sau că `Options -Indexes` este setat în `.htaccess`.

Ce Este de Fapt Directorul `www`

Directorul `www` este un link simbolic POSIX, nu un director real cu propriul inode și alocare de stocare. Puteți verifica acest lucru pe orice server bazat pe Linux:

“`bash

ls -la ~/

“`

Rezultatul va arăta ceva de genul:

“`

lrwxrwxrwx 1 user user 10 Jan 15 09:22 www -> public_html

drwxr-xr-x 12 user user 4096 Jan 15 09:22 public_html

“`

`l` la începutul șirului de permisiuni și săgeata `-> public_html` confirmă că este un symlink. Aceasta înseamnă:

• `www` și `public_html` partajează exact aceleași date inode
• Scrierea unui fișier în `~/www/contact.html` este identică cu scrierea lui în `~/public_html/contact.html`
• Ștergerea `www` nu șterge `public_html` sau niciunul dintre conținuturile sale
• Recrearea symlink-ului este simplă: `ln -s ~/public_html ~/www`

De Ce Există Symlink-ul `www`

Symlink-ul `www` este un artefact legacy cu rădăcini practice. În mediile de hosting timpurii bazate pe Unix, convenția era de a stoca conținutul web într-un director numit literal `www` — oglindind prefixul subdomeniului `www.` care a devenit ubicuu în anii 1990. Pe măsură ce cPanel a standardizat `public_html` ca nume al rădăcinii documentelor, symlink-ul `www` a fost păstrat pentru a evita întreruperea:

• Scripturilor de implementare mai vechi codificate să scrie în `~/www/`
• Clienților FTP și managerilor de fișiere care așteptau un folder `www`
• Documentației și tutorialelor care referențiau `www` ca țintă de încărcare

În toate scopurile practice într-un mediu modern, ar trebui să tratați `public_html` ca locație canonică și să ignorați complet `www`.

`public_html` vs `www`: Comparație Directă

Structura Directoarelor în Interiorul `public_html`

Un director `public_html` bine organizat separă clar responsabilitățile. Iată o structură realistă pentru producție pentru un site bazat pe PHP sau o instalare WordPress:

“`

public_html/

├── index.php

├── .htaccess

├── wp-config.php ← WordPress config (ideally moved one level up)

├── wp-content/

│ ├── themes/

│ ├── plugins/

│ └── uploads/

├── assets/

│ ├── css/

│ ├── js/

│ └── images/

└── sitemap.xml

“`

Notă critică de securitate: `wp-config.php` conține credențialele bazei de date. WordPress suportă plasarea acestui fișier cu un director deasupra `public_html` (`/home/username/wp-config.php`), unde este inaccesibil prin HTTP, dar poate fi citit în continuare de PHP. Aceasta este o bună practică de întărire a securității pe care mulți administratori o ignoră.

Cum Extind Subdomeniile și Domeniile Add-on Această Structură

Când creați un subdomeniu sau un domeniu add-on prin Panouri de Control VPS sau cPanel, sistemul de hosting creează o nouă rădăcină a documentelor — fie în interiorul `public_html`, fie ca un director paralel la același nivel.

Rădăcinile Documentelor pentru Subdomenii

“`

/home/username/public_html/blog/ → blog.example.com

/home/username/public_html/shop/ → shop.example.com

“`

Sau, în unele configurații cPanel:

“`

/home/username/blog.example.com/ → blog.example.com

“`

Rădăcinile Documentelor pentru Domenii Add-on

“`

/home/username/public_html/newdomain/ → newdomain.com

“`

Sau ca un frate de nivel superior:

“`

/home/username/newdomain.com/ → newdomain.com

“`

Calea exactă depinde de configurația panoului dvs. de hosting. Verificați întotdeauna rădăcina documentelor în cPanel sub Domenii > Subdomenii sau Domenii Addon pentru a evita încărcarea fișierelor în locul greșit.

Diferențe de Comportament între Mediile de Hosting

Shared Hosting (cPanel)

Pe Web Hosting Shared cu cPanel, structura este standardizată:

• Rădăcina documentelor: `/home/username/public_html/`
• Symlink `www`: prezent implicit
• Apache cu suport `.htaccess`: activat
• Domenii multiple: fiecare primește propriul subdirector sau folder paralel

Servere VPS și Dedicate

Pe un Server Dedicat sau VPS auto-administrat, rădăcina documentelor este definită în întregime de administrator în configurația serverului web. Convenții comune:

Virtual Host Apache (`/etc/apache2/sites-available/example.com.conf`):

“`apache

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

DocumentRoot /var/www/example.com/public_html

</VirtualHost>

“`

Bloc Server Nginx (`/etc/nginx/sites-available/example.com`):

“`nginx

server {

listen 80;

server_name example.com www.example.com;

root /var/www/example.com/public_html;

index index.php index.html;

}

“`

În aceste medii, `public_html` este o convenție de denumire, nu o cerință tehnică. Rădăcina documentelor poate fi numită orice — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — atâta timp cât configurația serverului web indică spre ea. Symlink-ul `www` de obicei nu există dacă nu îl creați manual.

VPS cPanel

Un VPS cu cPanel combină flexibilitatea unui VPS cu structura standardizată `public_html` a shared hosting-ului, făcându-l cel mai comun mediu în care atât `www` cât și `public_html` coexistă exact așa cum este descris în acest articol.

Permisiunile Fișierelor: O Cerință Frecvent Neglijată

Permisiunile incorecte sunt una dintre cele mai frecvente cauze ale erorilor 403 Forbidden și ale implementărilor eșuate. Modelul standard de permisiuni pentru fișierele accesibile web:

Setați permisiunile recursiv cu:

“`bash

find ~/public_html -type d -exec chmod 755 {} ;

find ~/public_html -type f -exec chmod 644 {} ;

“`

Nu setați niciodată `777` pe niciun fișier sau director într-un mediu de producție. Aceasta acordă acces de scriere tuturor utilizatorilor sistemului și reprezintă un vector direct pentru compromiterea serverului.

SSL, HTTPS și Rădăcina Documentelor

Când instalați un Certificat SSL pe domeniul dvs., certificatul se leagă de numele domeniului, nu de un director specific. Cu toate acestea, configurația virtual host HTTPS trebuie să indice spre aceeași rădăcină a documentelor `public_html` ca și configurația HTTP. O nepotrivire — unde HTTP servește dintr-un director și HTTPS din altul — produce un comportament inconsistent care este notorioriu de dificil de diagnosticat.

Dacă utilizați Let’s Encrypt prin Certbot, procesul de verificare a provocării ACME plasează fișiere temporare în `public_html/.well-known/acme-challenge/`. Asigurați-vă că această cale nu este blocată de regulile `.htaccess` sau de blocurile `location` Nginx care refuză accesul la directoarele ascunse (cele care încep cu `.`).

Listă de Verificare Practică cu Puncte Cheie

Înainte de a încărca site-ul dvs.:

• Confirmați calea exactă a rădăcinii documentelor în panoul dvs. de hosting — nu presupuneți că este întotdeauna `/home/username/public_html/`
• Verificați că `www` este un symlink, nu un director separat, pentru a evita gestionarea duplicată a fișierelor
• Mutați fișierele de configurare sensibile (`.env`, credențiale bază de date) deasupra `public_html`

În timpul implementării:

• Setați permisiunile directoarelor la `755` și permisiunile fișierelor la `644`
• Asigurați-vă că există un `index.html` sau `index.php` la rădăcina documentelor pentru a preveni listarea directoarelor
• Dezactivați `Options Indexes` în `.htaccess` ca măsură de apărare în profunzime

Pentru configurații cu mai multe domenii:

• Confirmați rădăcina documentelor pentru fiecare subdomeniu și domeniu add-on individual
• Nu presupuneți că toate domeniile partajează același `public_html`

Pe medii VPS și dedicate:

• Definiți rădăcina documentelor explicit în configurația virtual host sau a blocului server
• Symlink-ul `www` nu există implicit — creați-l doar dacă scripturile legacy îl necesită
• Reporniți serverul web după orice modificare de configurare: `systemctl reload apache2` sau `systemctl reload nginx`

Pentru întărirea securității:

• Nu stocați niciodată chei API, fișiere `.env` sau configurații de baze de date în interiorul `public_html`
• Auditați periodic `public_html` pentru fișiere neașteptate, în special în directoarele `uploads/`
• Asigurați-vă că virtual host-ul dvs. SSL indică spre aceeași rădăcină a documentelor ca și configurația HTTP

Întrebări Frecvente

Ce se întâmplă dacă șterg directorul `www`?

Dacă `www` este un link simbolic (ceea ce este în practic toate mediile cPanel), ștergerea lui nu are niciun efect asupra site-ului dvs. sau a fișierelor sale. Site-ul dvs. continuă să funcționeze normal deoarece conținutul actual se află în `public_html`. Puteți recrea symlink-ul oricând cu `ln -s ~/public_html ~/www`.

Pot redenumi `public_html` în altceva?

Pe shared hosting, nu — panoul de control este codificat să folosească `public_html` ca rădăcină a documentelor. Pe un VPS auto-administrat sau server dedicat, puteți numi rădăcina documentelor orice doriți, cu condiția să actualizați configurația serverului web (`DocumentRoot` în Apache, `root` în Nginx) pentru a corespunde.

De ce primesc o eroare 403 Forbidden chiar dacă fișierele mele sunt în `public_html`?

Cele mai frecvente cauze sunt permisiunile incorecte ale fișierelor (fișierele necesită cel puțin `644`, directoarele necesită `755`), un fișier index lipsă cu listarea directoarelor dezactivată, sau o regulă `.htaccess` care blochează accesul. Verificați jurnalul de erori al serverului web (`/var/log/apache2/error.log` sau `/var/log/nginx/error.log`) pentru motivul specific.

Unde ar trebui să stochez fișierele pe care PHP trebuie să le citească, dar care nu ar trebui să fie accesibile public?

Plasați-le într-un director deasupra `public_html`, cum ar fi `/home/username/private/` sau direct în `/home/username/`. PHP poate citi fișiere oriunde pe sistemul de fișiere la care utilizatorul serverului web are permisiunea de acces, dar serverul web nu va servi fișiere din afara rădăcinii documentelor prin HTTP.

Funcționează subdomenul `www` diferit față de domeniul non-www la nivelul serverului?

Nu. Atât `www.example.com` cât și `example.com` sunt rezolvate la aceeași rădăcină a documentelor prin configurația DNS și setările virtual host. Symlink-ul directorului `www` de pe sistemul de fișiere nu are legătură cu subdomenul DNS `www.` — sunt concepte separate care se întâmplă să partajeze aceleași trei litere.