Открываете web.telegram.org, а он висит на подключении. Или менеджер пишет, что с ноутбука в коворкинге половина чатов не грузится. Прокси в клиенте добавляется в четыре клика. Только живут эти клики не там, где их ищут.
Ниже разберу по интерфейсу: где раздел, какой тип соединения выбрать, что делать со ссылкой из чата и почему форма иногда молча ничего не делает.
В веб-клиенте своего раздела прокси нет
Открываете браузерную версию, лезете в настройки и не находите ни слова про прокси. Логично: в веб-клиенте такого раздела нет. Трафик идёт через канал, заданный браузеру или операционной системе.
Отсюда главная путаница. Под фразой «как добавить прокси в тг веб» люди имеют в виду три разные вещи: браузерную версию, десктопное приложение и мобильный клиент. Интерфейс отличается, настройка живёт в разных местах.
Дальше по каждому варианту отдельно. Начну с десктопа: там полноценное меню, и именно его чаще всего называют «тг веб» по привычке.
Telegram Desktop: где живёт раздел подключения
В десктопном клиенте настройки соединения спрятаны на третьем уровне. Открываете приложение, жмёте на три горизонтальные полоски в левом верхнем углу, дальше «Настройки». В левом столбце ищете «Продвинутые настройки», внутри них «Тип соединения».
По умолчанию стоит автоматический режим. Переключаете на «Использовать собственный прокси», и только тогда активируется кнопка «Добавить прокси». Люди застревают ровно здесь: жмут «Добавить», не включив переключатель, и удивляются серой кнопке.
Дальше открывается форма: тип соединения, сервер, порт, для части типов логин с паролем или секретный ключ. Сохраняете, клиент сразу пробует соединение. Статус видно в этом же окне, перезапуск не нужен.
Пошагово: как добавить прокси в тг веб
Последовательность для десктопного клиента, проверенная на актуальных сборках:
- Открываете Telegram Desktop.
- Меню из трёх полосок слева вверху, затем «Настройки».
- «Продвинутые настройки» и следом «Тип соединения».
- Включаете «Использовать собственный прокси».
- Жмёте «Добавить прокси» и выбираете тип: MTProto, SOCKS5, HTTP или WEB.
- Заполняете сервер и порт, при необходимости логин с паролем или секретный ключ.
- Сохраняете и ждёте пару секунд, пока клиент переподключится.
После сохранения старый канал рвётся, новый встаёт не мгновенно. Чаты грузятся через три-четыре секунды, и это норма. Если статус висит в «Соединение», параметры не подошли, форму надо открыть заново.
Типы соединения и разница на уровне архитектуры
Четыре варианта в выпадающем списке не косметика. Разница в том, как упаковывается трафик и что должен уметь сервер на другой стороне.
MTProto. Родной протокол мессенджера. Пакеты заворачиваются в собственную обёртку, поверх работает секретный ключ, который генерируется при поднятии узла. Накладных расходов меньше: не нужно тащить чужой протокол и пересобирать поток. Минус один: сервер должен уметь именно MTProto. Обычный VPS с настроенным Squid не подойдёт, ключ не сойдётся.
SOCKS5. Работает на транспортном уровне: перенаправляет TCP-потоки и не лезет внутрь. Шифрование обеспечивает сам клиент, прокси в этом не участвует. Авторизация по логину и паролю, гибкая маршрутизация, поддержка почти у любого провайдера. Универсальный выбор, когда не хочется думать.
HTTP. Тот же принцип, но через метод CONNECT. Проще в настройке, чуть выше задержка на установку туннеля. Заходит там, где инфраструктура заточена под веб-трафик и не любит нестандартные протоколы.
WEB. Самый молодой тип, появился в десктопной версии 7.1.1. Про него отдельно: там есть неочевидное требование.
WEB-прокси: нужен домен, а не адрес сервера
Схема, которую собрали практики, выглядит так: клиент идёт на HTTPS, дальше обратный прокси вроде Caddy, дальше tproxy-server, дальше MTProxy, и уже оттуда в Telegram. Снаружи весь путь выглядит как обычный HTTPS-запрос к сайту.
Ключевая деталь: в поле сервера для WEB-типа нужен нормальный DNS-hostname с валидным сертификатом Let's Encrypt. Числовой адрес не сработает, соединение не установится. И только стандартный HTTPS-порт, экзотические номера не пройдут. В обсуждениях на Reddit администраторы каналов отмечают, что спотыкаются чаще всего именно на сертификате, а не на самом узле.
Для корпоративного узла вариант удобный. Поднимаете отдельный поддомен, выпускаете сертификат, раздаёте сотрудникам одну ссылку. Внутри зашиты hostname и secret: при переходе приложение само предлагает добавить соединение, руками ничего вбивать не надо. На Windows всё заводится сразу после сохранения.
Ссылка в буфере экономит минуту жизни
Прислали готовую ссылку на прокси - вручную поля заполнять не нужно. Открываете окно «Добавить прокси», вставляете ссылку, и сервер, порт и ключ подставляются сами. Остаётся нажать сохранение и проверить статус.
Один момент, который редко проговаривают. Ссылка ведёт на конкретный узел конкретного человека. Через SOCKS5 без собственного шифрования на уровне прокси видно объём трафика и направления запросов, даже если содержимое закрыто. Брать такие ссылки стоит у тех, кому доверяете, а не из первого сообщения в тематическом чате.
Почему не подключается: пять причин из практики
Форма сохранилась, статус висит, чаты молчат. Разбор почти всегда упирается в одно из пяти.
Не тот тип. Выдали доступ по SOCKS5, а выбран MTProto. Ключа нет, форма ругается или принимает пустое поле и молча не соединяется. Тип должен совпадать с тем, что реально поднято на сервере.
Логин и пароль. Для SOCKS5 они часто обязательны, и их путают с паролем от аккаунта. Если провайдер выдал отдельную пару, вводить надо именно её.
Мёртвый узел. Прокси живёт, пока жива сессия. У дешёвых пулов адрес меняется по расписанию, и старые настройки умирают без предупреждения. Симптом: вчера работало, сегодня нет, ничего не трогали.
Сеть режет нестандартные порты. Гостиничный или офисный Wi-Fi спокойно пропускает только HTTPS. Рабочий вариант здесь WEB-тип: он идёт по стандартному защищённому порту и не выглядит подозрительно для фильтра.
DNS не резолвится. Для WEB-типа нужен hostname, который реально разрешается снаружи. Запись в hosts на другом компьютере не поможет.
Мобильные клиенты: iOS и Android
На iPhone и iPad путь другой. Открываете Telegram, нижняя вкладка «Настройки», дальше «Данные и память». Прокручиваете до раздела «Прокси», включаете «Использовать прокси», жмёте «Добавить прокси». Дальше тип SOCKS5 или MTProto, сервер, порт, при необходимости логин с паролем или секретный ключ. Сохранение, потом проверка статуса.
На Android похоже, только вход через меню. Три полоски в левом верхнем углу, «Настройки», «Данные и память», вниз до «Прокси». Включаете переключатель, «Добавить прокси», выбираете SOCKS5, заполняете поля, подтверждаете галочкой. Клиент сам тестирует соединение и показывает результат.
Настройки привязаны к аккаунту, поэтому на десктопе подхватятся не всегда автоматически. Проще один раз пройти форму на каждом устройстве, чем гадать, почему на телефоне работает, а на ноутбуке нет.
Браузерная версия: настраивать надо не в Telegram
У web.telegram.org нет собственного раздела прокси. Канал задаётся браузером или операционной системой: в Chrome на Windows это системные настройки, в Firefox есть отдельный раздел сети с собственными параметрами.
Практический приём, который экономит нервы: держите браузерный клиент в отдельном профиле. Тогда через прокси идёт только он, остальные вкладки работают напрямую. Иначе получается классическая ситуация: включил прокси ради одного мессенджера, а потом полдня ловит таймауты в банке и почте.
Отдельный профиль удобен и для нескольких аккаунтов. У каждого свой канал, свои cookie, никакой путаницы с сессиями.
Где это нужно в работе, а не только для порядка
Самый частый сценарий в моих проектах - парсинг открытых каналов и мониторинг упоминаний бренда. Десятки запросов с одного адреса быстро приводят к пустым ответам, поэтому выходы распределяют и меняют. Второй сценарий: несколько рабочих аккаунтов у одного человека, у каждого свой узел, чтобы не собирать активность в одну точку.
Третий, недооценённый: стабильная задержка. Менеджеры на публичном Wi-Fi в коворкинге или аэропорту теряют голосовые звонки не из-за мессенджера, а из-за сети. Нормальный узел с предсказуемым маршрутом лечит это лучше любых танцев с настройками.
Четвёртый, корпоративный. Компания поднимает собственный узел, чтобы трафик сотрудников шёл через контролируемую точку, а не через случайные сети. С WEB-типом это выглядит как обычный HTTPS и не требует ставить на каждую машину дополнительный софт.
Как выбирать прокси под задачу
Смотреть стоит на четыре вещи. Тип: SOCKS5 для универсальности, MTProto когда нужен минимум накладных расходов, WEB когда среда пропускает только защищённый веб-трафик. География: exit-узел в нужной стране решает половину проблем с локальными сервисами. Стабильность: uptime важнее цены, мёртвый узел в середине рабочего дня стоит дороже подписки. Авторизация: логин и пароль означают, что узел не открыт всему интернету, а это уже про безопасность.
Готовый каталог с фильтрами по типу, стране и формату авторизации лежит тут: каталог прокси 3seller. Выбираете нужный тип, получаете данные для формы и вбиваете их в поля из инструкции выше.
Отдельно про ротацию. Если задача связана с массовыми запросами, берите пул с автоматической сменой адреса. Тогда не придётся раз в сутки переписывать настройки в клиенте и объяснять команде, почему опять всё отвалилось.
Что сделать прямо сейчас
Откройте десктопный клиент, пройдите по меню до «Тип соединения» и посмотрите, что стоит. В девяти случаях из десяти там автоматический режим, хотя человек уверен, что прокси уже настроен. Включите переключатель, добавьте узел нужного типа, сохраните и дождитесь статуса «Подключено».
Если чаты всё равно висят, меняйте не настройки, а узел. Форма в Telegram простая и предсказуемая, ошибки почти всегда на стороне сервера, а не интерфейса.