На своем ВПС использую 3x-ui, с Vless+XTLS+Reality. Настроен он таким образом, что весь трафик, не от клиентов проксирует на 127.0.0.1:4433, где слушает nginx и отдает простенькую страничку заглушку. Если в запросе есть путь, к примеру /Rt648fj1jg6/, то nginx проксирует на 127.0.0.1:40345, где висит панель 3X-ui. Хочу сделать резервный канал - еще один inbound, на который будет проксировать nginx, если Reality перестанет работать, например порежут TLS 1.3. Думаю какой протокол выбрать c условием, чтобы поддерживал sing-box, так как реализую все на роутере с openwrt и там стоит sing-box с Ruantiblock. Ну и чтобы было устойчиво к РКН, более или менее. Какой лучше: Vless+websocket? Vless+TLS?
vless+Tls+grpc, vless+grpc, но с fallback там гемор на сколько я помню, не делаю его
Могу ошибаться, но по моему там несколько vless с reality и чем-то ещё одновременно запустить нельзя. Из-за разных требований к параметру flow что ли. Хотя может я с TLS+fallback путаю.
основной inbound у вас будет как и сейчас Reality.
в качестве “dest” (куда будут передаваться подключения не прошедшие проверку Reality) указываете ваш локально слушающий Nginx (например 127.0.0.1:8443).
В Nginx делаете grpc_pass для секретного URL’а, который вернет подключение на другой локально слушающий gRPC-inbound XRay (например 127.0.0.1:8444), типа как тут (там вместо 127.0.0.1 используется unix-socket, но принцип тот же самый).
А еще на 443/udp можете поставить Hysteria2 как запасной вариант. Sing-box умеет к нему подключаться как клиент.
Зачем всё так усложнять, если можно просто сделать доступной панельку только с локалхост и открывать её через тунель?
Чтобы иметь возможность попасть на панель в ситуации, когда туннель не доступен - если его блочат, или у тебя под рукой просто нет конфига для подключения. Достаточно знать свой домен и url панели.
Добавил еще один inbound с websocket, в nginx добавил location /mywspath - все заколосилось, в том числе и на роутере.
сделал websocket, у меня nginx не поддерживает grpc_pass, а переустанавливать его неохота стало. Чем хуже websocket, если хуже? Поспрашивал ИИ, он говорит, что websocket выглядит для DPI не подозрительно, тем более за nginx.
у тебя тлс, дпи ничего не видит за тлс. grpc это однопоток, вебсокет будет триггерить сибирскую блокировку если она дойдёт до тебя
Можно чуть подробнее, если не лень? Как “сибирская блокировка” палит вебсокет?
сибирская блокировка: если за короткое время установлено >12 тлс соединений = блок
Спасибо, буду обновлять nginx тогда и настраивать grpc
grpc через nginx может быть гемор чтобы нормально работало, но точно не помню.
для уменьшения bufferbloat можно добавить в sysctl.conf
net.ipv4.tcp_notsent_lowat=16384
а вообще в sing-box есть свой mux который решает сибирскую блокировку (max_connections=1, сам mux должен быть включен и на сервере тоже)
в sing-box нашел multiplex, вроде понятно как его включить. Не нашел сходу, как его включить на стороне сервера, в частности панель 3x-ui?
есть один характерный признак. ни Xray, ни Nginx, ни почти ничего другое не умеют вебсокеты поверх h2. так что ALPN всегда будет “http/1.1”.
здесь хорошо бы помогло использование mux.cool. Но у автора на сервере sing-box, он такое не умеет. Ну либо на сервере тоже ставить sing-box и использовать yamux/smux/h2mux.
и еще важное для вебсокетов - ?ed=4096 (для клиентов xray) и early_data_header_name/max_early_data для клиентов sing-box.
у xray и у sing-box несовместимые реализации мультиплекса.
получается единственно правильным будет вместо websocket использовать grpc? Принято ))
Добавил в клиенте для android husi (ядро sing-box) в параметры вот это:
“multiplex”: {
“enabled”: true,
“protocol”: “smux”,
“min_streams”: 4,
“padding”: false
}
транспорт websocket, подключается нормально, работает. Добавил эти же параметры в sing-box в openwrt и получаю ошибку:
curl --interface ws https://api.myip.com
curl: (35) ssl_handshake returned: (-0x7280) SSL - The connection indicated an EOF
Может кто подскажет куда копать?
на сервере тоже sing-box?