Контейнер MTG создает внутреннюю петлю: пустые соединения (out=0 in=0) с собственного IP

[zilaev]

Я запускаю MTG в Docker-контейнере на том же хосте, где работает Nginx в качестве потокового прокси (stream).
Nginx принимает TLS-трафик на порту 443, анализирует ssl_preread и перенаправляет MTProto-трафик на MTG (порт 8444), а обычный веб-трафик — на другой бэкенд.

В логе Nginx (stream) появляется флуд, огромное количество записей вида:

172.17.0.2 [01/May/2026:20:13:23 +0300] host=ik.xxx.yy prot=TCP status=200 out=0 in=0

IP-адрес 172.17.0.2 принадлежит самому контейнеру mtg-proxy (проверено через docker inspect, других контейнеров нет).
Эти соединения пустые (out=0 in=0) и повторяются с большой частотой, утилизируя CPU.

У контейнера нет healthcheck. Конфигурация работает нормально для реальных клиентов (кстати, если клиент вместо ip указывает DNS имя, то коннект не строится), но внутренняя петля создает шум и лишнюю нагрузку. (Да, при обращении на DNS адрес который NGINX проскирует на MTG утилизация CPU растет до 100%, спустя 30 сек, падает к стандартным значениям)

Команда запуска mtg:

docker run -d --name mtg-proxy --restart unless-stopped \
  -p 127.0.0.1:8444:8444 \
  -v $(pwd)/mtg/config.toml:/config.toml:ro \
  nineseconds/mtg:2.2.8
config.toml:

toml

secret = "ee11223344556677889900aabbccddeeff6......"
domain = "ik.ххх.yyy"
bind-to = "0.0.0.0:8444"
[tls]
enabled = true

Доп.вопрос: как передавать реальный валидный сертификат который выпускается для NGINX в MTG, чтобы он не генерировал свой
Nginx (версия 1.22+):

Релевантная часть конфигурации nginx:

stream {
    map $ssl_preread_server_name $backend {
        ik.ххх.yyy mtg_backend;
        default web_backend;
    }
    upstream mtg_backend {
        server 127.0.0.1:8444;
    }
    server {
        listen 443 reuseport;
        ssl_preread on;
        proxy_pass $backend;
    }
}

Что происходит
Сам контейнер MTG устанавливает соединение с портом 443 хоста, используя свой IP 172.17.0.2.
Nginx, видя ik.ххх.yyy, перенаправляет трафик обратно на 127.0.0.1:8444, то есть снова на MTG.
Возникает петля, в результате которой создается множество TCP-соединений без передачи данных (out=0 in=0).

Вероятно, MTG после запуска выполняет внутреннюю самопроверку (self-test) или проверку домена (вероятно, резолвит domain и пытается подключиться к нему).
Если домен указывает на тот же хост, и трафик проходит через Nginx, возникает петля.

Какие есть варианты пресечения такого поведения?

Является ли это известным поведением? Есть ли способ отключить самопроверку (self-test/domain verification) в MTG?

Временное решение (костыль):
Я могу заблокировать петлю с помощью iptables:

iptables -I DOCKER-USER -s 172.17.0.2 -d 172.17.0.1 -p tcp --dport 443 -j DROP
Но хотелось бы более чистого решения внутри самого MTG.

[9seconds]

Попробуйте разорвать петлю с помощью конфигурации в domain-fronting секции. Если я правильно все понимаю, происходит следующее:

1. Запрос приходит на mtg
2. Тот видит, что с ним что-то не то, и перекидывает на хост, указанный в секрете
3. Этот хост резолвится в себя

Смотрите, что есть в настройках:

# This section is relevant to communication with fronting domain. Usually
# you do not need to setup anything here but there are plenty of cases, especially
# if you put mtg behind load balancer, when some specific configuration is
# required.
[domain-fronting]
# By default, mtg resolves the fronting hostname (from the secret) via DNS
# to establish a TCP connection. If DNS resolution of that hostname is blocked,
# you can specify an IP address to connect to directly. The hostname is still
# used for SNI in the TLS handshake.
#
# default value is not set (DNS resolution is used).
# ip = "10.10.10.11"

# FakeTLS uses domain fronting protection. So it needs to know a port to
# access. Default value is 443
# port = 443

# This makes a communication between both fronting website and mtg to use
# proxy protocol.
# proxy-protocol = false

Давайте предположим, что вы знаете, что nginx сидит по адресу 10.10.10.10:4444. Тогда можно прописать такое:

[domain-fronting]
ip = "10.10.10.10"
port = 4444

То есть mtg не будет пытаться разрезолвить хостнейм, и просто пойдет, куда вы ему скажете. С #480 можно будет подключаться и к другому хосту, не только к адресу