Що таке директорія `www` та `public_html` у вашому хостинговому акаунті?

Директорія `public_html` є кореневою директорією документів вашого вебсайту — серверною папкою, з якої ваш вебсервер (Apache, Nginx, LiteSpeed) зчитує та обслуговує всі публічно доступні файли, коли відвідувач завантажує ваш домен. Директорія `www` у більшості спільних середовищ та середовищ на основі cPanel є просто символічним посиланням (symlink), що вказує на `public_html`, і існує для історичної сумісності, а не як незалежне місце зберігання.

Розуміння цього розрізнення не є косметичним. Неправильне розміщення файлів за межами `public_html`, неправильне налаштування кореневої директорії документів або нерозуміння відносин символічного посилання може призвести до зламаних розгортань, помилок 403 Forbidden або ненавмисного публічного розкриття конфіденційних файлів конфігурації.

Роль `public_html` як кореневої директорії документів

Коли HTTP-запит надходить на ваш сервер, демон вебсервера звертається до своєї конфігурації, щоб визначити, яка директорія відповідає запитуваному домену. Ця директорія називається кореневою директорією документів. Практично у всіх середовищах спільного хостингу та більшості конфігурацій VPS Хостингу, що працюють на cPanel або подібних панелях керування, ця коренева директорія документів — `public_html`.

Абсолютний шлях на типовому сервері cPanel виглядає так:

“`

/home/username/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 або відкрити список директорій — що є значним ризиком безпеки. Завжди переконуйтеся, що або існує дійсний файл індексу, або в `.htaccess` встановлено `Options -Indexes`.

Що насправді являє собою директорія `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` підтверджують, що це символічне посилання. Це означає:

• `www` та `public_html` мають абсолютно однакові дані inode
• Запис файлу до `~/www/contact.html` ідентичний запису до `~/public_html/contact.html`
• Видалення `www` не видаляє `public_html` або будь-який з його вмістів
• Відтворення символічного посилання є тривіальним: `ln -s ~/public_html ~/www`

Чому існує символічне посилання `www`

Символічне посилання `www` є застарілим артефактом з практичним корінням. У ранніх середовищах хостингу на основі Unix конвенція полягала у зберіганні вебвмісту в директорії, буквально названій `www` — відображаючи префікс субдомену `www.`, який став повсюдним у 1990-х роках. Коли cPanel стандартизував `public_html` як назву кореневої директорії документів, символічне посилання `www` було збережено, щоб уникнути порушення роботи:

• Старіших скриптів розгортання, жорстко закодованих для запису до `~/www/`
• FTP-клієнтів та файлових менеджерів, які очікували папку `www`
• Документації та посібників, що посилаються на `www` як на ціль завантаження

Для всіх практичних цілей у сучасному середовищі слід вважати `public_html` канонічним місцем і повністю ігнорувати `www`.

`public_html` проти `www`: пряме порівняння

Структура директорій всередині `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/`
• Символічне посилання `www`: присутнє за замовчуванням
• Apache з підтримкою `.htaccess`: увімкнено
• Кілька доменів: кожен отримує власну піддиректорію або паралельну папку

VPS та виділені сервери

На Виділеному сервері або самокерованому VPS коренева директорія документів повністю визначається адміністратором у конфігурації вебсервера. Поширені конвенції:

Віртуальний хост 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>

“`

Серверний блок 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;

}

“`

У цих середовищах `public_html` є конвенцією іменування, а не технічною вимогою. Коренева директорія документів може мати будь-яку назву — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — за умови, що конфігурація вебсервера вказує на неї. Символічне посилання `www` зазвичай не існує, якщо ви не створите його вручну.

cPanel VPS

VPS з cPanel поєднує гнучкість VPS зі стандартизованою структурою `public_html` спільного хостингу, що робить його найпоширенішим середовищем, де `www` та `public_html` співіснують саме так, як описано в цій статті.

Права доступу до файлів: часто ігнорована вимога

Неправильні права доступу є однією з найпоширеніших причин помилок 403 Forbidden та невдалих розгортань. Стандартна модель прав доступу для файлів, доступних через вебсервер:

Встановіть права доступу рекурсивно за допомогою:

“`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 challenge розміщує тимчасові файли в `public_html/.well-known/acme-challenge/`. Переконайтеся, що цей шлях не заблоковано правилами `.htaccess` або блоками `location` Nginx, які забороняють доступ до прихованих директорій (тих, що починаються з `.`).

Практичний контрольний список ключових висновків

Перед завантаженням вашого сайту:

• Підтвердьте точний шлях до кореневої директорії документів у вашій панелі хостингу — не припускайте, що це завжди `/home/username/public_html/`
• Перевірте, що `www` є символічним посиланням, а не окремою директорією, щоб уникнути дублювання управління файлами
• Перемістіть конфіденційні файли конфігурації (`.env`, облікові дані бази даних) вище `public_html`

Під час розгортання:

• Встановіть права доступу до директорій `755` та права доступу до файлів `644`
• Переконайтеся, що в кореневій директорії документів існує `index.html` або `index.php` для запобігання перегляду директорій
• Вимкніть `Options Indexes` у `.htaccess` як захід глибокого захисту

Для налаштувань з кількома доменами:

• Підтвердьте кореневу директорію документів для кожного субдомену та додаткового домену окремо
• Не припускайте, що всі домени мають спільну `public_html`

На VPS та виділених середовищах:

• Явно визначте кореневу директорію документів у конфігурації вашого віртуального хосту або серверного блоку
• Символічне посилання `www` не існує за замовчуванням — створюйте його лише якщо цього вимагають застарілі скрипти
• Перезапустіть вебсервер після будь-яких змін конфігурації: `systemctl reload apache2` або `systemctl reload nginx`

Для посилення безпеки:

• Ніколи не зберігайте API-ключі, файли `.env` або конфігурації бази даних всередині `public_html`
• Periodically audit `public_html` на наявність несподіваних файлів, особливо в директоріях `uploads/`
• Переконайтеся, що ваш SSL віртуальний хост вказує на ту саму кореневу директорію документів, що й конфігурація HTTP

Часті запитання

Що станеться, якщо я видалю директорію `www`?

Якщо `www` є символічним посиланням (а це так практично у всіх середовищах cPanel), його видалення не впливає на ваш вебсайт або його файли. Ваш сайт продовжує нормально функціонувати, оскільки фактичний вміст знаходиться в `public_html`. Ви можете відтворити символічне посилання будь-коли за допомогою `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` — символічне посилання у файловій системі — не пов’язана з субдоменом DNS `www.` — це окремі концепції, які випадково мають однакові три літери.