Открываете web.telegram.org, заходите в настройки, ищете глазами раздел с прокси и не находите. У меня в первый раз было ровно так же. Потом дошло: в браузерной версии такой кнопки нет и не появится, потому что настройка живёт не там, где её ищут. Понять эту логику один раз - и дальше всё складывается за пять минут.
Ниже - где реально включается прокси для веб-версии, что за WEB-прокси прикрутили в десктопный клиент осенью 2026-го, и на каких граблях я лично стоял, когда гонял через браузер несколько аккаунтов одновременно.
Веб-версия ТГ не управляет сетевым стеком, и это не баг
web.telegram.org - это JavaScript-приложение. Оно рисует интерфейс, держит WebSocket-соединение с серверами и передаёт по нему пакеты. Всё. Сетевым стеком оно не управляет и управлять не может, потому что работает внутри браузера, а браузер - песочница.
Цепочка простая. Браузер решает, через какой шлюз отправлять запросы. Значит настройка прокси для веб-версии ТГ - это настройка прокси в браузере или в операционной системе. Третьего варианта нет. Всё, что вы найдёте в интернете про «включение прокси внутри веб-телеграма», либо про системные настройки браузера, либо про расширение-менеджер, либо про десктопный клиент, который к вебу отношения не имеет.
Есть нюанс, который ломает голову новичкам. Веб-версия держит долгоживущее WebSocket-соединение. Если прокси медленный, рвёт длинные соединения или балансирует запросы между разными выходными узлами, вы получите классическую картину: интерфейс загрузился, чаты видны, зелёный индикатор горит, а сообщения не уходят или уходят с задержкой в минуту. Люди думают, что «прокси не работает». На самом деле работает, просто не тянет persistent-соединения.
WEB-прокси в десктопном клиенте - это вообще про другое
Осенью 2026-го в коде клиента Telegram исследователи заметили новый тип прокси, и вокруг него поднялся шум. 22 августа 2026 года фича появилась в десктопной версии 7.1.0 и фиксе 7.1.1, а 25 августа в 7.1.2 её доработали. Суть такая: клиент упаковывает несколько соединений MTProxy в один поток HTTPS/WebSocket через встроенный WebView, специальный сервер распаковывает и отправляет дальше в MTProxy. Снаружи, на уровне провайдера, это выглядит как обычный веб-трафик к обычному сайту.
Не перепутайте. Это фича десктопного клиента, а не web.telegram.org. В браузере вы её не включите, потому что там нет встроенного WebView, который мог бы такую упаковку собрать. Зато сам подход объясняет, куда движется индустрия: трафик мессенджера всё сильнее маскируется под что-то нейтральное, и качество канала начинает играть ещё большую роль, чем раньше.
Три задачи, под которые люди ищут прокси для веб-ТГ
Первая и самая частая - мультиаккаунтинг. Один рабочий аккаунт, один личный, три под проекты. Если всё это открывать в одном браузере с одного IP, мессенджер довольно быстро начинает видеть в вас одного и того же человека. Дальше либо ограничения, либо верификации по кругу.
Вторая - публичные сети. Аэропорт, коворкинг, кофейня, гостиница. В таких местах трафик между вашим ноутбуком и точкой доступа видит кто угодно с ноутбуком и минимальным набором софта. Прокси тут не про анонимность, а про то, чтобы сессия не улетела в чужие руки.
Третья - автоматизация. Боты, парсеры каналов, интеграции с CRM, выгрузка сообщений из рабочих чатов. Тут веб-версия вообще редко используется напрямую, чаще через API, но прокси нужен всё равно, и требования к нему другие: стабильность, лимиты соединений, понятная география.
Настройка в Chrome и Edge: куда именно нажимать
Chrome тянет системные настройки прокси, своих у него нет. Порядок такой: три точки в правом верхнем углу, дальше Настройки, в левом меню пункт Система, кнопка «Открыть настройки прокси компьютера». Откроется окно свойств обозревателя Windows. Там вкладка «Подключения», кнопка «Настройка сети». Ставите галочку «Использовать прокси-сервер», вписываете адрес и порт из личного кабинета провайдера, жмёте ОК и закрываете окно.
Edge работает ровно так же, потому что берёт те же системные настройки Windows. Разницы никакой, только меню чуть иначе называется.
Грабли, на которые я наступал дважды. Chrome не всегда показывает окно авторизации прокси. Если шлюз требует логин и пароль, браузер может молча получить 407 и просто не пустить вас на web.telegram.org, без внятной ошибки. Лечится либо настройкой IP-авторизации на стороне провайдера, либо расширением-менеджером, которое умеет подставлять креды. Второй момент: системный прокси применяется ко всему, включая обновления Windows и облачные диски. Если канал узкий, вы это почувствуете.
Firefox: единственный, кто держит настройки отдельно
У Firefox своя система сетевых настроек, и это огромный плюс. Меню, Настройки, раздел Основные, в самом низу кнопка «Настройки сети». Дальше «Ручная настройка прокси», вписываете хост и порт, отдельно отмечаете «Использовать этот прокси для HTTPS». Сохраняете.
Зачем это нужно. Допустим, вы хотите, чтобы через прокси ходил только телеграм, а остальной браузинг шёл напрямую. В Chrome так не сделать без расширений, в Firefox - за тридцать секунд. Плюс Firefox аккуратнее ведёт себя с WebSocket, когда прокси нестабильный: реже роняет соединение молча, чаще показывает ошибку.
Почему системный прокси плохо дружит с мультиаккаунтингом
Когда прокси стоит на весь браузер, вы получаете один IP на все вкладки, все профили и все аккаунты сразу. Веб-версия Telegram хранит сессию в localStorage и IndexedDB, то есть внутри браузерного профиля. Два аккаунта в одном профиле под одним IP - это для серверов фактически один субъект с двумя сессиями. Ничего удивительного, что через пару недель прилетает проверка.
Есть второй, менее очевидный эффект. Если менять прокси на лету, не перезагружая вкладку, веб-клиент может потерять соединение с сервером и выкинуть вас на экран входа. Спасает только полная перезагрузка страницы после смены шлюза.
Рабочая схема выглядит так: отдельный браузерный профиль на каждый аккаунт, у каждого профиля свой собственный прокси, разные часовые пояса и языки, и никакого пересечения по кукам. Chrome это умеет из коробки через менеджер профилей, но чище работают антидетект-браузеры, где прокси прибит к профилю намертво.
Десктопный клиент: где включается прокси и что выбрать
Веб-версия зависит от браузера, поэтому у многих возникает резонный вопрос: а как вообще выглядит настройка в нормальном клиенте. Показываю по шагам, потому что интерфейс менялся и старые скриншоты вводят в заблуждение.
Открываете Настройки, дальше Продвинутые настройки, пункт «Тип подключения», кнопка «Прокси», затем «Добавить прокси». В открывшемся окне выбираете тип: MTProto, SOCKS5 или Web, если у вас версия 7.1.2 и выше. Вводите хост, порт, при необходимости логин и пароль. Сохраняете, включаете переключатель, смотрите на индикатор соединения внизу списка. Если он зелёный, всё поднялось.
Тут же лежит кнопка проверки, которая прогоняет тестовый запрос через выбранный шлюз. Нажимайте её каждый раз: она ловит ошибку авторизации и закрытый порт до того, как вы начнёте гадать, почему сообщения висят в облачке.
SOCKS5 против MTProto: разница на уровне архитектуры, а не маркетинга
SOCKS5 - универсальный туннель на уровне сессии. Он не знает и не хочет знать, что внутри: TCP-поток и всё. Отсюда плюсы: работает с любым протоколом поверх, легко настраивается, поддерживается почти всем софтом, включая Python-библиотеки для ботов. Минусы: лишний round-trip на установку соединения и полное отсутствие оптимизации под мобильные сети. На парсинге и API-интеграциях это нормальный выбор.
MTProto - родной протокол мессенджера. Внутри свой слой шифрования, своя логика переподключения, меньше накладных расходов на пакет. На нестабильном мобильном интернете он держится заметно лучше SOCKS5, потому что умеет аккуратно переустанавливать соединение, не роняя сессию. Если задача - стабильная работа клиента, начинайте с MTProto и смотрите на результат.
WEB-прокси, о котором писали в августе 2026-го, это надстройка: MTProxy-трафик заворачивается в HTTPS/WebSocket. Снаружи соединение неотличимо от похода на обычный сайт. Для корпоративных сетей с умной фильтрацией это часто единственный вариант, который вообще проходит.
Что ломается чаще всего: шесть типичных сценариев
- Ошибка 407. Прокси требует авторизацию, браузер её не передаёт. Проверяйте креды и способ авторизации у провайдера.
- Порт закрыт или адрес устарел. Банально, но случается чаще, чем кажется: сменили тариф, старый узел отключили.
- Сессия вылетает при смене IP. Веб-клиент не любит резкую смену географии, особенно между странами.
- WebSocket-таймауты. Прокси рвёт длинные соединения, чат живёт, сообщения не ходят.
- DNS-утечки. Запросы идут через прокси, а резолв напрямую, и часть картины видна снаружи.
- Лимит одновременных соединений. Дешёвый тариф на десять потоков не вывезет браузер с двадцатью вкладками.
Публичный Wi-Fi и корпоративный узел: зачем это в 2026-м
В гостевых сетях прокси решает простую задачу: трафик между вами и точкой доступа перестаёт быть открытой книгой. Плюс, если вы работаете из разных локаций, географически близкий узел снижает задержку. Я видел разницу в 200 мс на отправку сообщения, когда узел был в другом полушарии. Для чата это уже раздражает.
Для компаний логика другая. Свой VPS с поднятым шлюзом, все сотрудники ходят через один корпоративный выход, админ видит единую точку и может управлять политиками. Настройка на стороне клиента при этом минимальная: браузер или системные настройки, те же три поля.
Как выбирать прокси под веб-ТГ: мой практический фильтр
Первое, на что смотрю, это тип. Датацентровые - быстрые и дешёвые, хорошо идут под ботов, парсинг и технические задачи. Резидентские - дороже, но выглядят как домашние пользователи, их берут под мультиаккаунтинг и работу с чувствительными сессиями. Мобильные - самый дорогой сегмент, зато максимально приближены к реальному человеку с телефона.
Второе - география. Для веб-версии берите страну, совпадающую с той, где вы обычно работаете. Прыжок с российского IP на аргентинский и обратно за день выглядит странно, и алгоритмы это замечают.
Третье - протокол. Если настраиваете браузер, вам нужен HTTP или SOCKS5, потому что браузеры MTProto не понимают. Если настраиваете клиент, можно брать MTProto и получать более стабильную сессию.
Четвёртое - лимиты. Смотрите не на скорость в мегабитах, а на количество одновременных соединений и на политику ротации. Для веб-ТГ ротация по каждому запросу - зло, сессия будет рваться. Нужен sticky-режим хотя бы на 10-30 минут.
Держать всё это в голове при выборе утомительно, поэтому я просто открываю каталог прокси и фильтрую по стране, протоколу и типу. Там же видно цены и условия, не нужно переписываться с менеджером, чтобы узнать базовые параметры. Экономит минут двадцать на каждом новом проекте.
Мультиаккаунтинг: правило одного профиля
Самая дорогая ошибка новичка - запускать три аккаунта в трёх вкладках одного браузера и думать, что разные прокси в расширении что-то решают. Не решают. Куки, localStorage, отпечаток канваса и шрифтов общие. Сервер видит один браузер с тремя сессиями.
Правильно так: один профиль, один прокси, один аккаунт. Профили изолированы полностью, вплоть до отдельных папок на диске. Если работаете с десятком аккаунтов, берите антидетект-браузер и привязывайте прокси к профилю, а не к браузеру целиком. Тогда перезапуск не сбивает настройки, и вы не теряете сессию на ровном месте.
И ещё одна деталь, которую замечают не сразу. Веб-версия ТГ подтягивает часовой пояс и язык из браузера. Если профиль с немецким прокси, а язык системы русский, это мелкое несоответствие. По одному фактору ничего не решает, но в сумме с другими даёт ненужный сигнал.
Сколько это стоит и где не надо экономить
Датацентровые прокси начинаются от совсем смешных денег за штуку в месяц, и для технических задач этого достаточно. Резидентские считаются обычно за гигабайты и выходят дороже, особенно если гонять через них видео и стикеры. Мобильные - самый дорогой сегмент, там цена может отличаться в разы.
Экономить не стоит на двух вещах. Первое - стабильность аптайма. Прокси, который падает раз в сутки, обойдётся дороже любого тарифа, потому что вы будете тратить время на переподключение и повторную авторизацию. Второе - репутация подсети. Дешёвые пулы часто уже отработаны сотнями других пользователей, и вход в свежий аккаунт через такой адрес сразу выглядит подозрительно.
Проверка перед тем, как платить
Всегда берите тестовый период, даже если он стоит символических денег. Двух часов хватает, чтобы понять три вещи: держит ли шлюз WebSocket-соединение дольше пяти минут, не рвётся ли сессия при переключении между запросами, и совпадает ли заявленная география с реальной. Последнее проверяется любым сервисом определения IP прямо в браузере.
Если после подключения веб-версия грузится, но сообщения ходят рывками, проблема почти всегда в шлюзе, а не в вашей настройке. Меняйте узел, не тратьте вечер на диагностику браузера.
Начните с одного профиля и одного прокси. Прогоните его сутки в реальной работе: отправка файлов, звонок, переключение между чатами. Если всё держится, масштабируйте на остальные аккаунты. И держите под рукой нормальный каталог с понятными фильтрами, чтобы замена вылетевшего узла занимала минуту, а не полдня переписки.