Кэш в 1С-Битрикс кэширует почти всё - компоненты, HTML-страницы, результаты запросов к базе, обработанные шаблоны. Когда я меняю логику компонента или структуру инфоблока, а изменения не появляются на сайте, первым делом нужно очистить кэш Битрикс, и только потом искать баг в коде. За несколько лет работы с проектами на этой платформе я перепробовал все способы: кнопку в админке, ручное удаление файлов по SSH, вызов API из кода. Ниже разбираю, какой способ выбрать в конкретной ситуации и какие грабли меня поджидали.
Какие виды кэша использует 1С-Битрикс
Прежде чем чистить кэш Битрикс, стоит понимать, что это не единый механизм, а несколько независимых слоёв. Каждый хранится отдельно и очищается своими методами.
- Управляемый кэш (Managed Cache) - кэширует данные с тегами, привязанными к инфоблокам, разделам, группам. Именно он чаще всего «залипает» после правки настроек торгового каталога.
- Автокэш компонентов - результат работы компонента при параметре CACHE_TYPE, равном «A» или «Y». Хранится по хэшу входных параметров компонента.
- HTML-кэш (кэш целых страниц) - используется редко, включается вручную для статичных разделов вроде каталога без персонализации.
- Стек-кэш - кэш часто запрашиваемых мелких данных, живёт в памяти процесса и частично в файлах.
- Кэш файлов и папок - обслуживает агрегацию CSS/JS и ресайз картинок в upload/resize_cache.
Понимание этой карты экономит часы отладки: если правка в компоненте не отражается на сайте, не обязательно чистить всё, сначала стоит сообразить, какой именно слой кэша отвечает за то место, куда вносились изменения.
Физически всё это лежит в нескольких папках: bitrix/cache, bitrix/managed_cache, bitrix/stack_cache, bitrix/html_pages. Разработчику полезно помнить, где что хранится, потому что «очистить кэш» в интерфейсе и «удалить файлы кэша» на сервере не всегда одно и то же действие.
| Тип кэша | Где физически хранится | Когда чистить отдельно |
|---|---|---|
| Управляемый кэш | bitrix/managed_cache | После смены настроек инфоблоков, торгового каталога, модуля СДЭК |
| Автокэш компонентов | bitrix/cache | После правки шаблона компонента или логики .php-файла |
| HTML-кэш | bitrix/html_pages | После изменения статичного контента с включённым полным кэшированием страниц |
| Стек-кэш | bitrix/stack_cache | При сбоях меню и навигации, которые не сбрасываются обычной очисткой |
| Кэш файлов и картинок | upload/resize_cache | После смены логотипа или шаблона ресайза изображений |
Как очистить кэш Битрикс через административный интерфейс
Самый безопасный способ для человека без доступа к серверу. Раздел находится в Настройки > Инструменты > Очистка кэша (файл cache_clean.php в админке). Там чекбоксами отмечаются нужные типы: Кэш, Управляемый кэш, Автокэш компонентов, Стек кэш, HTML-кэш.
Я обычно не ставлю галочку «выбрать всё» на боевых проектах с заметным трафиком. Один раз чистил кэш маркетплейса целиком в разгар распродажи, сайт лёг на полминуты, потому что кэш нужно было заново собрать одновременно для тысяч конкурентных запросов к каталогу. С тех пор чищу точечно: если правил только карточку товара, снимаю галочку с HTML-кэша и стек-кэша, трогаю только управляемый кэш и автокэш компонентов.
Ещё один быстрый вариант - значок молнии рядом с адресной строкой публичной части, он появляется, если включён режим отладки. По клику он сбрасывает кэш конкретной страницы, не трогая остальной сайт, и это удобно, когда нужно проверить правку в одном разделе, не пересобирая кэш каталога целиком.
Право чистить кэш через эту форму завязано на группу пользователей с доступом к модулю «Технические возможности». На некоторых договорах поддержки клиенту специально урезают этот доступ, чтобы разработчик контролировал, когда и как часто выполняется полный сброс на боевом сервере.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Ручная очистка кэша Битрикс через файлы на сервере
Через SSH это нужно, когда админка недоступна: битый деплой положил публичную часть, а сайт всё равно продолжает отдавать старые страницы из кэша. В таком случае иду напрямую в файловую систему.
cd /home/bitrix/www
rm -rf bitrix/cache/*
rm -rf bitrix/managed_cache/*
rm -rf bitrix/stack_cache/*
rm -rf bitrix/html_pages/*Важная деталь: удаляю содержимое папок, а не сами папки. Если снести директорию bitrix/cache целиком, Битрикс пересоздаст её при следующем обращении, но на высоконагруженном проекте первые запросы после этого могут упасть с ошибкой прав доступа, если веб-сервер и php-fpm работают от разных пользователей. Проще держать структуру папок на месте и чистить только их содержимое.
После такой очистки обязательно проверяю права на созданные заново файлы. У меня был случай, когда после ручной чистки через root часть кэша начала создаваться с правами root, а php-fpm под своим пользователем не мог их перезаписывать, и сайт вставал в получастичный отказ на конкретных разделах каталога.
На каталоге в 15-20 тысяч товаров папка bitrix/managed_cache легко разрастается до нескольких гигабайт мелких файлов, и команда очистки на таком объёме может выполняться не мгновенно, а десятки секунд. Это стоит учитывать, если чистка встроена в скрипт деплоя с жёстким таймаутом.
Сброс кэша Битрикс кодом: BXClearCache и Cache API
Из кода кэш чистится через функцию BXClearCache, доступную в любом месте после подключения ядра.
<?php
// полный сброс управляемого кэша и автокэша компонентов
BXClearCache(true);Параметр true заставляет сбросить и управляемый кэш вместе с обычным. Если передать false, очистится только файловый кэш компонентов, а теги останутся нетронутыми, иногда это то, что нужно, если правки не затрагивали инфоблоки.
Для точечного сброса удобнее работать через теги, не трогая весь кэш сайта целиком.
<?php
use Bitrix\Main\Application;
$taggedCache = Application::getInstance()->getTaggedCache();
$taggedCache->clearByTag('iblock_id_' . $iblockId);С таким подходом я разбирался на проекте с интеграцией СДЭК: после изменения тарифной зоны стоимость доставки в корзине оставалась старой, хотя настройки на сайте уже поменялись. Полный сброс кэша решал проблему, но заодно пересобирал кэш всего каталога на несколько секунд под нагрузкой. В итоге завёл отдельный тег на кэш расчёта доставки и чищу теперь только его при изменении тарифов, не трогая карточки товаров и разделы.
На старых проектах, не переведённых на архитектуру D7, вместо нового Cache API встречается глобальный объект $CACHE_MANAGER с методами CleanDir и Clean. Работает он с теми же физическими файлами, просто через другой интерфейс, доставшийся от более ранних версий ядра.
Кэш PHP и внешних хранилищ: opcache, memcached, Redis
Отдельная и частая путаница: кэш Битрикс и кэш байткода PHP - это разные вещи. Если на сервере включён opcache, после деплоя новой версии кода через git старый байткод может продолжать выполняться, даже если файлы кэша Битрикс уже пустые.
<?php
if (function_exists('opcache_reset')) {
opcache_reset();
}Либо перезапуск сервиса на сервере: systemctl reload php8.1-fpm. Я держу сброс opcache отдельным пунктом чек-листа деплоя, потому что несколько раз видел, как разработчик чистит кэш Битрикс через админку, а правки в коде компонента всё равно не применяются, именно из-за неперезагруженного opcache.
Если в .settings.php прописано внешнее хранилище кэша (memcached или Redis вместо файлового), очистка папок bitrix/cache вообще ничего не даёт, данные лежат не в файлах. В этом случае кэш чистится либо через ту же кнопку в админке, либо командой на сервере. Для memcached это flush_all через telnet или nc, для Redis команда сброса другая: FLUSHDB чистит только текущую базу, а FLUSHALL все базы разом. Если на том же Redis висят очереди или сессии из другого сервиса, лучше выбирать FLUSHDB, а не выкашивать всё подряд.
Автоматизация очистки кэша при деплое
На проектах с регулярными релизами очистка кэша вручную после каждого деплоя быстро надоедает и норовит забыться в самый неподходящий момент. Обычно я включаю сброс кэша прямо в шаг деплоя: после git pull на сервере скрипт вызывает удаление нужных папок кэша и следом дергает opcache_reset через отдельный защищённый токеном PHP-эндпоинт.
Для проектов, где деплой запускается не вручную, а через внешний оркестратор, такой же шаг легко добавить в n8n: HTTP-запрос от репозитория при пуше в основную ветку триггерит workflow, тот подключается по SSH к серверу, выполняет очистку кэша и следом дергает эндпоинт с opcache_reset. Получается, что разработчик один раз настраивает пайплайн, а дальше кэш сбрасывается сам при каждом релизе, без ручных действий. Если деплой на бою до сих пор происходит вручную и очистка кэша каждый раз ложится на плечи разработчика, есть смысл автоматизировать процесс деплоя и сопровождения сайта на Битрикс.
На одном проекте с ботом на aiogram для внутренних уведомлений я цеплял в конец скрипта деплоя отправку сообщения в Telegram-канал команды о том, что кэш очищен и деплой завершён. Мелочь, но она избавила от вопросов в духе «а точно почистили» в общем чате.
Ещё один рабочий вариант для крупных каталогов - ночной агент Битрикс (CAgent), который сам раз в сутки чистит управляемый кэш в часы низкой нагрузки, не дожидаясь, пока папки кэша разрастутся до десятков тысяч мелких файлов и начнут тормозить файловую систему на операциях чтения директории.
Частые ошибки при очистке кэша Битрикс
Самая частая ошибка, которую я вижу у начинающих разработчиков, чистка всего кэша целиком там, где хватило бы точечного сброса по тегу. На небольшом сайте разницы не заметно, а вот на каталоге в несколько тысяч товаров с высокой посещаемостью полная пересборка кэша под живым трафиком заметно нагружает базу и процессор в момент пика.
Вторая по частоте, забытый opcache. Разработчик правит код компонента, чистит кэш Битрикс через админку, видит, что ничего не изменилось, и начинает искать несуществующий баг в логике, хотя дело в закэшированном байткоде на сервере.
Третья ошибка, удаление кэша не туда, где реально идёт запись. Если в .settings.php настроено внешнее хранилище, а разработчик по привычке чистит папки на диске, эффекта не будет вообще, потому что данные лежат в другом месте.
Четвёртая ошибка, о которой часто забывают, - очистка кэша сразу на нескольких серверах при балансировке нагрузки. Если сайт крутится на двух-трёх бэкендах за балансировщиком, а кэш файловый и локальный для каждого сервера, очистка на одном из них не уберёт устаревшие данные на соседних. Нужен скрипт, который проходится по всем нодам одновременно, либо общее сетевое хранилище кэша.
Частые вопросы
Как быстро очистить кэш Битрикс без доступа к админке?
Через SSH удалить содержимое папок bitrix/cache, bitrix/managed_cache и bitrix/stack_cache, а затем сбросить opcache функцией opcache_reset или перезапуском php-fpm. Это тот же результат, что даёт кнопка в админке, просто выполненный руками на файловой системе.
Нужно ли очищать кэш после каждого обновления модуля?
Да, обновление модуля почти всегда меняет шаблоны компонентов и структуру данных, поэтому старый управляемый кэш и автокэш компонентов стоит сбросить сразу после обновления, не дожидаясь жалоб пользователей на устаревший контент.
Почему после очистки кэша сайт стал медленнее?
Это нормально для первых минут: кэш пуст, и каждая страница собирается заново с обращением к базе данных. На высоконагруженном проекте лучше чистить кэш не полностью и не в часы пик, а точечно по нужным тегам, чтобы не пересобирать весь каталог одновременно.
Чем отличается очистка кэша Битрикс от очистки cookies у пользователя?
Кэш Битрикс живёт на сервере и одинаков для всех посетителей, а cookies хранятся в браузере конкретного пользователя и отвечают за его сессию, авторизацию, содержимое корзины. Проблемы с устаревшим контентом решает серверный кэш, а не просьба к клиенту почистить cookies.