Какво представляват директориите `www` и `public_html` във вашия хостинг акаунт?
Директорията `public_html` е основната директория на документи на вашия уебсайт — папката от страна на сървъра, от която вашият уеб сървър (Apache, Nginx, LiteSpeed) чете и обслужва всички публично достъпни файлове, когато посетител зарежда вашия домейн. Директорията `www`, в повечето споделени и базирани на cPanel среди, е просто символна връзка (symlink), сочеща към `public_html`, съществуваща за историческа съвместимост, а не като независимо място за съхранение.
Разбирането на това разграничение не е козметично. Неправилното поставяне на файлове извън `public_html`, неправилното конфигуриране на основната директория на документи или неразбирането на връзката symlink може да доведе до неуспешни внедрявания, грешки 403 Forbidden или непреднамерено публично излагане на чувствителни конфигурационни файлове.
Ролята на `public_html` като основна директория на документи
Когато HTTP заявка достигне до вашия сървър, демонът на уеб сървъра проверява конфигурацията си, за да определи коя директория съответства на заявения домейн. Тази директория се нарича основна директория на документи. На практически всички среди за споделен хостинг и повечето конфигурации на VPS Хостинг, работещи с cPanel или подобни контролни панели, тази основна директория на документи е `public_html`.
Абсолютният път на типичен cPanel сървър изглежда така:
“`
/home/username/public_html/
“`
Всеки файл, поставен в тази директория, става публично достъпен чрез вашия домейн. Съответствието е пряко:
| Път на файла на сървъра | Публичен URL |
|---|---|
| — | — |
| `/home/user/public_html/index.html` | `https://example.com/` |
| `/home/user/public_html/about.html` | `https://example.com/about.html` |
| `/home/user/public_html/images/logo.png` | `https://example.com/images/logo.png` |
| `/home/user/public_html/blog/post-1.php` | `https://example.com/blog/post-1.php` |
| `/home/user/secret-config.php` *(извън public_html)* | Недостъпен чрез браузър |
Последният ред е от решаващо значение. Файловете, поставени над `public_html` в дървото на директориите — директно в `/home/username/` — са невидими за уеб сървъра и не могат да бъдат извлечени чрез HTTP. Това е правилното място за чувствителни файлове като идентификационни данни за база данни, файлове `.env` и API ключове, които вашето приложение чете по време на изпълнение, но никога не трябва да бъдат обслужвани публично.
Файлове с индекс по подразбиране и разрешаване на директории
Когато посетител заявява URL адрес на директория (напр. `https://example.com/`), уеб сървърът търси файл с индекс по подразбиране в тази директория. Стандартният ред на разрешаване в директивата `DirectoryIndex` на Apache обикновено е:
“`
index.html > index.htm > index.php > index.cgi
“`
Ако нито един от тези файлове не съществува и списъкът на директориите не е изрично забранен, сървърът може да върне 403 Forbidden или да разкрие списък на директориите — значителен риск за сигурността. Винаги се уверявайте, че съществува валиден индексен файл или че `Options -Indexes` е зададен във вашия `.htaccess`.
Какво всъщност представлява директорията `www`
Директорията `www` е POSIX символна връзка, а не реална директория със собствен inode и разпределение на съхранение. Можете да проверите това на всеки базиран на Linux сървър:
“`bash
ls -la ~/
“`
Изходът ще покаже нещо подобно:
“`
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` в началото на низа с разрешения и стрелката `-> public_html` потвърждават, че е symlink. Това означава:
- `www` и `public_html` споделят абсолютно едни и същи данни на inode
- Записването на файл в `~/www/contact.html` е идентично на записването му в `~/public_html/contact.html`
- Изтриването на `www` не изтрива `public_html` или нейното съдържание
- Пресъздаването на symlink е тривиално: `ln -s ~/public_html ~/www`
Защо съществува symlink `www`
Symlink `www` е наследствен артефакт с практически корени. В ранните Unix-базирани хостинг среди конвенцията беше да се съхранява уеб съдържание в директория, буквално наречена `www` — отразявайки префикса на поддомейна `www.`, който стана повсеместен през 90-те години. Тъй като cPanel стандартизира `public_html` като името на основната директория на документи, symlink `www` беше запазен, за да се избегне нарушаването на:
- По-стари скриптове за внедряване, твърдо кодирани да записват в `~/www/`
- FTP клиенти и файлови мениджъри, очакващи папка `www`
- Документация и ръководства, посочващи `www` като целта за качване
За всички практически цели в съвременна среда трябва да третирате `public_html` като каноничното местоположение и да игнорирате `www` изцяло.
`public_html` срещу `www`: Пряко сравнение
| Атрибут | `public_html` | `www` |
|---|---|---|
| — | — | — |
| Тип | Реална директория | Символна връзка |
| Действителна основна директория на документи | Да | Не (сочи към `public_html`) |
| Съдържа файлове независимо | Да | Не (споделя inode-ите на `public_html`) |
| Може да бъде изтрита безопасно | Не (нарушава сайта) | Да (сайтът продължава да работи) |
| Присъства при всички видове хостинг | Да | Не е гарантирано |
| Препоръчителна цел за качване | Да | Не се препоръчва |
| Съществува при VPS/персонализирани настройки | Конфигурируемо | Рядко, освен ако не е създадено ръчно |
Структура на директориите вътре в `public_html`
Добре организираната директория `public_html` разделя ясно отговорностите. Ето реалистична за производствена среда структура за PHP-базиран сайт или инсталация на 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
“`
Критична бележка за сигурността: `wp-config.php` съдържа идентификационни данни за база данни. WordPress поддържа поставянето на този файл една директория над `public_html` (`/home/username/wp-config.php`), където е недостъпен чрез HTTP, но все още може да бъде прочетен от PHP. Това е най-добра практика за укрепване на сигурността, която много администратори пренебрегват.
Как поддомейните и добавените домейни разширяват тази структура
Когато създавате поддомейн или добавен домейн чрез Контролни панели за VPS или cPanel, хостинг системата създава нова основна директория на документи — или вътре в `public_html`, или като паралелна директория на същото ниво.
Основни директории на документи за поддомейни
“`
/home/username/public_html/blog/ → blog.example.com
/home/username/public_html/shop/ → shop.example.com
“`
Или, при някои конфигурации на cPanel:
“`
/home/username/blog.example.com/ → blog.example.com
“`
Основни директории на документи за добавени домейни
“`
/home/username/public_html/newdomain/ → newdomain.com
“`
Или като паралелен елемент на най-горно ниво:
“`
/home/username/newdomain.com/ → newdomain.com
“`
Точният път зависи от конфигурацията на вашия хостинг панел. Винаги проверявайте основната директория на документи в cPanel под Домейни > Поддомейни или Добавени домейни, за да избегнете качването на файлове на грешното място.
Разлики в поведението при различни хостинг среди
Споделен хостинг (cPanel)
При Споделен уеб хостинг с cPanel структурата е стандартизирана:
- Основна директория на документи: `/home/username/public_html/`
- Symlink `www`: присъства по подразбиране
- Apache с поддръжка на `.htaccess`: активирана
- Множество домейни: всеки получава своя поддиректория или паралелна папка
VPS и выделени сървъри
На Выделен сървър или самоуправляван VPS, основната директория на документи се определя изцяло от администратора в конфигурацията на уеб сървъра. Общи конвенции:
Apache Virtual Host (`/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>
“`
Nginx Server Block (`/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;
}
“`
В тези среди `public_html` е конвенция за именуване, а не техническо изискване. Основната директория на документи може да се казва каквото и да е — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — стига конфигурацията на уеб сървъра да сочи към нея. Symlink `www` обикновено не съществува, освен ако не го създадете ръчно.
cPanel VPS
VPS с cPanel съчетава гъвкавостта на VPS със стандартизираната структура `public_html` на споделения хостинг, което го прави най-разпространената среда, в която `www` и `public_html` съществуват едновременно точно така, както е описано в тази статия.
Разрешения за файлове: Често пренебрегвано изискване
Неправилните разрешения са една от най-честите причини за грешки 403 Forbidden и неуспешни внедрявания. Стандартният модел на разрешения за уеб достъпни файлове:
| Ресурс | Препоръчително разрешение | Осмично |
|---|---|---|
| — | — | — |
| Директории | Четене + Изпълнение за собственик и група | `755` |
| PHP/HTML файлове | Четене/Запис за собственик, Четене за останалите | `644` |
| Конфигурационни файлове (`.env`, идентификационни данни) | Само за собственик | `600` |
| Изпълними скриптове | Само изпълнение за собственик | `700` |
Задайте разрешенията рекурсивно с:
“`bash
find ~/public_html -type d -exec chmod 755 {} ;
find ~/public_html -type f -exec chmod 644 {} ;
“`
Никога не задавайте `777` на никой файл или директория в производствена среда. Това предоставя достъп за запис на всички системни потребители и е пряк вектор за компрометиране на сървъра.
SSL, HTTPS и основната директория на документи
Когато инсталирате SSL Сертификат на вашия домейн, сертификатът се свързва с името на домейна, а не с конкретна директория. Въпреки това конфигурацията на HTTPS виртуалния хост трябва да сочи към същата основна директория на документи `public_html` като HTTP конфигурацията. Несъответствие — при което HTTP обслужва от една директория, а HTTPS от друга — води до непоследователно поведение, което е известно с трудността си за диагностициране.
Ако използвате Let’s Encrypt чрез Certbot, процесът на верификация на ACME предизвикателството поставя временни файлове в `public_html/.well-known/acme-challenge/`. Уверете се, че този път не е блокиран от правила `.htaccess` или блокове `location` на Nginx, които отказват достъп до скрити директории (тези, започващи с `.`).
Практически контролен списък с ключови изводи
Преди качването на вашия сайт:
- Потвърдете точния път на основната директория на документи в хостинг панела си — не приемайте, че винаги е `/home/username/public_html/`
- Проверете дали `www` е symlink, а не отделна директория, за да избегнете дублирано управление на файлове
- Преместете чувствителните конфигурационни файлове (`.env`, идентификационни данни за база данни) над `public_html`
По време на внедряването:
- Задайте разрешения на директориите `755` и разрешения на файловете `644`
- Уверете се, че `index.html` или `index.php` съществува в основната директория на документи, за да предотвратите листване на директории
- Деактивирайте `Options Indexes` в `.htaccess` като мярка за задълбочена защита
За настройки с множество домейни:
- Потвърдете основната директория на документи за всеки поддомейн и добавен домейн поотделно
- Не приемайте, че всички домейни споделят едно и също `public_html`
При VPS и выделени среди:
- Дефинирайте изрично основната директория на документи в конфигурацията на виртуалния хост или сървърния блок
- Symlink `www` не съществува по подразбиране — създайте го само ако наследствени скриптове го изискват
- Рестартирайте уеб сървъра след всяка промяна в конфигурацията: `systemctl reload apache2` или `systemctl reload nginx`
За укрепване на сигурността:
- Никога не съхранявайте API ключове, файлове `.env` или конфигурации на база данни вътре в `public_html`
- Периодично проверявайте `public_html` за неочаквани файлове, особено в директории `uploads/`
- Уверете се, че вашият SSL виртуален хост сочи към същата основна директория на документи като HTTP конфигурацията
Често задавани въпроси
Какво се случва, ако изтрия директорията `www`?
Ако `www` е символна връзка (каквато е практически при всички cPanel среди), изтриването й няма никакъв ефект върху вашия уебсайт или неговите файлове. Сайтът ви продължава да функционира нормално, тъй като действителното съдържание се намира в `public_html`. Можете да пресъздадете symlink по всяко време с `ln -s ~/public_html ~/www`.
Мога ли да преименувам `public_html` на нещо друго?
При споделен хостинг — не, контролният панел е твърдо кодиран да използва `public_html` като основна директория на документи. При самоуправляван VPS или выделен сървър можете да наречете основната директория на документи каквото искате, при условие че актуализирате конфигурацията на уеб сървъра (`DocumentRoot` в Apache, `root` в Nginx), за да съответства.
Защо получавам грешка 403 Forbidden, въпреки че файловете ми са в `public_html`?
Най-честите причини са неправилни разрешения за файлове (файловете се нуждаят от поне `644`, директориите се нуждаят от `755`), липсващ индексен файл при деактивирано листване на директории или правило `.htaccess`, блокиращо достъпа. Проверете журнала за грешки на уеб сървъра (`/var/log/apache2/error.log` или `/var/log/nginx/error.log`) за конкретната причина.
Къде трябва да съхранявам файлове, които PHP трябва да чете, но не трябва да бъдат публично достъпни?
Поставете ги в директория над `public_html`, като например `/home/username/private/` или директно в `/home/username/`. PHP може да чете файлове навсякъде във файловата система, до която потребителят на уеб сървъра има разрешение за достъп, но уеб сървърът няма да обслужва файлове извън основната директория на документи чрез HTTP.
Поддомейнът `www` функционира ли по различен начин от домейна без www на ниво сървър?
Не. И `www.example.com`, и `example.com` се разрешават към същата основна директория на документи чрез DNS конфигурация и настройки на виртуалния хост. Директорията `www` symlink във файловата система е несвързана с DNS поддомейна `www.` — те са отделни концепции, които случайно споделят едни и същи три букви.
