Telegram Mtpro Proxy Resolver — DevOps skill for Claude Code

telegram-mtpro-proxy-resolver

Skill для Claude Code: установка, запуск, диагностика и починка **Telegram MTProto прокси (MTProxy)** на удалённой машине по ssh.

Главное, ради чего он написан — MTProxy ломается **тихо**. Порт открыт, сервис `active`, `journalctl | grep error` пуст, фаервол чист, дата-центры пингуются — а клиент вечно висит в «Соединение...». Все привычные проверки зелёные, потому что ломается не транспорт, а RPC-хендшейк с middle-proxy Telegram, и он в лог ошибок не пишет.

Главная грабля: приватный IP в хендшейке

MTProxy — не голый TCP-туннель. Он подключается к middle-proxy Telegram и **сообщает собственный IP**. Определяет он его старым перебором интерфейсов через `ioctl`, и на машине с VPN или Docker выбирает приватный адрес: `10.x` (WireGuard/AmneziaWG) или `172.17.x` (docker0). Middle-proxy такой адрес не принимает, ответный поток не встаёт — но TCP-сессия остаётся живой.

Диагностический признак — одна информационная строка в логе:

journalctl -u mtproxy.service -n 100 | grep "Started as"
→ Started as [10.8.0.1:8888:32103:1787814306]
             ^^^^^^^^ не публичный адрес — это оно

Лечится флагом `--nat-info <адрес-движка>:<публичный-адрес>`.

Что **не** лечит — `--address <публичный-ip>`: на VPS адрес часто навешен с маской `/32`, движок такой bind отвергает (`Bad binded IP address ..., search in ifconfig`) и всё равно берёт приватный.

Установка

git clone https://github.com/guid-empty/telegram-mtpro-proxy-resolver.git \
  ~/.claude/skills/telegram-mtpro-proxy-resolver

Дальше skill подхватывается Claude Code автоматически и триггерится на разговоры про MTProxy, прокси для Telegram и симптом «вечное Соединение...».

Использование без Claude Code

Скрипты самодостаточны — их можно запускать руками:

scripts/mtproxy-remote.sh --host  --port  <команда>

Команда	Что делает
check	Проверяет ssh-доступ и права root
diagnose	Полный разбор с вердиктом: что сло