xHTTP + Reality + Steal Oneself. Возможно ли?

Так не поднимай сайт визитку, ктож вас всех заставляет это делать? Подними любой легковесный веб апп с авторизацией или навайкодь себе свой.

Благодарю всех кто поделился ссылками для изучения информации.
Удалось завести озвученную в названии треда связку, используя nginx впервые в жизни.
Для это использовал 2 поддомена

Спойлер
stream {
    variables_hash_max_size 2048;
    variables_hash_bucket_size 128;
	
	# Бэкенды
    upstream xray_backend {
        server 127.0.0.1:2443;
    }

    upstream web_backend {
        server 127.0.0.1:8443;
    }

    # Определяем бэкенд по SNI
    map $ssl_preread_server_name $backend {
        xray.example.ru  xray_backend;
        default          web_backend;
    }

    server {
        listen 443 reuseport;
        listen [::]:443 reuseport;

        ssl_preread on;

        proxy_pass $backend;
        proxy_protocol on;

        proxy_connect_timeout 10s;
        proxy_timeout 300s;
        proxy_buffer_size 16k;
    }
}

Использую в 3x-ui следующие настройки. Кстати крайне важной оказалось “xver”: 1, без этой настройки не работало подключение к xray и не открывался сайт на поддомене для xray.

Спойлер

Товарищи, посоветуйте, пожалуйста, где почитать лучшие практики настройки xhttp со стороны сервера и клиента?
Самостоятельно разобраться, что в xhttp хорошо, а что плохо мне практически невозможно в силу недостаточных знаний о сетях

xActo, подскажите, что в вашем понимании легковесное вебприложение? Хочу понять более конкретные критерии, например, из каких компонентов оно должно состоять

Которое жрет не больше пары десятков мб ram.

Единственный компонент который нужен это страница авторизации, с рабочим джаваскриптом а не статический html из генератора. То что она может никуда не вести, это уже никто не узнает. Для простоты можно поставить authelia и направлять на https://auth.yourdomain.com

Мне интересно, эта практика чем-то обоснована или просто кто-то когда-то это предположил и все остальные подхватили? Я думаю, что если ркн будет в ручном режиме проверять сайт, то он и без всяких авторизаций поймет, что сервер используется для впн. Сеть хостера и паттерн трафика - двух этих факторов уже будет достаточно, чтобы забанить айпи “на всякий случай“, раз уж дошли до стадии ручной проверки. Но вручную, конечно же, никто не будет проверять десятки тысяч мелких сайтов.

Я уже давно просто возвращаю http 404 и стандартную nginx-страницу. Проблем ни разу не было

Практика пришла от китая, где боты-краулеры GFW помечают серваки, которые не отдают что-то похожее на функциональный веб сайт (с JS, robots и т.д.), для ручной проверки. У нас пока и правда достаточно 404 отдавать.

По умолчанию уже все настроено оптимально и обычно нет смысла что-то подкручивать до тех пор пока тспу не обнаружит его. Если сильно хочется, то можете потестить скорость с разными mode и xmux. Почитайте: XHTTP: Beyond REALITY · XTLS/Xray-core · Discussion #4113 Тестируем XHTTP - Censorship circumvention methods & software - NTC Кратко про XHTTP для VLESS: что, зачем и как / Хабр

настроил вот по этому гайду GitHub - filip-lebiecki/xray-xhttp · GitHub всё збс работает