Блог Clearway

Аренда сервера для VPN: какой VPS брать, чтобы его не блокировали

Коротко

Для личного VLESS/Xray хватает самого дешёвого VPS: 1 vCPU, 1 ГБ RAM, KVM, ядро 5.x+ с BBR — производительность упирается не в железо, а в сеть и IP. Главный выбор при аренде сервера для VPN не «где мощнее», а «какой IP». Зарубежный VPS дешевле (от ~4–5 $/мес) и проще, но в зоне белых списков его дата-центровый IP не входит в whitelist оператора и режется ТСПУ независимо от Reality. РФ-хостер с whitelisted-подсетью (по проверкам — часть /24 Selectel, отдельные диапазоны Yandex Cloud) белый список переживает, но такие IP добывают точечно по /24 и они «протухают». Любой сервер в дата-центре при белых списках уязвим: устойчивость даёт не сам VPS, а фронт через whitelisted-CDN перед ним. Residential-IP «белее» любого дата-центра, но под постоянную ноду он дорог, сидит за CGNAT и нестабилен.

Сколько железа реально нужно под VLESS/Xray

Главное заблуждение при аренде VPS для VPN — что нужен «мощный» сервер. Для VLESS на Xray (Remnawave, Marzban, 3x-ui) шифрование лёгкое, узкое место — канал и его качество, а не CPU.

Базовая конфигурация под личный сервис или небольшой сквад:

  • CPU: 1 vCPU. Одно ядро тянет сотни одновременных сессий VLESS; Reality/XTLS почти не грузят процессор.
  • RAM: 1 ГБ хватает, 2 ГБ — с запасом под панель и логи.
  • Диск: 10–20 ГБ SSD/NVMe. Трафик через диск не идёт, место нужно под ОС и панель.
  • Виртуализация: только KVM. OpenVZ/LXC не дадут своё ядро, tun-интерфейс и нужные sysctl-модули — берите KVM без исключений.
  • Ядро: 5.x+ ради BBR.

Включить BBR (Debian/Ubuntu), ощутимый прирост на плохих маршрутах до РФ:

cat >> /etc/sysctl.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl -p
# проверка:
sysctl net.ipv4.tcp_congestion_control # должно быть bbr

Что важнее гигагерц:

  • Ширина и стабильность канала — 100–200 Мбит/с без жёсткого шейпинга лучше, чем «10 Гбит/с shared» с ночными просадками.
  • Пиринг с РФ — низкий пинг и хорошая маршрутизация до Ростелеком/МТС/Мегафон важнее точки на карте. Проверяйте до покупки: mtr --report your.ip из сети целевого оператора.
  • Лимит трафика — «unlimited» часто скрывает FUP-порог, после которого режут скорость. Читайте мелкий шрифт.

Вывод: под VPN берут самый дешёвый адекватный VPS и вкладываются не в железо, а в правильный IP и сеть.

Гео: зарубежный VPS против РФ-хостера

Выбор гео при аренде сервера для VPN — компромисс между простотой и выживаемостью в зоне блокировок.

Зарубежный VPS (Германия, Нидерланды, Финляндия, Турция)

  • Плюсы: дёшево (по наблюдениям от ~4–5 $/мес), нет вопросов к контенту, легко платить, много локаций, никаких «белых списков на выход».
  • Минусы: в регионах с *белыми списками* (оператор пропускает трафик только на разрешённые подсети, остальное режет ТСПУ) зарубежный дата-центровый IP по умолчанию не в whitelist. Reality помогает против DPI, но против явного белого списка на уровне IP — нет. Плюс латентность выше.
  • Кому: аудитории вне зоны жёстких белых списков и как запасной выход.

РФ-хостер

  • Плюсы: низкий пинг, хороший локальный пиринг и — главное — часть подсетей физически попадает в whitelist мобильных операторов, то есть переживает белый список.
  • Минусы: не любая площадка и не любая её подсеть «белая»; whitelist работает по конкретным /24, а не по хостеру целиком; вопросы к легальности сервиса на территории; IP надо подбирать и проверять.

Правило 2026 года: если поднимаете сервис для аудитории в зоне белых списков (мобильный интернет отдельных регионов РФ в моменты «шатдаунов»), гео вторично — первично, входит ли IP сервера в whitelist оператора. Об этом ниже.

Whitelist-хостеры РФ: почему IP важнее гео

Когда оператор включает белый список, он пропускает трафик только на заранее разрешённые подсети (банки, госсервисы, часть CDN, отдельные хостинги), а всё прочее дропает на ТСПУ. VPS выживает, только если его IP лежит в такой подсети.

Ключевой факт, ломающий интуицию: whitelist работает на уровне /24, а не хостера или ASN целиком. Один /16 бывает разбит между владельцами — одна /24 «белая», соседняя нет. «Весь такой-то хостер в whitelist» — так не бывает.

По проверкам из мобильных сетей РФ (2026, картина плавающая):

  • Selectel (AS49505) — ряд подсетей стабильно проходят ТСПУ в белом списке; самый реалистичный кандидат под собственный whitelisted-сервер.
  • Yandex Cloud — часть диапазонов работает, часть выпала (например, 51.250.0.0/16 в какой-то момент перестал проходить).
  • cloud.ru / SberCloud (Cloud Technologies LLC) — по наблюдениям не проходят, хотя гео РФ; наличие аккаунта не помогает.

Как проверять на практике:

  1. Создаёте ВМ, получаете IP.
  2. Смотрите владельца и ASN подсети, сверяете с открытыми cidr-списками whitelist мобильного интернета РФ:
whois -h whois.radb.net 85.215.200.163 # origin ASN и netname
curl -s https://ipinfo.io/85.215.200.163/json # org, route /24
  1. Обязательно делаете реальное тест-подключение из мобильной сети нужного региона — единственная 100% проверка. Офлайн-сверка лишь отсеивает заведомо мёртвое.

Оговорка честности: whitelist динамичен. Сегодня /24 «белая», через неделю её убрали. Строить весь сервис на одном таком IP — риск; «белый VPS» это не разовая покупка, а процесс подбора и мониторинга. Подробный разбор диапазонов и методики — в отдельном материале про белые списки на этом блоге.

На что смотреть, чтобы сервер не блокировали

Аренда сервера — половина дела; вторая половина в настройке, чтобы не подставить ноду под блок.

  • Свежесть IP. Спрашивайте у хостера, не «палёный» ли адрес. Переиспользованные IP из-под прошлых VPN/спама часто уже в чёрных списках Google/Cloudflare — ловите капчи и баны ещё до всякого ТСПУ. Быстрая проверка: зайдите с сервера на ipquery.io или откройте Google — если сразу капча, IP грязный.
  • Абузоустойчивость и юрисдикция. У зарубежных площадок узнайте политику DMCA/abuse, иначе ноду снесут за торренты соседа по пулу.
  • Свой домен + валидный TLS. Для маскировки (Reality, XHTTP, WS+TLS) нужен домен и нормальный сертификат. Голый IP на:443 без TLS — маркер VPN для DPI.
  • Порты. 443/TCP выглядит как обычный HTTPS. Нестандартные высокие порты и явный VMess/Shadowsocks без обёртки палятся эвристиками.
  • Не светите один SNI на всех. Общий домен на многих клиентов — один бан по SNI кладёт всех сразу.
  • Разнесите панель и данные. Админку Remnawave/Marzban держите за отдельным контуром, а не на том же:443, что канал.
  • Резервный выход. Даже белый IP выпадает из whitelist — заранее держите второй сервер в другой подсети/гео и переключение по сквадам.

Отдельно про *дата-центровую природу* IP: любой адрес из хостинг-ASN вычисляется и банится пачками. Reality скрывает факт VPN, но не меняет того, что IP «датацентровый». При белом списке датацентровый origin — самое слабое звено.

Дата-центр против residential: где предел

Все обычные VPS — это дата-центровые IP: принадлежат хостинг-ASN, публично известны, банятся диапазонами. Residential-IP выдаётся домашним провайдером (Ростелеком, Билайн, местные ISP) и «белее» почти по определению — оператору дорого и политически неудобно резать собственных абонентов.

Дата-центр (обычный VPS)

  • Дёшево, стабильно, полный root, легко масштабировать и автоматизировать.
  • Уязвим к белым спискам и массовым банам подсетей. Спасают либо точечный whitelisted-IP (см. выше), либо фронт через CDN.

Residential (домашний IP как нода)

  • Максимальная «белизна», трудно отличить от обычного абонента.
  • Но почти всегда CGNAT (нет белого внешнего IP — входящее подключение без туннеля/реле не поднять), динамический адрес, слабый асимметричный аплинк, зависимость от того, что дома не выключат ПК/роутер. Аренда «residential» у прокси-провайдеров считается по трафику, а не фиксом, — дорого и не рассчитано на постоянную ноду.
  • Реалистичная роль residential — точечный fallback на время шатдауна, а не основа сервиса. И даже гипотеза «домашний IP автоматически в whitelist» требует реальной проверки: CGNAT-адрес может вести себя иначе.

Итог: для 99% операторов основа — обычный VPS, а «белизну» решают не сменой сервера на residential, а слоем перед сервером.

Когда одного сервера мало: фронт через whitelisted-CDN

Тезис, экономящий месяцы охоты за «белыми» IP: сервер в дата-центре при белых списках блокируется легко; устойчивость даёт не сам VPS, а фронт перед ним через whitelisted-CDN.

Логика простая. Клиент по TLS подключается не к вашему origin, а к edge-узлу CDN, чей IP уже в whitelist оператора (по проверкам — часть подсетей Yandex CDN, VK, Ngenix, Gcore, CloudMTS попадают в белые списки). Edge по XHTTP тянет трафик с origin. При этом origin-нода не обязана быть whitelisted вообще — «белизну» на клиентской стороне обеспечивает edge, а origin арендуете где угодно и дешевле.

Что это меняет в выборе сервера:

  • Отпадает мучительная охота за whitelisted /24 под сам VPS — берёте обычный VPS с хорошим каналом, белый вход даёт CDN.
  • Один заблокированный edge/SNI не кладёт всё, если фронтов несколько.
  • Origin прячется: его прямой IP клиенты не видят, значит найти и заблокировать его труднее.

Это не серебряная пуля: edge может сесть на не-белую /24 (проверяйте реальный адрес после поднятия), а SSE-буферизация на части CDN подтормаживает downlink. Но как архитектура устойчивости фронт-через-CDN сегодня надёжнее и дешевле в сопровождении, чем ставка на один «вечно белый» IP. Кому не хочется собирать это самим — есть whitelist-CDN как готовый сервис для VPN-нод. Технические детали (XHTTP packet-up, инбаунды, кэш) разобраны в отдельных статьях про Remnawave/панели за CDN.

Частые вопросы

Какой минимальный VPS хватит для личного VPN на VLESS?

1 vCPU, 1 ГБ RAM, 10–20 ГБ диска, обязательно KVM и ядро 5.x+ с включённым BBR. Для VLESS/Xray этого достаточно на сотни сессий — упор делайте не на железо, а на качество канала, пиринг с РФ и правильный IP.

Зарубежный или российский сервер брать под VPN?

Вне зоны жёстких белых списков проще и дешевле зарубежный VPS (от ~4–5 $/мес). Если аудитория попадает под белые списки мобильных операторов РФ, зарубежный датацентровый IP там режется ТСПУ независимо от Reality — нужен либо РФ-хостер с whitelisted-подсетью, либо фронт через whitelisted-CDN перед любым сервером.

Какие РФ-хостеры входят в whitelist операторов?

По проверкам из мобильных сетей — часть подсетей Selectel и отдельные диапазоны Yandex Cloud проходят; cloud.ru/SberCloud по наблюдениям нет. Но whitelist работает по конкретным /24, а не по хостеру целиком, и статус меняется — любой IP надо проверять реальным подключением из нужного региона.

Почему мой сервер блокируют, хотя стоит Reality?

Reality маскирует факт VPN от DPI, но не меняет того, что IP датацентровый и известен. При белом списке оператор режет по IP-подсети независимо от протокола. Частая вторая причина — «палёный» переиспользованный IP уже в чёрных списках. Решения: whitelisted-IP, фронт через CDN, свежий адрес и свой домен с валидным TLS.

Можно ли использовать домашний (residential) IP как VPN-сервер?

В теории он «белее» датацентрового, но на практике мешают CGNAT (нет внешнего белого IP для входящих), динамический адрес и слабый аплинк. Реалистичная роль residential — точечный резерв на время шатдауна, а не основа сервиса; аренда residential под постоянную ноду дорогая и нестабильная.

Как арендовать сервер, чтобы его не заблокировали при белых списках?

Надёжнее не искать «вечно белый» IP под сам VPS, а поставить перед обычным сервером фронт через whitelisted-CDN: клиент бьёт в edge с белым IP, edge по XHTTP тянет трафик с вашего origin, который whitelisted быть не обязан. Плюс держите резервный сервер в другой подсети и переключение по сквадам.

Читайте также

Whitelisted-вход для вашего VPN-сервиса

Clearway даёт «белый» CDN-вход перед вашей нодой — устойчивый к троттлингу операторов. Первые 10 ГБ бесплатно, без карты.

Попробовать →