Зачем вы меняете reality на что-то другое? Какой у вас хостинг? Его тоже блокируют?
Провайдер pq hosting. Я прочитал просто всю тему и увидел в конце Ваше сообщение “Обход блокировок через vless-tls, reality, xhttp - бесполезен, т.к. у них тоже отправляются Client Hello.
Обходится блокировка протоколами, которые скрывают Client Hello, например, vless-tcp, vless-mkcp, vless-http” и вот как раз думал как сделать vless-http например через 3x-ui. В данный момент используется nginx с сайтом на своем vps ( steal-from-yourself) и vless+reality, которая перестала подключаться в ленинградской области, но в Иваново все ок. Не хотелось бы уходить от провайдера с учётом того, что сервер до конца года арендовал вот и читал тему как остаться на нём, но обойти эту блокировку.
Понятно. Но я httpupgrade не проверял и как его через панель настраивать не знаю. Но, судя по ответам chatgpt, должен прятать ответы в пакетах upgade. Попробуйте сделать как вам советовали выше, в новом профиле создать httpupgrade без шифрования. Reality лучше оставить, и даже настроить несколько профилей с разными протоколами, т.к. никогда не знаешь как начнут в следующий раз блокировать. Да и на разных провайдерах может один обход работать, а на другом нет.
Вариант простой: создаете в панели новый inbound в VLESS, транспортом httpupgrade и без TLS на порту 80 и с безобидным path типа /websocket_chat. Все работает.
Вариант чуть сложнее: если у вас на порту 80 слушает Nginx с вашим фейковым сайтом (которому вы делаете steal), создаете в панели в панели новый inbound в VLESS, транспортом httpupgrade и без TLS на порту типа 8080 или 18080, адресе 127.0.0.1 (локалхост) и с безобидным path типа /websocket_chat, а потом в конфиге Nginx для 80 порта добавляете правило, чтобы подключения вебсокетов с урлом /websocket_chat реверс-проксировались на 127.0.0.1:8080:
location /websocket_chat {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Accept-Encoding "";
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;
proxy_redirect off;
access_log off;
error_log off;
}
Этот вариант лучше в плане маскировки (отвечает настоящий Nginx и на 80 порту крутится реальный сайт).
И еще совет - вместо VLESS для вебсокетов использовать VMESS - настраивается точно так же, но раз уж вы используете нешифрованный HTTP, то хотя бы хендшейки не будут с голой жопой (зачеркнуто) в открытом виде по интернету летать.
И самое важное: не забывайте на клиенте ?ed=2048 (или даже ?ed=4096) в path (так называемое early data).
на моб сети проверял на счёт блока? все таки чистый vmess там блочится
Так речь выше конкретно про вебсокет-транспорт.
Если голый HTTP сам по себе работает и нет блока на Upgrade: websocket (а если есть, то можно XHTTP попробовать, главное чтоб клиент его умел), то для цензора уже без разницы, что там внутри бегает, VLESS или VMess - цензоры пока еще до уровня “смотрим что там внутри вебсокетов” не доросли и неизвестно когда дорастут (принцип Неуловимого Джо), а если и дорастут - то VLESS там заблокировать будет еще гораздо проще чем VMess (зато внезапно может помочь Trojan - там первые 56 байт by design должны быть читаемым ASCII-текстом)
найти хендшейк или какие другие признаки vmess в 1 пакете (чистый vmess) или в 5 со смещением (vmess в http upgrade) разница не большая как мне кажется.
Вопрос был работает или нет, я проверил - да работает.
Так у VMess нет выраженной сигнатуры хендшейка, его по длине пакетов блокируют. И вебсокеты это дело усложняют - там первые данные от VMess будут уже не в первом, а во втором пакете (после ответа сервера) если по умолчанию, или в зависимости от выставленного значения ED часть хендшейка может оказаться в первом пакете, а часть во втором (примерно как работает Zapret). То есть DPI надо уже быть stateful и держать в памяти метаданные предыдущих пакетов. Это все более ресурсоемко и требует переработки алгоритмов работы.
Большое спасибо за подробное объяснение, вроде всё сделал, как Вы советовали, но вот вообще не работает почему-то. Не могли бы Вы подсказать почему? Кстати неожиданно vless+reality на pq hosting, который 4 дня не работал, заработал в Ленинградской области. И хотел бы уточнить: Вы написали " не забывайте на клиенте ?ed=2048 (или даже ?ed=4096 ) в path (так называемое early data).“, я для собственного развития, когда читал про httpupgrade увидел такое " Если в пути клиента содержится параметр ed (например, /mypath?ed=2560 ), будет активирована функция Early Data для уменьшения задержки, ее значение - порог длины первого пакета. Если длина первого пакета превышает это значение, Early Data не будет активирована. Рекомендуемое значение - 2560.”, поэтому хотел бы уточнить почему Вы рекомендуете ?ed=2048 (или даже ?ed=4096?
У вас зачем-то порт стоит 50396 (видимо баг панели, она то про nginx ничего не знает). Исправьте на 80.
Потому что когда-то давно рекомендованное было 2048, а потом авторы XRay немного поменяли протокол и рекомендовали его увеличить, но я не помнил насколько - я у себя ставил 4096, через nginx оно пролезает нормально. В любом случае, как вы процитировали документацию, оно определяется размером первого пакета, так что можно и 2560 и 4096, особой разницы не будет.
Большое Вам спасибо, всё заработало! Жалко конечно, что в документации нет информации о том, что Вы написали (ну или я не нашёл) (про то, что авторы XRay немного поменяли протокол и рекомендовали его увеличить).
А ради интереса XHTTP я так понимаю по той же логике настраивается, не знаете?
Да, нашёл информацию о который Вы рассказали.
на pq работает Remnawave со стандартным профилем vless и со selfsteal с доменом или сабдоменом. маскировку вместо warp (он похоже там заблочен) можно делать через tor webtunnel
поставьте в панели Listen IP в 127.0.0.1, а то у вас этот порт светит наружу. Не критично, но лучше так не делать.
В просто варианте - да. В панели просто выбрать xhttp, остальные параметры остаются такие же. В nginx надо немного поменять конфиг, вместо proxy_pass сделать grpc_pass как здесь (на самом деле gprc-протокол там не используется, это обманка для Nginx чтобы он не мешал работе XHTTP).
На клиенте добавляется настройка mode c вариантами packet-up, stream-up и stream-one, рекомендую второй.
Важно, что версия XRay-ядра клиента совпадала с версией ядра на сервере - иначе могут быть странные глюки, или вообще ничего не будет работать, т.к. XHTTP протокол активно развивается и там часто происходят всякие изменения ломающие совместимость.
Ну и в XHTTP есть и более сложные варианты, поскольку в режимах packet-up и stream-up происходит разделение потоков (входящие и исходящие данные идут по разным подключениям) там можно упарываться сложными схемами, например “туда” данные слать по IPv4 на один домен, а “обратно” данные получать по IPv6 с другого домена. Чтобы у РКН волосы на заднице дыбом встали 
Edit: отвалились серваки, потому что я сдуру не заметил, как скрипт изменил мне дату на 2021 год, всё нормально, прошу прощения за беспокойство)
Сэлф Стил ?пробовали менять на не селф стил sni/порты?
На каких хостингах vless не работает?
Если по nginx не открывается то это не блокировка vless, а всего https, то ест тактика обезьяны с гранатой
Почему дата 2021г? В ошибке как бы написано что дата у тебя не верная.
Это верно. Только хотел написать. Отбой, скрипт для Vegas Pro сменил дату на 2021 год и не вернул обратно. Прошу прощения за тупость, продолжаем пользоваться нормальным интернетом)
Любопытно, что прошло очень много часов до того, как начали проявляться хоть какие-то проблемы, связанные с датой, хотя обычно браузер должен сразу посылать.
