v3.1.5

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

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.1.5.

Full Changelog: v3.1.4...v3.1.5

Full Changelog: v3.1.4...v3.1.5

v3.1.4

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

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.1.4.

Full Changelog: v3.1.3...v3.1.4

Full Changelog: v3.1.3...v3.1.4

v3.1.3

• Корень «подключилось, 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-путь исправен.)

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.1.3.

Full Changelog: v3.1.2...v3.1.3

Full Changelog: v3.1.2...v3.1.3

v3.1.2

• Корень бага «не подключается ни к одному серверу». Версия движка
  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. Если на диске лежит забракованный
  1.13.x, он считается «не установлен», сносится и заменяется на 1.12.9 при
  следующем подключении — вручную ничего удалять не нужно.
• Connect-проверка больше не висит 2 минуты. Гейт готовности туннеля считал
  виртуальное время (сумму интервалов), а не реальное, и при мёртвом транспорте
  растягивал заявленные 15 с до ~122 с «Проверяю…». Теперь отвал укладывается в
  честные 15 с.

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.1.2.

Full Changelog: v3.1.1...v3.1.2

Full Changelog: v3.1.1...v3.1.2

v3.1.1

• Корень бага «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 health-proxy), а не
  сравнением egress-IP двух trace-запросов, которое часто давало ложный отказ.
• Компромисс, который ты выбрал сознательно: запросы к системному DNS идут
  открытым UDP/53 (без DoH), т.е. провайдер видит запрашиваемые домены —
  надёжность важнее скрытия DNS. Содержимое трафика по-прежнему в туннеле.
• ipv4_only для DNS: приложения не тратят время на IPv6-попытки (глобальный
  IPv6 и так отклоняется внутри туннеля).

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.1.1.

Full Changelog: v3.1.0...v3.1.1

Full Changelog: v3.1.0...v3.1.1

v3.1.0

• 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 и файловые хэндлы.
• Что больше не поддерживается: конфиги на XHTTP / splithttp (возьми сервер
  на обычном TCP / WS / gRPC) и режим системного HTTP-прокси. Протоколы
  VLESS (в т.ч. REALITY + flow), Trojan, VMess, Shadowsocks и Hysteria2 работают
  как прежде — через нативный TUN.

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.1.0.

Full Changelog: v3.0.13...v3.1.0

Full Changelog: v3.0.13...v3.1.0

v3.0.13

• Защищённый DNS переведён на прямой DoH: провайдер видит только HTTPS к
  публичному резолверу, но DNS больше не зависит от VLESS/Hysteria2.
• Connect-проверка теперь требует реальный HTTP-трафик через TUN/proxy.
  Живой процесс с мёртвым транспортом больше не получает статус «Подключено».
• Серия CRYPTO_ERROR при старте Hysteria2 завершает проверку досрочно и
  возвращает понятную ошибку вместо минуты неработающего интернета.
• Runtime-watchdog проверяет не только DNS, но и реальный трафик через sing-box:
  живой процесс с умершим VPN-транспортом больше не зависает в статусе «Подключено».
• Connect-gate проверяет outbound через отдельный loopback health-proxy, принудительно
  направленный в proxy: direct/geoip-маршрут больше не может дать ложный успех.
• Запоздавший IP-probe от уже отключённой сессии больше не пишет реальный RU-IP
  в VPN-логи и интерфейс.
• Отображение внешнего IP больше не перебирает api.myip.com, httpbin,
  ipinfo, ipify и ifconfig.co: один короткий Cloudflare trace-запрос идёт
  через локальный proxy активного движка, без повторов, лог-спама и влияния на connect.
• MTU sing-box TUN снижен с jumbo 9000 до безопасного 1400: маленькие probes
  больше не маскируют зависание крупных TLS/WebSocket/video-потоков на сетях с
  неработающим PMTUD или фильтрацией фрагментов.
• Connect/runtime health-check использует HTTPS через выбранный VPN outbound,
  а не крошечный plain-HTTP 204.
• Готовность sing-box теперь подтверждается двумя путями: Cloudflare trace через
  служебный proxy и через обычный системный стек Windows должны вернуть один
  VPN-IP. Живой outbound больше не маскирует сломанный TUN/auto-route.

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.0.13.

Full Changelog: v3.0.12...v3.0.13

Full Changelog: v3.0.12...v3.0.13

v3.0.12

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

• Умный сплит DNS — путь резолва теперь совпадает с путём трафика.
  • Сайты из твоего списка (и так идущие напрямую) резолвятся напрямую —
    через обычный DNS по физическому интерфейсу. Быстро, надёжно, никогда не
    зависит от прокси. Это не утечка: ты и так ходишь на них по реальному IP,
    провайдер всё равно видит соединение. Российские банки/сервисы из списка
    больше не зависают из-за нестабильного зарубежного сервера.
  • Всё остальное (проксируемое) резолвится через DoH-в-туннеле —
    leak-protected и устойчиво к подмене DNS российским провайдером. Плюс
    добавлен connect_timeout: 5s: если сервер уронил DoH-соединение, зависание
    ограничено ~5 с вместо 24 с — DNS быстро восстанавливается, а не блэкаутит.
• Проверено реальным sing-box check во всех режимах (leak on/off × ru on/off)
  с твоим настоящим списком из 169 доменов; смоук зелёный.

Честно: периодические EOF — это нестабильность самого VLESS-сервера
(77.239.122.15) — он временами роняет соединения (и UDP тоже). Этот фикс
убирает зависимость прямого/российского трафика от него полностью и
ограничивает зависание для зарубежного. Если зарубежные сайты всё ещё временами
тупят — стоит попробовать другой сервер из подписки (он стабильнее).

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.0.12.

Full Changelog: v3.0.11...v3.0.12

Full Changelog: v3.0.11...v3.0.12

v3.0.11

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

• IP-проба больше не ходит через системный / env-прокси. В реестре
  Windows оказался прописан мёртвый прокси 127.0.0.1:12334 (оставленный другой
  программой). Библиотека requests по умолчанию уважает системный прокси
  (trust_env), и процесс приложения, запущенный от админа, резолвил этот
  прокси, хотя обычный процесс — нет. В итоге каждый запрос пробы пытался
  подключиться к мёртвому прокси и отваливался по таймауту 2.0 с (ConnectTimeout
  — в логе виден как «timeout»), а обычный трафик (ядро гонит через туннель)
  работал. Теперь проба создаёт сессию с trust_env=False и игнорирует любой
  системный/env-прокси — в TUN-режиме идёт напрямую через туннель, в
  HTTP-режиме через явный SOCKS. Проверено: с мёртвым прокси в окружении старый
  путь падает за 2.0 с, новый отдаёт IP за 0.48 с.
• Заодно: таймаут пробы на эндпоинт поднят до 3 с и в лог теперь пишется
  полный тип ошибки (ConnectTimeout / ReadTimeout / ProxyError) — чтобы подобное
  больше не приходилось диагностировать вслепую.

Туннель и сплит-роутинг как работали, так и работают — менялась только проба,
которая показывает IP в окне.

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.0.11.

Full Changelog: v3.0.10...v3.0.11

Full Changelog: v3.0.10...v3.0.11

v3.0.10

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

• IP-проба стала терпимее к холодному старту. Она запускается сразу после
  коннекта, пока REALITY-туннель ещё прогревает пул соединений — первые
  несколько HTTPS-запросов могут отвалиться по таймауту, хотя туннель уже
  работает. Окно прогрева расширено с ~6 до ~12 с (как у проверки живости из
  v3.0.8). На прогретом туннеле IP по-прежнему определяется меньше чем за
  секунду. «Ваш IP: —» на рабочем VPN больше не появляется.

Идея сплит-роутинга сохранена и подтверждена: домены из твоего списка и
российские IP (geoip:ru) идут напрямую через твой реальный IP, всё остальное —
через VPN.

---

⬇ Скачать (выбери под свою систему)

OS	Файл	Что делать
Windows 10/11 (x64)	KaproTUN-Setup.exe	Запустить, пара кликов
macOS (Apple Silicon)	KaproTUN-macOS-arm64.dmg	Открыть DMG, перетащить в Applications
Linux (x64)	KaproTUN-Linux-x64.AppImage	chmod +x и запустить

Полный changelog: CHANGELOG.md

---

Auto-built by GitHub Actions from v3.0.10.

Full Changelog: v3.0.9...v3.0.10

Full Changelog: v3.0.9...v3.0.10