Cannot setup chain of mtproxies

[verycrawfish100500]

Hello.
I am trying to make chain of two mtproxies, that is, Telegram_client(local) -> proxy1 -> proxy2 - > telgram servers in the internet.

And i cannot.

Proxy 1 and proxy 2 are on different physical servers.

running proxy2:

./mtproto-proxy -u common-user -p 8888 -H 43951 -S `cat users_secret.txt` --aes-pwd proxy-secret proxy-multi.conf -M 1

running proxy1:

./mtproto-proxy --verbosity=2 -p 8888 -H 43951 -l mtproxy.log -S `cat users_secret.txt` --aes-pwd proxy-secret _proxy-multi.conf -M 1

For proxy 1, _proxy-multi.conf has following contents:

default 2;
proxy_for 2 10.0.0.1:43951;

(10.0.0.1 is an address of server with proxy 2. If it is incorrect to replace proxy-multi.conf contents, then how should I set adress of the upstream proxy?)

When tg client tries to connect to proxy 2, i get (among many others) messages like that:

nowhere to forward user query from connection 7, dropping

However, if i try to connect from tg client directly to proxy 2, everything works.

So, I am asking for help for that setup

[MamkinCoder]

I've managed to set it up today using caddy l4 and xray tunnel heres the config snippets

Traffic goes into Server 1 and is picked up by Caddy L4. We just forwarded a dedicated entry port directly to local Xray relay:

{
  layer4 {
    :<ENTRY_PORT> {
      route {
        proxy 127.0.0.1:<XRAY_RELAY_INBOUND_PORT>
      }
    }
  }
}

On Server 1, Xray receives that local TCP stream via dokodemo-door and routes it through a dedicated VLESS+REALITY outbound to Server 2:

{
  "inbounds": [
    {
      "tag": "mtproto-relay",
      "listen": "127.0.0.1",
      "port": <XRAY_RELAY_INBOUND_PORT>,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1",
        "port": <SERVER2_MTPROXY_PORT>,
        "network": "tcp"
      }
    }
  ],
  "outbounds": [
    {
      "tag": "mt-hop-out",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "<SERVER2_PUBLIC_IP>",
            "port": <SERVER2_XRAY_INBOUND_PORT>,
            "users": [{ "id": "<UUID>", "encryption": "none" }]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "<CAMO_DOMAIN>",
          "publicKey": "<PUBLIC_KEY>",
          "fingerprint": "chrome"
        }
      }
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["mtproto-relay"],
        "outboundTag": "mt-hop-out"
      }
    ]
  }
}

On Server 2, Xray accepts that tunnel on a dedicated inbound and sends it to direct, so the final destination becomes local MTProxy:

{
  "inbounds": [
    {
      "tag": "proxy-mt",
      "port": <SERVER2_XRAY_INBOUND_PORT>,
      "protocol": "vless",
      "settings": {
        "decryption": "none",
        "clients": [{ "id": "<UUID>" }]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "dest": "<CAMO_DOMAIN>:443",
          "serverNames": ["<CAMO_DOMAIN>"],
          "privateKey": "<PRIVATE_KEY>",
          "shortIds": [""]
        }
      }
    }
  ],
  "outbounds": [{ "tag": "direct", "protocol": "freedom" }]
}

I tried using docker first but image is outdated, couldn't connect using SNI, plain connection to server 2 worked so i've built repo from source and SNI started working:

the Docker image telegrammessenger/proxy is outdated (2020 build). Plain mode may work, but TLS transport (-D) was unreliable in our case. The stable fix was building official MTProxy from source (TelegramMessenger/MTProxy, current commit) and running that binary with TLS transport (-D ) plus promo tag (-P ). After switching to source-built MTProxy, the TLS + tagged setup worked as expected.