Reality по определению не может работать через CDN, потому что когда TLS-соединение терминируется на CDN, то поля типа session id, необходимые для работы Reality, до XRay просто не дойдут в оригинальном виде.
Без Reality - пожалуйста.
И это не зависит от используемого транспорта, что XHTTPS, что gRPC, что вебсокеты - без разницы. Так что работать с другими транспортами с Reality оно у вас тоже не должно было, если «сработало», то скорее всего ошиблись в конфигурации и либо законнектились напрямую без CDN (например не успел обновиться DNS или было взято значение из кэша), либо не включили Reality, либо на сервере у вас reality dest стоял на другой inbound xray, других вариантов просто нет.
Можно, конечно, было бы допустить совершенно фантастический вариант что в каких-то случаях Cloudflare зачем-то переиспользует исходные session id и другие поля при проксировании соединения на origin, но нет - просто потому что вы не сможете делегировать на CF чужой фейковый домен, и фронтинг на CF тоже не разрешен.
В таком случае какая связка под xhttp будет перспективнее, с reality+xhttp или xhttp+cdn?
просто vless+tls со своим доменом: fingerprint xray-сервера отличается от фингерпринта веб-сервера, подозрительно (хотя я не видел упоминания, что РКН делает пробинг и как-то обращает вниманий на этот факт), работает с TLS 1.2/1.3 по HTTPS
reality + чужой фейковый домен: фингерпринт соответствует фингерпринту чужого сервера, используется чужой популярный домен (можно пролезать через белые списки), только TLS 1.3
reality + steal-from-yourself - фингерпринт сервера полностью соответствует обычному веб-серверу (который стоит за xray), но работает только с TLS 1.3 по HTTPS
xhttp без reality - фингерпринт сервера полностью соответствует обычному веб-серверу (который стоит перед XRay), как с CDN, так и без, работает не только с TLS 1.3, но и с TLS 1.2, и кроме HTTPS может еще работать через QUIC. Чужой домен (и обход белых списков) можно использовать только если CDN разрешает фронтинг.
Что-то всё равно так и не получается завести xhttp через cdn CF. Пробывал как с security tls так и без ничего. Попробывал во всех 4 режимах: auto, packet-up, stream-up, stream-one. Пробывал ipv4 и ipv6, на портах 433 и 80. Без cdn во всех вариантах работает, через cdn только на вебсокетах получается, xhttp не проходит почему то(. Клиент выдаёт ошибку: net/http TLS handshake timeout. Что я сейчас не так делаю?
Спойлер
{
“port”: 433,
“listen”: “ipv6”,
“protocol”: “vless”,
“tag”: “xhttp-in”,
“settings”: {
“clients”: [
{
“id”: “uuid”,
“email”: “123”
}
],
“decryption”: “none”,
“fallbacks”:
},
“streamSettings”: {
“network”: “xhttp”,
“xhttpSettings”: {
“headers”: {
“User-Agent”: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36”
},
“method”: “GET”,
“mode”: “auto”,
“host”: “несуществующий домен”,
“noSSEHeader”: false,
“path”: “рандомная строка”,
“scMaxBufferedPosts”: 30,
“scMaxEachPostBytes”: “1000000”,
“scStreamUpServerSecs”: “20-80”,
“xPaddingBytes”: “100-1000”
}
},
“sniffing”: {
“destOverride”: [
“http”,
“tls”,
“quic”
],
“enabled”: true,
“metadataOnly”: false,
“routeOnly”: false
}
}
Почему несуществующий то? CF не разрешает фронтинг, поэтому и на клиенте и на сервере должен быть указан существующий (совпадающий с SNI). На сервере этот параметр вообще не обязательный, лучше не указывать (как и user-agent, он там вообще ни к месту).
Еще на CF в настройках должно быть включено проксирование gRPC.
И еще важно посмотреть, что в логах сервера творится в момент подключения, логов клиента недостаточно чтобы что-то сказать.
Ну и традиционное - перевести на CF домен из proxies в прозрачный режим (dns only) и попробовать подключиться напрямую.
Вместо одного потока, через который идёт как загрузка, так и скачивание, трафик делится на два отдельных потока:один для загрузки, другой для скачивания. Это позволяет немного играться с трафиком, например, загрузка идёт через Cloudflare, а скачивание через обычный Reality с совершенно другим SNI(gRPC ли сокеты, но с минимальной задержкой и высокой скоростью) . Или же, загрузка через Cloudflare CDN, а скачивание через Gcore CDN. Ещё можно загружать через reality, который работает через HTTP/2(TCP) и скачивать через TLS+HTTP/3 (QUIC). Также, трафик на загрузку дробится, прямо как goodbye dpi, что делает жизнь цензоров ещё хуже. Для DPI это будет выглядеть как очень активный браузинг и скачивание обычного файла(Packet-up. Пакетная загрузка, потоковое скачивание. Stream-up/one. Потоковая загрузка и потоковое скачивание). Насколько я понял, смысл XHTTP - сделать его настолько сложным для DPI, что накладные расходы на его распознание будут абсурдно велики, а разделение трафика будет выступать в качестве дополнительной защиты т.к теперь DPI нужно будет пытаться соотнести два совершенно разных трафика, которые могут идти с разных SNI, CDN и даже серверов в разных странах, друг с другом. Например, ты загружаешь что-то через сервер CF, находящийся в Польше, а скачиваешь что-то по QUIC/UDP из Казахстана (Если маршрутизация настроена правильно, то понят, что на серверах стоит xray понять невозможно). Пока это overkill и в большинстве случаем можно спокойно пользоваться vless-xhttp-reality со stream-one(Максимальная скорость как загрузки, так и скачивания) или xhttp+CDN+tls со Stream-up/one(gRPC) или Packet-up, но создатель протокола готовиться сразу к худшему из возможного и пытается создать “мастер-ключ” от любой “тюремной камеры”)
П.с 0: На всякий случай, если у вас есть домен для Cloudflare, настройте всё так, чтобы загрузка шла через CDN, а скачивание напрямую с сервера(CDN_up_Reality_down) . Может помочь в случае ухудшение ситуации с блокировками
П.с 1: Т.к скачивание потоковое и без дробления, то потери скорости, в сравнении с обычным TCP+Reality, максимум 10% и задержки выросли тоже очень незначительно(XHTTP+Reality) , а защита от распознания TLS-in-TLS достигается за счёт xmux, нового алгоритма ответственного за мультиплексирования
П.С 2:Если в чём ошибся, прошу поправить)
Спасибо, все это интересно. Еще бы faq как это настроить всё. Да и с cdn cloudflare нынче сложно. Блочат его
У Cloudflare очень много различных IPv4 и серверов. Один IP заблочили - другой разблочили т.ч связь будет пропадать, но через час-два всё может начать работать снова. Но с гайдами и вправду проблемка… Я тоже долго мучался с настройкой, но вот этот пример неплохо помог: xhttp 五合一配置 ( reality 直连与过 CDN 共存, 附小白可抄的配置) · XTLS/Xray-core · Discussion #4118 · GitHub
P.S: Вместо Nginx можно использовать Caddy. Caddy прекрасно подходит, если у тебя нет планов продавать подписки, а иначе лучше использовать Nginx для максимальной производительности
Благодарю. Да, нечто похожее уже прочитал на хабре, один из участников форума написал там статью на тему xhttp. Штука интересная.
По поводу Caddy кстати согласен, удобно.
А для глупых, при настроенном транспорт если подключение работает значит все окей?
Попробовал посмотреть по логам, ничего связанного с xhttp не увидел
При уровне логирования info в error.log должно быть как минимум.
transport/internet/splithttp: XHTTP is dialing to tcp:d1.name:443, mode stream-up, HTTP version 2, host d1.name
transport/internet/splithttp: XHTTP is downloading from tcp:d2.name:443, mode stream-down, HTTP version 2, host d2.name
При более детальном будет подробнее.
Спасибо где то видимо накосячил в конфиге есть только это
INFO - XRAY: transport/internet/splithttp: listening TCP for XHTTP on 0.0.0.0:504
INFO - XRAY: transport/internet/splithttp: listening TCP for XHTTP on 0.0.0.0:504
INFO - XRAY: transport/internet/splithttp: listening TCP for XHTTP on 0.0.0.0:504
Пойду разбираться
Такое ощущение, что при использовании подключения vless-xhttp-tls через Cloudflare (проводной интернет, Cloudflare не блокируется) сам Cloudflare распознает xhttp как подозительный трафик, DDoS и т.п. и через некоторое время применяет некий троттлинг, временное замедление соединения. Помогает переподключение, но на некоторое время.
Вроде бы не похоже на вмешательство ТСПУ. Если переключить на “устаревший” в xray транспорт, например, httpupgrade, то соединение долго работает стабильно.
Кто-то сталкивался с такой проблемой?
У меня тоже сервер за CF, блокировок 16кб на домашнем провайдере нет, но у меня правда никакой не фейк, а полноценный сайт на WP. Стоит Nginx+PHP+FPM+MySQL в общем всё как положено.
Сегодня Xray обновил до последней версии, всё стабильно работает. У меня Stream-up через CF, а down напрямую с сервера через другой левый домен. Но я стараюсь не наглеть и не гоняю весь ненужный трафик через прокси, только то что мне нужно. CF ещё ни разу не ругался. Для ютюба и подобного xhttp не юзаю, для этих целей у меня другие варианты пока отлично справляются.
Выше по теме есть много ссылок на полезные мануалы, попробуйте разные методы.
У меня Stream-up через CF, а down напрямую с сервера
Т.е. у Вас большая часть трафика идет напрямую через VPS, т.к. трафика down больше. Ну и IP сервера засвечивается. В такой конфигурации проблем, действительно, быть не должно. А если гонять down и up через Cloudflare, то, видимо, превышаются какие-то лимиты или определяется трафик, как подозрительный, и включается троттлинг.
Именно так и есть. Не вижу в этом проблем, пусть засвечивается. У меня и обычный reality ещё там есть, им я даже чаще пользуюсь. Для параноидного режима со скрытием всего и вся пока нет крайней необходимости.
Так тоже всё нормально работает, никакого тротлинга нет. Я не случайно сказал, смотрите мануалы выше, там есть примеры как можно настроить серверный кофиг сразу на несколько вариантов. В дальнейшем настройки меняются только на клиенте в зависимости от потребностей, серверные настройки остаются как есть.
Но повторюсь, у меня там полноценный сайт, а не просто заглушка на чистом html как у многих. Возможно это играет свою роль и CF никак не реагирует, потому что ещё и обычные пользователи заходят и пользуются сайтом по прямому назначению. Вы конкретно по каким мануалам настраивали?
Мануалы разные использовал. Попробовал транспорт grpc через Cloudflare, тоже через какое-то время начинает лагать соединение, пока не переподключишь. Но я прогоняю иногда через прокси потоковое видео. Возможно, как раз, и срабатывают лимиты на трафик (предположение, опять же). Если использовать конфигурацию xhttp up-CF down-VPS, не лагает пока что, видимо, потому что up-трафика проходит гораздо меньше через Cloudflare.
Как альтернативу, пробую Cloudflare Tunnel (cloudflared) c пробросом TCP-трафика на локальный socks-прокси на сервере. Посмотрю, как будет себя вести подключение вдолгую, если гонять по-больше трафика.
Xhttp работает только при условии использования CDN?
Со стороны российских CDN легко секут xhttp.