CDN и защита

Проксирование DNS-записи — это и есть включение CDN и защиты. Пока запись не проксируется, трафик идёт на origin напрямую; включили Proxy — и он пошёл через WebShield.

Какие записи можно проксировать

Проксирование доступно только для:

• A
• AAAA
• CNAME

Для MX, TXT, SRV, CAA и других служебных записей проксирование не включается.

Как включить CDN

1. Откройте DNS.
2. Найдите запись A, AAAA или CNAME для нужного хоста.
3. Включите переключатель Proxy.
4. Откройте раздел Хосты и настройте поведение трафика для этого хоста.

После включения proxy запросы к этому имени проходят через WebShield CDN, WAF и механизмы фильтрации.

Параметры proxy

На странице хоста доступны:

• Режим хоста: Проксирование - запросы проксируются на origin-сервер с защитой WAF.
• Режим хоста: Редирект на другой хост - вместо проксирования посетители получают 301-редирект на указанный хост с сохранением пути и параметров запроса.
• SSL required - требовать HTTPS для защищенного хоста.
• Redirect HTTP to HTTPS - перенаправлять HTTP-запросы на HTTPS.
• Bot protection: Off - не выполнять дополнительную проверку браузера.
• Bot protection: Browser - включить browser-check для подозрительных клиентов.
• Bot protection: Captcha - включить режим проверки с CAPTCHA. Этот режим взаимоисключающий с Browser.
• HTTP/2 - включить HTTP/2 для клиентских соединений.
• HTTP/3 - включить HTTP/3 (QUIC, UDP 443) для клиентских соединений. Браузер узнаёт о поддержке из заголовка Alt-Svc в ответе и переключается на HTTP/3 со следующего запроса; первое соединение всегда идёт по TCP. Если сеть посетителя блокирует UDP, клиент прозрачно остаётся на HTTP/2.
• Протокол до вашего сервера - протокол соединения WebShield с origin-сервером. На посетителей он не влияет: их протокол задаётся параметрами выше.
• Кешировать страницы - разрешить кеш HTML, когда ваш сервер о сроке хранения молчит (см. раздел «Кеш»). Файлы кешируются независимо от этого переключателя.

Протокол до вашего сервера

Параметр управляет только участком «WebShield → ваш сервер».

• Автоматически (по умолчанию) - мы периодически проверяем, поддерживает ли ваш сервер HTTP/2, и включаем его, только если поддержка подтверждена. Пока проверка не выполнена или сервер её не прошёл, используется HTTP/1.1. Это безопасный вариант: настраивать ничего не нужно.
• HTTP/2 - принудительно. Выбирайте, если знаете, что сервер поддерживает HTTP/2 без TLS (h2c) либо предлагает h2 при TLS-соединении.
• HTTP/1.1 - принудительно. Выбирайте, если после переключения на HTTP/2 сайт стал отвечать с ошибками.

Что даёт HTTP/2 на этом участке: границы запросов внутри соединения заданы однозначно, поэтому режим устойчивее к атакам подмены границ запроса (request smuggling). Кроме того, параллельные запросы передаются в одном соединении, без отдельного рукопожатия на каждый.

Осторожно

У HTTP/2 нет автоматического отката. Если принудительно выбрать HTTP/2 для сервера, который его не поддерживает, сайт начнёт отвечать ошибкой 502 на все запросы. При сомнениях оставляйте «Автоматически».

Отдельно: WebSocket-соединения всегда передаются по HTTP/1.1 независимо от этой настройки - механизма апгрейда соединения в HTTP/2 нет. Настройка на работу вебсокетов не влияет.

Редирект www на основной домен

Если основной сайт размещен на апексе (например, статический сайт на example.com), а www.example.com должен вести на него, проксировать www некуда - у него нет origin-сервера. Настройте редирект:

1. Откройте DNS и включите Proxy для записи www (это направит трафик на WebShield).
2. Откройте хост www в разделе Хосты.
3. Выберите режим Редирект на другой хост и укажите целевой хост, например example.com.
4. Сохраните параметры.

Посетители www.example.com будут получать 301-редирект на example.com с сохранением исходного пути и параметров. Сертификат для www выпускается автоматически.

Кеш

Проксируемый хост раздаётся через кеш на edge-узлах — том самом, что стоит ближе к посетителю.

Файлы кешируются всегда. Картинки, стили, скрипты, шрифты, медиа — всё, что опознаётся по расширению. Если ваш сервер прислал Cache-Control, мы соблюдаем его буквально. Если промолчал — держим файл час, а по истечении срока спрашиваем ваш сервер условно: не изменился — он отвечает коротким «тем же самым», и перекачки нет.

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

• со стороны вашего сервера — отдавайте Cache-Control: public, max-age=600 (или s-maxage) на тех страницах, которые одинаковы для всех. Ничего настраивать у нас не нужно;
• переключателем «Кешировать страницы» на странице хоста — тогда HTML молчаливого сервера хранится у нас минуту. Минуты достаточно, чтобы всплеск трафика (или атака) превратился для вашего сервера в один запрос на страницу вместо тысяч.

Что не попадёт в кеш ни при каких настройках: ответы с Cache-Control: private, no-store, no-cache, ответы, устанавливающие cookie, и всё, что запрошено с заголовком Authorization или с cookie сессии — такие запросы всегда идут на ваш сервер напрямую.

Осторожно

Прежде чем включать кеш страниц, убедитесь, что страницы, отличающиеся для вошедших пользователей, отдаются с Cache-Control: private. Мы пропускаем мимо кеша запросы с типовыми сессионными cookie, но знать про вашу собственную схему авторизации мы не можем.

Проверить и сбросить

В ответе приходит заголовок X-Proxy-Cache: HIT — отдано из кеша, MISS — ходили на ваш сервер, BYPASS — запрос признан персональным.

Кнопка «Сбросить кеш» на странице хоста мгновенно обесценивает всё закешированное для этого хоста на всех узлах. Она нужна после выкладки, если файлы обновились под прежними именами; если имена содержат версию или хеш, сбрасывать ничего не требуется.

Доля попаданий в кеш и объём, отданный из него, видны в разделе «Статистика».

Исключения проверок

Исключения снимают с указанных путей перенаправление на проверку браузера — и экран защиты от ботов, и автоматические проверки, которые применяются независимо от переключателя защиты. Они нужны там, где перенаправление ломает клиента по своей природе: WebSocket-соединения, вызовы API, мобильные и серверные SDK.

Что на этих путях продолжает действовать: фильтрация вредоносных запросов, ограничение частоты обращений и блокировки адресов. Исключение отключает проверку посетителя, а не защиту сайта.

Исключения задаются построчно. Добавляйте только необходимые адреса и не исключайте разделы с пользовательскими данными, формами входа или административными функциями.

Правила:

• максимум 50 исключений;
• каждое исключение должно начинаться с /;
• нельзя указывать корень /;
• нельзя использовать ..;
• максимальная длина одного исключения - 200 символов;
• разрешены буквы, цифры, /, _, ., -, *;
• * используется как маска в конце сегмента.

Как работает текущий CDN

CDN — это reverse proxy перед сайтом: запись DNS указывает на WebShield, запрос приходит к нам, проходит защитные проверки и только потом идет на ваш origin.

В статистике трафик «пользователь → WebShield» и «WebShield → бэкенд» показан отдельно — сразу видно, сколько нагрузки снимают кеш и защита.

Прямые обращения к серверу

Пока сайт за нами, адрес вашего сервера остаётся доступным всем, кто его знает, — и такой запрос проходит мимо защиты целиком. Закрывается это секретным заголовком, который мы добавляем к каждому запросу на ваш сервер: Доступ к серверу только через WebShield.