Всё начинается
с подключения.

запуск Windows с правами администратора

При запуске Windows-клиент запрашивает права администратора до открытия интерфейса. При отмене UAC приложение завершает запуск. Фоновые команды Windows запускаются без консольного окна; PowerShell дополнительно получает явный режим скрытого окна. Подписи настроек больше не появляются отдельными маленькими окнами KaproTUN поверх заставки при запуске. При выходе меню и значок трея скрываются до ожидания фоновых задач. Исправлена упаковка Windows-сборки: сторонняя icuuc.dll из PATH сборочной машины больше не подменяет системную библиотеку и не ломает загрузку QtCore.

Подробности v4.2.1 →

новая заставка, установщик и окно обновления

Три окна, которые видно до и вокруг основного, переделаны в том же виде, что и сам клиент. Windows; заставка — на всех системах.

Подробности v4.2.0 →

системные команды по полному пути, конфигурация движка под защитой

Остаток пункта аудита про запуск с правами администратора. Только Windows; интерфейс и поведение не меняются.

Подробности v4.1.7 →

macOS: системный прокси возвращается как был; сборка проверяет сама себя

Остаток аудита по macOS и проверка собранного приложения на настоящих Mac.

Подробности v4.1.6 →

подключение на macOS

Одно исправление по жалобе с Intel Mac.

Подробности v4.1.5 →

главный экран на низких дисплеях

Одно исправление вёрстки.

Подробности v4.1.4 →

установщик больше не зависит от одного GitHub

Исправление по жалобе пользователя и одна мелочь в английском интерфейсе.

Подробности v4.1.3 →

надёжность: чужие VPN, смена сети, выбор сервера

Три исправления из аудита. Интерфейс не меняется.

Подробности v4.1.2 →

запускается только то, что проверено

Три исправления из аудита и одно по жалобе на подключение. Интерфейс не меняется.

Подробности v4.1.1 →

новый интерфейс

Интерфейс переписан целиком. Подключение, маршрутизация и защита работают так же, как в 4.0.2: изменилось то, как это выглядит и где находится.

Подробности v4.1.0 →

macOS: полный VPN (TUN) снова запускается

macOS: исправлен запуск в режиме TUN. При запуске с правами администратора («Полный VPN (TUN)») подключение падало с ошибкой configure tun interface: bad tun name: KaproTun. В macOS сетевое TUN-устройство может называться только utunN, и движок отказывался создавать устройство с нашим именем. Теперь имя выбирает система. Ошибку нашёл и исправление предложил Enzzo657 (#13, #14); он же проверил его на Mac с Apple Silicon. Счётчик трафика и сетевая диагностика на macOS находят туннель по его адресу, а не по имени. Режим прокси на macOS (без пароля администратора) эта ошибка не затрагивала. Для Windows и Linux изменений нет: конфигурация движка та же, что в 4.0.1. Запуск туннеля без заданного имени проверен на реальном Mac автором исправления. Счётчик трафика и диагностика на Mac проверены только автотестами. Если TUN на macOS всё ещё не поднимается, напиши в Issues.

Подробности v4.0.2 →

подписка не может подменить чужой сервер

Четыре исправления безопасности из аудита. Обычное подключение не меняется.

Подробности v4.0.1 →

kill-switch, который действительно держит

Версия 4.0, потому что меняется поведение kill-switch: с ним раздельная маршрутизация на время сессии выключается (подробности ниже). У тех, кто kill-switch не включал, маршрутизация остаётся прежней.

Подробности v4.0.0 →

macOS: установка одной командой и памятка в образе

macOS: установка без окна «Apple не удалось подтвердить…». У приложения нет платной подписи Apple, поэтому macOS блокирует DMG, скачанный браузером. Теперь его можно поставить одной командой в Терминале, без предупреждения и без пароля: curl -fsSL https://raw.githubusercontent.com/fafnirov/KaproTUN/main/packaging/install-macos.sh | bash Команда сама выбирает версию под твой Mac (Intel или Apple Silicon), сверяет контрольную сумму файла с GitHub, устанавливает приложение и открывает его. В образе DMG теперь лежит памятка «Не открывается? Прочти.txt» с обоими способами: командой и вручную через «Системные настройки» → «Конфиденциальность и безопасность» → «Всё равно открыть». Исправлена инструкция в README: совет «правый клик → Открыть» на macOS 15 больше не работает. Для Windows и Linux в этой версии изменений нет.

Подробности v3.8.3 →

версия для Mac на Intel

Появилась сборка для Mac с процессором Intel: KaproTUN-macOS-x64.dmg. До сих пор выходила только версия для Apple Silicon (M1 и новее), а на Intel-маках она не запускается вообще. Теперь в каждом релизе два DMG: arm64 для Apple Silicon и x64 для Intel. Как понять, какой нужен. Меню Apple → «Об этом Mac». Если в строке «Процессор» указан Intel, бери x64. Если указан чип Apple (M1, M2, M3, M4), бери arm64. В версии для Intel всё то же самое, включая подключение без пароля администратора (режим прокси из v3.8.0). Уточнено требование к системе: обе версии для Mac работают на macOS 13 и новее. Раньше в описании значилось «12+», это было неточно. Сборка для Intel пока не проверена на реальном Mac: она собирается и проходит проверку архитектуры в CI. Если что-то не так, напиши в Issues. Если macOS не даёт открыть приложение («Apple не удалось подтвердить, что KaproTUN не содержит вредоносного…

Подробности v3.8.2 →

macOS без пароля администратора, быстрый DNS на Windows

Версии 3.7.6 и 3.8.0 не были опубликованы: их сборку остановила ошибка в автоматическом тесте (он проверял поведение Windows, а запускался на Linux). Сам код от этого не менялся. Этот релиз включает всё, что в них вошло:

Подробности v3.8.1 →

на macOS больше не нужен пароль администратора

macOS: клиент подключается без запроса прав администратора. Раньше на Mac приходилось при каждом запуске перезапускать клиент «от админа» и вводить пароль: туннельный интерфейс без root там создать нельзя. Теперь по умолчанию работает режим прокси. Движок запускается от обычного пользователя, клиент сам включает системный прокси macOS, пароль не спрашивается. Что идёт через VPN в этом режиме. Браузеры и приложения, которые используют системный прокси. Игры, UDP и программы, игнорирующие прокси, идут мимо VPN. Разделение трафика то же, что и раньше: российские адреса и твой список прямых сайтов идут напрямую, остальное через VPN. Чего в режиме прокси нет. Kill-switch и блокировки WebRTC: это правила firewall, им нужны права администратора. Браузер может раскрыть настоящий IP через WebRTC, это описано в SECURITY.md. Полный VPN остался. В настройках есть кнопка «Полный VPN (TUN)»: она…

Подробности v3.8.0 →

под VPN каждое новое доменное имя резолвилось 5 секунд

Исправлена 5-секундная задержка DNS на Windows. При включённом VPN первое обращение к любому новому домену занимало ровно пять секунд. Сайты открывались с паузой, а программы с коротким таймаутом просто падали: клиент League of Legends показывал «Возникла непредвиденная ошибка», Vanguard зависал на «Запускается сессия» и выдавал VAN 68. Причина — петля. DNS-модуль движка обращался к системному резолверу Windows, а тот первым делом спрашивал DNS самого туннеля, то есть возвращал запрос обратно в движок. Через пять секунд Windows сдавалась и спрашивала настоящий DNS сети. Замер на живом подключении: DNS сети отвечал за 135–207 мс, тот же запрос через туннель занимал 5000–5200 мс. Теперь клиент при подключении сам определяет DNS-сервер сети и обращается к нему напрямую, минуя петлю. Резолвер остаётся тем же, что и раньше, видимость запросов для провайдера не изменилась. После исправления…

Подробности v3.7.6 →

защита от WebRTC-утечки снова работает, и клиент честно говорит, если защита не встала

Защита от утечки через WebRTC не работала с v3.1.0 — теперь работает. Настройка включена по умолчанию, подсказка в настройках и документ о безопасности описывали блокировку STUN-портов — но само правило firewall с версии 3.1.0 не устанавливалось вообще: вызов потерялся при удалении старых движков. Проверено на живой машине: клиент подключён, настройка включена, правила нет. Теперь оно ставится при каждом подключении. Зачем она нужна при полном туннеле. Российские адреса идут напрямую, мимо VPN. Поэтому скрипт на любом зарубежном сайте мог обратиться к STUN-серверу на российском адресе и узнать твой настоящий IP. Правило закрывает эту дыру. Заодно закрыт порт 19309. Диапазон блокировки заканчивался на 19308, хотя в коде он был описан до 19309, — одна дыра на ровном месте. ⚠ Возможное изменение поведения: раз блокировка снова работает, видеозвонки в браузере (Google Meet, Discord в…

Подробности v3.7.5 →

обход VPN для игр наконец покрывает реальные сети Riot и Valve

Фризы в League of Legends: найдена настоящая причина. В v3.5.0 игровой трафик стали выводить мимо туннеля, и это работало — но список игровых сетей оказался выборкой, а не полным перечнем. Мы исключали 104.160.128.0/22, тогда как Riot держит 104.160.128.0/19: то есть семь восьмых этого блока всё равно шли через туннель. Целиком отсутствовал диапазон 151.106.246-254 — это европейские серверы, ровно те, на которые попадает игрок из России. Из пятнадцати сетей Riot покрывались три. Поэтому фризило через раз. Всё зависело от того, на какой сервер попал матч: попал в исключённую сеть — игра шла нормально, попал в любую другую — трафик уходил в туннель и получал задержку. Это объясняет, почему проблема выглядела плавающей и почему предыдущие исправления помогали лишь отчасти. Список пересобран по фактическим анонсам Riot (AS6507) и Valve (AS32590) и сокращён до минимального набора: 17 сетей…

Подробности v3.7.4 →

клиент проверяет, что скачал именно то, что мы выложили

Каждый скачиваемый файл теперь сверяется по контрольной сумме. Движок sing-box, драйвер WinTUN и сам установщик обновлений — всё это либо запускается, либо загружается в сетевой стек, и приходит с зеркала. Раньше клиент доверял тому, что соединение защищено, и не проверял сами байты. HTTPS подтверждает, что мы достучались до нужного хоста, но ничего не говорит о том, те ли это файлы, что мы публиковали. Теперь говорит. Файл, не прошедший проверку, удаляется и не используется. Он не остаётся на диске даже частично, а причина отказа пишется в лог. Если зеркало отдало не то — клиент молча возьмёт файл с GitHub, но в логе останется запись, что зеркало отклонено. Ожидаемые суммы движка и драйвера зашиты в код рядом с версией, к которой относятся, и не требуют обращения к сети. Это важно: зеркало существует для тех, у кого GitHub недоступен, поэтому проверка, которой пришлось бы спрашивать…

Подробности v3.7.3 →

гонка при подключении из трея и утечка памяти в меню

Подключение из трея больше не может стартовать поверх уже идущего. Защита от повторного нажатия стояла только на кнопке в окне, а выбор сервера в меню трея шёл мимо неё — можно было запустить второе подключение поверх первого, и два потока начинали делить одни и те же маршруты и сокеты. Теперь проверка стоит в самой процедуре подключения, через которую проходят все способы его запустить. Устранена утечка памяти в меню трея. Пункты быстрого подключения пересобираются на каждый результат пинга, но старые при этом только убирались из меню, а сами оставались в памяти. За долгую сессию с большим списком серверов их накапливались сотни. Теперь удаляются по-настоящему. Поправлен комментарий в коде, съехавший не к той настройке при правке v3.7.0. На поведение не влияет.

Подробности v3.7.2 →

одна битая строка больше не роняет всю подписку

Импорт подписки перестал падать целиком из-за одной плохой записи. Если провайдер отдавал в списке хотя бы один сервер с нечисловым портом, импортировалось ноль серверов — падал весь разбор, а не одна строка. Причина тонкая: внутренний класс ошибок парсера наследует стандартный ValueError, поэтому обработчик, ловивший «свою» ошибку, пропускал мимо себя чужую того же рода. Теперь каждый из пяти протоколов (vless, trojan, vmess, shadowsocks, hysteria2) сообщает об ошибке единообразно, битая строка попадает в список ошибок импорта, а остальные серверы добавляются как ни в чём не бывало. Настройка «Русские сайты напрямую» наконец доехала до тех, кто обновлялся. В v3.3.0 она стала включённой по умолчанию — это был главный фикс того релиза. Но клиент записывает на диск все настройки целиком, включая те, что пользователь не трогал, поэтому у всех, кто ставил версии до v3.3.0, на диске осталось…

Подробности v3.7.1 →

клиент представляется устройством, как того ждут современные панели

Добавлена идентификация устройства при запросе подписки. Панели вроде Remnawave ждут, что клиент сообщит, с какого устройства пришёл запрос (x-hwid и сопутствующие заголовки). Без этого они возвращают заглушку «Приложение не поддерживается» вместо серверов — именно поэтому часть подписок не импортировалась. Теперь клиент говорит на этом протоколе. Ошибка стала точной. Проверено на живой подписке: без заголовков панель отвечала «Приложение не поддерживается», с ними — «Лимит устройств достигнут». То есть настоящей причиной был исчерпанный лимит устройств, а не неподдерживаемый клиент. Теперь в окне импорта видно именно это, вместе со ссылкой на личный кабинет, где лимит сбрасывается. Идентификатор — случайный UUID, созданный один раз и сохранённый в настройках. Он не выводится из железа и ничего не рассказывает о машине, но и не меняется от запроса к запросу: несколько твоих запусков…

Подробности v3.7.0 →

журнал больше не умирает молча + честная документация

Исправлено логирование, которое отключалось навсегда. Достаточно было одного мгновения, когда файл журнала занят (второй экземпляр приложения, открытый редактор) — и запись отключалась до конца работы программы. В реальности так и вышло: app.log не писался десять дней, пока клиент работал и даже падал, из-за чего последующие проблемы приходилось искать вслепую. Теперь: неудачная инициализация повторяется, сорванная ротация не убивает журнал (пусть файл лучше вырастет, чем записи пропадут), а если основной файл занят — пишем в запасной рядом. Документация приведена в соответствие с тем, что делает программа. SECURITY.md описывал давно удалённый движок и, что важнее, ошибался в приватности: утверждал, будто трафик к российским адресам идёт через туннель. На самом деле он идёт напрямую, и по умолчанию — как и игровой трафик, и DNS-запросы. Теперь в начале файла таблица «что покидает…

Подробности v3.6.1 →

игры реально мимо туннеля, новый формат подписок, приватный режим

Игровые сети теперь исключаются из туннеля на уровне маршрутов. Прежний обход по процессам менял только то, куда уйдёт пакет, но не то, через что он пройдёт: трафик всё равно шёл через виртуальный адаптер и пользовательский сетевой стек, и платил за это задержкой. Замер на живой сессии показал, что даже трафик с правилом «напрямую» двигал счётчики TUN-интерфейса. Теперь Windows вообще не отправляет игровые адреса (Riot Direct, Valve/Steam) в туннель — путь пакетов такой же, как при выключенном клиенте.

Подробности v3.6.0 →

сетевая диагностика, свои приложения мимо VPN, режим отладки

Экран «Сетевая диагностика» (Настройки → Сетевая диагностика). Один снимок вместо десятка команд в PowerShell: физический адаптер (IP, шлюз, метрика, MTU), TUN-адаптер (IP, MTU, стек), маршруты по умолчанию, маршрут до VPN-сервера, статус и версия движка, и тесты канала — TCP, UDP и задержка через прокси. Результат копируется одной кнопкой. Почему тесты, а не ping. Задокументировано прямо в отчёте: ping и tracert при включённом VPN недостоверны — пользовательский стек (gVisor) отвечает на ICMP локально (<1 мс, TTL=64), не отправляя пакет наружу. Это нормальное поведение стека, а не подмена трафика. Реальный путь данных меряют тесты TCP/UDP — UDP-тест особенно важен для игр. Свои приложения мимо VPN (Настройки → Приложения мимо VPN). Добавляешь .exe — и приложение ходит в интернет напрямую. Это тот же механизм, что и встроенный обход для игр (правило по имени процесса), а не отдельный…

Подробности v3.5.2 →

фикс фризов 5–8 с в играх: клиент больше не рвёт живой туннель

Причина найдена: мы сами обрывали соединение. Сторож здоровья считал любую неудачу своей проверки смертью туннеля и «лечил» это полным переподключением — остановка sing-box, снос TUN и маршрутов, повторный запуск. Всё это время сети нет вообще: в игре команды не проходят 5–8 секунд, при этом FPS цел и ping в интерфейсе выглядит нормальным. В логах зафиксировано 32 таких самопроизвольных «лечения». Почему проверка ошибалась: под нагрузкой (игра насыщает пользовательский сетевой стек) её HTTP/DNS-пробы с таймаутом 2.5 с просто не успевали ответить. Она мерила не туннель, а загрузку процессора. Что теперь: вердикт стал трёхзначным — «жив» / «деградация» / «мёртв». Если пробы не проходят, но через туннель реально идут байты (счётчики TUN-интерфейса), это «деградация»: пишем в лог и ничего не рвём. Переподключение — только при доказанной смерти: движок упал или трафика нет. Пробы стали мягче…

Подробности v3.5.1 →

игры Steam и Riot идут мимо VPN

Новая галочка в Настройках: «🎮 Игры Steam и Riot — мимо VPN» (включена по умолчанию). Игры не блокируются по региону, а туннель добавляет им только пинг и джиттер — в матче это чувствуется. Теперь их трафик идёт напрямую. Ловим по процессу, а не по доменам. Это принципиально: игровой трафик — это UDP на голые IP (релеи Valve SDR, Riot Direct), никакого DNS в этот момент нет, поэтому доменные правила его в упор не видят. Клиент определяет игры по имени процесса (Steam, Riot Client, League of Legends, VALORANT) и по пути установки (…/steamapps/common/…, …/Riot Games/…) — последнее покрывает все установленные игры Steam, не перечисляя каждую по имени. Магазин, авторизация и загрузка патчей тоже идут напрямую — качается на полной скорости канала, а не через прокси. Правила намеренно стоят до блокировки QUIC: игры, говорящие по UDP/443, иначе отбрасывались бы раньше, чем успевали уйти…

Подробности v3.5.0 →

WhatsApp: обход подмены DNS (настоящая причина ERRCONNECTIONCLOSED)

Найдена настоящая причина. v3.4.2 (принудительный проксинг доменов) не помог, потому что проблема была не в маршрутизации, а в DNS: системный резолвер отдавал для web.whatsapp.com фальшивый адрес (fdfe:dcba:9876::2 — служебный ULA-диапазон, классическая подпись подмены DNS от РКН). Браузер получал отравленный адрес ещё до маршрутизации и соединялся в пустоту → ERRCONNECTIONCLOSED, сколько ни форсируй туннель. Фикс: заблокированные домены (WhatsApp, Meta, YouTube, OpenAI) теперь резолвятся через туннель — DoH-резолвер, поднятый поверх VPN-соединения, отвечает настоящими адресами, минуя подмену. Весь остальной трафик по-прежнему использует быстрый системный DNS: это НЕ возврат прямого DoH из v3.1.1 (тот резался DPI на физическом интерфейсе и ломал подключение) — новый идёт внутри уже поднятого туннеля, где DPI его не видит. Схема конфига проверена реальным sing-box check на движке 1.12.9.

Подробности v3.4.3 →

WhatsApp/Meta принудительно через VPN (фикс ERRCONNECTIONCLOSED)

WhatsApp снова открывается. web.whatsapp.com падал с ERRCONNECTIONCLOSED — это TLS-SNI reset от DPI РКН (WhatsApp/Meta режут в РФ). У Meta есть edge-узлы, чьи IP попадают в geoip:ru, поэтому правило «российский IP → напрямую» выкидывало WhatsApp мимо туннеля прямо в блокировку. Теперь WhatsApp и семейство Meta (Facebook, Instagram, whatsapp.net/fbcdn.net и т.п.) принудительно идут через VPN — как YouTube и OpenAI, — где SNI зашифрован и DPI их не видит. Если WhatsApp всё ещё не грузится — убедись, что VPN включён: при выключенном клиенте трафик идёт напрямую, и никакой список маршрутизации не поможет против блокировки.

Подробности v3.4.2 →

фикс краша «пингую сервер → переключаюсь → вылет»

Больше не крашит при пинге + смене сервера. Если запустить проверку серверов (пинг) и, не дожидаясь, переключиться на другой сервер, приложение вылетало целиком. Причина — нативный сбой Qt: пингующий поток ещё работал (TCP-проверки до 3 с каждая), а окно-владелец уже уничтожалось → Qt аварийно завершал процесс (QThread: Destroyed while thread is still running). Поэтому в логах ничего и не было — это не Python-исключение, а abort на уровне C++. Теперь окно пикера корректно останавливает и дожидается свои фоновые потоки перед закрытием, а сами пинги стали прерываемыми (реагируют на отмену за доли секунды). Чистое завершение приложения. При выходе все фоновые потоки (пинг, проба IP, подключение, проверка обновлений) теперь останавливаются и join-ятся — тот же класс вылета «выкидывает из приложения» на закрытии устранён.

Подробности v3.4.1 →

авто-переподключение при смене сети (Ethernet ↔ Wi-Fi)

Роуминг Ethernet↔Wi-Fi больше не ломает туннель. Раньше, если отключить кабель и перейти на Wi-Fi (или наоборот), sing-box оставался привязан к интерфейсу, который был активен при подключении: Wi-Fi «работал как без VPN» (трафик уходил напрямую мимо туннеля), а ручной реконнект на устаревшей таблице маршрутов часто заканчивался «нет сети». Теперь клиент замечает смену сетевого интерфейса и сам делает чистое переподключение на новом — туннель восстанавливается за несколько секунд, без ручных действий. Как это работает: дешёвый и точный сигнал — локальный source-IP до сервера (UDP-проба ничего не отправляет, без прав администратора). Смена интерфейса = смена этого IP → чистый reconnect по проверенной crash-механике. Кратковременные «моргания» сети (DHCP) отфильтровываются (нужно ~10 с устойчивой смены).

Подробности v3.4.0 →

«Позже» в апдейтере наконец означает «позже»

Отмена обновления реально отменяет. Раньше, если закрыть окно обновления (Esc / крестик) во время скачивания, загрузка продолжалась в фоне — и по завершении клиент молча запускал инсталлятор и выключался, обрывая активный VPN-туннель вопреки явному отказу. Теперь любое «нет» (кнопка «Позже», Esc, крестик) немедленно прерывает загрузку, недокачанный файл удаляется, а инсталлятор не запускается никогда. Кнопка «Позже» больше не блокируется во время скачивания — это штатный способ передумать на полпути.

Подробности v3.3.7 →

вернул фирменный оранжевый на кольцо (откат зелёного из v3.3.5)

Зелёное «подключено» из v3.3.5 не прижилось — кольцо, свечение и статус снова фирменного оранжевого цвета, как раньше. Убрано и «дыхание» ореола. Живой график трафика из v3.3.5 остаётся — сглаженная кривая с градиентной заливкой и маркером пика (на него жалоб не было).

Подробности v3.3.6 →

состояние читается цветом + живой график трафика

Состояние — цветом. Большое кольцо, его свечение и строка статуса теперь меняют цвет по состоянию: подключение — янтарный пульс (бренд, «идёт работа»), подключено — зелёный с мягким «дыханием» ореола («ты под защитой»), ошибка/kill-switch — красный. Раньше всё было оранжевым, и «Отключить» читалось как предупреждение — теперь состояние понятно с одного взгляда, без чтения текста. График трафика живее. Вместо бледной ломаной — сглаженная кривая (сплайн) с градиентной заливкой области ↓/↑ и маркером пика на максимуме загрузки. Скачок скорости читается как светящийся всплеск, а не тонкая линия.

Подробности v3.3.5 →

«Ваш IP» для серверов с IPv6-выходом (настоящий фикс Trojan)

Точная причина «Ваш IP: —» на Trojan (по живой диагностике туннеля). Проба доходила до эндпоинта и получала HTTP 200 — но твой сервер выходит в интернет по IPv6 (2a01:ecc0:…), а проба отбрасывала любой IPv6 как «утечку» и возвращала пусто. Отбраковка была правильной только для одного случая — не показать реальный IPv6 пользователя. Но когда запрос идёт через прокси (а он всегда пришпилен к outbound=proxy и физически проходит через туннель), IPv6 в ответе — это адрес сервера на выходе, а не твой. Теперь IPv6 принимается на прокси-пути (показывается как есть) и по-прежнему отбраковывается на прямом (там он мог бы быть утечкой). v3.3.3 (терпеливый прогрев) был мимо — причина оказалась в IPv6. Побочно: для такого сервера в «Ваш IP» отображается настоящая страна выхода (напр. Германия для NL-конфига, если сервер выходит через немецкий ЦОД), а не догадка по флагу конфига.

Подробности v3.3.4 →

Trojan снова показывает «Ваш IP» (проба стала терпеливой к прогреву)

Фикс «на Trojan не определяется IP». После подключения клиент спрашивает внешний IP через туннель, чтобы показать «Ваш IP: … · Нидерланды». Проба делала одну попытку с таймаутом 2 с — а холодный Trojan-туннель (он гонит этот HTTPS-запрос внутри своего внешнего TLS, TLS-в-TLS, тяжелее чем VLESS-REALITY) за 2 с ответить не успевал, и в UI висело «Ваш IP: —», хотя трафик уже шёл. Теперь окно прогрева ~12 с (4 попытки по 3 с с паузами) — ровно как обещал комментарий в коде, но чего сам вызов не делал. Тёплый туннель по-прежнему отвечает меньше чем за секунду. Резервный эндпоинт пробы. Раньше был единственный источник (cloudflare.com/cdn-cgi/trace) — один сбой и IP не определялся. Проба идёт через прокси (имя резолвится на стороне сервера), поэтому старые причины оставить один эндпоинт (блокировки AdGuard, geoip-direct) больше не действуют — добавлен api.myip.com как запасной.

Подробности v3.3.3 →

иностранные сайты не отваливаются со временем + читаемые логи

Фикс «РФ работает, а иностранное со временем перестаёт грузиться». Причина — QUIC/HTTP-3: браузер грузит зарубежный сайт по TCP, а через несколько минут (через Alt-Svc) переносит соединения на QUIC (UDP :443), который пользовательский gvisor-стек не тянет через VLESS/Trojan — пакеты начинают теряться, сайт виснет. РФ-сайты идут напрямую и не затронуты, поэтому «половина интернета есть, половины нет». Теперь на обычном стеке туннелируемый QUIC отклоняется (как уже отклоняется IPv6), и браузер мгновенно откатывается на надёжный TCP (HTTP/2). LAN и РФ-трафик не затрагиваются; на Турбо-режиме (kernel-стек, который UDP тянет нормально) QUIC остаётся включённым. Починка авто-переподключения. Раньше при обрыве отрабатывала только первая попытка из трёх: после неё таймер не перевзводился, backoff 1/5/15 с сворачивался в одну попытку, и клиент тихо падал в «Отключено», хотя тост обещал «#1/3».…

Подробности v3.3.2 →

предупреждение о приложениях, перехватывающих сеть

«Подключено, но интернета нет» — теперь клиент подскажет, кто виноват. Некоторые сторонние приложения ставят собственный сетевой драйвер / виртуальный адаптер / пакетный фильтр и перехватывают трафик ещё до того, как он доходит до нашего TUN. Итог выглядит как наша поломка: статус «Подключено», но ни один сайт не грузится и внешний IP не определяется — хотя VPN тут ни при чём. Пользовательский VPN не может перебить чужой сетевой драйвер, поэтому при подключении клиент теперь проверяет запущенные процессы и, если находит такой конфликт, показывает предупреждение с именем приложения — чтобы не искать несуществующий баг VPN часами. Первым в списке известных «нарушителей» — Meta Horizon Link / Oculus (VR) (по реальной жалобе: приложение Meta ломало весь интернет, пока KaproTUN был подключён). Список легко расширяется.

Подробности v3.3.1 →

российские сайты напрямую по умолчанию + Турбо-режим скорости

Российские сайты грузятся снова: РФ-IP теперь идёт мимо VPN по умолчанию. Раньше напрямую шёл только встроенный список из ~170 доменов, а все прочие российские сайты туннелировались через заграничный сервер и упирались в гео-блокировку по иностранному IP. Теперь модель простая: российский IP (geoip:ru) → твой реальный IP, любой другой → VPN. Встроенный список доменов оставлен — он дополнительно ловит РФ-сайты на зарубежных CDN (банки), которые по IP не распознать. Критичные к загранице сервисы (YouTube, OpenAI и т.п.) по-прежнему принудительно идут через VPN. Выключить широкий обход можно в Настройках (для edge-кейса с Telegram/CDN). ⚠️ Работает при наличии скачанной geoip:ru-базы (качается при первом запуске). ⚡ Турбо-режим (Настройки). Переключает VPN на kernel-стек сети — ощутимо выше скорость (ближе к нативной). По умолчанию выключен, потому что на части Windows-ПК…

Подробности v3.3.0 →

фикс падения приложения «через 5-7 минут»

Баг: приложение исчезало через несколько минут работы без какого-либо следа. Причина — PySide6 (Qt) по умолчанию аварийно завершает весь процесс при первом же необработанном исключении внутри слота/таймера/потока (тик опроса, DNS-watchdog, авто-обновление подписки и т.п.). Одна скрытая ошибка в любом периодическом колбэке = жёсткий вылет, и нигде не логировалось (стартовый crash-handler покрывал только запуск, не рабочий цикл). Фикс: добавлен runtime-guard — глобальный обработчик, который при таком исключении записывает трассировку (в app.log и файл runtime-crash-.log) и не роняет приложение: сбойнул один колбэк — залогировали и работаем дальше, вместо гибели всего окна. Ctrl+C и обычный выход работают как прежде; включён faulthandler для нативных падений. Теперь любое остаточное исключение оставляет диагностический след — пришли runtime-crash-.log, и я починю конкретную причину точечно.

Подробности v3.2.1 →

English UI / английская локализация

Полноценный английский интерфейс. Весь видимый UI — главный экран, настройки, выбор сервера, импорт по подписке, онбординг, трей, диалоги, тосты и пользовательские сообщения об ошибках — переведён на английский. Переключатель языка в Настройках: Авто (по системе) / English / Русский; «Авто» определяет язык по системной локали (русская → RU, остальные → EN). Язык применяется после перезапуска. Перевод покрывает ~400 строк через лёгкую встроенную систему (tr()), без тяжёлого Qt-translation тулинга. Русский остаётся источником истины: если какой-то строки нет в EN, она показывается по-русски (не пустая). Диагностические лог-строки (страница «Логи», записи []/[!]) пока остаются на русском — это технические сообщения; при необходимости добьём второй волной.

Подробности v3.2.0 →

Подписки: авто-обновление при подключении, баннер истечения, импорт из буфера/QR

Авто-обновление при подключении. Сразу после успешного коннекта KaproTUN тихо перетягивает свежий список серверов и баланс по подписке — теперь через туннель, так что провайдера, недоступного напрямую, наконец видно. Без спама: не чаще раза в 10 минут. В строке подписки появилось «обновлено N назад». Баннер истечения. Если подписка скоро кончается (≤3 дней или ≤10% трафика) или уже истекла — на главном экране показывается заметный баннер «осталось X дней · Y трафика», клик по нему открывает импорт для продления. Данные берутся из заголовка Subscription-Userinfo провайдера. Импорт из буфера / по QR. В окне импорта — кнопки «📋 Вставить» (ссылка или конфиг из буфера; понимает и картинку с QR в буфере) и «🖼 Из QR» (распознать QR из файла-картинки). И URL подписки, и одиночный share-конфиг распознаются автоматически. QR-декодер опционален: если он не попал в сборку, кнопка честно об этом…

Подробности v3.1.9 →

«Обновить подписку» снова работает (фикс мёртвого порта обхода DPI)

Баг: подписка не обновлялась и новые серверы не добавлялись. Причина — регрессия из v3.1.0: при DPI-блокировке прямой загрузки подписки клиент пытался обойти её через локальный HTTP-прокси xray на 127.0.0.1:2080, но xray вырезан вместе с движком — на 2080 больше никто не слушает. Обход утыкался в мёртвый порт, и каждое «Обновить» / импорт тихо падали. Фикс: обход DPI теперь идёт через loopback health-proxy самого sing-box (127.0.0.1:2082, привязан к выходу через VPN). Если прямая загрузка заблокирована, а VPN подключён — подписка скачивается через туннель (это же чинит случай, когда хост подписки уезжает в прямой маршрут geoip:ru). Если VPN не подключён — честная ошибка «подключись и попробуй снова». Затронуты все три точки: ручное «Обновить», импорт по ссылке и фоновое автообновление. Мёртвая настройка порта (listenport) больше не прокидывается в загрузчик.

Подробности v3.1.8 →

Linux: подключение на свежих ядрах (обход сломанного autoroute)

Баг: на свежих ядрах Linux (проверено: Linux 7.0 / Ubuntu 26.04) подключение падало с add route 0: invalid argument. Причина — netlink-вызовы autoroute в sing-box несовместимы с ядром 7.0; воспроизводится на ВСЕХ версиях движка (1.11–1.13), то есть это апстрим-проблема sing-box, а не конфига. Само TUN-устройство при этом поднимается, а системная iproute2 маршруты добавляет нормально. Фикс: на Linux запускаем sing-box с autoroute=False и сами реплицируем то, что делал бы autoroute, через iproute2/resolvectl (новый модуль linuxtunroute): policy-route всего трафика в TUN-таблицу, исключение собственного egress sing-box по fwmark (route.defaultmark, иначе соединение к VPN-серверу зациклится), endpointindependentnat для прохождения UDP/DNS, и DNS через TUN (resolvectl dns/default-route). Маршруты и DNS аккуратно откатываются при отключении и вычищаются при старте после нечистого выхода.…

Подробности v3.1.7 →

сохранённая подписка больше не теряется при смене настроек

Баг: добавленная подписка молча пропадала — серверы из неё оставались, но «Обновить» в выборе конфига говорил «Нет сохранённых подписок». URL подписки живёт только в зашифрованном секрет-блобе и сохраняется несколькими путями. Один из них — ConnectionManager.updatesettings() — пишет долгоживущий in-memory словарь настроек, загруженный ОДИН раз при старте приложения. Если подписку добавляли уже ПОСЛЕ старта (диалог пишет блоб напрямую, в обход этого словаря), устаревший словарь по-прежнему держал subscriptionurl="" — и при следующей смене ЛЮБОЙ настройки (тема, kill-switch, маршрутизация…) затирал свежесохранённый URL пустым. Фикс: savesubscriptionsecrets больше НЕ затирает непустой сохранённый секрет пустым значением (merge-protect). URL подписки теперь переживает любые сохранения настроек. Явного «удалить подписку» в UI нет, так что легитимные сценарии это не ломает.

Подробности v3.1.5 →

транспорт конфига (network) корректно читается из хранилища

storage.loadconfigs() не считывал поле network (tcp / ws / grpc / xhttp) у сохранённых серверов — у всех загруженных конфигов оно было пустым. Гейт, который отсекает XHTTP/splithttp (их движок sing-box не умеет), держался только на запасной проверке текста share-URL. Теперь поле читается штатно, а для конфигов, сохранённых без него, восстанавливается ре-парсингом share-URL — так транспорт каждого сервера определяется явно и надёжно. Поведение для пользователя не меняется (XHTTP и так отсекался), это укрепление под капотом.

Подробности v3.1.4 →

реальный трафик через TUN пошёл: движок на gvisor-стеке

Корень «подключилось, IP сменился на VPN, но интернет не работает». TUN sing-box использовал сетевой стек mixed (kernel TCP + gVisor только для UDP). На реальных Windows-машинах (драйверы / антивирус / сторонние сетевые фильтры) этот путь через WinTUN часто не несёт трафик вообще: туннель поднимается, egress-IP меняется на VPN, connect-проверка проходит — а любой запрос приложения (Telegram, speedtest, браузер) отваливается с ошибкой соединения. Полевой замер на проблемной машине: mixed/system → 100% URLError, gvisor → Google и Telegram открываются сразу. Стек TUN переключён на gvisor (вся L3→L4 в userspace) — он работает там, где mixed молча глохнет. Надёжность важнее теоретической прибавки скорости, которой всё равно нет, когда соединения не проходят. (В будущем можно вынести выбор стека в Настройки для машин, где kernel-путь исправен.)

Подробности v3.1.3 →

откат движка на sing-box 1.12.x: туннель снова пропускает трафик

Корень бага «не подключается ни к одному серверу». Версия движка sing-box была запинена на 1.13.12, а ветка 1.13.x регрессировала data-плоскость VLESS на Windows: туннель ПОДНИМАЕТСЯ (прокси-CONNECT отдаёт 200, REALITY-хендшейк и авторизация проходят), но полезные данные не идут — HTTP/TLS-байты висят, любой реальный запрос отваливается по таймауту. Connect-проверка честно видела «сервер не пропускает трафик» и отменяла подключение. sing-box check это не ловит: баг рантайма data-path, а не грамматики конфига — поэтому он и просочился в v3.1.0/v3.1.1. Движок откатан на проверенную ветку 1.12.9. На том же конфиге и сервере 1.12.9 пропускает трафик end-to-end. Приложение больше не тянет GitHub «latest» вслепую (именно latest и притаскивал битый 1.13.x): качается ровно запиннутая версия (mirror → GitHub fallback). Авто-замена у тех, кто уже на 1.13.x. Если на диске лежит забракованный…

Подробности v3.1.2 →

DNS всегда системный: подключение больше не срывается из-за DoH

Корень бага «sing-box поднялся, но VPN-сервер не пропускает трафик». Connect-проверка ходила Cloudflare-trace'ом через прокси, а имя cloudflare.com резолвилось встроенным DoH. На многих российских сетях DoH режется DPI: запрос отваливался по таймауту (dns: exchange failed ... context deadline exceeded), DNS «чернел», и рабочий туннель ошибочно получал статус «не пропускает трафик». Подключиться было невозможно. DNS теперь ВСЕГДА системный. Убраны кастомные DoH / smart-split резолверы, переключатель DNS-сервера и галочка «Защита от DNS-утечек». Все :53-запросы перехватываются в sing-box и отвечаются системным резолвером (type: local) через физический интерфейс — тем же DNS, что работает у тебя без VPN. Один надёжный путь, который нельзя случайно сломать. Connect-проверка больше не зависит от DNS-выкрутасов. Готовность туннеля определяется живым HTTP-трафиком через прокси (loopback…

Подробности v3.1.1 →

один движок: sing-box. Меньше кода — меньше багов

KaproTUN полностью переведён на нативный TUN sing-box. Старые движки (Xray + tun2socks, отдельный Hysteria2-процесс, HTTP-proxy и «классический» TUN) вырезаны целиком — вместе с ними ушли источники гонок, лишних процессов и непредсказуемых разрывов, которые мешали просто «нажать и подключиться». Один процесс владеет TUN-устройством и сам держит маршрутизацию, DNS-hijack и split-туннелирование. Подключение перестало зависеть от связки из трёх бинарников, дерущихся за порты и за интерфейс KaproTun. Настройки упрощены: убраны переключатель движка, режим HTTP-proxy, выбор порта, поля скорости Hysteria и пресеты буферов. Всё, что раньше можно было сломать неудачной комбинацией галочек, больше не существует. При обновлении со старых версий приложение само добивает осиротевшие xray.exe / tun2socks.exe / hysteria.exe, чтобы они не держали драйвер WinTUN и файловые хэндлы. Что больше не…

Подробности v3.1.0 →

DNS больше не падает вместе с VPN-сервером

Защищённый DNS переведён на прямой DoH: провайдер видит только HTTPS к публичному резолверу, но DNS больше не зависит от VLESS/Hysteria2. Connect-проверка теперь требует реальный HTTP-трафик через TUN/proxy. Живой процесс с мёртвым транспортом больше не получает статус «Подключено». Серия CRYPTOERROR при старте Hysteria2 завершает проверку досрочно и возвращает понятную ошибку вместо минуты неработающего интернета. Runtime-watchdog проверяет не только DNS, но и реальный трафик через sing-box: живой процесс с умершим VPN-транспортом больше не зависает в статусе «Подключено». Connect-gate проверяет outbound через отдельный loopback health-proxy, принудительно направленный в proxy: direct/geoip-маршрут больше не может дать ложный успех. Запоздавший IP-probe от уже отключённой сессии больше не пишет реальный RU-IP в VPN-логи и интерфейс. Отображение внешнего IP больше не перебирает…

Подробности v3.0.13 →

Корневой фикс DNS: умный сплит (DNS идёт тем же путём, что и трафик)

Логи sing-box показали настоящую причину «нет связи»: dns: exchange failed for … EOF — резолвинг периодически зависал на 24 секунды, потому что весь DNS шёл через одно DoH-соединение к 1.1.1.1 через прокси, и когда нестабильный сервер ронял это соединение, отваливался ВЕСЬ DNS (а обычный сёрфинг жил — у каждого сайта своё соединение через прокси). Это не косметика пробы — это была архитектурная single-point-of-failure.

Подробности v3.0.12 →

Настоящая причина «Ваш IP: —»: проба ловилась на чужой системный прокси

В v3.0.10 я ошибся с диагнозом (думал — холодный старт). Настоящая причина найдена на живой машине: определение IP падало по таймауту на каждом эндпоинте за ровно 2.0 с, хотя туннель работал и грузил YouTube.

Подробности v3.0.11 →

«Ваш IP: —» больше не пугает: IP-проба переживает прогрев туннеля

Диагностика живой машины показала: туннель работает быстро и правильно (HTTPS отвечает за 0.2 с, сплит-роутинг на месте — 169 доменов из списка идут через реальный IP, geoip:ru напрямую, остальное через VPN), но определение IP сразу после подключения падало по таймауту, и в окне висело «Ваш IP: —» — из-за чего казалось, будто связи нет.

Подробности v3.0.10 →

Скорость и «Доступ в интернет заблокирован»: быстрый стек + правильный IPv6

Аудит реальной машины показал две причины тормозов и ошибки ERRNETWORKACCESSDENIED («Доступ в интернет заблокирован»), плюс висящий после закрытия GUI sing-box.

Подробности v3.0.9 →

«Просто нажми и подключись»: убраны лишние проверки, которые отклоняли рабочий туннель

В v3.0.7 здоровье туннеля проверялось слишком строго: даже рабочий сервер часто получал ошибку при подключении, а уже поднятый VPN сам себя переподключал («Подключение…»). Этот релиз убирает агрессивные проверки — подключение проходит, как только sing-box поднялся и в туннеле резолвится хоть одно имя, и держится, пока туннель реально живой.

Подробности v3.0.8 →

Критический фикс стабильности sing-box: DNS YouTube/CDN, честный health-check, диагностика крашей

Симптомы: VPN на движке sing-box сам себя переподключал (в логе [reconnect] reason=processcrash, PID sing-box менялся, в окне мелькало «Подключение…»), а YouTube / Google CDN / файлы ChatGPT грузились с задержкой 5–8 секунд. Корень — DNS в режиме TUN: системный резолвер на адаптере «KaproTun» (10.255.0.3) не получал стабильных ответов для CDN-доменов.

Подробности v3.0.7 →

Фикс: sing-box не стартовал из-за орфанного TUN-адаптера «KaproTun»

Симптом: sing-box завершился сразу после старта: FATAL … configure tun interface: Cannot create a file when that file already exists. Причина — оба TUN-движка называют устройство «KaproTun», а орфанный процесс прошлого запуска (sing-box.exe или tun2socks.exe, переживший аварийное закрытие) всё ещё держал этот адаптер, и новый sing-box не мог его пересоздать.

Подробности v3.0.6 →

Фикс sing-box TUN: DNS-зависания и картинки OpenAI/CDN мимо прокси

Симптом: через sing-box ChatGPT открывается, но картинки/файлы files.oaiusercontent.com висят или грузятся по 10-12 с; Яндекс.Картинки зависают на плейсхолдерах. Две независимые причины — обе пофикшены.

Подробности v3.0.5 →

Точечный фикс: тихие логи sing-box, ICMP-шум, изолированный smoke

smoke полностью изолирован от реального app.log. Sandbox теперь дополнительно перенаправляет paths.applogfile (раньше — только через appdatadir), а regression-тест больше не падает ложно из-за параллельно работающего приложения: проверяется не «размер не изменился» (его меняет сам работающий клиент своими [mem]-строками), а «ни одна строка с тест-сигнатурой не попала в реальный app.log». Подтверждено внешней проверкой — реальный app.log от smoke не меняется (0 добавленных строк). Лог-фильтр sing-box разделён на три корзины: - всегда скрыто из UI (но остаётся в recent/diagnostic logs): per-connection шум (forcibly closed, connection reset, download/upload closed, broken pipe) и спам ICMP («icmp is not supported by default outbound: proxy»); - скрыто, только когда туннель уже поднят, но видно на старте как диагностика подключения: неоднозначные сетевые ошибки (missing default interface,…

Подробности v3.0.4 →

Per-connection ошибки sing-box (безобидные «connection reset», «i/o timeout» к direct/LAN) больше не сыплются в UI-логи — остаются только в диагностическом буфере. Настоящие FATAL / ошибки конфига / прав по-прежнему видны. Ad-block честно показывает в Настройках, что он работает только на Xray-движках (Legacy / HTTP).

Фикс: ложный «краш Xray» в sing-box TUN + честная ошибка для XHTTP

После успешного подключения через sing-box приложение ошибочно писало «Xray-core упал (код None)» и уходило в авто-переподключение, хотя sing-box работал нормально. Причина — watchdog проверял процесс Xray (manager.process), который в sing-box-режиме вообще не запускается, и считал здоровую сессию крашем.

Подробности v3.0.2 →

Фикс: sing-box падал при отключённой защите от DNS-утечек

Если в Настройках выключить «защиту от DNS-утечек», движок sing-box (1.13.x) падал сразу после старта с ошибкой detour to an empty direct outbound makes no sense. Причина: сгенерированный DNS-сервер dns-direct имел detour: direct, а пустой direct-аутбаунд в sing-box 1.13 нельзя использовать как detour для DNS.

Подробности v3.0.1 →

Второй движок — sing-box — работает параллельно с Xray-core. Нативная поддержка Hysteria2 без отдельного процесса. Основной TUN теперь = sing-box (без моста 127.0.0.1:2081), legacy Xray + tun2socks остаётся как ручной fallback. README / SECURITY переписаны по движкам, добавлен чек-лист стабильного релиза и read-only скрипт для снапшота диагностики.

Устранена маршрутная петля в TUN-режиме: xray-аутбаунд direct теперь привязан к физическому интерфейсу через IP_UNICAST_IF (Windows). Прямой трафик (geoip:ru, direct-домены, приватные сети) физически не может вернуться в TUN. Это решает «socket-exhaustion» на CDN-адресах при включённом «РФ напрямую».

Первопричина авто-переподключений: private/LAN bypass + socket exhaustion

Реальная причина «клиент сам отключается/включается» — НЕ утечка памяти, а исчерпание локальных сокетов на loopback tun2socks → xray (127.0.0.1): [tun2socks] [TCP] dial 172.19.2.109:7680: connect to 127.0.0.1:2081: connectex: Only one usage of each socket address ... is normally permitted. 172.19.2.109:7680 — это Windows Delivery-Optimization (P2P-раздача обновлений) к пиру в Docker/WSL-подсети 172.19.x. Этот приватный трафик не должен идти через VPN, но падал в TUN-catch-all, и tun2socks открывал по сокету 127.0.0.1 на каждый поток → эфемерные порты заканчивались → росли хэндлы → memory watchdog ошибочно лечил это reconnect'ом → цикл.

Подробности v2.2.0 →

Memory-watchdog больше не «лечит» здоровое подключение. Пороги tun2socks подняты под реальный базовый уровень (умеренный 1.8 → 3.2 ГБ, критический 3.0 → 4.3 ГБ), добавлен 2-минутный grace-период после connect, heal требует устойчивого превышения (≈20–30 с подряд).

Safety: аварийный стоп при critical runaway + защита от reconnect-шторма

Две точечные правки стабильности поверх v2.1.7.

Подробности v2.1.8 →

Корень runaway: UDP-сессии, тиерный watchdog, app.log

v2.1.6 снизил TCP-буферы, но память всё равно росла (tun2socks ~4.7 ГБ / ~38k хэндлов / ~900 потоков, xray ~2.3 ГБ / ~66k хэндлов). Корень — не буферы, а массовое размножение UDP-сессий: tun2socks держит горутину + SOCKS-ассоциацию на каждый UDP 5-tuple, а QUIC/HTTP3, WebRTC, BitTorrent-DHT и Telegram открывают их тысячами. Исправлено по существу:

Подробности v2.1.7 →

Фикс памяти: безопасные буферы tun2socks, watchdog, лимиты xray

VPN-процессы могли отъедать гигабайты: tun2socks.exe ~5 ГБ и ~30k хэндлов, xray.exe ~2.3 ГБ и ~59k хэндлов. Причина — слишком большие дефолтные буферы и отсутствие лимитов на соединения. Исправлено без потери нормальной скорости.

Подробности v2.1.6 →

Реальный фикс деградации сети: DNS-failover, без утечки, fail-fast

Глубокая правка причин «при включённой защите DNS интернет умирает, при выключенной — работает». Защиту НЕ отключаем и безопасность не понижаем.

Подробности v2.1.5 →

Устойчивый TUN: само-восстановление DNS, health-check и watchdog

TUN-режим больше не должен оставлять интернет в состоянии «подключено, а ничего не открывается» и не требует ручного перезапуска сетевого адаптера после сбоя. Четыре направления:

Подробности v2.1.4 →

Фикс обрезки текста в Настройках (фиксированное/compact-окно)

На странице «Настройки» длинные описания и нижние блоки визуально резались по правому краю.

Подробности v2.1.3 →

Три точечных фикса: Unix-TUN, битый Content-Length, зеркало tun2socks

Unix-регрессия TUN. Контроллер вызывает networkroutes.findegressto() кроссплатформенно, но в networkroutesunix этой функции не было → AttributeError при TUN на Linux/macOS. Добавлен совместимый findegressto(remoteip) (делегирует на getdefaultroutev4()). Битый Content-Length ронял загрузчик. В netdownload строка int(Content-Length) падала на нечисловом заголовке (например "abc"). Теперь такой total трактуется как «неизвестно» (0), стрим продолжается, а жёсткий лимит размера по-прежнему защищает. Зеркало tun2socks указывало не туда. База была https://files.kaprovpn.pro (несуществующий поддомен, NXDOMAIN), а остальной проект — https://kaprovpn.pro/files. Приведено к единому рабочему адресу, так что mirror-first для tun2socks реально работает (важно для РФ при блокировке GitHub).

Подробности v2.1.2 →

Фикс TUN на Ethernet/мульти-NIC: «подключено, но трафика нет»

В TUN-режиме на Ethernet (особенно с несколькими адаптерами) клиент мог показывать «подключено», а трафик не шёл.

Подробности v2.1.1 →

UI/UX: читаемый график, единые тексты, ясные состояния, compact

Пакет улучшений интерфейса. Сетевую/security-логику не трогали — только слой представления.

Подробности v2.1.0 →

Окно по умолчанию фиксированного размера (480×870), больше не «ползёт» по пикселю за сессию из-за случайных задеваний невидимых хваталок. Для dev/advanced — флаг allow_window_resize: true в settings.json.

Фиксы двух регрессий после усиления безопасности

Две точечные правки к 2.0.0 — без изменения архитектуры.

Подробности v2.0.2 →

v2.0.1

Точечные правки против ситуации, когда в TUN-режиме при активном Telegram весь интернет через VPN подвисает. Архитектуру не трогали.

Подробности v2.0.1 →

Безопасность и приватность: усиление по всем фронтам

Большой релиз по безопасности. Логика VPN не менялась — это защита того, что лежит у тебя на диске и ходит по сети. Старые настройки мигрируют сами, ничего вводить заново не нужно.

Подробности v2.0.0 →

User-Agent подписки навсегда остаётся KaproVPN/<ver> — это технический ключ для провайдеров (kavonet.net и др.), которые вайтлистят клиентов по префиксу. Бренд приложения остаётся KaproTUN.

Переименование: KaproVPN → KaproTUN

Проект полностью переименован в KaproTUN — название в интерфейсе, python- пакет, бинарники, инсталлятор, репозиторий. Логика VPN не менялась.

Подробности v1.22.0 →

Split-routing «усыновляет» уже существующие маршруты (после нештатного выхода) мгновенно вместо удаления-и-пересоздания через shell. Очистка на отключении корректно убирает старые маршруты с метрикой 1 от прежних версий.

Фиксы по логам подключения: чистка маршрутов, ретраи, тише логи

Разобрал реальный лог подключения (TUN + Hysteria2) и поправил четыре вещи. VPN-функционал не менялся — это устойчивость и чистота.

Подробности v1.21.1 →

Живая карта: радар-пульс на пине, реагирует на трафик

Пин страны на карте больше не статичная точка. Теперь из него расходятся радар-кольца и мягко пульсирует свечение — карта «дышит».

Подробности v1.21.0 →

Авто-замер скорости для Hysteria2 brutal CC. При подключении к Hysteria2-серверу клиент сам замеряет канал через Cloudflare (download + upload) до поднятия туннеля и включает brutal-режим. Кнопка «↻ Перемерить» сбрасывает кеш. Альтернатива — ручной ввод скорости.

Первый коннект к Hysteria2 больше не падает с «FATAL: no recent network activity» под нагрузкой — старт hysteria автоматически перезапускается (2 попытки с чистым рестартом).

Скорость Hysteria2: brutal CC (туннель тянет торренты)

Когда торрент качается через VPN, он упирался в потолок туннеля и душил Телеграм/браузер. Причина: hysteria-клиент работал на BBR (адаптивно, вполсилы), потому что ему не задавалась пропускная способность канала.

Подробности v1.19.6 →

«Ваш IP» больше не показывает утёкший IPv6

По наблюдению: в плашке «Ваш IP» иногда мелькал IPv6-адрес с чужой страной (например, «Германия»), хотя подключение к Нидерландам. Это всплывал утёкший IPv6, а не VPN-выход. Сам VPN всё это время был в Нидерландах корректно (проверено live) — проблема была только в отображении.

Подробности v1.19.5 →

Диагностика IPv6-утечки при включённой защите

По обращению: бывает редкий случай, когда защита от IPv6-утечек включена, но правило Windows Firewall не применяется в конкретной системе (сторонний firewall, отключённая фильтрация IPv6) — и IPv6 всё равно течёт. Раньше это падало молча.

Подробности v1.19.4 →

Тест утечек чинит в один клик

По обращению пользователя: тест утечек поймал утечку IPv6, потому что защита от IPv6-утечек была выключена в настройках (по умолчанию она ВКЛ). Теперь тест не просто показывает проблему — он её чинит.

Подробности v1.19.3 →

Тюнинг tun2socks: выше потолок скорости в TUN

В TUN-режиме пропускная упиралась ниже скорости канала: gVisor-netstack внутри tun2socks по умолчанию держит маленькое TCP-приёмное окно, и на канале с задержкой оно режет потолок (окно < bandwidth-delay product).

Подробности v1.19.2 →

Фикс: тормоза DNS в TUN-режиме (сайты залипали на ~11с)

В TUN-режиме каждый новый домен мог залипать на ~11 секунд перед загрузкой — на части сетей (замечено на MTS RU) интернет «через VPN» казался сломанным, хотя в HTTP-режиме всё летало.

Подробности v1.19.1 →

Блокировка рекламы + российские сайты напрямую по гео

Две новые опции в Настройках → «Маршрутизация». Обе работают на geo-файлах (geosite.dat / geoip.dat), которые уже идут в комплекте с Xray-core, — ничего дополнительно качать не нужно.

Подробности v1.19.0 →

Закрыта IPv6-утечка в HTTP-режиме: firewall-правило на 2000::/3 (без LAN — link-local/ULA остаются) теперь ставится не только в TUN, но и в HTTP-прокси. Требует прав администратора; без них честно предупреждаем в логе.

Кнопка «Обновить» в списке серверов

В окне выбора серверов появилась кнопка 🔄 Обновить — рядом с «📥 Подписка». Один клик заново скачивает все сохранённые подписки и подтягивает свежие серверы.

Подробности v1.18.0 →

Переустановка через Setup.exe больше не падает с PermissionError: установщик сначала корректно останавливает запущенный KaproTUN (как «Выход» из трея), потом атомарно подменяет файл. При удалении подчищает системный прокси и firewall-правила.

Hotfix v1.17.2: выделение/активная подсветка по границам строки

Юзер: подсветка выбранного и активного сервера «очень криво» — амбер-бокс был выше своего контента и наезжал на соседнюю строку.

Подробности v1.17.3 →

Hotfix v1.17.1: текст в строках больше не обрезается (DPI)

Юзер прислал скриншот: текст в строках списка обрезался (имя и строка протокола резались по краям). Фикс v1.17.1 (потолок 56px) был полумерой.

Подробности v1.17.2 →

Hotfix v1.17.0: строки списка серверов больше не наезжают

Юзер прислал скриншот: в новом списке серверов две строки наезжали друг на друга — имя и строка «VLESS · server:port · пинг» перекрывались по вертикали.

Подробности v1.17.1 →

Список серверов: сортировка + цветные строки (UX 2.0, фаза 1)

Первый шаг к UX 2.0 — список серверов в окне выбора конфига стал консьюмерским.

Подробности v1.17.0 →

Зеркало переехало на kaprovpn.pro/files

При проверке фикса автообновления (v1.16.17) выяснилось, что субдомен files.kaprovpn.pro вообще никогда не существовал в DNS (NXDOMAIN). То есть mirror-first во ВСЕХ инсталлерах (xray / tun2socks / hysteria) и в апдейтере всё это время молча падал на GitHub — зеркало было лишь «на бумаге». Для пользователей с заблокированным github (РФ) это значит, что и установка бинарей, и автообновление держались только на github.

Подробности v1.16.18 →

Автообновление переживает блокировку github.com

Пользователь прислал ошибку автообновления:

Подробности v1.16.17 →

Hysteria2 теперь реально подключается

Раньше hysteria2:// парсился, но при попытке подключения падал с NotImplementedError — потому что Xray-core не умеет Hysteria2 (его вырезали вместе с переходом с sing-box на Xray в самом начале проекта).

Подробности v1.16.16 →

Подписка: остаток трафика и срок действия

Провайдеры отдают остаток трафика и дату окончания подписки в стандартном заголовке Subscription-Userinfo (де-факто формат Clash/v2ray):

Подробности v1.16.15 →

Импорт подписки: честная причина ошибки + отсев заглушек

Разбирали с пользователем импорт подписки gmailvpn и нашли два бага.

Подробности v1.16.14 →

Надёжность запуска: атомарная запись + safe-mode + диалог ошибки

В v1.16.11 мы реактивно чинили краш на старте (битый configs.json ронял приложение). Теперь закрываем весь класс этой проблемы. Это важно вдвойне: краш на старте случается до того, как отработает встроенный авто-апдейтер — то есть сломанная сборка не может починить сама себя, и пользователь застревает до ручной переустановки.

Подробности v1.16.13 →

Шифрование конфигов теперь и на macOS/Linux

До этого релиза configs.json шифровался на диске только на Windows (DPAPI). На macOS/Linux он лежал plaintext — твои VLESS-UUID, Trojan-пароли и subscription-URL читались любым, кто открыл файл. Для VPN с позиционированием «privacy» это была заметная дыра (и прямо числилась в roadmap).

Подробности v1.16.12 →

Битый локальный файл больше не роняет приложение на старте

Юзер прислал скриншот краша на запуске:

Подробности v1.16.11 →

Leak-test быстрее + не врёт про AdGuard

Юзер запустил тест после v1.16.9 — отработал, но медленно (~30 с) + показал ✗ DNS «подозрение на утечку» хотя все 8 резолверов были одним AdGuard-провайдером (AS208398 Edge Technology Plus, известный CDN-партнёр AdGuard в EU).

Подробности v1.16.10 →

Hotfix v1.16.8: leak-test больше не висит навечно

Юзер запустил «Проверить утечки» после v1.16.8, диалог замер на «Проверяем IPv4, IPv6, DNS, WebRTC…» на 30+ секунд без какого- либо результата.

Подробности v1.16.9 →

Защита от DNS-утечек теперь отдельный toggle, default ON

Юзер v1.16.7 запустил тест на System DNS — увидел утечку и спросил «это без DNS, че делать?». В v1.16.6/7 защита работала только для non-system DNS-опций — это было неправильное связывание двух разных решений в одно.

Подробности v1.16.8 →

DNS leak fix часть 2: глушим DNS на physical NIC

Юзер запустил leak-test после v1.16.6 (с DNS option = AdGuard, после reconnect). Результат:

Подробности v1.16.7 →

Реальный DNS leak fix: hijack :53 на VPN-resolved upstream

Юзер запустил leak-test после v1.16.5, переключил DNS option на AdGuard/Cloudflare/Quad9 — и тест всё равно показал ✗ с российскими ISP-резолверами (МГТС, Edge Technology). Переключение настройки не помогало.

Подробности v1.16.6 →

Hotfix v1.16.4: DNS leak test использовал не тот домен

Юзер запустил «Проверить утечки» — IPv4/IPv6/STUN зелёные, а DNS показал ⚠ «bash.ws не зарегистрировал ни одного резолвера». При этом DNS-резолверы у юзера явно есть (без них интернет не работал бы) — что-то не так с самим тестом.

Подробности v1.16.5 →

DNS / IPv6 / WebRTC Leak self-test

Новая кнопка в Настройки → Проверить утечки. Запускает 4 активные сетевые проверки через активный VPN-туннель + показывает результат в виде ●/⚠/✗ таблицы:

Подробности v1.16.4 →

Hotfix v1.16.1: resize теперь реально работает

Юзер: «Я должен тянуть за край программы, и его расширять или уменьшать. Вот так.» — то есть он установил v1.16.2, но resize по краям всё равно не работает. Курсор не меняется, drag не двигает границу.

Подробности v1.16.3 →

Hotfix v1.16.1: AttributeError при старте окна

Юзер: python run.py → AttributeError: 'MainWindow' object has no attribute 'manager' сразу на запуске. Окно не открывается, exit до splash'а.

Подробности v1.16.2 →

Окно теперь resizable

До v1.16.1 главное окно было setFixedSize(480, 870) — нельзя было ни увеличить, ни уменьшить. На больших мониторах хотелось график 24h побольше; на ноутбуках с маленьким экраном — наоборот, сжать.

Подробности v1.16.1 →

Защита от WebRTC leak

Новая фича приватности: блокируем WebRTC-утечки IP через STUN. Это дыра, через которую любой сайт может узнать твой реальный IP даже при работающем VPN.

Подробности v1.16.0 →

Hotfix v1.15.3: реальные цифры трафика на странице «Статистика»

Юзер: «Подключился, статус правильный (● Подключено), но ↓ 0 Б/с ↑ 0 Б/с, "За сессию: считаем…" висит навсегда — трафик идёт, цифры стоят».

Подробности v1.15.4 →

Hotfix v1.15.2: статус live-блока теперь не врёт

Юзер прислал скриншот: подключился к VPN, открыл «Статистика» — а live-блок упрямо пишет ○ Не подключено, цифры в —. При этом на главной всё ок: connect-кнопка зелёная, таймер тикает.

Подробности v1.15.3 →

Live-блок на странице «Статистика»

Юзер заметил, что после свежей установки страница «Статистика» пустая (24h-график показывает «Нет данных за последние 24 часа», пока не накопится хотя бы один минутный сэмпл). Хотелось видеть что происходит прямо сейчас, а не только историю.

Подробности v1.15.2 →

Hotfix v1.15.0: иконка Stats в навбаре теперь одного размера

Юзер прислал скриншот навбара: 📊 рендерится цветной и визуально больше остальных глифов (⌂ ⚙ +). Variation selector U+FE0E (text-style override) на 📊 не сработал — Segoe UI Emoji всё равно отрисовала emoji-style.

Подробности v1.15.1 →

Страница «Статистика»: график трафика за 24 часа

Новая вкладка в нижней навигации между «Главная» и «Настройки» — 📊 Статистика. Внутри:

Подробности v1.15.0 →

Карта прижата к «Прямые сайты», нет пустого места внизу

Юзер прислал скриншот: между картой мира и строкой «Прямые сайты — 168 доменов идут напрямую» был большой пустой пробел (~100 px). Дословная цитата: «не оставлять дохуя места».

Подробности v1.14.6 →

Connect-кнопка больше + текст «ПОДКЛЮЧЕНИЕ…» не обрезается

После v1.14.4 (где я уменьшил кнопку до 190) юзер прислал три скриншота:

Подробности v1.14.5 →

Layout home-страницы: уменьшил кнопку и карту, увеличил окно

После того как карта вернулась в v1.14.3, юзер сообщил о компоновке: кнопка слишком крупная, кольцо почти пересекалось с заголовком, статус заходил на нижний край кольца, IP/карта слишком близко. Также «белые полосы справа» от карты.

Подробности v1.14.4 →

Карта показывается СРАЗУ при connect (не зависит от probe)

После v1.14.2 юзер увидел что блок IP+карта вообще пропал — осталось только "Подключено · 01:33 · TUN", сразу за ним "Прямые сайты". Расследовал: мой fix v1.14.2 (только blur radii) физически не мог это сломать. Реальная причина — AdGuard расширил blocklist'ы и теперь блокирует все 5 наших probe endpoint'ов (api.myip.com, httpbin.org, ipinfo.io, api.ipify.org, ifconfig.co). Probe полностью провален → ip пустой → блок скрыт по логике graceful-degrade из v1.14.0.

Подробности v1.14.3 →

Fix: glow connect-кнопки бликовал на карту и статус-текст

Юзер прислал скриншот: на «Подключено» строке и «Ваш IP» строке — размытое янтарное свечение, через карту мира видна «диагональная оранжевая линия». Хороший bug report с точным описанием.

Подробности v1.14.2 →

Hotfix v1.14.0: карта визуально отделена от текста выше

Юзер прислал скриншот — карта работает и пин на Нидерландах правильно. Но «из-за карты въезжает вверх IP и Подключено». Реально это не overlap (текст выше карты в layout'е), но карта без border'а и в цвет фона (palette.BG) визуально сливалась со строками статуса и IP — выглядело как «карта проходит через текст».

Подробности v1.14.1 →

Карта мира с pin'ом VPN-сервера

Под строкой «Ваш IP: ...» теперь рисуется маленькая карта мира с янтарным пином в стране где находится твой VPN-сервер. Размер 400×200 px, появляется автоматически когда probe определил страну.

Подробности v1.14.0 →

Тема применяется СРАЗУ (live-apply вместо restart)

v1.13.0 сохраняла выбор темы, но применяла только при следующем запуске. Юзер протестировал — «выбрал светлую, никакой белезны нет, тёмная осталась». Это был мой UX-провал: я перенёс паттерн «применяется после рестарта» с language combo на theme combo, но для языка это оправдано (нужно перетранслировать ~50 hardcoded строк), а для темы — просто app.setStyleSheet(getqss(newtheme)) и весь global QSS перепаинтит мгновенно.

Подробности v1.13.1 →

Светлая тема + Auto/Dark/Light toggle

Раньше KaproTUN был только тёмной. Теперь — 3 варианта: Auto (по системе), Dark, Light. Переключается в Settings → Тема. Применяется при следующем запуске (Qt не умеет красиво re-стайлить уже-построенные виджеты, restart надёжнее чем гоняться за каждым label'ом).

Подробности v1.13.0 →

Поиск по конфигам в выборе сервера

Подписочные провайдеры обычно дают 20-50 серверов под один URL. Скроллить глазами и искать «тот финский с REALITY» каждый раз — ад. Теперь в окне «Выбор конфига» (открывается при клике по карточке активного сервера в Home или через «+ Добавить») есть поиск.

Подробности v1.12.0 →

Реальная защита от IPv6-leak в TUN-режиме

В v1.10.3 я зафиксил IPv6-leak только в нашем UI-probe (мы перестали показывать v6 IP вместо v4). Реальный leak оставался — приложения с AAAA-записями (Google, YouTube, Cloudflare, Facebook — почти весь крупный веб) шли через провайдера по IPv6 мимо туннеля. На Билайне / МТС / Ростелекоме (где у юзера обычно публичный IPv6) — это значит провайдер видел куда вы заходите.

Подробности v1.11.0 →

Probe-endpoints, которые реально работают через AdGuard

v1.10.3 показывал Ваш IP: 46.17.101.82 · — (страна em-dash) когда выбран AdGuard. Причина — AdGuard DNS NXDOMAIN'ит все три наших endpoint'а (ipinfo.io / api.ipify.org / ifconfig.co — каждый классифицируется как "трекинговый/аналитический"). В итоге либо все три падают (пустая строка), либо в лучшем случае срабатывает только ipify (даёт IP без страны).

Подробности v1.10.4 →

Hotfix v1.10.2: probe IPv4-only + release-body теперь Desktop, а не Android

Юзер запустил v1.10.2 и прислал скриншот. Probe сработал, но показал 2a00:1370:8192:1aa2:4c8:f2e4:7479:a856 · Россия · Moscow — это реальный IPv6 от Билайн-Москва, не IP VPN-сервера. Получилось что наш UI наглядно показал утечку IPv6 пользователю.

Подробности v1.10.3 →

Hotfix: AdGuard блокировал наш же IP-probe (ipinfo.io)

Логи v1.10.1 показали виновника:

Подробности v1.10.2 →

Hotfix v1.10.0: PySocks в bundled-сборке + диагностические логи

Юзер сразу после релиза v1.10.0 написал: «Никаких изменений не вижу кроме версии — строки Ваш IP нет». Две причины (плюс никакой диагностики чтобы понять которая из них сработала).

Подробности v1.10.1 →

Видимое подтверждение что VPN работает: «Ваш IP: X (страна)»

После аудита фич я честно сказал что в KaproTUN нет визуального пруфа что туннель реально работает. Юзер кликает «Подключить» → видит янтарную кнопку и «Подключено · 16:34 · TUN» — и идёт проверять через ipleak.net вручную. У NordVPN, Hiddify, Mullvad сразу показывают «Connected · IP: X.X.X.X · Country».

Подробности v1.10.0 →

Onboarding-карточка «Нет провайдера → открой гайд» больше не ведёт на несуществующую страницу — теперь редирект на главную с описанием проекта и инструкциями.

Добавлена подсказка под опцией AdGuard: YouTube-реклама всё равно показывается (она идёт с тех же доменов что и видео), для её блокировки рекомендуется uBlock Origin в браузере.

Блокировка рекламы через xray routing-rules (geosite-категория) — работает независимо от DNS браузера и встроенных AdBlock-расширений.

Выбор DNS-сервера: System, AdGuard (блокирует рекламу и трекеры), Cloudflare 1.1.1.1, Quad9 9.9.9.9. Доступно в Настройках.

Авто-восстановление от ошибки Windows rc=5010, которая возникала после нештатного отключения (BSOD, kill-process, ребут): «зависшие» routing-записи теперь чистятся автоматически перед новым подключением.

Поправлены installer-тесты после v1.8.2; в Maintenance UI вернулась кнопка «Удалить», убран лишний чекбокс desktop-shortcut.

Фиксы v1.8.1: кнопка «Удалить» теперь работает

Юзер протестировал v1.8.1 — нашёл что я пропустил:

Подробности v1.8.2 →

Maintenance UI в Setup.exe: если приложение уже установлено, инсталлятор показывает экран с двумя кнопками — «Переустановить» или «Удалить», вместо повторного install-flow.

Большой приватность-апгрейд:

• 🔒 Конфиги шифруются на диске через Windows DPAPI (как Chrome шифрует пароли) — нельзя прочитать через Блокнот без вашего Windows-аккаунта
• 🚫 xray access-логи полностью отключены — никаких записей «куда подключались»
• 🛡 Усилена защита от DNS-утечек
• ♻ Ротация логов: старые файлы автоматически удаляются

Background subscription auto-refresh

Раз в 12 часов KaproTUN тихо обновляет твою сохранённую подписку, добавляет новые сервера от провайдера. Никаких toast-спамов: уведомление только если реально что-то добавилось. Удалений нет — даже если fetch упадёт (DPI, провайдер в дауне), известные рабочие конфиги остаются на месте.

Подробности v1.7.1 →

TUN-режим на всех трёх ОС. Раньше TUN был только в Windows-сборке. Теперь системное туннелирование (Telegram, Steam, игры) работает на Windows (UAC), macOS (sudo) и Linux (pkexec/sudo).

First-launch onboarding

При первом запуске вместо пустого «Конфиг не выбран» — Welcome-экран с тремя большими карточками: «есть subscription URL», «есть share-URL», «нет провайдера → открой гайд». Понятно что делать дальше без чтения доков.

Подробности v1.6.1 →

Auto-reconnect

Если xray умер не по нашей команде — KaproTUN сам перезапускает соединение до 3 раз с backoff 1с/5с/15с. После 3-х провалов — toast «нужно вручную». User-initiated disconnect отменяет цепочку.

Подробности v1.6.0 →

EN localization (MVP)

Translate tray + main connect button + Settings. Toggle в Settings (Auto / English / Русский). Auto-detect из системной локали при первом запуске. Глубокие диалоги (subscription import body, error popups) пока на русском — следующая итерация добавит инкрементально.

Подробности v1.5.2 →

Tray quick-connect

Топ-3 самых быстрых конфига (по пингу) теперь в самом верху меню трея. Один клик = переключение + подключение, без открытия главного окна.

Подробности v1.5.1 →

Real firewall kill-switch

Если включить kill-switch в Settings и подключиться, KaproTUN ставит 3 firewall-правила через netsh advfirewall: блокирует весь outbound кроме LAN и xray.exe. Если xray упадёт — у браузера интернет тоже отвалится, и юзер сразу заметит вместо тихой утечки реального IP в открытый интернет.

Подробности v1.5.0 →

WireGuard removed

После шести версий попыток (gVisor user-space, system WG service, portable extract, locale-fixes...) — WG so rough in real RU networks that we cut losses. Если нужен WG — используй официальный WireGuard for Windows. KaproTUN остаётся клиентом VLESS / Trojan / VMess / SS / Hysteria2.

Подробности v1.4.0 →

v1.3.4

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.3.4 →

v1.3.3

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.3.3 →

v1.3.2

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.3.2 →

v1.3.1

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.3.1 →

v1.3.0

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.3.0 →

v1.2.7

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.7 →

v1.2.6

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.6 →

v1.2.5

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.5 →

v1.2.4

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.4 →

v1.2.3

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.3 →

v1.2.2

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.2 →

v1.2.1

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.1 →

v1.2.0

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.2.0 →

v1.1.4

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.1.4 →

v1.1.3

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.1.3 →

v1.1.2

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.1.2 →

v1.1.1

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.1.1 →

v1.1.0

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.1.0 →

v1.0.1

Подробности и файлы этой версии доступны в записи релиза.

Подробности v1.0.1 →

Первый стабильный релиз с поддержкой трёх ОС. Windows (Setup.exe), macOS Apple Silicon (DMG), Linux x64 (AppImage). HTTP-прокси на всех; TUN-режим — пока только Windows (mac/Linux в v1.7).

v0.1.9

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.9 →

v0.1.8

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.8 →

v0.1.7

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.7 →

v0.1.6

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.6 →

v0.1.5

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.5 →

v0.1.4

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.4 →

v0.1.3

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.3 →

v0.1.2

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.2 →

v0.1.1

Подробности и файлы этой версии доступны в записи релиза.

Подробности v0.1.1 →