#Что означает проблема
Если после переноса сайта работают обычные HTML-файлы, но перестали действовать человекопонятные адреса, ограничения доступа или переадресации из .htaccess, проверьте прежде всего новую физическую директорию и AllowOverride. По умолчанию Apache 2.4 может не читать .htaccess вообще. Если всё работает через Nginx, сначала убедитесь, что запрос вообще доходит до Apache: Nginx не обрабатывает .htaccess.
#Как различить причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Новая папка не совпадает с DirectoryПеренесён DocumentRoot, но блок <Directory> остался привязан к старой папке. | Новый сайт отдаёт файлы, однако его .htaccess не действует. | Найти эффективный путь DocumentRoot и подходящий <Directory>. |
| AllowOverride NoneДля нужной директории отключено чтение файлов .htaccess либо разрешена недостаточная группа директив. | В журнале нет ошибок синтаксиса, но RewriteRule не срабатывает. | Включить только необходимый класс директив, обычно FileInfo для переадресаций. |
| Модуль или уровень прокси отличаетсяНа новом сервере не включён mod_rewrite или URL обслуживает Nginx. | Другие директивы .htaccess действуют, а RewriteRule — нет; либо Apache не получает запрос. | Проверить модуль и реальную цепочку обработки. |
#Подробная диагностика и устранение
- Выясните, какая программа отвечает на запросОткройте на компьютере страницу сайта, затем средства разработчика браузера клавишей F12 → вкладка «Сеть». Обновите страницу и запишите URL и HTTP-статус. На сервере по SSH проверьте логи Apache за ту же минуту; если записей нет, запрос мог завершиться на Nginx, CDN или другом сервере. В такой конфигурации не стоит начинать с правки .htaccess — установите реальный обработчик адреса.
- Посмотрите активный виртуальный хостВ SSH-терминале Debian/Ubuntu выполните
sudo apache2ctl -S. Это чтение конфигурации, сайты не перезапускаются. В выводе найдите домен, IP:порт, путь и номер строки VirtualHost. На других системах команда может называтьсяapachectl -Sилиhttpd -S. Если домен отсутствует, сначала исправьте подключение виртуального хоста, а не .htaccess. - Проверьте DocumentRoot и фактическое расположение файлаОткройте найденный файл настройки с правами администратора только для чтения, найдите
DocumentRoot. В SSH вызовитеsudo ls -la /var/www/example/public/— замените каталог своим, взятым из настройки, и убедитесь, что виден.htaccess. Наличие файла в старом каталоге не помогает новому DocumentRoot. Если владелец и разрешения неизвестны, не меняйте их массово: сначала уточните права каждого уровня каталога. - Найдите действующий AllowOverride именно для каталогаВ конфигурации найдите блоки
<Directory ...>для новой папки, её родителей и правила в более специфичных каталогах. Для правил RewriteRule нуженAllowOverride FileInfo(или иной явно разрешающий RewriteRule вариант).AllowOverride Noneозначает, что .htaccess игнорируется. Не ставьте повсюдуAllowOverride All: это разрешает гораздо больше классов изменений и может нарушить политику хостинга. - Убедитесь в наличии модуля rewriteВ SSH выполните
sudo apache2ctl -Mи найдитеrewrite_module. Если модуль отсутствует и проект использует RewriteRule, в Debian/Ubuntu штатно включите егоsudo a2enmod rewriteтолько после согласования с администратором и резервного копирования конфигурации. Команда изменяет список активных модулей; на системах вне Debian её нет. До применения обязательно выполните проверку синтаксиса. - Сохраните копию и разрешите нужные директивыСкопируйте конкретный конфигурационный файл, который управляет этим VirtualHost, в ту же папку с расширением
.bak. В относящемся к новому DocumentRoot блоке<Directory>задайте точечныйAllowOverride FileInfo, если .htaccess содержит только допустимые директивы из этой группы. Для AuthConfig/Options нужны отдельные права, не расширяйте их без анализа строк файла. Учитывайте, что панели управления могут перегенерировать настройки; в таком случае изменяйте предоставляемый панелью шаблон. - Проверьте настройки и примените их без разрыва запросовВыполните
sudo apache2ctl configtest. Нормальный результат —Syntax OK; при другой строке ничего не применяйте, исправьте указанный файл. При успешном тесте в Debian/Ubuntu выполнитеsudo systemctl reload apache2; на других ОС служба может называться httpd. Если после изменения появилась 500, первым делом читайте error.log: теперь Apache мог начать разбирать ошибочный .htaccess. Откат — вернуть резервную копию и повторить проверку и reload. - Проверьте отдельное правило, а не только главнуюОткройте заранее известный вложенный адрес, для которого есть правило .htaccess, и сравните код и конечный URL до и после исправления. Дополнительно проверьте страницу с закрытым доступом — она не должна оказаться публичной. Если адрес по-прежнему не работает, проверьте порядок более специфичных Directory/Location и сам синтаксис RewriteRule; не отключайте защиту для диагностики.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Как проверить результат
Исправление подтверждено, если указанные правила работают в нужном виртуальном хосте, а запрещённые адреса остались защищены. Apache сообщает Syntax OK, после запроса нет новых сообщений об ошибке .htaccess.
#Если проблема не устранена
Если .htaccess найден и разрешён, но эффект отсутствует, сопоставьте точный URL с журналами Apache и Nginx, проверьте наличие mod_rewrite, относительный путь в Directory и конфигурацию самой панели хостинга. При ошибке 500 восстановите прежний VirtualHost и передайте обезличенную строку error.log специалисту.