chore(release): 2.0.0-beta.12 (#52 )

Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>
fix(proxy): загрузка останавливала отправку, туннель шёл в одну сторону (#42 , #32 ) (#51 )
2026-09-05 18:16:09 +03:00 · 2026-08-26 16:34:54 +03:00 · 2026-08-26 16:28:43 +03:00 · 2026-08-19 15:04:34 +03:00 · 2026-08-19 14:59:34 +03:00 · 2026-08-19 14:37:05 +03:00
16 changed files with 1295 additions and 105 deletions
@@ -9,7 +9,40 @@ permissions:
  contents: write

 jobs:
+  # Токен Actions умеет создавать релиз только на HEAD ветки по умолчанию. Если
+  # тег отстал хоть на один коммит, GitHub отвечает «Resource not accessible by
+  # integration» — сообщение про права, хотя права в порядке и дело в положении
+  # тега. Так утонул v2.0.0-beta.8: тег поставили, следом дописали коммит в main,
+  # и три сборки по восемь минут закончились загадочным 403.
+  #
+  # Проверка занимает секунды и идёт до сборок. Но она НЕ закрывает гонку: если
+  # запушить в main уже после её прохождения, публикация всё равно упадёт — как и
+  # случилось с beta.8. Единственная настоящая защита — порядок действий: тег
+  # ставится последним, и пока идёт релиз, в main не пушим.
+  guard:
+    name: Тег должен стоять на HEAD
+    runs-on: ubuntu-latest
+    steps:
+      - name: Сверить тег с веткой по умолчанию
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          branch=$(gh api "repos/$GITHUB_REPOSITORY" -q .default_branch)
+          head=$(gh api "repos/$GITHUB_REPOSITORY/commits/$branch" -q .sha)
+          if [ "$head" = "$GITHUB_SHA" ]; then
+            echo "$GITHUB_REF_NAME и $branch указывают на $head — собираем."
+            exit 0
+          fi
+          echo "::error::$GITHUB_REF_NAME стоит на $GITHUB_SHA, а $branch — на $head. Публикация упадёт с 403, потому что токен Actions создаёт релиз только на HEAD ветки по умолчанию."
+          echo "Переставьте тег и запушьте заново:"
+          echo "  git tag -d $GITHUB_REF_NAME"
+          echo "  git push origin :refs/tags/$GITHUB_REF_NAME"
+          echo "  git tag -a $GITHUB_REF_NAME $head -m 'TGLock ...'"
+          echo "  git push origin $GITHUB_REF_NAME"
+          exit 1
+
  publish:
+    needs: guard
    name: Build ${{ matrix.platform }}
    strategy:
      fail-fast: false
@@ -3553,7 +3553,7 @@ dependencies = [

 [[package]]
 name = "tglock"
-version = "2.0.0-beta.8"
+version = "2.0.0-beta.12"
 dependencies = [
 "aes",
 "cipher",
@@ -1,6 +1,6 @@
 [package]
 name = "tglock"
-version = "2.0.0-beta.8"
+version = "2.0.0-beta.12"
 edition = "2021"
 rust-version = "1.88"
 description = "Telegram unblock via local WebSocket tunnel"
@@ -165,6 +165,13 @@ Telegram → Настройки → **Продвинутые** → Тип сое

 В LAN-режиме TGLock пропускает **только адреса Telegram**. Открытым SOCKS5-прокси для всего интернета он при этом не становится — иначе им бы воспользовались не только твои устройства.

+> **📵 С телефона не подключается?** Открой **Диагностика** на компьютере и посмотри две цифры.
+>
+> - **Соединения `0` и Отклонено `0`** — телефон до компьютера не дошёл. Дело не в TGLock: проверь, что оба устройства в одной сети (телефон может сидеть на гостевом Wi-Fi или в мобильном интернете), что в роутере не включена изоляция клиентов, и что брандмауэр пускает входящие на порт TGLock.
+> - **Соединения растут, Отклонено растёт** — телефон дошёл, но просит адрес, который LAN-режим не пропускает. Конкретный адрес назван в журнале событий ниже — пришли эту строку в issue.
+> - **Не опознаны растёт** — телефон дошёл, но договориться не вышло. Почти всегда в Telegram на телефоне вписана ссылка от прошлого запуска, то есть другой секрет. Сверь её с той, что показана в окне сейчас.
+> - **Соединения растут, Туннели `0`** — до Telegram не доходит уже сам компьютер. Это [Cloudflare Worker](docs/CLOUDFLARE_WORKER.md), а не проблема LAN.
+
 ### 🖥 Без графического интерфейса: `tglock-cli`

 Для сервера, виртуалки, контейнера и машины без монитора или без 3D-ускорения. Это отдельный бинарь, в котором **нет ни Tauri, ни системного WebView** — там, где окно просто не создаётся, CLI работает.
@@ -201,7 +208,7 @@ worker = ["my-name.workers.dev"]

 Файл с секретом внутри держите с правами `600`: это доступ к вашему прокси.

-При запуске печатается готовая `tg://proxy`-ссылка — её можно открыть на любом устройстве в сети, чтобы Telegram настроился сам. Дальше в лог идёт по строке на каждое изменение состояния: сколько соединений, какой дата-центр, какой маршрут живой, сколько сбоев.
+При запуске печатается готовая `tg://proxy`-ссылка — её можно открыть на любом устройстве в сети, чтобы Telegram настроился сам. Дальше в лог идёт по строке на каждое изменение состояния: сколько соединений, какой дата-центр, какой маршрут живой, сколько сбоев, сколько запросов отклонено политикой «только Telegram» и сколько клиентов не опознано. Отдельными строками отмечаются подключившиеся устройства, адреса, из-за которых был отказ, и клиенты, с которыми не удалось договориться, — по ним видно, дошёл ли телефон до сервиса вообще и не вписан ли в нём устаревший секрет.

 Прав администратора не нужно: TGLock не правит ни системный DNS, ни файл `hosts` — нужные адреса Telegram зашиты в маршрутах, а TLS SNI остаётся настоящим.

@@ -55,6 +55,99 @@ LAN-режим превращал бы машину в открытый прок
 `config::ListenConfig`, а не в условиях по месту вызова; переопределяется
 только явным `--allow-direct` в CLI.

+### Что считается адресом Telegram
+
+Список сетей — опубликованный самим Telegram
+(<https://core.telegram.org/resources/cidr.txt>), он лежит в `telegram_net` и
+проверяется по маске префикса. До 2.0.0-beta.9 сравнивались два первых октета,
+то есть «телеграмом» считались целиком `149.154.0.0/16`, `91.108.0.0/16`,
+`91.105.0.0/16` и `185.76.0.0/16`, а IPv6 не распознавался вовсе. Ошибка была в
+обе стороны:
+
+- чужие адреса внутри этих `/16` уходили в MTProto-туннель и умирали там;
+- настоящие адреса дата-центров по IPv6 отклонялись как посторонние.
+
+Второе и давало «на компьютере работает, с телефона нет» (#42): на loopback
+неопознанный адрес всё равно релеился напрямую, поэтому там дефект не
+проявлялся, а на сетевом слушателе тот же адрес получал отказ.
+
+Назначение делится на три вида:
+
+| Вид | Что это | Что делаем |
+|---|---|---|
+| Дата-центр | IP из опубликованных сетей, v4 или v6 | заворачиваем в WebSocket |
+| Веб Telegram | имя из `telegram.org`, `t.me`, `telegram.me`, `telesco.pe`, `cdn-telegram.org` | пропускаем как есть — это обычный HTTPS, а не MTProto |
+| Всё остальное | — | напрямую на loopback, отказ на сетевом адресе |
+
+Имена сопоставляются по границе метки, поэтому `telegram.org.example.com` —
+посторонний домен. В ограниченном режиме имя разрешается заранее, и адреса
+внутри локальной сети (`127.0.0.0/8`, `10/8`, `172.16/12`, `192.168/16`,
+`100.64/10`, `fc00::/7`, `fe80::/10`) отбрасываются: назначение выбирает чужое
+устройство, и DNS-ответ не должен превращать TGLock в дверь во внутреннюю сеть
+этой машины.
+
+### Отказ перестаёт быть молчаливым
+
+Отклонённый запрос увеличивает счётчик `blocked` и один раз называет адрес в
+журнале; повторы того же адреса склеиваются, чтобы не забить журнал одной
+строкой. Отдельно отмечается первое подключение с каждого сетевого адреса.
+
+Без этого «с телефона не работает» неразличимо распадалось на два случая:
+телефон не дошёл до машины (сеть, брандмауэр, изоляция клиентов на роутере) —
+и дошёл, но попросил адрес, который мы не пропускаем. Первый виден как ноль
+соединений и ноль отказов, второй — как соединения есть, отказы растут.
+
+Третий случай нашёлся, когда репортёр #42 прислал диагностику: у него было ноль
+отказов и работающие туннели, то есть оба счётчика говорили «всё хорошо».
+Клиент, который дошёл до прокси, но не сумел договориться, не попадал ни в
+один из них. Соединение просто закрывалось: `active` дёргался вверх и обратно.
+
+Теперь такие клиенты считает `unknown_clients`, и журнал называет адрес и
+причину. Их две:
+
+- MTProto-init не разбирается под текущим секретом. Почти всегда это ссылка
+  `tg://proxy` от прошлого запуска: секрет — её половина, и клиент со
+  сохранённой старой ссылкой попадает ровно сюда. Со стороны Telegram это и
+  есть «прокси настроен неверно и будет отключён» (#37).
+- SOCKS5-приветствие не разбирается. Сюда же попадает MTProto-соединение,
+  ушедшее в SOCKS5-ветку по неоднозначному первому байту, если полный init не
+  успел прийти за `PROTOCOL_PROBE_TIMEOUT`.
+
+Счётчик `ws_failures` от них отличается тем, что растёт после успешного
+рукопожатия с клиентом: там договорились с клиентом, но не смогли с Telegram.
+
+## Туннель: два независимых направления
+
+Каждое клиентское соединение получает свой WebSocket-туннель, и внутри него
+данные идут в обе стороны сразу. До 2.0.0-beta.12 оба направления обслуживал
+один `select!` с пометкой `biased`, и это давало два дефекта, снаружи
+выглядевших одинаково: «Подключено», а ничего не идёт.
+
+`biased` опрашивает ветки строго по порядку. Пока в первой — «Telegram →
+клиент» — есть данные, до второй очередь не доходит вообще. То есть при
+непрерывном потоке вниз (первичная синхронизация телефона, загрузка медиа)
+исходящие пакеты клиента не читались.
+
+Второй дефект — одна задача на оба направления. `tcp_w.write_all` ждёт, пока
+клиент разберёт присланное, и всё это время не опрашивается чтение от клиента.
+Телефон по Wi-Fi разбирает поток медленнее, чем Telegram Desktop на той же
+машине через loopback, — отсюда асимметрия «на компьютере работает, на телефоне
+нет» из #42.
+
+Для MTProto это фатально: клиент обязан слать подтверждения, а за каждым
+следующим куском файла — свой `upload.getFile`. Первый запрос уходит, дальше
+идёт поток вниз, и следующие запросы наверх не попадают. Загрузка встаёт при
+живом туннеле, нулевых сбоях и нулевых отклонениях — ровно картина из #32.
+
+Теперь это две независимые половины: `ws.split()` плюс `CryptoContext::split()`,
+потому что шифры направлений независимы — два потока AES-CTR со своими ключами.
+Ping приходит в читающую половину, а отвечает на него пишущая, через канал на
+четыре слота: владелец отправляющей половины должен оставаться ровно один.
+
+Оба дефекта закрыты тестами, которые падают на beta.11. Первый: за пять секунд
+непрерывной загрузки наверх не уходит ни одного байта. Второй: клиент, не
+успевающий читать, замораживает собственную отправку.
+
 ## Учёт состояния

 `Stats::ws` считает **установленные** туннели: счётчик поднимается после
@@ -63,6 +156,14 @@ LAN-режим превращал бы машину в открытый прок
 несколько секунд каждый. Состояния «порт открыт», «идёт перебор маршрутов» и
 «туннель установлен» различимы и в GUI, и в выводе CLI.

+Дата-центр и маршрут пишутся **одним значением**, в момент, когда туннель
+поднялся. Пока это были два независимых поля, номер писало соединение при
+разборе init, а маршрут — другое соединение после рукопожатия, и при десятках
+одновременных соединений в строку статуса попадала пара из разных из них.
+Читалась она как «до этого DC шли этим маршрутом», хотя означала другое: в
+диагностике #42 встречались строки `DC5 · Запасной Telegram IP`, а у DC5
+закреплённый адрес всего один и запасного у него не бывает вовсе.
+
 Секрет прокси — половина ссылки `tg://proxy`. Для сервиса его нужно закрепить
 файлом (`--secret-file`): под `DynamicUser` и `ProtectHome` домашней папки нет,
 путь по умолчанию не определяется, и секрет генерировался бы заново при каждом
@@ -41,6 +41,44 @@
 > кодом, LAN-режим ограничен адресами Telegram на уровне типа, Cloudflare Worker
 > остаётся исключительно пользовательской настройкой.

+> **Статус на 19 августа 2026.** С прошлой отметки вышли beta.6, beta.7,
+> beta.8 и beta.9. Что закрыто и что осталось:
+>
+> - **#32 (медиа).** Файл настроек `tglock.toml` сделан в beta.6 — это была
+>   отдельная просьба из того же issue. Заодно исправлена паника `println!` при
+>   закрытом stdout. Причина проблем с медиа не подтверждена: репортёр не
+>   прислал строку статуса в момент, когда фото не грузится. Слабое место
+>   названо в самом issue — у DC203 закреплён один IP, резерва по адресам для
+>   медиа нет.
+> - **#37 («прокси настроен неверно»).** В beta.7 перестала проглатываться
+>   ошибка записи секрета: раньше при неудачной записи в `%APPDATA%\TGLock`
+>   секрет молча генерировался заново при каждом запуске, и ссылка `tg://proxy`
+>   переставала совпадать с сохранённой в Telegram. Это гипотеза, а не
+>   подтверждённый диагноз — воспроизвести случай репортёра не удалось, но
+>   теперь видно, тот это случай или нет.
+> - **#39 (не работает).** По скриншоту: соединения есть, DC определяется,
+>   туннелей ноль, 678 падений маршрутов за пять минут. Наружу не отвечает ни
+>   один маршрут — у провайдера заблокирована веб-инфраструктура Telegram
+>   целиком. Кодом это не лечится, остаётся свой Cloudflare Worker. Счётчик
+>   падений маршрутов, по которому это стало видно, появился в beta.7.
+> - **#40, #41 (свои).** В LAN-режиме окно показывает готовый адрес для других
+>   устройств — люди искали его в интерфейсе и вписывали `127.0.0.1`. И страж
+>   тега в CI, который ловит тег, поставленный не на HEAD.
+> - **#42 (LAN не работает с телефона).** Нашлось в коде. Принадлежность адреса
+>   Telegram проверялась по двум первым октетам, то есть «телеграмом» считались
+>   целиком четыре `/16`, а IPv6 не распознавался вовсе. На loopback это не
+>   проявлялось: неопознанный адрес там всё равно релеится напрямую. На сетевом
+>   слушателе тот же адрес получал отказ — отсюда ровно то, что описал
+>   репортёр: на компьютере работает, с телефона нет. В beta.9 список сетей
+>   взят опубликованный Telegram, добавлены IPv6 и имена веб-инфраструктуры.
+>   Отказ перестал быть молчаливым: счётчик «Отклонено» и адрес в журнале.
+> - **#9 (Android)** остаётся открытым. PR #36 собирает APK, но приложение
+>   никто ни разу не запускал — нужен человек с телефоном.
+>
+> Общее по трём разобранным issue: во всех трёх диагноз упирался в то, что
+> программа не рассказывала о себе достаточно. Каждый выпуск с beta.7 добавлял
+> не функцию, а показание прибора.
+
 ## Выводы

 Главная причина жалоб «прокси подключён, но Telegram не работает» — приложение
@@ -0,0 +1,74 @@
+# Как выпускать релиз
+
+## Порядок важен
+
+Токен GitHub Actions создаёт релиз **только на HEAD ветки по умолчанию**. Если тег
+отстанет от `main` хотя бы на один коммит, публикация упадёт с ошибкой
+`Resource not accessible by integration` — сообщение про права, хотя права в
+порядке и дело в положении тега.
+
+Отсюда единственное жёсткое правило: **тег ставится последним, и пока идёт
+релиз, в `main` не пушим.**
+
+## Шаги
+
+1. Влить в `main` всё, что должно попасть в релиз, и дождаться зелёного CI.
+2. Поднять версию **в двух местах** — `Cargo.toml` и `tauri.conf.json`. Они
+   должны совпадать: имена файлов бандла берутся из `tauri.conf.json`.
+3. Закоммитить подъём версии и запушить в `main`.
+4. Убедиться, что больше ничего не уедет: `git ls-remote origin refs/heads/main`
+   должен совпасть с локальным `git rev-parse HEAD`.
+5. Поставить аннотированный тег на этот же коммит и запушить его:
+
+   ```bash
+   git tag -a v2.0.0-beta.N -m "TGLock 2.0.0-beta.N"
+   git push origin v2.0.0-beta.N
+   ```
+
+6. **Ничего не пушить в `main`, пока сборка не закончится.** Правки README,
+   документации, чего угодно — после публикации релиза.
+
+## Проверить, что выпустили
+
+Зелёный workflow — это ещё не доказательство. В бетах 2 и 3 сборка была зелёной,
+а в приложение попадал headless-бинарь вместо графического. Поэтому проверяем
+содержимое, а не имя файла:
+
+```bash
+gh release download vX.Y.Z --repo by-sonic/tglock -p 'TGLock_universal.app.tar.gz' -D /tmp/check
+tar -xzf /tmp/check/TGLock_universal.app.tar.gz -C /tmp/check
+python scripts/verify_bundle_binary.py /tmp/check/TGLock.app/Contents/MacOS/tglock
+```
+
+Скрипт ищет внутри бинаря маркеры GUI (`ipc.localhost`, `wry`) и маркеры CLI
+(`allow-direct`, `secret-file`) и ругается, если в бандле оказался не тот.
+
+## Если публикация всё-таки упала с `Resource not accessible by integration`
+
+Значит, тег разошёлся с `main`. Сверьте:
+
+```bash
+git ls-remote origin refs/heads/main 'refs/tags/vX.Y.Z^{}'
+```
+
+Если SHA разные — переставьте тег на HEAD и запушьте заново:
+
+```bash
+git tag -d vX.Y.Z
+git push origin :refs/tags/vX.Y.Z
+git tag -a vX.Y.Z <sha ветки main> -m "TGLock X.Y.Z"
+git push origin vX.Y.Z
+```
+
+Перезапускать упавший workflow бесполезно: он возьмёт тот же отставший тег и
+упадёт снова.
+
+## Что защищает автоматически
+
+Первым шагом релиза идёт задача `guard`: она сверяет тег с HEAD ветки по
+умолчанию и валится за секунды, не запуская сборки. Она ловит тег, поставленный
+на старый коммит.
+
+Она **не** ловит гонку: если запушить в `main` уже после её прохождения, но до
+конца сборки, публикация упадёт. Ровно так утонул первый заход v2.0.0-beta.8.
+От этого защищает только правило из первого раздела.
@@ -1,7 +1,7 @@
 {
  "name": "tglock-ui",
  "private": true,
-  "version": "2.0.0-beta.8",
+  "version": "2.0.0-beta.12",
  "type": "module",
  "scripts": {
    "dev": "vite --port 1420",
@@ -205,21 +205,33 @@ async fn watch_status(stats: Arc<proxy::Stats>) {
    let mut previous = None;
    loop {
        tokio::time::sleep(STATUS_POLL).await;
+
+        // Отдельные события — кто подключился и какой адрес отклонён. Без них
+        // journalctl показывает только счётчики, по которым нельзя отличить
+        // «телефон не дошёл» от «дошёл и получил отказ» (by-sonic/tglock#42).
+        for event in stats.drain_events() {
+            if !say(&event) {
+                return;
+            }
+        }
+
        let current = (
            stats.active.load(Ordering::Relaxed),
            stats.ws.load(Ordering::Relaxed),
-            stats.last_dc.load(Ordering::Relaxed),
-            stats.last_route.load(Ordering::Relaxed),
+            stats.last_dc(),
+            stats.last_route(),
            stats.ws_failures.load(Ordering::Relaxed),
            stats.route_failures(),
+            stats.blocked.load(Ordering::Relaxed),
+            stats.unknown_clients.load(Ordering::Relaxed),
        );
        if previous.as_ref() == Some(&current) {
            continue;
        }
-        let (active, tunnels, dc, route, failures, route_failures) = current;
+        let (active, tunnels, dc, route, failures, route_failures, blocked, unknown) = current;
        let line = format!(
            "соединений {active} · туннелей {tunnels} · {} · {} · сбоев {failures} · \
-             падений маршрутов {route_failures}",
+             падений маршрутов {route_failures} · отклонено {blocked} · не опознано {unknown}",
            if dc > 0 {
                format!("DC{dc}")
            } else {
@@ -8,6 +8,7 @@
 pub mod config;
 pub mod mtproto;
 pub mod proxy;
+pub mod telegram_net;
 pub mod transport;

 /// Настройки headless-версии: файл конфигурации и сведение с флагами.
@@ -47,6 +47,15 @@ struct StatusSnapshot {
    /// Падения отдельных маршрутов. Растёт даже когда соединение в итоге
    /// состоялось через запасной адрес (by-sonic/tglock#32).
    route_failures: u32,
+    /// Запросы, отклонённые политикой «в LAN-режиме только Telegram».
+    ///
+    /// Ноль при неработающем телефоне означает, что он вообще не дотянулся до
+    /// этой машины; не ноль — что дотянулся, и разбираться надо с адресами
+    /// (by-sonic/tglock#42).
+    blocked: u32,
+    /// Клиенты, которые дошли, но не сумели договориться. Почти всегда это
+    /// ссылка `tg://proxy` от прошлого запуска, то есть другой секрет.
+    unknown_clients: u32,
    uptime_seconds: u64,
    port: u16,
    /// Адрес, который нужно вписать в Telegram на другом устройстве.
@@ -102,8 +111,13 @@ impl AppState {
    }

    fn snapshot(&self) -> StatusSnapshot {
-        let data_center = self.stats.last_dc.load(Ordering::Relaxed);
-        let route = transport::route_label(self.stats.last_route.load(Ordering::Relaxed));
+        // События прокси доходят до журнала только здесь: у ядра нет своего
+        // способа что-то показать, а интерфейс и так опрашивает состояние.
+        for event in self.stats.drain_events() {
+            self.log(event, false);
+        }
+        let data_center = self.stats.last_dc();
+        let route = transport::route_label(self.stats.last_route());
        StatusSnapshot {
            running: self.stats.running.load(Ordering::SeqCst),
            active_connections: self.stats.active.load(Ordering::Relaxed),
@@ -112,6 +126,8 @@ impl AppState {
            route: route.to_owned(),
            failures: self.stats.ws_failures.load(Ordering::Relaxed),
            route_failures: self.stats.route_failures(),
+            blocked: self.stats.blocked.load(Ordering::Relaxed),
+            unknown_clients: self.stats.unknown_clients.load(Ordering::Relaxed),
            uptime_seconds: self
                .started_at
                .lock()
@@ -43,6 +43,49 @@ impl CryptoContext {
        self.telegram_decrypt.apply_keystream(data);
        self.client_encrypt.apply_keystream(data);
    }
+
+    /// Разделить шифры по направлениям, чтобы туннель шёл в обе стороны сразу.
+    ///
+    /// Направления независимы: это два потока AES-CTR со своими ключами, и ни
+    /// один байт одного не влияет на другой.
+    pub fn split(self) -> (Upstream, Downstream) {
+        (
+            Upstream {
+                client_decrypt: self.client_decrypt,
+                telegram_encrypt: self.telegram_encrypt,
+            },
+            Downstream {
+                telegram_decrypt: self.telegram_decrypt,
+                client_encrypt: self.client_encrypt,
+            },
+        )
+    }
+}
+
+/// Шифры направления «клиент -> Telegram».
+pub struct Upstream {
+    client_decrypt: AesCtr,
+    telegram_encrypt: AesCtr,
+}
+
+impl Upstream {
+    pub fn apply(&mut self, data: &mut [u8]) {
+        self.client_decrypt.apply_keystream(data);
+        self.telegram_encrypt.apply_keystream(data);
+    }
+}
+
+/// Шифры направления «Telegram -> клиент».
+pub struct Downstream {
+    telegram_decrypt: AesCtr,
+    client_encrypt: AesCtr,
+}
+
+impl Downstream {
+    pub fn apply(&mut self, data: &mut [u8]) {
+        self.telegram_decrypt.apply_keystream(data);
+        self.client_encrypt.apply_keystream(data);
+    }
 }

 pub fn generate_secret() -> [u8; 16] {
@@ -1,6 +1,7 @@
 use crate::config::ListenConfig;
-use std::net::Ipv4Addr;
-use std::sync::atomic::{AtomicBool, AtomicU16, AtomicU32, AtomicU8, Ordering};
+use std::collections::{HashSet, VecDeque};
+use std::net::{IpAddr, Ipv4Addr, SocketAddr};
+use std::sync::atomic::{AtomicBool, AtomicU16, AtomicU32, Ordering};
 use std::sync::{Arc, Mutex};
 use std::time::Duration;
 use tokio::io::{AsyncRead, AsyncReadExt, AsyncWrite, AsyncWriteExt};
@@ -15,23 +16,66 @@ const SOCKS5_VERSION: u8 = 0x05;
 /// byte as the start of a SOCKS5 greeting.
 const PROTOCOL_PROBE_TIMEOUT: Duration = Duration::from_millis(250);
 const PROTOCOL_PROBE_INTERVAL: Duration = Duration::from_millis(5);
+/// Сколько неотвеченных Ping'ов держать, пока отправляющая половина занята.
+const PONG_QUEUE: usize = 4;

 pub struct Stats {
    pub running: AtomicBool,
    pub active: AtomicU32,
    pub total: AtomicU32,
    pub ws: AtomicU32,
-    pub last_dc: AtomicU16,
+    /// DC последнего разобранного соединения. Показывается, пока туннеля ещё
+    /// нет: клиент уже понят, маршрут ещё не выбран.
+    seen_dc: AtomicU16,
    pub ws_failures: AtomicU32,
-    /// See `transport::RouteKind::ui_code`.
-    pub last_route: AtomicU8,
+    /// Сколько запросов отклонено политикой «только Telegram».
+    ///
+    /// В LAN-режиме это единственный признак, отличающий «телефон не дотянулся
+    /// до компьютера» от «дотянулся, но попросил адрес, который мы не пускаем».
+    /// Раньше отказ происходил молча, и снаружи оба случая выглядели одинаково
+    /// (by-sonic/tglock#42).
+    pub blocked: AtomicU32,
+    /// Сколько клиентов дошло до прокси, но не сумело договориться.
+    ///
+    /// Почти всегда это несовпадение секрета: в Telegram вписана ссылка от
+    /// прошлого запуска. Такое соединение закрывалось молча, и по диагностике
+    /// отличить его от рабочего было нельзя.
+    pub unknown_clients: AtomicU32,
+    /// DC и маршрут последнего поднятого туннеля, упакованные в одно значение.
+    ///
+    /// Раньше это были два независимых поля: номер писало соединение при
+    /// разборе init, маршрут — другое соединение после рукопожатия. При
+    /// нескольких десятках одновременных соединений пара в строке статуса
+    /// складывалась из разных из них, и читалась она как «до этого DC шли
+    /// этим маршрутом», хотя означала совсем не это. У DC1, DC3, DC5 и DC203
+    /// закреплённый адрес всего один, и «запасного» у них не бывает вовсе —
+    /// а строки `DC5 · Запасной Telegram IP` в диагностике встречались
+    /// (by-sonic/tglock#42).
+    ///
+    /// Формат: `dc << 8 | route`, где route — `transport::RouteKind::ui_code`.
+    last_tunnel: AtomicU32,
    transport: crate::transport::TransportEngine,
    secret: [u8; 16],
    /// Почему секрет не удалось сохранить, если не удалось.
    secret_write_error: Option<String>,
+    events: Mutex<Events>,
    shutdown: Mutex<Option<tokio::sync::watch::Sender<bool>>>,
 }

+/// Однократные сообщения о том, что происходит с подключениями.
+///
+/// Однократные намеренно: отклонённый адрес повторяется десятки раз в минуту,
+/// и без склейки журнал превратился бы в одну строку, повторённую сто раз.
+/// Число повторов при этом не теряется — оно в счётчике `blocked`.
+#[derive(Default)]
+struct Events {
+    pending: VecDeque<String>,
+    seen: HashSet<String>,
+}
+
+/// Сколько разных событий помним, чтобы буфер не рос без границы.
+const EVENT_LIMIT: usize = 64;
+
 impl Stats {
    pub fn new() -> Arc<Self> {
        Self::with_stored_secret(initial_secret())
@@ -65,16 +109,94 @@ impl Stats {
            active: AtomicU32::new(0),
            total: AtomicU32::new(0),
            ws: AtomicU32::new(0),
-            last_dc: AtomicU16::new(0),
+            seen_dc: AtomicU16::new(0),
            ws_failures: AtomicU32::new(0),
-            last_route: AtomicU8::new(0),
+            blocked: AtomicU32::new(0),
+            unknown_clients: AtomicU32::new(0),
+            last_tunnel: AtomicU32::new(0),
            transport: crate::transport::TransportEngine::new(),
            secret,
            secret_write_error,
+            events: Mutex::new(Events::default()),
            shutdown: Mutex::new(None),
        })
    }

+    /// Запомнить событие, если такого ещё не было.
+    pub fn note(&self, message: impl Into<String>) {
+        let message = message.into();
+        let mut events = self.events.lock().unwrap();
+        if events.seen.len() >= EVENT_LIMIT || !events.seen.insert(message.clone()) {
+            return;
+        }
+        events.pending.push_back(message);
+    }
+
+    /// Забрать накопившиеся события. Показывает их GUI или CLI — тот, кто есть.
+    pub fn drain_events(&self) -> Vec<String> {
+        self.events.lock().unwrap().pending.drain(..).collect()
+    }
+
+    fn note_blocked(&self, destination: &str, port: u16) {
+        self.blocked.fetch_add(1, Ordering::Relaxed);
+        self.note(format!(
+            "Отклонено: {destination}:{port} — адрес не из сетей Telegram"
+        ));
+    }
+
+    /// Клиент дошёл, но договориться с ним не удалось.
+    ///
+    /// Раньше такое соединение закрывалось молча: `active` дёргался вверх и
+    /// обратно, и всё. По диагностике это неотличимо от «клиент подключился и
+    /// работает», хотя означает противоположное (by-sonic/tglock#42).
+    fn note_unknown_client(&self, peer: Option<SocketAddr>, reason: &str) {
+        self.unknown_clients.fetch_add(1, Ordering::Relaxed);
+        let who = match peer {
+            Some(peer) => peer.ip().to_string(),
+            None => "неизвестный адрес".to_owned(),
+        };
+        self.note(format!("Клиент {who}: {reason}"));
+    }
+
+    /// Отметить, что до прокси дотянулось устройство из сети, а не с этой машины.
+    ///
+    /// Это первое, что нужно знать при разборе LAN-режима: если строки нет,
+    /// телефон до компьютера не дошёл, и дело в сети, а не в TGLock.
+    fn note_peer(&self, peer: SocketAddr) {
+        if peer.ip().is_loopback() {
+            return;
+        }
+        self.note(format!("Подключилось устройство из сети: {}", peer.ip()));
+    }
+
+    /// Запомнить DC, с которым пришёл клиент. Туннеля может ещё не быть.
+    fn note_dc(&self, dc: u16) {
+        self.seen_dc.store(dc, Ordering::Relaxed);
+    }
+
+    /// Запомнить, каким маршрутом поднялся туннель и до какого DC.
+    ///
+    /// Пишется одним значением, чтобы пара в диагностике всегда была из
+    /// одного соединения.
+    fn note_tunnel(&self, dc: u16, route: u8) {
+        self.last_tunnel
+            .store(u32::from(dc) << 8 | u32::from(route), Ordering::Relaxed);
+    }
+
+    /// Номер дата-центра для показа: из последнего поднятого туннеля, а пока
+    /// туннеля не было — из последнего разобранного соединения.
+    pub fn last_dc(&self) -> u16 {
+        match self.last_tunnel.load(Ordering::Relaxed) {
+            0 => self.seen_dc.load(Ordering::Relaxed),
+            packed => (packed >> 8) as u16,
+        }
+    }
+
+    /// Маршрут последнего поднятого туннеля. См. `transport::RouteKind::ui_code`.
+    pub fn last_route(&self) -> u8 {
+        (self.last_tunnel.load(Ordering::Relaxed) & 0xff) as u8
+    }
+
    pub fn telegram_secret(&self) -> String {
        crate::mtproto::telegram_secret(&self.secret)
    }
@@ -149,8 +271,9 @@ pub async fn serve(
        tokio::select! {
            result = listener.accept() => {
                match result {
-                    Ok((stream, _)) => {
+                    Ok((stream, peer)) => {
                        let s = stats.clone();
+                        s.note_peer(peer);
                        s.active.fetch_add(1, Ordering::Relaxed);
                        s.total.fetch_add(1, Ordering::Relaxed);
                        tasks.spawn(async move {
@@ -243,18 +366,55 @@ async fn detect_protocol(
    }
 }

+/// Куда просится SOCKS5-клиент и что с этим делать.
+#[derive(Debug, Eq, PartialEq)]
+enum Destination {
+    /// Адрес дата-центра Telegram: дальше идёт MTProto, его заворачиваем в
+    /// WebSocket — ради этого TGLock и существует.
+    DataCentre(IpAddr),
+    /// Имя из веб-инфраструктуры Telegram. Это обычный HTTPS, а не MTProto:
+    /// клиент ходит сюда за конфигурацией, превью и файлами CDN. Заворачивать
+    /// такое соединение в MTProto-туннель нельзя, его нужно пропустить как есть.
+    ///
+    /// На телефоне эти запросы идут через тот же прокси, поэтому в LAN-режиме
+    /// они разрешены — иначе клиент не может даже дочитать свою конфигурацию.
+    TelegramWeb,
+    /// Всё остальное. На loopback пропускается напрямую, на сетевом адресе —
+    /// отклоняется, иначе LAN-режим стал бы открытым прокси.
+    Elsewhere,
+}
+
+fn classify(address: &str) -> Destination {
+    match address.parse::<IpAddr>() {
+        Ok(ip) if crate::telegram_net::is_telegram(ip) => Destination::DataCentre(ip),
+        Ok(_) => Destination::Elsewhere,
+        Err(_) if crate::telegram_net::is_telegram_host(address) => Destination::TelegramWeb,
+        Err(_) => Destination::Elsewhere,
+    }
+}
+
 async fn handle_socks5(
    mut s: TcpStream,
    stats: &Stats,
    allow_direct: bool,
 ) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    s.set_nodelay(true)?;
+    let peer = s.peer_addr().ok();

-    let (addr, port) = tokio::time::timeout(IO_TIMEOUT, read_socks5_request(&mut s))
+    let request = tokio::time::timeout(IO_TIMEOUT, read_socks5_request(&mut s))
        .await
-        .map_err(|_| "SOCKS5 handshake timeout")??;
-    let tg = addr.parse::<Ipv4Addr>().ok().and_then(dc_from_ip).is_some();
-    if !tg && !allow_direct {
+        .map_err(|_| "SOCKS5 handshake timeout".to_owned())
+        .and_then(|result| result.map_err(|error| error.to_string()));
+    let (addr, port) = match request {
+        Ok(request) => request,
+        Err(error) => {
+            stats.note_unknown_client(peer, &format!("SOCKS5-приветствие не разобрано ({error})"));
+            return Err(error.into());
+        }
+    };
+    let destination = classify(&addr);
+    if destination == Destination::Elsewhere && !allow_direct {
+        stats.note_blocked(&addr, port);
        write_socks_reply(&mut s, 0x02).await?;
        return Err("LAN mode only permits Telegram destinations".into());
    }
@@ -263,19 +423,15 @@ async fn handle_socks5(
    s.write_all(&[0x05, 0x00, 0x00, 0x01, 127, 0, 0, 1, 0x04, 0x38])
        .await?;

-    if tg {
+    if let Destination::DataCentre(ip) = destination {
        // Read 64-byte obfuscated2 init → extract real DC
        let mut init = [0u8; 64];
        s.read_exact(&mut init).await?;

-        let (dc, media) = dc_from_init(&init).unwrap_or_else(|| {
-            addr.parse::<Ipv4Addr>()
-                .ok()
-                .and_then(dc_from_ip)
-                .map_or((2, false), |dc| (dc, false))
-        });
+        let (dc, media) = dc_from_init(&init)
+            .unwrap_or_else(|| (crate::telegram_net::dc_from_ip(ip).unwrap_or(2), false));

-        stats.last_dc.store(dc, Ordering::Relaxed);
+        stats.note_dc(dc);

        let r = ws_tunnel(s, dc, media, &init, None, stats).await;

@@ -284,7 +440,7 @@ async fn handle_socks5(
        }
        r?;
    } else {
-        let remote = tokio::time::timeout(IO_TIMEOUT, TcpStream::connect((addr.as_str(), port)))
+        let remote = tokio::time::timeout(IO_TIMEOUT, connect_direct(&addr, port, allow_direct))
            .await
            .map_err(|_| "direct connection timeout")??;
        let _ = remote.set_nodelay(true);
@@ -293,19 +449,87 @@ async fn handle_socks5(
    Ok(())
 }

+/// Открыть прямое соединение по адресу, который назвал клиент.
+///
+/// В ограниченном режиме имя разрешается заранее и проверяется, куда оно
+/// указывает: список доменов принадлежит Telegram, но DNS-ответ приходит извне,
+/// а адрес назначения выбирает чужое устройство. Без проверки ответ вида
+/// `127.0.0.1` или `192.168.0.1` сделал бы TGLock дверью во внутреннюю сеть
+/// этой машины.
+async fn connect_direct(
+    address: &str,
+    port: u16,
+    allow_direct: bool,
+) -> Result<TcpStream, Box<dyn std::error::Error + Send + Sync>> {
+    if allow_direct {
+        return Ok(TcpStream::connect((address, port)).await?);
+    }
+
+    let mut last = None;
+    for candidate in tokio::net::lookup_host((address, port)).await? {
+        if is_private(candidate.ip()) {
+            continue;
+        }
+        match TcpStream::connect(candidate).await {
+            Ok(stream) => return Ok(stream),
+            Err(error) => last = Some(error),
+        }
+    }
+    Err(match last {
+        Some(error) => Box::new(error) as Box<dyn std::error::Error + Send + Sync>,
+        None => format!("{address} resolves only to addresses inside this network").into(),
+    })
+}
+
+fn is_private(ip: IpAddr) -> bool {
+    match ip {
+        IpAddr::V4(ip) => {
+            ip.is_private()
+                || ip.is_loopback()
+                || ip.is_link_local()
+                || ip.is_broadcast()
+                || ip.is_unspecified()
+                || ip.octets()[0] == 0
+                // 100.64.0.0/10, операторский NAT
+                || (ip.octets()[0] == 100 && (64..128).contains(&ip.octets()[1]))
+        }
+        IpAddr::V6(ip) => {
+            ip.is_loopback()
+                || ip.is_unspecified()
+                // fc00::/7 — уникальные локальные, fe80::/10 — link-local
+                || (ip.segments()[0] & 0xfe00) == 0xfc00
+                || (ip.segments()[0] & 0xffc0) == 0xfe80
+                || ip.to_ipv4_mapped().is_some_and(|ip| is_private(IpAddr::V4(ip)))
+        }
+    }
+}
+
 async fn handle_mtproto(
    mut stream: TcpStream,
    stats: &Stats,
 ) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    stream.set_nodelay(true)?;
+    let peer = stream.peer_addr().ok();
    let mut init = [0; 64];
    tokio::time::timeout(IO_TIMEOUT, stream.read_exact(&mut init))
        .await
        .map_err(|_| "MTProto init timeout")??;
-    let parsed = crate::mtproto::parse_client_init(&init, &stats.secret)
-        .ok_or("invalid MTProto init or secret")?;
+    let parsed = match crate::mtproto::parse_client_init(&init, &stats.secret) {
+        Some(parsed) => parsed,
+        None => {
+            // Секрет — половина ссылки `tg://proxy`. Клиент с сохранённой
+            // ссылкой от прошлого запуска попадает ровно сюда, и Telegram
+            // показывает ему «прокси настроен неверно».
+            stats.note_unknown_client(
+                peer,
+                "MTProto-init не разобран. Скорее всего в Telegram вписан другой \
+                 секрет — сверьте ссылку tg://proxy с той, что показана сейчас",
+            );
+            return Err("invalid MTProto init or secret".into());
+        }
+    };

-    stats.last_dc.store(parsed.dc, Ordering::Relaxed);
+    stats.note_dc(parsed.dc);
    let result = ws_tunnel(
        stream,
        parsed.dc,
@@ -407,28 +631,6 @@ fn dc_from_init(init: &[u8; 64]) -> Option<(u16, bool)> {
    matches!(dc, 1..=5 | 203).then_some((dc, id < 0))
 }

-fn dc_from_ip(ip: Ipv4Addr) -> Option<u16> {
-    let o = ip.octets();
-    match (o[0], o[1]) {
-        (149, 154) => Some(match o[2] {
-            160..=163 => 1,
-            164..=167 => 2,
-            168..=171 => 3,
-            172..=175 => 1,
-            _ => 2,
-        }),
-        (91, 108) => Some(match o[2] {
-            56..=59 => 5,
-            8..=11 => 3,
-            12..=15 => 4,
-            _ => 2,
-        }),
-        (91, 105) if o[2] == 192 => Some(203),
-        (91, 105) | (185, 76) => Some(2),
-        _ => None,
-    }
-}
-
 // -- WebSocket tunnel -------------------------------------------------------

 /// Keeps `Stats::ws` equal to the number of *established* tunnels.
@@ -458,57 +660,92 @@ async fn ws_tunnel(
    dc: u16,
    media: bool,
    init: &[u8; 64],
-    mut crypto: Option<crate::mtproto::CryptoContext>,
+    crypto: Option<crate::mtproto::CryptoContext>,
    stats: &Stats,
 ) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    use futures_util::{SinkExt, StreamExt};

-    let (mut ws, connected) = stats.transport.connect(dc, media).await?;
+    let (ws, connected) = stats.transport.connect(dc, media).await?;
    let _tunnel = EstablishedTunnel::new(stats);
-    stats
-        .last_route
-        .store(connected.route.kind.ui_code(), Ordering::Relaxed);
+    stats.note_tunnel(dc, connected.route.kind.ui_code());

    let (mut tcp_r, mut tcp_w) = tokio::io::split(tcp);
+    let (mut ws_w, mut ws_r) = ws.split();
+    let (upstream_crypto, downstream_crypto) = match crypto.map(|crypto| crypto.split()) {
+        Some((upstream, downstream)) => (Some(upstream), Some(downstream)),
+        None => (None, None),
+    };

    // Send buffered init as first frame
-    ws.send(tungstenite::Message::Binary(init.to_vec())).await?;
+    ws_w.send(tungstenite::Message::Binary(init.to_vec()))
+        .await?;

-    let mut buf = vec![0u8; 65536];
+    // Ping приходит в половину, которая читает, а отвечать на него должна та,
+    // которая пишет: владелец у отправляющей половины строго один.
+    let (pong_tx, mut pong_rx) = tokio::sync::mpsc::channel::<Vec<u8>>(PONG_QUEUE);

-    loop {
-        tokio::select! {
-            biased;
-
-            msg = ws.next() => match msg {
-                Some(Ok(tungstenite::Message::Binary(mut data))) => {
+    // Направления работают независимо друг от друга. Раньше это был один
+    // `select!`, и любое ожидание внутри него останавливало вторую половину:
+    // непрерывная загрузка не давала опросить клиента вообще, а клиент,
+    // который не успевал разбирать входящий поток, замораживал заодно и свою
+    // отправку. Telegram при этом ждёт от клиента подтверждений — без них
+    // сессия встаёт при живом туннеле (by-sonic/tglock#42, #32).
+    let downstream = async {
+        let mut crypto = downstream_crypto;
+        while let Some(message) = ws_r.next().await {
+            match message {
+                Ok(tungstenite::Message::Binary(mut data)) => {
                    if let Some(crypto) = &mut crypto {
-                        crypto.telegram_to_client(data.as_mut());
+                        crypto.apply(data.as_mut());
                    }
                    tcp_w.write_all(data.as_ref()).await?;
                    tcp_w.flush().await?;
                }
-                Some(Ok(tungstenite::Message::Ping(p))) => {
-                    let _ = ws.send(tungstenite::Message::Pong(p)).await;
-                }
-                Some(Ok(tungstenite::Message::Close(_))) | None => break,
-                Some(Err(_)) => break,
-                _ => {}
-            },
-
-            n = tcp_r.read(&mut buf) => match n {
-                Ok(0) | Err(_) => break,
-                Ok(n) => {
-                    if let Some(crypto) = &mut crypto {
-                        crypto.client_to_telegram(&mut buf[..n]);
+                Ok(tungstenite::Message::Ping(payload)) => {
+                    if pong_tx.send(payload).await.is_err() {
+                        break;
                    }
-                    ws.send(tungstenite::Message::Binary(buf[..n].to_vec())).await?;
                }
-            },
+                Ok(tungstenite::Message::Close(_)) | Err(_) => break,
+                Ok(_) => {}
+            }
        }
-    }
+        Ok::<(), Box<dyn std::error::Error + Send + Sync>>(())
+    };

-    let _ = ws.close(None).await;
+    let upstream = async {
+        let mut crypto = upstream_crypto;
+        let mut buf = vec![0u8; 65536];
+        loop {
+            tokio::select! {
+                read = tcp_r.read(&mut buf) => match read {
+                    Ok(0) | Err(_) => break,
+                    Ok(read) => {
+                        if let Some(crypto) = &mut crypto {
+                            crypto.apply(&mut buf[..read]);
+                        }
+                        ws_w
+                            .send(tungstenite::Message::Binary(buf[..read].to_vec()))
+                            .await?;
+                    }
+                },
+                payload = pong_rx.recv() => match payload {
+                    Some(payload) => {
+                        ws_w.send(tungstenite::Message::Pong(payload)).await?;
+                    }
+                    None => break,
+                },
+            }
+        }
+        let _ = ws_w.close().await;
+        Ok::<(), Box<dyn std::error::Error + Send + Sync>>(())
+    };
+
+    tokio::pin!(downstream, upstream);
+    tokio::select! {
+        result = &mut downstream => result?,
+        result = &mut upstream => result?,
+    }
    Ok(())
 }

@@ -696,12 +933,130 @@ mod tests {
        assert!(server_task.await.unwrap());
    }

+    /// Что именно решает судьбу соединения в LAN-режиме.
+    ///
+    /// Принадлежность адреса сетям Telegram проверяется в `telegram_net`;
+    /// здесь важно, что из неё следует для каждой из трёх веток.
    #[test]
-    fn maps_known_telegram_networks_to_dc() {
-        assert_eq!(dc_from_ip("149.154.160.1".parse().unwrap()), Some(1));
-        assert_eq!(dc_from_ip("149.154.167.255".parse().unwrap()), Some(2));
-        assert_eq!(dc_from_ip("91.108.58.1".parse().unwrap()), Some(5));
-        assert_eq!(dc_from_ip("1.1.1.1".parse().unwrap()), None);
+    fn destinations_are_sorted_into_three_kinds() {
+        assert_eq!(
+            classify("149.154.167.51"),
+            Destination::DataCentre("149.154.167.51".parse().unwrap())
+        );
+        assert_eq!(
+            classify("2001:67c:4e8:f002::a"),
+            Destination::DataCentre("2001:67c:4e8:f002::a".parse().unwrap()),
+            "IPv6-адрес дата-центра — такой же Telegram (by-sonic/tglock#42)"
+        );
+        assert_eq!(classify("web.telegram.org"), Destination::TelegramWeb);
+        assert_eq!(classify("1.1.1.1"), Destination::Elsewhere);
+        assert_eq!(
+            classify("185.76.150.1"),
+            Destination::Elsewhere,
+            "соседний адрес вне опубликованного блока Telegram"
+        );
+        assert_eq!(classify("telegram.org.example.com"), Destination::Elsewhere);
+    }
+
+    #[test]
+    fn a_refused_destination_is_counted_and_named_once() {
+        let stats = Stats::new();
+        for _ in 0..3 {
+            stats.note_blocked("1.1.1.1", 443);
+        }
+        stats.note_blocked("8.8.8.8", 443);
+
+        assert_eq!(
+            stats.blocked.load(Ordering::Relaxed),
+            4,
+            "счётчик считает все отказы"
+        );
+        let events = stats.drain_events();
+        assert_eq!(events.len(), 2, "а журнал называет каждый адрес один раз");
+        assert!(events[0].contains("1.1.1.1:443"), "{events:?}");
+        assert!(
+            stats.drain_events().is_empty(),
+            "забранное событие не приходит повторно"
+        );
+    }
+
+    /// Диагностика обязана показывать пару из одного соединения.
+    ///
+    /// Пока это были два независимых поля, при десятках одновременных
+    /// соединений в строку статуса попадали номер от одного и маршрут от
+    /// другого. Читалось это как «до DC5 шли запасным адресом», хотя у DC5
+    /// закреплённый адрес всего один и запасного не бывает вовсе
+    /// (by-sonic/tglock#42).
+    #[test]
+    fn the_reported_data_centre_and_route_come_from_the_same_tunnel() {
+        let stats = Stats::new();
+        assert_eq!(stats.last_dc(), 0, "до соединений показывать нечего");
+        assert_eq!(stats.last_route(), 0);
+
+        stats.note_dc(2);
+        assert_eq!(stats.last_dc(), 2, "клиент разобран, номер известен");
+        assert_eq!(stats.last_route(), 0, "а маршрут ещё не выбран");
+
+        stats.note_tunnel(4, 2);
+        assert_eq!((stats.last_dc(), stats.last_route()), (4, 2));
+
+        // Ещё одно соединение до другого DC, туннеля у него пока нет.
+        stats.note_dc(203);
+        assert_eq!(
+            (stats.last_dc(), stats.last_route()),
+            (4, 2),
+            "пара обязана остаться от соединения, у которого туннель был"
+        );
+    }
+
+    /// Клиент с сохранённой ссылкой от прошлого запуска. Раньше его соединение
+    /// закрывалось молча, и по диагностике это было неотличимо от рабочего.
+    #[tokio::test]
+    async fn a_client_with_the_wrong_secret_gets_named_instead_of_dropped_in_silence() {
+        let stats = Stats::new();
+        let (port, server) = start_proxy(stats.clone(), true).await;
+
+        let stranger = crate::mtproto::generate_secret();
+        let init = unambiguous_client_init(&stranger, 2);
+        let mut client = TcpStream::connect(("127.0.0.1", port)).await.unwrap();
+        client.write_all(&init).await.unwrap();
+
+        wait_until("отказ по секрету", || {
+            stats.unknown_clients.load(Ordering::Relaxed) > 0
+        })
+        .await;
+        let events = stats.drain_events();
+        assert!(
+            events
+                .iter()
+                .any(|event| event.contains("MTProto-init не разобран")),
+            "в журнале должно быть сказано, что init не разобран: {events:?}"
+        );
+
+        stats.stop();
+        let _ = server.await.unwrap();
+    }
+
+    #[tokio::test]
+    async fn a_client_that_speaks_neither_protocol_is_counted_too() {
+        let stats = Stats::new();
+        let (port, server) = start_proxy(stats.clone(), true).await;
+
+        // Приветствие SOCKS5 с нулём методов: разбор обязан провалиться.
+        let mut client = TcpStream::connect(("127.0.0.1", port)).await.unwrap();
+        client.write_all(&[0x05, 0x00]).await.unwrap();
+
+        wait_until("отказ по рукопожатию", || {
+            stats.unknown_clients.load(Ordering::Relaxed) > 0
+        })
+        .await;
+        assert!(stats
+            .drain_events()
+            .iter()
+            .any(|event| event.contains("SOCKS5-приветствие не разобрано")));
+
+        stats.stop();
+        let _ = server.await.unwrap();
    }

    #[tokio::test]
@@ -832,7 +1187,7 @@ mod tests {
        // Detection must land on MTProto, which records the data centre. The
        // SOCKS5 path would instead answer with a handshake reply.
        wait_until("the MTProto data centre to be recorded", || {
-            stats.last_dc.load(Ordering::Relaxed) == 2
+            stats.last_dc() == 2
        })
        .await;

@@ -873,6 +1228,42 @@ mod tests {
            reply[1], 0x02,
            "a shared listener must not relay arbitrary destinations"
        );
+        assert_eq!(
+            stats.blocked.load(Ordering::Relaxed),
+            1,
+            "отказ должен быть виден в диагностике, а не только клиенту"
+        );
+        assert!(
+            stats
+                .drain_events()
+                .iter()
+                .any(|event| event.contains("1.1.1.1:443")),
+            "в журнале должен быть назван адрес, из-за которого отказали"
+        );
+
+        stats.stop();
+        let _ = server.await.unwrap();
+    }
+
+    /// Ровно то, на чём ломался LAN-режим: телефон просит адрес дата-центра по
+    /// IPv6, а прокси отвечает «не Telegram» (by-sonic/tglock#42).
+    #[tokio::test]
+    async fn network_listener_accepts_a_telegram_ipv6_data_centre() {
+        let stats = Stats::new();
+        let (port, server) = start_proxy(stats.clone(), false).await;
+
+        let mut request = vec![0x05, 0x01, 0x00, 0x04];
+        request.extend_from_slice(
+            &"2001:67c:4e8:f002::a"
+                .parse::<std::net::Ipv6Addr>()
+                .unwrap()
+                .octets(),
+        );
+        request.extend_from_slice(&443_u16.to_be_bytes());
+
+        let (_client, reply) = socks5_exchange(port, &request).await;
+        assert_eq!(reply[1], 0x00, "адрес Telegram по IPv6 нельзя отклонять");
+        assert_eq!(stats.blocked.load(Ordering::Relaxed), 0);

        stats.stop();
        let _ = server.await.unwrap();
@@ -949,9 +1340,9 @@ mod tests {
            "Telegram must receive exactly the client's plaintext"
        );

-        assert_eq!(stats.last_dc.load(Ordering::Relaxed), 4);
+        assert_eq!(stats.last_dc(), 4);
        assert_eq!(
-            stats.last_route.load(Ordering::Relaxed),
+            stats.last_route(),
            crate::transport::RouteKind::TelegramIp.ui_code()
        );
        assert_eq!(stats.ws_failures.load(Ordering::Relaxed), 0);
@@ -1006,7 +1397,7 @@ mod tests {
        );
        assert_eq!(relayed, request);
        assert_eq!(
-            stats.last_route.load(Ordering::Relaxed),
+            stats.last_route(),
            crate::transport::RouteKind::CloudflareWorker.ui_code()
        );

@@ -1034,10 +1425,7 @@ mod tests {
        let mut client = TcpStream::connect(("127.0.0.1", port)).await.unwrap();
        client.write_all(&init).await.unwrap();

-        wait_until("the init to be parsed", || {
-            stats.last_dc.load(Ordering::Relaxed) == 2
-        })
-        .await;
+        wait_until("the init to be parsed", || stats.last_dc() == 2).await;
        tokio::time::sleep(Duration::from_millis(300)).await;

        assert_eq!(
@@ -1046,7 +1434,7 @@ mod tests {
            "a handshake still in flight must not be reported as a working tunnel"
        );
        assert_eq!(
-            stats.last_route.load(Ordering::Relaxed),
+            stats.last_route(),
            0,
            "no route may be announced before a tunnel is established"
        );
@@ -1075,7 +1463,7 @@ mod tests {
        })
        .await;
        assert_eq!(
-            stats.last_route.load(Ordering::Relaxed),
+            stats.last_route(),
            0,
            "a route must not be reported as working when every attempt failed"
        );
@@ -1105,16 +1493,194 @@ mod tests {
        client.write_all(&init).await.unwrap();

        tokio::time::timeout(Duration::from_secs(10), async {
-            while stats.last_route.load(Ordering::Relaxed) == 0 {
+            while stats.last_route() == 0 {
                tokio::task::yield_now().await;
            }
        })
        .await
        .unwrap();
-        assert_eq!(stats.last_dc.load(Ordering::Relaxed), 4);
+        assert_eq!(stats.last_dc(), 4);
        assert_eq!(stats.ws_failures.load(Ordering::Relaxed), 0);

        stats.stop();
        server.await.unwrap().unwrap();
    }
+
+    /// Скачивание не должно затыкать отправку.
+    ///
+    /// В `ws_tunnel` цикл `select!` помечен `biased`, то есть сначала всегда
+    /// опрашивается ветка чтения из WebSocket. Пока Telegram присылает данные
+    /// непрерывно — а именно так выглядит загрузка медиа или первичная
+    /// синхронизация телефона — ветка чтения из клиента не опрашивается
+    /// вообще, и исходящие пакеты клиента наверх не уходят.
+    #[allow(clippy::result_large_err)]
+    #[tokio::test]
+    async fn a_download_in_flight_must_not_stop_the_client_from_sending() {
+        use futures_util::{SinkExt, StreamExt};
+
+        let relay_listener = TcpListener::bind("127.0.0.1:0").await.unwrap();
+        let relay_port = relay_listener.local_addr().unwrap().port();
+        let uploads = Arc::new(std::sync::atomic::AtomicUsize::new(0));
+        let relay_uploads = uploads.clone();
+
+        tokio::spawn(async move {
+            let (tcp, _) = relay_listener.accept().await.unwrap();
+            let websocket =
+                tokio_tungstenite::accept_hdr_async(tcp, |_: &Request, mut response: Response| {
+                    response.headers_mut().insert(
+                        "Sec-WebSocket-Protocol",
+                        "binary".parse().expect("static header value"),
+                    );
+                    Ok(response)
+                })
+                .await
+                .unwrap();
+            let (mut sink, mut stream) = websocket.split();
+
+            match stream.next().await {
+                Some(Ok(Message::Binary(_))) => {}
+                other => panic!("expected an init frame, got {other:?}"),
+            }
+
+            tokio::spawn(async move {
+                while let Some(message) = stream.next().await {
+                    if let Ok(Message::Binary(data)) = message {
+                        relay_uploads.fetch_add(data.len(), Ordering::Relaxed);
+                    }
+                }
+            });
+
+            // Непрерывный поток вниз — так выглядит загрузка медиа.
+            while sink.send(Message::Binary(vec![0; 32 * 1024])).await.is_ok() {}
+        });
+
+        let stats = Stats::new();
+        stats.transport.force_local_route(relay_port);
+        let (port, server) = start_proxy(stats.clone(), false).await;
+
+        let init = unambiguous_client_init(&stats.secret, -4);
+        let client = TcpStream::connect(("127.0.0.1", port)).await.unwrap();
+        let (mut client_r, mut client_w) = client.into_split();
+        client_w.write_all(&init).await.unwrap();
+
+        // Клиент исправно читает загрузку, иначе он затыкал бы туннель сам.
+        let downloaded = Arc::new(std::sync::atomic::AtomicUsize::new(0));
+        let counted = downloaded.clone();
+        tokio::spawn(async move {
+            let mut drain = vec![0; 64 * 1024];
+            while let Ok(read) = client_r.read(&mut drain).await {
+                if read == 0 {
+                    break;
+                }
+                counted.fetch_add(read, Ordering::Relaxed);
+            }
+        });
+
+        wait_until("загрузка пошла", || {
+            downloaded.load(Ordering::Relaxed) > 1024 * 1024
+        })
+        .await;
+
+        // Telegram ждёт от клиента подтверждений и запросов. Без них сессия
+        // встаёт: «Подключено», а сообщения висят с часиками.
+        tokio::spawn(async move {
+            while client_w.write_all(&[0x42; 128]).await.is_ok() {
+                tokio::time::sleep(Duration::from_millis(20)).await;
+            }
+        });
+
+        tokio::time::timeout(Duration::from_secs(5), async {
+            while uploads.load(Ordering::Relaxed) == 0 {
+                tokio::time::sleep(Duration::from_millis(10)).await;
+            }
+        })
+        .await
+        .expect("пока идёт загрузка, клиент должен доставить наверх хоть один байт");
+
+        stats.stop();
+        let _ = server.await.unwrap();
+    }
+
+    /// Медленный клиент не должен останавливать весь туннель.
+    ///
+    /// `ws_tunnel` читает и пишет в одной задаче: пока `tcp_w.write_all` ждёт,
+    /// когда клиент разберёт присланное, ветка чтения из клиента не
+    /// опрашивается, и наверх не уходит ничего. Телефон по Wi-Fi разбирает
+    /// поток медленнее, чем десктоп на той же машине по loopback — отсюда
+    /// асимметрия «на компьютере работает, на телефоне нет».
+    #[allow(clippy::result_large_err)]
+    #[tokio::test]
+    async fn a_slow_client_must_not_freeze_its_own_uploads() {
+        use futures_util::{SinkExt, StreamExt};
+
+        let relay_listener = TcpListener::bind("127.0.0.1:0").await.unwrap();
+        let relay_port = relay_listener.local_addr().unwrap().port();
+        let uploads = Arc::new(std::sync::atomic::AtomicUsize::new(0));
+        let relay_uploads = uploads.clone();
+
+        tokio::spawn(async move {
+            let (tcp, _) = relay_listener.accept().await.unwrap();
+            let websocket =
+                tokio_tungstenite::accept_hdr_async(tcp, |_: &Request, mut response: Response| {
+                    response.headers_mut().insert(
+                        "Sec-WebSocket-Protocol",
+                        "binary".parse().expect("static header value"),
+                    );
+                    Ok(response)
+                })
+                .await
+                .unwrap();
+            let (mut sink, mut stream) = websocket.split();
+
+            match stream.next().await {
+                Some(Ok(Message::Binary(_))) => {}
+                other => panic!("expected an init frame, got {other:?}"),
+            }
+
+            tokio::spawn(async move {
+                while let Some(message) = stream.next().await {
+                    if let Ok(Message::Binary(data)) = message {
+                        relay_uploads.fetch_add(data.len(), Ordering::Relaxed);
+                    }
+                }
+            });
+
+            while sink.send(Message::Binary(vec![0; 32 * 1024])).await.is_ok() {}
+        });
+
+        let stats = Stats::new();
+        stats.transport.force_local_route(relay_port);
+        let (port, server) = start_proxy(stats.clone(), false).await;
+
+        let init = unambiguous_client_init(&stats.secret, -4);
+        let client = TcpStream::connect(("127.0.0.1", port)).await.unwrap();
+        let (client_r, mut client_w) = client.into_split();
+        client_w.write_all(&init).await.unwrap();
+
+        // Клиент занят и не разбирает входящий поток: его приёмное окно
+        // закрывается, и запись в него встаёт.
+        wait_until("туннель поднялся", || {
+            stats.last_route() != 0
+        })
+        .await;
+        tokio::time::sleep(Duration::from_secs(2)).await;
+
+        tokio::spawn(async move {
+            while client_w.write_all(&[0x42; 128]).await.is_ok() {
+                tokio::time::sleep(Duration::from_millis(20)).await;
+            }
+        });
+
+        let result = tokio::time::timeout(Duration::from_secs(5), async {
+            while uploads.load(Ordering::Relaxed) == 0 {
+                tokio::time::sleep(Duration::from_millis(10)).await;
+            }
+        })
+        .await;
+
+        drop(client_r);
+        stats.stop();
+        let _ = server.await.unwrap();
+        result.expect("клиент, который не успевает читать, всё равно должен отправлять");
+    }
 }
@@ -0,0 +1,271 @@
+//! Какие адреса и имена принадлежат Telegram.
+//!
+//! От этого ответа зависит поведение LAN-режима: слушатель на сетевом адресе
+//! пропускает только Telegram, всё остальное отклоняет. Значит ошибка в любую
+//! сторону видна пользователю.
+//!
+//! Раньше проверка сравнивала два первых октета, то есть считала «телеграмом»
+//! целиком `149.154.0.0/16`, `91.108.0.0/16`, `91.105.0.0/16` и `185.76.0.0/16`,
+//! а IPv6 не знала вовсе. Отсюда два разных дефекта: чужие адреса внутри этих
+//! сетей уходили в MTProto-туннель и умирали, а настоящие адреса Telegram по
+//! IPv6 отклонялись как посторонние. Второе и выглядит как «на компьютере
+//! работает, с телефона нет» (by-sonic/tglock#42): на loopback не-Telegram
+//! адреса всё равно релеятся напрямую, поэтому там ошибка не проявляется.
+//!
+//! Список сетей — официальный, <https://core.telegram.org/resources/cidr.txt>,
+//! сверен 19 августа 2026 года.
+
+use std::net::{IpAddr, Ipv4Addr, Ipv6Addr};
+
+/// IPv4-сети Telegram: адрес сети и длина префикса.
+const V4: &[(Ipv4Addr, u32)] = &[
+    (Ipv4Addr::new(91, 105, 192, 0), 23),
+    (Ipv4Addr::new(91, 108, 4, 0), 22),
+    (Ipv4Addr::new(91, 108, 8, 0), 22),
+    (Ipv4Addr::new(91, 108, 12, 0), 22),
+    (Ipv4Addr::new(91, 108, 16, 0), 22),
+    (Ipv4Addr::new(91, 108, 20, 0), 22),
+    (Ipv4Addr::new(91, 108, 56, 0), 22),
+    (Ipv4Addr::new(149, 154, 160, 0), 20),
+    (Ipv4Addr::new(185, 76, 151, 0), 24),
+];
+
+/// IPv6-сети Telegram.
+const V6: &[(Ipv6Addr, u32)] = &[
+    (Ipv6Addr::new(0x2001, 0x67c, 0x4e8, 0, 0, 0, 0, 0), 48),
+    (Ipv6Addr::new(0x2001, 0xb28, 0xf23c, 0, 0, 0, 0, 0), 48),
+    (Ipv6Addr::new(0x2001, 0xb28, 0xf23d, 0, 0, 0, 0, 0), 48),
+    (Ipv6Addr::new(0x2001, 0xb28, 0xf23f, 0, 0, 0, 0, 0), 48),
+    (Ipv6Addr::new(0x2a0a, 0xf280, 0, 0, 0, 0, 0, 0), 32),
+];
+
+/// Домены Telegram, к которым SOCKS5-клиент может попроситься по имени.
+///
+/// Это веб-инфраструктура, а не дата-центры: обычный HTTPS, MTProto в нём нет.
+/// Telegram ходит сюда за конфигурацией, превью ссылок и файлами CDN, и на
+/// телефоне такие запросы идут через тот же прокси.
+const HOSTS: &[&str] = &[
+    "telegram.org",
+    "t.me",
+    "telegram.me",
+    "telesco.pe",
+    "cdn-telegram.org",
+];
+
+/// Принадлежит ли адрес Telegram.
+pub fn is_telegram(ip: IpAddr) -> bool {
+    match ip {
+        IpAddr::V4(ip) => in_v4(ip),
+        // Клиент может прислать `::ffff:149.154.167.51` вместо IPv4-формы, и
+        // это тот же самый адрес.
+        IpAddr::V6(ip) => match ip.to_ipv4_mapped() {
+            Some(ip) => in_v4(ip),
+            None => in_v6(ip),
+        },
+    }
+}
+
+/// Принадлежит ли имя Telegram.
+///
+/// Совпадение только по границе метки: `telegram.org.example.com` — чужой
+/// домен, и разрешать его нельзя.
+pub fn is_telegram_host(host: &str) -> bool {
+    let host = host.trim_end_matches('.').to_ascii_lowercase();
+    HOSTS.iter().any(|suffix| {
+        host == *suffix
+            || (host.len() > suffix.len()
+                && host.ends_with(suffix)
+                && host.as_bytes()[host.len() - suffix.len() - 1] == b'.')
+    })
+}
+
+/// Номер дата-центра по адресу — запасной вариант, когда его не удалось
+/// достать из init-пакета.
+///
+/// Это догадка, а не факт: одна и та же подсеть обслуживает несколько DC
+/// (`149.154.175.x` — и DC1, и DC3). Настоящий номер приходит из init, и сюда
+/// попадают только соединения, у которых init разобрать не вышло.
+pub fn dc_from_ip(ip: IpAddr) -> Option<u16> {
+    match ip {
+        IpAddr::V4(ip) => dc_from_ipv4(ip),
+        IpAddr::V6(ip) => match ip.to_ipv4_mapped() {
+            Some(ip) => dc_from_ipv4(ip),
+            None => dc_from_ipv6(ip),
+        },
+    }
+}
+
+fn dc_from_ipv4(ip: Ipv4Addr) -> Option<u16> {
+    if !in_v4(ip) {
+        return None;
+    }
+    let octets = ip.octets();
+    Some(match (octets[0], octets[1], octets[2]) {
+        (149, 154, 160..=163) => 1,
+        (149, 154, 164..=167) => 2,
+        (149, 154, 168..=171) => 3,
+        (149, 154, 172..=175) => 1,
+        (91, 108, 56..=59) => 5,
+        (91, 108, 8..=11) => 3,
+        (91, 108, 12..=15) => 4,
+        (91, 105, 192..=193) => 203,
+        _ => 2,
+    })
+}
+
+/// Адреса дата-центров имеют вид `2001:b28:f23d:f002::a`, где `f00N` —
+/// номер DC. Для `2a0a:f280::/32` такого правила нет, и выдумывать его не
+/// нужно: номер придёт из init.
+fn dc_from_ipv6(ip: Ipv6Addr) -> Option<u16> {
+    if !in_v6(ip) {
+        return None;
+    }
+    let dc = ip.segments()[3].checked_sub(0xf000)?;
+    matches!(dc, 1..=5).then_some(dc)
+}
+
+fn in_v4(ip: Ipv4Addr) -> bool {
+    let value = u32::from(ip);
+    V4.iter().any(|&(network, prefix)| {
+        let mask = u32::MAX.checked_shl(32 - prefix).unwrap_or(0);
+        value & mask == u32::from(network) & mask
+    })
+}
+
+fn in_v6(ip: Ipv6Addr) -> bool {
+    let value = u128::from(ip);
+    V6.iter().any(|&(network, prefix)| {
+        let mask = u128::MAX.checked_shl(128 - prefix).unwrap_or(0);
+        value & mask == u128::from(network) & mask
+    })
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    fn ip(value: &str) -> IpAddr {
+        value.parse().unwrap()
+    }
+
+    #[test]
+    fn known_data_centre_addresses_are_telegram() {
+        for address in [
+            "149.154.175.50", // DC1
+            "149.154.167.51", // DC2
+            "149.154.175.100",
+            "149.154.167.91",
+            "91.108.56.130", // DC5
+            "91.105.192.100",
+            "185.76.151.1",
+        ] {
+            assert!(is_telegram(ip(address)), "{address} принадлежит Telegram");
+        }
+    }
+
+    /// Раньше сюда попадал весь `/16`, то есть десятки тысяч чужих адресов.
+    #[test]
+    fn neighbours_outside_the_published_blocks_are_not_telegram() {
+        for address in [
+            "149.154.159.255", // на один адрес ниже 149.154.160.0/20
+            "149.154.176.0",   // на один выше
+            "91.108.3.255",
+            "91.108.24.0",
+            "91.108.60.0",
+            "91.105.194.0",
+            "185.76.150.255",
+            "185.76.152.0",
+            "1.1.1.1",
+        ] {
+            assert!(!is_telegram(ip(address)), "{address} — не Telegram");
+        }
+    }
+
+    #[test]
+    fn block_edges_belong_to_the_block() {
+        for address in [
+            "149.154.160.0",
+            "149.154.175.255",
+            "91.108.4.0",
+            "91.108.7.255",
+            "185.76.151.0",
+            "185.76.151.255",
+        ] {
+            assert!(is_telegram(ip(address)), "{address} — край блока Telegram");
+        }
+    }
+
+    /// Из-за этого LAN-режим отклонял живой Telegram (by-sonic/tglock#42).
+    #[test]
+    fn ipv6_data_centres_are_telegram_too() {
+        for address in [
+            "2001:b28:f23d:f001::a",
+            "2001:67c:4e8:f002::a",
+            "2001:b28:f23d:f003::a",
+            "2001:67c:4e8:f004::a",
+            "2001:b28:f23f:f005::a",
+            "2001:b28:f23c::1",
+            "2a0a:f280:203:a::b",
+        ] {
+            assert!(is_telegram(ip(address)), "{address} принадлежит Telegram");
+        }
+        assert!(!is_telegram(ip("2606:4700:4700::1111")), "это Cloudflare");
+        assert!(!is_telegram(ip("2001:b28:f23e::1")), "соседний префикс");
+    }
+
+    #[test]
+    fn ipv4_mapped_form_is_the_same_address() {
+        assert!(is_telegram(ip("::ffff:149.154.167.51")));
+        assert!(!is_telegram(ip("::ffff:1.1.1.1")));
+    }
+
+    /// Поведение, на которое опирался предыдущий тест `dc_from_ip`.
+    #[test]
+    fn data_centre_guess_survives_the_stricter_membership_check() {
+        assert_eq!(dc_from_ip(ip("149.154.160.1")), Some(1));
+        assert_eq!(dc_from_ip(ip("149.154.167.255")), Some(2));
+        assert_eq!(dc_from_ip(ip("91.108.58.1")), Some(5));
+        assert_eq!(dc_from_ip(ip("1.1.1.1")), None);
+    }
+
+    #[test]
+    fn data_centre_guess_reads_the_number_out_of_an_ipv6_address() {
+        assert_eq!(dc_from_ip(ip("2001:67c:4e8:f002::a")), Some(2));
+        assert_eq!(dc_from_ip(ip("2001:b28:f23f:f005::a")), Some(5));
+        assert_eq!(
+            dc_from_ip(ip("2a0a:f280:203:a::b")),
+            None,
+            "для этого префикса правила нет — лучше признаться, чем выдумать"
+        );
+    }
+
+    #[test]
+    fn telegram_hosts_are_matched_on_label_boundaries() {
+        for host in [
+            "telegram.org",
+            "web.telegram.org",
+            "core.telegram.org",
+            "venus.web.telegram.org",
+            "t.me",
+            "TELEGRAM.ORG",
+            "telegram.org.", // корневая точка в имени законна
+            "cdn4.cdn-telegram.org",
+        ] {
+            assert!(is_telegram_host(host), "{host} — Telegram");
+        }
+    }
+
+    #[test]
+    fn lookalike_hosts_are_rejected() {
+        for host in [
+            "telegram.org.example.com",
+            "nottelegram.org",
+            "fakecdn-telegram.org",
+            "t.me.evil.net",
+            "example.com",
+            "",
+        ] {
+            assert!(!is_telegram_host(host), "{host} — не Telegram");
+        }
+    }
+}
@@ -1,7 +1,7 @@
 {
  "$schema": "https://schema.tauri.app/config/2",
  "productName": "TGLock",
-  "version": "2.0.0-beta.8",
+  "version": "2.0.0-beta.12",
  "identifier": "com.bysonic.tglock",
  "mainBinaryName": "tglock",
  "build": {
@@ -11,6 +11,10 @@ type Status = {
  route: string;
  failures: number;
  routeFailures: number;
+  /// Отклонено политикой «в LAN-режиме только Telegram».
+  blocked: number;
+  /// Клиенты, которые дошли, но не сумели договориться о рукопожатии.
+  unknownClients: number;
  uptimeSeconds: number;
  port: number;
  /// Адрес для других устройств. Приходит только в LAN-режиме.
@@ -41,6 +45,8 @@ let status: Status = {
  route: "Маршрут ещё не выбран",
  failures: 0,
  routeFailures: 0,
+  blocked: 0,
+  unknownClients: 0,
  uptimeSeconds: 0,
  port: 1080,
  shareAddress: null,
@@ -283,6 +289,14 @@ function renderDiagnostics(): void {
          <span>Падений маршрутов</span>
          <strong>${status.routeFailures}</strong>
        </article>
+        <article class="metric-card">
+          <span>Отклонено</span>
+          <strong>${status.blocked}</strong>
+        </article>
+        <article class="metric-card">
+          <span>Не опознаны</span>
+          <strong>${status.unknownClients}</strong>
+        </article>
      </div>

      <p class="field-hint">
@@ -291,6 +305,20 @@ function renderDiagnostics(): void {
        Число в багрепорте помогает понять, что именно перебиралось.
      </p>

+      <p class="field-hint">
+        «Отклонено» — запросы, которые LAN-режим не пропустил: он ходит только
+        по адресам Telegram. Если с телефона ничего не работает, а здесь ноль и
+        соединений тоже ноль, значит телефон до этого компьютера не дошёл —
+        дело в сети или брандмауэре. Какие именно адреса отклонены, видно ниже.
+      </p>
+
+      <p class="field-hint">
+        «Не опознаны» — клиенты, которые дошли до прокси, но договориться с ними
+        не удалось. Почти всегда это старая ссылка: секрет в Telegram остался от
+        прошлого запуска и больше не совпадает. Тогда Telegram пишет «прокси
+        настроен неверно», а адрес такого клиента появится в журнале ниже.
+      </p>
+
      <div class="log-panel">
        <div class="log-heading">
          <span>Последние события</span>
Author	SHA1	Message	Date
Никита Sonic	28085f9127	chore(release): 2.0.0-beta.12 (#52 ) Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-26 16:34:54 +03:00
Никита Sonic	923c22f9b4	fix(proxy): загрузка останавливала отправку, туннель шёл в одну сторону (#42 , #32 ) (#51 ) Оба направления туннеля обслуживал один `select!` с пометкой `biased`. `biased` опрашивает ветки строго по порядку: пока в первой — «Telegram → клиент» — есть данные, до второй очередь не доходит вообще. При непрерывном потоке вниз, то есть при первичной синхронизации телефона или загрузке медиа, исходящие пакеты клиента не читались. Второй дефект в том же цикле: одна задача на оба направления. `tcp_w.write_all` ждёт, пока клиент разберёт присланное, и всё это время не опрашивается чтение от клиента. Телефон по Wi-Fi разбирает поток медленнее, чем Telegram Desktop на той же машине через loopback, — отсюда асимметрия «на компьютере работает, на телефоне нет». Для MTProto это фатально: клиент обязан слать подтверждения, а за каждым следующим куском файла — свой `upload.getFile`. Первый запрос уходит, дальше идёт поток вниз, и следующие запросы наверх не попадают. Снаружи это выглядит как «Подключено» при живом туннеле, нулевых сбоях и нулевых отклонениях: чаты на месте, иконки не грузятся, отправка виснет с часиками. Направления разделены на две независимые половины: `ws.split()` плюс `CryptoContext::split()`, потому что шифры направлений независимы — два потока AES-CTR со своими ключами. Ping приходит в читающую половину, а отвечает на него пишущая, через канал на четыре слота: владелец отправляющей половины должен оставаться ровно один. Два теста, падающие на beta.11: за пять секунд непрерывной загрузки наверх не уходит ни одного байта, и клиент, не успевающий читать, замораживает собственную отправку. Снятие одного `biased` чинит только первый — это и показывает, что дефекта два. Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-26 16:28:43 +03:00
Никита Sonic	8ce3c368a3	chore(release): 2.0.0-beta.11 (#48 ) Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-19 15:04:34 +03:00
Никита Sonic	0dc6b7bf3e	fix(proxy): DC и маршрут в строке статуса были из разных соединений (#47 ) В диагностике из #42 встречаются строки вида соединений 9 · туннелей 9 · DC5 · Запасной Telegram IP · сбоев 12 Такого сочетания не бывает: у DC1, DC3, DC5 и DC203 закреплённый адрес ровно один, и маршрута «запасной адрес» у них не существует в принципе. Значит номер и маршрут пришли из разных соединений. Так и было. `last_dc` писало соединение при разборе init, `last_route` — другое соединение после рукопожатия, двумя независимыми атомиками. У репортёра от пяти до двадцати шести одновременных соединений, поэтому пара складывалась случайно. Читается она как «до этого DC шли этим маршрутом» и в этом качестве врала — ровно тот класс дефектов, ради которого затевалась честная диагностика в #38. Теперь пара пишется одним значением в момент, когда туннель поднялся: `dc << 8 \| route`. Пока туннеля не было, показывается разобранный DC и «маршрут ещё не выбран» — это состояние тоже настоящее и его терять не надо. Поля стали приватными, наружу выведены `last_dc()` и `last_route()`, чтобы рассогласовать их снаружи было нельзя. Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-19 14:59:34 +03:00
Никита Sonic	fe9ab39abe	chore(release): 2.0.0-beta.10 (#46 ) Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-19 14:37:05 +03:00
Никита Sonic	b92403b4c9	fix(proxy): клиент, с которым не договорились, закрывался молча (#42 ) (#45 ) Диагностика от @alexsagaidak в #42 показала третий случай, которого ни один счётчик не различал. У него ноль отклонённых и живые туннели, то есть оба показателя говорят «всё хорошо»: соединений 17 · туннелей 6 · DC4 · Запасной Telegram IP · сбоев 0 · падений маршрутов 26 · отклонено 0 Клиент, который дошёл до прокси, но не сумел договориться, не попадал ни в blocked, ни в ws_failures. Ошибка из handle() выбрасывалась в `let _ =`, соединение закрывалось, и наружу это выглядело как active, дёрнувшийся вверх и обратно. По диагностике неотличимо от клиента, который подключился и работает. Теперь такие клиенты считает unknown_clients, а журнал называет адрес и причину. Причин две: MTProto-init не разбирается под текущим секретом. Почти всегда это ссылка tg://proxy от прошлого запуска: секрет — её половина, и клиент с сохранённой старой ссылкой попадает ровно сюда. Со стороны Telegram это и есть «прокси настроен неверно и будет отключён» — то, с чем пришли в #37 и что до сих пор нельзя было подтвердить со стороны прокси. SOCKS5-приветствие не разбирается. Сюда же попадает MTProto-соединение, ушедшее в SOCKS5-ветку по неоднозначному первому байту, если полный init не успел прийти за PROTOCOL_PROBE_TIMEOUT. На loopback этого не бывает, а через Wi-Fi с телефона — уже вопрос задержки. От ws_failures отличается тем, что тот растёт после успешного рукопожатия с клиентом: там договорились с клиентом, но не смогли с Telegram. Различать их важно, иначе непонятно, в какую сторону смотреть. В интерфейсе — метрика «Не опознаны» с пояснением, в строке статуса CLI — поле «не опознано N». Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-19 14:32:34 +03:00
Никита Sonic	41e8040e59	chore(release): 2.0.0-beta.9 (#44 ) Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-19 09:12:23 +03:00
Никита Sonic	945e794eb3	fix(proxy): LAN-режим отклонял настоящие адреса Telegram (#42 ) (#43 ) @alexsagaidak: с компьютера прокси работает, с телефона — нет. Адрес машины вписан верно, порт верный, брандмауэр выключен, порт добавлен в исключения. Причина нашлась в проверке «это Telegram?». Она сравнивала два первых октета: (149, 154) => Some(...) (91, 108) => Some(...) То есть «телеграмом» считались целиком четыре /16 — десятки тысяч чужих адресов, — а IPv6 не распознавался вообще ни один. Telegram владеет 149.154.160.0/20, шестью /22 в 91.108, 91.105.192.0/23, 185.76.151.0/24 и пятью блоками IPv6. Ошибка в обе стороны, и на loopback она не видна. Там allow_direct включён, и неопознанный адрес всё равно релеится напрямую — соединение просто работает. На сетевом слушателе allow_direct выключен, и тот же адрес получает SOCKS5 0x02. Отсюда ровно то, что описал репортёр: на компьютере работает, с телефона нет. Заодно чужие адреса внутри этих /16 уходили в MTProto-туннель и умирали там. Список сетей теперь опубликованный самим Telegram (core.telegram.org/resources/cidr.txt), проверка по маске префикса, IPv4 и IPv6, с тестами на края блоков и на соседей за границей. Отдельно разрешены имена веб-инфраструктуры: telegram.org, t.me, telegram.me, telesco.pe, cdn-telegram.org. Это не MTProto, а обычный HTTPS — клиент ходит туда за конфигурацией, превью и файлами CDN, и на телефоне эти запросы идут через тот же прокси. Заворачивать их в туннель нельзя, поэтому они идут прямым релеем. Совпадение по границе метки, так что telegram.org.example.com — посторонний домен. В ограниченном режиме имя разрешается заранее и адреса внутри локальной сети отбрасываются: назначение выбирает чужое устройство, и DNS-ответ не должен открывать доступ к 192.168.х этой машины. И главное для разбора следующего такого случая: отказ перестал быть молчаливым. Появился счётчик «Отклонено» в диагностике и в строке статуса CLI, отклонённый адрес один раз называется в журнале, и отдельно отмечается первое подключение с каждого сетевого адреса. Без этого «с телефона не работает» неразличимо распадалось на два случая: телефон не дошёл до машины — и дошёл, но попросил адрес, который мы не пускаем. Теперь первый виден как ноль соединений и ноль отказов, второй — как соединения есть, отказы растут. Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-19 09:07:50 +03:00
Никита Sonic	60264ff177	ci: страж тега на HEAD и записанный порядок выпуска (#41 ) Первый заход v2.0.0-beta.8 собрался на всех трёх платформах и упал на публикации с «Resource not accessible by integration». Сообщение про права уводит не туда: права были ровно те же, что у beta.7 (Contents: write), tauri-action тот же коммит, правил на теги нет. Настоящая причина — положение тега. Токен Actions создаёт релиз только на HEAD ветки по умолчанию. Тег поставили на chore(release), следом дописали коммит в main, и к моменту вызова API тег отстал на один коммит. Задача guard сверяет тег с HEAD и валится за секунды до сборок, вместо загадочного 403 через восемь минут. Она ловит тег на старом коммите, но не ловит гонку «запушили в main во время сборки» — то есть ровно тот случай, который и произошёл. Поэтому главная защита не в ней, а в порядке действий, записанном в docs/RELEASING.md: тег ставится последним, во время релиза в main не пушим. Логика стража прогнана на обеих ветках на реальных SHA этого репозитория. Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>	2026-08-10 22:29:54 +03:00