Системный прокси - по сути записка, вывешенная в ОС: «отправляйте трафик на 127.0.0.1:7890». Браузеры и воспитанные приложения слушаются. Но записка - не принуждение: часть программ её игнорирует.

Четыре класса нарушителей

  1. Консольные утилиты (curl, git, pip, go, …): прокси Windows не читают вовсе. Лечение: переменные окружения или настройки инструментов.
  2. UWP / приложения из Store: ОС запрещает им loopback. Лечение: утилита UWP Loopback.
  3. Приложения с собственным сетевым стеком (часть игр, офисных пакетов, мессенджеров): соединяются напрямую, не глядя в настройки. Если внутри есть свой пункт «прокси» - впишите 127.0.0.1:7890 (SOCKS5 или HTTP); нет - остаётся TUN.
  4. Системные службы и драйверы (Windows Update, синхронизация времени, …): работают в контексте служб и пользовательский прокси не видят. Тоже территория TUN.

Универсальное лекарство: режим TUN

TUN закрывает все случаи выше, забирая трафик на сетевом уровне - без чьего-либо согласия. После включения колонка Process на Connections покажет, что трафик приложения пошёл куда надо.

Обратная задача: вывести приложение из прокси

Под TUN захватывается всё; тем, кого хотите пустить напрямую (облачные диски, местные игровые клиенты):

rules:
  - PROCESS-NAME,clouddrive.exe,DIRECT
  - PROCESS-NAME,game.exe,DIRECT

См. Правила PROCESS-NAME.

Ещё вариант: приложение ходит через другой прокси

На машине с несколькими прокси-инструментами приложение может быть настроено на чужой порт. Проверьте его собственные сетевые настройки и посмотрите, не «прыгает» ли переключатель System Proxy - верный знак, что его переписывает другой инструмент.

Ключевой признак: ни следа приложения на Connections = его трафик до Clash не доходит (это не проблема правил). Сначала решайте «как попасть внутрь», потом «как маршрутизировать».