Открываешь web.telegram.org, идёшь в настройки и не находишь там ни слова про прокси. Ни в K-сборке, ни в A. Люди гуглят «как настроить прокси в телеграмм веб», попадают на инструкции для мобильного приложения, ищут «Данные и память», не находят и закрывают вкладку.
Разбираю, как это устроено на самом деле. Настраивать придётся не Телеграм, а браузер или профиль, в котором он открыт. Дальше три рабочих сценария, разница между протоколами и грабли, на которые я наступал лично.
Почему в веб-версии нет своих настроек прокси
Telegram Web это JS-приложение внутри вкладки. В сеть оно ходит тем же стеком, что и любая страница: через сокеты браузера. Собственного транспорта, как у нативного клиента, у него нет. Кнопку «Добавить прокси» просто некуда прикрутить, потому что маршрут выбирает не приложение, а браузер и операционная система.
В нативном клиенте всё иначе. Там свой сетевой слой, свои дата-центры, свой протокол. Поэтому в Desktop и на мобилке раздел «Прокси» есть, а в вебе нет. Это не баг и не урезанная версия, это архитектура.
Что реально есть в настройках web.telegram.org
Открываешь шестерёнку или меню слева. Внутри: General, Chat Settings, Devices, а в некоторых сборках Advanced. В Advanced видно активные сессии и можно выбрать предпочтительный протокол соединения с дата-центрами. Всё.
Ни поля для хоста, ни порта, ни выбора SOCKS5. Максимум, что даёт веб, это разлогинить лишние устройства. Полезно, но к прокси отношения не имеет.
Дальше работаем с обвязкой. Вариантов ровно три, и они не конкурируют, а решают разные задачи.
Вариант 1. Прокси на уровне браузера
Самый быстрый путь, если нужен один аккаунт и один адрес. Chrome и Edge берут настройки из системы: Настройки - Система - Открыть настройки прокси компьютера - вкладка «Подключения» - «Настройка сети» - галочка «Прокси-сервер» - вручную. Вводишь хост, порт, выбираешь SOCKS5, сохраняешь.
Firefox живёт своей жизнью: Настройки - Основные - Настройки сети - Настроить вручную - SOCKS-хост, порт, SOCKS v5. И обязательно галочка «Проксировать DNS при использовании SOCKS v5». Без неё браузер отправит DNS-запросы через провайдера, и весь смысл схемы развалится.
Safari на macOS тянет системные настройки из «Системных настроек» - «Сеть» - «Дополнительно» - «Прокси». Работает, но с авторизацией там беда.
Рабочий сценарий из практики: публичный Wi-Fi в коворкинге, канал общий, трафик видит администратор сети. Ставишь SOCKS5 с шифрованием, браузер гонит всё через него, вкладка с Telegram Web живёт спокойно. Больше ничего не нужно.
Мобильный браузер: то же самое, но через Wi-Fi
Если веб-клиент открываешь на телефоне, прокси прописывается в настройках конкретной сети. iOS: Настройки - Wi-Fi - шестерёнка рядом с сетью - «Настроить прокси» - «Вручную» - сервер, порт, при необходимости логин и пароль. Android: долгое нажатие на сеть - «Изменить» - «Дополнительные параметры» - «Прокси» - «Вручную».
Грабли тут такие: настройка привязана к сети. Переключился на мобильный интернет, и прокси исчез. Плюс iOS применяет Wi-Fi-прокси не ко всем приложениям одинаково, а к тем, что ходят через системный URLSession. Safari с Telegram Web в эту категорию попадает, сторонние браузеры со своим сетевым стеком могут проигнорировать.
Авторизация: по IP или по логину
Момент, на котором валится половина попыток. Системный диалог Windows и macOS не умеет передавать логин с паролем в SOCKS5. Полей для них просто нет. Узел просит авторизацию, браузер её не отдаёт, соединение падает с ошибкой 407 или молчаливым таймаутом.
Два выхода. Первый: брать адреса с авторизацией по IP. Привязываешь свой домашний или офисный адрес в панели провайдера, и узел пускает без пароля. Второй: антидетект-браузер, там креды вбиваются в карточку профиля и подставляются в сокет на уровне движка.
Расширения-переключатели в Chrome проблему решают частично: они гоняют только HTTP-трафик вкладки, а WebSocket, на котором держится Telegram Web, может уйти мимо. Проверяй на живом соединении, а не по зелёной галочке в попапе.
Вариант 2. Антидетект-профиль, когда аккаунтов больше одного
Схема, которую использую для мультиаккаунта. Создаёшь профиль, привязываешь к нему свой адрес, выставляешь fingerprint под ту же страну и платформу. Открываешь web.telegram.org внутри профиля, логинишься по QR. Один аккаунт, один профиль, один IP.
Почему не один браузер с переключением прокси на лету. Потому что куки, localStorage и IndexedDB остаются общими. Telegram Web хранит в localStorage привязку сессии, и переезд на другой адрес посреди работы читается как смена устройства. Ловишь запрос кода подтверждения каждый раз, когда переключил узел.
По количеству аккаунтов на один адрес: больше двух на мобильном IP держать не советую, больше пяти на датацентровом почти гарантированная проверка. Мобильные прощают больше, потому что за ними реально стоят тысячи людей с одного оператора.
И про сам профиль. Fingerprint должен совпадать с географией адреса. Прокси во Франкфурте и браузер с русской локалью, часовым поясом Москвы и русским языком в заголовках это набор флагов, который видно без всякой магии.
Вариант 3. Telegram Desktop с прокси, а веб рядом
Если нужен прокси именно внутри Телеграма, а не снаружи, идти надо в Desktop. Settings - Advanced - Connection type - Use custom proxy - Add proxy. Дальше тип.
SOCKS5: host, port, username, password. MTProto: host, port, secret. Сохраняешь, включаешь переключатель, клиент сам тестирует соединение и показывает статус.
Практический смысл комбинации: Desktop с прокси держит основную переписку и медиа, а веб открыт в браузере с системным прокси для быстрых задач с другого устройства. Оба клиента на одном аккаунте живут нормально, Telegram это поддерживает штатно.
SOCKS5 и MTProto: разница на уровне архитектуры
SOCKS5 работает ниже прикладного уровня. Он просто перенаправляет TCP-соединение, не вникая в содержимое. Отсюда универсальность: через него ходит и HTTP, и WebSocket, и что угодно ещё. Браузер про MTProto ничего не знает, поэтому для веба выбор один: SOCKS5 или HTTP CONNECT.
MTProto это родной протокол Telegram. Он оборачивает пакеты в собственный контейнер, шифрует полезную нагрузку и умеет маскировать поток под обычный TLS. Внутри клиента даёт меньший оверхед и лучшую устойчивость на плохих каналах, потому что не тащит двойное шифрование поверх TLS.
По задержке на практике: разница в 10-30 мс в пользу MTProto на мобильной сети, и она полностью съедается качеством самого узла. На десктопе с проводным интернетом я этой разницы не вижу вообще.
По нагрузке: SOCKS5 дешевле для процессора, там нет лишнего шифрования. Если гоняешь большие файлы через веб-клиент, SOCKS5 выигрывает.
По совместимости: MTProto живёт только в клиентах Telegram. Ни браузер, ни WhatsApp Web, ни что-либо ещё его не понимает. SOCKS5 понимают все.
Серверные или мобильные адреса
Датацентровые дешёвые и быстрые. Для защиты трафика в кафе, для доступа к своему рабочему узлу из отеля, для фоновых задач их хватает с запасом. Один адрес стоит от полудоллара в месяц.
Мобильные дороже в разы, но у них IP оператора. Для мультиаккаунта в вебе это критично: такой адрес не выглядит как ферма, за ним стоят живые люди. И живёт он часами, а не минутами, что важно для долгих сессий в браузере.
Резидентские посередине. Хороши, когда нужна конкретная страна и город, а мобильный в этом регионе стоит неадекватно.
Отдельно про ротацию. В вебе ротация по времени вредна. Открыл вкладку, поработал двадцать минут, адрес сменился, и Telegram просит подтвердить вход. Для веб-сессий беру статику или липкую сессию на несколько часов.
Где брать узлы и на что смотреть в каталоге
Смотрю на три параметра. Протокол: нужен именно SOCKS5, а не только HTTP, иначе авторизация в браузере превращается в квест. Тип и география: под веб беру Mobile или Residential, под фоновые задачи хватает Datacenter. Формат выдачи: нужен хост, порт, логин и пароль списком, а не ссылка на подписку, которую браузер не понимает.
Каталог, которым пользуюсь сам: https://3seller.com/proxy. Фильтры по стране, типу и протоколу, цена за конкретный адрес и объём трафика видны сразу на карточке. Под десять аккаунтов беру десять штук, а не пакет на пятьсот, половина которого потом простаивает.
Пошагово: браузер + SOCKS5 + web.telegram.org
- Берёшь адрес с авторизацией по IP или с логином и паролем.
- Chrome и Edge: Настройки - Система - Открыть настройки прокси компьютера - Подключения - Настройка сети - вручную, SOCKS5, хост, порт, сохранить.
- Firefox: Настройки - Основные - Настройки сети - Настроить вручную - SOCKS-хост, порт, SOCKS v5, галочка «Проксировать DNS».
- Полностью закрываешь браузер и открываешь заново. Старые сокеты на прежнем маршруте иначе останутся жить.
- Проверяешь адрес на любом сервисе определения IP. Страна и город должны совпасть с тем, что обещал провайдер.
- Открываешь web.telegram.org, логинишься по QR с телефона, отправляешь себе файл на 20-30 МБ и смотришь на скорость.
Шестой пункт многие пропускают. Мелкие текстовые сообщения пролетят через любой мёртвый узел, а вот медиа на нём застрянут.
Корпоративный сценарий: свой узел на VPS
Если речь про компанию, никто не покупает внешние адреса. Админ поднимает SOCKS5 на своём сервере, ставит авторизацию, ограничивает доступ по IP офиса. Сотрудники прописывают адрес узла в браузере, и весь трафик, включая Telegram Web, идёт через корпоративный шлюз.
Смысл не в анонимности, а в контроле: логи, единая точка выхода, понятная политика. Плюс настройка задержки, если сервер стоит в том же регионе, что и дата-центры Telegram. Разница в отзывчивости интерфейса заметна сразу.
Что учесть: пропускная способность канала делится на всех, а Telegram Web тянет медиа охотно. Считай нагрузку заранее, иначе в час пик вкладка будет думать по три секунды на каждое действие.
Тот же приём работает не только для Telegram
Браузерный прокси не разбирает, какая вкладка за ним стоит. Поставил SOCKS5 на уровне системы, и через него пойдут WhatsApp Web, Slack, веб-панели и всё остальное. Удобно, когда нужно закрыть одним маршрутом весь рабочий набор, а не настраивать каждый сервис отдельно.
Обратная сторона: если узел упал, падает всё сразу. Поэтому для рабочих сценариев беру адреса с нормальным аптаймом, а не самые дешёвые из выдачи.
Почему «Подключено» не значит «работает»
Системный диалог покажет «прокси включён», даже если узел уже сутки как мёртв. Он не проверяет соединение, он просто хранит настройки. Проверка только руками.
Три ошибки, которые я видел чаще всего.
- DNS уходит мимо. В Firefox забыта галочка «Проксировать DNS», запросы идут через провайдера. Сайт открывается, а часть трафика палит реальный адрес.
- IPv6 в обход. Браузер стучится по IPv6 напрямую, минуя SOCKS5. Лечится отключением IPv6 в системе или узлом с поддержкой v6.
- Сессия на старом маршруте. Сменил настройки, не перезапустил браузер, часть сокетов осталась на прежнем адресе. Всегда полный рестарт.
Плюс банальное: логин с паролем скопированы с лишним пробелом на конце. Смешно, но я на это попадался дважды.
Сколько это стоит
Датацентровый SOCKS5: от 0,5 до 2 долларов за адрес в месяц. Мобильный: 2-5 долларов в день или 50-100 в месяц, зависит от страны. Резидентский посередине.
Если задача закрыть трафик в публичной сети, платить больше доллара в месяц смысла нет. Если в вебе живут десять рабочих аккаунтов, экономия выглядит странно: один бан стоит дороже, чем месяц мобильных адресов на всю команду.
Что делать дальше
Открой браузер, поставь SOCKS5 на уровне системы или профиля, проверь IP через сторонний сервис, и только потом логинься в web.telegram.org. Если аккаунтов больше одного, не мучай один браузер переключением на лету, собери профили: один аккаунт, один адрес, один fingerprint.
Адреса под эти задачи беру в каталоге 3seller: фильтры по стране и типу, протокол и цена за штуку сразу на карточке, без переписки с менеджером.