telemt/docs/FAQ.ru.md

16 KiB
Raw Blame History

Как настроить канал "спонсор прокси" и статистику через бота @MTProxybot

  1. Зайдите в бота @MTProxybot.
  2. Введите команду /newproxy.
  3. Отправьте IP-адрес и порт сервера. Например: 1.2.3.4:443.
  4. Откройте файл конфигурации: nano /etc/telemt/telemt.toml.
  5. Скопируйте и отправьте боту секрет пользователя из раздела [access.users].
  6. Скопируйте тег (tag), который выдаст бот. Например: 1234567890abcdef1234567890abcdef.

[!WARNING] Ссылка, которую выдает бот, работать не будет. Не копируйте и не используйте её!

  1. Раскомментируйте параметр ad_tag и впишите тег, полученный от бота.
  2. Раскомментируйте или добавьте параметр use_middle_proxy = true.

Пример конфигурации:

[general]
ad_tag = "1234567890abcdef1234567890abcdef"
use_middle_proxy = true
  1. Сохраните изменения (в nano: Ctrl+S -> Ctrl+X).
  2. Перезапустите службу telemt: systemctl restart telemt.
  3. В боте отправьте команду /myproxies и выберите добавленный сервер.
  4. Нажмите кнопку «Set promotion».
  5. Отправьте публичную ссылку на канал. Приватные каналы добавлять нельзя!
  6. Подождите примерно 1 час, пока информация обновится на серверах Telegram.

[!WARNING] Спонсорский канал не будет у вас отображаться, если вы уже на него подписаны.

Вы также можете настроить разные спонсорские каналы для разных пользователей:

[access.user_ad_tags]
hello = "ad_tag"
hello2 = "ad_tag2"

Распознаваемость для DPI и сканеров

1 апреля 2026 года нам стало известно о методе обнаружения MTProxy Fake-TLS, основанном на расширении ECH и порядке набора шифров, а также об общем уникальном отпечатке JA3/JA4, который не встречается в современных браузерах: мы уже отправили первоначальные изменения разработчикам Telegram Desktop и работаем над обновлениями для других клиентов.

  • Мы считаем это прорывом, которому на сегодняшний день нет стабильных аналогов;

  • Исходя из этого: если telemt настроен правильно, режим TLS полностью идентичен реальному «рукопожатию» + обмену данными с указанным хостом;

  • Вот наши доказательства:

    • 212.220.88.77 — «фиктивный» хост, на котором запущен telemt;
    • petrovich.ru — хост с tls + masking, в HEX: 706574726f766963682e7275;
    • Без MITM + без поддельных сертификатов/шифрования = чистое прозрачное TCP Splice к «лучшему» исходному серверу: MTProxy или tls/mask-host:
      • DPI видит легитимный HTTPS к tls_host, включая достоверную цепочку доверия и энтропию;
      • Краулеры полностью удовлетворены получением ответов от mask_host.

    Клиент С секретным ключом получает доступ к ресурсу MTProxy:

    telemt

    Клиент БЕЗ секретного ключа получает прозрачный доступ к указанному ресурсу:

    • с доверенным сертификатом;
    • с исходным «рукопожатием»;
    • с полным циклом запрос-ответ;
    • с низкой задержкой.
root@debian:~/telemt# curl -v -I --resolve petrovich.ru:443:212.220.88.77 https://petrovich.ru/
* Added petrovich.ru:443:212.220.88.77 to DNS cache
* Hostname petrovich.ru was found in DNS cache
*   Trying 212.220.88.77:443...
* Connected to petrovich.ru (212.220.88.77) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=RU; ST=Saint Petersburg; L=Saint Petersburg; O=STD Petrovich; CN=*.petrovich.ru
*  start date: Jan 28 11:21:01 2025 GMT
*  expire date: Mar  1 11:21:00 2026 GMT
*  subjectAltName: host "petrovich.ru" matched cert's "petrovich.ru"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
*  SSL certificate verify ok.
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: petrovich.ru
> User-Agent: curl/7.88.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: Variti/0.9.3a
Server: Variti/0.9.3a
< Date: Thu, 01 Jan 2026 00:0000 GMT
Date: Thu, 01 Jan 2026 00:0000 GMT
< Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: *
< Content-Type: text/html
Content-Type: text/html
< Cache-Control: no-store
Cache-Control: no-store
< Expires: Thu, 01 Jan 2026 00:0000 GMT
Expires: Thu, 01 Jan 2026 00:0000 GMT
< Pragma: no-cache
Pragma: no-cache
< Set-Cookie: ipp_uid=XXXXX/XXXXX/XXXXX==; Expires=Tue, 31 Dec 2040 23:59:59 GMT; Domain=.petrovich.ru; Path=/
Set-Cookie: ipp_uid=XXXXX/XXXXX/XXXXX==; Expires=Tue, 31 Dec 2040 23:59:59 GMT; Domain=.petrovich.ru; Path=/
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 31253
Content-Length: 31253
< Connection: keep-alive
Connection: keep-alive
< Keep-Alive: timeout=60
Keep-Alive: timeout=60

< 
* Connection #0 to host petrovich.ru left intact

  • Мы поставили перед собой задачу, не сдавались и не просто «бились в пустоту»: теперь у нас есть что вам показать.
  • Не верите нам на слово? — Это прекрасно, и мы уважаем ваше решение: вы можете собрать свой собственный telemt или скачать готовую сборку и проверить её прямо сейчас.

Звонки в Telegram через MTProxy

  • Архитектура Telegram НЕ поддерживает звонки через MTProxy, а только через SOCKS5, который невозможно замаскировать

Как DPI распознает TLS-соединение MTProxy?

  • DPI распознает MTProxy в режиме Fake TLS (ee) как TLS 1.3
  • указанный вами SNI отправляется как клиентом, так и сервером;
  • ALPN аналогичен HTTP 1.1/2;
  • высокая энтропия, что нормально для трафика, зашифрованного AES;

Белый список по IP

  • MTProxy не может работать, если:
    • отсутствует IP-связь с целевым хостом: российский белый список в мобильных сетях — «Белый список»;
    • ИЛИ весь TCP-трафик заблокирован;
    • ИЛИ трафик с высокой энтропией/зашифрованный трафик заблокирован: контент-фильтры в университетах и критически важной инфраструктуре;
    • ИЛИ весь TLS-трафик заблокирован;
    • ИЛИ заблокирован указанный порт: используйте 443, чтобы сделать его «как настоящий»;
    • ИЛИ заблокирован предоставленный SNI: используйте «официально одобренное»/безобидное имя;
  • как и большинство протоколов в Интернете;
  • такие ситуации наблюдаются:
    • в Китае за Великим файрволом;
    • в России в мобильных сетях, реже в проводных сетях;
    • в Иране во время «активности».

Зачем нужен middle proxy (ME)

https://github.com/telemt/telemt/discussions/167

Что такое dd и ee в контексте MTProxy?

Это два разных режима работы прокси. Понять, какой режим используется, можно взглянув на начало секрета — там будет dd или ee, вот пример: tg://proxy?server=s1.dimasssss.space&port=443&secret=eebe3007e927acd147dde12bee8b1a7c9364726976652e676f6f676c652e636f6d

dd — режим с мусорным трафиком, обфускацией данных, похожий на shadowsocks. У такого трафика есть заметный паттерн, который DPI умеют распознавать и впоследствии блокировать. Использовать этот режим на текущий момент не рекомендуется.

ee — режим маскировки под существующий домен (FakeTLS), словно вы сёрфите в интернете через браузер. На текущий момент не попадает под блокировку.

Где эти режимы настраиваются?

В конфиге telemt.toml в разделе [general.modes]:
classic = false # классический режим, давно стал бесполезным
secure = false # переменная dd-режима
tls = true # переменная ee-режима

Сколько человек может пользоваться одной ссылкой

По умолчанию одной ссылкой может пользоваться неограниченное число людей.
Однако вы можете ограничить количество уникальных IP-адресов для каждого пользователя:

[access.user_max_unique_ips]
hello = 1

Этот параметр задает максимальное количество уникальных IP-адресов, с которых можно одновременно использовать одну ссылку. Если первый пользователь отключится, второй сможет подключиться. При этом с одного IP-адреса могут подключаться несколько пользователей одновременно (например, устройства в одной Wi-Fi сети).

Как создать несколько разных ссылок

  1. Сгенерируйте необходимое количество секретов с помощью команды: openssl rand -hex 16.
  2. Откройте файл конфигурации: nano /etc/telemt/telemt.toml.
  3. Добавьте новых пользователей в секцию [access.users]:
[access.users]
user1 = "00000000000000000000000000000001"
user2 = "00000000000000000000000000000002"
user3 = "00000000000000000000000000000003"
  1. Сохраните конфигурацию (Ctrl+S -> Ctrl+X). Перезапускать службу telemt не нужно.
  2. Получите готовые ссылки с помощью команды:
curl -s http://127.0.0.1:9091/v1/users | jq

Ошибка "Unknown TLS SNI"

Обычно эта ошибка возникает, если вы изменили параметр tls_domain, но пользователи продолжают подключаться по старым ссылкам с прежним доменом.

Если необходимо разрешить подключение с любыми доменами (игнорируя несовпадения SNI), добавьте следующие параметры:

[censorship]
unknown_sni_action = "mask"

Как посмотреть метрики

  1. Откройте файл конфигурации: nano /etc/telemt/telemt.toml.
  2. Добавьте следующие параметры:
[server]
metrics_port = 9090
metrics_whitelist = ["127.0.0.1/32", "::1/128", "0.0.0.0/0"]
  1. Сохраните изменения (Ctrl+S -> Ctrl+X).
  2. После этого метрики будут доступны по адресу: SERVER_IP:9090/metrics.

[!WARNING] Значение "0.0.0.0/0" в metrics_whitelist открывает доступ к метрикам с любого IP-адреса. Рекомендуется заменить его на ваш личный IP, например: "1.2.3.4/32".

Дополнительные параметры

Домен в ссылке вместо IP

Чтобы в ссылках для подключения отображался домен вместо IP-адреса, добавьте следующие строки в файл конфигурации:

[general.links]
public_host = "proxy.example.com"

Общий лимит подключений к серверу

Этот параметр ограничивает общее количество активных подключений к серверу:

[server]
max_connections = 10000    # 0 - без ограничений, 10000 - по умолчанию

Upstream Manager

Для настройки исходящих подключений (Upstreams) добавьте соответствующие параметры в секцию [[upstreams]] файла конфигурации:

Привязка к исходящему IP-адресу

[[upstreams]]
type = "direct"
weight = 1
enabled = true
interface = "192.168.1.100" # Замените на ваш исходящий IP

Использование SOCKS4/5 в качестве Upstream

  • Без авторизации:
[[upstreams]]
type = "socks5"            # выбор типа SOCKS4 или SOCKS5
address = "1.2.3.4:1234"   # адрес сервера SOCKS
weight = 1                 # вес
enabled = true
  • С авторизацией:
[[upstreams]]
type = "socks5"            # выбор типа SOCKS4 или SOCKS5
address = "1.2.3.4:1234"   # адрес сервера SOCKS
username = "user"          # имя пользователя
password = "pass"          # пароль
weight = 1                 # вес
enabled = true

Использование Shadowsocks в качестве Upstream

Для работы этого метода требуется установить параметр use_middle_proxy = false.

[general]
use_middle_proxy = false

[[upstreams]]
type = "shadowsocks"
url = "ss://2022-blake3-aes-256-gcm:BASE64_KEY@1.2.3.4:8388"
weight = 1
enabled = true