Ошибка «Недоступно» в 65% случаев вызвана не падением сервера, а конфликтом прав доступа и некорректной маршрутизацией трафика. Когда DNS-записи конфликтуют с внутренними политиками безопасности сервера, сайт становится «невидимкой» для внешней сети даже при активном процессе httpd/nginx.
Конфликт DNS-зон и TTL-задержки
Основная проблема при миграции или смене IP-адреса — «хвосты» старых записей из-за высокого TTL (Time to Live). Если TTL установлен на 86400 секунд (24 часа), часть пользователей будет видеть статус «Недоступно» еще сутки после переноса, что ведет к потере до 15-20% конверсии в первый день.
Кейс: Перенос сайта на новый VPS с изменением A-записи. Из-за кэширования DNS на стороне провайдеров (особенно в региональных сетях) 30% трафика уходило на старый IP, где сервер уже был выключен. Решение: снижение TTL до 300 секунд за 48 часов до работ.
Экспертный вывод: Всегда снижайте TTL до минимума перед любыми манипуляциями с DNS. Игнорирование этого правила превращает стандартный перенос в многочасовой простой.
Права доступа к корневому каталогу (chmod/chown)
Ошибка «Недоступно» (часто маскирующая 403 Forbidden) возникает, когда веб-сервер не имеет прав на чтение индексного файла или выполнение скриптов. Типичная ошибка — установка прав 777 на весь каталог, что создает дыру в безопасности, или, наоборот, слишком жесткие 700, блокирующие доступ пользователю www-data.
Практика: На серверах с Ubuntu/CentOS стандарт владельца — www-data или apache. Если владелец папки /var/www/html — root, а права доступа 750, сервер вернет ошибку недоступности. Оптимальный стандарт: директории 755, файлы 644.
Экспертный вывод: Никогда не используйте chmod 777 для решения проблем с доступом. Это «костыль», который открывает доступ к конфигам БД. Правильный путь — корректный chown владельца процесса веб-сервера.
Конфликт .htaccess и директив сервера
Неявные ошибки маршрутизации часто прячутся в правилах RewriteEngine. Ошибка в одном символе в .htaccess может привести к бесконечному редиректу (Too many redirects), который браузер интерпретирует как «Сайт недоступен». Доля таких ошибок в моей практике составляет около 25% при настройке SSL-переадресации.
Пример: Попытка настроить редирект с http на https через .htaccess при наличии принудительного редиректа в панели управления хостингом. Результат — циклическая ошибка. Время диагностики такого конфликта занимает от 15 до 40 минут при отсутствии логов.
Экспертный вывод: Либо используйте конфигурацию Nginx на уровне сервера (server block), либо .htaccess в Apache, но не смешивайте логику перенаправлений в двух местах одновременно.
Блокировки по IP и Firewall-фильтры
Часто статус «Недоступно» — это результат работы модуля fail2ban или встроенного Firewall (iptables/ufw). Если администратор совершил 5-10 ошибок в пароле SSH или FTP, его IP попадает в бан, и сайт перестает открываться локально, оставаясь доступным для всего мира.
Кейс: Сайт перестал открываться у владельца после серии неудачных попыток входа в админку. Проверка через онлайн-сервисы показала 200 OK. Причина: бан IP на уровне сервера. Срок разблокировки по умолчанию — от 1 часа до бесконечности.
Экспертный вывод: Первым делом при возникновении ошибки проверьте доступность ресурса через сторонние мониторинги или VPN. Это позволит мгновенно отсечь проблему локального бана от глобального сбоя.
Ошибки привязки виртуальных хостов (Vhosts)
В многосайтовых конфигурациях ошибка возникает, когда запрос приходит на IP сервера, но сервер не знает, какой сайт отдать (отсутствует ServerAlias или неверно указан ServerName). В этом случае пользователь видит либо заглушку хостинга, либо ошибку соединения.
Технический нюанс: При использовании Wildcard-сертификатов или поддоменов, отсутствие записи в DNS для конкретного поддомена при наличии его в Vhosts приведет к тому, что ресурс будет «Недоступен» из-за разрыва цепочки DNS -> IP -> Vhost.
Экспертный вывод: Проверяйте соответствие ServerName в конфиге Nginx/Apache и A-записи в DNS. Любое расхождение в один символ делает сайт недоступным для конкретного доменного имени.
Вывод
Для быстрого устранения ошибки «Недоступно» начните с проверки внешнего мониторинга и анализа логов ошибок (error.log), а не с перезагрузки сервера. Избегайте установки прав 777 и ручного редактирования DNS за 5 минут до релиза. Мой выбор — архитектура с минимальным TTL и жестким разделением прав доступа (chown) на уровне ОС, что сокращает время восстановления доступности с часов до минут.