Кэш в 1С-Битрикс: как устроен и что с ним идёт не так

Кэш в 1С-Битрикс устроен сложнее, чем кажется по кнопке «Очистить кэш» в административной панели. Это четыре независимых механизма, которые живут в разных каталогах, сбрасываются по разным правилам и ломаются каждый по-своему.

Разбираем, что где лежит, из чего складывается ключ кэша и какие сбои встречаются чаще всего — включая тот, из-за которого посетители интернет-магазина однажды увидели оптовые цены.

Четыре слоя и где они лежат

Кэш служебных таблиц ядра. Самый нижний слой, про который почти никто не помнит. Включается константами в bitrix/php_interface/dbconn.php:

define("CACHED_b_file", 3600);
define("CACHED_b_option", 3600);
define("CACHED_b_lang", 3600);
define("CACHED_b_site_template", 3600);
define("CACHED_menu", 3600);

Это кэш файлов, настроек модулей, языков, шаблонов сайта и меню. Если их нет в dbconn.php, ядро на каждом хите ходит в базу за тем, что меняется раз в месяц.

Кэш компонентов. То, что имеют в виду, когда говорят «кэш Битрикса». Лежит в bitrix/cache. Компонент сохраняет результат работы — либо данные, либо готовый HTML — и при следующем вызове отдаёт сохранённое, не обращаясь к базе.

Управляемый кэш. Каталог bitrix/managed_cache. Отличается тем, что сбрасывается сам при изменении данных: ядро знает, какие таблицы участвовали, и чистит связанное. Рядом работает теговый кэш — класс Bitrix\Main\Data\TaggedCache с методами startTagCache, registerTag и clearByTag. Компонент регистрирует теги, а при изменении инфоблока ядро чистит всё, что этим тегом помечено.

HTML-кэш, он же композит. Каталог bitrix/html_pages. Хранит целые страницы и отдаёт их до запуска PHP. Самый быстрый слой и самый опасный с точки зрения персональных данных.

Из чего складывается ключ кэша

Главное, что нужно понимать про кэш компонентов: всё решает ключ. Два вызова с одинаковым ключом получают один результат, с разными — разные.

Ключ собирается в методе getCacheID класса CBitrixComponent и включает:

• идентификатор сайта;
• язык;
• идентификатор шаблона сайта;
• имя компонента и имя его шаблона;
• все параметры компонента, кроме начинающихся с тильды;
• смещение часового пояса, если оно не нулевое.

Посмотрите на этот список ещё раз. Группы пользователя в нём отсутствуют.

Права доступа в ключ не входят по умолчанию

Это не недосмотр, а осознанное решение: если бы кэш всегда разделялся по группам, от него осталась бы малая часть пользы. Поэтому группы добавляются отдельно, компонентом, и управляется это параметром CACHE_GROUPS — в административном интерфейсе он подписан «Учитывать права доступа».

В компонентах каталога это выглядит так:

$this->arParams['CACHE_GROUPS'] === 'N' ? false : $this->getUserGroupsCacheId()

То есть при значении «нет» группы в ключ не попадают, и все посетители получают один и тот же сохранённый результат — независимо от того, что им положено видеть.

Правило из этого простое: если вывод компонента зависит от того, кто смотрит, ключ обязан это учитывать. Иначе первый зашедший наполнит кэш своей версией, и её получат остальные.

Как цены для косметологов попали к анонимам

Случай из нашей практики, сентябрь 2026 года. Интернет-магазин профессиональной косметики, две цены на товар: розничная и для косметологов. Вторая заметно ниже и предназначена только для профессиональной группы.

На одной из посадочных страниц анонимные посетители увидели — и могли купить — по профессиональным ценам. Солнцезащитная пудра: розничная 3970 рублей, профессиональная 2700. Анониму показывали 2430 вместо 3573. На другом товаре разрыв был почти двукратным: 3932 вместо 7096.

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

Дело было в другом. В шаблоне каталога блок «Розничная цена» выводится намеренно только для профессиональной группы: косметологу показывают его цену как основную, а розничную — подписью. Значит, HTML для разных групп получается разный. А блок товаров на посадочной собирался компонентом, которому не передали «Учитывать права доступа». Готовая разметка, собранная под косметологом, досталась анонимным посетителям.

Исправление — одна строка в вызове компонента:

'CACHE_GROUPS' => 'Y',

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

Ошибка в расследовании, которую стоит не повторять: кэш сбросили, проверяя гипотезу, и уничтожили улику — посмотреть содержимое кэш-файлов стало нельзя. При подозрении на утечку сначала ищите по bitrix/cache, и только потом чистите.

Как проверить это у себя за пять минут

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

1. Откройте страницу под пользователем с особыми правами. Дождитесь, пока она закэшируется.
2. Откройте ту же страницу в режиме инкогнито, не авторизуясь.
3. Сравните, что видно. Цены, блоки, кнопки, доступные разделы.

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

grep -rl "Розничная цена" bitrix/cache | head

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

Почему кэш не сбрасывается после правки

Вторая по частоте жалоба: контент-менеджер поменял текст, а на сайте старый.

Причины, по убыванию частоты:

• Компонент кэширует с фиксированным временем и без тегов. Тогда изменение в админке ничего не сбрасывает: кэш доживёт до конца своего срока. Лечится включением тегового кэша или уменьшением времени жизни.
• Правка пришла в обход ядра. Данные, записанные напрямую в базу запросом, ядро не видит и кэш не чистит. То же относится к импорту, который пишет мимо API.
• Страница лежит в композите. Её отдали до запуска PHP, поэтому сброс кэша компонентов ничего не изменил.
• Кэширует не Битрикс. Nginx, внешний кэш-прокси или браузер. Проверяется заголовками ответа, а не сбросом кэша в админке.

Почему кэш иногда вовсе не работает

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

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

Признак простой: каталог bitrix/cache растёт, а скорость не улучшается. Посмотрите, сколько файлов накопилось за сутки.

find bitrix/cache -type f -mtime -1 | wc -l

Для сравнения, на нашем сайте в кэше компонентов лежит около сотни файлов и меньше трёх мегабайт. Если у вас их десятки тысяч, ключ где-то течёт.

Композит и персональные данные

Композит отдаёт готовую страницу до запуска PHP, и в этом его сила: время ответа сокращается многократно. И в этом же риск — на странице не должно быть ничего персонального.

Типичная ошибка — вывести в шапку имя пользователя, содержимое корзины или баланс бонусов и не вынести эти блоки из кэшируемой области. Первый же авторизованный посетитель оставит своё имя в HTML, который потом покажут остальным.

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

Сколько места занимает кэш

Отдельная тема, потому что кэш иногда съедает диск. Полезно знать, что именно смотреть:

du -sh bitrix/cache bitrix/managed_cache bitrix/stack_cache bitrix/html_pages

Нормальный порядок — от единиц до сотен мегабайт в зависимости от размера каталога. Гигабайты означают либо течь в ключе, либо то, что кэш никогда не чистился.

Важно: чистка кэша — не способ освободить место. Он нарастёт обратно за сутки, а пока нарастает, сайт работает медленнее. Если место кончается, искать надо в журналах и резервных копиях — мы разбирали это отдельно.

Что кэшировать нельзя

• Персональные данные. Имя, корзина, бонусы, история заказов, адреса.
• Цены, если они разные для разных групп — либо кэшировать с учётом прав доступа.
• Остатки на складе, если они меняются часто и от них зависит кнопка покупки.
• Результаты, зависящие от текущего времени, если время участвует в выводе: обратный отсчёт акции в кэше остановится.
• Данные, которые видят не все: закрытые разделы, цены для дилеров, документы по договору.

Коротко

• Кэшей четыре: служебные таблицы ядра, компоненты, управляемый с тегами и композит. Кнопка в админке чистит не все.
• Ключ кэша компонента складывается из сайта, языка, шаблона, имени компонента и всех его параметров. Групп пользователя там нет.
• Если вывод зависит от того, кто смотрит, включайте «Учитывать права доступа» — иначе первый зашедший наполнит кэш для всех.
• Проверка на утечку занимает пять минут: открыть страницу под особыми правами, потом в инкогнито и сравнить.
• При подозрении на утечку сначала ищите по файлам кэша, потом чистите: сброс уничтожает улики.
• Растущий кэш без прироста скорости означает течь в ключе, а не нехватку места.

Если не уверены, что у вас на сайте не утекает лишнее, — закажите технический аудит или напишите нам: проверим кэш, права и скорость, а заодно посмотрим, что показывают анонимным посетителям.