Да, отключил через 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 проблемы не возникают.
UPD 23.03.25
Вот прям почти сразу же после того, как я написал этот пост, всё вернулось в норму. Отлично стало работать XHTTP через CF, так же как и раньше. Я никакие настройки ни Xray ни Nginx вообще не трогал. Значит проблемы возникают из-за ТСПУ, либо на самом CF.
Похоже, что этот issue связан с моей проблемой. Соединение отключается, если через Cloudflare используется режим stream-up. У меня был настроен режим auto, в этом случае подключался режим stream-up.
Попробовал на download настроить режим auto, а на upload режим packet-up. Пока проблем не наблюдается, надо последить.
У меня были похожие проблемы как тут и в посте выше. До начала марта всё было ОК во всех режимах, затем начались периодические проблемы с кратковременными отвалами в мониторинге. Я сначала думал, что это CF начало душить проксирование через себя, но позавчера в мониторинге легли разом все аутбаунды, где использовался XHTTP в режиме stream-up через CF, И также аутбаунды с классическим vless с транспортом grpc через CF. (stream-up, если кто не в курсе это HTTP/2 с маскировкой заголовков под grpc для потоковой передачи)
У меня довольно много серверов на разных хостингах и доменов под нужды проксирования через CF, клиенты есть в разных частях РФ, так что какие-то локальные проблемы я исключил сразу. Проверил извне РФ - stream-up и grpc подключения прекрасно работают. Вывод - это результат деятельности ТСПУ. Сейчас помогает на upload режим packet-up, т.к. это по сути голый HTTP транспорт. Заблочить его, не заблочив все сайты за CF, они не смогут. Но судя по всему это уже вопрос времени теперь.
Sing box по прежнему игнорируют xhttp?
Никто еще не просил разраба его добавить. можешь сам попросить на github, но ожидай самый бредовый ответ, такой уж разраб.
Мой запросто вынесли в корзину через пару минут после создания. 
У меня произошла достаточно интересная ситуация.
После мартовских экспериментов РКН с Cloudflare стабильно работал только режим packet-up, вот вообще без нареканий. Stream-up не работал вовсе (v2rayN писал -1 после запуска), голый Xray тоже не работал с ним, steam-one работал, но через раз и очень не стабильно.
Не так давно у моего VPS провайдера случился сбой, который они не смогли исправить, в результате мне выдали полностью новый сервак с другим IPv4 и IPv6 адресом. И вот на удивление с новыми IP все 3 режима сразу же заработали вообще без каких-либо проблем! Уж не знаю что это было, сам Cloudflare как-то ограничивал или РКН руку приложил, но видимо проблема была связана с IP. Сейчас с новыми адресами работает очень шустро во всех режимах + обычный reality. У тех у кого работает только packet-up попробуйте попросить хостера сменить вашему VPS IP адреса. Возможно поможет.
или же просто зайдите по url на свой домен через браузер, если cloudflare вас заблочил (прокси по правилам запрещены и некоторые блочатся) то это будет видно (будет сообщение о блокировке, не ошибка). packet режимы постоянно нагружают cdn запросами и добавляют мусорный трафик, смысла в их использовании на cloudflare не вижу и осуждаю. (как и вебсокет, но он хотя бы не шлёт сотню запросов в секунду)
Разумеется я так делал. Всё нормально работало со старыми IP, сайт открывался без каких-либо проблем. Curl’ом тоже пробовал, всё работало отлично, никаких ошибок.
А у меня был выбор? Все остальные не работали. Сейчас как ipшники поменялись снова использую stream-up.
вебсокет в рф не блокировался, да и внутри https не видно какой там протокол, если не работает то скорее настраиваете неправильно. впс у вас скорее всего тоже не на hetzner и cloudflare для доступа к ней не нужен
Ещё с декабрьских версий Xray пишет при запуске конфигов с ws:
[Warning] common/errors: This feature WebSocket transport (with ALPN http/1.1, etc.) is deprecated and being migrated to XHTTP H2 & H3. Please update your config(s) according to release note and documentation before removal.
И потом тут тема про тесты XHTTP, я и пишу относительно тестов и режимов, которые относятся непосредственно к этому. Я прекрасно знаю ещё 101 способ как обойти мне блокировки без участия CDN, но речь была не об этом. Разумеется XHTTP у меня запасной способ и 24/7 я его не использую и терабайтами данные не качаю.
Подскажите, пожалуйста, для XHTTP я могу за основу брать подключение через WebSocket, а не gRPC? Вот мой конфиг для nginx WebSocket. Будет работать или нужно что-то поменять?
location /justapath {
if ($http_upgrade != "websocket") {
return 404;
}
proxy_pass http://127.0.0.1:1111;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
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_read_timeout 52w;
}