Если уже пользуетесь DoH/DoT/DNSCrypt/т. д., то смысла особого нет, а если ваша цель - получить рабочие IP адреса для допустим mail.proton.me, то для этого существует ECS.
Если же заграничные DNS-сервера у вас заблокированы, то тут уже всё ясно.
И как узнать какие адреса в белом списке?
Перебором.
- Берешь ВПСку на вк\яндекс клауд
- Поднимаешь там веб-сервер или xray
- Проверяешь подключение с мобилки во время работы БС.
Если подключение идет и все работает, то ip в бс, если нет, то повторяешь все действия с первого пункта.
Но я слышал, что ВК начал банить аккаунты, за перебор айпишников, так что хз насколько успешно сейчас такое проворачивать можно. Да и ценник там будет от 1500р\мес за сервер+ip, для личного пользования не особо рентабельная штука.
Мне ж не только для себя 
Но да, если перебирать по полтора косаря за каждый сервер, то эдак в минус уйдешь очень быстро, пока не найдешь такой IP.
Там тарификация поминутная. Если взять сервер, протестить за 10 минут и удалить его, то только за эти 10 минут и заплатишь
Заметил что во многих дефолтных настройках маршрутизации блочат udp 443 порт полностью. Зачем?
Китайцы особенно любят этим заниматься. Мож у них палят по udp?
Где-то мельком слышал, что у нас тож могут палить по звонкам в Телеге.
Через QUIC утекает реальная локация. Полезно для ИИ
Эм, что? Бред.
Vless работает по tcp, quic - udp со своим congestion control, т.е. если гонять его через влесс, то будет большая нагрузка на сервер и два congestion control что может создавать тормоза, поэтому он и блокируется, чисто для производительности
Ну объясните тогда отвал Gemini при включении QUIC для !ru. У вас всегда везде один бред
У меня и chatgpt отваливался при включенном в браузере QUIC. DNS через него резолвиться может. А может и не резолвиться, и тогда будут зависать открытия новых сайтов без DNS кэша, будет fallback обратно на TCP/UDP DNS.
VLESS действительно работает по TCP, т.к HTTPS по умолчанию TCP. Было бы странно его использовать через UDP. HTTP/3 работает как-раз по UDP (QUIC), некоторые сайты стараются его и использовать, раз включено в браузере.
Поэтому и существует такая штука как xudp для передачи UDP over TCP.
Я не очень понял суть диалога, если честно, но если у вас не открываются некоторые сайты при включенном в браузере QUIC - отключите его.
Гонять UDP, а тем более QUIC через xudp смысла почти нет, задержка будет примерно такой же как и у TCP, если не хуже. xudp имеет смысл как слой совместимости для работы приложений, которые понимают только UDP.
Иначе получается: QUIC → UDP → XUDP → TCP → TLS. Ещё и TLS in TLS. Смысл QUIC убит, это переусложнение.
Поэтому и блокируется, для производительности, желательно на уровне браузера чтобы он вообще туда не лез. Если не выключить, браузер ведь всё равно timeout прождет прежде чем fallback. Отсюда и пресловутые типа лаги или вообще дроп TLS соединения.
шта?
DNS-over-QUIC (DoQ). Либо для загрузки/интерактивности страницы.
Если от QUIC подтверждения не придет, например если sing-box его не поддерживает (проблемы со сниффингом, например), то браузер переключится на fallback протокол.
Может дело и не в DNS вовсе, а может и в нём, реализации и расширения браузеров разные и DNS настройки sing-box тоже. Указано DoQ - может не сработать.
Вряд ли конечно, скорее всего при загрузке страницы и есть проблема.