Прямое подключение к DC¶

По умолчанию Teleproxy маршрутизирует трафик через промежуточные relay-серверы Telegram (middle-end, ME). Прямой режим обходит их:

По умолчанию:  Клиент -> Teleproxy -> ME relay -> Telegram DC
Прямой режим:  Клиент -> Teleproxy -> Telegram DC

Включение через --direct:

./teleproxy -u nobody -p 8888 -H 443 -S <секрет> --http-stats --direct

В прямом режиме:

Файлы proxy-multi.conf и proxy-secret не нужны
Аргумент конфигурационного файла не требуется
Подключение идёт напрямую к известным адресам дата-центров Telegram
Несовместим с -P (тег прокси) — учёт тегов спонсорских каналов происходит на middle-end Telegram, поэтому слоты для спонсорских каналов требуют ME relay

Ограничения¶

Прямой режим обходит middle-end Telegram (MiddleProxy) по проекту. Этот компромисс стоит трёх вещей на стороне клиента:

Медиа на не-Premium аккаунтах может не загружаться. Фото, видео и сторис для бесплатных аккаунтов привязаны Telegram к авторизации сессии, которая проходит через MiddleProxy; сессии, установленные через прямой режим, считаются не-авторизованными для этого медиа, и клиент видит бесконечную "загрузку" вместо явной ошибки. Premium-аккаунты не затронуты. Это симптом, который пользователи описывают в #60.
Спонсорские (промо) каналы не доставляются. Та же причина — теги спонсорских каналов выдаются на ME.
Голосовые и видео-звонки Telegram не передаются ни одним MTProto-прокси — ни прямым, ни relay. Клиент Telegram принимает прокси для сигнального трафика звонков только в виде встроенного SOCKS5; MTProto-прокси видит только трафик чатов. Это не специфично для прямого режима, но это полезно знать при выборе схемы развёртывания.

Если медиа важнее выигрыша по задержкам, уберите --direct и запускайтесь с proxy-multi.conf + proxy-secret (путь по умолчанию через ME relay).

Docker:

docker run -d \
  --name teleproxy \
  -p 443:443 \
  -e DIRECT_MODE=true \
  --restart unless-stopped \
  ghcr.io/teleproxy/teleproxy:latest