Обход блокировки Hetzner / OVH / OnLine через NGINX ‑прокси

С июня 2025 года Роскомнадзор активно ограничивает зарубежные площадки: Hetzner, OVH, OnLine — любимые дата ‑центры российских разработчиков — всё чаще попадают под блокировки. Операторы фиксируют IP адреса в реестре, а абоненты, особенно мобильные (MTS, Beeline, Tele2, «Мегафон»), получают ERR_CONNECTION_TIMED_OUT. Полный переезд — дорого и долго. Проще «спрятать» исходный сервер за релейным NGINX ‑прокси на недорогом VPS внутри России или в «белой» стране.

В статье:

Как работает DPI блокировка и почему мобильные сети сложнее обходить;
Пошаговая настройка reverse proxy в NGINX: SSL, HTTP/2, кеш, ограничение скорости;
Рекомендации по DNS, SNI, ALPN и мониторингу;
FAQ — ответы на частые вопросы и типовые ошибки.

1. Механика блокировки: коротко о главном

1.1 DPI + реестр = двойная «гильотина»

Российские операторы применяют две технологии одновременно:

Реестр запрещённых ресурсов — статическая блокировка по IP и / или домену.
DPI‑фильтрация (Deep Packet Inspection) — анализ SNI и HTTP Host‑заголовков в реальном времени. Поэтому «сменить домен» без смены IP недостаточно, а HTTP без TLS здесь бессилен.

У мобильных провайдеров DPI агрессивнее: соединения режутся быстрее, а список IP обновляется чаще. Поэтому важно «спрятать» конечный дата‑центр за легальным, неблокируемым узлом и прокидывать трафик прозрачно.

2. Архитектура обхода

Origin‑сервер — ваш VPS/дедик в Hetzner / OVH / OnLine, IP которого заблокирован.
Промежуточный VPS — любой «чистый» хостинг с белым IP (Gcore, Selectel, Yandex Cloud, Leaseweb и т.д.). Именно здесь запускаем NGINX.
DNS — указывает только на «чистый» VPS. Мобильные пользователи видят его IP, DPI пропускает.
NGINX — принимает HTTPS, кеширует статику / медиапотоки, пускает запросы дальше на Origin по внутреннему адресу или публичному IP (заблокированному, но видимому только NGINX — провайдер его не сканирует).

3. Готовый конфиг NGINX c пояснениями

Ниже «минимально рабочий» пример для cdn.example.com (IP 203.0.113.10 — документарный, RFC 5737):


# /etc/nginx/conf.d/example.com.conf
server {
    listen              443 ssl http2;          # HTTP/2 улучшает скорость у мобильных
    server_name         example.com;        # замените на свой поддомен

    # --- TLS -----------------------------------------------------
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_session_cache   shared:SSL:10m;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # --- Проксируем только каталог /v/ --------------------------
    location /v/ {
        proxy_pass              https://203.0.113.10;   # <‑‑ Origin (Hetzner/OVH)
        proxy_http_version      1.1;                    # websockets / keep‑alive
        proxy_request_buffering off;                    # улучшает потоковую отдачу
        proxy_set_header        Host $host;             # передаём оригинальный host
        proxy_set_header        Range $http_range;      # поддержка докачки
        proxy_set_header        If-Range $http_if_range;
        
        limit_rate              2m;                     # ⟵ при необходимости
    }

    # --- Логи ----------------------------------------------------
    access_log  /var/log/nginx/example_access.log  main;
    error_log   /var/log/nginx/example_error.log   warn;
}

Зачем нужны ключевые директивы

http2 — мультиплексирование: одно соединение вместо десятков; особенно полезно на 4G.
proxy_request_buffering off — отдаём медиапоток «на лету», экономим RAM.
proxy_set_header Host $host — Upstream увидит правильный Host; важно для мультисайта.
limit_rate — опционально ограничивает исходящий канал, чтобы не забить VPS.

4. Шаг‑за‑шагом: полный чек‑лист

#	Действие	Команда / примечание
1	Берём «чистый» VPS	Ubuntu 22.04, 1 vCPU, 1 GB RAM хватит для ~10 Мбит
2	Устанавливаем NGINX Mainline	`apt install nginx`
3	Открываем 80/443 в фаерволе	`ufw allow "Nginx Full"`
4	Выпускаем TLS‑сертификат	`certbot --nginx -d cdn.example.com`
5	Создаём конфиг (см. выше)	`nano /etc/nginx/conf.d/cdn.example.com.conf`
6	Тестируем и рестартим	`nginx -t && systemctl reload nginx`
7	Правим DNS A‑запись	`cdn.example.com → IP VPS`
8	Проверяем	`curl -I https://cdn.example.com/v/test.mp4`

5. Дополнительные советы для устойчивости

5.1 Минимизируйте «следы» Origin‑сервера

Закройте исходный IP фаерволом iptables -s <VPS_IP> -j ACCEPT.
Переведите административную панель на отдельный порт + сеть 10.0.0.0/24.

5.2 Используйте несколько VPS‑прокси

Round‑robin в DNS или GeoDNS позволяет распределить нагрузку и пережить точечные блокировки.

5.3 Включите TLS 1.3 + ALPN h3 (HTTP/3)

У мобильных провайдеров HTTP/3 иногда идёт поверх QUIC «сквозь» DPI. В NGINX 1.25+ достаточно listen 443 quic reuseport; и ssl_protocols TLSv1.3;.

5.4 Мониторьте доступность

Скрипты curl или внешние сервисы (BetterStack, UptimeRobot) с точками из РФ показывают, не споткнулся ли прокси.

Reverse‑proxy на NGINX — самый быстрый способ вернуть доступ к сайту, расположенному на Hetzner, OVH или OnLine, без полной миграции. Ключевые моменты:

«Белый» VPS в нейтральной зоне + правильный TLS = трафик проходит DPI;
Кешируйте крупные файлы, чтобы экономить пропускную способность Origin;
Защитите исходный IP и всегда мониторьте доступность с точек в РФ.

Настройте конфиг за 30 минут — и ваши мобильные пользователи снова увидят сервис без танцев с VPN.

Преимущества такого решения

Скрытие реального IP. Roskomnadzor видит только IP «чистого» VPS с NGINX, а не заблокированный адрес origin. Это позволяет обойти DPI-фильтры, поскольку оператор не знает IP конечного сервера (аналогично проксированию через CDN).
Быстрое восстановление доступа. Настройка NGINX-прокси занимает минуты, вместо долгой и дорогой миграции сервисов. Как отмечают разработчики mkdev, перенос инфраструктуры в другую страну бессмыслен (не было гарантии, что РКН не заблокирует новые IP), а прокси-схема позволяет сразу вернуть работу сервиса.
Экономия ресурсов. NGINX может кэшировать большие статические файлы и медиа, снижая нагрузку на origin. Клиенты получают контент быстрее благодаря HTTP/2 и SSL-терминации на локальном сервере.
Низкая стоимость и простота. Требуется лишь недорогой VPS в нейтральном регионе и базовая настройка NGINX. Это дешевле, чем полная миграция инфраструктуры: достаточно указать новый A-запись DNS и установить SSL (например, с помощью certbot) на прокси.

Недостатки и ограничения

Дополнительная точка отказа. Если VPS-прокси упадёт (сбой хостинга или DDoS), российские пользователи снова потеряют доступ. У бюджетных VPS Uptime ≈99.9% (что означает ~42 минуты простоя в месяц), поэтому для надёжности лучше использовать резервные серверы.
Немного более медленное соединение. Из‑за дополнительного SSL-раунда и пересылки трафика скорость чуть ниже, чем при прямом подключении.
Ограниченные ресурсы. Пропускная способность и диск «белого» VPS обычно меньше, чем у origin. Нужно контролировать нагрузку (директива limit_rate в конфиге) и при возможности проксировать только нужные каталоги, иначе неожиданная нагрузка вызовет подозрения.
Вероятность повторной блокировки. Если Роскомнадзор обнаружит запрещённый контент на прокси, его IP тоже могут заблокировать. Поэтому важно фильтровать контент и не отдавать через прокси «лишнего».
Не вечное решение. Это скорее временный «патч» — при изменении механизмов фильтрации или усилении блокировок придётся перенастраивать прокси или искать новый VPS.

Когда и зачем применять

Экстренная мера. При резкой потере трафика из России прокси-сервер позволяет вернуть доступ «немедленно», пока разбираются юридические вопросы.
Альтернатива долгому переезду. Если полный перенос в «белый» дата-центр займёт много времени или ресурсов, промежуточный NGINX-прокси даст сервису время. Даже после переезда РКН может начать блокировать новые адреса, а прокси-схема служит буфером.
Кеширование крупных файлов. Подходит для сайтов с большим количеством статики/медиа (видео, изображения). NGINX-прокси отдаёт кешированные копии тяжёлого контента, экономя полосу origin и ускоряя загрузку.
Временная подстраховка. Можно включить прокси на время отказа от VPN или до переноса на российский хостинг, чтобы не потерять пользователей. Он даёт пользователям непрерывный доступ без сложной миграции.

Таким образом, NGINX reverse-proxy на «белом» VPS — самый простой способ быстро восстановить доступ к заблокированному ресурсу. Оно скрывает исходный сервер и не требует масштабного переезда, но требует контроля (надёжность VPS, объём трафика) и понимания, что это временный обходной путь.

Как обойти блокировку Hetzner, OVH и OnLine в России через NGINX‑прокси