Доброго времени суток. Я имею не сильно большой опыт в настройках xray, но большу часть конфигурации пишу руками, а не через всякие панели по типу 3xui. Сейчас я использую vless с xtls reality vision, но предполагаю, что в РФ научились блокировать подсети хостеров, на которых выявляют подозрительные соединения на основе TLS 1.3, поэтому я бы хотел иметь запасной маршрут и хотя бы не на пару месяцев. Почитал про xhttp, но как понял с ним проблема в мобильных сетях т.к. CDN по типу CF, Gcore и которые подходят для этой цели также блокируют. Понимаю, предсказать что будет завтра сложно, но все таки, что можно использовать в качестве запасного выхода на случай полной блокировки TLS 1.3 и популярных CDN?
Если я где-то ошибся в терминологии прошу прощения.
XHTTP не обязательно использовать с CDN, он вполне себе работает и без них.
Reality действительно не переживает блокировку TLSv1.3. Решение простое - использовать простой VLESS-over-TLS или VLESS-over-XHTTP, но не с Reality, а со своим доменом. Домен можно взять бесплатно на https://freedns.afraid.org/, dynu.com или даже sslip.io, сертификат получить от Let’s Encrypt с помощью certbot.
Я бы выбрал вариант с XHTTP, чтобы на 443 порту с валидным сертификатом слушал Nginx, а XRay стоял за ним через grpc_pass. Плюс такого варианта в том, что к прокси-серверу можно будет подключаться и по TCP-TLS, и через QUIC.
Пример конфига тут: Xray-examples/VLESS-XHTTP3-Nginx at main · XTLS/Xray-examples (да и вообще в той репе очень много хороших примеров).
А что до CDN - если есть иностранная карта, то могу в личку подсказать недорогой забугорный CDN который не блокируют (но там ограничение по трафику, ютуб не погоняешь, только как экстренная запасная мера).
Спасибо большое. Не будет ли конфликта 2х indound’ов в таком случае они же на один порт сядут я так понимаю? У меня есть зарубежная карта (криптовалютная).
Если речь про QUIC, то для него второй inbound не нужен, он делается средствами Nginx.
А если речь про то, что вы хотите оставить Reality как основной inbound, то там все сложнее.
Вариант раз: настроить streal-from-yourself. Это когда Reality маскируется не под чужой вебсайт, а под ваш собственный с вашим доменом.
Схема, конечно, будет сильно сложнее:
Запрос принимает XRay с reality-inbound на 443 порту. Если проверка Reality пройдена - работает прокси, если нет - запрос передается на Nginx (например на 127.0.0.1:8443).
Дальше запрос обрабатывает Nginx. Если там запрошен / или любой другой урл, то он отдает фейковый веб-сайт или страницу ошибки (401, 403, 404, you name it). Если запрошен секретный URL для XHTTP, он передает запрос обратно в XRay на XHTTP-inbound, например на 127.0.0.1:8444.
Для QUIC Nginx всегда будет слушать на 443/udp.
В этом случае все по красоте - Reality работает напрямую, XHTTP работает если забанили TLS1.3, на все левые запросы отвечает настоящий Nginx.
Вариант другой:
Nginx слушает порт 443, с помощью ssl_preread зависимости от SNI передаем запрос или на Reality-inbound, или на сам Nginx, и дальше как прошлом пункте.
Но смысла в таком я особо не вижу - будет как-то странно, если на одном и том же сервере будет одновременно и сайт с вашим доменом и сайт с каким-то левым доменом, да и преимуществ никаких это не дает.