Сервер доступен по SSH, а сайт не открывается: что делать

Если сервер отвечает по SSH, а сайт не открывается — проблема почти никогда не в самом сервере: SSH и HTTP работают независимо друг от друга. Чаще всего дело в упавшем веб-сервере (nginx, apache), зависшем процессе 1С, закончившемся месте на диске, заблокированном порте 80 или 443, либо истёкшем TLS-сертификате. Диагностика через SSH-консоль обычно занимает 10-15 минут.

Почему возникает ситуация, когда SSH работает, а сайт не открывается

Утро понедельника: отдел продаж открывает сайт с формой заказа, которая тянет остатки со склада из 1С, и видит белый экран или «502 Bad Gateway». Системный администратор заходит по SSH за десять секунд — командная строка отвечает мгновенно, load average в норме. Но сайт всё равно не открывается, потому что SSH проверяет только доступность самой машины, а веб-сайт зависит от отдельной службы: nginx или apache, рабочих процессов 1С (ragent, rphost, rmngr) и связки портов 80 и 443. SSH-демон и веб-сервер — разные процессы на одном сервере, и падение одного не трогает другой.

Пока идёт разбор, компания теряет не гипотетические риски, а конкретные заявки: каждый час простоя интернет-магазина или личного кабинета на 1С — это упущенные заказы и звонки в поддержку с вопросом «почему сайт не работает». Для B2B с оплатой через личный кабинет это ещё и сорванные сверки, задержанные счета и раздражённые бухгалтеры на другом конце. Если через сайт проходит даже десяток заявок в день, три часа простоя в рабочее время — это заметная доля дневной выручки, а не абстрактный «риск репутации», плюс время менеджера на то, чтобы вручную обзвонить тех, чья заявка потерялась в момент падения.

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

Частые причины, если коротко:

• ✓веб-сервер nginx или apache упал после обновления пакетов или из-за нехватки памяти
• ✓рабочий процесс 1С завис и держит соединение с базой, не отпуская порт
• ✓диск заполнен логами или временными файлами, и служба не может писать данные
• ✓DNS-запись указывает на старый IP-адрес после переезда или смены сервера
• ✓firewall блокирует порты 80 и 443, оставляя открытым только 22-й для SSH

Как исправить ошибку, если сайт не открывается при рабочем SSH

Проверка за пять шагов

Первым делом смотрим статус веб-сервера: systemctl status nginx (или apache2) — если служба помечена как failed, причину читаем в journalctl -u nginx -n 50. Отдельно стоит прогнать nginx -t: если кто-то незадолго до падения правил конфиг публикации базы 1С и оставил опечатку, служба откажется стартовать именно по этой причине, и в логе будет явное указание на строку с ошибкой. Дальше проверяем процессы 1С: ps aux | grep rphost покажет, жив ли рабочий сервер, а обращение к кластеру через консоль администрирования или утилиту rac — доступен ли он вообще и не потеряна ли регистрация информационной базы. Место на диске смотрим командой df -h: если раздел с логами или базой заполнен на 100%, служба отказывается писать и падает. Порты проверяем через netstat -tulpn | grep -E '80|443' — если nginx их не слушает, значит он либо не запущен, либо порт занят другим процессом. Последний шаг — DNS и сертификат: nslookup домен.ru должен вернуть IP именно этого сервера, а браузер не должен ругаться на просроченный TLS.

Если веб-публикация 1С настроена через отдельный файл

Когда сайт — это опубликованная база 1С (личный кабинет, интернет-магазин на управляемых формах), стоит дополнительно проверить файл публикации default.vrd и права доступа веб-сервера к каталогу базы: после обновления конфигурации или переноса каталога права иногда слетают, и nginx технически жив, но не может достучаться до файлов 1С — в логе это выглядит как «Permission denied», а не как явная ошибка самого 1С.

Если в компании нет штатного сисадмина, эти пять шагов у стороннего специалиста занимают от получаса на выяснение, где вообще искать. У нас такие случаи закрывает настройка сервера 1С с диагностикой и коротким отчётом, что именно упало и почему, а не просто «перезапустили, работает».

Что делать, если ошибка повторяется через несколько дней

nginx перезапустили, сайт ожил — но через два дня всё повторяется в то же время, около полудня, когда склад массово выгружает остатки в каталог. Это значит, что причину не устранили, а перезапуск лишь спрятал её на день-два. Смотрим dmesg -T | grep -i oom: если ядро убивало процесс из-за нехватки памяти, это системная нехватка ресурсов, а не разовая случайность. На сервере, где веб-сайт делит оперативную память с рабочими процессами 1С, при 15-20 одновременных пользователях типовых 4 ГБ ОЗУ часто не хватает — системные требования 1С закладывают запас под каждый рабочий процесс кластера, а веб-сервер в эти расчёты обычно не входит и добавляется поверх.

Вторая частая причина — логи: без настроенного logrotate лог nginx или 1С за месяц-полтора съедает весь диск, и сайт падает по кругу с интервалом в несколько дней. Проверить это просто: du -sh /var/log/* сразу покажет, какой лог вырос до нескольких гигабайт. Третья причина — автопродление TLS-сертификата: если задача certbot в cron перестала отрабатывать из-за смены пути или прав, сертификат тихо истекает раз в 90 дней, и сайт «падает» ровно с таким интервалом — SSH при этом работает как ни в чём не бывало. Четвёртая — бот: агрессивный парсер цен долбит каталог на сайте запросами, веб-сервер упирается в лимит одновременных соединений и отваливается именно в рабочие часы, когда нагрузка и так на пике.

Пока причина не найдена, компания теряет заявки заново при каждом падении — и вместе с ними доверие клиентов, которые после второго-третьего «сайт не открывается» звонят конкурентам, а не ждут, пока починят. Разбор с логами за несколько недель обычно показывает закономерность за 20-30 минут — гораздо быстрее, чем гадать заново при каждом повторном падении.

Как предотвратить повторное падение сайта на сервере с 1С

Мониторинг с оповещением о падении службы и о заполнении диска экономит часы простоя: о сбое узнают за минуту по алерту в Telegram, а не когда позвонит клиент. Отдельно стоит мониторить срок действия TLS-сертификата — простое уведомление за 14 дней до истечения снимает ту самую причину «падения по расписанию раз в квартал». Запас по памяти и CPU нужен под пиковую нагрузку, а не под среднюю — иначе OOM killer вернётся при первом же наплыве заказов перед праздниками. И перенос сайта с 1С-интеграцией на ресурсы, рассчитанные под совместную нагрузку веб-сервера и кластера 1С, а не под бюджетный тариф общего хостинга: аренда сервера 1С с заложенным запасом по памяти обычно обходится дешевле, чем повторные простои и внеплановые выезды сисадмина.

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

Что делает ukved, когда сайт на сервере с 1С падает

Когда клиент присылает «SSH есть, сайта нет», сисадмин сначала проходит тот же список — служба, процессы 1С, диск, порты, DNS, сертификат — и фиксирует в тикете, что упало и почему. Разовый разбор и устранение стоит от 3800 руб/час; обычно укладываемся в один-два часа, если причина не требует переноса на другое железо. Если падения повторяются из-за нехватки ресурсов, предлагаем перенос на сервер с запасом — от 3300 руб/мес за мощности, рассчитанные под сайт и 1С вместе, без пересчёта на «среднюю нагрузку» задним числом. Перенос обычно укладывается в один рабочий день: текущая база продолжает работать, пока новая среда проверяется, а переключение домена происходит в момент, когда всё уже готово принимать нагрузку. Компаниям с нагруженной ERP-конфигурацией и веб-клиентом для сотрудников подойдёт сервер под 1С:ERP — там изначально закладывается ресурс под параллельную работу веб-интерфейса и учётной системы, а не досчитывается после первого падения.

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

Почему SSH работает, а сайт выдаёт 502 Bad Gateway?

502 Bad Gateway обычно означает, что nginx или apache жив, но не может достучаться до бэкенда — упавшего процесса 1С, php-fpm или другого приложения за прокси. SSH при этом продолжает работать, потому что проверяет только доступность самого сервера, а не состояние конкретных служб внутри него.

Как проверить, жив ли nginx, если под рукой только SSH?

Достаточно команды systemctl status nginx — она сразу покажет, запущена служба или нет. Если статус failed, причину смотрите в journalctl -u nginx -n 50: там обычно указана конкретная строка конфигурации или ошибка, из-за которой служба отказалась стартовать при последнем запуске.

Может ли причина быть в самой базе 1С, а не в веб-сервере?

Да: если сайт — это опубликованная база 1С, зависший процесс rphost или потерянная регистрация информационной базы в кластере тоже дают белый экран при полностью рабочем SSH. Проверяется это через ps aux | grep rphost и обращение к кластеру через консоль администрирования 1С.

Сайт падает снова через час после перезапуска nginx — что не так?

Обычно это признак нехватки ресурсов сервера: заканчивается оперативная память, диск забит логами или процесс принудительно убивает OOM killer ядра Linux. Разовый перезапуск снимает симптом, но не устраняет причину — нужно смотреть dmesg -T | grep -i oom и свободное место через df -h.

Сколько стоит регулярное сопровождение, чтобы не разбираться с этим самостоятельно?

Разовая диагностика и устранение проблемы стоит от 3800 руб/час, аренда сервера с запасом ресурсов под сайт и 1С — от 3300 руб/мес. Точная стоимость зависит от текущей нагрузки и конфигурации и обычно называется после короткого бесплатного аудита действующего сервера.