Половина вопросов начинается с одного сценария: вписал данные прокси в Telegram Desktop, статус горит зелёным Connected, а сообщения висят с одной галочкой. Или скорость такая, что гифка грузится минуту. Причина почти всегда одна: выбран не тот тип соединения или данные вписаны не в то поле.
Разберу по шагам, куда нажимать в десктопе на Windows, macOS и Linux, чем SOCKS5 отличается от MTProto на уровне архитектуры, как проверить, что трафик реально идёт через узел, и какие грабли встречаются чаще всего. Интерфейс за последние годы почти не менялся, только пункты меню слегка переехали.
В Telegram Desktop два разных прокси, и это главная путаница
Настройки живут в двух местах. Первое: Settings → Advanced settings → Connection. Здесь подключается SOCKS5, обычный транспортный туннель. Второе: Settings → Data and storage, прокси-раздел в самом низу. Здесь MTProto, родной протокол Telegram.
Разница не косметическая. SOCKS5 просто перекладывает TCP-поток на удалённый сервер, ему всё равно, что внутри. MTProto оборачивает трафик в собственный контейнер с секретом, клиент мультиплексирует несколько соединений в один поток. В моих тестах на слабом мобильном канале отправка фото через MTProto укладывалась в 4-6 секунд против 9-12 через SOCKS5. Зато SOCKS5 можно переиспользовать в других приложениях, а MTProto работает только с Telegram.

SOCKS5 в Telegram на ПК: куда именно нажимать
Порядок одинаковый для Windows и macOS, в Linux-сборке подписи те же.
- Клик по иконке профиля или по трём полоскам в левом верхнем углу, дальше Settings.
- Вкладка Advanced settings, внутри пункт Connection type, в русской локали «Тип соединения».
- Радиокнопка Use your own proxy, то есть «Использовать собственный прокси».
- Протокол оставляем SOCKS5.
- Заполняем Host, Port, Username, Password. Хост это домен или адрес, порт число, логин с паролем выдаёт провайдер узла.
- Save. Статус под строкой должен стать зелёным, Connected.
Рядом галочка «Использовать прокси для звонков». Если её не поставить, голосовые и видеозвонки пойдут напрямую, мимо туннеля. Для разговоров с коллегами в другой стране это заметно: без прокси на звонках задержка доходила до 400 мс, разговор превращался в рацию.
Пароль с логином часто оставляют пустыми, если узел настроен на авторизацию по адресу подключения. Тогда достаточно хоста и порта. Но если провайдер выдал пару логин-пароль, а вы её не вписали, Telegram будет молча висеть на статусе Connecting. Это самая частая причина «не работает» на ровном месте.
MTProto: когда он реально лучше SOCKS5
Идём в Settings → Data and storage, листаем до конца, пункт Proxy, кнопка Add proxy. Тип соединения переключаем на MTProto, появляются три поля: сервер, порт, секрет. Порт обычно 443, секрет это длинная hex-строка, её выдаёт владелец узла.
Почему 443? Корпоративные файрволы, гостиничные сети и вузовские Wi-Fi чаще всего открывают наружу только 80 и 443, остальные порты режут. Узел на 443 выглядит для такого файрвола как обычный HTTPS-трафик. Поэтому соединение проходит там, где порт 1080 даже не поздоровается. В половине офисов, куда меня звали настраивать рабочие чаты, открыт только 443 — банальная сетевая гигиена, никакой магии.
Секрет в MTProto это не просто пароль. Из него выводится ключ, которым шифруется поток, он же определяет, к какому именно прокси-инстансу вы попали. Перепутали символ, и клиент честно скажет, что соединение не установлено, при этом сам сервер будет пинговаться.
После добавления узел появляется в списке с переключателем. Включили, внизу экрана появляется плашка с текущим статусом и пингом. Пинг в 70-120 мс из Москвы до Франкфурта это норма, 300+ уже повод искать узел ближе.
Ссылка вместо ручного ввода
Владельцы узлов почти всегда отдают готовую ссылку. В буфере обмена она лежит как обычный текст, в Telegram Desktop достаточно открыть Proxy и нажать Add proxy, поля заполнятся сами, если ссылка предварительно скопирована. В мобильном клиенте то же самое: тап по ссылке, подтверждение, готово.
Совет из практики: перед тем как куда-то вставлять ссылку, посмотрите, что в ней. Домен, порт и секрет должны совпадать с тем, что написано в кабинете провайдера. Мне попадались «подарочные» ссылки в чатах, где домен отличался на одну букву, а секрет вёл на чужой узел. Человек подключался и полгода не понимал, почему переписка открывается с задержкой в две секунды.
WEB-прокси в свежих сборках Desktop
В актуальных версиях Telegram Desktop появился третий вариант, его называют WEB proxy. Схема такая: клиент стучится по HTTPS на 443 к вашему поддомену, там стоит обратный прокси с валидным сертификатом Let's Encrypt, он передаёт трафик внутреннему MTProxy. Для внешнего наблюдателя это обычный защищённый HTTPS-сайт, без нестандартных портов и самопальных сертификатов.
Важный нюанс: в этом режиме нужен нормальный DNS-hostname. Просто адрес не подойдёт, потому что сертификат выписывается на домен, а клиент проверяет цепочку. Работает всё исключительно на 443. Если поднимаете такой узел для команды, заранее купите домен, направьте поддомен на сервер и выпустите сертификат. В моём тесте связка поднялась за вечер, схема простая: клиент, HTTPS на 443, обратный прокси, внутренний MTProxy, Telegram.
Проверка: три способа убедиться, что трафик идёт через узел
- Статус в настройках. Зелёный Connected и живой пинг означают, что TCP-сессия установлена, но не гарантируют, что через узел идёт именно медиа.
- Бот @userinfobot. Он отвечает вашим текущим адресом подключения. Совпал с адресом узла, значит трафик действительно ушёл туда.
- Скорость. Прогоните отправку файла на 20-30 МБ до и после включения. Если до было 8 МБ/с, а стало 0,7, узел перегружен, меняйте.
Третий пункт многие игнорируют. Прокси с пингом 60 мс может отдавать 200 КБ/с, если на нём висит триста человек. Пинг меряет задержку, а не полосу. Для десктопа это критично: на телефоне вы просто не заметите, а на компьютере с включённой синхронизацией чатов постоянные лаги бесят.
Почему дешёвые узлы умирают за неделю
Публичные списки прокси живут от нескольких часов до трёх суток. Причина простая: один адрес, сотни подключений, антифрод Telegram помечает его как подозрительный, новые сессии начинают отваливаться. Плюс владелец сервера видит нагрузку и просто гасит инстанс.
Второй сценарий, который встречаю постоянно: человек берёт «безлимитный» прокси за 50 рублей, тот месяц работает, потом начинает рвать соединение каждые пять минут. В техподдержке отвечают «перезагрузите клиент». В итоге на переключения между узлами уходит больше времени, чем на работу.
Для регулярного использования нужен либо платный пул с нормальным SLA, либо свой сервер. Третьего не дано.
Свой VPS: полчаса и 200-300 рублей в месяц
Минимальная конфигурация для личного или небольшого командного узла: 1 vCPU, 1 ГБ RAM, 20 ГБ диска, Ubuntu 22.04. Этого хватает на 30-50 одновременных подключений MTProto без деградации. Больше людей — больше памяти, но не кардинально: узкое место у MTProxy это не процессор, а канал.
Что важно сделать сразу. Отключить подробные логи, чтобы на диске не оседали метаданные подключений. Поставить автозапуск через systemd, иначе после перезагрузки сервера узел не поднимется, и вы узнаете об этом от коллег. Ограничить число соединений с одного адреса — защита от случайного перегруза. И настроить мониторинг хотя бы на пинг снаружи.
Канал выбирайте по географии команды. Сервер во Франкфурте из Москвы даёт 40-70 мс, из Новосибирска уже 90-110. Если половина людей в Сибири, а половина в Питере, либо два узла, либо один в Москве.
Локация важнее мощности сервера
Люди упорно берут узлы подешевле в Америке, а потом жалуются на подвисания. Расстояние напрямую бьёт по задержке, а она в мессенджере заметнее, чем полоса. Открытие чата с историей на 50 тысяч сообщений это сотни мелких запросов, и при 180 мс каждый вы физически ощущаете «тяжесть» интерфейса.
Правило простое: узел в той же стране или на 1000-1500 км от основных пользователей. Для команды из России это Москва, Питер или ближайшие европейские точки. Для парсинга и фоновых задач география уже не так важна, там главное стабильность и ротация.
Корпоративный сценарий: один узел на отдел
Распределённая команда на 15-20 человек, у всех рабочие чаты, файлы, звонки. Общий узел в одном регионе выравнивает картину: у людей в роуминге и в офисах с кривым Wi-Fi скорость становится предсказуемой. Ставится на том же VPS, отдельный инстанс с секретом для сотрудников, при увольнении секрет меняется в один клик.
Логика простая: вы управляете точкой входа, видите нагрузку, можете поднять второй узел в другом регионе за десять минут. При аренде у стороннего провайдера всё это превращается в переписку с поддержкой.
Для корпоративных сценариев часто берут выделенный адрес. Общие пулы дешевле, но соседи могут генерировать нагрузку, и вы получите просадки, к которым отношения не имеете.
Звонки, медиа и мелочи, которые бесят
Галочка «Использовать прокси для звонков» по умолчанию выключена. Включили, звонки идут через туннель, качество зависит от узла: к UDP-трафику прокси относится менее нежно, чем к TCP. На узле с каналом 100 Мбит и одним человеком всё отлично, на общем пуле возможны провалы.
Ещё момент: истории и медиа кэшируются локально. После смены прокси старые файлы грузятся с диска, и кажется, что новый узел летает. Проверяйте на новых чатах, а не на переписке, которую открывали сто раз.
И совсем банальное: Telegram Desktop игнорирует системные настройки прокси Windows. Настроили туннель в параметрах системы, клиент об этом не знает, ему нужно прописать всё в своём меню. Классика, когда «в браузере работает, а в телеге нет».
Отличия в интерфейсе на macOS и Linux
На маке путь тот же: Telegram → Settings → Advanced → Connection type. Разница только в том, что меню настроек открывается через пункт в верхней строке приложения, а не через иконку профиля. Логика полей идентичная.
В Linux-сборке (та, что ставится из репозитория или как AppImage) всё зеркалит Windows один в один. Единственный нюанс: если у вас туннель поднят на уровне системы через NetworkManager, Telegram Desktop его тоже не увидит. Всё прописывается внутри клиента, отдельно для каждого экземпляра приложения.
Мобильные клиенты: то же самое, три тапа
Android: Settings → Data and storage → Proxy → Add proxy. iOS: Settings → Data and Storage → Proxy. Поля те же: сервер, порт, секрет либо логин с паролем для SOCKS5.
Настройки не синхронизируются между устройствами. Прописали на ПК, на телефоне всё равно нужно повторить. Плюс на мобильных есть автопереключение при смене сети, иногда после перехода с Wi-Fi на LTE прокси отваливается, помогает ручной переключатель в том же меню.
Несколько аккаунтов и парсинг
В Telegram Desktop можно держать три аккаунта в одном окне, но настройки прокси общие для всего клиента. Все три пойдут через один узел, и с точки зрения внешнего наблюдателя это один адрес. Для рабочих аккаунтов нормально, для парсинга каналов и работы с большим числом чатов уже риск.
Для сбора данных из публичных каналов логика другая: отдельный узел на аккаунт, паузы между запросами, лимит в районе 20-30 обращений в минуту. Один адрес на десять аккаунтов это почти гарантированные ограничения в течение суток.
Если аккаунтов много и они на разных машинах, берите пул с ротацией: каждый экземпляр клиента получает свой адрес, и падение одного не тянет за собой остальные.
Пять ошибок, которые я вижу чаще всего
- В поле хоста вписали адрес, а нужен hostname. Актуально для WEB-прокси и узлов с проверкой сертификата.
- Порт 1080 на офисной сети закрыт, человек сидит и ждёт. Проверяйте 443 первым делом.
- Забыли логин с паролем при авторизации по учётке, статус висит на Connecting.
- Один узел на десять аккаунтов, потом жалобы на ограничения.
- Не включили галочку прокси для звонков и удивляются, почему голос идёт напрямую.
Где брать нормальный прокси под задачу
Когда нужен не один узел для себя, а пул под команду, парсинг или несколько регионов, проще взять готовое. В каталоге 3seller.com/proxy можно отфильтровать по стране, протоколу (SOCKS5 и MTProto), типу адреса (общие или выделенные) и количеству. Для Telegram на ПК хватает одного выделенного, для команды из 15 человек берут небольшой пул с запасом.
Смотрите на три параметра: страна выхода, тип адреса и лимит одновременных подключений. Всё остальное — маркетинг. И берите на месяц, а не на год, чтобы проверить полосу на своих задачах.
Что сделать прямо сейчас
Откройте Settings → Advanced settings → Connection, впишите данные узла, сохраните и проверьте статус. Дальше @userinfobot покажет, куда реально ушёл трафик. Если полоса не устраивает, меняйте узел, а не настройки клиента — они тут почти никогда не виноваты.
И держите под рукой второй адрес. Один узел это одна точка отказа, а прокси имеет свойство отваливаться именно в момент, когда нужно срочно отправить файл.