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

MAATRIX

ISPmanager ошибки — тема, с которой рано или поздно сталкивается каждый, кто держит панель на своём VPS. Панель управления упрощает жизнь, пока работает, но стоит закрыться порту, кончиться памяти или сломаться веб-серверу — и вы остаётесь один на один с непонятным экраном. Хорошая новость в том, что большинство проблем типовые, и у каждой есть понятная причина и конкретная команда для починки. В этом руководстве мы разберём восемь самых частых бед: от «панель вообще не открывается» до битого веб-сервера и проваленного обновления. По каждой ошибке — как её распознать, чем диагностировать и чем чинить прямо в консоли. Прежде чем бросаться чинить, зафиксируйте одно правило: сначала диагностика, потом действие. Соблазн наугад перезапустить всё подряд велик, но так вы рискуете сломать ещё сильнее и потерять понимание, что вообще произошло. Почти к любой ошибке ISPmanager у вас есть три инструмента диагностики: логи панели и сервисов, проверка какие порты слушаются, и статус сервисов через systemctl. Держите под рукой доступ по SSH — если веб-панель недоступна, консоль остаётся вашим единственным входом, и терять её нельзя ни в коем случае.

Панель недоступна и порт закрыт фаерволом

Самая частая жалоба — «поставил панель, а https://IP:1500 не открывается». В девяти случаях из десяти виноват фаервол: порт 1500 не разрешён, и браузер молча упирается в закрытую дверь. Первым делом проверьте с самого сервера, слушает ли панель свой порт. Если процесс есть и порт слушается локально, а снаружи не открывается — дело точно в фильтрации трафика, а не в самой панели.

ss -tlnp | grep 1500
systemctl status ispmgr

Если панель слушает порт, откройте его в ufw и заодно проверьте, нет ли блокировки на стороне провайдера в облачной консоли — у многих есть внешний фаервол уровня сети поверх серверного. Разрешите порт панели и SSH, чтобы не отрезать себя от сервера, и перезагрузите правила. После этого адрес должен открыться. Если ufw неактивен, а порт всё равно закрыт, ищите правило именно во внешней панели провайдера — это отдельный слой, который ufw не видит.

ufw allow 1500/tcp
ufw allow 22/tcp
ufw reload
ufw status numbered

Бывает и обратная ситуация: порт открыт, но панель всё равно не отвечает, потому что её сервис упал. Тогда grep по порту ничего не покажет, а systemctl status выдаст failed. В этом случае проблема не в сети, а в самой панели — переходите к разделу про ресурсы и логи, скорее всего сервису не хватило памяти или он споткнулся о битый конфиг. Не открывайте порт «на всякий случай» шире, чем нужно: лишние открытые порты — это подарок ботам-переборщикам.

Забыли или потеряли пароль администратора

Вторая по популярности беда — не получается войти, пароль не подходит. Важно понимать: пароль администратора панели по умолчанию совпадает с root-паролем сервера. Поэтому «сброс пароля панели» — это на самом деле смена пароля root в системе. Зайдите на сервер по SSH под root или через SSH-ключ и задайте новый пароль. После этого используйте его для входа в панель под пользователем root.

passwd root

Если вы вообще не можете зайти по SSH под root — например, вход по паролю запрещён, а ключ утерян, — то остаётся аварийный доступ через консоль провайдера. Почти у каждого хостинга есть VNC или веб-консоль, которая даёт доступ к серверу в обход SSH, как будто вы сидите за монитором. Через неё вы логинитесь локально и меняете пароль. Для пользователей панели, которые не root, пароль меняется прямо в интерфейсе в разделе управления пользователями, — но только если у вас есть доступ администратора. Отсюда мораль: не теряйте root-доступ и держите резервный способ входа.

Конфликт портов с уже установленным ПО

Третья классическая проблема всплывает ещё на этапе установки или сразу после: панель не поднимает веб-сервер, потому что 80-й или 443-й порт уже кем-то занят. Обычно виноват предустановленный в образе Apache или Nginx, либо ваш собственный сервис, который вы забыли про него. ISPmanager рассчитывает поставить свой стек с нуля и конфликтует с чужим. Найдите, кто держит порт, и вы поймёте масштаб проблемы.

ss -tlnp | grep -E ':80|:443'
systemctl list-units --type=service | grep -E 'apache|nginx'

Если порт держит посторонний сервис, который не имеет отношения к панели, его нужно остановить и отключить автозапуск, а затем дать панели переустановить свой веб-сервер. Но действуйте осторожно: убедитесь, что это действительно чужой процесс, а не тот, что подняла сама панель. Идеальное решение конфликта портов — вообще не доводить до него, ставя ISPmanager только на чистую систему. Если конфликтов много и вы запутались, зачастую быстрее и надёжнее пересоздать VPS из чистого образа ОС и поставить панель заново, чем разгребать наслоения.

systemctl stop apache2
systemctl disable apache2

Не выпускается SSL-сертификат Let's Encrypt

Четвёртая частая ошибка — «включаю Let's Encrypt, а сертификат не выпускается». Причина почти всегда в DNS: домен не указывает на IP этого сервера, поэтому проверка владения проваливается. Let's Encrypt должен убедиться, что домен ваш, обратившись к нему по HTTP, и если запрос уходит не на ваш сервер, выпуск обрывается. Проверьте, куда реально резолвится домен, и сравните с IP сервера.

dig +short вашдомен.ru
curl -I http://вашдомен.ru/.well-known/acme-challenge/test

Если A-запись указывает на чужой адрес или ещё не распространилась после недавнего изменения, дождитесь обновления DNS и повторите выпуск. Вторая частая причина — закрытый снаружи 80-й порт: валидация Let's Encrypt по умолчанию идёт именно по HTTP, и если ufw или внешний фаервол режут 80-й, проверка не пройдёт при живом сайте на 443. Откройте 80-й порт, убедитесь что домен резолвится на сервер, и повторите. Ещё одна ловушка — лимиты Let's Encrypt: если вы много раз подряд пытались выпустить сертификат на один домен, упрётесь во временный лимит и придётся подождать час-другой.

Права доступа и «отдаёт 403 или 500»

Пятая беда — сайт создан, файлы залиты, а вместо страницы отдаётся 403 Forbidden или 500 Internal Server Error. Чаще всего это права доступа: файлы принадлежат root или другому пользователю, а веб-сервер работает от имени пользователя сайта и не может их прочитать. Такое случается, когда файлы заливали по SSH под root, минуя файловый менеджер панели. Посмотрите, кому принадлежат файлы сайта и какие у них права.

ls -la /var/www/USER/data/www/вашдомен.ru
tail -n 30 /var/www/httpd-logs/вашдомен.ru.error.log

Правильные владелец и права лечат большинство таких ошибок: файлы сайта должны принадлежать пользователю сайта, каталоги обычно имеют права 755, а файлы 644. Восстановите владельца рекурсивно на пользователя сайта, и 403 с 500 из-за прав уйдут. Если после этого ошибка осталась, читайте лог ошибок веб-сервера — там будет конкретная причина: битый .htaccess, нехватка модуля PHP или ошибка в коде самого сайта. Лог ошибок — ваш главный друг: не гадайте, а смотрите последние строки, они почти всегда называют виновника прямым текстом.

chown -R USER:USER /var/www/USER/data/www/вашдомен.ru

Нехватка RAM и сервисы падают

Шестая проблема коварна тем, что проявляется плавающими симптомами: то панель тормозит, то сайт отдаёт 502, то почта не отправляется, то сервис сам по себе перезапускается. За этим часто стоит банальная нехватка оперативной памяти. Когда память кончается, ядро Linux начинает убивать процессы через OOM-killer, и первыми под нож идут прожорливые MySQL и PHP. Проверьте, сколько памяти реально свободно и не срабатывал ли OOM-killer в системном журнале.

free -h
dmesg | grep -i 'out of memory'

Если памяти хронически не хватает, есть два пути. Быстрый и временный — добавить swap-файл: это спасёт от внезапных падений, хотя своп на диске медленный и не заменяет настоящую RAM. Правильный путь — увеличить тариф VPS: панель плюс несколько сайтов с базами и почтой на 1 ГБ памяти жить не будут. Swap лечит симптом, апгрейд лечит причину. Ниже — как быстро добавить пару гигабайт свопа, чтобы дожить до апгрейда без падений.

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Сломанный веб-сервер и ошибки обновления

Седьмая и восьмая беды идут парой, потому что часто связаны. Иногда после обновления панели, PHP или системы веб-сервер перестаёт запускаться: сайты отдают 502 Bad Gateway или вовсе не отвечают. Причина — битый конфиг: обновление изменило синтаксис, а старая директива в конфиге сайта стала несовместимой. Не паникуйте и не сносите ничего — сначала попросите сам веб-сервер проверить конфигурацию, он точно укажет файл и строку с ошибкой.

nginx -t
apache2ctl configtest
journalctl -u nginx --no-pager -n 40

Проверка конфига покажет, где именно ошибка, — исправьте эту строку и перезапустите сервис. Что касается сорванных обновлений самой панели или системы: если apt ругается на сломанные зависимости или прерванную установку, обычно помогает завершить прерванную настройку пакетов и доустановить недостающее. Только не запускайте обновление, когда на диске нет места, — это верный способ получить полусломанную систему. Сначала проверьте место командой df, освободите его при нужде, и лишь потом обновляйтесь. Ниже команды, которые вытаскивают apt из большинства тупиков.

df -h
dpkg --configure -a
apt --fix-broken install

После любой из этих починок обязательно проверьте, что всё поднялось: откройте панель, зайдите на пару сайтов, гляньте статус ключевых сервисов через systemctl. Ошибка считается устранённой не тогда, когда прошла команда, а когда вы своими глазами увидели, что сервис работает. И профилактика важнее лечения: держите свободное место на диске, следите за памятью, делайте бэкапы перед обновлениями и не заливайте файлы мимо панели под root — это снимает большую часть проблем ещё до их появления.

Если панель регулярно упирается в ресурсы и вы устали бороться с нехваткой памяти, возможно, дело в слишком скромном тарифе. В MAATRIX можно взять VPS с запасом по RAM и диску в локациях Россия, США и Великобритания, с оплатой картой РФ, по СБП, криптой или токеном MAAT. Иногда апгрейд сервера решает разом половину проблем из этого списка — просто потому, что панели наконец хватает ресурсов дышать спокойно.

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