В nekoray на windows 10:
tun mode whitelist работает некорректно и пускает через себя всю систему, а должен только процессы из whitelist

благодарю, буду пробовать

Отслеживание процессов работает только в режиме TUN. Если вы выбрали “Встроенный Tun*”, в этом режиме TUN конфиг объединиться с обычным и будет запущено не два xray или sing-box, а лишь один с общим конфигом. TUN работает как виртуальное подключение и в любом случае весь трафик прогоняет через себя, нужен он чтобы видеть путь к процессу и на основе этого фильтровать.

Так вот, когда используется моно процесс - конфиг кривой, вы можете в этом убедится через “Поделится → Экспортировать конфиг”.

Основная заминка в том, что по умолчанию в маршрутах “final” установлен как “proxy”, а в режиме разделённых окон для TUN “final” прописан как “bypass”. Какие тут есть варианты?

1. Самый простой, отключаем “Встроенный Tun*” чтобы для процессов запускался отдельный конфиг, для всего остального тоже;
2. Настраиваем всё ручками используя logical правила.

К примеру я придерживаюсь следующего принципа для стратегии final: proxy только для выбранных процессов.

в rules на самое дно опускаем правило для процесса

      {
        "outbound": "proxy",
        "process_name": [
          "Discord.exe",
          "Update.exe"
        ]
      }

поднимаемся на верх и меняем final на bypass

    "final": "bypass",

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

 "route": {
   "final": "bypass",
   "rules": [
     { // Если нужно наложение для процесса используем logical, полезно для geocdn или youtube после google
       "type": "logical",
       "mode": "and",
       "rules": [
         {
           "geosite": [
             "discord",
             "youtube"
           ]
         },
         {
           "process_name": [
             "Discord.exe",
             "Update.exe"
           ]
         }
       ],
       "outbound": "proxy"
     },
     { // Перебиваем для всего гео домены
       "domain_suffix": [
         ".ir"
       ],
       "geosite": [
         "google"
       ],
       "outbound": "bypass"
     },
     { // Перебиваем для всего geo ip
       "geoip": [
         "ir"
       ],
       "outbound": "bypass"
     },
     { // Перебиваем для всего приватные ip
       "ip_is_private": true,
       "outbound": "bypass"
     },
     { // Только для процессов выводим в прокси
       "outbound": "proxy",
       "process_name": [
         "Discord.exe",
         "Update.exe"
       ]
     }
   ]
 }

Что мы на выходе получаем? Остаётся полный TUN для выбранных процессов, а весь остальной трафик идёт напрямую? У меня проблема похожая. Скачав последнюю бетку 4.0, со встроенным туном у меня белый список работает, проксирует только то, что нужно, но при открытии сайтов из браузера, который в белый список для проксирования не входит, неко все равно проводит некую обработку, пропускает через сервак судя по всему, понимает что проксировать не нужно и пускает байпасом. Т.е. некий инпут лаг я чувствую при этом сценарии, и хочу поинтересоваться, при данном конфиге эта проблема пофиксится?

Если использовать подобную схему, то да, мы на выходе получаем проксирование только определенных процессов. Если нет каких либо дополнительных правил схему можно сократить до

"route": {
  "final": "bypass",
    { // Перебиваем для всего приватные ip
      "ip_is_private": true,
      "outbound": "bypass"
    },
    { // Только для процессов выводим в прокси
      "outbound": "proxy",
      "process_name": [
        "Discord.exe",
        "Update.exe"
      ]
    }
  ]
}

Аналогичные правила хорошо бы и для dns секции добавить.

Относительно инпут лага, он в схеме с TUN в любом случае будет при старте соединения (1-3ms зависимо от раздутых правил), если хотите полностью его избежать, то это возможно только с ручной настройкой прокси в приложениях где это возможно и никак иначе, чтобы именно само приложение определяло для себя куда ходить.

ну там как будто не 1-3ms, я так замечаю, если сам сервак перегружен впски, то оно может и несколько секунд висеть

Не должно, только если sniff_override_destination или reverse_mapping в true, так как они насилуют dns, правила отрабатывают локально, для самой машины задержка должна быть минимальна, мы естественно говорим про локальный клиент и фильтрацию локальных процессов. При тормознутом DNS и множестве запросов можно попробовать переписать TTL в dns правилах "rewrite_ttl": 28800 и включить кеш для отказов "store_rdrc": true

“sniff_override_destination”: false , а reverse_mapping вообще нету

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

INFO[0603] [3201561675 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx
INFO[0603] [3201561675 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0603] [3201561675 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0603] dns: exchanged stats.vk-portal.net A stats.vk-portal.net. 272 IN A xx.xx.xx.xx
INFO[0603] [1058693205 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:xx.xx.xx.xx
INFO[0603] [1058693205 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0603] [1058693205 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0603] [1058693205 0ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0603] dns: exchanged stats.vk-portal.net A stats.vk-portal.net. 272 IN A xx.xx.xx.xx
INFO[0604] [2470248214 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:64874
INFO[0604] [2470248214 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0604] [2470248214 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0604] dns: exchanged bifrost.vivaldi.com A bifrost.vivaldi.com. 120 IN A xx.xx.xx.xx
INFO[0604] [27643922 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61875
INFO[0604] [27643922 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0604] [27643922 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0604] [27643922 0ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0604] dns: exchanged bifrost.vivaldi.com A bifrost.vivaldi.com. 120 IN A xx.xx.xx.xx
ERROR[0608] dns: exchange failed for ozon.ru. IN A: lookup ozon.ru: i/o timeout
ERROR[0608] dns: exchange failed for ozon.ru. IN A: lookup ozon.ru: operation was canceled
ERROR[0608] dns: exchange failed for ozon.ru. IN A: lookup ozon.ru: operation was canceled
ERROR[0608] dns: exchange failed for ozon.ru. IN A: lookup ozon.ru: operation was canceled
ERROR[0608] dns: exchange failed for ozon.ru. IN A: lookup ozon.ru: operation was canceled
INFO[0609] [3401884075 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:60228
INFO[0609] [3401884075 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0609] [3401884075 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0609] [1765476771 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:60985
INFO[0609] [1765476771 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0609] [1765476771 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0609] [1765476771 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0609] dns: exchanged dns.msftncsi.com A dns.msftncsi.com. 17 IN A xx.xx.xx.xx
INFO[0609] dns: exchanged dns.msftncsi.com A dns.msftncsi.com. 17 IN A xx.xx.xx.xx
INFO[0609] [778881140 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:63454
INFO[0609] [778881140 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0609] [778881140 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0615] [867408169 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:60111
INFO[0615] [867408169 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0615] [867408169 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0615] [867408169 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0615] [3449262751 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:50307
INFO[0615] [3449262751 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0615] [3449262751 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0616] dns: exchanged play.google.com A play.google.com. 300 IN A xx.xx.xx.xx
INFO[0616] [1520234091 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:54243
INFO[0616] [1520234091 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0616] [1520234091 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0616] dns: cached play.google.com A play.google.com. 299 IN A xx.xx.xx.xx
INFO[0616] [3348733976 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61877
INFO[0616] [3348733976 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0616] [3348733976 1ms] outbound/vless[proxy]: outbound connection to xx.xx.xx.xx:443
INFO[0616] dns: exchanged play.google.com A play.google.com. 197 IN A xx.xx.xx.xx
INFO[0616] dns: exchanged play.google.com SOA google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. xx.xx.xx.xx
INFO[0616] dns: exchanged play.google.com SOA google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. xx.xx.xx.xx
INFO[0616] [3348733976 148ms] outbound/vless[proxy]: outbound connection to xx.xx.xx.xx:443
ERROR[0619] dns: exchange failed for www.ozon.ru. IN A: lookup www.ozon.ru: i/o timeout
ERROR[0619] dns: exchange failed for www.ozon.ru. IN A: lookup www.ozon.ru: operation was canceled
ERROR[0619] dns: exchange failed for www.ozon.ru. IN A: lookup www.ozon.ru: operation was canceled
ERROR[0619] dns: exchange failed for www.ozon.ru. IN A: lookup www.ozon.ru: operation was canceled
ERROR[0619] dns: exchange failed for www.ozon.ru. IN A: lookup www.ozon.ru: operation was canceled
INFO[0620] [838971003 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:57997
INFO[0620] [838971003 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0620] [838971003 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0620] [838971003 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0620] [684439540 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:60987
INFO[0620] [684439540 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0620] [1576783644 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:51059
INFO[0620] [1576783644 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0620] [684439540 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0620] [1576783644 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0620] [684439540 1ms] outbound/direct[bypass]: outbound packet connection
INFO[0620] [4079921284 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:53468
INFO[0620] [4079921284 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0620] [4079921284 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0621] [1326365875 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:62525
INFO[0621] [1326365875 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0621] [1326365875 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0621] dns: exchanged cdn1.ozonusercontent.com CNAME cdn1.ozonusercontent.com. 221 IN CNAME edge-mmedia-lb.ozone.ru.
INFO[0621] dns: exchanged cdn1.ozonusercontent.com A edge-mmedia-lb.ozone.ru. 221 IN A xx.xx.xx.xx
INFO[0621] dns: exchanged cdn1.ozonusercontent.com A edge-mmedia-lb.ozone.ru. 221 IN A xx.xx.xx.xx
INFO[0621] [567517468 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:63869
INFO[0621] [567517468 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0621] [567517468 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0621] [567517468 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0621] dns: exchanged cdn1.ozonusercontent.com CNAME cdn1.ozonusercontent.com. 96 IN CNAME edge-mmedia-lb.ozone.ru.
INFO[0621] dns: exchanged cdn1.ozonusercontent.com A edge-mmedia-lb.ozone.ru. 96 IN A xx.xx.xx.xx
INFO[0621] dns: exchanged cdn1.ozonusercontent.com A edge-mmedia-lb.ozone.ru. 96 IN A xx.xx.xx.xx
INFO[0621] [1620951015 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61879
INFO[0621] [1620951015 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0621] [1620951015 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0621] [1620951015 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0621] [4090609774 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61881
INFO[0621] [4090609774 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:8080
INFO[0621] [4090609774 0ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:8080
ERROR[0630] dns: exchange failed for st.ozone.ru. IN A: lookup st.ozone.ru: i/o timeout
ERROR[0630] dns: exchange failed for st.ozone.ru. IN A: lookup st.ozone.ru: operation was canceled
ERROR[0630] dns: exchange failed for st.ozone.ru. IN A: lookup st.ozone.ru: operation was canceled
ERROR[0630] dns: exchange failed for st.ozone.ru. IN A: lookup st.ozone.ru: operation was canceled
ERROR[0630] dns: exchange failed for st.ozone.ru. IN A: lookup st.ozone.ru: operation was canceled
ERROR[0631] dns: exchange failed for ir-2.ozone.ru. IN A: lookup ir-2.ozone.ru: i/o timeout
ERROR[0631] dns: exchange failed for ir-2.ozone.ru. IN A: lookup ir-2.ozone.ru: operation was canceled
ERROR[0631] dns: exchange failed for ir-2.ozone.ru. IN A: lookup ir-2.ozone.ru: operation was canceled
ERROR[0631] dns: exchange failed for ir-2.ozone.ru. IN A: lookup ir-2.ozone.ru: operation was canceled
ERROR[0631] dns: exchange failed for ir-2.ozone.ru. IN A: lookup ir-2.ozone.ru: operation was canceled
INFO[0632] [3185401635 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:57432
INFO[0632] [3185401635 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0632] [3185401635 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [3185401635 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0632] [555816126 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61883
INFO[0632] [555816126 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [555816126 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [555816126 0ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0632] [1233291715 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:62710
INFO[0632] [1233291715 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0632] [1233291715 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [1233291715 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0632] [1641750125 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61885
INFO[0632] [1641750125 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [1641750125 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [1641750125 0ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
ERROR[0632] [1083690989 5m41s] inbound/tun[tun-in]: download: raw-read tcp xx.xx.xx.xx:61604->xx.xx.xx.xx:80: An existing connection was forcibly closed by the remote host.
INFO[0632] [2399230989 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:59154
INFO[0632] [2399230989 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0632] [2399230989 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0632] [2600775942 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:63090
INFO[0632] [2600775942 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0632] [2600775942 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0632] [3849125006 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:52753
INFO[0632] [3849125006 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0632] [3849125006 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0632] dns: exchanged ocsp.globalsign.com CNAME ocsp.globalsign.com. 234 IN CNAME global.prd.cdn.globalsign.com.
INFO[0632] dns: exchanged ocsp.globalsign.com CNAME global.prd.cdn.globalsign.com. 234 IN CNAME cdn.globalsigncdn.com.cdn.cloudflare.net.
INFO[0632] dns: exchanged ocsp.globalsign.com A cdn.globalsigncdn.com.cdn.cloudflare.net. 234 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged ocsp.globalsign.com A cdn.globalsigncdn.com.cdn.cloudflare.net. 234 IN A xx.xx.xx.xx
INFO[0632] [1066541159 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61887
INFO[0632] [1066541159 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:80
INFO[0632] [1066541159 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [1066541159 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:80
INFO[0632] dns: exchanged ocsp.globalsign.com CNAME ocsp.globalsign.com. 276 IN CNAME global.prd.cdn.globalsign.com.
INFO[0632] dns: exchanged ocsp.globalsign.com CNAME global.prd.cdn.globalsign.com. 276 IN CNAME cdn.globalsigncdn.com.cdn.cloudflare.net.
INFO[0632] dns: exchanged ocsp.globalsign.com A cdn.globalsigncdn.com.cdn.cloudflare.net. 276 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged ocsp.globalsign.com A cdn.globalsigncdn.com.cdn.cloudflare.net. 276 IN A xx.xx.xx.xx
INFO[0632] [2651529950 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61889
INFO[0632] [2651529950 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [2826113552 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61890
INFO[0632] [2826113552 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [4181788425 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61891
INFO[0632] [4181788425 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [957016265 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61892
INFO[0632] [957016265 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [1338555140 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61893
INFO[0632] [1338555140 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] dns: exchanged s.deepl.com CNAME s.deepl.com. 300 IN CNAME hpkaj.deepl.com.
INFO[0632] dns: exchanged s.deepl.com CNAME hpkaj.deepl.com. 300 IN CNAME 46a2e5c3c5a64e218b60f2c2ee76b750.pacloudflare.com.
INFO[0632] dns: exchanged s.deepl.com A 46a2e5c3c5a64e218b60f2c2ee76b750.pacloudflare.com. 300 IN A xx.xx.xx.xx
INFO[0632] [2651529950 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [2651529950 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0632] [2826113552 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [2826113552 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0632] [4181788425 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [4181788425 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0632] [957016265 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [957016265 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0632] [1338555140 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [1338555140 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0632] [1135949303 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61899
INFO[0632] [1135949303 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [1135949303 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [1135949303 0ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0632] [3215767973 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:51198
INFO[0632] [3215767973 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx
INFO[0632] [3215767973 0ms] router: found process path: C:\Windows\System32\svchost.exe
INFO[0632] dns: exchanged s.deepl.com CNAME s.deepl.com. 300 IN CNAME hpkaj.deepl.com.
INFO[0632] dns: exchanged s.deepl.com CNAME hpkaj.deepl.com. 300 IN CNAME 46a2e5c3c5a64e218b60f2c2ee76b750.pacloudflare.com.
INFO[0632] dns: exchanged s.deepl.com A 46a2e5c3c5a64e218b60f2c2ee76b750.pacloudflare.com. 300 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] dns: exchanged 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com A 7ng6v3lu3c.execute-api.us-east-1.amazonaws.com. 60 IN A xx.xx.xx.xx
INFO[0632] [2297705604 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:55567
INFO[0632] [2297705604 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0632] [2297705604 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [2297705604 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0632] [1046287425 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61901
INFO[0632] [1046287425 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0632] [1046287425 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0632] [1046287425 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443
INFO[0633] [2543815819 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:55210
INFO[0633] [2543815819 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0633] [2543815819 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0633] [2543815819 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0633] [4018843444 0ms] inbound/tun[tun-in]: inbound packet connection from xx.xx.xx.xx:50685
INFO[0633] [4018843444 0ms] inbound/tun[tun-in]: inbound packet connection to xx.xx.xx.xx:443
INFO[0633] [4018843444 0ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0633] [4018843444 0ms] outbound/direct[bypass]: outbound packet connection
INFO[0633] [2543370102 0ms] inbound/tun[tun-in]: inbound connection from xx.xx.xx.xx:61903
INFO[0633] [2543370102 0ms] inbound/tun[tun-in]: inbound connection to xx.xx.xx.xx:443
INFO[0633] [2543370102 1ms] router: found process path: C:\Program Files\Application\vivaldi.exe
INFO[0633] [2543370102 1ms] outbound/direct[bypass]: outbound connection to xx.xx.xx.xx:443

dns для прямых запросов local? Если да, то попробуйте вписать какой-нибудь. Например https://1.1.1.1/dns-query

сейчас local, до этого doh.pub/dns-query был - то же самое

По ошибке явно мы не смогли достучаться до dns сервера, нужно убедится в его доступности из источника, дальше гадать всё равно что на кофейной гуще, так как нужен полный sing-box конфиг

При использовании TUN в качестве direct dns надо указывать стандартный незащищённый, идеально просто локальный (к примеру от роутера если стационар), вот минимальный жизнеспособный конфиг, где всё идёт в пропуск кроме chrome.exe, обращаю внимание, что также мы обязаны отлавливать dns запросы и заворачивать их на внутреннюю службу, в любом стандартном конфиге это будет даже при mixed

{
  "dns": {
    "final": "dns-direct",
    "independent_cache": true,
    "rules": [
      {
        "process_name": ["chrome.exe"],
        "server": "dns-remote"
      }
    ],
    "servers": [
      {
        "address": "https://dns.google/dns-query", // любой dns для проксированных
        "address_resolver": "dns-direct",
        "detour": "proxy", // только через прокси
        "strategy": "ipv4_only",
        "tag": "dns-remote"
      },
      {
        "address": "77.88.8.8", // незащищенный dns для прямых запросов
        "address_resolver": "dns-local",
        "detour": "direct", // только напрямую
        "strategy": "ipv4_only",
        "tag": "dns-direct"
      },
      {
        "address": "local",
        "detour": "direct",
        "tag": "dns-local"
      }
    ]
  },
  "inbounds": [
    {
      "auto_route": true,
      "domain_strategy": "ipv4_only",
      "endpoint_independent_nat": false,
      "inet4_address": "172.19.0.1/28",
      "interface_name": "neko-tun",
      "mtu": 9000,
      "sniff": true,
      "sniff_override_destination": false,
      "stack": "gvisor",
      "strict_route": false,
      "tag": "tun-in",
      "type": "tun"
    }
  ],
  "log": {
    "level": "warn"
  },
  "outbounds": [ // настройки прокси
    {
      "domain_strategy": "ipv4_only",
      "server": "192.168.1.1",
      "server_port": 1080,
      "tag": "proxy",
      "type": "socks"
    },
    {
      "tag": "direct",
      "type": "direct"
    },
    {
      "tag": "bypass",
      "type": "direct"
    },
    { // обязательно должно быть
      "tag": "dns-out",
      "type": "dns"
    }
  ],
  "route": {
    "auto_detect_interface": true,
    "final": "bypass",
    "rules": [ // ловим любые стандартные dns запросы
      {
        "outbound": "dns-out",
        "port": [53]
      },
      {
        "outbound": "dns-out",
        "protocol": "dns"
      },
      {
        "ip_is_private": true,
        "outbound": "bypass"
      },
      {
        "outbound": "proxy",
        "process_name": ["chrome.exe"]
      }
    ]
  }
}

прикол в том, что этот лог, который я скинул на "local"днсе и есть, и такое случается нередко, пару секунд пролаг и потом сайт загружается

значит локальный ресолвер уходит в луп или блочится, нужно узнать его адрес через nslookup и верхним правилом пропустить его, вероятнее всего там адрес из tun и добавление его сети исправит ситуацию

      {
        "outbound": "bypass",
        "ip_cidr": [
          "172.19.0.1/28"
        ],
        "protocol": "dns"
      }

но без полного конфига сложно судить

В твоём случае как и предлагал выше, либо вместо local в dns прописываешь публичный адрес без tls или https, обычный, стандартный 8.8.8.8, либо добавляешь в пропуск tun подсеть на dns запросы, и проверять это всё добро через nslookup, mixed если не раздаешь прокси можно грохнуть.

Или

{
  "dns": {
    "final": "dns-direct",
    "strategy": "ipv4_only",
    "independent_cache": true,
    "rules": [
      {
        "process_name": ["chrome.exe"],
        "server": "dns-remote"
      }
    ],
    "servers": [
      {
        "address": "https://dns.google/dns-query",
        "address_resolver": "dns-direct",
        "detour": "proxy",
        "tag": "dns-remote"
      },
      {
        "address": "tls://common.dot.dns.yandex.net",
        "address_resolver": "dns-local",
        "detour": "direct",
        "tag": "dns-direct"
      },
      {
        "address": "local",
        "detour": "direct-in",
        "tag": "dns-local"
      }
    ]
  },
  "inbounds": [
    {
      "auto_route": true,
      "endpoint_independent_nat": true,
      "inet4_address": "172.19.0.1/28",
      "interface_name": "neko-tun",
      "mtu": 9000,
      "sniff": true,
      "sniff_override_destination": false,
      "stack": "gvisor",
      "strict_route": false,
      "tag": "tun-in",
      "type": "tun"
    }
  ],
  "log": {
    "level": "warn"
  },
  "outbounds": [
    {
      "tag": "proxy",
      "type": "socks"
    },
    {
      "tag": "direct",
      "type": "direct"
    },
    {
      "tag": "bypass",
      "type": "direct"
    },
    {
      "tag": "dns-out",
      "type": "dns"
    }
  ],
  "route": {
    "auto_detect_interface": true,
    "final": "bypass",
    "rules": [
      {
        "outbound": "bypass",
        "ip_cidr": [
          "172.19.0.1/28"
        ],
        "protocol": "dns"
      },
      {
        "outbound": "dns-out",
        "protocol": "dns"
      },
      {
        "outbound": "dns-out",
        "protocol": "dns"
      },
      {
        "outbound": "proxy",
        "process_name": ["chrome.exe"]
      }
    ]
  }
}

или

{
  "dns": {
    "final": "dns-local",
    "strategy": "ipv4_only",
    "independent_cache": true,
    "rules": [
      {
        "process_name": ["chrome.exe"],
        "server": "dns-remote"
      }
    ],
    "servers": [
      {
        "address": "https://dns.google/dns-query",
        "address_resolver": "dns-local",
        "detour": "proxy",
        "tag": "dns-remote"
      },
      {
        "address": "8.8.8.8",
        "detour": "direct-in",
        "tag": "dns-local"
      }
    ]
  },
  "inbounds": [
    {
      "auto_route": true,
      "endpoint_independent_nat": true,
      "inet4_address": "172.19.0.1/28",
      "interface_name": "neko-tun",
      "mtu": 9000,
      "sniff": true,
      "sniff_override_destination": false,
      "stack": "gvisor",
      "strict_route": false,
      "tag": "tun-in",
      "type": "tun"
    }
  ],
  "log": {
    "level": "warn"
  },
  "outbounds": [
    {
      "tag": "proxy",
      "type": "socks"
    },
    {
      "tag": "direct",
      "type": "direct"
    },
    {
      "tag": "bypass",
      "type": "direct"
    },
    {
      "tag": "dns-out",
      "type": "dns"
    }
  ],
  "route": {
    "auto_detect_interface": true,
    "final": "bypass",
    "rules": [
      {
        "outbound": "dns-out",
        "protocol": "dns"
      },
      {
        "outbound": "dns-out",
        "protocol": "dns"
      },
      {
        "outbound": "proxy",
        "process_name": ["chrome.exe"]
      }
    ]
  }
}

спасибо, буду пробовать, щас поставил обычный яндекс без шифрования, пока что нареканий не вижу. А чем по итогу это вызвано?

Tun перехватывает весь трафик и защищённый запрос улетает в роутинг и зависает во встроенном dns без разрешения. В случае ipv6 + tun, DNS и вовсе отвалится, так как будет вставлять в интерфейс адрес по которому не будет ресолвить адреса, так как рабочий ресолвер будет только на ipv4, так что там вообще нельзя указывать local, по этому в любой конфигурации у китайцев DNS Alibaba открытый

Кто-нибудь обращал внимание, что в свежих 4 версиях сломали байпас на локальные ресурсы?

Сравнивал, как работают 3.26 и 4b4. Так вот 4b4 не пропускает трафик к внутренним корпоративным адресам (exchange, облако и т.п.), а 3.26 работает нормально. Сравнивал настройки двух версий в интерфейсах, всё одинаково. По логам видно, что 3.26 пускает запросы в обход, а 4b4 упорно пытается направить через прокси.

Работает в режиме TUN.

Как настроить Nekobox (Nekoray) так, чтобы он проксировал только выбранные процессы (например, Discord), и все, что идет через порт 2080 (к адресу 127.0.0.1:2080 подключаю браузер с расширением “Обход блокировок Рунета” и использую список Антицензорсити, чтобы проксировались только заблокированные домены, удобно, что список автоматически обновляется)?

Для дискорда есть вот такое: Настройка прокси только для Discord через DLL (плюс голосовые звонки без прокси)

Подскажите, этот конфиг можно сразу вставить в nekoray, заменив свой (если да, то где это) ? Или на основании это конфига нужно в гуи прокликать и прописать руками?

2 недели назад вышла версия 4.0.1

изображение805×641 24.3 KB

Рекомендуете с 3.26 переходить? Я читал на форуме что в новых версиях проблемы есть, поддержки xhttp тоже нет вроде?

Ага, я на ней сижу, проблем с Дискордом нет. Просто поинтересовался как конфиги чужие заливать в nekoray, посмотрел тут D:\distrib\network\vpn\nekoray\config как то все разбито по группам(по файлам разным), непонятна…

Почему некорей а не в2рей ?
Последний xhhtp поддерживает

Пользуетесь ли мультиплексированием ?
Читал что если ядро рей а клиент синг то нужны танцы с бубном.

В ней нет изменений которые изменяли бы поведение описанное выше, так как дефолтная работа с TUN запускает два сервера сразу, а используя встроенный (т.е. один сервер) просто подставляет кривой конфиг
Да и в целом она не шибко от beta-4 отличается, из критичного только dns починили для правил, но sing-box 1.11 так и не затащили, хотя после него у тех кто конфиги пишет знатно полыхнёт

А я пару дней только с этим вожусь, еще не посмотрел другие клиенты. Спасибо, гляну v2ray.

Только сейчас благодоря вам понял какая настройка отвечает за паралельное использование днс, кароче не работает мультиплекс у меня в некорай 4 (сервер хрей, клиент синг), возможно в 3.26 работает, проверю…

Да там всё несложно. Структура директории config следующая:

config
├── groups # Хранит общие настройки nekoray/nekobox и конфигурации групп
│   ├── 0.json # Конфигурация группы 0
│   ├── 1.json # Конфигурация группы 1
│   ├── ...
│   ├── n.json # Конфигурация группы n
│   ├── coreType # Хранит выбранное ядро: 0 - Xray, 1 - sing-box
│   ├── nekobox.json # Хранит основные настройки программы, если выбрано ядро sing-box
│   ├── nekoray.json # Хранит основные настройки программы, если выбрано ядро Xray
│   ├── pm.json # Хранит массив ID групп
├── profiles # Хранит профили серверов
│   ├── 0.json # Профиль серера 0
│   ├── 1.json # Профиль серера 1
│   ├── ...
│   ├── n.json # Профиль серера n
├── routes # Хранит профили настроек маршрутеризации ядра Xray
│   ├── Default # Дефолтный профиль настроек маршрутеризации
├── routes_box # Хранит профили настроек маршрутеризации ядра sing-box
│   ├── Default # Дефолтный профиль настроек маршрутеризации
└── dashboard # Хранит html файлы дашбордов clash
     └── index.html

Профили серверов можно собирать в группы, настраивать для них подписки и прочее. Делается это в Настройка → Группы. Если в группах ничего не трогали, то у вас будет одна группа Default (или “По умолчанию”, в зависимости от языка) с конфигурацией в файле groups/0.json.

Профили серверов все свалены в кучу без разделения по группам в директории profiles. Принадлежность профиля к группе задаётся в поле gid (ID группы) файла профиля сервера. ID группы можно узнать из файлов конфигурации группы в поле id, или по имени файла, так как он как раз совпадает с его ID.

Профили настроек маршрутов хранятся в директории routes или routes_box, в зависимости от выбранного ядра. Можно сохранять и загружать профили маршрутов в меню Настройки → Настройки маршрутов → Общие, там есть секция Набор маршрутов, тыкаем “Изменить набор маршрутов”. В окне отобразятся все профили из директории routes или routes_box. Можно менять настройки маршрутов и с помощью функции Запись сохранять их в отдельный профиль-файл.

Итог

Eсли хотите делится профилем сервера, то берёте его конфигурацию из profiles на одной системе и помещаете в profiles на другой. При этом меняете gid в json файле профиля на вашу группу, иначе сервер не добавится в вашу группу и в интерфейс программы.
Но вообще проще конечно делится через QR или ссылку. Хотя я с помощью переноса файлов копировал профили серверов между моими системами, всё работало нормально.

Если хотите делится настройками маршрутов, то сохраняете её через меню “Изменить набор маршрутов” в файл и копируете его из routes или routes_box на одной системе в routes или routes_box на другой. Затем нужно из меню “Изменить набор маршрутов” загрузить этот профиль.

Это не другой клиент это другое ядро, nekobox стал box называться из-за перехода на sing-box от слабой поддержки 2ray, разные ядра, разные клиенты, разные конфиги, разная работая с правилами и условными правилами

Намаялся с настройкой сил уже нет (несколько дней сижу с этим).
У меня сервер vless с realitty.
Я ставил NekoBox (разных версий), v2Rayn результат один и тот же, опишу ситуацию.
Визуально все OK, меня устраивает, я имею ввиду сеть работает как мне нужно (если трафик к Яндекс, то он идет прямо к нему без прокси… если нет, то в прокси, Дискорд ну и все такое так же OK). Я в TUN (sing-box).
Но очень сильно напрягают параллельные запросы которые я вижу в Wireshark. Как я проверяю:

1. Включаю туннель.
2. Задаю фильтр в Wireshark ip.dst == 78.110.50.142
3. Открываю https://ipmy.ru/ в браузере (этот сайт попадает под фильтр gepip:ru, потому что IP ru)
4. Вижу в Wireshark два запроса к 78.110.50.142 от 172.19.0.1 (IP tun) и от 192.168.49.48 (мой ПК)
5. Иду в Микротик, смотрю куда ушли запросы: один прямиком к 78.110.50.142, а второй на IPvpn:443

Очень хочу это исправить (чтобы был один запрос), я спрашивал в соседней теме про такое, мне посоветовали, что можно создать правило-маршрут в программе-клиенте, который я использую для подключения к впн или использовать локальный ДНС сервер и слать все запросы на него он разберется (если я правильно конечно понял).
Вариант с локальным ДНС отпадает.
Chat GPT давал мне советы, конфиги, но ничего не помогло (скорее всего я что-то не так делал)
Подскажите, пожалуйста, как мне добиться средствами маршрутов или правил один запрос к сайту, желательно средствами NekoBox или v2rayN ?!
Может поделитесь примерами своих конфигов… не нашел похожих тем, разве это не важно, провайдер же будет видеть два одновременных запроса к одному сайту, понятно что ему пофигу (пока), но все же.

И если использовать режим прокси:1080 будет так же два запроса одновременных? (не проверял еще)

вам не нравится запрос к прокси серверу когда заходите на ру сайт? днс запросы тогда тоже направляйте напрямую а не через прокси

Да! Вот конфиг днс из v2rayN, в нем на мой взгляд (не уверен конечно до конца) днс запросы идут напрямую, посмотрите пожалуйста.

Вот как в гуи выглядит

image985×690 22.1 KB

что за clash mode не знаю, замените его правила на те же что и в правилах роутинга (т.е. geoip-ru в local dns)

В итоге даже на версии 4.0.1 от 12.12 белый лист не работает корректно(
Какой то выход из ситуации появился?

некорректно это как? вы пытаетесь сделать белый список для приложений?

Для того, что бы он работал корректно, нужно в настройках маршрутизации выставить дефолтный outbound с proxy на bypass, тогда проксироваться будут только процессы из белого списка, а всё остальное идти напрямую:

Снимок экрана 2025-01-19 021130996×793 23.9 KB

Тоже сначала не понял, почему в онлайн играх пинг выше обычного, только потом дошло, что дело в NekoBox’е. Из-за этого решил опытным путём поковыряться в настройках - как оказалось, в разных режимах одна и та же опция может работать совершенно по разному, что собственно говоря и было в случае с белым списком приложений и конечной выходной точкой (outbound’ом).

Тогда в чем смысл белого списка? Я запутался… если мне всего то надо было что бы он через себя пропускал первые 4 из списка… а остальные нет… что я тут делаю не так? или это все делается не так? а как на вашем скриншоте… забить в точности как у вас и будет работать?
а унбаунд у меня всегда стоял прокси

image850×351 10 KB

image593×598 6.37 KB

image802×632 4.36 KB

Как раз в том, чтобы выборочно проксировать только нужные приложения, а остальные шли напрямую (без ВПН).

В списке оставь только chrome.exe, Discord.exe, Updater.exe и RocketLeague.exe (если правильно понял), MTU оставить на 9000 (как подсказали ниже).

Затем, в третьем окне пропиши как сделано у меня (весь RU трафик идёт напрямую, НЕ на впн, + выборочные настройки для определённых сайтов. Если ютуб смотришь с помощью Zapret, то строчку с geosite:youtube удали, если же Zapret не используешь, то оставь её, иначе ютуб работать не будет).

И самое главное - Outbound по-умолчанию выстави в bypass, без этого белый список приложений не будет адекватно работать.

01_Russia-to-Direct_Other-to-Proxy.txt (478 байтов)

MTU 9000 нужен тупо для увеличения производительности, никакой дополнительной фрагментации он не cделает, обмен данными происходит на localhost

А… Интересно, не знал. То есть, его в любом случае следует оставлять в 9000, не смотря на MTU реального интерфейса? Справедливо ли это для других клиентов, таких как Husi, Hiddify и прочие, или это актуально только в случае с NekoBox?

И ещё вопрос - в чём разница между gVisor, System и Mixed? Какой стоит использовать, а какой нет и при каких обстоятельствах? Благодарю.

да, MTU реального интерфейса вообще не важен. Справедливо это для всех прокси клиентов с TUN.

в чем разница не скажу, mixed (default) это system для TCP трафика и gvisor для UDP трафика.

на счёт фрагментации: даже с 1500 TUN MTU возможна фрагментация QUIC протокола, но я сам не проверял т.к. обычно его блокирую (он через TCP прокси сам по себе работает медленно, фрагментация тут уже не особо важна, чтобы 100% небыло фрагментации то надо ставить TUN MTU в ~1240, но хз что может сломаться с таким низким значением т.к. некоторые протоколы (напр онлайн игры) нужно фрагментировать на уровне прокси иначе они работать не будут вообще). И вообще всё что я написал про фрагменты может быть бредом т.к. я не смотрел как именно работает TUN, может он собирает фрагменты сам и MTU интерфейса не важен совершенно…

Благодарю

Спросил у ChatGPT, он написал что разница в подходах:

• System - это системная реализация (неожиданно), в теории требует меньше ресурсов и обладает меньшими задержками, из минусов - требует больших прав (видимо администратора), а так же могут быть проблемы с совместимостью (вроде как раз у Hiddify были проблемы в связанные с этим).

• gVisor - это внешняя реализация, вроде как основанная на контейнеризации, что требует меньше прав, увеличивает совместимость и даёт некую гибкость, но в теории работает медленее и с чуть большими задержками.

• Mixed - комбинация двух подходов, по всей видимости компромисс, когда частично работает режим System, а gVisor выполняет дополнительные функции.

Насколько я понял, если System работает без проблем, то лучше использовать его, в противных же случаях можно перейти на остальные.

Сделал все как вы сказали… гугл перестал гуглиться

image802×632 6.42 KB

image916×623 14.6 KB

image979×512 10.4 KB

image1331×736 64.5 KB

Однозначно выключи Обход блокировок Рунета, вместе они конфликтуют, это раз. Второе - у тебя зачем-то стоят две галочки “Режим TUN” и “Режим системного прокси”, нужно использовать только TUN.

В общем, отключи расширение Обхода, выйди из NekoBox’а, и ещё можешь попробовать использовать клиент с моими настройками (если даже так не заработает, то хз, видимо в системе что-то не так настроено) - http://www.mediafire.com/file/gdr3a4869jw7b5f/NekoBox.zip

можно использовать и обе галки, поддерживающие прокси проги будут использовать именно его и меньше грузить проц

Это да, но вайтлист приложений работает только в TUN режиме

почему то ваш сайт перестает работать на вашей сборке

image722×474 5.9 KB

image1920×1080 66.8 KB

fix
поставил обе галочки, тун и режим прокси… заработало

О кстати, ублок перестал работать на твич… запускать рекламу стал… как вернуть ему работоспособность? такое началось после впн