Grpc на nginx -> xray vless. Где-то есть подвох?

,
1

Последние годы пользовался xray с TLS и fallback на собственный сайт - все работало как часы.

На днях заскучал и решил попробовать что-нибудь новое. В рамках диалога с ChatGPT по поводу установки nginx на публичный порт и xray на локальный пришел к варианту grpc с клиента на nginx + редирект по определенному servicename (пути) - ChatGPT сказал, что это прям топчик - лучше всяких хваленых xhttp, ws и tls+fallback.

Все прекрасно запустилось. Судя по комментам ИИ - обфускация топ. Да и скорость процентов на 5-10 стала повыше.

Но почему-то в рунете я ни разу не замечал, чтобы кто-то предлагал такую схему. Разве что с дополнительным проксированием через CF.

В этой истории где-то есть подвох? Мне, кстати, казалось, что кто-то писал, что grpc в РФ блокируют.

P.S. Я - человек не настолько прошаренный в сетевых историях, поэтому пишите попроще, пожалуйста)

Спасибо!

2

grpc не блокируют, да и он в зашифрованном трафике (если тлс вкл). Непонятно почему его стал продвигать чатгпт, ведь он хуже в общем (bufferbloat), “скорость стала выше” это погрешность тестирования, единственное что может быть быстрее это tcp хеншдейк при открытии сайтов (который в grpc только один против множества в tcp/etс транспортах).
Xhttp можно настроить и он будет внешне выглядить так же (если тлс вкл).
Плюс - mux: всё множество соединений через прокси проходит через одно grpc соединение и не будет триггерить сибирскую блокировку

3

Спасибо!

Про скорость - я не тестировал, чисто собственные ощущения. Пинг остался тем же, но по факту при каждом переходе/обновлении приложения/страницы пауза стала меньше.

Еще такой момент - grpc висит на том же 443 порту. Это похоже на обычный трафик в этом плане? ws и grpc вешают вообще на 443 или используют отдельный порт?

И что такое сибирская блокировка, если не секрет?)

4

Не зацикливайтесь на маскировке, это не нужно, работает - отлично. (Я бы вообще убрал nginx и поставил порт 40ххх чтоб от ботов было меньше трафика)

Ограничение на количество тлс сессий (около 10, дальше блок)

5

Здесь могу ошибаться, т.к. по сути цитирую чатгпт - но прослойка в виде веб-сервера в этом сценарии исключает какие-либо следы самого xray core.

Про порт - тешу себя мыслью, что 443 всегда выглядит наименее подозрительным, когда через него проходит по 200гб трафика в месяц. Ну а на производительность более высокий порт, как я понимаю, не влияет.

6

Сложилась ли практика применения данной схемы?) Пришел к ней исходя из следующих задач (сейчас использую vless-tcp-reality):

  1. Избавиться от reality в пользу tls + свой домен + полноценный серт. Кажется, что таким образом большой трафик на одну точку будет выглядеть менее подозрительно, особенно если поднять там настоящую файлопомойку, или вообще какой-нибудь gitea.

  2. Избавиться от tcp в пользу grpc для борьбы с сибирской блокировкой.

7

Изначально использую nginx + свои серты как внешний фронт. Он позволяет:

  • фильтровать пробники на левые домены и пропускать только свои
  • разделять разные домены на любые listeners (и xray и прочие сервисы) и вообще на всякие порты через stream
  • возвращает пробникам совершенно валидный и ровный fingerprint от официального nginx
  • обрабатывает тот же grpc_pass с любого вложенного path для xhttp и при этом отдает любые “нужные“ имитации для fallback - хоть minio, хоть seaweed, хоть черта лысого )
8

Не подскажите как настроить xhttp, чтобы он не создавал огромное кол-во конектов ?
xmux пробовал. не помогает
xray-core клиент, сервер - nginx-grpc-xray

9

mode - stream-one, alpn - h2, extra: {"xmux":{"maxConnections":1}}
и ещё обязателен вкл tls, уж почему не знаю.
экспортнутый конф клиента из v2rayN показывает это

        "tlsSettings": {
          "allowInsecure": false,
          "serverName": "sni",
          "alpn": [
            "h2",
            "http/1.1"
          ],
          "fingerprint": "chrome"
        },
        "xhttpSettings": {
          "path": "",
          "host": "qwe.com",
          "mode": "stream-one",
          "extra": {
            "xmux": {
              "maxConnections": 1
            }
          }
        }
10

У меня nginx за tls отвечает

11

ну для теста могу полный конф в лс скинуть

12

Ваша общая проблема в том, что xhttp по умолчанию теперь ведет себя как tcp и спамит коннекциями. В xmux нужно все параметры задавать в явном виде на стороне клиента, иначе происходит следующее: (выдержка из XHTTP: Beyond REALITY · XTLS/Xray-core · Discussion #4113 · GitHub)

Эти параметры XMUX позволяют создавать различные комбинации. Например, для многопоточного теста скорости нужно установить "maxConcurrency": 1, а для «бесконечного» переиспользования — "maxConnections": 1.

Примечание: Если ничего не заполнять, это равносильно всем нулям (применяются значения по умолчанию). Но если заполнен хотя бы один параметр, значения по умолчанию для остальных отключаются, и всё нужно заполнять самостоятельно (кроме первых двух, которые взаимоисключающие).

Выделено жирным это то, почему ваши соединения будут висеть и переиспользоваться вечно, по крайней мере если не используется какой-то миддл-бокс в виде CDN или реверс прокси, который сам их грохнет.

Я писал об этом тут Блокировка VLESS-xtls-rprx-vision-Reality в России? (Нет, частичная блокировка TLS) - #790 by xActo

13

Все это опробовано.
Чтобы бы ни правил, конекты плодятся простыней нестата как ему захочется.
По крайней мере в моей конфе с nginx+grpc pass.
Вписано в правильное место. Если вписать оба конкуренси и максконнекшинс, идет ругань. Значит он видит параметры

        "xhttpSettings": {
                "path": "/secret_uri",
                "mode": "stream-one",
                "extra": {
                        "xPaddingBytes": "100-1000",
                        "xmux": {
                                "maxConcurrency": "1",
                                "#maxConnections": 1,
                                "cMaxReuseTimes": 0,
                                "hMaxRequestTimes": "600-900",
                                "hMaxReusableSecs": "1800-3000",
                                "hKeepAlivePeriod": 0
                        }
                }
        }


Xray 26.2.6 (Xray, Penetrates Everything.) 12ee51e (go1.25.7 linux/amd64)
A unified platform for anti-censorship.
14

Надо вписать и maxConcurrency со значением 0, и maxConnections: 1. У меня так работает (тоже nginx с grpc pass стоит перед xray), удерживается ровно один коннект.

15

Да, действительно. Видимо незаданный параметр принимает значение по умолчанию !=0 и перебивает заданный

16

Да, там значение по умолчанию “16-32”.

17

У меня примерно такая-же схема, но напрашиваестя вопрос - а не слишком ли экстремально заворачивать весь трафик в один коннект? Получается достаточно жирный долго живущий туннель. Возможно ошибаюсь, но вроде типичный браузер ведет себя иначе. Или стоит какая-то иная задача? Сам сижу на таких настройках:

"xmux": {
    "maxConcurrency": 8,
    "maxConnections": 4,
    "cMaxReuseTimes": 0,
    "hMaxRequestTimes": "150-300",
    "hMaxReusableSecs": "300-600",
    "hKeepAlivePeriod": 60
}
18 
"maxConcurrency": "1",
"maxConnections": 1,

В этом конфиге maxConcurrencyозначает, что внутри одного соединения может быть только один поток данных от приложения(-ий), которые стучатся на вход прокси. В свою очередь, maxConnectionsэто ограничение на общее количество соединений с сервером, которые как раз видит ТСПУ. Т.е. такая прокси при (1,1) не может проксировать больше одного потока, а все остальные нужно было бы reject’ить. Для того, чтобы таких ошибок в конфигурации избежать, xray не позволяет задавать одновременно оба параметра, поэтому можно либо выставить maxConcurrency = 0и maxConnections = 1, либо оставить только последний.