urlrewrite.php в 1С-Битрикс и правила nginx: что проверять

Файл urlrewrite.php в 1С-Битрикс отвечает за сопоставление красивых URL с файлами и компонентами. Когда ЧПУ работает нестабильно, часть страниц открывается, часть отдаёт 404, а некоторые URL попадают не в тот компонент. Но сам urlrewrite.php — только один слой. Ещё есть nginx, Apache, .htaccess, document root и порядок правил.

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

Document root должен смотреть в корень сайта

Для Битрикс document root обычно указывает на директорию, где лежат bitrix, upload, local и index.php. Если сервер смотрит не туда, ЧПУ может работать странно или не работать вообще.

root /var/www/site.ru;

Нужно проверить, что по этому пути действительно есть index.php и папка bitrix.

ls -la /var/www/site.ru/index.php
ls -la /var/www/site.ru/bitrix

nginx try_files

Для nginx важно передавать несуществующие физические файлы в index.php, чтобы Битрикс смог применить правила ЧПУ.

location / {
    try_files $uri $uri/ /index.php?$args;
}

Если nginx просто пытается найти файл и отдаёт 404, urlrewrite.php даже не будет использован. В таком случае проблема не в Битрикс, а в конфиге сервера.

Apache и .htaccess

На Apache правила обычно лежат в .htaccess. После переноса на nginx они не применяются автоматически. Если сайт раньше работал на Apache, а теперь на nginx, правила нужно перенести в конфиг nginx.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

На реальных проектах .htaccess может быть сложнее: редиректы, HTTPS, www, старые URL. Переносить его нужно внимательно, а не целиком копировать в nginx.

Структура urlrewrite.php

Файл содержит массив правил. У каждого правила есть CONDITION, RULE, ID и PATH. Порядок правил важен: более общее правило может перехватить URL раньше конкретного.

[
    'CONDITION' => '#^/blog/#',
    'RULE' => '',
    'ID' => 'bitrix:news',
    'PATH' => '/blog/index.php',
],

Если два компонента используют похожие URL, нужно проверить, какое правило стоит выше.

Пересохранение компонента

Иногда после изменения ЧПУ проще пересохранить настройки компонента через публичную часть или админку, чтобы Битрикс обновил правила. Но делать это нужно аккуратно: самописные правки в urlrewrite.php могут быть перезаписаны.

Если в проекте есть кастомные правила, лучше сначала сохранить копию файла.

cp urlrewrite.php urlrewrite.php.bak

Редиректы не должны конфликтовать с ЧПУ

Правила редиректа в nginx или .htaccess могут срабатывать до Битрикс и уводить URL. Например, общее правило добавления слеша может конфликтовать с конкретным адресом.

curl -IL https://example.ru/catalog/product

Если видна длинная цепочка 301, сначала нужно разобраться с редиректами. Иначе кажется, что Битрикс отдаёт 404, хотя запрос уже пришёл на другой URL.

Физические файлы и папки

Если по пути существует физическая директория, сервер может попытаться открыть её напрямую. Например, /catalog/ может быть и папкой, и SEF_FOLDER компонента. Это нормально, если внутри лежит index.php компонента. Но случайные папки могут мешать маршрутизации.

find . -maxdepth 2 -type d -name catalog
ls -la catalog/index.php

Кэш и OPcache

После изменения правил иногда мешает кэш. Битрикс-кэш, композит и OPcache могут создавать впечатление, что правка не применялась.

rm -rf bitrix/cache/*
rm -rf bitrix/managed_cache/*

Если менялся PHP-код и OPcache настроен жёстко, может потребоваться перезапуск PHP-FPM.

Чек-лист проверки

1. Проверить document root.
2. Проверить наличие index.php, bitrix, local и upload.
3. Проверить nginx try_files.
4. Проверить .htaccess, если сайт на Apache.
5. Проверить правила в urlrewrite.php.
6. Проверить порядок похожих правил.
7. Проверить цепочки редиректов через curl -IL.
8. Проверить физические папки, которые совпадают с SEF_FOLDER.
9. Очистить кэш после изменения маршрутов.

urlrewrite.php не стоит воспринимать как единственное место, где ломается ЧПУ. Если сервер не передаёт запрос в Битрикс, файл правил даже не участвует. Поэтому сначала сервер, потом правила, потом компонент.