🔐 Netwall Hosting — абузоустойчивая инфраструктура под SEO и Arbitrage

Общий upstream в Кан+Саб: как управлять сеткой из десятков доменов через один backend

Базовый сценарий Кан+Саб — несколько публичных адресов работают через один upstream. Это может быть основной домен, группа зеркал, региональные сабдомены или отдельные точки входа affiliate-кампании.

Посетитель открывает нужный домен или сабдомен. Netwall принимает запрос, применяет правила участника и обращается к указанному upstream. При проксировании публичный адрес в браузере не меняется.

Например, запросы к адресам:

site.example
promo.site.example
de.site.example

могут обрабатываться через один backend, но каждый участник сохраняет собственный hostname и собственные SEO-настройки.

Практические кейсы:
SEO-зеркала. Группа доменов направляется на общий upstream, а для каждого участника применяется нужный canonical.

Несколько входов в affiliate-воронку. Разные рекламные домены и сабдомены ведут к одному backend-сценарию без видимого перенаправления пользователя.

Поэтапное подключение новых адресов. Новый домен добавляется участником существующей
сети и получает уже подготовленную логику маршрутизации.

Переключение backend. Маршрут сети можно перевести на другой upstream без замены публичных ссылок в рекламе и поисковой выдаче.

При необходимости отдельному участнику назначается собственный upstream. Поэтому общая схема не лишает сеть точечных исключений.

🛡 Абузоустойчивый хостинг, Кан+Саб:

📩 Подключить хостинг: @netwall_host
🤖 Оформить заявку в боте
📣 Netwall — канал о защите SEO-проектов

#обновления
#кансаб

Как конкуренты выбивают сайты из ТОП-3 Google с помощью DDoS

DDoS обычно воспринимают как техническую проблему: сайт атакуют, сервер не справляется с нагрузкой и какое-то время проект становится недоступен.

Но в конкурентных SEO-нишах, недоступность сайта может ударить и по его присутствию в поисковой выдаче.

Google регулярно обходит сайты своими ботами и проверяет в том числе их доступность. Если во время очередного обхода Googlebot приходит на сайт, а тот не отвечает из-за DDoS, поисковик видит недоступный ресурс.

Разовая кратковременная проблема ещё не означает, что сайт сразу исчезнет из выдачи. Но если недоступность продолжается и при повторных обходах ситуация не меняется, сайт может начать терять своё присутствие в поиске.

Целью DDoS может быть именно длительная недоступность сайта, чтобы последствия дошли уже до поисковой выдачи.

При этом сама атака тоже может выглядеть совершенно по-разному:

✔ Можно атаковать непосредственно IP сервера, если удалось его определить

✔ Можно создавать такое количество запросов, что переполняется очередь их обработки

✔ Можно бить по веб-серверу, пока он не начнёт ограничивать запросы и отдавать ошибки вроде: 429, 502 Bad Gateway, 504 Gateway Timeout и 503 Service Unavailable.

А можно сначала изучить сайт, найти наиболее ресурсоёмкие участки и направить нагрузку именно туда.

То есть «DDoS» — это далеко не всегда сценарий, когда на сервер просто отправляют огромное количество одинаковых запросов.

Одна из важных задача для SEO-проекта: сохранить сайт доступным для реальных пользователей и поисковых ботов даже во время атаки.

Потому что если инфраструктура не выдерживает DDoS, последствия могут закончиться далеко не только несколькими часами простоя.

🛡 Нужна абузоустойчивая защита от DDoS и блокировок?

📩 Подключить хостинг: @netwall_host
🤖 Оформить заявку в боте
📣 Канал с кейсами и гайдами

Новые инструменты Netwall: проверены на реальных SEO-сетках

Недавно мы выкатили большое обновление Netwall и теперь хотим подробнее рассказать о новых возможностях.
До публичного релиза часть инструментов некоторое время работала в приватном режиме. Мы давали к ним доступ нескольким крупным SEO- и affiliate-командам, собирали обратную связь и дорабатывали функционал под их реальные задачи.

Поэтому кейсы, которыми мы будем делиться дальше, — не придуманные сценарии. Они основаны на том, как эти инструменты уже используют команды в работе с крупными сетками.

⚙️ Что появилось в Netwall:
✓ Кан+Саб — управление доменами, сабдоменами, маршрутами и SEO-правилами как единой сетью
✓ Клоакинг — разные сценарии показа и обработки для разных аудиторий
✓ Субаккаунты — разграничение доступов для сотрудников, подрядчиков и AI-агентов
✓ Netwall MCP — управление инфраструктурой и автоматизация задач через AI

🔥 И главное: весь новый функционал доступен пользователям балансеров абсолютно бесплатно.

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

Абузоустойчивый хостинг, балансер:
📩 Подключить хостинг: @netwall_host
🤖 Оформить заявку в боте
📣 Канал с кейсами и гайдами

#обновления

Зачем конкуренты превращают обычную Trademark-жалобу в обвинение в фишинге

Иногда обычные Trademark-жалобы могут приводить к более неприятным последствиям чем можно было бы ожидать. Всё дело в том, что такие абузы могут специально "усиливать", чтобы они квалифицировались как более серьёзные. Цель - повысить вероятность блокировки сайта

Как это происходит?

Допустим, компания считает, что кто-то использует её бренд или торговую марку. По сути, это обычный Trademark-спор

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

Например:
— fraud
— phishing
— мошенничество
— введение пользователей в заблуждение

Хотя по факту сама ситуация остаётся той же самой — речь идёт об использовании торговой марки. Зачем это делают?

Для большинства хостинг-провайдеров жалоба на торговую марку — это одна категория обращений.

А вот сообщения о фишинге или мошенничестве воспринимаются уже совсем иначе. Соответственно, вероятность того, что провайдер начнёт реагировать быстрее и жёстче, становится выше.

Но есть ещё один важный момент, если сайт работает через Cloudflare

На phishing-абузы Cloudflare может реагировать самостоятельно: при попытке открыть сайт пользователь получает предупреждение о том, что ресурс может быть фишинговым, и продолжает переход уже на свой страх и риск

Чтобы избавиться от такой плашки, владелец проекта может решить отключить проксирование Cloudflare и направить трафик непосредственно на свой хостинг.

В результате инфраструктура, которая до этого находилась за проксированием Cloudflare, оказывается под прямым ударом.
И уже после отключения проксирования может начаться DDoS-атака. Это происходит не всегда, но такой сценарий встречается.

Получается целая цепочка:

Trademark-жалоба → обвинение в phishing/fraud → предупреждение Cloudflare → отключение проксирования → возможный DDoS по инфраструктуре

Из-за самой природы работы Cloudflare жалоба может быть передана дальше — непосредственно хостинг-провайдеру

Изначально phishing-abuse мог отправить кто угодно. Но хостер в итоге получает информацию о возможном фишинге уже от Cloudflare — сервиса, которому провайдеры доверяют

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

В результате первоначально обычная Trademark-претензия, в которую добавили обвинение в phishing, может пройти сразу по нескольким уровням:

1. Cloudflare реагирует на phishing-abuse и может показать посетителям предупреждение о потенциально опасном сайте.

2. Жалоба передаётся дальше хостинг-провайдеру, но приходит к нему уже через доверенный источник — Cloudflare.

3. Хостер может отреагировать на phishing значительно жёстче, не разбираясь подробно, насколько первоначальное обвинение соответствует реальности.

А дальше возможен ещё один сценарий: владелец сайта отключает проксирование Cloudflare, чтобы избавиться от предупреждения, открывает свою инфраструктуру — и после этого по хостингу может начаться DDoS.

Так одна усиленная Trademark-жалоба потенциально создаёт сразу несколько точек давления на проект.


Netwall — канал о защите SEO-проектов

Почему некоторые доменные зоны теряют сайты после одной жалобы

Когда выбирают домен для нового проекта, обычно смотрят на три вещи:

— красивое название
— стоимость регистрации
— свободен ли домен

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

Далеко не все TLD одинаково реагируют на жалобы.

Есть классические международные зоны, такие как .com, .net или .org

Есть национальные доменные зоны: .ua, .pl, .es, .ru и многие другие.

А есть тематические и менее распространённые TLD

У каждой из них свои правила и свои принципы обработки обращений. Некоторые доменные зоны относятся к жалобам достаточно спокойно и требуют дополнительных разбирательств.

Другие могут реагировать значительно жёстче. Встречаются TLD, где для блокировки домена может оказаться достаточно одного обращения.

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

При этом проблема далеко не всегда в регистраторе. Регистратор лишь работает с выбранной доменной зоной.

Во многих случаях именно политика конкретного TLD определяет, насколько легко домен может попасть под ограничения.

При выборе домена для SEO-проектов важно оценивать не только стоимость регистрации.

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

Netwall — канал о защите SEO-проектов

Абузы могут угрожать не только хостингу, а и самому домену.

Когда речь заходит про риски для SEO-проектов, большинство сразу вспоминает DMCA. Но есть сценарий, который может оказаться намного неприятнее.

Это жалоба регистратору домена. Если DMCA чаще всего создаёт проблемы с видимостью сайта, то жалоба регистратору может поставить под угрозу сам домен. А вместе с ним и весь проект.

Многое зависит от конкретного регистратора и его внутренних правил. От того, как именно он работает с жалобами. И даже от того, какой сотрудник будет рассматривать обращение.

Есть регистраторы, которые реагируют крайне быстро. Некоторые могут не только заблокировать домен, но и создать проблемы для других доменов внутри того же аккаунта.

Для high-risk проектов имеет смысл обращать внимание на косвенные признаки:
— принимает ли регистратор криптовалюту;
— требует ли обязательный KYC;
— насколько жёстко он относится к жалобам.

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

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

При этом важно понимать: выбор регистратора — это не защита от абуз.

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

Netwall — канал о защите SEO-проектов

Как мы сократили до 95% мусорного трафика до того, как он дошёл до сервера

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

Когда мы столкнулись с этой проблемой, стало понятно: просто увеличивать ресурсы сервера — не лучший путь.

Можно бесконечно добавлять процессоры, память и новые VPS, но если до сервера продолжает доходить тот же объём нежелательных запросов, проблема никуда не исчезает.

Поэтому решение искали не на стороне серверов, а на стороне фильтрации трафика.

Для этого начали использовать BetaWall.

На первом этапе система собирала базу плохих IP-адресов — источников трафика, которые регулярно участвовали в сканировании сайтов. Со временем эта логика была перенесена на балансеры.

В результате фильтрация начала происходить ещё до того, как запросы доходили до конечного сервера. То есть VPS или выделенный сервер больше не тратили свои ресурсы на обработку заведомо бесполезного трафика.

Такой подход позволяет отсекать порядка 90–95% сканер-ботов. Причём речь идёт не о блокировке уже после того, как сервер начал испытывать нагрузку.
Задача — не допустить эти запросы до сервера вообще.

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

Именно поэтому при росте сетки сайтов важно смотреть не только на характеристики VPS или сервера. Во многих случаях гораздо больше пользы приносит грамотная фильтрация трафика ещё до того, как он попадает внутрь инфраструктуры.

Netwall — канал о защите SEO-проектов

Когда VPS уже недостаточно

Один из самых популярных вопросов: «Сколько сайтов можно разместить на VPS?». На практике правильнее уточнять, какие именно сайты.

Например, если речь идёт о сетке из 20–50 сайтов, то в большинстве случаев VPS будет вполне достаточным решением. Даже для 100 сайтов не всегда есть смысл сразу смотреть в сторону выделенного сервера.

Но дальше всё зависит от того, как именно устроены проекты

Сетка из 100 HTML-сайтов и сетка из 100 WordPress-сайтов — это две совершенно разные нагрузки.

Если речь идёт о простой HTML-генеренке, то и 100, и даже 200 сайтов могут спокойно работать на VPS.

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

Именно поэтому после отметки примерно в 100 сайтов уже стоит внимательно оценивать нагрузку и смотреть, не пора ли переходить на выделенный сервер.

Причём проблема здесь не только в посетителях. Очень часто основную нагрузку создают сканер-боты.

Те самые системы, которые постоянно ищут:
— уязвимости
— открытые панели управления
— резервные копии
— служебные файлы
— слабые места в инфраструктуре

Каждый такой запрос потребляет ресурсы сервера. Поэтому оценивать инфраструктуру только по количеству сайтов — ошибка.

Важно понимать:
— какой используется движок
— сколько запросов обрабатывается
— насколько ресурсоёмкие операции выполняются
— какой объём мусорного трафика приходит на сервер

Именно поэтому переход с VPS на выделенный сервер обычно связан не с количеством сайтов как таковым.

Он связан с реальной нагрузкой, которую эти сайты создают.

Netwall — канал о защите SEO-проектов

Shared Hosting — коммуналка, которая может похоронить ваш проект

Многие выбирают shared hosting по простой причине: дешево и не нужно разбираться в инфраструктуре. Загрузил сайт, настроил панель управления и работаешь.

Но для SEO-проектов в конкурентных нишах это одно из самых рискованных решений.

Проблема в том, что shared hosting — это сервер на котором root не вы

Если сравнивать простыми словами, это как камера хранения на вокзале. У вас есть своя ячейка, но сам шкаф принадлежит не вам. Вы не контролируете операционную систему, сервер и файловую систему целиком.
А значит, хостинг имеет полный доступ к тому, что находится внутри аккаунта.

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

Если система находит триггерные темы вроде casino, crypto или других категорий, которые хостинг считает нежелательными, дальше подключается живой модератор. Именно поэтому некоторые сайты блокируются даже без внешних жалоб.

Есть ещё одна проблема — абузы

Если жалоба приходит на shared hosting, провайдеру зачастую проще быстро заблокировать аккаунт, чем разбираться в деталях.

Третья проблема — DDoS

Поскольку сервер общий для большого количества клиентов, любая атака становится проблемой не только для вас, но и для соседей по серверу.

В такой ситуации хостеру проще отключить проблемный сайт, чем рисковать стабильностью остальных клиентов.

Поэтому, всегда лучше несколько раз подумать, готовы ли вы строить высокорисковый проект на инфраструктуре, которую полностью контролирует кто-то другой.

Netwall — канал о защите SEO-проектов