В IETF (там проектируют архитектуру интернетов) внезапно осознали, что спасение веба от будущих квантовых компьютеров обернется знатной болью для сетевой инфраструктуры и серверов.

Долгие годы мы пользовались классической криптографией, где ECDSA-подпись весила смешные 64 байта, и всем всё хватало. Но на горизонте замаячили квантовые компьютеры, способные помножить на ноль наши RSA и эллиптические кривые. Чтобы мировые правительства и товарищи майоры не смогли расшифровать трафик 🙂, индустрия начала перекатываться на постквантовую криптографию.

С алгоритмами обмена ключами (Kyber) всё разрулили довольно быстро. А вот когда дело дошло до сертификатов (алгоритм ML-DSA, он же Dilithium), случился былинный отказ. Новая подпись стала весить ~2.4 килобайта! А поскольку TLS-хендшейк состоит чуть более, чем полностью из цепочки сертификатов (Root, Intermediate, Leaf + всякие пруфы вроде SCT), общий вес стартового пакета раздуло с привычных 2-4 КБ до 15-30 КБ. То есть размер вырос кратно 🍔

Что мы имеем с гуся? Справедливо из канала летит эникейский вопрос: "И хуле? Гигабитные каналы же!". А то, мой юный эникей, что эта жирная туша тупо не влезает в стандартное TCP-окно, которое исторически вмещает ~14 КБ (около 10 пакетов).

Начинается жесткая фрагментация, лишние обращения и задержки (особенно на мобильных линках и спутниках). А твои Nginx, HAProxy и балансировщики просто фалломорфируют от такого размера буферов клиентского хендшейка и начинают нещадно дропать пакеты, отправляя юзера в таймаут 😱

Корпорации добра уже притащили в IETF проект очередной костыль, обозвав его Merkle Tree Certificates (MTC???). Идея проста... нафига гонять эту жирную простыню при каждом подключении? Давайте отдавать клиенту компактные пруфы по отдельному каналу. TLS худеет обратно, прозрачность сохраняется, все довольны, PROFIT!

Чтобы пересадить на эти костыли весь мировой зоопарк серверов, роутеров, микроволновок и браузеров, потребуется лет 10-15. Так что можем пока расслабиться по этому вопросу... 😁

В погоне за гибкостью ушел искать десктопные решения (под Windows в моем случае).. ProxyCap — Заворачивание трафика определенных программ в прокси (на примере Guilded — аналог Discord) чрезвычайно не гибок, но с проксированием трафика определенного софта его хватает, хочешь чтобы только один из кучи, что установлены в системе, работал через внешний прокси сервер — пожалуйста, ограничивается все лишь использованием Shadowsocks, если нужна поддержка UDP конечно. Clash for Windows (CFW) (ядро Clash) заставлял себя настраивать, как и NekoBox (под Windows — NekoRay, ядро Sing-Box), но в первом случае идентичная настройка на разных машинах приводила к непредсказуемым результатам. NekoRay — круто, но так и не разобрался с автозапуском в режиме TUN, просто лень уже было.. и опять же.. давай настраивай его, но уже, спасибо, проще чем CFW..

• Гибкое проксирование трафика (встречаем Clash for Windows)

• Гибкое проксирование трафика (NekoBox или NekoRay)

Поиск большей информации по параметрам конфигов NekoBox, описание на Github — Qt based cross-platform GUI proxy configuration manager (backend: sing-box), привели сюда, и заставили думать зачем мне графический интерфейс, я хочу "мало весящий архив — распаковал — запустил — работает".

Так вот, мой конфиг Sing-Box (урезан в правилах конечно же 🫡)

Настроен под работу с VMess

{

"log": {

"level": "info",

"timestamp": true

},

"dns": {

"servers": [

{

"tag": "google",

"address": "tls://8.8.8.8"

},

{

"tag": "cloudflare",

"address": "https://1.1.1.1/dns-query"

},

{

"tag": "local",

"address": "223.5.5.5"

}

],

"rules": [

{

"outbound": "any",

"server": "local"

}

]

},

"inbounds": [

{

"type": "tun",

"inet4_address": "172.16.0.1/30",

"interface_name": "Sing-Box Kravenrus",

"auto_route": true,

"strict_route": true,

"sniff": true,

"domain_strategy": "prefer_ipv4"

}

],

"outbounds": [

{

"type": "direct",

"tag": "direct-out"

},

{

"type": "vmess",

"tag": "vmess-out",

"server": "109.120.129.231",

"server_port": 27589,

"uuid": "1f429211-0a5f-4e1c-a798-53aa709ac672",

"security": "auto",

"alter_id": 0,

"global_padding": false,

"authenticated_length": true,

"tls": {},

"packet_encoding": "",

"transport": {},

"multiplex": {}

},

{

"type": "dns",

"tag": "dns-out"

}

],

"route": {

"rules": [

{

"rule_set": "github-rule-set",

"outbound": "vmess-out"

},

{

"domain_suffix": [

"amd.com",

"apple.com"

],

"outbound": "vmess-out"

},

{

"protocol": "dns",

"outbound": "dns-out"

},

{

"domain_keyword": [

"whatismyip",

"openai",

"chatgpt"

],

"outbound": "vmess-out"

},

{

"process_name": [

"steam.exe",

"steamservice.exe",

"steamwebhelper.exe"

],

"outbound": "direct-out"

},

{

"process_name": [

"Guilded.exe",

"firefox.exe"

],

"outbound": "vmess-out"

},

{

"ip_cidr": [

"66.22.192.0/18"

],

"outbound": "vmess-out"

},

{

"port_range": [

"50000:65535"

],

"outbound": "vmess-out"

}

],

"rule_set": [

{

"type": "remote",

"tag": "github-rule-set",

"format": "binary",

"url": "https://github.com/.../rule-set.srs",

"download_detour": "vmess-out"

}

],

"auto_detect_interface": true

},

"experimental": {

"cache_file": {

"enabled": true

}

}

}

Описание параметров конфигурации

Конфигурационный файл Sing-Box представляет собой JSON-документ, в котором указаны параметры настройки логирования, DNS-серверов, входящих и исходящих соединений, правил маршрутизации и экспериментальных функций. Более подробно про конфигурацию описано здесь. Вот что значат мои параметры:

Логирование (log)

• level: Уровень логирования. В данном случае "info" — для записи информационных сообщений. Возможны значения: debug, info, warn, error, fatal.

• timestamp: Если true, то в логе будет включено время записи каждого сообщения.

DNS (dns)

• servers: Список DNS-серверов, которые будут использоваться.

  • tag: Метка для сервера, чтобы его можно было идентифицировать.

  • address: Адрес DNS-сервера, может использовать различные протоколы (например, tls://8.8.8.8 или https://1.1.1.1/dns-query).

• rules: Определяет правила выбора сервера DNS для различных типов трафика.

  • outbound: Задает тип исходящего соединения, для которого будет использован сервер DNS.

  • server: Выбранный сервер DNS, указанный по tag в списке серверов.

Входящие подключения (inbounds)

• type: Тип входящего подключения. В данном случае это tun (виртуальный туннельный интерфейс).

• inet4_address: IPv4-адрес, который будет использоваться для туннеля.

• interface_name: Имя интерфейса, под которым будет создан туннель.

• auto_route: Автоматически добавляет маршруты для трафика.

• strict_route: Определяет, нужно ли строго следовать заданным маршрутам.

• sniff: Если включено, Sing-Box будет пытаться анализировать (сниффить) трафик, чтобы определить его тип.

• domain_strategy: Стратегия выбора IP-адреса. "prefer_ipv4" означает, что будет предпочтение отдаваться IPv4-адресам.

Исходящие подключения (outbounds)

• type: Тип исходящего подключения. Возможные значения включают:

  • direct: Для прямого подключения.

  • vmess: Протокол VMess, используемый для соединений через серверы.

  • dns: Используется для выхода на DNS-сервисы.

• tag: Метка для идентификации исходящего подключения.

• server и server_port: IP-адрес и порт сервера, к которому будет подключаться клиент (для vmess).

• uuid: Уникальный идентификатор пользователя, необходимый для VMess.

• security: Уровень шифрования (например, "auto").

• alter_id: Настройка дополнительного шифрования в VMess (0 означает отсутствие дополнительных идентификаторов).

• global_padding и authenticated_length: Опции шифрования и целостности пакетов.

• tls и packet_encoding: Параметры для использования TLS и кодирования пакетов.

• transport и multiplex: Опции транспорта и мультиплексирования.

Маршрутизация (route)

• rules: Список правил маршрутизации:

  • rule_set: Название набора правил, который будет использован.

  • outbound: Исходящее подключение для трафика, соответствующего данному правилу.

  • domain_suffix: Трафик к доменам с определенными суффиксами будет направлен через указанный outbound.

  • protocol: Протокол, для которого применяется правило.

  • domain_keyword и process_name: Позволяет указать ключевые слова или названия процессов для фильтрации.

  • ip_cidr и port_range: Указывает диапазоны IP-адресов и портов, на которые применяется правило.

• rule_set: Задает дополнительные настройки для набора правил, например, возможность скачивания с удаленного ресурса (url) и использование определенного исходящего канала для загрузки (download_detour).

• auto_detect_interface: Опция автоматического обнаружения сетевого интерфейса.

Экспериментальные функции (experimental)

• cache_file: Настройки кэширования.

  • enabled: Если true, кэширование включено для улучшения производительности, исключает скачивание набора правил, если удаленный набор не был изменен.

Эти настройки позволяют гибко настраивать поведение Sing-Box в соответствии с потребностями сети и требованиями безопасности.

Подробное описание моих правил (для общего понимания)

Правила в разделе rules определяют, каким образом будет маршрутизироваться трафик в зависимости от условий и характеристик соединений. Вот к какому поведению приведут указанные мною правила:

Использование удаленного набора правил (rule_set)

Трафик, соответствующий набору правил из файла по URL, будет перенаправляться через выход vmess-out. Этот файл может содержать динамически обновляемые правила для более гибкого и актуального управления трафиком.

Маршрутизация по доменным суффиксам

Все запросы к доменам с суффиксами amd.com и apple.com будут отправляться через vmess-out. Это может быть полезно для безопасного или анонимного доступа к этим ресурсам.

DNS-запросы

Весь трафик, использующий протокол dns, будет направляться через исходящее соединение dns-out, что обеспечивает отдельный канал для запросов к DNS-серверам.

Маршрутизация по ключевым словам доменов

Любые запросы к доменам, содержащим ключевые слова whatismyip, openai, и chatgpt, будут отправляться через vmess-out. Это позволит обеспечить дополнительную защиту или конфиденциальность для доступа к этим сервисам.

Маршрутизация по названию процессов:

Запросы от процессов steam.exe, steamservice.exe, и steamwebhelper.exe будут отправлены напрямую (direct-out), что может сократить задержки при использовании Steam.

Запросы от процессов Guilded.exe и firefox.exe будут направляться через vmess-out, обеспечивая безопасность или проксирование для этих приложений.

Маршрутизация по диапазону IP-адресов (ip_cidr)

Трафик, направленный к IP-адресам в диапазоне 66.22.192.0/18, будет отправляться через vmess-out. Это может использоваться для маршрутизации специфического трафика, связанного с этим диапазоном.

Маршрутизация по диапазону портов (port_range)

Трафик на порты в диапазоне 50000:65535 будет направляться через vmess-out, что может быть полезно для приложений, использующих высокие порты (например, игровые или P2P-сервисы, голосовые каналы).

В целом, данные правила создают избирательную маршрутизацию для обеспечения безопасности, проксирования доступа к определенным сервисам и выполнения DNS-запросов через специальное соединение.

Про распространение знакомым

Для начала задумался над простотой старта, создал .bat для запуска от имени Администратора

@Echo off

reg add HKCU\Console /v VirtualTerminalLevel /t REG_DWORD /d 1 /f

cd /d "%~dp0"

set "config_file="

for %%F in (config-vmess-*.json) do (

set "config_file=%%F"

goto :found

)

:found

if defined config_file (

start "Sing-Box" sing-box.exe run -c "%config_file%"

) else (

echo Файл не найден!

)

Для корректного отображения цвета, скрипт изменяет ключ VirtualTerminalLevel на единицу. Далее ищет конфиг по шаблону (поскольку я передаю пользователям его в виде config-vmess-uuid.json) и запускает Sing-Box с первым найденным конфигом в новом окне.

Дабы не объяснять что откуда скачать, что куда скопировать было решено отправлять знакомым только их UUID для дальнейшей генерации архива с исполняемым файлом Sing-Box и их файлом конфигурации (с внесенным изменением соответствующего поля UUID на цифры пользователя), создал страницу с формой.

Далее от пользователя требуется как раз таки только скачать и распаковать архив, и запустить run.cmd от имени Администратора.

Итог

Ну а итоги те же, что и были ожидаемы исходя из правил :)

Жаль, что есть и проблемы, на двух-трех машинах из 15-ти либо не поднимается TUN, либо трафик не проксируется должным образом, либо не работает доступ напрямую, и все это из-за настройки пользователем своей операционной системы, а именно сетевых настроек, если человек туда не лез, то и проблем не возникало..

О выше упомянутых протоколах — Shadowsocks и VMess (V2Ray) написано тут.

Как я говорил ранее, не имеет значения где раздобудете прокси, у меня к примеру имеется виртуальный сервер с 3X-UI на борту, где я и создал подключение с протоколом Shadowsocks (тут пример моей конфигурации) и VMess (для данного протокола тут).

Пример кастомных маршрутов (JSON) скармливаемых NekoBox

{

"rules": [

{

"domain_suffix": [

"google.com",

"www.myip.com"

],

"outbound": "proxy"

},

{

"domain_keyword": [

"myip",

"2ip"

],

"outbound": "proxy"

},

{

"outbound": "proxy",

"process_name": [

"firefox.exe",

"Guilded.exe"

]

}

]

}

Описание параметров:

• domain_suffix включает домены, которые направляются через прокси.

• domain_keyword включает ключ. слова для доменов, которые должны идти через прокси.

• process_name задаёт процессы, которые используют прокси.

Их больше, но я не смог найти документации по всем (выцеплял необходимые мне с GitHub), если у кого есть информация по всем параметрам, поделитесь пожалуйста :)

Подробное описание моих правил (для общего понимания)

domain_suffix,google.com,Proxy

Это правило указывает проксировать все запросы к доменам, оканчивающимся на google.com через группу прокси Proxy. Например, любые страницы, такие как www.google.com, mail.google.com, drive.google.com будут направлены через прокси.

domain_suffix,www.myip.com,Proxy

Аналогично первому правилу, все запросы к www.myip.com будут проходить через прокси Proxy. Это используется для того, чтобы тестировать IP-адрес через сайт www.myip.com.

domain_keyword,myip,Proxy

Это правило указывает, что любые домены, содержащие ключевое слово myip в любом месте, будут проксироваться через Proxy. Например, такие домены как myip.com, checkmyip.net и т. д. будут направлены через прокси.

domain_keyword,2ip,Proxy

Здесь указано, что все домены, содержащие слово 2ip, также будут проксироваться через Proxy. Это может включать сайты вроде 2ip.ru, которые используют этот поддомен для проверки IP-адресов.

process_name,firefox.exe,Proxy

Это правило указывает, что все трафики, исходящие от процесса firefox.exe, должны быть направлены через прокси Proxy. Это означает, что при использовании браузера Firefox весь интернет-трафик будет проходить через прокси.

process_name,Guilded.exe,Proxy

Здесь указано, что весь трафик приложения Guilded.exe (клиент для геймеров, аналог Discord) будет направлен через прокси Proxy.

Резюме для приложений:

• Firefox и Guilded: Все их трафики полностью идут через прокси.

• Chrome: Нет явного правила для chrome.exe, следовательно, его трафик будет направляться напрямую, если он не попадает под доменные правила.

• Сайты с доменами google.com, myip.com, 2ip.ru: Эти домены всегда будут проксироваться, независимо от браузера или процесса.

• Сайты с американскими и российскими IP-адресами: Сейчас их трафик идет через прокси, так как правила для GEOIP,RU и GEOIP,US закомментированы.

Перейдем к NekoBox (NekoRay)

Для начала перейдем к кастомным правилам маршрутизации, оформляется все в формате JSON, пример выше.. Outbound по умолчанию — bypass, нужен для корректной работы белого-списка в настройках TUN-режима (при использовании кастомных правил, необходимости особой нет туда лезть), можно включить, так скажем на будущее :)

После описания необходимых правил (можно и до редактирования кастомных маршрутов) нужно добавить профиль подключения к прокси из буфера или отсканировав QR на экране (варианты добавления профилей порадовали). Включить TUN режим (важно для UDP трафика, используется голосовыми каналами Guilded). И соответственно запустить добавленный профиль.

Итог

Осталась последняя задача, запускать при загрузке ОС с активацией последнего профиля в TUN режиме (он не включается по умолчанию, прав не хватает при автозапуске, добавление в HKLM что-то проблему не решило), найду ответ дополню пост :)

• Лучше использовать, если вам нужна простота и скорость.

• Подходит для большинства пользователей, которые не хотят углубляться в детали.

VMess (V2Ray):

• Лучше использовать, если вам важна высокая безопасность и расширенные функции.

• Подходит для сложных сетей и пользователей, которые требуют гибкости в настройках.

• Лучше защищает трафик и предлагает дополнительные возможности, такие как мультиплексирование.

Если вы новичок, Shadowsocks может быть удобнее. Для более опытных пользователей с повышенными требованиями к безопасности стоит рассмотреть VMess.

Не имеет значения где раздобудете прокси, у меня к примеру имеется виртуальный сервер с 3X-UI на борту, где я и создал подключение с протоколом Shadowsocks (тут пример моей конфигурации) и VMess (для данного протокола ниже).

Примеры файлов конфигураций (.yaml) скармливаемый в Clash for Windows

Для Shadowsocks

proxies:

- name: "My Shadowsocks Proxy"

type: ss

server: *.*.*.*

port: 55223

cipher: chacha20-ietf-poly1305

password: BnGHogsywi0ZpTgSnjca2ELit5XhMnG/l9pTCiHjHTI=

udp: true

proxy-groups:

- name: "Proxy"

type: select

proxies:

- "My Shadowsocks Proxy"

- DIRECT

rules:

- DOMAIN-SUFFIX,google.com,Proxy

- DOMAIN-SUFFIX,www.myip.com,Proxy

- DOMAIN-KEYWORD,myip,Proxy

- DOMAIN-KEYWORD,2ip,Proxy

- PROCESS-NAME,firefox.exe,Proxy

- PROCESS-NAME,Guilded.exe,Proxy

# - GEOIP,RU,DIRECT

# - GEOIP,US,DIRECT

- MATCH,DIRECT

Для VMess (V2Ray)

proxies:

- name: "My V2Ray Proxy"

type: vmess

server: *.*.*.*

port: 27789

uuid: 1f829011-0a5f-4e1c-a797-57aa709ec672

alterId: 0

cipher: auto

tls: false

network: tcp

ws-opts:

path: "/"

headers:

Host: ""

proxy-groups:

- name: "Proxy"

type: select

proxies:

- "My V2Ray Proxy"

- DIRECT

rules:

- DOMAIN-SUFFIX,google.com,Proxy

- DOMAIN-SUFFIX,www.myip.com,Proxy

- DOMAIN-KEYWORD,myip,Proxy

- DOMAIN-KEYWORD,2ip,Proxy

- PROCESS-NAME,firefox.exe,Proxy

- PROCESS-NAME,Guilded.exe,Proxy

# - GEOIP,RU,DIRECT

# - GEOIP,US,DIRECT

- MATCH,DIRECT

Описание параметров конфигурации

Вот полное описание параметров конфигурации Clash for Windows, которое объединяет оба ваших конфига (для Shadowsocks и V2Ray):

Раздел proxies

• proxies: Главный раздел для определения всех прокси-серверов, доступных в конфигурации.

  • name: Имя для идентификации прокси-сервера. Например, "My Shadowsocks Proxy" или "My V2Ray Proxy".

  • type: Тип прокси-сервера. Возможные значения:

    • ss: для Shadowsocks.

    • vmess: для V2Ray.

  • server: IP-адрес или доменное имя прокси-сервера. Например, 102.130.133.251.

  • port: Порт, на котором прокси-сервер принимает соединения. Например, 55223 для Shadowsocks и 27789 для V2Ray.

  • cipher: Алгоритм шифрования, используемый для защиты данных. Например, chacha20-ietf-poly1305 для Shadowsocks и auto для V2Ray, который выбирает наиболее подходящий метод.

  • password: Пароль для аутентификации на прокси-сервере. Применяется только для Shadowsocks.

  • uuid: Уникальный идентификатор пользователя (UUID) для аутентификации в V2Ray. Например, 1f829011-0a5f-4e1c-a797-57aa709ec672.

  • alterId: Значение, определяющее дополнительную идентификацию (обычно используется в V2Ray). Для V2Ray может быть 0.

  • tls: Логическое значение (true/false), указывающее, используется ли шифрование TLS для V2Ray. Например, false.

  • network: Протокол передачи данных для V2Ray, например, tcp для использования TCP-протокола.

  • ws-opts: Настройки для WebSocket (если используется). Включает:

    • path: Путь для WebSocket-соединения, например, "/".

    • headers: Дополнительные заголовки, такие как Host, которые могут быть необходимы для маршрутизации трафика.

Раздел proxy-groups

• proxy-groups: Раздел для определения групп прокси-серверов, доступных для выбора в интерфейсе Clash.

  • name: Название группы прокси-серверов. Например, "Proxy".

  • type: Тип группы, например:

    • select: Позволяет пользователю вручную выбирать прокси из списка.

    • url-test: Автоматически выбирает лучший прокси по времени отклика (не используется в ваших конфигурациях).

  • proxies: Список названий прокси-серверов, входящих в эту группу. Например, список может содержать "My Shadowsocks Proxy" и "My V2Ray Proxy".

Раздел rules

• rules: Этот раздел определяет правила маршрутизации, которые управляют тем, какой трафик будет проксироваться и каким образом.

  • DOMAIN-SUFFIX: Прокси для всех запросов к доменам с указанным суффиксом.

  • DOMAIN-KEYWORD: Прокси для всех запросов к доменам, содержащим указанное ключевое слово.

  • PROCESS-NAME: Прокси для трафика, исходящего от конкретного процесса.

  • GEOIP: Правило для маршрутизации трафика на основе географического положения IP-адресов.

  • MATCH: Правило по умолчанию, которое применяется, если ни одно из предыдущих правил не сработало.

Заключение

Эти параметры помогают настроить и очень гибко управлять проксированием трафика, обеспечивая возможность выбора между несколькими прокси-серверами и контролируя, как и какой трафик проходит через них.

Подробное описание моих правил (для общего понимания)

DOMAIN-SUFFIX,google.com,Proxy

Это правило указывает проксировать все запросы к доменам, оканчивающимся на google.com через группу прокси Proxy. Например, любые страницы, такие как www.google.com, mail.google.com, drive.google.com будут направлены через прокси.

DOMAIN-SUFFIX,www.myip.com,Proxy

Аналогично первому правилу, все запросы к www.myip.com будут проходить через прокси Proxy. Это используется для того, чтобы тестировать IP-адрес через сайт www.myip.com.

DOMAIN-KEYWORD,myip,Proxy

Это правило указывает, что любые домены, содержащие ключевое слово myip в любом месте, будут проксироваться через Proxy. Например, такие домены как myip.com, checkmyip.net и т. д. будут направлены через прокси.

DOMAIN-KEYWORD,2ip,Proxy

Здесь указано, что все домены, содержащие слово 2ip, также будут проксироваться через Proxy. Это может включать сайты вроде 2ip.ru, которые используют этот поддомен для проверки IP-адресов.

PROCESS-NAME,firefox.exe,Proxy

Это правило указывает, что все трафики, исходящие от процесса firefox.exe, должны быть направлены через прокси Proxy. Это означает, что при использовании браузера Firefox весь интернет-трафик будет проходить через прокси.

PROCESS-NAME,Guilded.exe,Proxy

Здесь указано, что весь трафик приложения Guilded.exe (клиент для геймеров, аналог Discord) будет направлен через прокси Proxy.

Закомментированные строки не действуют (так как перед ними стоит символ #), но их можно легко активировать, убрав комментарий. Сейчас они отключены, и вот их назначение:

GEOIP,RU,DIRECT

Это правило отключено, но если бы оно было активным, оно направляло бы весь трафик с геолокацией Россия (RU) напрямую (не через прокси), минуя прокси-сервер. Оно могло бы быть полезным, если вы не хотите проксировать запросы к российским сайтам.

GEOIP,US,DIRECT

Это правило, если активировать, перенаправляло бы трафик для всех IP-адресов, относящихся к США (US) напрямую, также минуя прокси. Это может быть полезно, если не требуется проксировать сайты с американскими IP.

MATCH,DIRECT

Правило MATCH является универсальным, оно действует как правило "по умолчанию". Если ни одно из вышеуказанных правил не сработало, то оно применяет это правило и направляет все оставшиеся запросы напрямую (DIRECT).

Резюме для приложений:

• Firefox и Guilded: Все их трафики полностью идут через прокси.

• Chrome: Нет явного правила для chrome.exe, следовательно, его трафик будет направляться напрямую, если он не попадает под доменные правила.

• Сайты с доменами google.com, myip.com, 2ip.ru: Эти домены всегда будут проксироваться, независимо от браузера или процесса.

• Сайты с американскими и российскими IP-адресами: Сейчас их трафик идет через прокси, так как правила для GEOIP,RU и GEOIP,US закомментированы.

Перейдем к Clash for Windows

Основная настройка софта производится на вкладке General

Для работы в режиме TUN обязательно необходимо установить Service Mode

Файлы конфигурации можно добавить с помощью Drag and Drop (перетащив в окно программы). Далее выбираем конфигурацию, согласно которой необходимо работать (выбранная отмечена зеленым)

На вкладке Proxies можно выбрать способ проксирования, в данном случае согласно правилам, описанным в файлах конфигурации

Connections отражает текущие соединения

Программа работает следующим образом: имеются два подключения DIRECT (поднимается по умолчанию для всего трафика) и PROXY (добавляется вручную), весь трафик идет через нее. Согласно способу проксированию, при необходимости правилам, определенный трафик уходит через PROXY. В режиме DIRECT на вкладке Proxies весь трафик будет проходить через локальный прокси, но не будет направляться на внешний прокси-сервер, соответственно правила игнорируются.

Итог

Не имеет значения где раздобудете прокси, у меня к примеру имеется виртуальный сервер с 3X-UI на борту, где я и создал подключение с протоколом Shadowsocks. Обратите внимание на параметр сеть — TCP/UDP, ваш прокси должен уметь работать с обоими протоколами.

А теперь по порядку..

После установки ProxyCap обязательно необходимо перезагрузить компьютер. Далее открываем конфигурацию и создаем подключение

• Type: shadowsocks (нам важна поддержка UDP, SOCKS5 его поддерживает, но я не проверял)

• Hostname: IP-адрес или соответственно имя хоста (сервера)

• Port: порт, на котором работает ваш прокси-сервер

• Password: пароль пользователя прокси (см. добавл. пользователя к подключению в 3X-UI)

После создания подключения проверяем, что все работает :)

И самое главное, для чего это все.. В конфигурации переходим к правилам, создаем новое, указываем исполняемый файл программы, которую необходимо пускать через прокси, если софт использует UDP протокол (Guilded его использует для голосовых каналов) — ставим соответствующую галку

Итог