Очистка кэша в Битрикс: из админки, скриптом и вручную

Правите шаблон или цену, обновляете страницу, а на сайте всё по-старому. В Битриксе так бывает постоянно: движок складывает готовые результаты компонентов в кэш и отдаёт их, пока время жизни не истечёт. Сбросить кэш можно за минуту: Настройки → Производительность → Управление кешем → Очистить кеш.

Если в админку не попасть или нужна автоматика, есть ещё скрипт, удаление папок и сброс по расписанию. Ниже все способы от безопасного к жёсткому и разбор ситуаций, когда кэш сброшен, а изменений всё равно не видно.

Какие кэши есть в Битриксе и что именно сбрасывается

Прежде чем жать кнопку, полезно понимать, что за слои у вас работают. От этого зависит, какой способ подойдёт.

Первые три слоя сбрасываются обычной очисткой. Композитные страницы, ресайз картинок, память сервера и браузер приходится трогать отдельно. Этот момент чаще всего и объясняет жалобу «я очистил, а ничего не поменялось».

Сброс через административную панель

Это основной способ, ломать им нечего.

1. Войдите в админку под администратором: /bitrix/admin/.
2. Откройте Настройки → Производительность → Управление кешем. Прямой адрес страницы: /bitrix/admin/cache.php.
3. Перейдите на вкладку очистки и выберите, что удалять: весь кэш или только устаревшие файлы.
4. Нажмите кнопку очистки и дождитесь сообщения о завершении.

Названия вкладок и пунктов немного отличаются в зависимости от версии продукта. Ищите на странице кнопку с очисткой кэша, а не точный текст.

Быстрый сброс одного компонента

В режиме правки на публичной части есть кнопка сброса кэша текущей страницы. Она удаляет кэш только тех компонентов, что стоят на открытой странице. Для точечной правки (поменяли один блок) этого хватает, и сайт не тормозит после полной очистки.

Включение и отключение кэширования

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

Скрипт для сброса кэша на PHP

Когда админка недоступна (ошибка в шаблоне, белый экран) или сброс нужен из кода, например после импорта товаров, используют PHP.

Самый простой вариант: файл clear_cache.php в корне сайта.

<?php
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

global $USER;
if (!$USER->IsAdmin()) {
    die("Доступ закрыт");
}

BXClearCache(true);
$GLOBALS["CACHE_MANAGER"]->CleanAll();
$stackCache = new \CStackCacheManager();
$stackCache->CleanAll();

echo "Кэш очищен";

Откройте https://ваш-сайт/clear_cache.php под администратором. Проверка IsAdmin() обязательна: без неё любой посетитель сможет сбрасывать кэш и нагружать сервер.

Сброс в обработчике своего кода

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

\Bitrix\Main\Application::getInstance()
    ->getTaggedCache()
    ->clearByTag("iblock_id_5");

Число после iblock_id_ это ID вашего инфоблока. Так кэш обновляется только у компонентов, показывающих данные из него. Остальной сайт остаётся быстрым.

Удаление файлов кэша вручную

Работает, даже когда сломан весь PHP. Нужен доступ по FTP или SSH.

1. Откройте папку /bitrix/cache/ и удалите её содержимое. Саму папку не трогайте.
2. То же сделайте с /bitrix/managed_cache/ и /bitrix/stack_cache/.
3. Для картинок при необходимости очистите /upload/resize_cache/. Они пересоздаются при обращении, но на большом каталоге это долго.
4. Откройте сайт и проверьте, что страницы строятся.

На сервере по SSH проще так (путь подставьте свой):

cd /var/www/site/bitrix
rm -rf cache/* managed_cache/* stack_cache/*

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

Если кэш лежит в Memcached или Redis

Файловая очистка тут не поможет: данные хранятся в памяти. Сбросить их можно из админки (она знает, куда писать) или командой сервера. Для Redis это FLUSHDB в нужной базе. Учтите, что если на том же Redis хранятся сессии, они тоже пропадут, и пользователей выбросит из личных кабинетов.

Командная строка для опытных пользователей

Ядро Битрикса умеет работать из консоли, и это удобно в деплое: сборка прошла, кэш сбросили, сайт обновился без захода в админку.

Типовой подход: небольшой PHP-скрипт, который подключает ядро без веб-сервера, и вызов его из консоли.

<?php
$_SERVER["DOCUMENT_ROOT"] = "/var/www/site";
define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS", true);
define("BX_NO_ACCELERATOR_RESET", true);

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

BXClearCache(true);
$GLOBALS["CACHE_MANAGER"]->CleanAll();

echo "OK\n";

Запуск: php /var/www/site/local/tools/clear_cache.php. Такой файл лучше держать вне публичной части (в local/tools/ закройте доступ из веба) или за пределами корня сайта.

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

Автоматический сброс: по событиям и по расписанию

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

Время жизни кэша в компонентах

В настройках компонента задаётся Время кеширования (сек.). По истечении оно обновится само. Ориентиры:

• 🕐 новости и статьи: 3600 секунд (час);
• 🛒 каталог товаров с ценами: 300–1800 секунд;
• 📄 статичные страницы: 86400 секунд (сутки) и больше.

Выше значение быстрее сайт, но дольше задержка до появления правок.

Автообновление при изменении данных

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

Периодическая очистка по cron

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

0 4 * * * www-data php /var/www/site/local/tools/clear_cache.php >/dev/null 2>&1

Запись означает: каждый день в 4:00 запустить скрипт от пользователя www-data. Подставьте пользователя вашего веб-сервера.

Кэш сброшен, а правки не видны: разбор причин

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

Как проверить, что кэш вообще работает

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

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

Чего не делать при очистке кэша

Несколько ошибок, которые встречаются снова и снова:

• ❌ Удалять папку /bitrix/ целиком или её подпапки, кроме перечисленных кэшей. Там лежит ядро, и без него сайт не поднимется.
• ❌ Чистить /upload/ целиком. В ней лежат загруженные файлы, фото товаров и документы клиентов. Безопасная часть здесь только resize_cache.
• ❌ Оставлять на боевом сайте отключённое кэширование «чтобы не мучиться».
• ❌ Запускать консольный скрипт от root на сервере, где сайт работает под другим пользователем.
• ❌ Делать полный сброс в разгар рабочего дня на нагруженном магазине.

Частые вопросы