Очистка кэша 1С-Битрикс: из админки, вручную, через API и cron

Быстрее всего кэш Битрикса сбрасывается из админки: раздел Настройки → Производительность → Автокеширование → вкладка очистки файлов кэша, режим «Все». Если админка не открывается, удалите содержимое папок /bitrix/cache/ и /bitrix/managed_cache/. Сам каталог оставьте, удаляйте только его содержимое.

«1С-Битрикс» — это система управления сайтом, а не платформа 1С:Предприятие. Кэш здесь значит сохранённые готовые куски страниц, результаты запросов к базе и сжатые CSS/JS. Когда после правки шаблона или товара на сайте всё по-старому, виноват почти всегда он.

Ниже способы по возрастанию «радикальности»: от кнопки в панели до скрипта и cron.

Что именно кэшируется и где лежит

Прежде чем что-то удалять, полезно понимать, что вы стираете. В Битриксе несколько независимых слоёв.

Если в настройках проекта кэш вынесен в Memcached или Redis, файлов в /bitrix/cache/ будет мало или совсем не будет. Тип хранилища задан в файле /bitrix/.settings.php в блоке cache. Проверьте его до начала работ, иначе потратите час на удаление пустой папки.

Очистка кэша из административной панели

Это штатный путь. Он безопасен: Битрикс сам решает, какие файлы можно удалять, и не трогает служебные.

Через раздел «Автокеширование»

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

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

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

Быстрый сброс из публичной части

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

Второй вариант — параметр в адресе. Добавьте к URL ?clear_cache=Y, например https://example.ru/catalog/?clear_cache=Y. Работает только для авторизованного администратора и сбрасывает кэш при открытии этой страницы. Для посторонних параметр безвреден.

Кэш в настройках отдельного компонента

У каждого компонента (каталог, новости, меню) есть блок «Кеширование»: тип кэша и время жизни. Варианты:

• 🟢 «Авто + Управляемое» — кэш сам сбрасывается при изменении данных. Оптимальный выбор.
• 🟡 «Кешировать» — живёт заданное время, изменения подхватит не сразу.
• 🔴 «Не кешировать» — каждый заход идёт в базу. Для отладки допустимо, для боя нет.

Если у вас правка есть, а на странице её нет, сначала посмотрите именно сюда.

Свой скрипт очистки на API

Бывает, что админка недоступна, а кэш нужно сбросить из деплоя или по расписанию. Тогда пишут небольшой PHP-файл. Готового cache_cleaner.php в ядре нет: это обычная самописная утилита, поэтому внимательно проверяйте код, который берёте из интернета.

Минимальный вариант, который чистит файловый кэш через ядро:

<?php
// /local/tools/clear_cache.php — запуск только из консоли
if (php_sapi_name() !== 'cli') { exit('CLI only'); }

$_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);                                   // файловый кэш компонентов
\Bitrix\Main\Data\Cache::clearCache(true);            // кэш через D7
\Bitrix\Main\Application::getInstance()
    ->getManagedCache()->cleanAll();                  // управляемый кэш

echo "Кэш сброшен\n";

Запуск: php -f /var/www/site/local/tools/clear_cache.php.

Три момента, на которых спотыкаются:

• Не кладите такой файл в публичную часть сайта без проверки доступа. Любой, кто откроет его по ссылке, сможет сбрасывать кэш и нагружать сервер. Проверка php_sapi_name() в примере закрывает веб-запуск.
• Путь в DOCUMENT_ROOT укажите свой. Из консоли переменной нет, и ядро без неё не стартует.
• Запускайте скрипт под тем же пользователем, под которым работает веб-сервер. Иначе новые файлы кэша получат владельца root, и сайт не сможет их перезаписывать.

Ручное удаление файлов через файловую систему

Нужно, когда админка недоступна из-за ошибки (например, «белый экран» после правки шаблона) или кэш разросся на десятки гигабайт.

Через SSH

Сначала узнайте, сколько места занимает кэш:

du -sh /var/www/site/bitrix/cache /var/www/site/bitrix/managed_cache /var/www/site/bitrix/stack_cache

Затем удалите содержимое папок, не сами папки:

find /var/www/site/bitrix/cache -mindepth 1 -delete
find /var/www/site/bitrix/managed_cache -mindepth 1 -delete
find /var/www/site/bitrix/stack_cache -mindepth 1 -delete

Команда find ... -delete надёжнее rm -rf /путь/*: она не упирается в лимит аргументов, когда файлов сотни тысяч.

Через FTP или панель хостинга

На виртуальном хостинге откройте файловый менеджер, зайдите в bitrix/cache/ и выделите всё внутри. Если файлов очень много, менеджер зависнет. Тогда переименуйте папку в cache_old, создайте пустую cache с теми же правами (обычно 755) и удалите старую по частям или через поддержку хостинга.

Что не удалять

• ❌ Папку /bitrix/ целиком и её подпапки modules, php_interface, admin.
• ❌ Файлы .settings.php и dbconn.php.
• ❌ Папку /upload/ целиком: в ней живут загруженные файлы, и только resize_cache — это кэш.

Управляемый кэш и теги через API

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

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

<?php
// после программного изменения данных инфоблока с ID = 5
\Bitrix\Main\Application::getInstance()
    ->getTaggedCache()->clearByTag('iblock_id_5');

Тег вида iblock_id_N Битрикс создаёт для компонентов, работающих с инфоблоком. Для одного элемента используется iblock_id_N вместе со своими внутренними тегами, поэтому надёжнее сбрасывать инфоблок целиком.

Если вы пишете свой компонент, вешайте теги сами. Шаблон такой: начало кэша, startTagCache, регистрация тега, endTagCache. Тогда ваш кэш сбросится вместе с инфоблоком без ручной чистки.

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

Автоматическая очистка по расписанию через cron

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

Отредактируйте расписание пользователя веб-сервера: crontab -e -u www-data.

# каждую ночь в 03:30 удалять файлы кэша старше суток
30 3 * * * find /var/www/site/bitrix/cache -type f -mtime +1 -delete

# раз в неделю убирать пустые папки
0 4 * * 0 find /var/www/site/bitrix/cache -mindepth 1 -type d -empty -delete

Второй вариант — вызывать ваш скрипт из прошлого раздела:

0 4 * * * /usr/bin/php -f /var/www/site/local/tools/clear_cache.php >> /var/log/bx_cache.log 2>&1

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

Прогрев кэша после сброса

Прогрев — это обход основных страниц, чтобы первые настоящие посетители не ждали. Простейший вариант: файл со списком адресов (главная, разделы каталога, топ-20 карточек) и цикл на bash.

while read -r url; do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s $url\n" "$url"
  sleep 1
done < /var/www/site/local/tools/warmup_urls.txt

Пауза в секунду нужна, чтобы прогрев сам не положил слабый сервер. Колонка с временем ответа заодно покажет, какие страницы тяжёлые и без кэша работают хуже всего. Запускайте скрипт сразу после ночной очистки, например в 04:10.

Если после очистки ничего не изменилось

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

Другие слои, которые тоже держат старое

• 🌐 Браузер. Откройте страницу в режиме инкогнито или обновите через Ctrl+F5.
• 🧱 Композитный сайт. Если он включён, страницы лежат в /bitrix/html_pages/. Очистите их отдельно в настройках композитного режима.
• 🚀 OPcache. PHP держит скомпилированные файлы в памяти. После выкладки нового PHP-кода перезапустите php-fpm или сбросьте OPcache.
• 🛡 Nginx и CDN. Статика и страницы могут кэшироваться на проксирующем уровне. Сбросьте кэш там (в панели CDN или командой очистки каталога proxy_cache).

Типичные проблемы

После любых ручных действий с правами проверьте, что сайт может писать в папки кэша. Иначе он будет работать «в обход» кэша и медленно.

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