Что такое директория `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` обычно не существует, если вы не создадите её вручную.

VPS с cPanel

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 помещает временные файлы в `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`
• Периодически проверяйте `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.` — это отдельные концепции, которые случайно используют одни и те же три буквы.