Частая проблема в последнее время: на телефоне или в браузере Telegram работает нормально, а десктопный клиент сутками грузит одну картинку и постоянно переподключается. Обычно это связано с тем, что провайдерский DPI режет или жестко шейпит прямой MTProto-трафик. При этом веб-версии (WebK/WebZ) работают отлично, потому что они гоняют данные через WebSockets (WSS), который для провайдера выглядит как дефолтный HTTPS до web.telegram.org
Репозиторий tg-ws-proxy предлагает изящный костыль: локальный SOCKS5-прокси, который перехватывает трафик десктопного клиента и заворачивает его в WSS-соединения к дата-центрам Telegram.
Как это работает под капотом
Десктопная телега не умеет сама работать через вебсокеты, поэтому ей нужен локальный посредник.
Схема такая:
Скрипт поднимает локальный SOCKS5 (по дефолту на 127.0.0.1:1080).
Клиент подключается к прокси и начинает слать свой обычный обфусцированный трафик.
Прокси парсит пакет MTProto obfuscation init и достает оттуда ID целевого дата-центра.
Дальше скрипт устанавливает TLS-хендшейк и открывает WebSocket к нужному DC через домены вида kws{N}.web.telegram.org.
Если вебсокет отваливается или отвечает редиректом (302), прокси автоматически фоллбечится на прямое TCP-соединение.
В итоге DPI видит лишь зашифрованный трафик до поддоменов telegram.org и не применяет к нему правила, написанные для блокировки MTProto.
Развертывание
Для Windows:
В релизах на GitHub лежит собранный через PyInstaller TgWsProxy.exe. Работает как приложение в трее.
Нюанс: Windows Defender часто агрится на этот экзешник, выдавая детект Wacatac. Это классический false-positive для PyInstaller, так что придется добавлять папку в исключения. Если кликнуть в трее «Открыть в Telegram», скрипт сам прокинет tg://socks линк в клиент.
Для Linux/macOS:
Гораздо проще и надежнее запустить прямо из исходников:
git clone https://github.com/Flowseal/tg-ws-proxy.git cd tg-ws-proxy pip install -r requirements.txt # Запуск с дефолтными параметрами python proxy/tg_ws_proxy.py --port 1080
Для прода или постоянного использования на рабочей станции это дело элементарно оборачивается в systemd-сервис.
sudo nano /etc/systemd/system/tg-ws-proxy.service
[Unit] Description=Telegram WebSocket Proxy SOCKS5 After=network.target [Service] Type=simple User=nobody WorkingDirectory=/opt/tg-ws-proxy ExecStart=/opt/tg-ws-proxy/venv/bin/python proxy/tg_ws_proxy.py --port 1080 Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
sudo systemctl daemon-reload sudo systemctl enable --now tg-ws-proxy sudo systemctl status tg-ws-proxy
Конфигурация и дебаг
В консольном режиме можно жестко задать маршрутизацию для конкретных дата-центров через аргумент --dc-ip. Например, --dc-ip 2:149.154.167.220. Это спасает, когда встроенные в скрипт IP-адреса попадают под раздачу или перестают отвечать.
В Windows-версии все эти параметры лежат в обычном JSON-конфиге по пути %APPDATA%/TgWsProxy.
Если коннект не поднимается, запускаем скрипт с флагом -v. В консоль посыпется дамп (уровень DEBUG), по которому сразу понятно, на каком этапе отваливается TLS или почему не проходит MTProto init.
Когда это реально нужно?
Это не серебряная пуля от Чебурнета.
Если РКН или ваш местный регулятор глушит домены *.telegram.org на уровне SNI или банит IP-адреса целиком, этот скрипт не поможет. В таких сценариях выход один — арендовать VPS и поднимать полноценный туннель (тот же VLESS с Reality).
Но если проблема заключается именно в троттлинге тяжелых файлов (провайдер не банит IP, но целенаправленно «душит» сессии по паттернам протокола), то локальный SOCKS5 с оберткой в WSS отлично решает проблему без необходимости гонять весь трафик через внешние серверы.
Если есть идеи для разбора, нашёл ошибку
или хочешь предложить тему — пиши на
aleksandr@murzin.digital Отвечаю.