К контенту
habrforever
ЖИВА #vless 2026 · ~3 мин чтения

Прокси MTProto | Обход ограничения на зарубежный трафик — актуализация 2026

оригинал на Хабре habr.com/…/1020804
снимок Wayback не сохранялся
статус на Хабре (ноябрь 2026) доступна
права © автор, переиздание в архивных целях с указанием источника

Прокси MTProto | Обход ограничения на зарубежный трафик

Архивное переиздание с актуализацией. Оригинал опубликован на Habr (2026), автор — неизвестен. оригинал доступен на Habr по состоянию на ноябрь 2026. Ниже — редакция ноября 2026: что работает сейчас, что изменилось и как правильно повторить рецепт сегодня. Полный текст оригинала — в конце, без купюр.

TL;DR — версия 2026

VLESS+REALITY (Xray) в 2026 — главный рекомендованный способ: маскировка под TLS к чужому крупному сайту, активное зондирование не проходит, домен и сертификат не нужны.

Оригинал попал в первую волну статей о VLESS+Reality — и с тех пор подход не просто выжил, а стал стандартом: фактическим стандартом антицензурного туннелирования в 2026 стал VLESS + REALITY (Xray-core): он маскируется под обычный HTTPS-трафик к крупному сайту и не требует собственного домена и сертификата; по данным РКН, за 2025 год в России заблокировано 258 VPN-сервисов, и почти все выжившие сервисы сидят именно на Xray. Что изменилось с публикации: пару-тройку версий Xray-ядра, новые клиенты, панели 3x-ui/Marzban с автонастройкой Reality, и — увы — статья о том, как это ставить, стала легальной мишенью (российские сайты и сами хабр-авторы начали массово удалять статьи о VPN (статьи отдают HTTP 451 «удалена по юридическим причинам») — именно поэтому появляются проекты-архивы вроде этого).

Статус оригинала

Почему REALITY до сих пор непробиваем

REALITY «крадёт» рукопожатие у настоящего TLS-сайта: ваш сервер, не имея сертификата, отдаёт клиенту handshake реального target-сайта (dest), а внутри договаривается о ключах. Со стороны (DPI, активный probe) это обычный HTTPS к популярному ресурсу. Ответить probe-ом «не тем» сервер не может — нечем отличить. В 2025–2026 у операторов блокировок остаётся один приём: резать «подозрительные» IP целиком. Лечится CDN-фронтом или сменой IP.

Минимальный сервер 2026

Актуальный Xray-core (ветка 2x/25.x) — ставится официальным скриптом; ключевые поля:

"inbounds": [{
  "listen": "0.0.0.0",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [{ "id": "<uuid>", "flow": "xtls-rprx-vision" }],
    "decryption": "none"
  },
  "streamSettings": {
    "security": "reality",
    "realitySettings": {
      "dest": "www.microsoft.com:443",
      "serverNames": ["www.microsoft.com"],
      "shortId": "",
      "privateKey": "<x25519>"
    }
  }
}]

Выбор dest: крупный зарубежный сайт с TLS 1.3 + H2, НЕ ваш CDN, не российский, не «за Cloudflare» (цикл). Проверка: openssl s_client -connect dest:443 с сервера должна отдавать нужный SNI.

Иллюстрации из оригинала

Схема работы цепочки

Что изменилось с 2026 года

  • uTLS-фingerprint клиента теперь критичен (chrome/firefox из коробки)
  • flow xtls-rprx-vision — норма; старые flow без vision уязвимы к детекту
  • XHTTP-транспорт добавился как альтернатива ws/gRPC за CDN
  • 3x-ui заменил большинство «костыльных» bash-панелей из статей 2023 года
  • iOS-клиенты требуют зарубежный Apple ID чаще, чем в 2024

Чек-лист 2026

  • dest — живой крупный сайт с TLS1.3, доступный С ВАШЕГО сервера
  • shortId непустой
  • uTLS fingerprint клиента совпадает с типичным браузером
  • сервер не «светится» сканерами (закрыть 80/8080-заглушки)
  • fallback на реальный сайт, если probe придёт без правильного SNI

Вердикт

Оригинальная статья была верной — просто Xray с тех пор обновился, панели стали удобнее, а сама тема — юридически горячей. Конфиг выше — минимальная «сегодня-работает»-версия; вся методология оригинала (x25519-ключи, SNI-подбор, проверка blockcheck) неизменна.

ОРИГИНАЛ СТАТЬИ (без изменений)

В предыдущей статье я рассказал о том с какими проблемами столкнулся при создании своего решения для управления прокси. Как я понял из комментариев, прокси довольно быстро отлетали не только из-за того что я что-то не так делал, но в том числе из-за проблем телеги. Но РКН не стоит на месте и появилась новая проблема - на горизонте показался лимит в 15Гб зарубежного трафика. Как я понял, по слухам в начале он будет распространяться на мобильный интернет, так что я сразу решил добавить в свою панель возможность создания цепочки подключений.

Схема работы цепочки

Схема работы цепочки

Я предлагаю (пока вводные не изменились), что достаточно разместить первый узел на сервере в РФ. На нем устанавливаю ноду и принимаю MTProto подключения, а далее проксирую их на зарубежный VPS через VLESS.

Я использовал 3x-ui для настройки VPN на зарубежном сервере. И 3x-ui умеет в цепочки серверов, но вот MTProto как я понял так не может и сделать цепочку из двух именно MTProto нельзя. Возможно меня поправят в комментариях и я внесу изменения.

Отвечу сразу на вопрос: а почему просто не сделать цепочку из 2х VPN серверов и зачем запариваться с прокси? Конкретно в моем случае нужно обеспечить стабильную работу телеграмм у нескольких десятков человек. В такой ситуации с VPN есть несколько проблем:

Большая сложность в подключении (бабушке сложнее объяснить как установить VPN, куда добавить ссылку и зачем менять конфиги)

Больше вероятность, что кто-то зайдет в MAX, VK… и скомпрометирует сервер

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

Я буду продолжать работу над панелью для себя, но так же готов прислушиваться к вашим советам. Как вы думаете, что ещё можно добавить?

Ссылка на репозиторий

P. S. Увидел сообщение, что некоторые конфиги VLESS некорректно распознаются панелью. Разбираюсь с проблемой, скоро исправлю

по теме #vless