мультиплексирование часто просаживает скорость, но ускоряет подключение к серверу.
с мультиплексированием лучше. см. недавнюю сибирскую блокировку, когда “если за короткое время установлено >12 тлс соединений = блок”
Спасибо. Я не до конца понимаю. Под мультиплексированием мы понимаем тот факт, что под запросы к прокси открывается новое соединение до тех пор, пока их не стало maxConnections, после чего соединения переиспользуются, верно? Тогда у меня по-прежнему есть вопросы:
- А если я поставлю maxConnections: 13 (или выше), то при сибирской блокировке будет шанс нарваться? Или это не так работает?
- Почему нельзя (или можно) просто поставить maxConnections: 1, если в этом случае скорость выше? Что там внутри будет происходить такое с пакетами, из-за чего возникнут проблемы?
ну типа. и опять же, мы не можем быть уверенными ни в чем - сегодня у них отсечка по 12 коннектам, завтра по 6, послезавтра по 3…
можно, почему нет-то.
только наоборот, пропускная способность. зачастую может быть ниже, особенно на нестабильных каналах.
да
Сам xhttp у меня завёлся, а вот попытка использовать его для реверс прокси (portal/bridge) не увенчалась успехом. Это в принципе не поддерживается, или на моей стороне косяк?
Присоединяюсь к теме. Всем здравствуйте. Делал по примеру из репозитория vless-xhttp-nginx. Вроде как работает, но в конфиге явно указан stream-one, а хотелось бы разделять потоки (на одном vps). У меня куча глупых вопросов, но я не смог найти на них ответа либо что-то недопонимаю. Правильно ли я понял, что для разделения потоков в режиме stream-up я должен сделать 3 inbound’а, из которых 2 (для двух разных потоков с клиента) с fallback на основной третий? Или достаточно на клиенте указать “downloadSettings” с отличными от первого потока настройками на единственный inbound сервера? Я использую клиент на android v2rayNG, в котором вроде как есть поддержка всего необходимого.
Благодарю всех за любую помощь и информацию.
у меня на роутере sing-box на входе и дальше через socks на xray который уже в xhttp
Довольно забавную схему собрал на одном из своих серверов
nginx ←→ xray-core с XHTTP
Nginx слушает 443 по TCP с TLS 1.2 (т к 1.3 часто блокируют в сторону хостеров), и также слушает UDP 443 уже с QUIC (ну тут понятное дело 1.3 потому что QUIC только по нему работает)
На клиенте это все дело можно настроить разными способами
Проверял upload с alpn h3 и в downloadSettings тоже alpn h3— то есть QUIC в обе стороны. Режим stream-up. Вот тут стало очевидно что QUIC определенно троттлят, ибо скорость выше 100 мбит/с не поднималась
Далее upload с alpn h3 и download с alpn h2. То есть исходящий трафик идёт в QUIC по UDP, а входящий по HTTPS с TLS 1.2 — вот тут уже скорость загрузки полноценная (около 800 мбит/с), а аплоад и так медленный в xhttp, так что пусть остаётся на QUIC, это сильно погоды не сделает
Также можно поставить на upload и download просто общий alpn h2 — будет работать только по TCP с HTTPS и TLS 1.2
Далее на клиенте — ядро xray поднял так чтобы слушал локальный socks5 localhost:1080, и рядом тестировал ядра sing-box и mihomo в режиме tun, которые пересылали весь трафик с tun inbound в xray по socks5. На линуксе это заработало довольно легко и стабильно, правда ядро mihomo хуже работает на линуксе в таком режиме и почему-то зависает часто. А на винде в sing-box так и не удалось полностью победить утечку DNS (но частично можно пренебречь так как в системе можно поставить DoH на 1.1.1.1), а вот в mihomo никакой утечки DNS не было и работало очень стабильно.
То есть конечный вариант на клиенте
sing-box/mihomo tun ←→ xray-core socks5 ←XHTTP—> nginx –> /dev/shm unix socket ←xray-core–> freedom
Через эту всю связку например отлично играл в Battlefield 6 без единого отвала сети или лагов, пинг около 70.
Если что я не использую никакие панели/GUI клиенты и все это настраивал руками в json и yaml конфигах, запускал на винде через батники, а на линуксе через systemd сервисы
Кстати скоро в ядро mihomo добавят поддержку splithttp (уже висит pull request), и можно будет не городить монстра из двух ядер для системного туннелирования и просто использовать ядро mihomo.
Вот такие дела
Вы так и не ответили когда и куда блокировался тлс 1.3
Скорее так работает протокол
Конкретно мои серверы это не затронуло, но тут видел сообщения что именно в сторону некоторых хостеров блокировался TLS 1.3, видимо из расчёта что большинство сайтов и по 1.2 работают отлично, а вот классическая связка xtls-vision-reality требует именно 1.3, так его и прибить
Большинство сайтов именно по 1.3 работают по дефолту и будут блокнуты в таком случае, админам придется менять конфиг веб сервера. Смысл ломать веб сайты чтобы сломать прокси? Прокси перейдут на другую версию тлс вместе с ними. По логике ркн будут заблочены все версии тлс и вообще весь трафик. Сообщений я этих не видел, есть ссыль?
Если получится то проверю влияние версии тлс на сибирскую блокировку
По дефолту обычно 1.2 включены и 1.3 одновременно. Почти никакие серверы не ограничены именно одной версий протокола
Это легко проверить через curl например
~ $ curl https://google.com --tlsv1.2 --tls-max 1.2 -v
* Host google.com:443 was resolved.
* IPv6: 2607:f8b0:4006:80b::200e
* IPv4: 142.250.80.78
* Trying [2607:f8b0:4006:80b::200e]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
* CAfile: /data/data/com.termux/files/usr/etc/tls/cert.pem
* CApath: /data/data/com.termux/files/usr/etc/tls/certs
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
....
....
Ну а как ты браузеру хром на андроид обьяснишь что тлс1.3 использовать не нужно?
Не влияет
Сервер сообщит Андроид что умеет только в TLS 1.2?
Я же про это писал. Если админы сайтов будут отключать тлс 1.3 для восстановления работы то и владельцам прокси ничего не помешает сделать тоже самое
Если не удаеться использовать TLS 1.3, то сервер-клиент разве не пытаются сделать это с понижением TLS до 1.2
помешает то что Reality через 1.3 не работает, а это в настоящий момент самый популярный вариант.
хром не пытается (и правильно, это же небезопасно), в тм уже блочили тлс 1.3 на CDNах, потом откатили
Офтоп конечно, но в чем небезопасность заключается в TLS 1.2?
пока ни в чем, потом могут найти уязвимость, получится хакеры смогут внедряться в сети, блокировать там тлс 1.3 чтобы браузеры переключались на тлс 1.2 и делать всё что им надо