Update MTProxy checker documentation and logic to clarify probing modes and improve error handling. Modify README and Docker documentation to reflect changes in the -probe flag behavior, including detailed descriptions of exit codes and timeout handling. Refactor connection handling to enhance robustness and align with Telethon's approach.

docs/docker.ru.md

@@ -50,7 +50,7 @@ docker run -d --name mtproxy-api --restart unless-stopped -p 8080:8080 `
 | `MTPROXY_CHECK_INTERVAL` | `5m` | Интервал между циклами (`time.ParseDuration`, например `5m`, `1h`) |
 | `MTPROXY_HTTP_ADDR` | `:8080` | Адрес прослушивания HTTP |
 | `MTPROXY_CHECK_TIMEOUT` | `45s` (в демоне по умолчанию; CLI по-прежнему `15s` если не задано) | Таймаут **всей** одной проверки; для `MTPROXY_PROBE=deep` нужен запас (TLS + drain + ответ DC) |
-| `MTPROXY_PROBE` | *(пусто)* → **`fast`** | `fast` — как в ранних релизах: рукопожатие + init + любой входящий байт. `deep` — `req_pq`/`resPQ` через DC (строже, дольше) |
+| `MTPROXY_PROBE` | *(пусто)* → **`fast`** | `fast` — рукопожатие + init + короткое ожидание как в Telethon TcpMTProxy (#1134): OK, если прокси **не** рвёт TCP сразу после init (входящие байты не обязательны). `deep` — `req_pq`/`resPQ` через DC (строже, дольше) |
 | `MTPROXY_DC_ID` | `2` | DC id (аналог `-dc-id` CLI) |
 | `MTPROXY_ALLOWED_IPS` | *(не задана)* | Если задана непустая строка — доступ к **всем** маршрутам только с перечисленных IP/CIDR; остальные получают **403** и JSON `{"error":"forbidden"}`. Формат: через запятую, пробелы допускаются: `192.168.1.10`, `10.0.0.0/8`, IPv6 и CIDR вида `2001:db8::/32`. Учитывается только **`RemoteAddr`** TCP-соединения; заголовок `X-Forwarded-For` **не** используется |
 
@@ -61,7 +61,7 @@ docker run -d --name mtproxy-api --restart unless-stopped -p 8080:8080 `
 | GET | `/health` | `200`, `{"status":"ok"}` |
 | GET | `/api/v1/proxies` | `200`, JSON с полями `cycle_finished_at`, `next_check_after`, массив `proxies` |
 
-Элемент `proxies[]`: `raw_line`, при успешном разборе — `url`, `ok`, `exit_code` (`0` OK — через туннель прокси получен ответ DC на MTProto `req_pq` (`resPQ`), как при реальной проверке клиентом; `1` ошибка проверки, в т.ч. нет `resPQ` за время ожидания; `2` ошибка разбора URL/секрета; `3` прокси закрыл соединение; `4` таймаут всего запроса), `error`, при необходимости `parse_error`, `checked_at`.
+Элемент `proxies[]`: `raw_line`, при успешном разборе — `url`, `ok`, `exit_code` (`0` OK — при `MTPROXY_PROBE=fast`: рукопожатие + init и прокси не закрыл TCP сразу (как Telethon #1134); при **`deep`**: дополнительно получен `resPQ` от DC через туннель); `1` ошибка проверки, в т.ч. нет `resPQ` за время ожидания в `deep`; `2` ошибка разбора URL/секрета; `3` прокси закрыл соединение; `4` таймаут всего запроса), `error`, при необходимости `parse_error`, `checked_at`.
 
 ### Whitelist IP и Docker
 
@@ -281,8 +281,8 @@ docker run --rm registry.example.com/owner/mtproxy_checker:latest \
 
 | Код | Значение |
 |-----|----------|
-| 0 | Проверка прошла: Fake-TLS/dd + MTProxy init, затем MTProto `req_pq` и ответ `resPQ` от Telegram DC через прокси |
-| 1 | Ошибка (сеть, протокол; в т.ч. **нет валидного `resPQ`** — туннель до DC не подтверждён) |
+| 0 | **`fast`**: Fake-TLS/dd + MTProxy init, прокси не закрыл соединение сразу (как Telethon). **`deep`**: плюс подтверждён `resPQ` от DC |
+| 1 | Ошибка (сеть, протокол; в **`deep`** — в т.ч. нет валидного `resPQ`) |
 | 2 | Неверные аргументы CLI |
 | 3 | Прокси закрыл TCP сразу после начального payload |
 | 4 | Общий таймаут (`-timeout`) |