Я поставил на двух впсках ватсап прокси еще 12 числа, подключений к первой не делал, ко второй делал, но пока тихо. Порта 443 там достаточно, всё началось с того что забанили айпи на котором стоял реалити под ватсап
Для чистоты эксперимента имхо нужно 2 впс с wa прокси, к обоим постоянно делать подключения, на одной ограничить фаерволом коннекты только со своих айпи, на второй не использовать фаервол. Дальше можно делать выводы, если отлетает впс с фаером (или обе), это не сканер. Если отлетает только впс без фаера, это сканер.
Если впс без коннектов будет жить долго, это имхо мало о чем говорит, ведь ни сканер, ни теоретический анализатор трафика о ней никогда не узнает.
Обкатываю (вполне успешно) такую логику: раз мы хотим разделить upstream/downstream для xhttp, направив апстрим через cdn, чтобы детектировать проксирование было сложнее, то можно сделать проще и быстрее в плане скорости. Виртуалка с 2 айпишниками. 2 провайдера. Задаем маршрут до ip 1 через провайдера 1, маршрут до ip 2 через провайдера 2. В апстрим пишем ip1 (и домен 1), в даунстрим соответственно ip 2.
На nginx соответственно 2 домена, можно даже 3 уровня, которыйе имеют одинаковый локейшн, который проксирует на один и тот же инбаунд xray.
Провайдеры разные, ТСПУ разные, сопоставить 2 разных набора соединений они никак не могут.
От потенциальной блокировки подсети хостера оно не спасет, но в случае апстрима через cdn, блокировка сети хостера не спасет тоже, даунстрим у нас напрямую. А тут еще и скорость на аплоад хорошая и в бан клаудфлейра попасть не грозит.
Что за CDN?
На последней версии ядра появилось такое предупреждение в логах:
[Warning] common/errors: The feature VLESS (with no Flow, etc.) is deprecated, not recommended for using and might be removed. Please migrate to VLESS with Flow & Seed as soon as possible.
У меня там настроен только один инбаунд xhttp, и сообщение повторяется столько раз, сколько в нем добавлено клиентских id. Не особо понимаю, чего разраб хочет, ведь flow vision можно использовать только с транспортом tcp/raw. Более того, xhttp предназначен для прохождения cdn, а flow vision с ними принципиально несовместим. Может кто-то уже разобрался?
В релиз нотах увидел только одну пометку без конкретики:
Config: Add Warning for deprecated features (allowInsecure, Shadowsocks, VMess, Trojan, VLESS without flow) by [@RPRX](https://github.com/RPRX) in [5836f36](https://github.com/XTLS/Xray-core/commit/5836f36f69bc4253ef96336d0c129b7f4b99ad2a)
XTLS-Vision теперь пролезает через CDN с включенным VLESS шифрованием.
Вместо encryption/decryption none нужно явно указывать ключи, сгенерированные через xray vlessenc. Я проверил и всё работает, правда вопрос актуальности остаётся.
Без явно указанного “flow”: “xtls-rprx-vision” теперь будет всегда warning.
как влияет на производительность есть понимание?
Пруфы будут? VLESS Enc относится только к тому что бегает внутри соединения, а Vision - это его наружняя часть. “Vision пролезает через CDN” звучит как фантастика, потому что это принципиально противоречит тому как работает терминирование TLS на CDN.
Upd. посмотрел доки, и авторы XRay в принципе пишут ровно то что я сказал:
XTLS is only available under the following combinations:
TCP+TLS/Reality: In this case, encrypted data is directly copied at the underlying layer (if transmitting TLS 1.3).
VLESS Encryption: No underlying transport restrictions. If the underlying layer does not support direct copying (see above), it only penetrates Encryption.
По факту с XHTTP/WS/gRPC это не настоящий полноценный XTLS-Vision, а используется только паддинг от всего этого (своеобразный костыль потому что Seed прибили гвоздями к Vision, а оказалось что оно далеко не всегда нужно одновременно).
Не знаю, разницы на глаз не заметил. Я проверил - работает. Warning исчезает. Пока так оставил.
Чего именно? Что это работает? Ну так сделай так же да и всё.
Почему работает? Я не знаю. Моей целью было убрать warning и я его убрал таким образом. Время будет изучу более детально, пока мне не до этого.
Да, с указанием flow и decryption/encryption всё работает, предупреждение пропало, трафик при этом проходит cdn и реверс прокси.
Можешь конфигами поделиться? Сделал также, но пинг скачет и скорость 30 Мбит/сек.
Помогите понять, каковы адекватные настройки mode\xmux в наших реалиях при использования XHTTP для подключения напрямую до сервера с self-steal (VLESS-XHTTP-Nginx).
Правильно ли я понимаю, что в данной схеме большого смысла от разделения на upstream/downstream нет и можно использовать stream-one?
Какое стоит выставлять количество соединений? Не станет ли установка maxConnections 1 паттерном для ТСПУ?
тут в других темах упоминали, что наоборот множество подключений к одному ip может заинтересовать ТСПУ, у меня как раз стоит maxConnections 1.
Имеет-ли смысл, при использовании XHTTP-Reality, добавлять Authentication: decryption/encryption (выбор из X25519 и ML‑KEM‑768)? Сколько не пытался найти информации про это, вижу только, что не имеет смысла. Если кто разобрался для чего эти параметры, они нужны?
и единичный коннекшн повод (но получше чем просто tcp), и множественные соединения когда врубают рейт лимит. На сервере ставите auto, а в клиенте меняете под ситуацию
В контексте сибирского блока вопрос и задан. ЕМНИП была информация, что лимит был в 12 подключений. Интересует именно стоит ли указывать одно соединение, либо подбирать по диапазону, входящему в лимит.
В этих ситуациях и хочется разобраться. Например, в случае использования с CDN, либо промежуточных серверов, польза от разделения upstream/downstream очевидна, но в ситуации с прямым подключением нет понимания, имеет ли это смысл.
Это про VLESS Encryption, а не Reality, там только MLKEM768 поддерживается. Тут всё написано.
Edit: ссылался не на тот header.
Потестировал у себя Reality + XHTTP на 3X-UI и обнаружил, что он адово плодит и удерживает подключения (на данный момент 14 тысяч при паре десятков клиентов), из-за чего Xray начинает жрать много памяти и в конце концов тупить. Знаю, что это решается на стороне клиента настройками XMUX. Но я многим просто отправляю ссылку на подписку в 3X-UI, через которую, насколько я знаю, нельзя передать нужные клиентские параметры для ограничения подключений.
И вот как с этим быть?
del
Знаю, что так можно. Но я раздаю подключения через подписку на случай новых блокировок.
Держит клиент, если его от этого не отучить тюнингом этих параметров:
"xmux": {
"maxConcurrency": "16-32",
"maxConnections": 0,
"cMaxReuseTimes": 0,
"hMaxRequestTimes": "600-900",
"hMaxReusableSecs": "1800-3000",
"hKeepAlivePeriod": 0
}
Вот картина с настройками по умолчанию.
Между браузером и локальным инбаундом 4 подключения (socks5):
$ ss -Ht state established dst 127.0.0.1:1080 | wc -l
4
А до удалённого прокси-сервера 30 (XHTTP):
$ ss -Ht state established dst remote-proxy:443 | wc -l
30
Если активного обмена трафиком нет, то эти 30 подключений всё-таки медленно закрываются (пока писал, стало 25). Но такое поведение приводит к тысячам подключений на сервере, когда по факту требуется меньше.