Поднимал в декабре, XHTTP + Reality, в конце июня отвалился сразу на всех провайдерах одновременно (моб. и домашний). IP сервера не в блоке, пинг есть, tcp соединение через браузер работает корректно, даже на порт 8443, на котором висит тоннель. SSH тоже стабильно, но траффик через VLESS не идет. На домашнем интернете иногда проходят 2-3 пакета, потом тишина. На мобилке вообще глухо.
Что перепробовал?
– Смена fingerprint → не помогло
– Cмена dest → не помогло
– Смена mode на packet-up → не помогло
– Настройка XMUX → не помогло
– Смена портов – 443 и др. → не помогло
Не понятен сам принцип блокировки и причина резкого отвала сразу на всех провайдерах (обычно начинается с мобильных операторов, а потом уже переходит на проводных). Хотя сам ip и привязанный к нему домен через браузер работает.
Если настроить xmux с 1 коннектом максимум, отключиться, открыть страницу в браузере, и через 30 секунд включить xray - не работает? Клиент и сервер насколько актуальны?
Можно поднять на 4123 порте свой https сайт и как цель вписать 127.0.0.1:4123, сам туннель при этом на 443.
Маскировка под многие сайты почему-то просто так может перестать работать. Иногда помогает смена ключей.
Ну и уже стандарт для 26 года - лучше делать каскадный ВПН, между ними теги обратного проксирования, писали тут на форуме ранее
Учитывая “в конце июня” не думаю, что это ваш кейс, но всё же.
Я сегодня обновил у себя панель 3xui, которая подтянула последнюю версию ядра xray и положила мне все соединения (включая hysteria2).
Оказалось ядро v26.7.11 теперь придирается к клиентской версии ядра при использовании Reality. Если она не указана явно в после в MinVersion, то по дефолту пускает только клиентов с версией ядра новее v26.3.27. А клиенты имеют свойство работать на довольно старых ядрах.
После указания 0.0.0 (или можно конкретную указать) соединения пошли как по маслу.
После обновления до 26.7.11 перестал работать reality на нескольких серваках, при этом TLS продолжал работать, думал всё, кабздец стали SNI к IP сравнивать, а оказалось дело в ограничении версии клиента, а я mihomo на клиенте пользуюсь.
Самое интересное, что RPRX нигде не указывает о каких либо изменениях, кроме коммитов в Git или в своем канале в Telegram (который еще и полон тонной щитпоста и, откровенно говоря, сомнительными постами о его личной жизни). В чейнжлогах одни спонсоры. Три часа мучался, пытаясь понять что и как, и в итоге откатился. Достало это уже, хоть на sing-box уходи.
Похоже они не сами их качают, это нейрослоп-панель 3x-ui обновилась до “стабильной” версии 3.5, куда она решила включить двухдневной давности релиз Xray-core. Это точно не человек делал, а бредогенератор (и по истории коммитов тоже видно).
Проблема в том, что последний релиз не вполне stable. Как минимум в нем большие проблемы с wireguard outbound, с которыми я сам сталкивался на двух разных серверах и долго не мог понять причину. Там есть какой-то issue на эту тему, может быть исправления даже попали в одну из pre-release версий, но релиз уже несколько месяцев сломан.
Короче, не панацея. Но да, согласен, что подробный чейнджлог для релизов всегда публикуется.
Я уже указывал об этом, и это отвратительная практика. Почему я должен мотать десятки коммитов, чтобы узнать, что было добавлено или исправлено в бета-версии? Да даже прикрутить github-actions бота, который автоматически генерирует чейджлог исходя из коммитов.
Вчера-позавчера возникла подобная проблема на проводном (крупный провайдер из топ 4).
Схема: stream-up, Client → Cloudflare → VPS → Nginx → Xray. Разные домены на upload и download. Reality не используется.
Признаки:
Запрос с клиента не доходит даже до nginx и не виден в его access логах. Крайне редко что-то пробивается.
Используемые IP с виду не под 16-20. Домены тоже не в блоке. Страницы открываются. Large file с доменов можно скачать, как и зайти на этот самый path xhttp, даже методом POST (в логах nginx это видно, возвращает 400).
На другом забугорном VPS запустил клиент-конфиг xray к данному, и на нём же пробовал курлом сайты открывать - нормально. Т.е. вроде и не cloudflare блок.
Изучай логи в дэшэ CF, я сталкивался с подобным - триггерилась защита от ddos от CF из-за огромного количества запросов от клиента, а происходило это потому что тспу гадило и рвало сессии.