Сессии в Битрикс: блок session в .settings.php (database и проверка)

Сессии в Битрикс по умолчанию часто живут в файлах. На нескольких вебах или при высокой нагрузке это даёт гонки, «вылет» из админки и странные CSRF. Нормальный путь — явно описать блок session в /bitrix/.settings.php (или в /.settings.php проекта) и держать сессии в БД или Redis.

Ниже — рабочая замена блока, отличие mode, типовые грабли и как проверить, что настройка реально подхватилась.

Где править

Основной файл — /bitrix/.settings.php. Если используете переопределения проекта, смотрите также /.settings.php в корне (не путать с dbconn.php). После правки нужен сброс PHP opcache / перезагрузка php-fpm, иначе старый массив настроек может жить в памяти воркера.

Сессии в базе (типовой вариант)

Подходит для одного сервера и небольших кластеров без отдельного Redis:

'session' => [
    'value' => [
        'mode' => 'default',
        'handlers' => [
            'general' => [
                'type' => 'database',
            ],
        ],
    ],
],

type => database переводит хранение в таблицы ядра (сессии читаются/пишутся через механизм Битрикс). Это убирает зависимость от общей session.save_path на диске между нодами — при условии, что все ноды смотрят в одну БД.

Redis / Memcached

На BitrixVM и высоконагруженных витринах чаще выносят сессии в Redis. Конкретный handler зависит от версии ядра и окружения; идея та же — не файлы на локальном диске каждой ноды. Если Redis уже подключён для кэша (см. Redis для кэша в Битрикс), уточните у хостера/в документации VM актуальный блок handlers под вашу сборку — копировать «с форума 2018 года» опасно.

mode: default и separated

В современных ядрах встречается режим раздельных сессий (публичка / админка). Если в проекте уже стоит mode => 'separated', не откатывайте его «на глаз» только ради database-handler — сначала поймите, зачем его включали (безопасность админки, разные lifetime). Меняйте handler, сохраняя нужный mode.

Что проверить после правки

1. Залогиньтесь в админку, откройте два раздела в соседних вкладках — сессия не должна «отваливаться» сразу.
2. На кластере повторите логин через разные балансируемые ноды (sticky session на LB всё равно полезен, но хранилище уже общее).
3. В phpinfo() или через временный скрипт убедитесь, что не остался старый session.save_handler=files как единственный механизм без Битрикс-обёртки.
4. Если появляется «Ваша сессия истекла» — смотрите также домен cookie, HTTPS и session.cookie_secure, не только handler. Разбор симптома: вылет из админки.

Типичные ошибки

• Правили не тот файл (кэш старого .settings.php в opcache).
• Синтаксическая ошибка в PHP-массиве — сайт падает на белом экране; держите бэкап файла.
• Смешали кавычки/запятые при копипасте из статьи.
• Ожидали, что смена session в .settings.php починит CSRF при неверном cookie_domain — это разные слои.

Вывод

Блок session в .settings.php — место, где вы явно выбираете хранилище сессий Битрикс. Для большинства проектов старт — type => database; для кластера смотрите Redis и единый конфиг на всех нодах. После правки обязательно сбросьте opcache и проверьте логин в админку на реальном URL сайта.