Корзина, авторизация и обмен с 1С не работают после восстановления сайта

Все три симптома — «молчащая» корзина, вечно слетающая авторизация и падающий обмен с 1С — держатся на одном механизме: PHP-сессиях и cookies. Не сохраняется сессия — корзина пустеет, пользователя перекидывает на форму входа, а 1С падает на первом же шаге checkauth. Это одна корневая проблема, а не три отдельных.

Важно различать два состояния: Redis доступен, но пуст — пользователи просто разлогинились, это не поломка; Redis недоступен вообще — вот это наша картина.

Шаг 1. Диагностика без панели

Панель управления недоступна, php.ini не тронуть — работаем через файлы сайта и SSH. Залейте в корень сайта файл test_session.php:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');

echo 'save_handler: ' . ini_get('session.save_handler') . "\n";
echo 'save_path:    ' . ini_get('session.save_path') . "\n";
echo 'redis ext:    ' . (class_exists('Redis') ? 'да' : 'нет') . "\n";

session_start();
$_SESSION['n'] = ($_SESSION['n'] ?? 0) + 1;

echo 'id:       ' . session_id() . "\n";
echo 'counter:  ' . $_SESSION['n'] . "\n";

Откройте его в браузере и обновите 2–3 раза. Трактовка результатов:

Если есть SSH-доступ, дополнительно проверьте сам Redis из консоли:

redis-cli -h 127.0.0.1 -p 6379 keys '*'

Соединение не установится, если сервис мёртв. После проверки обязательно удалите test_session.php с сервера.

Шаг 2. Обходной манёвр: сессии на файлы

Доступа к php.ini нет — переопределяем на уровне сайта.

Вариант А — через .htaccess в корне сайта

Работает, если PHP работает как модуль Apache:

php_value session.save_handler "files"
php_value session.save_path "/home/u/ВАШ_ЛОГИН/domain.ru/php_sessions"

# создать каталог и закрыть его:
mkdir ~/domain.ru/php_sessions && chmod 700 ~/domain.ru/php_sessions

Вариант Б — если PHP-FPM

Директивы php_value в .htaccess дадут 500-ю ошибку. Тогда создайте рядом файл .user.ini:

session.save_handler = files
session.save_path = "/home/u/ВАШ_ЛОГИН/domain.ru/php_sessions"

Шаг 3. Приводим в порядок .settings.php

Откройте /bitrix/.settings.php и найдите секцию session. Если там указан Redis со старыми хостом и портом — это приоритетный источник проблемы: настройки Битрикса перекрывают PHP-настройки. Самый надёжный обход без Redis — переключиться на базу данных и раздельные сессии:

'session' => [
    'value' => [
        'mode' => 'separated',
        'lifetime' => 14400,
        'handlers' => [
            'general' => ['type' => 'database'],
            'kernel'  => 'encrypted_cookies',
        ],
    ],
],

Это штатный режим Битрикса: сессии пишутся в MySQL, ядро (авторизация) хранится в зашифрованных куках, Redis больше не нужен для старта. Альтернатива — вернуть type => 'file'. Когда хостинг оживёт и вы захотите обратно на Redis, поменяете database на redis с хостом и портом.

После правки обязательно очистите кэш — переименуйте папки:

cd ~/domain.ru/bitrix
mv cache cache_old && mkdir cache
mv managed_cache managed_cache_old && mkdir managed_cache

Устаревший кэш после восстановления может хранить битые страницы и старые sessid — тогда даже исправные сессии не спасут.

Шаг 4. Диск и логи

Восстановление могло задвоить файлы и забить квоту — тогда файловым сессиям некуда будет писаться. По SSH:

du -sh ~/* ~/.* 2>/dev/null | sort -rh | head -20
find ~/domain.ru/bitrix -name "error_log" -o -name "*.log" | head

В логах ищите session_start(): open(...) failed и No space left on device. Кэш и бэкапы-дубликаты — первые кандидаты на чистку.

Шаг 5. Проверка обмена с 1С

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

curl -u "ЛОГИН_1С:ПАРОЛЬ" "https://вашдомен.ru/bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth"

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

Шаг 6. Напишите в поддержку Beget

Панель не работает, но поддержка хостинга обычно отвечает на почту даже при падении панели. Опишите суть: «после восстановления аккаунта недоступен Redis / не работают сессии, нужна проверка микросервиса и состояния настроек PHP». Заодно уточните, на какой версии PHP сейчас работает сайт — после аварии её могли сменить.

Шаг 7. Безопасность после атаки

Сайт восстанавливали после атаки — прежде чем снова включать приём заказов и обмен с 1С:

• смените пароли админки, SSH/FTP и пользователя обмена с 1С;
• проверьте чужие учётные записи с правами администратора в /bitrix/admin/user_admin.php;
• просмотрите недавно изменённые PHP-файлы — восстановленный бэкап мог прихватить с собой шелл.

find ~/domain.ru -name "*.php" -mtime -30

Шпаргалка: симптом — первое действие

← Вернуться на главную страницу