Браузер работает, а приложения — нет

Системный прокси — это предложение, а не приказ

Когда вы включаете системный прокси, клиент делает ровно одно: записывает 127.0.0.1 и номер порта в настройки прокси операционной системы. Кто из программ станет эту настройку читать, система не решает и заставить никого не может. Кто читает — идёт через прокси, кто не читает — уходит напрямую. Отсюда и вся история: браузер работает, а конкретное приложение наотрез отказывается.

• Chrome и Edge следуют системной настройке без всякой донастройки.
• Firefox по умолчанию тоже следует, но держит собственную страницу прокси. Стоит кому-то переключить её на ручную настройку или на вариант без прокси — и он перестаёт следовать.
• Консольные утилиты системный прокси не смотрят вовсе. curl, git, npm, pip, apt и их родня знают только переменные окружения.
• Часть приложений на Electron и почти все игровые клиенты соединяются напрямую по замыслу разработчика либо имеют собственное поле прокси, никак не связанное с системным.
• Приложения из магазина Windows (UWP) работают в контейнере со своими правилами сетевой изоляции — это отдельная история.

Сначала определите: не идёт через прокси или идёт и падает?

1. Откройте в клиенте страницу соединений; в большинстве сборок она называется Connections.
2. Очистите список, затем зайдите в приложение и заставьте его отправить запрос.
3. Ни одной новой строки не появилось — приложение прокси не использует вообще, и следующие два раздела для вас.
4. Строки появляются, но постоянно обрываются или замирают на нескольких сотнях байт — приложение идёт через прокси, а виноваты узел или правила. Это совсем другое расследование, не тратьте время на настройки прокси.

Есть своё поле прокси — просто заполните его

Самый простой слой и самый часто пропускаемый. Пройдитесь по настройкам приложения: поле прокси прячется в разделе «Сеть» или «Соединение» чаще, чем кажется. Впишите 127.0.0.1 и свой смешанный порт. Обратите внимание, что именно у вас спрашивают, HTTP-прокси или SOCKS5: mixed-port принимает оба, так что подойдёт любой, но в старом конфиге, где port и socks-port разведены, нужно попасть в нужный.

Консоль читает только переменные окружения

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1,192.168.0.0/16

В ходу оба написания, строчными и прописными, поэтому аккуратный вариант — задать каждое имя дважды. no_proxy выводит из-под прокси локальные и внутренние адреса; забудете о нём, и запросы к собственной машине пойдут в обход. Эти строки живут только в текущей сессии оболочки и исчезают вместе с терминалом: чтобы закрепить их, впишите в .bashrc, .zshrc или другой стартовый файл вашей оболочки. В Windows PowerShell использует форму $env:HTTP_PROXY, CMD — set, а setx записывает значение навсегда. И ещё: у git, npm и pip есть собственные настройки прокси, так что если переменные будто игнорируются, загляните в их конфиги.

Когда не помогло ни то, ни другое, остаётся TUN

У некоторых программ нет ни поля прокси, ни интереса к переменным окружения: открыли сокет и пошли. Договориться с ними нельзя. TUN перехватывает уровнем ниже — создаёт виртуальный адаптер и переписывает маршруты так, что исходящий трафик забирается независимо от того, что программа думает про прокси. Это единственный универсальный запасной вариант, и стоит он прав администратора плюс собственного набора проблем. С UDP та же история: игры и голосовые звонки идут по UDP, которого системный прокси никогда не касался. Бывает и обратная задача — внутренние утилиты, менеджеры загрузок, рабочий софт, которые вам как раз не нужны в прокси. Одно правило по имени процесса это закрывает.

rules:
  - PROCESS-NAME,aria2c.exe,DIRECT
  - PROCESS-NAME,ssh,DIRECT
  - MATCH,PROXY