Классная статья, это же FUD прямо в каноническом виде. Можно вставлять в учебники как есть. Если вдруг никогда не сталкивались, добавьте статью в закладки, такое в живой природе нечасто встречается.
Именно в таком виде IBM использовали эту стратегию, чтобы манипулировать продажами. Вот как Эрик Рэймонд вспоминает:
The idea, of course, was to persuade buyers to go with safe IBM gear rather than with competitors' equipment. This implicit coercion was traditionally accomplished by promising that Good Things would happen to people who stuck with IBM, but Dark Shadows loomed over the future of competitors' equipment or software. After 1991, the term has become generalized to refer to any kind of disinformation used as a competitive weapon.[11]
Мне нравится:
Противопоставление двух позиций, будто бы соревнующихся
Полунамеки на то, что вон там петлю затягивают
Намеки на то, что да, плохо, но зато честно, а значит, с этим можно будет жить (почему-то стены обязательно рушатся, а не хребты ломаются)
Умолчание, что и в Европе стены ломаются или не допускаются (вспомним историю Chat Control)
Ложная эквивалентность (и там чот не то, и тут чот не то - а значит везде одинаково чот не то)
Намек на то, что здесь хуже не будет, а там все только начинается
Причем намек, основанный на отдельном, не подтвержденный ничем слухе, вынесенном в заголовок
Короче, все испугались, засомневались, и ну его это все, конечно. Всей правды же не узнаем.
Прокси здесь особо не причем. Проблема была в TLS-финегрпринте, с который Telegram подключался к прокси, то есть проблема на клиенте. Будем надеяться, что в ближайших обновлениях клиента все снова заработает.
Работало оно странно, потому что блокировка не очень детерминированая: подозрительный трафик определялся сразу, но пропускалось несколько соединений, прежде чем IP-адрес отлетал в бан.
Я понимаю, что время тревожное, но как было бы здорово, если бы авторы статей поэкономили яркие формулировки. Не переживайте, в будущем еще пригодятся.
Никак, просто пользуйтесь. mtg не поддерживает adtag, а следовательно и регистрировать нечего. Если вам принципиально нужна поддержка такого промо, используйте telemt
У mtg есть свои особенности, которые могут не всех устроить:
Только прямое подключение к "ядру" Телеграма
Только один секрет на пользователя
Невозможность шейпить трафик
Если нужны все эти штуки, посмотрите на другие проекты: все, кроме mtg, умеют подключаться к так называемым middle proxies, промежуточным серверам Телеграма. Раньшее такая конструкция была нужна только для adtag: это такая функциональность, когда владелец прокси может "запинить" какой-то канал у всех пользователей этого прокси. Больших преимуществ такая архитектура не дает, однако в случае, если "ядро" сбоит, возможность пойти другим путем - ценная.
Здравствуйте. Я автор mtg. Скорее всего статика плохо работала из-за настройки auto-update. Попробуйте ее отключить. Сервера, которые приходят из конфига для Телеграма как-то стали странно работать, но захардкоженный - вполне
Я тоже рад. Но вопрос был про производительность. Прокси делает не очень много, нагрузка на CPU минимальная. Если где-то что-то медленно, давайте я это отпрофилирую и пофикшу.
Просто не было большой нужды обновлять. Активность и заинтересованность пользователей сильно спала после предыдущей разблокировки Телеграма. Какие-то проблемы были, но неясно как было их решать, либо они были скорее необязательными хотелками. Я надеялся, что все, никому больше ничего не нужно в целом. Накачивать фичами ради фич я не люблю.
Моя претензия в том, что вы в своей табличке сравнили 2 проекта. Один все может, а второй — камень. Тогда как по факту еще с 21 года (5 лет как) mtg умеет все из вышеперечисленного. Кроме того, сравнение про active probing ну уж совсем возмутительное. Пробуем — не работает, ха-ха, фу. Одновременно с тем, оно работает уже с 2019, что ли года, и более того, об этом написано чуть не в первых строчках README.
Ваша замечательная статья больше похоже на некрасивое продвижение прекрасного проекта, и в чем-то отбрасывает на него тень.
Здравствуйте. Я автор mtg. Я очень рад за telemt, это прекрасный проект, но когда вы расказываете об mtg, давайте не будем врать.
У nineseconds/mtg на это нет ответа. Если клиент приходит без правильного секрета, mtg просто дропает соединение. Краулер это видит и делает выводы.
Это ложь. У mtg активная защита работает как минимум лет 5. Более того, у меня там есть и защита от replay-аттак, и подписки на черные и белые списки, и многое другое.
Провел эксперимент. Завел виртуальную машину, скопировал mtg и конфиг. Сгенерировал секрет.
Все работает ровно так, как и ожидается. Я даже не знаю, как сделать так, чтобы оно не работало так, как ожидается. Возвращается ответ, побайтово идентичный ответу сервера.
У mtg есть 2 режима - полноценный конфиг (тоже в TOML, раз вы об этом упомянули как о чем-то важно) + упрощенный режим, чтобы одной командой - и полетели. Даже называются так: run и simple-run.
Пользователи - да, один секрет. Это идеалогия проекта. Нет никакого практического смысла иметь больше. Прокси в современном мире - эфемерная штука, которая живет считанные дни, разводить разделение прав и тп - глупости.
Апстрим - в том числе и SOCKS5. В этом можно убедиться, если прочитать хотя бы 20 строчек README + заглянуть в конфиги.
Статус проекта - правда что ли заброшен? Ну дела! Новая версия вышла несколько часов назад.
Есть настройка, которая позволяет перенаправлять такие запросы в другие DC. 203 DC = CDN. Если кто-то вдруг имеет понятие, каким образом к нему подключаться - добавлю поддержку.
tl;dr - нет, и с этим, похоже, придется жить. Оно должно примерно одинаково работать во всех прокси с direct-режимом.
Давайте теперь чуточку развернутее отвечу.
Так получилось, что MTPROTO-proxy работают в двух режимах. Неофициально они называются direct и adtag.
Изначально был только direct-режим. Грубо говоря, он выглядит так: клиент открывает соединение и посылает хендшейк, из которого прокси должен получить информацию о датацентре, к которому хочет подключиться клиент + параметры для AES-CTR. Дальше прокси должен подключиться к нужному IP-адресу (захардкоженному) и по такой же процедуре передать данные дальше. То есть прокси фактически занимается тем, что потоково расшифровывает данные от клиента и зашифровывает для сервера и наоборот.
Есть еще режим adtag. Когда-то давно команда Telegram решила поддержать держателей прокси тем, что те могли закрепить какой-то канал у всех пользователей этого прокси и таким образом монетизироваться. Вот только работает эта штука совсем иначе: когда приходит запрос, нам недостаточно просто передать его куда-то. Telegram поддерживает постоянно ротируемый список так называемых middle-proxy, к которым должен подключаться наш софт. Но не абы как: для простоты своей реализации теперь пользовательские данные надо оборачивать в RPC-запрос, куда прописывается adtag сотоварищи. По сравнению с direct-режимом, для этого нужно держать целую тонну довольно неприятного кода, который сложно как тестировать, так и просто нормально написать из-за целой кучи чисто технических нюансов. Например, общение с клиентом идет в режиме потока, тогда как общение с middle-proxy - пакетное.
Во второй версии я выкинул из mtg поддержку adtag, поскольку мне показалось это тупиковой идеей: вместо того, чтобы монетизировать IP-адрес, надо наоборот, воспринимать его как нечто эфемерное. Поймали, заблокировали - новый поднимем. Разводить из-за этого целые церемонии с ботом + держать кучу реально неприятного кода не хотелось.
Где-то в 22 году чего-то поменялось, и через прокси стали тормозить кружочки, фоточки и видео. Я тогда не меньше месяца потратил на дебаг, и пришел вот к какому-выводу: https://github.com/9seconds/mtg/issues/283#issuecomment-1247789563 В телеграме появился CDN, который позволил снять часть проблем с загрузкой контента. Однако в direct-реализации все заворачивается в MTPROTO, и идет на DC-адреса. Технически, Телеграм умеет отвечать на запросы из каждого DC, но это долго, а иногда и таймаутится.
Как я понимаю, в других реализациях, которые тащут adtag-режим, все может работать иначе, потому что у них коннект к Телеграму идет по другим адресам.
Все верно, именно так и живет все, что касается, например, ShadowSocks: быстро разворачиваем, пользуемся, пока не прибили. Сами прокси передаются либо сарафанным радио (во всех клиентах даже есть возможность считывания QR-кода + его генерация для каких-нибудь существующих), либо через сайты вроде free-ss.site Какие уж спонсорские штуки, да множественные секреты.
Классная статья, это же FUD прямо в каноническом виде. Можно вставлять в учебники как есть. Если вдруг никогда не сталкивались, добавьте статью в закладки, такое в живой природе нечасто встречается.
Именно в таком виде IBM использовали эту стратегию, чтобы манипулировать продажами. Вот как Эрик Рэймонд вспоминает:
Мне нравится:
Противопоставление двух позиций, будто бы соревнующихся
Полунамеки на то, что вон там петлю затягивают
Намеки на то, что да, плохо, но зато честно, а значит, с этим можно будет жить (почему-то стены обязательно рушатся, а не хребты ломаются)
Умолчание, что и в Европе стены ломаются или не допускаются (вспомним историю Chat Control)
Ложная эквивалентность (и там чот не то, и тут чот не то - а значит везде одинаково чот не то)
Намек на то, что здесь хуже не будет, а там все только начинается
Причем намек, основанный на отдельном, не подтвержденный ничем слухе, вынесенном в заголовок
Короче, все испугались, засомневались, и ну его это все, конечно. Всей правды же не узнаем.
Прокси здесь особо не причем. Проблема была в TLS-финегрпринте, с который Telegram подключался к прокси, то есть проблема на клиенте. Будем надеяться, что в ближайших обновлениях клиента все снова заработает.
Работало оно странно, потому что блокировка не очень детерминированая: подозрительный трафик определялся сразу, но пропускалось несколько соединений, прежде чем IP-адрес отлетал в бан.
Я понимаю, что время тревожное, но как было бы здорово, если бы авторы статей поэкономили яркие формулировки. Не переживайте, в будущем еще пригодятся.
Никак, просто пользуйтесь. mtg не поддерживает adtag, а следовательно и регистрировать нечего. Если вам принципиально нужна поддержка такого промо, используйте telemt
Помимо mtg есть еще реализации:
https://github.com/alexbers/mtprotoproxy
https://github.com/seriyps/mtproto_proxy
https://github.com/telemt/telemt
У mtg есть свои особенности, которые могут не всех устроить:
Только прямое подключение к "ядру" Телеграма
Только один секрет на пользователя
Невозможность шейпить трафик
Если нужны все эти штуки, посмотрите на другие проекты: все, кроме mtg, умеют подключаться к так называемым middle proxies, промежуточным серверам Телеграма. Раньшее такая конструкция была нужна только для adtag: это такая функциональность, когда владелец прокси может "запинить" какой-то канал у всех пользователей этого прокси. Больших преимуществ такая архитектура не дает, однако в случае, если "ядро" сбоит, возможность пойти другим путем - ценная.
К сожалению, вы неправильно собираете секрет. Дело в том, что рандом - это первые 16 байтов + префикс, а не последние. У вас получается рандомный SNI.
Здравствуйте. Я автор mtg. Скорее всего статика плохо работала из-за настройки auto-update. Попробуйте ее отключить. Сервера, которые приходят из конфига для Телеграма как-то стали странно работать, но захардкоженный - вполне
Я тоже рад. Но вопрос был про производительность. Прокси делает не очень много, нагрузка на CPU минимальная. Если где-то что-то медленно, давайте я это отпрофилирую и пофикшу.
Просто не было большой нужды обновлять. Активность и заинтересованность пользователей сильно спала после предыдущей разблокировки Телеграма. Какие-то проблемы были, но неясно как было их решать, либо они были скорее необязательными хотелками. Я надеялся, что все, никому больше ничего не нужно в целом. Накачивать фичами ради фич я не люблю.
Моя претензия в том, что вы в своей табличке сравнили 2 проекта. Один все может, а второй — камень. Тогда как по факту еще с 21 года (5 лет как) mtg умеет все из вышеперечисленного. Кроме того, сравнение про active probing ну уж совсем возмутительное. Пробуем — не работает, ха-ха, фу. Одновременно с тем, оно работает уже с 2019, что ли года, и более того, об этом написано чуть не в первых строчках README.
Ваша замечательная статья больше похоже на некрасивое продвижение прекрасного проекта, и в чем-то отбрасывает на него тень.
Да, я уже выпустил новую версию. Спасибо!
В каком смысле превзошел по производительности? Расскажите.
Здравствуйте. Я автор mtg. Я очень рад за telemt, это прекрасный проект, но когда вы расказываете об mtg, давайте не будем врать.
Это ложь. У mtg активная защита работает как минимум лет 5. Более того, у меня там есть и защита от replay-аттак, и подписки на черные и белые списки, и многое другое.
Провел эксперимент. Завел виртуальную машину, скопировал mtg и конфиг. Сгенерировал секрет.
root@ubuntu-s-1vcpu-512mb-10gb-ams3-01:~# ./mtg-2.1.9-linux-amd64/mtg generate-secretvultr.com7giQTW41NdKt0_4VuxDrG_p2dWx0ci5jb20
Поменял секрет в конфиге, поставил 443 порт как у вас. Запустил
r
oot@bee:~# curl -ki --resolve vultr.com:443:68.183.5.244https://vultr.com
HTTP/2 301server: nginx
date: Mon, 16 Feb 2026 20:15:43 GMT
content-type: text/html
content-length: 162
location:
https://www.vultr.com/
expires: Tue, 17 Feb 2026 20:15:43 GMTcache-control: max-age=86400
strict-transport-security: max-age=63072000
x-content-type-options: nosniff
x-vid: 9120349
301 Moved PermanentlynginxВсе работает ровно так, как и ожидается. Я даже не знаю, как сделать так, чтобы оно не работало так, как ожидается. Возвращается ответ, побайтово идентичный ответу сервера.
Про образ
mtg тоже distroless. Контейнеры весят 4 мегабайта, внутри - сертификаты, конфиг + статически собранный бинарник: https://hub.docker.com/r/nineseconds/mtg + https://github.com/9seconds/mtg/pkgs/container/mtg
У mtg есть 2 режима - полноценный конфиг (тоже в TOML, раз вы об этом упомянули как о чем-то важно) + упрощенный режим, чтобы одной командой - и полетели. Даже называются так: run и simple-run.
Пользователи - да, один секрет. Это идеалогия проекта. Нет никакого практического смысла иметь больше. Прокси в современном мире - эфемерная штука, которая живет считанные дни, разводить разделение прав и тп - глупости.
Апстрим - в том числе и SOCKS5. В этом можно убедиться, если прочитать хотя бы 20 строчек README + заглянуть в конфиги.
Статус проекта - правда что ли заброшен? Ну дела! Новая версия вышла несколько часов назад.
Есть настройка, которая позволяет перенаправлять такие запросы в другие DC. 203 DC = CDN. Если кто-то вдруг имеет понятие, каким образом к нему подключаться - добавлю поддержку.
Когда Телеграм подключается к прокси, он дополнительно шифрует трафик через AES-CTR. Получается двойное шифрование, если задуматься.
tl;dr - нет, и с этим, похоже, придется жить. Оно должно примерно одинаково работать во всех прокси с direct-режимом.
Давайте теперь чуточку развернутее отвечу.
Так получилось, что MTPROTO-proxy работают в двух режимах. Неофициально они называются direct и adtag.
Изначально был только direct-режим. Грубо говоря, он выглядит так: клиент открывает соединение и посылает хендшейк, из которого прокси должен получить информацию о датацентре, к которому хочет подключиться клиент + параметры для AES-CTR. Дальше прокси должен подключиться к нужному IP-адресу (захардкоженному) и по такой же процедуре передать данные дальше. То есть прокси фактически занимается тем, что потоково расшифровывает данные от клиента и зашифровывает для сервера и наоборот.
Есть еще режим adtag. Когда-то давно команда Telegram решила поддержать держателей прокси тем, что те могли закрепить какой-то канал у всех пользователей этого прокси и таким образом монетизироваться. Вот только работает эта штука совсем иначе: когда приходит запрос, нам недостаточно просто передать его куда-то. Telegram поддерживает постоянно ротируемый список так называемых middle-proxy, к которым должен подключаться наш софт. Но не абы как: для простоты своей реализации теперь пользовательские данные надо оборачивать в RPC-запрос, куда прописывается adtag сотоварищи. По сравнению с direct-режимом, для этого нужно держать целую тонну довольно неприятного кода, который сложно как тестировать, так и просто нормально написать из-за целой кучи чисто технических нюансов. Например, общение с клиентом идет в режиме потока, тогда как общение с middle-proxy - пакетное.
Во второй версии я выкинул из mtg поддержку adtag, поскольку мне показалось это тупиковой идеей: вместо того, чтобы монетизировать IP-адрес, надо наоборот, воспринимать его как нечто эфемерное. Поймали, заблокировали - новый поднимем. Разводить из-за этого целые церемонии с ботом + держать кучу реально неприятного кода не хотелось.
Где-то в 22 году чего-то поменялось, и через прокси стали тормозить кружочки, фоточки и видео. Я тогда не меньше месяца потратил на дебаг, и пришел вот к какому-выводу: https://github.com/9seconds/mtg/issues/283#issuecomment-1247789563 В телеграме появился CDN, который позволил снять часть проблем с загрузкой контента. Однако в direct-реализации все заворачивается в MTPROTO, и идет на DC-адреса. Технически, Телеграм умеет отвечать на запросы из каждого DC, но это долго, а иногда и таймаутится.
Как я понимаю, в других реализациях, которые тащут adtag-режим, все может работать иначе, потому что у них коннект к Телеграму идет по другим адресам.
Попробуйте https://github.com/alexbers/mtprotoproxy, https://github.com/seriyps/mtproto_proxy или официальный https://github.com/TelegramMessenger/MTProxy но только именно с adtag. Если с ними все будет работать - ну и славно. Здесь еще активно упоминается https://github.com/telemt/telemt - там вроде заявлена поддержка adtag.
Если и с adtag такие тормоза, то, боюсь, сделать ничего без подключения кого-то со стороны Telegram, будет нельзя.
Все причесал, пыль сдул, в порядок привел. Проблема выше оказалась не проблемой.
Спасибо. Вы совершенно правы. В ближайшее время все обновлю и актуализирую. Тот проект, про который втайне надеешься, что он уже не будет актуальным.
А что не работает? Заведите issue
Я автор устаревшего проекта выше. Он давно не обновлялся, потому что не было особой необходимости. mtg ведет себя точно так же, прозрачно проксирует вышестоящий домен: https://github.com/9seconds/mtg/blob/e68d0c7da53b266019d33644b902e8872c84fe32/mtglib/proxy.go#L173-L181 + https://github.com/9seconds/mtg/blob/e68d0c7da53b266019d33644b902e8872c84fe32/mtglib/proxy.go#L263-L287
Практически все фреймворки для скрапинга асинхронные. От Scrapy до менее известных вроде Grab. Чем отличается ваш подход?