astelm/telemt
1
0
Fork 0
mirror of https://github.com/telemt/telemt.git synced 2026-10-06 09:25:59 +03:00
Code Issues Packages Projects Releases Wiki Activity

Docs 3.5.8 Pull-Up

Browse Source 
Co-Authored-By: brekotis <93345790+brekotis@users.noreply.github.com>
This commit is contained in:
Alexey
2026-09-27 18:55:04 +03:00
parent 717a34771f
commit 56e0f000ba
18 changed files with 1137 additions and 458 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/FAQ.ru.md
+72 -34
View File
@@ -42,8 +42,7 @@ hello2 = "ad_tag2"
- Для расследования блокировок на базе JA4 ClientHello используйте отдельную инструкцию: [`JA3 и JA4 анализ в Telemt`](Architecture/Fronting-splitting/TLS_JA3_JA4_ANALYSIS.ru.md).
- Мы считаем это прорывом, которому на сегодняшний день нет стабильных аналогов;
- Исходя из этого: если `telemt` настроен правильно, **режим TLS полностью идентичен реальному «рукопожатию» + обмену данными** с указанным хостом;
- При корректной настройке TLS fronting неаутентифицированный трафик проходит через реальный upstream TLS handshake и получает его ответы. Устойчивость fingerprint по-прежнему зависит от версии клиента, выбранного host, сетевого пути и внешней проверки;
- Вот наши доказательства:
- 212.220.88.77 — «фиктивный» хост, на котором запущен `telemt`;
- `petrovich.ru` — хост с `tls` + `masking`, в HEX: `706574726f766963682e7275`;
@@ -61,7 +60,10 @@ hello2 = "ad_tag2"
- с полным циклом запрос-ответ;
- с низкой задержкой.
```bash
> [!NOTE]
> Ниже приведён исторический capture от 1 января 2026 года, а не проверка текущей доступности. Показанный сертификат истёк 1 марта 2026 года; актуальные endpoint и сертификат необходимо проверять отдельно.
```text
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
@@ -130,6 +132,8 @@ Keep-Alive: timeout=60
- Мы поставили перед собой задачу, не сдавались и не просто «бились в пустоту»: теперь у нас есть что вам показать.
- Не верите нам на слово? — Это прекрасно, и мы уважаем ваше решение: вы можете собрать свой собственный `telemt` или скачать готовую сборку и проверить её прямо сейчас.
## ЧаВо
### Звонки в Telegram через MTProxy
- Архитектура Telegram **НЕ поддерживает звонки через MTProxy**, а только через SOCKS5, который невозможно замаскировать
@@ -154,7 +158,7 @@ Keep-Alive: timeout=60
- в Иране во время «активности».
## Зачем нужен middle proxy (ME)
### Зачем нужен middle proxy (ME)
https://github.com/telemt/telemt/discussions/167
## Как клиенты взаимодействуют с дата-центрами Telegram
@@ -175,25 +179,23 @@ Telegram заранее определяет к какому DC привязат
По той же причине MTProxy необходимо иметь доступ к инфраструктуре Telegram целиком, а не частично.
Cамому MTProxy всё равно, на каком DC живёт ваш аккаунт. Клиент cам договаривается о нужном DC через прокси уже после подключения.
## Что такое dd и ee в контексте MTProxy?
### Что такое `dd` и `ee` в контексте MTProxy?
Это два разных режима работы прокси. Понять, какой режим используется, можно взглянув на начало секрета — там будет dd или ee, вот пример:
tg://proxy?server=s1.dimasssss.space&port=443&secret=eebe3007e927acd147dde12bee8b1a7c9364726976652e676f6f676c652e636f6d
dd — режим с мусорным трафиком, обфускацией данных, похожий на shadowsocks. У такого трафика есть заметный паттерн, который DPI умеют распознавать и впоследствии блокировать. Использовать этот режим на текущий момент не рекомендуется.
ee — режим маскировки под существующий домен (FakeTLS), словно вы сёрфите в интернете через браузер. На текущий момент не попадает под блокировку.
Это разные режимы прокси, обозначаемые в начале закодированного секрета. `dd` включает защищённый обфусцированный транспорт. `ee` включает Fake TLS и добавляет к секрету настроенный SNI-домен. Выбирайте режим по поддержке клиентом, условиям цензуры и настроенному пути fronting/masking. Используйте `ee`, только когда требуется TLS-shaped traffic, и проверяйте его через реальный публичный endpoint; WEB-режим поддерживает `plain` и `dd`, но не `ee`.
### Где эти режимы настраиваются?
```toml
В конфиге telemt.toml в разделе [general.modes]:
classic = false # классический режим, давно стал бесполезным
secure = false # переменная dd-режима
tls = true # переменная ee-режима
[general.modes]
# Classic MTProxy mode.
classic = false
# dd mode.
secure = false
# ee Fake TLS mode.
tls = true
```
## Сколько человек может пользоваться одной ссылкой
### Сколько человек может пользоваться одной ссылкой
По умолчанию одной ссылкой может пользоваться неограниченное число людей.
Однако вы можете ограничить количество уникальных IP-адресов для каждого пользователя:
@@ -203,7 +205,7 @@ hello = 1
```
Этот параметр задает максимальное количество уникальных IP-адресов, с которых можно одновременно использовать одну ссылку. Если первый пользователь отключится, второй сможет подключиться. При этом с одного IP-адреса могут подключаться несколько пользователей одновременно (например, устройства в одной Wi-Fi сети).
## Как создать несколько разных ссылок
### Как создать несколько разных ссылок
1. Сгенерируйте необходимое количество секретов с помощью команды: `openssl rand -hex 16`.
2. Откройте файл конфигурации: `nano /etc/telemt/telemt.toml`.
@@ -220,7 +222,7 @@ user3 = "00000000000000000000000000000003"
curl -s http://127.0.0.1:9091/v1/users | jq
```
## Ошибка "Unknown TLS SNI"
### Ошибка "Unknown TLS SNI"
Обычно эта ошибка возникает, если вы изменили параметр `tls_domain`, но пользователи продолжают подключаться по старым ссылкам с прежним доменом.
Если необходимо разрешить подключение с любыми доменами (игнорируя несовпадения SNI), добавьте следующие параметры:
@@ -236,34 +238,61 @@ unknown_sni_action = "reject_handshake"
```
Это не пропускает старых клиентов, но делает поведение на 443-м порту неотличимым от стокового веб-сервера, у которого просто нет такого виртуального хоста.
## Как посмотреть метрики
### Как посмотреть метрики
1. Откройте файл конфигурации: `nano /etc/telemt/telemt.toml`.
2. Добавьте следующие параметры:
```toml
[server]
metrics_port = 9090
metrics_whitelist = ["127.0.0.1/32", "::1/128", "0.0.0.0/0"]
metrics_listen = "127.0.0.1:9090"
metrics_whitelist = ["127.0.0.1/32", "::1/128"]
```
3. Сохраните изменения (Ctrl+S -> Ctrl+X).
4. После этого метрики будут доступны по адресу: `SERVER_IP:9090/metrics`.
4. Метрики будут доступны локально по адресу `http://127.0.0.1:9090/metrics`.
> [!WARNING]
> Значение `"0.0.0.0/0"` в `metrics_whitelist` открывает доступ к метрикам с любого IP-адреса. Рекомендуется заменить его на ваш личный IP, например: `"1.2.3.4/32"`.
> Оставляйте metrics на loopback, если удалённый сборщик не требуется. Для удалённого сбора привяжите явный приватный адрес, разрешите только CIDR сборщика и закрепите ту же границу в host firewall. Не используйте whitelist `/0`.
Счётчики нагрузки и проверки операционной системы описаны в [руководстве по High-Load](Advanced_settings/HIGH_LOAD.ru.md#5-диагностика-и-мониторинг).
### Слишком много открытых файлов
- На свежей Linux-системе лимит открытых файлов обычно мал; под нагрузкой Telemt может завершать accept с ошибкой `Too many open files`.
- Для systemd добавьте `LimitNOFILE=65536` в секцию `[Service]`.
- Для Docker добавьте `--ulimit nofile=65536:65536` в `docker run` либо настройте Compose:
```yaml
ulimits:
nofile:
soft: 65536
hard: 65536
```
- При необходимости задайте системные пределы в `/etc/security/limits.conf`:
```conf
* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576
```
## Дополнительные параметры
### Домен в ссылке вместо IP
Чтобы в ссылках для подключения отображался домен вместо IP-адреса, добавьте следующие строки в файл конфигурации:
Чтобы в native-ссылках `tg://proxy` отображался домен вместо IP-адреса, добавьте следующие строки в файл конфигурации:
```toml
[general.links]
public_host = "proxy.example.com"
```
Эта настройка вместе с `public_port` влияет только на native-ссылки. WEB-ссылки `tg://webproxy` всегда используют `[[web.vhosts]].host` и внешний порт `443`.
### Общий лимит подключений к серверу
Этот параметр ограничивает общее количество активных подключений к серверу:
```toml
[server]
max_connections = 10000 # 0 - без ограничений, 10000 - по умолчанию
# Zero disables the limit; 10000 is the default.
max_connections = 10000
```
### Upstream Manager
@@ -275,27 +304,36 @@ max_connections = 10000 # 0 - без ограничений, 10000 - по у
type = "direct"
weight = 1
enabled = true
interface = "192.168.1.100" # Замените на ваш исходящий IP
# Replace this value with your outbound IP.
interface = "192.168.1.100"
```
#### Использование SOCKS4/5 в качестве Upstream
- Без авторизации:
```toml
[[upstreams]]
type = "socks5" # выбор типа SOCKS4 или SOCKS5
address = "1.2.3.4:1234" # адрес сервера SOCKS
weight = 1 # вес
# Specify SOCKS4 or SOCKS5.
type = "socks5"
# SOCKS server address.
address = "1.2.3.4:1234"
# Selection weight.
weight = 1
enabled = true
```
- С авторизацией:
```toml
[[upstreams]]
type = "socks5" # выбор типа SOCKS4 или SOCKS5
address = "1.2.3.4:1234" # адрес сервера SOCKS
username = "user" # имя пользователя
password = "pass" # пароль
weight = 1 # вес
# Specify SOCKS4 or SOCKS5.
type = "socks5"
# SOCKS server address.
address = "1.2.3.4:1234"
# SOCKS username.
username = "user"
# SOCKS password.
password = "pass"
# Selection weight.
weight = 1
enabled = true
```