Открываешь web.telegram.org, лезешь в настройки, ищешь раздел «Прокси» и не находишь. Не спрятали, не перенесли в новую версию. Его там нет и не будет. Telegram Web живёт целиком внутри браузера, а браузер не отдаёт сайту право рулить сетевым соединением. Вкладка видит уже готовый канал и понятия не имеет, что происходит уровнем ниже.
Я упёрся в это года три назад, когда настраивал рабочие места для команды, которая принципиально сидела в вебе и отказывалась ставить десктопный клиент. Полдня искал несуществующую кнопку. Потом дошло: прокси надо ставить не в Telegram, а над ним. Между браузером и сетью.
Дальше расскажу, какие три уровня реально работают, чем они отличаются по поведению и где люди чаще всего ломаются.
Веб-клиент не умеет в прокси, и это не баг
В мобильном приложении и в десктопном клиенте всё просто: Настройки, раздел «Данные и память», подраздел «Прокси», тумблер «Использовать прокси», тип SOCKS5 или MTProto, адрес, порт, логин с паролем. Telegram сам держит соединение и сам решает, куда его направить.
В вебе такой прослойки нет. Клиент это JavaScript, который крутится в песочнице браузера. Он умеет открывать WebSocket и HTTP-запросы, но не умеет менять маршрут этих запросов. Всё сетевое окружение ему выдаёт браузер, а браузер берёт настройки из системы или из расширений.
Практическое следствие: если в вебе не открываются сообщения или висит вечное «Connecting», лезть в настройки Telegram бессмысленно. Надо смотреть, что стоит в браузере и в операционной системе.
Три уровня, на которых прокси действительно включается
Первый уровень: расширение браузера. Быстро, обратимо, можно держать десяток профилей и переключаться в два клика. Минус в том, что расширение управляет только тем браузером, где оно установлено.
Второй уровень: системные настройки Windows, macOS или Linux. Прокси подхватывают все приложения, которые уважают системные параметры. Хром и большинство браузеров на Chromium уважают. Firefox по умолчанию живёт своей жизнью, там отдельная вкладка настроек сети.
Третий уровень: прослойка вроде Proxifier. Она перехватывает соединения конкретных программ по имени процесса или по целевому хосту и заворачивает их куда скажешь. Нужна, когда остальной трафик должен идти напрямую, а через прокси должен ходить только web.telegram.org.
Выбор уровня зависит от задачи. Если надо просто привести в порядок один браузер на своём ноуте, хватит расширения. Если рабочих мест десять и на каждом свой сотрудник, дешевле системная настройка через групповые политики. Если нужна точность до домена, без Proxifier не обойтись.
Способ первый: расширение для браузера, пошагово
Ставите из магазина расширений любой менеджер прокси. Классика жанра это SwitchyOmega, но подойдут и другие с похожим набором функций. Дальше логика одинаковая везде.
- Открываете настройки расширения и создаёте новый профиль, назовите его понятно, например «TG Web».
- Выбираете протокол: SOCKS5, если прокси его поддерживает, иначе HTTP.
- Вбиваете адрес сервера и порт из карточки прокси.
- Если провайдер выдал логин и пароль, вводите их в отдельных полях.
- Сохраняете профиль и применяете его.
- Только после этого открываете web.telegram.org и проходите вход.
Порядок важен. Если сначала открыть вкладку, а потом включить прокси, клиент уже установил соединение напрямую, и переключение профиля ничего не изменит без полной перезагрузки страницы. Я на этом терял минуты и злился на прокси, который был полностью рабочий.
Отдельный момент про SOCKS5 с авторизацией. Часть расширений не умеет передавать логин и пароль по SOCKS5 и молча падает. Если профиль не подключается, а данные точно верные, попробуйте HTTP-прокси с теми же учётными данными. Диагностика занимает тридцать секунд, а нервов экономит много.
Способ второй: системный прокси в Windows
Путь такой: «Пуск», «Параметры», «Сеть и Интернет», «Прокси». Дальше блок «Настройка прокси вручную», кнопка «Настроить», тумблер «Использовать прокси-сервер» и два поля: адрес и порт.
Всё, что ниже в том же окне, это поле «Не использовать прокси для адресов из списка». Туда через точку с запятой добавляют локальные адреса и внутренние ресурсы компании, чтобы они ходили напрямую. Полезная штука, если корпоративная сеть не любит, когда её трафик уходит наружу.
Нюанс, о котором забывают: системный прокси в Windows по умолчанию не передаёт учётные данные в фоне. При первом заходе браузер покажет диалог с логином и паролем, и это нормально. Но если вы настраиваете машину для сотрудника и не хотите, чтобы он видел этот диалог, ставьте прокси с авторизацией по IP или отдельный узел под конкретного пользователя.
Второй нюанс: настройки применяются к новым соединениям. Chrome иногда держит уже открытые сокеты и не переподключается сразу. Полная перезагрузка браузера решает вопрос за пять секунд.
Способ третий: macOS и Linux
В macOS всё лежит в «Системные настройки», «Сеть», выбор активного интерфейса, «Подробнее», вкладка «Прокси». Там отдельными галочками включаются HTTP, HTTPS и SOCKS. Для Telegram Web нужен минимум HTTPS и SOCKS, потому что клиент ходит по защищённому каналу.
В Linux с GNOME то же самое через «Настройки», «Сеть», «Сетевой прокси». Если на машине нет графической оболочки, параметры задаются переменными окружения http_proxy, https_proxy и all_proxy. Браузеры на Chromium их читают, Firefox читает не всегда, у него собственные настройки в разделе «Сеть».
Совет из практики: на Linux не смешивайте переменные окружения и настройки в браузере. Получается двойная маршрутизация, соединение уходит в петлю, и вы полчаса смотрите на таймаут, проклиная провайдера, у которого всё в порядке.
Способ четвёртый: Proxifier, когда нужен только Telegram Web
Этот вариант я использую, когда остальной трафик должен идти напрямую. Например, вы работаете с внутренними сервисами компании, которые не любят чужие IP, а веб-клиент мессенджера надо вести через конкретный узел.
Логика настройки такая. Сначала добавляете сервер: меню «Profile», пункт «Proxy Servers», кнопка «Add», вводите адрес, порт, протокол и, если нужно, логин с паролем. Жмёте «OK» и проверяете соединение встроенной кнопкой проверки.
Потом создаёте правило: меню «Profile», пункт «Proxification Rules», кнопка «Add». В поле «Target Hosts» вписываете домены веб-клиента, обычно это web.telegram.org и подсети, которые клиент использует для медиа. В выпадающем списке «Action» выбираете добавленный прокси. Правило поднимаете выше стандартного «Default», иначе оно не сработает.
Тут есть подводный камень, на который ловятся почти все. Telegram Web держит соединение через WebSocket. Если прокси не пропускает метод CONNECT на 443 порт или режет wss, вы увидите интересную картину: интерфейс загрузился, чаты видны, а новые сообщения не приходят. Человек думает, что прокси медленный. На самом деле он не умеет в туннель.
Проверяется просто. Откройте в том же браузере любой сайт с WebSocket-тестом, если соединение не устанавливается, дело в прокси, а не в Telegram.
SOCKS5 или MTProto: что вообще подходит для веба
MTProto это протокол самого Telegram, и он работает только внутри клиента, который умеет его готовить. В браузере такой возможности нет. Поэтому для веб-версии остаются два варианта: SOCKS5 и HTTP/HTTPS-прокси.
SOCKS5 работает на уровне TCP и не заглядывает внутрь пакета. Ему всё равно, что вы передаёте, шифрованный трафик или обычный текст. Для Telegram Web это плюс: клиент сам шифрует содержимое, прокси не мешает. Плюс SOCKS5 умеет держать длинные соединения, а веб-клиенту именно это и нужно.
HTTP-прокси проще и быстрее настраивается, но хуже переносит долгие сессии и иногда обрывает WebSocket при простое. Для разовой проверки сойдёт, для постоянной работы берите SOCKS5.
Отдельно про задержку. Telegram Web чувствителен к пингу, потому что держит постоянный канал. Прокси с задержкой 200 мс и выше вы почувствуете руками: сообщения уходят с паузой, медиа подгружается рывками. Для работы в вебе ищите узлы с задержкой до 80-100 мс от вашей точки.
Почему бесплатные публичные прокси это лотерея с плохими шансами
Каждый раз, когда кто-то спрашивает меня про бесплатные списки, я вспоминаю историю. Знакомый взял узел из открытого списка для работы с веб-клиентом. Через два дня аккаунт попросил повторный вход с подтверждением по SMS, а сессия на другом устройстве оказалась не его.
Публичный прокси это чужой сервер, владелец которого вам ничего не обещал. Он видит, с каких адресов и когда вы подключаетесь, может писать логи, может подменять сертификаты, если вы не проверили цепочку. Для мессенджера, где вся переписка привязана к аккаунту, это плохая сделка.
Второй минус чисто технический. Бесплатные узлы перегружены, держат по сотне соединений на порт и рвут длинные сессии. Веб-клиент как раз держит длинную сессию. Итог: интерфейс грузится, а сообщения приходят через раз, и вы не понимаете, где проблема. На Reddit эта тема всплывает постоянно: люди жалуются на обрывы, а виноват бесплатный узел, который не держит WebSocket.
Нормальный путь такой: брать прокси у провайдера, который отвечает за качество, и проверять его перед покупкой. В каталоге прокси можно отфильтровать узлы по стране, протоколу и типу IP, а не собирать их по форумам и телеграм-каналам с сомнительной репутацией.
Какую страну выбирать и почему это важнее, чем кажется
География влияет на две вещи: задержку и то, как сервис видит вашу сессию. Если вы каждый день заходите из Москвы, а прокси стоит в США, Telegram это заметит и может попросить подтвердить вход. Ничего страшного, но раздражает.
Правило простое. Для повседневной работы берите страну, близкую к вам физически, задержка будет меньше. Для задач, где нужна конкретная геолокация, например работа с зарубежными аккаунтами или проверка рекламных кабинетов, берите нужную страну и не меняйте её без причины. Постоянство выглядит естественнее, чем прыжки между континентами три раза в день.
Отдельно про тип IP. Датацентровые адреса дешевле и быстрее, резидентские дороже и выглядят как обычный домашний пользователь. Для веб-версии мессенджера в большинстве рабочих сценариев хватает датацентровых, если узел не засвечен в чёрных списках. Проверить это можно до покупки, многие провайдеры дают тестовый период.
Что проверить перед тем, как платить
Первое: поддержка SOCKS5 и авторизации по логину с паролем. Второе: разрешён ли метод CONNECT на 443, без него WebSocket не поднимется. Третье: лимит одновременных соединений, веб-клиент открывает их несколько сразу, особенно когда грузит медиа. Четвёртое: тарификация трафика, если она по гигабайтам, видео и голосовые съедят её быстрее, чем вы думаете.
Пятое и самое недооценённое: стабильность в долгую. Прокси, который держит соединение четыре часа без разрыва, стоит дороже того, который рвётся каждые двадцать минут. Для веб-версии это критично, потому что после разрыва клиент переподключается, а история непрочитанных может отрисоваться не сразу.
Я обычно беру минимальный тариф, гоняю его сутки в реальной работе, и только потом докупаю объём. Проверять на тестовом скрипте бессмысленно, нужна именно живая сессия с отправкой файлов и звонком.
Мелкие грабли, которые съедают время
Вкладка Telegram Web живёт в фоне и держит соединение. Если вы выключили прокси, не закрыв вкладку, клиент может продолжать висеть на старом сокете. Закрывайте вкладку перед сменой настроек, это дешевле, чем искать причину странного поведения.
Корпоративный фаервол иногда режет не только сам прокси, но и DNS-запросы к нему. Если адрес не резолвится, дело не в прокси, а в сети. Проверяется командой nslookup, тридцать секунд.
И последнее. Не держите один прокси на все задачи сразу: рабочий мессенджер, личный аккаунт, парсинг и рекламные кабинеты. Разнесите по разным узлам. Когда что-то пойдёт не так, вы хотя бы поймёте, где искать.
Начните с расширения браузера и одного нормального SOCKS5-узла. Этого хватит, чтобы веб-версия работала предсказуемо, а вы перестали искать кнопку «Прокси» там, где её никогда не было. Подобрать узел под свою задачу можно в каталоге прокси, там же видно протоколы и география без лишних телодвижений.