CPanel на сервере: частые ошибки и решения

MAATRIX

Даже стабильная cPanel на сервере время от времени преподносит сюрпризы: слетела лицензия, перестала выпускаться AutoSSL, не уходит почта или WHM отдаёт 500-ю ошибку. Хорошая новость в том, что типовые ошибки cPanel лечатся набором проверенных команд, и почти всегда причина лежит в лицензии, DNS, правах или нехватке ресурсов. Ниже — разбор самых частых проблем с готовыми решениями, начиная с тех, что встают чаще всего. Прежде чем чинить конкретный симптом, полезно знать, где cPanel хранит подсказки. Главные журналы лежат в /var/log: /var/log/messages — системные события, /usr/local/cpanel/logs/error_log — ошибки самой панели, /var/log/exim_mainlog — почта, /var/log/apache2/error_log — веб-сервер. Привычка сначала заглянуть в лог, а потом гуглить симптом экономит часы. Диагностику панели целиком запускает встроенный скрипт /usr/local/cpanel/scripts/check_cpanel_rpms, который находит битые пакеты.

Слетела лицензия: WHM пишет о недействительном ключе

Самая частая и самая пугающая ошибка — сообщение «This server does not have a valid cPanel license». Обычно паниковать не нужно: причина не в блокировке, а в том, что панель не смогла синхронизироваться с лицензионным сервером cPanel. Первое, что делаем, — принудительное обновление ключа:

/usr/local/cpanel/cpkeyclt

Команда обращается к серверам cPanel по IP сервера и переустанавливает ключ. Если она возвращает ошибку соединения, проверьте, что исходящие соединения на порты 2089 и 443 не заблокированы фаерволом, а IP сервера не сменился. Лицензия cPanel привязана строго к IP: если провайдер выдал вам новый адрес, старая лицензия перестаёт действовать. Именно поэтому важен выделенный статический IP — на VPS MAATRIX адрес закреплён за сервером и не меняется, так что лицензия не слетает после перезагрузок.

Проверить, какой IP видит лицензия, можно так:

curl -s https://verify.cpanel.net/

Если адрес в ответе не совпадает с реальным, разберитесь с сетевой конфигурацией и снова выполните cpkeyclt.

AutoSSL не выпускает сертификаты

Второй по частоте вопрос — сайты остаются без HTTPS, хотя AutoSSL включён. Механизм выпуска Let's Encrypt требует, чтобы домен уже резолвился на этот сервер и был доступен по HTTP для проверки. Если A-запись домена указывает на старый хостинг или ещё не разошлась по DNS, валидация провалится. Запустите проверку вручную и посмотрите причину отказа:

/usr/local/cpanel/bin/autossl_check --all --verbose

В выводе AutoSSL прямо пишет, почему не смог выпустить сертификат: «DNS does not resolve to this server» — не разошлась A-запись; «HTTP request failed» — домен закрыт паролем, редиректом или фаерволом; «rate limit» — превышен лимит Let's Encrypt (5 неудач в час). Убедитесь, что домен доступен снаружи по http://domen/.well-known/acme-challenge/, и что в .htaccess нет глобального редиректа, ломающего проверку. После исправления DNS дайте записям разойтись и повторите проверку.

Почта не отправляется или уходит в спам

Проблемы с почтой на cPanel почти всегда упираются в две вещи: заблокированный порт 25 и отсутствие правильных DNS-записей. Многие провайдеры закрывают исходящий 25-й порт по умолчанию для борьбы со спамом. Проверьте, открыт ли он:

telnet smtp.gmail.com 25

Если соединения нет, порт закрыт — тогда нужен либо релей через смарт-хост, либо открытие порта у провайдера. На VPS MAATRIX порт 25 доступен, а для стабильной доставки настроена возможность корректной PTR-записи.

Если письма уходят, но попадают в спам, причина в отсутствии SPF, DKIM и DMARC. В WHM откройте Email → Email Deliverability — панель сама покажет, какие записи не настроены, и предложит готовые значения для добавления в DNS. Диагностику доставки конкретного письма ищите в почтовом логе:

grep получатель@domen.ru /var/log/exim_mainlog

Ошибка 500 и «Internal Server Error» в WHM или на сайте

Внутренняя ошибка сервера — общий симптом с десятком причин. Для сайта чаще всего виноваты права доступа или синтаксис в .htaccess. cPanel требует, чтобы файлы имели права 644, папки — 755, а владельцем был пользователь аккаунта, а не root. Массово исправить владельца поможет встроенный скрипт:

/scripts/chownpublichtml пользователь

Если 500-я вылезает в самом WHM, дело обычно в переполненном диске или битых пакетах Perl. Проверьте свободное место:

df -h

Переполнение раздела / — крайне частая причина «внезапно всё сломалось»: перестают писаться логи, базы уходят в read-only, панель отдаёт ошибки. Почистите старые бэкапы и логи, а для баз данных проверьте раздел с MySQL. Битые RPM-пакеты панели чинит /usr/local/cpanel/scripts/check_cpanel_rpms --fix.

Высокая нагрузка и нехватка памяти

Если сервер тормозит, WHM открывается по минуте, а сайты отваливаются с ошибкой подключения к базе, почти всегда виновата нехватка RAM. cPanel со всем стеком — Apache, MySQL, Exim, Dovecot, ClamAV — прожорлив, и на 1–2 ГБ памяти при реальной нагрузке начинается своп и OOM-killer. Посмотрите, кто ест память и не убивал ли ядро процессы:

free -m
grep -i 'killed process' /var/log/messages

Частый пожиратель памяти — антивирус ClamAV и апдейтер cPanel во время ночного обслуживания. Если убийства процессов регулярны, вариантов два: оптимизировать (отключить ClamAV, перевести Apache на MPM event, ограничить MySQL) или добавить память. Честно говоря, для боевого cPanel-сервера с почтой 4 ГБ — практический минимум. На VPS MAATRIX память можно увеличить в пару кликов, не переустанавливая панель.

MySQL не запускается или базы недоступны

Ошибка «MySQL server has gone away» или отказ старта MariaDB — частый спутник переполненного диска и повреждённых таблиц. Сначала посмотрите статус и лог:

systemctl status mysql
tail -50 /var/lib/mysql/*.err

Если сервис не стартует из-за повреждённых InnoDB-таблиц после аварийного выключения, помогает запуск с параметром восстановления innodb_force_recovery в /etc/my.cnf (значения от 1 до 6, начинайте с 1), после чего делают дамп и восстанавливают базу начисто. Не оставляйте recovery включённым постоянно — это аварийный режим только для снятия дампа. Регулярные повреждения баз — сигнал о нестабильном диске или внезапных отключениях; на надёжном VPS такое встречается редко.

Обновления и восстановление после сбоя

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

/usr/local/cpanel/scripts/upcp --force

Скрипт обновит панель, пересоберёт при необходимости RPM-пакеты и приведёт конфиги в согласованное состояние. Если же сервер пострадал серьёзно, спасают резервные копии. Настроенный в WHM Backup Configuration бэкап с выгрузкой на удалённое хранилище позволяет развернуть аккаунт целиком командой восстановления или через интерфейс. Мораль простая: держите свежие бэкапы вне сервера — тогда любая ошибка cPanel из катастрофы превращается в получасовую задачу.

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