Тестируем XHTTP

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 кстати согласен, удобно.