Force tcp telegram что это
Перейти к содержимому

Force tcp telegram что это

  • автор:

Transports

Enables the delivery of encrypted containers together with the external header (hereinafter, Payload) from client to server and back. Multiple transport protocols are defined:

The URI format for connecting to the websocket and HTTP endpoints is the following:

The TCP transport is implemented simply by sending the payloads generated by the chosen MTProto transport over a plain TCP socket on ports 80, 443, 5222 or other (a different port number may be returned by help.getConfig).

Framing is managed by the chosen MTProto transport protocol.

There are no implicit acknowledgments for the TCP transport: all messages must be acknowledged explicitly. Most frequently, acknowledgments are placed in a container with the next query or response if it is transmitted in short order. For example, this is almost always the case for client messages containing RPC queries: the acknowledgment normally arrives with the RPC response.

Websocket

Implementation of the websocket transport is pretty much the same as with TCP: a websocket connection is established to the chosen MTProto server over port 80 using the specified URI format.

Framing of payloads is still managed by the chosen MTProto transport protocol, not by websocket messages: the length of MTProto payloads is defined by the MTProto transport protocol, not by the length of the single websocket messages. This simply means that all data received and sent through websocket messages is to be treated as a single duplex stream of bytes, just like with TCP.

When using the websocket transport, transport obfuscation is required. Transport errors are transmitted the usual way, as with TCP. The close code of websockets will always be 1000 (normal closure), regardless of the actual exit status. In all cases, the description string will be a decimal encoded real error code (which may be forward/back-padded with whitespaces for constant length) and can be safely ignored.

Websocket over HTTPS

To establish a websocket connection over HTTPS, simply use the TLS URI format. The rest is the same as with plain websockets.

Note: when implementing browser clients, websocket transport is recommended instead of HTTP, thanks to its full-duplex stream logic similar to TCP’s; this removes the need for HTTP long polling and eventual delays while relaying RPC replies.

Implemented over HTTP/1.1 (with keepalive) running over the traditional TCP Port 80. HTTPS can also be used.

Message framing is not managed by MTProto transport protocols; it is instead handled by the HTTP protocol itself. Transport errors are also not transmitted the usual way, instead they are simply returned as normal HTTP status codes.

An HTTP connection is attached to a session (or rather, to session + key identifier) specified in the most recent user query received; normally, the session is the same in all queries, but crafty HTTP proxies may corrupt that. A server may not return a message into an HTTP connection unless it belongs to the same session, and unless it is the server’s turn (an HTTP request had been received from the client to which a response has not been sent yet).

The overall arrangement is as follows. The client opens one or more keepalive HTTP or HTTPS connections to the server. If one or more messages need to be sent, they are made into a payload which is followed by a POST request to the URL/api to which the payload is transmitted as data. In addition, Content-Length , Keepalive , and Host are valid HTTP headers.

Having received the query, the server may either wait a little while (if the query requires a response following a short timeout) or immediately return a dummy response (only acknowledging the receipt of the container). In any case, the response may contain any number of messages. The server may at the same time send out any other messages it might be holding for the session.

In addition, there exists a special long poll RPC query (valid for HTTP connections only) which transmits maximum timeout T. If the server has messages for the session, they are returned immediately; otherwise, a wait state is entered until such time as the server has a message for the client or T seconds have elapsed. If no events occur in the span of T seconds, a dummy response is returned (special message).

If a server needs to send a message to a client, it checks for an HTTP connection that belongs to the required session and is in the “answering an HTTP request” state (including long poll) whereupon the message is added to the response container for the connection and sent to the user. In a typical case, there is some additional wait time (50 milliseconds) against the eventuality that the server will soon have more messages for the session.

If no suitable HTTP connection is available, the messages are placed in the current session’s send queue. However, they find their way there anyway until receipt is explicitly confirmed by the client. For all protocols, the client must return an explicit acknowledgment within a reasonable time (it can be added to a container for the following request).

Important: if the acknowledgment fails to arrive on time, the message can be resent (possibly, in a different container). The parties must autonomously be ready for this and must store the identifiers of the most recent messages received (and ignore such duplicates rather than repeat actions). In order not to have the identifiers stored forever, there exist special garbage collection messages that take advantage of message identifier monotonicity.

If the send queue overflows or if messages stay in the queue for over 10 minutes, the server forgets them. This may happen even faster, if the server is running out of buffer space (for example, because of serious network issues resulting in a large number of connections becoming severed).

HTTPS

To establish a connection over HTTPS, simply use the TLS URI format. The rest is the same as with plain HTTP.

URI format

The URI format that must be used when connecting to the plain websocket and HTTP endpoints is the following:

The w flag is added when CORS headers are required in order to connect from a browser.
The s flag enables the websocket API.
The name placeholder in the domain version specifies the DC ID to connect to:

  • pluto => DC 1
  • venus => DC 2
  • aurora => DC 3
  • vesta => DC 4
  • flora => DC 5

-1 can be appended to the DC name to raise the maximum limit of simultaneous requests per hostname.
The _test flag, when connecting to the domain version of the URL, specifies that connection to the test DCs must be made, instead.

TLS URI format

When connecting to the HTTPS and WSS endpoints, only the domain name URI can be used over port 443:

See the URI format for an explanation of the placeholders.

Example implementations: tdlib, MadelineProto (client side), MTProxy (server side).

Самый надежный MTProto прокси для телеграм

Команда Telegram не остановилась перед угрожающим лицом роскомнадзора, постоянно обрубающего любые возможности «коннекта» со своей целевой аудиторией. После использования бесплатных прокси и VPN для телеграм, разработчики выкатили 1.3 релиз в котором помимо тучи других полезных функций, появилась поддержка подключения разных прокси серверов, более того появилась поддержка MTProto Proxy серверов телеграм. Сначала в этой статье мы разберем общие понятия касательно подключения для клиентов, далее углубимся в более технические аспекты.

Как подключится к MTProto proxy (Bot) в телеграмм

Команда Telegrator.ru специально для своих пользователей подняла собственный сервер с установленным MTProto протоколом. D Для подключения подойдут любые операционные системы: windows, iOS, android. Вы можете подключиться к нему абсолютно бесплатно и без какой либо рекламы кликнув на кнопку ниже:

Или

Зайдите в настройки
Настройки (Settings) > Расширенные (Advanced) > Тип соединения (Connection type) > Ставим галочку на «Использовать прокси» (Use proxy) > Ставим галочку на «MTPROTO»

Вводим данные для подключения:

Хост (Host) — 95.216.151.58
Порт (Port) — 443
Secret (Секрет) — b7e70329dcf3721c4239b86ad32a90b8

Profit!

❗️ Если по кнопке не переходит, то введите название бота вручную — @tg_mtproxy_bot.

Спонсор бота — @CRYPTOSLIVA
(Самый полезный канал о криптовалютах)

Важное замечание. Для того что бы воспользоваться новым способом обхода блокировки от роскомнадзора, вам необходимо обновить свой телеграм до версии не позднее 1.3

Вы можете обновить телеграмм прямо сейчас:

  • Если у вас: Windows
  • Если у вас: iOS
  • Если у вас: Android

Что такое MTProto Proxy сервер

MTProto Proxy — самый передовой протокол от самих разработчиков специально предназначенного для обхода блокировок соответствующих органов. Этот способ гораздо эффективнее SOCKS5, он безопаснее, стабильнее, надежнее. Стоит заметить что по данному протоколу не получиться подключиться иным приложениям. Он заточен только под телеграм.

Официальный MTProto прокси (репозитории):

Преимущества MTProto

  1. Возможна генерация до 16 ключей
  2. До 60000 подключений
  3. Встроенная система мониторинга
  4. Образ в Docker
  5. Система рекламы (promoted) каналов

Настройка MTProto (запуск на сервере)

Этот пункт подходит для владельцев каналов, и всех желающих запустить свой прокси MTproxy сервер. Для этого нам потребуется в идеале: сервер с чистым протоколом 443, установленный на него docker, прямые руки. Будем рассматривать установку на debian/ubuntu, все дальнейшие команды будут введены при подключении через ssh.

mtproxy

  1. Устанавливаем Docker.
    Если не знаете что это, рекомендуем ознакомиться для более глубокого понимания всего происходящего. Процесс установки всех репозиториев описан тут — https://docs.docker.com/install/. Выбираем нужную ось. Мы ставили stretch.
  2. Запускаем контейнер
    Авто-реген ключа Secret:
    docker run -d -p443:443 —name=mtproto-proxy —restart=always -v proxy-config:/data telegrammessenger/proxy:latest
    Назначение своего ключа Secret:
    docker run -d -p443:443 -v proxy-config:/data -e SECRET=«16-ричный ключ» telegrammessenger/proxy:latest
  3. Получаем всю информацию о созданном контейнере. Там будет содержаться ссылка для подключения, secret (ключ) и остальные данные. Вводим:

Реклама канала в MTProto

Как мы написали выше, в этой системе есть функция монетизации. Вам наверняка придется за сервер платить, разработчики telegram придумали как отдать вам дань от ваших подписчиков/пользователей за пользование вашим прокси сервером. При подключении к вашему прокси, они будут видеть вами установленный спонсированный закрепленный канал в топе всех каналов. Выглядеть это будет следующим образом:

Что бы таким образом закрепить свой канал у ваших пользователей прокси, необходимо:

    Зарегистрировать созданный вами прокси у бота @MTProxybot
    new proxy > отправляете ip:port > отправляете боту сгенерированный или вами назначенный secret > Получаете TAG. Высылаете его вашему контейнеру командой (возможно придется переустановить контейнер, команды для этого ниже):

Дополнительные команды Docker’a

$ docker pull telegrammessenger/proxy # обновить образ
$ docker stop mtproto-proxy # остановить контейнер
$ docker rm mtproto-proxy # удалить контейнер
$ docker run …. # создать из обновленного образа и запустить контейнер заново
$ docker logs -f —tail= 30 mtproto-proxy # посмотреть журнал контейнера

Как отключить прокси в телеграм на windows/androin/ios

В отключении теперь вообще пропали какие лиюо преграды существовашие ранее до версии 1.3. Для отключения вам необходимо кликнуть на «щит» в левом нижнем углу телеграма после чего снять галочку напротив Use Proxy (Использовать прокси). Если у вас смартфон, то в самом приложении вы также найдете «щит» в верхнем топ-баре.

mtproxy отключение

Вуаля. Теперь мы с вам научились не только подключаться к готовым прокси серверам MTProxy в телеграм. Но и создавать свой собственный сервер, к которому могут подключаться другие пользователи.

Мобильный протокол MTProto

Разработчикам клиентов нужно соблюдать наши требования безопасности.

Связанные статьи

Общее описание

Протокол предназначен для доступа к серверному API с приложений, запущенных на мобильных устройствах. Подчеркнем, что интернет-браузер не считается таким приложением.

Протокол разбит на три почти независимых части:

  • Высокоуровневая часть (язык запросов к API) — определяет, каким образом запросы к API и ответы на эти запросы преобразуются в двоичные сообщения.
  • Криптографическая (авторизационная) прослойка — определяет, каким образом сообщения шифруются перед передачей через транспортный протокол.
  • Транспортная часть — определяет, каким образом передаются сообщения между клиентом и сервером поверх какого-либо другого существующего сетевого протокола (например, http, https, tcp, udp).

Примечание 1: Каждое текстовое сообщение, которое нужно зашифровать через MTProto, всегда содержит следующие данные, которые проверяются расшифровкой, чтобы сделать систему устойчивой против известных проблем с компонентами:

  • server salt (соль сервера) (64-битная)
  • session id (идентификатор сессии)
  • message sequence number (порядковый номер сообщения)
  • message length (длина сообщения)
  • time (время)

Краткий обзор компонентов

Высокоуровневая часть (язык RPC-запросов/API)

С точки зрения высокоуровневой части, клиент и сервер обмениваются сообщениями в рамках некоторой сессии. Сессия привязана к клиентскому устройству (вернее, приложению), но не к конкретному http/https/tcp-соединению. Кроме того, каждая сессия привязана к идентификатору пользовательского ключа, по которому фактически производится авторизация.

Может быть открыто несколько соединений к серверу; сообщения в ту или иную сторону могут идти по любому из них (ответ на запрос не обязан прийти по тому же соединению, по которому был отправлен сам запрос, хотя чаще всего это так; однако ни в коем случае сообщение не может быть возвращено в соединении, принадлежащем другой сессии). При использовании UDP-протокола может случиться, что ответ на запрос приходит не с того IP, на который был отправлен запрос.

Сообщения бывают нескольких типов:

  • RPC-вызовы (от клиента к серверу) — обращения к методам API
  • RPC-результаты (от сервера к клиенту) — результаты RPC-вызовов
  • Подтверждение приема сообщений (вернее, уведомление о состоянии набора сообщений)
  • Запрос состояния сообщений
  • Составное сообщение или контейнер (контейнер, содержащий несколько сообщений; нужен, например, чтобы по HTTP-соединению можно было отправить несколько RPC-вызовов сразу; кроме того, контейнер может поддерживать gzip).

С точки зрения протоколов более низкого уровня, сообщение — это поток двоичных данных, выровненный по границе 4 или 16 байтов. Первые несколько полей сообщения фиксированы и используются системой криптографии/авторизации.

Каждое сообщение, отдельное или внутри контейнера, состоит из идентификатора сообщения (64 бита; см. ниже), порядкового номера сообщения в сессии (32 бита), длины (тела в байтах; 32 бита) и тела (любой размер, кратный 4 байтам). Кроме того, при отправке контейнера или одиночного сообщения, в его начало дописывается внутренний заголовок (см. ниже), после чего все это шифруется, и в начало зашифрованного сообщения добавляется внешний заголовок (64-битный идентификатор ключа и 128-битный ключ сообщения).

Тело сообщения обычно состоит из 32-битного типа сообщения, за которым следуют параметры, зависящие от типа. В частности, каждой RPC-функции соответствует свой тип сообщения. Более подробно читайте в статье про двоичную сериализацию данных и служебные сообщения.

Все числа записываются как little-endian. Однако очень большие числа (2048-битные), используемые в RSA и DH, записываются как big-endian, потому что так делает библиотека OpenSSL.

Авторизация и криптография

Перед передачей сообщений (или составных сообщений) по сети посредством транспортного протокола они шифруются определенным образом; при этом перед сообщением приписывается внешний заголовок: 64-битный идентификатор ключа (однозначно определяющий авторизационный ключ для сервера, а также пользователя) и 128-битный ключ сообщения. Пользовательский ключ вместе с ключом сообщения определяют реальный 256-битный ключ, которым и зашифровано сообщение посредством шифра AES-256. Начало тела незашифрованного сообщения содержит некоторые данные (сессию, идентификатор сообщения, порядковый номер сообщения в сессии, серверную соль); ключ сообщения должен совпадать с младшими 128 битами SHA1 от тела сообщения (включая сессию, идентификатор сообщения и т.п.). Составные сообщения шифруются как единое целое.

Первым делом клиентское приложение должно произвести создание авторизационного ключа, который обычно создается при первом запуске и практически никогда не изменяется.

Примечание от переводчика: по некоторым сведениям, в последних обновлениях этот ключ меняется через каждые 100 отправленных сообщений — https://twitter.com/durov/status/539489480676085760

Основной недостаток протокола — в том, что злоумышленник, пассивно перехватывающий сообщения, а затем каким-либо образом заполучивший авторизационный ключ (например, украв устройство) получит возможность расшифровать все перехваченные сообщения post factum. Вероятно, это не слишком серьезно (украв устройство, можно получить и всю закешированную на нем информацию, ничего не расшифровывая), однако для преодоления этих проблем можно сделать следующее:

  • Сессионные ключи, генерируемые по протоколу Диффи-Хелмана, и используемые совместно с авторизационным ключом и ключом сообщения для выбора параметров AES. Для их создания клиент должен первым действием после создания новой сессии отправить серверу специальный RPC-запрос («сгенерировать сессионный ключ»), сервер ответит на него, после чего все последующие сообщения сессии шифруются с учетом и сессионного ключа.
  • Защищать ключ, хранимый на клиентском устройством, (текстовым) паролем; этот пароль никогда не хранится в памяти и вводится пользователем при запуске приложения или чаще (в зависимости от настроек приложения).
  • Данные, хранимые (кэшируемые) на пользовательском устройстве, можно также защищать, шифруя с помощью авторизационного ключа, который, в свою очередь, надо защитить паролем. Тогда без ввода пароля невозможно будет получить доступ даже к этим данным.

Синхронизация времени

Если время на клиенте сильно отличается от времени на сервере, может так получиться, что сервер начнет игнорировать сообщения клиента, или наоборот, из-за некорректного значения идентификатора сообщения (которое тесно связано с временем создания). В таких ситуациях сервер шлет клиенту специальное сообщение с правильным временем, содержащие, помимо него, некую 128-битную соль (либо явно присланную клиентом в специальном RPC-запросе синхронизации, либо равную ключу последнего сообщения, полученного от клиента в рамках данной сессии). Такое сообщение может быть первым в контейнере, содержащим и другие сообщения (если рассинхронизация существенна, но еще не приводит к игнорированию клиентских сообщений).

При получении такого сообщения (или содержащего его контейнера) клиент сначала выполняет синхронизацию времени (фактически всего лишь запоминает разницу своего и серверного времени, чтобы уметь впредь вычислять «правильное» время), а затем проверяет идентификаторы сообщений на корректность.

В запущенных случаях клиенту придется сгенерировать новую сессию, чтобы обеспечить монотонность идентификаторов сообщений.

Транспорт

Позволяет доставлять уже зашифрованные контейнеры вместе с внешним заголовком (в дальнейшем — полезную нагрузку) от клиента к серверу и наоборот. Есть три типа транспорта:

  • HTTP
  • TCP
  • UDP

Рассмотрим первые два типа.

Передача по HTTP

Реализуется поверх HTTP/1.1 (с keepalive), запущенного поверх классического TCP-порта 80. HTTPS не используется; используется криптографическая схема, объясненная выше.

HTTP-соединение привязывается к сессии (вернее, сессии + идентификатору ключа), указанной в последнем пришедшем пользовательском запросе; обычно во всех запросах сессия одинакова, однако хитрые HTTP-прокси могут это испортить. Сервер может вернуть сообщение в HTTP-соединение только в том случае, если оно принадлежит той же сессии, и если сейчас очередь сервера (был получен HTTP-запрос от клиента, на который еще не было отправлено ответа).

Общая схема такова. Клиент открывает одно или несколько keepalive HTTP-соединений к серверу. При необходимости отправки одного или нескольких сообщений из них составляется полезная нагрузка, после чего делается POST-запрос на URL /api , в качестве данных которому и передается полезная нагрузка. Кроме того, допускаются HTTP-заголовки Content-Length , Keepalive , Host .

После получения запроса сервер может либо подождать немного (если запрос подразумевает ответ после небольшого ожидания), либо сразу вернуть фиктивный ответ (сообщающий всего лишь о том, что контейнер был получен). В любом случае в ответе может оказаться сколько угодно сообщений — сервер вправе заодно отправить любые накопившиеся у него сообщения для этой сессии.

Кроме того, есть специальный longpoll RPC-запрос (действительный только для http-соединений), в котором передается максимальное время ожидания T. Если у сервера есть сообщения для этой сессии, они возвращаются сразу же; в противном случае происходит ожидание до тех пор, пока у сервера не появится сообщение для клиента, либо не пройдет T секунд. Если за T секунд не произошло никаких событий, возвращается фиктивный ответ (специальное сообщение).

Если серверу надо отправить сообщение клиенту, он проверяет, нет ли HTTP-соединения, принадлежащего нужной сессии, и находящегося в состоянии «выполнения HTTP-запроса» (включая long poll), после чего сообщение добавляется в контейнер ответа этого соединения и отправляется пользователю. В типичном случае происходит небольшое дополнительное ожидание (50 миллисекунд), на тот случай, если у сервера вскоре появятся еще сообщения для этой сессии.

Если ни одного подходящего HTTP-соединения нет, сообщения ставятся в очередь отправки для данной сессии. Впрочем, они туда попадают в любом случае, пока явно или косвенно не подтверждено получение клиентом. Для http-протокола неявным подтверждением считается отправка следующего запроса по тому же HTTP-соединению (уже нет — и для HTTP-протокола необходимо слать явные подтверждения); в остальных случаях клиент должен прислать явное подтверждение за разумное время (его можно добавить в контейнер для следующего запроса).

Важно: если подтверждение вовремя не пришло, сообщение может быть перепослано (возможно, в составе другого контейнера). Стороны должны быть морально готовы к этому и хранить идентификаторы последних полученных сообщений (и игнорировать такие дубли, а не повторять действие). Для того, чтобы не хранить идентификаторы вечно, есть специальные сообщения сборки мусора, эксплуатирующие монотонность идентификаторов сообщений.

Если очередь отправки переполняется, или сообщения ждут в ней больше 10 минут, то сервер их забывает (или отправляет в своп — дурное дело нехитрое). Это может случиться и быстрее, если у сервера заканчиваются буферы (например, из-за серьезных проблем в сети, приведших к разрыву большого количества соединений).

TCP-транспорт

Очень похож на HTTP-транспорт, может быть реализован тоже на порт 80 (чтобы проходить все фаерволы) и даже на те же ip-адреса серверов. В этом случае сервер понимает, нужно ли использовать HTTP или TCP-протокол для данного соединения по первым четырем пришедшим байтам (для HTTP это будет POST).

При создании TCP-соединения оно приписывается сессии (и авторизационному ключу), переданному в первом сообщении пользователя, и потом используется исключительно для данной сессии (схемы мультиплексирования не допускаются).

При необходимости отправки полезной нагрузки (пакета) от сервера к клиенту или от клиента к серверу она инкапсулируется следующим образом: спереди дописывается 4 байта длины (включая длину, порядковый номер и CRC32; всегда делится на четыре) и 4 байта с порядковым номером пакета внутри данного tcp-соединения (первый отправленный пакет помечается 0, следующий — 1 и т.д.), а в конце — 4 байта CRC32 (длины, порядкового номера и полезной нагрузки вместе).

Существует сокращённая версия этого протокола: если клиент отправляет первым байтом (важно: только перед самым первым пакетом данных) 0xEF , то после этого длина пакета кодируется одним байтом ( 0×01..0×7E = длина данных, делённая на 4; либо 0×7F , а затем 3 байта длины (little-endian), делённой на 4), а далее идут сами данные (порядковый номер или CRC32 не добавляются). Ответы сервера в этом случае имеют тот же вид (при этом сервер не отсылает первый байт 0xEF ).

В случае, если требуется выравнивание 4-байтовых данных, может быть использована промежуточная версия оригинального протокола: если клиент отправляет 0xEEEEEEEE как первый инт (int) (четыре байта), то длина пакета зашифрована всегда четырьмя байтами как в оригинальной версии, но порядковый номер и CRC32 опускаются, таким образом уменьшая итоговый /общий размер пакета на 8 байт.

В полной и в сокращённой версии протокола есть поддержка быстрых подтверждений. В этом случае клиент устанавливает старший бит длины в пакете с запросом, а сервер отсылает в ответ специальные 4 байта, представляющие собой самостоятельный пакет. Они представляют собой старшие 32 бита SHA1 от зашифрованной части пакета, с установленным старшим битом, чтобы было понятно, что это не длина обычного пакета с ответом сервера; если используется сокращённая версия, то к этим четырём байтам применяется bswap.

Неявных подтверждений для TCP-транспорта не бывает: все сообщения должны быть явно подтверждены. Чаще всего подтверждения помещаются в контейнер вместе со следующим запросом или ответом, если он отправляется вскоре. Например, это почти всегда так для сообщений от клиента, содержащих RPC-запросы: подтверждение обычно приходит вместе с RPC-ответом.

В случае возникновения ошибки сервер может прислать пакет, полезная нагрузка которого состоит из 4 байтов — кода ошибки. Например, код ошибки −403 соответствует ситуациям, в которых через HTTP-протокол вернулась бы соответствующая HTTP-ошибка.

Сайт про Telegram на русском (неофициальный).

Здесь собраны приложения на базе MTProto, переведена некоторая документация с официального сайта, а также работает Webogram.

MTProto Telegram: настройка, руководство по запуску и использованию

Lorem ipsum dolor

MTProto Proxy Telegram — это официальный прокси от разработчиков Телегра м а. Он предназначен для обхода блокировки всем известных органов. Это намного эффективнее Socks5, так как тут больше безопасности, стабильности и надежности. Хочется сразу проговорить, что данная технология предназначена только для Телегра м и воспользоваться ею в других приложениях не представляется возможным.

Данные прокси — это результат известной борьбы между мессенджером и РосКомНадзором. Как известно уже каждому, РКН не раз блокировал возможности Телегра м а «кон н ектиться» со своими пользователями. Как инструмент обхода этих блокировок до сих пор шли бесплатные proxy и VPN для Телегра м а. Но разработчики «телеги» пошли дальше и создали собственный продукт — MTProto proxy.

Настройка MTProto Telegram

  1. github.com/TelegramMessenger/MTProxy
  2. hub.docker.com/r/telegrammessenger/proxy
  1. Откройте Телегра м ;
  2. Откройте «Настройки»;
  3. Потом «Продвинуты е настройки»;
  4. Тип соединения ;
  5. Выбираем «Использовать прокси» .
  1. При подключении используется только пароль вместо login/password;
  2. Безопасность трафика схожа с https;
  3. Пароли не передаются на сервер, а значит , их невозможно «украсть»;
  4. Зашифрованная передача трафика;
  5. Данные прокси предназначены для использования только Телегра м ом;
  6. Обмен данными с proxy server не распознается и не дешифруется сторонними фильтрами и анализаторами, поэтому передачу трафика невозможно ограничить;
  7. Программное обеспечение прокси-серверов обновляется регулярно.
  • @proxy_socks5_bot;
  • @socks5_bot.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *