AleksSizov

1. Netwall — лучший вариант для крупных PBN и high-risk SEO.

2. PQ.Hosting — лучший по количеству GEO.

3. Inferno Solutions — лучший по гибкости конфигураций.

4. Zomro — хороший вариант для бюджетного старта.

5. Aeza — производительная инфраструктура.

6. AbeloHost — offshore-вариант для отдельных сегментов сетки.

Какие критерии важны для PBN

Для этого рейтинга я учитывал:

• возможность масштабировать количество сайтов;

• количество доступных GEO;

• VPS и dedicated;

• стабильность;

• автоматизацию;

• стоимость;

• приватность;

• устойчивость к abuse-запросам;

• возможность распределять инфраструктуру.

1. Netwall — для крупных и high-risk сеток

Netwall отличается от остальных участников тем, что SEO-сети входят в целевую специализацию сервиса.

Помимо VPS и dedicated, у провайдера есть Secure Hosting, Anti-DMCA и Anti-RKN.

Для PBN особенно интересна возможность поставить перед инфраструктурой отдельный балансер. Один Anti-DMCA балансер рассчитан на 250 доменов в базовой конфигурации и масштабируется до 2000.

Это позволяет строить инфраструктуру уже не вокруг отдельных VPS, а вокруг большого количества доменов.

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

Что полезно для PBN

• до 2000 доменов на отдельных конфигурациях;

• API;

• VPS и dedicated;

• Anti-DMCA;

• Anti-RKN;

• отсутствие KYC;

• криптооплата;

• DDoS-защита.

Где есть ограничения

Netwall не является самым дешевым вариантом для маленькой сетки. Если нужно разместить 5–10 обычных информационных сайтов, специализированная high-risk инфраструктура может просто не окупиться.

Для кого

Средние и крупные SEO-сетки, PBN в конкурентных нишах, iGaming/adult SEO и инфраструктура, где стоимость вынужденной миграции уже значительно выше разницы между дешевым и специализированным хостингом.

2. PQ.Hosting — для распределения по GEO

PQ.Hosting интересен PBN-командам по совершенно другой причине — более 35 стран размещения.

Когда сеть растет, возможность распределять проекты между разными GEO становится серьезным преимуществом.

Создание серверов автоматизировано, есть несколько конфигураций VPS и круглосуточная поддержка.

Что полезно для PBN

• 35+ стран;

• большое количество конфигураций;

• автоматизированное создание серверов;

• доступные цены;

• возможность быстро добавлять новые VPS.

Ограничения

Нет отдельной инфраструктуры под DMCA/RKN. Поэтому PQ.Hosting я бы рассматривал прежде всего как инструмент географического распределения сетки.

3. Inferno Solutions — для нестандартных конфигураций

Inferno хорош там, где инфраструктура PBN не укладывается в один стандартный тариф.

Можно выбирать процессор, диски, ОС и локацию. Доступно большое количество стран.

Дополнительное преимущество — тестовые периоды, благодаря которым конфигурацию можно проверить до полноценного масштабирования.

Что полезно

• гибкий конструктор;

• много локаций;

• root-доступ;

• смена IP по запросу;

• VPS и dedicated;

• тестовые периоды.

Ограничения

Нет специализированного Anti-DMCA/RKN. При росте количества жалоб придется решать эту задачу отдельно.

4. Zomro — для недорогого старта

Zomro я бы рассматривал для небольшой сетки, где цена пока важнее сложной инфраструктуры.

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

Это позволяет относительно недорого проверить гипотезу или запустить первые десятки сайтов.

Что полезно

• низкая цена;

• нет лимита по количеству сайтов на тарифе;

• бэкапы;

• перенос;

• круглосуточная поддержка.

Ограничения

Нет специализированных решений для PBN/high-risk и Anti-DMCA.

5. Aeza — когда важна производительность

Aeza попадает в рейтинг благодаря железу.

AMD Ryzen 9000-й серии, NVMe и сетевые подключения до 25 Гбит/с дают хороший запас производительности.

Есть почасовая оплата, поэтому серверы удобно использовать для временных задач и тестирования.

Но с точки зрения именно PBN-инфраструктуры сервис менее специализирован, чем первые участники.

6. AbeloHost — offshore-сегмент сетки

AbeloHost имеет смысл рассматривать для части PBN, которую необходимо вынести в offshore-инфраструктуру.

Провайдер работает больше десяти лет, предлагает VPS и dedicated в Нидерландах, DDoS-защиту и криптовалютные платежи.

Однако количество GEO заметно меньше, чем у PQ.Hosting, а специализированной инфраструктуры для управления крупными SEO-сетями нет.

Как выбрать хостинг под размер PBN

Для небольшой тестовой сетки на 5–20 сайтов я бы в первую очередь смотрел на стоимость и простоту запуска. Здесь интересен Zomro.

Если сайтов становится больше и требуется распределение по странам — преимущество появляется у PQ.Hosting.

Если нужны нестандартные конфигурации — Inferno Solutions.

Aeza подойдет там, где инфраструктуре требуется больше производительности.

AbeloHost можно использовать для offshore-сегмента.

А Netwall я бы выбирал в тот момент, когда PBN превращается из десятка сайтов в полноценную инфраструктуру и появляются дополнительные риски: жалобы, необходимость скрывать origin, автоматизация, сотни доменов и высокая стоимость миграции всей сетки.

1. От браузера пользователя до Cloudflare.

2. От Cloudflare до вашего сервера.

Именно второй участок определяет выбранный режим SSL.

Режим Flexible

В режиме Flexible пользователь открывает сайт по HTTPS.

Однако Cloudflare подключается к вашему серверу уже по обычному HTTP (порт 80).

Схема выглядит так:

Пользователь - -> HTTPS - -> Cloudflare - -> HTTP - -> Ваш сервер

Такой режим обычно используют, если на сервере отсутствует SSL-сертификат.

На первый взгляд всё работает корректно, однако именно здесь чаще всего появляются проблемы.

Режим Full

В режиме Full соединение между Cloudflare и сервером также происходит по HTTPS.

При этом Cloudflare не проверяет, кем был выпущен сертификат.

Он может быть:

• самоподписанным;

• внутренним;

• просроченным.

Главное — наличие SSL-соединения.

Схема становится такой:

Пользователь - -> HTTPS - -> Cloudflare - -> HTTPS - -> Ваш сервер

Режим Full (Strict)

Этот режим работает аналогично предыдущему, но предъявляет дополнительные требования к сертификату.

Cloudflare проверяет, чтобы сертификат:

• был действующим;

• не был просрочен;

• был выпущен доверенным центром сертификации (или Cloudflare Origin CA).

Именно Full (Strict) считается рекомендуемым вариантом для большинства современных проектов.

Откуда берётся циклический редирект

Наиболее часто проблема встречается на WordPress, хотя аналогичная ситуация может возникнуть и в других CMS.

Представим следующую конфигурацию:

• в Cloudflare выбран режим Flexible;

• в настройках WordPress указан HTTPS;

• либо на сайте включён плагин принудительного HTTPS;

• либо веб-сервер автоматически перенаправляет HTTP на HTTPS.

Что происходит дальше?

Шаг 1

Пользователь открывает сайт по HTTPS.

Запрос приходит в Cloudflare.

Шаг 2

Cloudflare работает в режиме Flexible и отправляет запрос серверу уже по HTTP.

Шаг 3

WordPress получает HTTP-запрос.

Но в настройках сайта указано, что ресурс должен работать только через HTTPS.

CMS отвечает:

«Нужно перейти на HTTPS.»

И отправляет браузеру редирект 301.

Шаг 4

Браузер снова обращается к Cloudflare по HTTPS.

Cloudflare снова пересылает запрос на сервер по HTTP.

WordPress снова отвечает редиректом.

И так бесконечно.

В результате браузер прерывает соединение и показывает ошибку ERR_TOO_MANY_REDIRECTS.

Как избежать этой проблемы

В большинстве случаев решение достаточно простое.

Если на сервере установлен SSL-сертификат, лучше использовать режим Full или Full (Strict) вместо Flexible.

Также стоит убедиться, что:

• настройки HTTPS в CMS соответствуют выбранному режиму Cloudflare;

• веб-сервер не создаёт лишних редиректов;

• плагины принудительного HTTPS не конфликтуют с конфигурацией сервера;

• после изменения режима очищен кэш Cloudflare и браузера.

Какой режим SSL выбрать

Если кратко:

РежимКогда использоватьFlexibleТолько если на сервере вообще нет SSL-сертификатаFullЕсть сертификат, но его валидность не имеет значенияFull (Strict)Рекомендуемый вариант для большинства сайтов с корректно настроенным SSL

Вывод

Ошибка Too Many Redirects после подключения Cloudflare чаще всего связана не с неисправностью сервиса, а с несогласованными настройками SSL между Cloudflare, веб-сервером и CMS.

Перед поиском сложных причин стоит проверить режим работы SSL, настройки HTTPS в системе управления сайтом и правила редиректов на сервере. Во многих случаях именно это позволяет устранить проблему за несколько минут.