Скорая помощь: сайт лёг после правки .htaccess

Сайт не открывается после правки .htaccess? Без паники. Почти любая проблема решается за 5–10 минут, если действовать по порядку. Начните с первого шага — он же диагностический.

Первый шаг: изолировать причину

Сделайте это прямо сейчас: переименуйте .htaccess в .htaccess.bak (или временно очистите его содержимое) и обновите страницу.

  • Сайт ожил — причина точно в .htaccess. Читайте дальше по симптому ошибки.
  • Сайт не ожил — проблема не в .htaccess. Смотрите error.log PHP, логи базы данных, статус PHP-процесса.

Это правило работает всегда и занимает 30 секунд. Не тратьте час на догадки до этого шага.

Читаем error.log

error.log — главный инструмент: почти всегда там написана точная причина и номер строки .htaccess.

Где найти error.log:

  • cPanel — «Metrics» → «Errors», или файл ~/logs/error_log.
  • ISPmanager — раздел «Журналы» в панели управления.
  • Plesk — «Logs» сайта в панели.
  • VPS / выделенный — /var/log/apache2/error.log (Debian/Ubuntu) или /var/log/httpd/error_log (CentOS/RHEL); для конкретного сайта — путь из директивы ErrorLog в его vhost.

Типовые сообщения и их смысл:

  • Invalid command 'Foo', perhaps misspelled or defined by a module not included — опечатка в директиве или модуль не загружен.
  • … not allowed here — директива запрещена настройкой AllowOverride (см. статья про AllowOverride).
  • Options not allowed here — для Options нужен AllowOverride Options или AllowOverride All.
  • Invalid command 'php_flag' — PHP работает через FPM/FastCGI, а не mod_php; используйте .user.ini.
  • Request exceeded the limit of 10 internal redirects — петля редиректа, см. раздел ниже.

Найдите последнюю строку с именем вашего файла — там точный номер строки и описание проблемы.

500 Internal Server Error

Сервер отдаёт «500 Internal Server Error» — значит Apache нашёл синтаксическую ошибку или недопустимую директиву в .htaccess.

Частые виновники:

  • php_value / php_flag на PHP-FPM: если хостинг использует PHP-FPM (не mod_php), эти директивы дают 500. Замените на .user.ini в корне сайта.
  • Options без AllowOverride Options: хостинг не разрешил менять Options в .htaccess. Уточните у хостинга или уберите директиву.
  • Order / Allow / Deny на Apache 2.4: старый синтаксис Apache 2.2 — используйте Require, или конвертируйте через /apache24/.
  • Директива незагруженного модуля: например, Header set … без mod_headers. Оберните в <IfModule mod_headers.c>…</IfModule>.
  • Битая RewriteRule: несбалансированные скобки, неэкранированные спецсимволы в regex.
  • BOM или CRLF: файл сохранён с BOM (UTF-8 with BOM) или переносами строк Windows CRLF — пересохраните как UTF-8 без BOM, LF.

Метод бинарного поиска — если error.log не указывает точную строку: закомментируйте символом # ровно половину файла, обновите страницу. Если 500 исчезло — проблема в закомментированной половине. Делите снова, пока не найдёте одну строку. При 32 строках — максимум 5 итераций.

Прогоните файл через линтер /check/ — он найдёт опечатки, устаревшие директивы и php_value на FPM.

403 Forbidden

Сервер отвечает «403 Forbidden» — доступ запрещён. Ищите в .htaccess этого каталога и во всех родительских:

  • Require all denied или Deny from all — закрыли больше, чем планировали.
  • Слишком широкий <FilesMatch> — regex зацепил нужный файл.
  • Options -Indexes при запросе к каталогу без index.* — Apache не знает, что отдать.
  • Неверные права на файл или каталог — должно быть 644 на файлы, 755 на каталоги.
  • Require ip … — IP-фильтр не включает ваш текущий адрес (мобильный интернет, VPN, офис).

В error.log ищите client denied by server configuration или AH01797.

ERR_TOO_MANY_REDIRECTS

Браузер пишет «слишком много перенаправлений» — правило тянет само себя в бесконечный круг.

Самая частая причина за CDN или прокси: правило RewriteCond %{HTTPS} off всегда срабатывает, потому что CDN терминирует TLS и передаёт Apache уже HTTP. Правило редиректирует «на https», но снова видит HTTP — и так по кругу.

Решение:

.htaccessкопировать
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

Другие причины петли:

  • Два правила «конфликтуют»: одно добавляет www, другое убирает — каждое запускает второе.
  • Правило без условия-страховки !-f / !-d переписывает само себя.
  • Один и тот же редирект настроен и в .htaccess, и в панели хостинга / CMS — два перенаправления друг за другом.

Откройте DevTools → Network, отфильтруйте по 3xx — видно, кто на кого ведёт.

404 на все страницы кроме главной

Главная открывается, а все остальные адреса (/about/, /blog/123) отдают 404. Это значит, что фронт-контроллер не работает.

Типичные причины:

  • Нет RewriteEngine On — все правила rewrite игнорируются.
  • mod_rewrite не включён на хостинге.
  • Нет правила фронт-контроллера (или оно написано неверно).
  • Неправильный RewriteBase — сайт в подкаталоге, но база не указана.

Правильный фронт-контроллер:

.htaccessкопировать
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]

Без !-f и !-d правило будет перенаправлять и существующие файлы (style.css, картинки) на index.php. Протестируйте конкретный URL в тестере RewriteRule.

Правка вообще не действует

Внесли изменения, а сайт ведёт себя как прежде — ни ошибки, ни нового поведения.

Проверьте по списку:

  • Сервер не Apache: на чистом nginx .htaccess игнорируется полностью. Узнайте тип сервера у хостинга или в phpinfo().
  • AllowOverride None: в конфиге сервера запрещено использовать .htaccess. Типично для VPS с дефолтной конфигурацией Apache.
  • Не тот каталог: файл лежит не в document root или не в той папке, где нужен.
  • Неверное имя файла: Windows прячет расширения — файл может называться .htaccess.txt вместо .htaccess.
  • CDN-кэш: CDN отдаёт старый закэшированный ответ. Сбросьте кэш в панели CDN.

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

Восстановление и профилактика

Восстановить рабочую версию:

  • Верните файл из бэкапа (Git, архив панели хостинга, ручная копия).
  • Если бэкапа нет — возьмите эталонный .htaccess вашей CMS из официальной документации.

Как не попасть в ту же ситуацию:

  • Держите копию рабочего файла: .htaccess.work рядом.
  • Вносите изменения по одному блоку, проверяя после каждого.
  • Перед правкой на боевом сервере: проверьте синтаксис в линтере, объясните себе блок через объяснялку, протестируйте rewrite-правило в тестере.
  • На VPS — используйте apachectl configtest после правки конфигов сервера (не проверяет .htaccess, но ловит ошибки в vhost).