У небольшого сайта обычно уже есть домен, хостинг и HTTPS. Чтобы добавить перед ним облачную защиту, нужно правильно связать три адреса: имя сайта, адрес платформы фильтрации и исходный сервер. Затем проверить, что посетитель получает прежний сайт, а запрос действительно проходит через защиту.
Ниже — последовательность проверок для одного заранее подготовленного тестового сайта. Потребуются подтверждённый аккаунт, доступ к DNS, работоспособный исходный сервер и право менять настройки ресурса. Срок подключения зависит от этих условий, обновления DNS и выпуска сертификата. Время здесь не измерялось; до завершения проверок подключение нельзя считать готовым.
Что входит в бесплатный вариант
В документации Solar Space бесплатный тариф описан как один ресурс, 1 Мбит/с и AntiDDoS. Antibot и WAF Lite в этот состав не входят. Отдельно существует демо на 14 дней с другим составом возможностей и условиями доступности. Перед изменениями проверьте, что в своём кабинете выбрали именно бесплатный вариант, а итоговая стоимость равна нулю.
Параметр 1 Мбит/с не означает «защита от атак не мощнее 1 Мбит/с». Документация связывает ширину канала с очищенным трафиком сайта. Она также не превращает тариф в обещание определённого числа посетителей: размер страниц и сценарии использования отличаются. Для рабочего ресурса с большей нагрузкой сначала подберите подходящие условия.
Подготовьте всё до начала
- Аккаунт Solar Space с доступом к почте и завершёнными обязательными шагами профиля. Если регистрируетесь впервые, выделите на это отдельное время. Не выбирайте другой тип пользователя только ради сокращения формы: документация предупреждает, что тип контрагента нельзя затем свободно поменять.
- Один домен или отдельный тестовый поддомен, которым вы вправе управлять. Для первого знакомства удобнее ресурс без заказов, личных кабинетов и реальных персональных данных.
- Доступ именно к DNS-провайдеру, который обслуживает зону. Он может отличаться от компании, у которой куплен домен.
- Настоящий публичный IPv4 исходного сервера — origin, поддерживаемые им протокол и порт. Основной сценарий ниже предполагает готовый HTTPS-origin, обычно на порту 443; если origin работает по HTTP, это нужно явно учесть в настройках платформы. Если сайт уже находится за другим прокси, IP из публичного DNS может принадлежать ему. Адрес origin уточните у хостинга.
- Копию действующих DNS-записей и способ вернуть прежнюю маршрутизацию. Для сайта на конструкторе или хостинге с обязательным CNAME заранее проверьте, допускает ли провайдер такую схему подключения. У этого сценария нет универсального решения для любой площадки.
В официальном быстром старте базовыми предпосылками названы домен, доступ к DNS и аккаунт платформы. Проверка origin и подготовка возврата прежних DNS-записей — дополнительные меры для предсказуемого переключения.
Шаг 1. Проверьте тариф и создайте ресурс
Откройте кабинет по ссылке из официальной документации. Если бесплатный тариф уже активен, не подключайте платный пакет просто потому, что стартовый экран предлагает пополнить баланс. Если тариф нужно выбрать, проверьте его название, состав, ограничение и итог перед подтверждением. Универсальная инструкция по тарифам описывает и оформление платного пакета; этот шаг нельзя автоматически переносить в бесплатный сценарий.
В списке ресурсов запустите создание сайта. Укажите понятное название и точное доменное имя — без случайного пути к странице. Например, demo.your-domain.example здесь означает ваше собственное имя, а не адрес для копирования. Откройте настройку защиты созданного ресурса. На этом этапе запись в списке ещё не доказывает, что трафик пошёл через платформу.
Шаг 2. Проверьте адрес и протокол origin
В настройках ресурса откройте «Целевой IP». Проверьте адрес исходного сервера: сюда нельзя ставить защитный IP, который платформа позже предложит для DNS. Иначе вместо цепочки «защита → сайт» можно получить ошибочную маршрутизацию.
Выберите протокол и порт, которые действительно поддерживает исходный сервер. Для подготовленного HTTPS-origin это обычно HTTPS/443. Документация относит HTTP/80 к тестовым целям и рекомендует HTTPS/443 для рабочего ресурса. Фактические протокол и порт origin должны соответствовать настройке; наличие внешнего сертификата само по себе не подтверждает HTTPS до origin. Параметр определяет соединение платформы с origin, а сертификат для посетителя настраивается отдельно. Режим проверки сертификата origin при специальных требованиях уточните у поддержки.
Для первого подключения оставьте один проверенный origin. Балансировка, резервные адреса и веса — отдельная задача. Не отключайте TLS-проверки в браузере ради демонстрации «работающего» сайта.
Шаг 3. Проверьте маршрутизацию нужного имени
На вкладке «Домен и SSL» возьмите значение DNS-A из своего ресурса. Это адрес защиты, который должен оказаться в публичной A-записи. Сохранённый origin при этом остаётся в настройках платформы. Не копируйте IP из чужого скриншота или этой статьи.
В DNS-панели измените запись только защищаемого имени. У корневого домена это обычно @; у тестового поддомена — его соответствующая запись. Почтовые MX, SPF/DKIM и записи других сервисов не относятся к этому действию. Не считайте, что защита одного имени автоматически распространяется на www и все поддомены.
Проверьте, нет ли у этого же имени AAAA-записи, которая направляет IPv6-трафик в обход выбранной схемы. Быстрый старт описывает IPv4-подключение. Изменение AAAA нужно согласовать с хостингом и ограничить нужным именем; не удаляйте IPv6-записи всей зоны. После сохранения запустите проверку DNS в кабинете.
Если кабинет предлагает подтверждение через TXT, скопируйте значение точно и добавьте новую запись, сохранив существующие TXT. Текущая документация допускает подтверждение без перевода трафика, например для сканирования. Сам по себе статус подтверждения домена ещё не означает, что A-запись уже ведёт на защиту. В разных частях быстрого старта требования TXT описаны неодинаково; для конкретного мастера ориентируйтесь на его текущую проверку, а не на предположение об обязательности TXT во всех случаях.
Шаг 4. Проверьте внешний HTTPS и AntiDDoS
Для стандартного сценария выберите «Бесплатный сертификат (LE)». Дождитесь успешного выпуска и проверьте срок действия и нужное имя. Включайте перенаправление на HTTPS, когда HTTPS уже работает. При собственном сертификате отдельно потребуется корректный комплект файлов; закрытый ключ не должен попадать в скриншоты, переписку или пример статьи.
Проверьте, что AntiDDoS включён и ресурс получил статус работы через защиту. На старте не повышайте агрессивность только ради красивого события в журнале. В документации максимальная агрессивность означает JS Challenge для всех запросов: это может затронуть интеграции и клиентов без JavaScript. Порог и режим следует подбирать под ресурс.
Если DNS ещё обновляется или сертификат выпускается, зафиксируйте «ожидание», а не «готово». Не переключайте записи туда-сюда каждую минуту: разные DNS-кеши могут ещё возвращать разные ответы.
Шаг 5. Проверьте доступность и пользовательские сценарии
Откройте защищаемое имя обычным браузером. Проверьте:
- Сертификат подходит домену, предупреждений нет.
- Открылась ожидаемая страница, а не заглушка хостинга.
- Загружаются стили и изображения; обычный переход по ссылке работает.
- Нет цикла перенаправлений между HTTP и HTTPS или между www и основным именем.
- В кабинете выбраны этот ресурс и нужный временной интервал; после обновления отчёта видны ваши обращения.
Если доступен журнал origin, сопоставьте время обычного обращения с его записью. Это помогает подтвердить всю цепочку. Один HTTP 200 не доказывает прохождение через защиту: такой же ответ может вернуть старый маршрут из DNS-кеша. И статус «под защитой» в кабинете нужно сопоставить с фактическим открытием сайта.
После проверки доступности отдельно ограничьте прямой доступ к веб-портам origin доверенными сетями платформы, если это допускает ваша инфраструктура. Берите актуальные сети из документации и согласуйте мониторинг, выпуск сертификатов и административный доступ. Не вставляйте универсальные firewall-команды в рабочий сервер без проверки. Это отдельный этап укрепления схемы после проверки доступности.
Где смотреть результат фильтрации
Начните со страницы «Статистика» → «Запросы». Выберите один ресурс, период, часовой пояс и интервал обновления. В документации различаются входящие запросы до фильтрации и легитимные после неё. Это счётчики запросов, а не уникальных посетителей. Разность рядов не следует подписывать «столько DDoS-атак отражено».
На вкладке «Коды» проверьте ответы сервиса. Рост ошибок — повод для диагностики. Самостоятельно взятый 403, 429 или 503 не доказывает ни злонамеренность клиента, ни причину отказа: ответ мог сформировать один из разных слоёв цепочки.
При разборе отдельного обращения выберите нужный ресурс и время и проверьте доступные сведения о запросе. Наличие журнала, набор полей и доступность функции сверяйте с текущей официальной документацией и условиями своего тарифа.
Код ответа или наличие записи в журнале сами по себе не устанавливают причину отказа и решение защиты. Для вывода о блокировке нужны сведения о конкретном действии и его основании. Если их нет, корректный вывод — «решение не установлено».
Если сведения о событии содержат явное решение защиты, сопоставьте его с причиной, правилом и режимом сервиса. Режим анализа WAF не равен режиму блокировки; WAF Lite не входит в описанный бесплатный тариф.
Как показать блокировку без нагрузочной атаки
Вариант 1 — историческое событие. На разрешённом ресурсе найдите уже существующую запись с подтверждённым решением. Скройте адреса клиентов, чувствительные пути и параметры запроса, идентификаторы аккаунта и содержимое запроса. Подпишите дату, источник, действие и основание. Если происхождение трафика неизвестно, не называйте его реальной атакой.
Вариант 2 — одна проверка доступа. Только на собственном тестовом домене, если тариф и текущий интерфейс поддерживают точечный Black list, можно временно добавить отдельный согласованный публичный IP тестового клиента. Он не должен быть общим адресом офиса, мониторинга или единственного административного подключения. Сохраните исходное состояние, добавьте только этот адрес, сделайте одно обычное открытие тестовой страницы и найдите соответствующее решение в журнале. После демонстрации удалите только созданное тестовое правило и проверьте восстановление доступа. Документация описывает блокировку адресов в Black list, но наличие события с нужными полями и доступность функции на Free нужно проверить в своём кабинете до демонстрации.
Корректный вывод такого опыта: «Тестовое обращение отклонено по заданному правилу доступа». Это не тест ёмкости AntiDDoS, не оценка поведения под нагрузкой и не доказательство отражённой распределённой атаки. Если безопасный тест недоступен, используйте первый вариант или покажите пустую статистику честно. Не создавайте поток запросов и не отправляйте эксплойты ради иллюстрации.
Если подключение остановилось
- Ресурс создан, но защиты нет
- A-запись именно нужного имени, ожидаемый IP из кабинета, результат проверки и DNS-кеши.
- Сертификат не готов
- Текущее состояние выпуска, правильность имени и маршрута; требования мастера к подтверждению. Не обходить предупреждение браузера.
- HTTPS работает с ошибкой или редиректы повторяются
- Раздельно внешний TLS и HTTPS/порт origin, редиректы приложения и платформы.
- Сайт возвращает 5xx
- Адрес, порт и доступность origin, его журналы и журнал защиты. Если причина не видна, передать поддержке время, часовой пояс и ID события по закрытому каналу.
- График пуст
- Выбранный домен, интервал и часовой пояс, задержку обновления и фактический путь запроса. Не делать вывод «сервис не работает» только по пустому графику.
- Событие есть, действия нет
- Сохранить вывод «решение не установлено», не подписывать событие как блокировку.
Подключение завершено, когда нужное имя направлено через платформу, сертификат действителен, AntiDDoS активен, origin доступен и обычные пользовательские сценарии работают. Проверку этих условий лучше сохранить в короткой записи с датой. Если DNS ещё обновляется или сертификат выпускается, зафиксируйте достигнутый этап и продолжите после завершения ожидания.
Дополнительный исторический пример — обзор Anti-Malware.ru от 1 июля 2025 года. Его иллюстрации и наблюдения относятся к описанному там подключению. Тарифы, подписи интерфейса и сроки из обзора не являются текущими условиями или результатами этого руководства.
Документация и источники
- Быстрый старт
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Тарифы на веб-защиту
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Выбор параметров тарифа
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Регистрация
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Подтверждение аккаунта
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Подключение сервисов
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Домен и SSL
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Целевой IP
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- AntiDDoS
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Дополнительная безопасность origin
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Запросы
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Коды ответов
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Black list
Официальная документация Solar Space. Условия и интерфейс могут изменяться.
Проверено .
- Обзор Solar Space, системы комплексной защиты веб-сайтов
Исторический обзор подключения; не подтверждает текущие тарифы и сроки.
Опубликовано . Проверено .
