Enhance MTProxy checker by introducing a new -probe mode deep-strict for stricter response validation. Update README and Docker documentation to clarify probing modes, exit codes, and the new MTPROXY_TDLIB_HELPER and MTPROXY_TDLIB_TIMEOUT environment variables for external helper integration. Refactor connection handling and error reporting to improve robustness and clarity in response verification.

2026-04-11 16:12:45 +07:00
parent 24a7315a16
commit 388784eb5e
17 changed files with 902 additions and 24 deletions
@@ -20,12 +20,14 @@ go build -o mtproxy_checker.exe ./cmd/mtproxy_checker
 .\mtproxy_checker.exe --server HOST --port PORT --secret HEX
 ```

-Флаги: `-timeout` (по умолчанию 15s), `-dc-id` (по умолчанию 2), `-dc-ids` (например `1,2,3,4,5` — проверка **каждого** DC по очереди; `-timeout` на **один** DC; общий лимит времени умножается на число DC; код `0`, если **хотя бы один** DC прошёл; список удавшихся DC печатается в stderr), `-probe fast|deep` (по умолчанию **`fast`** — как Telethon TcpMTProxy после init; **`deep`** — `req_pq`/`resPQ` до DC).
+Флаги: `-timeout` (по умолчанию 15s), `-dc-id` (по умолчанию 2), `-dc-ids` (например `1,2,3,4,5` — проверка **каждого** DC по очереди; `-timeout` на **один** DC; общий лимит времени умножается на число DC; код `0`, если **хотя бы один** DC прошёл; список удавшихся DC печатается в stderr), `-probe fast|deep|deep-strict` (по умолчанию **`fast`** — как Telethon TcpMTProxy после init; **`deep`** — после init отправляется `req_pq`, успех если от DC пришло **любое** валидное unencrypted MTProto-сообщение (часто `resPQ`, но не только); **`deep-strict`** — как раньше `deep`, ответ должен быть именно `resPQ`).

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

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

+**HTTP API и TDLib:** в JSON каждой строки прокси поля **`standard`** (наш TCP/MTProxy чек) и **`tdlib`** (опционально: внешний helper TDLib `addProxy`+`pingProxy`). Рекомендуется нативный бинарник **`tdlib_ping`** (`cmd/tdlib_ping`, официальный JSON API TDLib через `libtdjson`). Альтернатива на Node — `contrib/tdlib-ping`. Задаётся `MTPROXY_TDLIB_HELPER` и `MTPROXY_TDLIB_TIMEOUT`; helper вызывается только в режиме **`fast`**. Базовый Docker-образ остаётся без TDLib/Node — helper подключают своим слоем образа или volume.
+
 ### Если в Telegram прокси «Available», а утилита падает на `read server hello`

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