Я тоже рад. Но вопрос был про производительность. Прокси делает не очень много, нагрузка на 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 Какие уж спонсорские штуки, да множественные секреты.
А можете сделать 2 образа, один с pypy, другой с cpython (либо один образ, но с опциональным переключением)? Если память является узким местом, то PyPy — не лучший выбор. Помимо скорости, он еще ощутимо более прожорливый в смысле оперативки.
Прикинуться определенным юзерагентом — это здравая мысль, но помогает только в самых простых случаях. Еще нужно отправлять те хедеры, что посылает тот браузер, под который идет закос, причем очень желательно посылать в том же порядке, в котором их сам браузер и расставляет.
Я тоже рад. Но вопрос был про производительность. Прокси делает не очень много, нагрузка на 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. Чем отличается ваш подход?