# mtproxy_checker

Проверка **MTProto MTProxy** на Go: не ICMP ping, а TCP + протокол (для `ee` — Fake-TLS, затем первый кадр MTProxy; для `dd` — сразу MTProxy Randomized Intermediate).

## Сборка

```powershell
go build -o mtproxy_checker.exe ./cmd/mtproxy_checker
```

## Запуск

```powershell
.\mtproxy_checker.exe "tg://proxy?server=HOST&port=PORT&secret=HEX"
```

или

```powershell
.\mtproxy_checker.exe --server HOST --port PORT --secret HEX
```

Флаги: `-timeout` (по умолчанию 15s), `-dc-id` (по умолчанию 2), `-probe fast|deep` (по умолчанию **`fast`** — как Telethon TcpMTProxy после init; **`deep`** — `req_pq`/`resPQ` до DC).

Код выхода: `0` — OK (**`fast`**: рукопожатие + init, прокси не рвёт TCP сразу; **`deep`**: плюс `resPQ` от DC), `1` — ошибка (в **`deep`** в т.ч. нет валидного `resPQ`), `2` — неверные аргументы, `3` — прокси закрыл соединение после проверки, `4` — таймаут.

**Docker:** [docs/docker.ru.md](docs/docker.ru.md) — один образ: **с аргументами** после образа — CLI; **без аргументов** — HTTP API (файл со списком `tg://`, интервал, опциональный whitelist IP).

### Если в Telegram прокси «Available», а утилита падает на `read server hello`

Для `ee` в TLS SNI должен идти **только ASCII hostname** из хвоста секрета; в коде это `SNIDomain`. Ответ сервера читается по схеме из Telegram Desktop (`mtproto_tls_socket`), а не по старому фиксированному формату telethon.