Файл .htaccess: что в нём настраивают и почему nginx его не читает

Файл .htaccess — это конфигурация веб-сервера Apache для одного каталога: в нём задают перенаправления, закрывают доступ, ставят пароли и свои страницы ошибок. Работает он только на Apache. На nginx, включая наш сайт cimes.ru, этот файл не читается, и те же правила нужно писать в основной конфигурации.

Что такое файл .htaccess?

.htaccess — файл с директивами Apache, который лежит в обычной папке сайта. Через него задают параметры веб-сервера для отдельного каталога без изменения главного конфигурационного файла. Директивы из файла действуют на каталог, в котором он лежит, и на его дочерние каталоги. Синтаксис тот же, что и в главной конфигурации.

Название расшифровывается как «распределённая конфигурация»: настройки разбросаны по папкам сайта, а не собраны в одном файле. Точка в начале имени означает скрытый файл в системах семейства Unix, поэтому в проводнике он может быть не виден: включите показ скрытых файлов.

Файл особенно удобен там, где владелец сайта не администрирует сервер и не может править его главную конфигурацию. Отсюда популярность на виртуальном хостинге: провайдеры, как правило, разрешают использовать .htaccess, и правила для своей папки владелец сайта задаёт сам.

.htaccess даёт владельцу сайта рычаг на сервере, к настройкам которого у него нет доступа. Это функция Apache, а не универсальный файл настроек сайта.

Что в .htaccess обычно настраивают

Чаще всего в файле лежат правила пяти типов. Любое из них можно перенести в другую конфигурацию, но синтаксис будет другим:

• Постоянные перенаправления — отправляют старый адрес на новый с кодом 301.
• Закрытый доступ — запрет для отдельных файлов, каталогов или IP-адресов: конфигурационные файлы, служебные папки, панель управления.
• Пароль на каталог — базовая HTTP-аутентификация для закрытых разделов и тестовых версий сайта.
• Свои страницы ошибок — страница 404 в стиле сайта вместо серой заглушки сервера.
• Правила для адресов CMS — все запросы к несуществующим файлам передаются в index.php, чтобы работали человекочитаемые адреса.

Типичный пример для Apache:

Redirect 301 /old-page/ https://site.ru/new-page/

<Files "config.php">
    Require all denied
</Files>

ErrorDocument 404 /404.html

Первая строка переносит страницу, вторая закрывает файл настроек, третья подключает свою страницу ошибки.

Почему правила в .htaccess иногда не срабатывают

Самая частая причина — Apache вообще не читает файл. Можно ли использовать .htaccess в каталоге, задаётся в основной конфигурации сервера директивой AllowOverride. На хостингах это обычно уже разрешено, на собственном сервере разрешение включают руками в основной конфигурации.

Вторая причина — директива не разрешена в .htaccess или написана с ошибкой. Тогда сервер выдаёт 500 на всех страницах каталога, и объяснение лежит в журнале ошибок Apache: там сказано, что директива здесь не разрешена или в её синтаксисе опечатка. Поэтому после каждой правки открывайте сайт и держите под рукой копию прежнего файла.

Третья причина — сервер вообще не Apache. Об этом отдельный раздел.

Почему на nginx файл .htaccess не работает

nginx не ищет файлы настроек в папках сайта. Вся его конфигурация собрана в основном файле и в подключаемых к нему, а правила применяются после перечитывания: по документации nginx, для этого главному процессу посылают сигнал HUP, и он сначала проверяет синтаксис новой конфигурации. Аналога распределённых файлов у nginx нет, поэтому .htaccess в папке сайта остаётся обычным файлом, который сервер не интерпретирует.

Наш сайт cimes.ru работает именно на nginx. Правила в .htaccess там не действуют: перенаправления и закрытый доступ живут в конфигурации сервера и в коде самой CMS. Это нормально для сайта на собственном или управляемом сервере, но ловушка для тех, кто взял готовое решение с инструкцией «добавьте в .htaccess» и поставил его на nginx.

Признаки такой ловушки: перенаправление из инструкции не срабатывает, но и ошибок нет; закрытый файл по-прежнему открывается; человекочитаемые адреса CMS дают 404. Первым делом выясните, на каком сервере работает сайт. Заголовок Server в ответе curl -I https://site.ru/ иногда показывает его, но многие хостинги заголовок скрывают, и тогда надёжнее спросить поддержку.

Факт. По документации nginx, чтобы сервер перечитал конфигурацию, главному процессу посылают сигнал HUP, а перед применением он проверяет её синтаксис. Файлы в папках сайта в этой схеме не участвуют.

Есть и обратный риск. Если на nginx остался файл .htaccess с настройками доступа, сервер правил не применяет, а сам файл остаётся доступным как обычный. Закройте к нему доступ директивой deny или удалите, когда перенесли правила.

Чем заменить каждую настройку в nginx?

Задачи те же, меняются директивы и место, где они лежат. Соответствие для самых частых случаев:

Каждая строка таблицы опирается на документацию. Директива return в nginx возвращает код, а для 301, 302, 303, 307 и 308 принимает адрес перенаправления. Модуль access ограничивает доступ для определённых адресов клиентов, auth_basic проверяет имя и пароль. Директива error_page задаёт адрес, который показывается при указанных ошибках, а try_files проверяет существование файлов по порядку и использует первый найденный.

Тот же пример, что выше, но для nginx:

server {
    server_name site.ru;

    location = /old-page/ {
        return 301 https://site.ru/new-page/;
    }

    location = /config.php {
        deny all;
    }

    error_page 404 /404.html;
}

Блок целиком кладут в конфигурацию виртуального сервера. После правки проверяют синтаксис и перечитывают конфигурацию: ошибка в ней не уронит сайт, потому что nginx откатится к старой версии. На хостингах с панелью управления эти правила обычно задают через раздел дополнительных директив nginx, а не через файл в папке сайта.

Что лучше: .htaccess или основная конфигурация?

Если есть доступ к основной конфигурации, правила удобнее держать в ней. Причины две — порядок и безопасность.

С порядком всё просто: когда настройки собраны в одном месте, их легче прочитать, проверить и перенести, а не искать по вложенным папкам сайта. С безопасностью тоже: каждый, кто может править .htaccess, меняет настройки сервера для своего каталога.

Мнение. Если сайт на собственном сервере или VPS, переносите правила из .htaccess в основную конфигурацию и отключайте AllowOverride. Если сайт на дешёвом виртуальном хостинге без доступа к настройкам, .htaccess остаётся единственным рабочим вариантом, и пользоваться им нормально.

Честная граница: для небольшого сайта на хостинге разница невелика, и главным аргументом остаётся контроль над настройками.

Как проверить, что правила работают?

Проверять нужно ответ сервера, а не внешний вид страницы: браузер кэширует перенаправления, и старое поведение может обмануть. Порядок такой:

Если правило молчит на Apache, проверьте AllowOverride. Если молчит на nginx, убедитесь, что правило лежит в конфигурации, а конфигурация перечитана.

Что делать при переносе с Apache на nginx

Перенос сайта между серверами ломает именно то, что жило в .htaccess: перенаправления, закрытые папки, адреса CMS. Чтобы не потерять их, действуйте по списку:

Подробнее о том, как не потерять трафик при смене сервера, в материале про перенос сайта на другой хостинг. Если нужно установить сайт на хостинг и настроить сервер, этим занимаются специалисты студии: услуга установки сайта на хостинг.

Источники

• .htaccess — Википедия
• Управление nginx — nginx
• Модуль ngx_http_rewrite_module — nginx
• Модуль ngx_http_core_module — nginx
• Модуль ngx_http_access_module — nginx
• Модуль ngx_http_auth_basic_module — nginx