Популярная панель 3X-UI обновилась до 2.4.9. Наконец-то туда прикрутили хайпуемый авторами Xray протокол XHTTP.
Это, кто не в курсе, переработанный SplitHTTP, который теперь официально переименован в XHTTP. Документацию старую пока выпилили. Там, насколько я помню, говорилось, что он шинкует соединение в салат так, что если вы смотрите потоковое видео, например, то у вас не статичный туннель, а он режет и пересобирает его в набор случайных запросов, так что это со стороны выглядит как интенсивный браузинг. Теперь вместо документации ссылаются на статью:
Там, полистайте, в топике есть русский перевод. Теперь фокус сместили на раздельные восходящие/нисходяшие потоки и продвинутые сценарии работы через CDN.
Базово, теперь в 3X-UI все работает из коробки. Просто берете свой рабочий конфиг и транспорт меняете на XHTTP. Проверил, работает Reality c чужим доменом, со steal oneself и TLS с fallback.
Минус пока в том, что все популярные клиенты на Sing-Box, а его авторы запрос на поддержку XHTTP дропнули и не известно, будут ли вообще его прикручивать. Поэтому нам остается только V2RayN. Обязательно обновляйте до последнего, чтобы поддержка XHTTP появилась. Плюсом, там теперь есть встроенный русские базы geosite/geoip.
А на Android V2RayNG русские базы прикрутить это тот еще квест. И, честно говоря, работает YT через этот клиент довольно тормознуто, причем не только с XHTTP, но и с “классическими” уже протоколами.
.
Streisand уже сделали обнову
Подскажите, как для не особо разбирающегося, в чем преимущества перед решением, которое все используют сейчас (“обычный” Reality)? Пока не очень понятно. Кроме того, как я понял, для данного решения обязательно нужен домен, метода с самоподписанным сертификатом недостаточно?
Ребят, подскажите как через 3x-ui сделать что бы dns запросы отправлялись через мой сервер? В настройках xray пробовал настроить, но ничего не работает(
Плюсы, которые я вижу
Использование мультиплексирование и долгоживущих сессий.
Возможность проксирования через любые CDN, уход от gRPC
Разные потоки на аплоад и даунлоад
Домен не обязателен, можно использовать тот же Reality, но с транспортом xhttp. Что за метод с самоподписанными сертификатами - не ясно. Если только для прокcирования через CF
Это не решение, это хак. Cloudflare, как я понял, просто читает gRPC заголовок, а все что ты дальше передаешь, считает gRPC траффиком. Xray просто теперь эксплуатирует эту лазейку, маскируя свой трафик под gRPC. Но не факт, что, если её начнут массово абузить, CF эту дыру не прикроет.
А можно на пальцах? Абсолютно тот же конфиг с риалити беру и протокол просто меняю на xhttp?
И все? Там появляются дополнительные настройки мне их не трогать (host, path etc)? Нужно ли включать или отключать настройки какие-то в клиентах? Как вообще проверить работает ли этот xhttp?
Я так и не понял, можно ли использовать XHTTP через CDN с использованием realitySettings, чтобы маскироваться под чужой домен?
Меня reality всем устраивает кроме того, что приходится палить IP сервера.
Официальная инструкция не очень понятная. Вроде как на сервере нужно поменять transport на xhttp, и в xhttpSettings добавить path (видимо можно любой вписать? я хз). Ну я прописал xhttp, в nginx и в конфиг xray добавил path, в v2rayn указал xhttp и path (при этом в v2rayn еще есть дополнительные непонятные настройки связанные с xhttp). И короче нифига не работает. В общем если кто в теме, напишите пожалуйста нормальную инструкцию как с реалити с маскировкой под свой сайт, перейти на xhttp, и надо ли оно вообще, так как видимо это решение в основном сделано для работы через cdn.
Присоединяюсь, помогите, кто в теме, тем, кто не. Или если уже есть какой-то адекватный гайд - киньте ссылку.
Все проще некуда. Берете свой рабочий конфиг, на TCP-Vision, например, и в поле Transmission просто вместо TCP выбираете XHTTP. Экспортируете ключик заново и импортируете в клиент. Клиент должен поддерживать XHTTP, под Windows это только V2RayN на сегодня. Настройки TLS или Reality оставляете как есть. Настройки XHTTP тоже по умолчанию. Неважно, чужой сайт вы воруете или свой на Nginx, НИЧЕГО кроме Transmission менять не надо. В Nginx ничего менять не надо. “Покормите собак и не трогайте никакие кнопки” (C).
За CDN не расскажу, не знаю, не настраивал. Есть пока только китайские гайды.
Поставил как NowAndThen пишет, количество сессий уменьшилось, значит и мультиплексирование работает. Хотелось бы конечно понять как подружить с CDN ведь это главная фишка из анонса протокола.
Может кто-то отбъяснить как это вообще работает и что дает? Вот использую я к примеру reality с network:tcp dest:chtoto.net. Что мне нужно что бы прикрутить XHTTP? Нужен ли свой домен? И что вообще даст переход на XHTTP?
это для 3x ui видимо? Я просто в конфиг xray - streamSettings - network прописал “xhttp”, в v2rayn поменял transport на xhttp, и ничего не работает.
Ну ок, тогда следую инструкции с гитхаба
- Независимо от того, используется TLS или REALITY, обычно в конфигурации XHTTP достаточно указать только
path, остальные параметры можно не заполнять.
Делаю xhttpSettings, прописываю туда path на “/”, и на клиенте тоже. Ну и тоже ничего не работает.
Я про панель, голый не настраивал.
Я у себя так же настроил xhttp+reality, все работает и пашет. Только выбрал дополнительно stream-one, это, как мне показалось, дало меньше всего открытых tcp-сессий при равных условиях (возможно, что просто показалось).
Но я так и не получил ответа нигде, выбор этого новомодного транспорта повышает/не меняет/уменьшает маскировку в случае использования совместно с Reality?
Буквально вчера поднял у себя VLESS - XHTTP h3 за nginx. Использовал конфиги отсюда Xray-examples/VLESS-XHTTP3-Nginx at main · XTLS/Xray-examples · GitHub
Разве что stream-one изменил на stream-up.
Работает очень шустро я сказал бы, но полноценные тесты пока не проводил
XHTTP возможен только со своим доменом?
Не обязательно.
Кто-нибудь пробовал настроить с fallbackом на network tcp? Чтобы можно было к reality серверу подключаться как с клиентов с поддержкой xhttp так и без поддержки (напр. sing-box)
Можно сделать так ничего не трогая?
Я такое на Reality сделал. Первый инбаунд, например, XHTTP слушает 443, в поле Dest пишем ему какой-нибудь внутренний порт или юникс-сокет. Этот порт/сокет слушает следующий инбаунд, например, на gRPC, в Dest новый порт, который слушает третий инбаунд, пусть на TCP. Если надоело в эти цепочки играть, терминируем последний через тот же Dest на воруемый сайт или свой домен, как обычно. Т.е. мы по очереди перебираем протоколы, если какой-то подошел ключом, устанавливаем туннель, а если ни один не подцепил, с последнего перебрасываем на сайт. В результате по всем протоколам можно ходить через 443. TLS c fallback, как я понимаю, так же должен работать. Попробуйте такую цепочку через поле Dest в fallback построить, оно ту же функцию по идеее выполняет.
Настроил. Оказалось очень просто, при уже имеющемся инбаунде для “классического” vless-reality на 443 порте нужно добавить новый инбаунд:
{
"listen": "@xhttp",
"protocol": "vless",
"settings": {
"decryption": "none",
"clients": [
{
"id": "ваш_id",
"email": "12345"
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"path": "/ваш_path"
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
И добавить его в фоллбеки у vless-reality:
"settings": {
"fallbacks": [
{
"dest": "@xhttp"
}
]
},
И теперь клиенты могут подключаться к reality серверу как c транспортом tcp (raw), так и с xhttp
Типа такого?
Спойлер
{
"inbounds": [
{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "12345",
"flow": "xtls-rprx-vision",
"level": 0,
"email": "555@555.com"
}
],
"decryption": "none",
"fallbacks": [
{
"dest": "1111"
},
{
"dest": "@xhttp"
}
]
},
"streamSettings": {
"fingerprint": "chrome",
"network": "raw",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "1111",
"xver": 0,
"serverNames": [
"example.com"
],
"privateKey": "123",
"shortIds": [
"123"
]
}
},
"sniffing": {
"routeOnly": true,
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
},
{
"listen": "@xhttp",
"protocol": "vless",
"settings": {
"decryption": "none",
"clients": [
{
"id": "тот же id что у reality",
"email": "тот же email что у reality"
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"path": "/"
}
},
"sniffing": {
"routeOnly": true,
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
]
}
Потом в v2rayN изменяю transport на xhttp, и в Path указываю /.
Ну и опять не работает. Чёт вообще этой темы не выкупаю.
В настройках клиента надо ещё flow сделать пустым вместо rprx-vision (вдруг забыли). А так должно работать
Да, надо было flow пустым сделать, теперь работает, спасибо.
Это не демаскирует клиента для провайдера?
Отключение flow xtls-rprx возвращает проблему tls-in-tls. Если транспорт xhttp ее не решает, то конечно демаскирует
Предположу, что не демаскирует, так как в xhttp работает мультиплексирование. Т.е. клиент смешивает в кучу все сессии, потом нарезает в n-ое количество уже новых сессий и уже на сервере собирает в нужную последовательность. Таким образом с одной стороны уменьшается количество открытых сессий, а с другой стороны это одновременно является идеальной маскировкой.
Но это лишь мое предположение, сам хочу получить ответ, прав ли я.
Я изучил все китайские посты и статьи по теме (которых к слову не особо много, все ссылки есть в этом треде), и по сути единственное упоминание tls-in-tls в контексте xhttp вот это:
(https://github.com/XTLS/Xray-core/discussions/4113#discussioncomment-11468947)
И, наконец, кульминация - еще одна новая эра: разделение исходящего и входящего трафика. Мы знаем, что сейчас GFW обнаруживает такие характеристики трафика, как TLS in TLS, основываясь на одном соединении. Таким образом, если мы разделим исходящий и входящий трафик на разные системы проверки, например, исходящий трафик будет идти через IPv4 TCP, а входящий - через IPv6 UDP, GFW не сможет сразу среагировать.
Т.е. да, по всей видимости tls-in-tls там присутствует, как в классическом vless без rprx-vision, а бороться с детектом они предлагают через разделение потоков на up и down и мультиплекс сессий. Видимо, xhttp изначально делался под использование именно с CDN на как миниум одном из потоков, а там rprx-vision всё равно применить никак нельзя. На всякий случай спросил у разработчиков ещё.
Собственно поэтому от идеи использовать xhttp с только прямым reality подключением я пока отказался. Сейчас удалось настроить более замороченные схемы по типу CDN_UP+REALITY_DOWN и CDN UP+DOWN через два разных домена, буду пока их тестировать.
Мультиплексирование не решает tls-in-tls, да
Можно примеры конфигурации сервера и клиента?
Я все конфиги взял отсюда:
Нужен nginx, да. В конфигурации клиентов раздел “sockopt” можно опускать, в блоке “extra” можно убрать всё кроме “downloadSettings”, если их нет - можно весь “extra” также опустить. (это написано там в комментах иероглифами, советую весь конфиг переводчиком с китайского тоже прогнать, чтобы комментарии были понятны)
Единственное, что я добавил от себя - конфиг клиента для cdn up/down на два домена:
//xhttp_cdn_up_down
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "domain1.com",
"port": 443,
"users": [
{
"id": "ваш_xhttp_id",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"serverName": "domain1.com",
"allowInsecure": false,
"alpn": ["h2"],
"fingerprint": "chrome"
},
"xhttpSettings": {
"host": "",
"path": "/ваш_xhttp_path",
"mode": "auto",
"extra": {
"downloadSettings": {
"address": "domain2.com",
"port": 443,
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"allowInsecure": false,
"alpn": ["h2"],
"fingerprint": "chrome"
},
"xhttpSettings": {
"host": "domain2.com",
"path": "/ваш_xhttp_path",
"mode": "auto"
}
}
}
}
}
},
Тут “восходящий” поток идёт через domain1, а “нисходящий” через domain2. Оба домена приземляются на nginx через cdn.
И все-таки я продолжу предполагать, что xhttp закрывает проблему tls-in-tls, привел весь текст, но главное внизу выделил:
Try to understand the focus and logic of our series of protocols under XTLS. If you are wrong, please@RPRXCorrection.
The first generation of XTLS splice/direct/origin, etc. - solving performance:
traditional TLS over TLS will have two layers of encryption overhead, while XTLS directly and losslessly embeds/splices the inner TLS data into the outer TLS stream, making the surface It’s still single-layer TLS, but the proxy traffic is actually hidden. Reduce repeated encryption and decryption processes. The CPU load and encryption and decryption costs are significantly reduced without sacrificing security, thus improving performance.
VISION----Solution to TLS in TLS characteristics:
When multi-layer TLS is superimposed (TLS in TLS), there are two interactions between the inner TLS handshake and the outer TLS. This timing has obvious characteristics and can be accurately identified by GFW. The significance of VISION is to smooth out this unnatural timing characteristic by simulating delay and message exchange sequence, making the multi-layer TLS handshake process look closer to real Internet traffic and reducing the risk of being identified.
REALITY----Solving the SNI blocking problem:
Mainland China’s SNI cannot be encrypted, so GFW can identify and block it through SNI.
REALITY disguises itself in the TLS handshake and certificate delivery. By returning a certificate and initial data that looks like a real website in the handshake between the two parties, it is difficult to distinguish the authenticity of the entire TLS connection and the connection to the “big factory” HTTPS website. If GFW wants to block it, it needs to risk accidentally damaging the real website.
XHTTP - solves the common “single tunnel” feature of circumvention protocols:
traditional protocols (such as Shadowsocks, Vmess, Trojan, etc.) usually only encrypt data and continuously transmit it through a specific port, which can appear to be “stable and long-lasting” “Time encrypted flow” characteristics; reviewers can suspect that it is proxy traffic through statistical analysis, long connection characteristics, and data transmission patterns.
Therefore, XHTTP focuses on the application layer this time, further packaging the encrypted transmission into real HTTP requests and responses. By splitting the upstream data into multiple normal-looking POST requests and URLs with randomized parameters, the downstream data is disguised as large file streaming downloads or the continuous output of SSE (Server-Sent Events), which makes the traffic behavior different from that of ordinary users. The browsing and downloading patterns are very close. Compared with traditional “encrypted tunnels”, XHTTP is no longer a stable and continuous data pipeline, but is ostensibly composed of multiple independent, fragmented and natural HTTP interactions, more like common WEB access actions.
А какой CDN используете, Cloudflare или что-то еще? И что настраиваете на стороне провайдера?
А может кто-нибудь пожалуйста привести конфиг для 3xui с xhttp для двух reality сайтов (без воровства своего серта)
Вроде такое возможно или нет?
- Создаете новый inbound.
- Вводите порт 443, или другой, если этот у вас уже где-то занят.
- Выбираете в выпадающем меню Transmission XHTTP
- Выбираете Security Reality
- Вводите в Dest и SNI воруемый сайт.
- Получаете ключи кнопкой Get New Cert.
- Жмете Create.
- Экспортируете ключик в клиент.
Стоит уточнить, что клиентов, которые поддерживают xhttp можно пересчитать по пальцам. На винду, по-моему, только v2rayN
Cloudflare. Настройки базовые, просто заведён домен купленный на godaddy, в разделе DNS records создана AAAA запись указывающая на ipv6 адрес сервера, включено проксирование, в настройках кеширования всё отключено, в настройках SSL/TLS режим Full (strict). Для второго домена то же самое. В конфиге nginx нужно разумеется оба домена указать, у обоих выполняется grpc_pass на xhttp сокет, как в тех конфигах у китайцев:
server {
listen [ваш_ipv6_адрес]:443 ssl ipv6only=on http2 so_keepalive=on;
server_name domain1.com;
ssl_certificate /path/cloudflare_cert/domain1.com.pem;
ssl_certificate_key /path/cloudflare/domain1.com.key;
...
}
server {
listen [ваш_ipv6_адрес]:443 ssl ipv6only=on http2 so_keepalive=on;
server_name domain2.com;
ssl_certificate /path/cloudflare_cert/domain2.com.pem;
ssl_certificate_key /path/cloudflare/domain2.com.key;
...
}
Сертификаты для nginx берутся в панели cloudflare в разделе SSL/TLS → Origin Server → Origin Certificates
Можно обойтись и одним верхним доменом, использовать субдомены типа up.domain1.com и down.domain1.com, но целесообразность этого под вопросом.
если не разделять трафик на 4 и 6 то получается палево ?
@MasterYoba А не затруднит пояснить за топологию этой схемы, пытаюсь понять, как это все работает. Вот есть клиент, который хочет сходить на экстремистский Твиттер. Обычно он идет на ваш прокси и там в туннеле сообщает вам, что хочет посетить Твиттер, наш прокси сервер ему его приносит в зашифрованном туннеле. А тут куда запрос клиента в вашем случае идет? На сервер Cloudflare или на ваш UP домен? Куда дальше идет ответ с Твиттера, как он понимает, что нужно ответить на DOWN домен? И какую роль тут играет Cloudflare?
Нет, разницы никакой, этот ipv6 служит только для стыковки сервера с cloudflare и цензору он не виден. Можно всё повесить на один ipv4 адрес, именно так китайцы в конфигах выше и делают. У меня просто был дополнительно свободный ipv6 адрес, cloudflare с ними дружит, и я захотел сделать вот так.
Минус пока в том, что все популярные клиенты на Sing-Box, а его авторы запрос на поддержку XHTTP дропнули и не известно, будут ли вообще его прикручивать. Поэтому нам остается только V2RayN.
Так подождите, а V2RayN поддержку 32бит выпилили что ли. В 6 версии была же вроде
Всё то же самое, просто соединение с прокси сервером строится не напрямую, а через cloudflare. Клиент сначала строит “честное” tls соединение с сервером Cloudflare с SNI вашего купленного домена, а внутрь него заворачивает соединение с экстремистским твиттером посредством vless с выбранным транспортом через ваш VPS прокси-сервер. VPS сервер как бы спрятан за CDN как за щитом, внешний наблюдатель видит только обращение к ip-адресам CF и SNI вашего домена, но про сам VPS ничего не знает. Всё что может сделать цензор - забанить ваш домен, который легко сменить.
Вот тут очень хорошая статья по этой теме:
Из минусов тут только характеристика трафика tls-in-tls, как раз с которой вроде как и должен помогать транспорт xhttp. Теперь с ним запросы от клиента идут по одному “каналу” к CDN с внешним SNI domain1, а ответы от сервера по второму каналу с внешним SNI domain2. Насколько это эффективно - черт его знает, но выглядит перспективнее, чем “простое” проксирование через CDN с транспортом вебсокет или grpc.
@MasterYoba Я правильно понял, что эти ваши домены просто висят в воздухе, получается, зарегистрированы на CF и все, на них нет никаких сайтов? А Xray сервер у вас на третьем домене или на голом IP? Или как?
Домен зарегистрированный в CF указывает на IP-адрес vps сервера (v4 или v6 - без разницы), весь трафик к этому домену на 443 порт CF проксирует через себя, т.е. при DNS резолвинге отдаёт клиенту не IP-адрес сервера, а IP-адреса своих “промежуточных” серверов.
На vps сервере на 443 порту слушает nginx, а там уже можно хостить любой контент, и веб сайты в том числе. То есть можно сделать domain1.com/mywebsite - ваша веб-страничка с котиками, domain1.com/proxy - grpc_pass на сокет, где слушает xray. Вообще, чем об этом так рассуждать проще самому посмотреть и поиграться, цена вопроса - рублей 100 за какой-нибудь самый дешевый домен (главное не .ru/su/рф), а cloudflare бесплатен.
А как можно не указывать порт при создании inbound в панели 3x ?
Я когда ввожу /dev/shm/xrxh.socket,0666 и выбираю порт 0, панель возвращает значение 1 вместо 0 )
Оставить как есть. В json файле конфигурации и в списке входящих соединений в панеле будет 0. Почему-то в настройках инбаунда он 1 показывает, недоработка UI.
Настроил раздельный XHTTP по китайским гайдам. С одним доменом даже обошелся и через 3X-UI по большей части. Домен регистрируем в Cloudflare, у регистратора, где покупали прописываем кастомные DNS сервера, которые выдаст CF, включаем ему gRPC (в СF кабинет настройки домена, закладка Network), отключаем ECH, который запрещен в РФ.
На 3Х-UI сервере запускаем меню командой x-ui и выбираем там Cloudflare SSL Certificate. Нужно ввести свой имейл аккаунта CF, Global API Key (настройки домена в CF кабинете, вкладка Overview, внизу справа) и имя домена. Он создаст автоматом родной сертификат CloudFlare на 15 лет и импортирует его в панель. В вкладке SSL/TLS Encryption для домена в кабинете CF выбираем режим Full (Strict). Теперь вход только по CF сертификату.
В панеле 3Х-UI создаем новый инбаунд. Назовем, чтобы не запутаться Remark: Vision-Reality. Порт 443. Дальше именно щас важно в Fallback в поле Dest вписать порт 2023, на котором нас будет слушать следующий инбаунд. Transmission TCP. Дальше выбираем Security: Reality. Fallback исчезает, не пугайтесь, его настройки в JSON конфиге сохранятся. В Dest (Target) прописываем порт 7443, на котором будет слушать Nginx. Xver = 1, общаются они через Proxy Protocol. В SNI указываем наш cdn-domain.com. Возвращаемся в раздел Client и ставим Flow: xtls-rprx-vision. Возвращаемся в настройки Reality. Генерируем ключи. Жмем Create. Готово.
Создаем второй инбаунд. Remark: XHTTP. Listen 127.0.0.1. Port 2023. Transmission: XHTTP. Path: xhttp-path (такой же как в конфиге Nginx). Security: TLS. SNI: cdn-domain.com - ваш домен. Жмем Set Cert from Panel, он подставит сгенерированные ранее сертификаты CloudFlare. Create. Готово.
Код для сервера Nginx.
server {
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name cdn-domain.com www.cdn-domain.com; // Укажите свой домен на CloudFlare
location / {
try_files $uri $uri/ =404;
}
listen 127.0.0.1:7443 ssl http2 proxy_protocol;
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol;
ssl_certificate /root/cert-CF/cdn-domain.com/fullchain.pem; // Путь к сертификатам CloudFlare
ssl_certificate_key /root/cert-CF/cdn-domain.com/privkey.pem; // Путь к сертификатам CloudFlare
location /xhttp-path {
proxy_http_version 1.1;
proxy_pass http://127.0.0.1:2023;
proxy_redirect off;
proxy_request_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
server {
listen 80;
listen [::]:80;
server_name cdn-domain.com www.cdn-domain.com; // Укажите свой домен на CloudFlare
return 302 https://$server_name$request_uri;
}
Дальше нужно клиентскую часть загнать в V2RayN (единственный на сегодня клиент, который умеет в XHTTP). Здесь придется поколдовать руками, два наших соединения надо сшить в одного хитрого Франкенштейна. Экспортируем ключик от Vision-Reality в V2RayN. Он как есть работать не будет! Экспортируем его оттуда в буфер и допиливаем секцию “outbounds” в блокноте. Если у вас нет второго, “прямого” домена, вместо direct-domain.com просто вбиваем IP вашего Xray сервера.
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "cdn-domain.com", // Ваш домен CloudFlare
"port": 443,
"users": [
{
"id": "6cc4e521-e0db-4c7d-a4c6-453f5d8c64e8", // поменять на ID инбаунда XHTTP
"email": "t@t.tt",
"security": "auto",
"encryption": "none",
"flow": "xtls-rprx-vision"
}
]
}
]
},
"streamSettings": {
"network": "xhttp", //поменять на "xhttp"
// добавить объект "xhttpSettings"
"xhttpSettings": {
"mode": "auto",
"path": "/xhttp-path", // Path из инбаунда XHTTP
"extra": {
"downloadSettings": {
"address": "direct-domain.com", // прямой домен или IP Xray сервера
"port": 443,
"network": "xhttp",
"xhttpSettings": {
"mode": "auto",
"path": "/xhttp-path" // Path из инбаунда XHTTP
}
}
}
},
"security": "reality",
"realitySettings": {
"serverName": "direct-domain.com", // меняем на прямой домен или IP Xray сервера
"fingerprint": "chrome",
"show": false,
"publicKey": "ob_ZLNraBpBrEi5YuedCt_eg69IfXWBWANy86-lVKg0", // Публичный ключ инбаунда Vision-Reality, оставить как есть
"shortId": "4ef078", // Short ID инбаунда Vision-Reality, оставить как есть
"spiderX": "/"
}
},
"mux": {
"enabled": false,
"concurrency": -1
}
}
Импортируем снова в V2RayN. Запускаем, работаем!
Плюсы. Гиперпаранойность. Все запросы идут в восходящем потоке через CloudFlare, цензор не видит IP вашего VPS, вы обращаетесь к IP CDN. Нисходящий поток идет к вам с VPS, тут его IP видно, но связать домен с IP цензор не может. Детектировать такую схему намного сложнее.
Минусы. Сложность в настройке. Вырастут задержки из-за того, что у нас еще CDN появляется в цепочке. Также из-за того, что XHTTP шинкует трафик, снижается полезная полоса, т.е. несколько снизится скорость загрузок.
Гипотетически, если использовать VLESS+TLS со своим доменом с Ngnix на 80 и 443 порту для сайта-заглушки, то пока нет смысла прятать IP VPS?
Пока все работает. Это сильно паранойный сценарий на гипотетическое северокорейское будущее. Но и тут прибегут другие параноики, которые скажут, да этот ваш CloudFlare забанят к чертям. Нельзя исключать и такие варианты. Но как по мне, тут уже не настройки надо будет искать, а чемодан паковать.
По какой причине не сможет ?
Сама сеть выглядит подозрительно когда исходящие запросы идут в цдн и тут же возвращаются с какого-то непонятного айпишника, который на проверку окажется ещё и в пуле хост провайдера, тут же очевидно наш прокси хитрюля спрятался.
Не понятны такие телодвиженя, они рассчитаны на то что роскомнадзор будет честно себя вести ?
Тут как раз все безобидно выглядит. Я отправляю какие-то запросы на CDN, т.е. как будто члены семьи посещают какие-то сайты с котиками, за этим CDN сидящие. А параллельно с одного IP качаю файло, например, и на этом IP легальный файлообменник к тому же. Как цензор может это вскрыть и увязать, что это одна сессия? Как от свяжет моит параллельные запросы к эсктремисткому фейсбуку и к легальному новостному сайту, сидящими за одним CDN? Никак. За CDN он не видит, куда я хожу. На этом CDN и строят свою безопасность. На этом и китайский трюк строится. Как раз когда вы сидите постоянно в одном туннеле, этот трафик, хотя и тоже нельзя вскрыть, и посмотреть куда вы идете, но его можно хотя бы статистически анализировать. А тут что с чем коррелирует? Как это по пакетам вынюхивать? Тут головоломка на порядок сложнее.
и возвращаются оттуда же…
NowAndThen выше пишет что не оттуда, кто из вас прав ?
Мне казалось что в этом и смысл возни с Xhhtp - гонять трафик через цднку и маскировать айпи своего сервера.
цитата? я ничего не понял
Еще глюк обнаружился у этого сетапа. Хитрый юзерский ручной конфиг не стартует у меня при запуске V2RayN, нужно сначала выбрать какой-то другой конфиг, а потом переключиться на этот раздельный XHTTP. Т.е. в автозагрузке он не работает. И на Андроиде в V2RayNG запустить этот конфиг вообще не удалось. Вобщем, юзабельность этой технологии пока сильно в бета стадии.
Приветствую. Извиняюсь если подобный вопрос был, я не нашёл ответов.
Ловлю следующую ошибку:
[Info] transport/internet/splithttp: invalid x_padding length:0
Версии софта:
nginx/1.26.2Xray 24.12.31
Кто-нибудь сталкивался с подобным? Ниже приведу свои конфигурации nginx’а и xray’я как для сервера, так и для клиента.
На всякий случай сообщу что использую path поверх уже существующей конфигурации nginx’а под приложение. Однако, хочу заверить что схема с vless-nginx через websocket работала и работает, проблемы возникли при пробе XHTTP.
Некоторые переменные заменил, даю им здесь определение:
myhost- алиас сервера, не особо важно, просто строка для всяких директорийmy.host.com- домен для доступа к серверу через HTTP (ex: https://my.host.com/)mypath- путь в nginx’е перенаправляющий наxrayинстансmyuuid- мой uuid
Конфигурация nginx:
upstream myhost {
server unix:/srv/.venvs/myhost/run/gunicorn.sock fail_timeout=0;
}
server {
server_name my.host.com;
listen 80;
return 301 https://my.host.com$request_uri;
}
server {
server_name my.host.com;
listen 443 ssl;
listen 443 quic reuseport ipv6only=off;
ssl_protocols TLSv1.3 TLSv1.2;
ssl_certificate /etc/letsencrypt/live/my.host.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/my.host.com/privkey.pem;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GC M-SHA384;
client_header_timeout 5m;
keepalive_timeout 5m;
client_max_body_size 15M;
access_log /var/log/myhost/nginx/access/access.log;
error_log /var/log/myhost/nginx/error/error.log;
location /mypath {
client_max_body_size 0;
grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_body_timeout 5m;
grpc_read_timeout 315;
grpc_send_timeout 5m;
grpc_pass unix:/dev/shm/xrxh.socket;
}
location /static/ {
alias /srv/myhost/static/;
}
location / {
proxy_pass http://myhost/;
proxy_http_version 1.1;
proxy_connect_timeout 1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Конфигурация для xray server:
{
"log": {
"loglevel": "debug",
"access": "/var/log/xray/access.log",
"error": "/var/log/xray/error.log",
"dnsLog": false
},
"inbounds": [
{
"listen": "/dev/shm/xrxh.socket,0666",
"protocol": "vless",
"settings": {
"clients": [
{
"id": "myuuid"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"mode": "stream-up",
"path": "/mypath"
}
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "blocked",
"protocol": "blackhole",
"settings": {}
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "blocked"
},
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
}
]
}
}
Конфигурация для xray client:
{
"log": {},
"inbounds": [
{
"port": "1080",
"listen": "127.0.0.1",
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"outbounds": [
{
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "my.host.com",
"port": 443,
"users": [
{
"id": "myuuid",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"path": "/mypath",
"mode": "stream-up",
"#xmux": {
"maxConcurrency": 128,
"hMaxRequestTimes": 1000,
"hMaxReusableSecs": 3600
},
"#downloadSettings": {
"address": "my.host.com",
"port": 443,
"network": "xhttp",
"xhttpSettings": {
"path": "/mypath",
"#xmux": {
"maxConcurrency": 128,
"hMaxRequestTimes": 1000,
"hMaxReusableSecs": 3600
}
},
"security": "tls"
}
},
"security": "tls",
"tlsSettings": {
"alpn": [
"h3"
]
}
}
},
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "blocked",
"protocol": "blackhole",
"settings": {}
}
],
"routing": {
"domainStrategy": "IPOnDemand",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
}
]
}
}
Попробуйте в xhttpSettings добавить такие параметры, это панель 3X-UI ставит по умолчанию, там, я смотрел, автор тупо рекомендуемые параметры из документации по умолчанию подставляет.
"scMaxBufferedPosts": 30,
"scMaxEachPostBytes": "1000000",
"xPaddingBytes": "100-1000"
Спасибо за ответ и приношу извинения за глупый вопрос, оказывается invalid x_padding length:0 не актуальная ошибка.
С моего клиента не приходили запросы на мой сервер, я решил попробовать пингануть path через curl, а в дальнейшем принял логи с curl’а как за те, что пришли с клиента. Спутал их. Очевидно что с курла будет ошибка авторизации и вообще там не был отправлен padding.
Настоящая проблема в том что запросы с клиента не доходят по какой-то причине, по всей видимости слишком криворукая конфигурация клиента/nginx’а. Попробую потом как-то решить.
2025/01/04 01:37:17 [Debug] [2049168422] transport/internet: dialing to udp:my.host.com:443
2025/01/04 01:37:17 [Info] [2049168422] transport/internet/splithttp: failed to POST https://my.host.com/mypath/7300f7be-ced5-411d-b209-ba16096ac392?x_padding=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Post "https://my.host.com/mypath/7300f7be-ced5-411d-b209-ba16096ac392?x_padding=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000": lookup my.host.com: no such host
2025/01/04 01:37:17 [Info] [2049168422] proxy/vless/outbound: tunneling request to tcp:130.255.77.28:443 via my.host.com:443
2025/01/04 01:37:18 [Info] [2049168422] app/proxyman/inbound: connection ends > proxy/socks: connection ends > context canceled
2025/01/04 01:37:18 [Info] [1788824348] proxy/socks: TCP Connect request to tcp:130.255.77.28:443
2025/01/04 01:37:18 [Info] [1788824348] app/dispatcher: default route for tcp:130.255.77.28:443
2025/01/04 01:37:18 [Info] [1788824348] transport/internet/splithttp: XHTTP is dialing to udp:my.host.com:443, mode stream-up, HTTP version 3, host my.host.com
2025/01/04 01:37:18 [Debug] [1788824348] transport/internet: dialing to udp:my.host.com:443
2025/01/04 01:37:18 from tcp:127.0.0.1:65297 accepted tcp:130.255.77.28:443
2025/01/04 01:37:18 [Info] [1788824348] transport/internet/splithttp: failed to GET https://my.host.com/mypath/c6edd6a5-bf19-4a60-9c8a-681ea555b57e?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Get "https://my.host.com/mypath/c6edd6a5-bf19-4a60-9c8a-681ea555b57e?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000": lookup my.host.com: no such host
2025/01/04 01:37:18 [Debug] [1788824348] transport/internet: dialing to udp:my.host.com:443
2025/01/04 01:37:18 [Info] [1788824348] transport/internet/splithttp: failed to POST https://my.host.com/mypath/c6edd6a5-bf19-4a60-9c8a-681ea555b57e?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Post "https://my.host.com/mypath/c6edd6a5-bf19-4a60-9c8a-681ea555b57e?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000": lookup my.host.com: no such host
2025/01/04 01:37:18 [Info] [1788824348] proxy/vless/outbound: tunneling request to tcp:130.255.77.28:443 via my.host.com:443
2025/01/04 01:37:19 [Info] [1788824348] app/proxyman/inbound: connection ends > proxy/socks: connection ends > context canceled
2025/01/04 01:37:22 [Debug] app/log: Logger closing
Оказывается это была опечатка хоста. Но теперь по какой-то причине падает timeout: no recent network activity.
На сервере всё ещё никаких логов у xray’я или nginx’а. Надо будет разобраться.
2025/01/04 02:09:43 [Info] [2279113200] transport/internet/splithttp: XHTTP is dialing to udp:my.host.com:443, mode stream-up, HTTP version 3, host my.host.com
2025/01/04 02:09:43 from tcp:127.0.0.1:57906 accepted tcp:130.255.77.28:443
2025/01/04 02:09:47 [Info] [2279113200] transport/internet/splithttp: failed to GET https://my.host.com/xxx/d147a73b-cc81-4498-9681-c66d03d2bcb9?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Get "https://my.host.com/mypath/d147a73b-cc81-4498-9681-c66d03d2bcb9?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000": timeout: no recent network activity
2025/01/04 02:09:47 [Info] [4142068304] transport/internet/splithttp: failed to POST https://my.host.com/xxx/3533c363-8add-4ab0-9e03-7bc8a8593d5f?x_padding=0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Post "https://my.host.com/mypath/3533c363-8add-4ab0-9e03-7bc8a8593d5f?x_padding=0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000": timeout: no recent network activity
2025/01/04 02:09:47 [Info] [4142068304] proxy/vless/outbound: tunneling request to tcp:142.250.65.164:443 via my.host.com:443
2025/01/04 02:09:47 [Debug] [2279113200] transport/internet: dialing to udp:my.host.com:443
2025/01/04 02:09:48 [Info] [4142068304] app/proxyman/inbound: connection ends > proxy/socks: connection ends > context canceled
2025/01/04 02:09:48 [Info] [1739706259] proxy/socks: TCP Connect request to tcp:142.250.65.164:443
2025/01/04 02:09:48 [Info] [1739706259] app/dispatcher: default route for tcp:142.250.65.164:443
2025/01/04 02:09:48 [Info] [1739706259] transport/internet/splithttp: XHTTP is dialing to udp:my.host.com:443, mode stream-up, HTTP version 3, host my.host.com
2025/01/04 02:09:48 from tcp:127.0.0.1:57907 accepted tcp:142.250.65.164:443
2025/01/04 02:09:52 [Info] [2279113200] transport/internet/splithttp: failed to POST https://my.host.com/xxx/d147a73b-cc81-4498-9681-c66d03d2bcb9?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Post "https://my.host.com/mypath/d147a73b-cc81-4498-9681-c66d03d2bcb9?x_padding=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000": timeout: no recent network activity
2025/01/04 02:09:52 [Info] [1739706259] transport/internet/splithttp: failed to GET https://my.host.com/xxx/54c2b095-676f-4994-b4d8-54a5d2fca83e?x_padding=0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Get "https://my.host.com/mypath/54c2b095-676f-4994-b4d8-54a5d2fca83e?x_padding=0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000": timeout: no recent network activity
2025/01/04 02:09:52 [Info] [2279113200] proxy/vless/outbound: tunneling request to tcp:130.255.77.28:443 via my.host.com:443
2025/01/04 02:09:52 [Debug] [1739706259] transport/internet: dialing to udp:my.host.com:443
2025/01/04 02:09:53 [Info] [2279113200] app/proxyman/inbound: connection ends > proxy/socks: connection ends > context canceled
2025/01/04 02:09:53 [Info] [883022489] proxy/socks: TCP Connect request to tcp:130.255.77.28:443
2025/01/04 02:09:53 [Info] [883022489] app/dispatcher: default route for tcp:130.255.77.28:443
2025/01/04 02:09:53 [Info] [883022489] transport/internet/splithttp: XHTTP is dialing to udp:my.host.com:443, mode stream-up, HTTP version 3, host my.host.com
2025/01/04 02:09:53 from tcp:127.0.0.1:57910 accepted tcp:130.255.77.28:443
2025/01/04 02:09:56 [Debug] app/log: Logger closing
Подскажите, что вводить в хост и путь?
И кто-то сравнивал скорость и задержку между tcp и xhttp?
Отвечу немного не по теме:
Под vk.com не стоит маскироваться, если у вас зарубежный сервер. Если российский, то наверное ещё можно.
Host и Path по умолчанию пустые. Это для сложных ветвистых конфигураций, которые с nginx работают, чтобы обращаться к серверу по адресу myhost.com/mypath.
У меня vk в моей подсети есть.
Учитывайте, что при анализе подсети, показывает ровно то, что прописали арендаторы. То есть, вероятно это другой человек решил маскироваться под vk, а не их настоящий сервер.
Поэтому, например, из-за стандартных настроек в 3X-UI с маскировкой под yahoo.com - чаще всего встречается именно он) Но не всегда, конечно. Не стоит маскироваться под российский сайт, если сервер зарубежный. Это рекомендация не мной придумана, но в ней есть логика так как при обращении из РФ к российскому сайту идёт запрос к ближайшему серверу, а они находятся в РФ.
Поэтому под российские сайты можно маскироваться только если арендуете сервер в РФ.
Благодарю. Действительно кто-то маскировался под vk.
А как можно проверить, что мультиплексинг работает?
Читал, что с работающим мульт. должно быть меньше сессий, но как их вывести для глаз?
В случае с XHTTP рекомендуют отключить mux.cool
В v2rayN mux.cool == Turn on Mux Multiplexing ?
И какой лучше выбрать параметр в настройке sing-box Mux Protocol
Мультиплексинг может работает в режимах system proxy и TUN ?
В проге system informer вкладка network, там видно количество соединений. Singbox mux protocol не относится к xhttp, это встроенный mux в синге (работает с любым протоколом)
Singbox не поддерживает xhttp и такой поддержки вроде как не будет, это во первых. А во вторых мультиплексирование будет работать только когда и клиент и сервер xray, насколько помню
Тут только ручками считать ?
Помню был более удобный способ подсчитать колчиество соединений но я благополучно потерял вкладку со ссылкой.
В поиске надо ввести sing-box, локальные соединения считать нет смысла. На сервере можно это сделать тоже через ss или netstat. Ну и я типа не вижу смысла их считать, их либо 1 либо множество, варианты между не нужны
Всем привет.
У меня переход на xhttp прошел успешно.
Поставил самый свежий xray на сервер и на клиент. Обновил v2rayNG на Android телефоне.
Вот мой рабочий конфиг на xray сервере:
"inbounds": [
{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"tag": "reality-in",
"settings": {
"clients": [
{
"id": "ваш_ID",
"email": "email"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"host": "несуществущюий_сайт.com",
"path": "/здесь-несуществующий_путь_на_этом_сайте",
"read_idle_timeout": 10,
"health_check_timeout": 15,
"method": "GET"
},
"security": "reality",
"realitySettings": {
"show": false,
"dest": "известный_существующий_сайт:443",
"xver": 0,
"serverNames": [
"известный_существующий_сайт:443"
],
"privateKey": "ваш_приватный_ключ",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [""]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
},
Поменял только “network”: “http” на “network”: “xhttp”. И “httpSettings”: на “xhttpSettings”:
Вот рабочий конфиг xray клиента:
"outbounds": [
{
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "адрес_вашего_xray_сервера",
"port": 443,
"users": [
{
"id": "ваш_ID",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"host": "несуществущюий_сайт.com",
"path": "/здесь-несуществующий_путь_на_этом_сайте",
"method": "GET"
},
"security": "reality",
"realitySettings": {
"fingerprint": "chrome",
"serverName": "известный_существующий_сайт",
"publicKey": "ваш_публичный_ключ",
"spiderX": "",
"shortId": ""
}
},
"tag": "vless-server"
},
Поменял только “network”: “http” на “network”: “xhttp”. И “httpSettings”: на “xhttpSettings”:
Ссылка, которая работает в v2rayNG
vless://ваш_публичный_ключ@адрес_вашего_xray_сервера:443?mode=auto&path=%2здесь-несуществующий_путь_на_этом_сайте&security=reality&alpn=h2&encryption=none&pbk=ваш_публичный_ключ&host=несуществущюий_сайт.com&fp=chrome&type=xhttp&sni=известный_существующий_сайт#
Что изменил в настройка - вместо “Сеть h2” - поставил “Сеть xhttp, Режим XHTTP auto”.
Спасибо за ответы.
Кажется мультиплексирование у меня работает (xhttp_reality) → я вижу одно подключение к VPS на 443 со своего компа (да, sing-box не включается c xhttp)
Проверил еще в режиме tcp_xtls-rprx-vision+reality → я вижу несколько подключений к VPS на 443 порту… (с xray и sing-box)
Клиент v2rayN. Получается мультиплексирование хорошо работает только в первом случае с xhttp ?
Через какое то время появилось второе подключение (в режиме xhttp), так и висят оба активными течении часа.
Привет. У вас информация дает указание левого host и path ?
У меня host пусто, path /
Привет. Извините, не понял ваш вопрос.
У меня указанно, примерно, так:
"host": "prevedmedvedppppppp.com",
"path": "/abirvalgkkkkkkkkkk",
"method": "GET"
Ребят, можете подсказать как настроить xhttp+tls cdn CF? Просто уже сколько бьюсь над этим всё никак не рабоает, но другой .ru домен преспокойно работает всё с теми же настройками.
Вопрос в том, зачем указываете что-то в host и path ?
По умолчанию "host": пусто , "path": /
Вот вы указали абракдабру эту и что изменилось, в отличии от настроек по умолчанию?
Он поддерживается только синг боксом и включать нужно вручную
Да, отключил через curl
На андроид кроме v2rayNG какие еще приложения поддерживают xhttp ?
Здравствуйте, как у вас дела с XHTTP ?
Быть может появилась новая информация или заметки
Кто-то использует xhttp+cloudflare+nginx(grpc_pass)? При проксировании через cloudflare прокси работает нестабильно, через некоторое время начинает тормозить или сбрасывать соединение, в логах вижу ошибки “сonnection end”. Если подключаться напрямую к VPS, прокси работает четко, ничего не тормозит. Как будто cloudflare по какой-то причине обрывает подключения grpc.
Cloudflare закрывает grpc соединения которые загрузили >100мб, есть ли там ограничение на скачивание не знаю. А вообще на cloudflare есть вебсокет.
какая версия XRay? в самом новом релизе пару недель назад они там что-то поправили в протоколе как раз связанное с тем что CF рвал подключения после определенного времени.
Версия xray последняя 25.3.6 на сервере и на клиенте. Но проблема все равно остается.
Я настраивал по китайским гайдам, там 5 в 1.
С декабря и по начало марта работало всё очень хорошо, но потом действительно начались проблемы. Версии Xray на клиентах и на сервере обновлял по мере их выхода. Я использую варианты 3,4,5 и сейчас стабильно работает только 5, то есть когда аплинк идёт напрямую, а даунлинк через CF. В вариантах 3 и 4 там аплинк идёт тоже на CF и видимо в этом и проблема. На сервере в логах ошибок не пишет, соединения просто не доходят до сервера, в логах тишина. Если несколько раз пытаться обновить то примерно каждое пятое соединение срабатывает, логи на сервере оживают.
Не знаю почему так стало, возможно это из-за новых ограничений исходящего трафика на CF, с даунлинком через CF проблемы не возникают.