Здравствуйте!
По статьям на Хабре, удалось настроить xray сервер (обычный ПК x64_86 на linux). Как можно добавить в конфиг сервера ещё одного пользователя (в конфиге настройки для clients, id, privateKey и т.д) и чтоб каждый из них шёл на свой outbounds-protocol?
ничего непонятно, выкладывайте конфиг и пишите подробнее
Конфиг:
Спойлер
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 2443,
"protocol": "vless",
"tag": "reality-in",
"settings": {
"clients": [
{
"id": "UUID",
"email": "user1",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.microsoft.com:443",
"xver": 0,
"serverNames": [
"www.microsoft.com"
],
"privateKey": "privatkey",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [""]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "http",
"tag": "proxy",
"settings":
{
"servers": [
{
"address": "127.0.0.1",
"port": 3128
}
]
}
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
Здесь, пользователь в конечном итоге подключается к локальному прокси (на той же системе). А другой пользователя (его нужно как-то ещё оформить), должен подключаться к другому прокси, тоже на той же системе.
Я вообще верно понимаю что для нового пользователя не нужен новый отдельный конфиг и соответственно второй экземпляр xray?
почему не использовать второй inbound с другим портом?
пробуйте, не проверял
"clients": [
{
"id": "UUID",
"email": "user1",
"flow": "xtls-rprx-vision"
},
{
"id": "UUID2",
"email": "user2",
"flow": "xtls-rprx-vision"
},
],
...
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"user": ["user1"],
"outboundTag": "proxy1",
"type": "field"
},
{
"user": ["user2"],
"outboundTag": "proxy2",
"type": "field"
}
]
}
В серверном конфиге у тебя есть privateKey и shortIds(один или несколько).
В клиентском конфиге есть publicKey (который “сгененирован в паре” с серверным privateKey) и shortIds(должен быть быть в серверном списке shortIds).
Так вот серверный конфиг должен содержать один privateKey и количество shortIds, соответствующее количеству юзеров.
А клиентские конфиги будут содержать один и тот же publicKey, но разные shortIds.
shortid может быть одним для разных пользователей или вообще пустым, если в списке на сервере есть вариант “”. Отличаться должны только UUID. Кроме того, в правилах routing используется именно имя user, а не UUID, поэтому правило может быть универсальным для разных протоколов (например vless и shadowsocks).
Если UUID сгенерирован по имени юзера, а не рандомно, то в клиенте можно использовать понятное имя:
xray uuid -i “custom string”
не стоит, некоторые клиенты (HiddifyNext) глючат на сочетаниях некоторых символов
ну так-то они глючат и если в ключе shadowsocks залетает “\”. Но v2ray/nekobox переваривают нормально
По поводу, почему не использовать… я просто не знаю что лучше. Предложенная вами часть конфига работает как нужно. Не подумал бы, что user из email использовался бы в правилах для outbound, для второго пользователя я его решил пропустить. Тут получается что privatekey (и public) одинаковые, я думал что они должны быть разные. И ещё не понятно, какие секции с какими можно (или даже нужно) сочетать.
Есть небольшая проблема. К прокси, к которому обращается xray, xray формирует запросы типа таких:
CONNECT remote_host:port HTTP/1.1
Можно ли их привести к виду:
GET http://remote_host:port/ HTTP/1.1
В последнем случае, это когда в браузере непосредственно указан прокси, который в конфиге xray указан в “servers”: [ { “address”: “127.0.0.1”, “port”: 3128 } ], т.е. чтоб запросы через браузер->xray->remote_proxy не отличались, как если бы не было xray, т.е. так браузер->remote_proxy.
По стандарту запросы к прокси должны быть:
Для HTTP:
GET http://remote_host:port/ HTTP/1.1
или
POST http://remote_host:port/ HTTP/1.1
А в случае создания туннеля для проброса HTTPS:
CONNECT remote_host:port HTTP/1.1
В данном конкретном случае, я подключаюсь к удалённому серверу по http. Да через туннель. Например stunnel это не смущает.
Да полноты картины, объясню чего добиваюсь. В моей локальной сети есть nas, на нём есть plex. К нему я подключаюсь с мобильного устройства. На мобильном устройстве установил nekobox, на маршрутизаторе (это другой девайс), который обслуживает локальную сеть установил xray-сервер. Я подключаюсь к plex из браузера, (nekobox при этом работает), набирая обычный локальный адрес nas. Но подключение не происходит, в логе прокси, который работает на маршрутизаторе (в конфиге xray тот что 127.0.0.1:3128) видно, что запрос идёт как connect. Этот прокси фильтрующий. Он не подключает, выдавая ошибку “Error: The TLS/SSL handshake with the client failed: error:0A00009C:SSL routines::http request”. Если запрос идёт через get, то ошибки нет. Аналогичное происходит, если я подключаюсь к сайту, который работает по не защищённому протоколу http, так же не подключается. Чтоб работало, в прокси я должен отключить фильтрацию, но по идее это должно работать только для сайтов https. В общим, в моём кейсе, отключение фильтрации не нужно.
Не знаю насчёт XRay, но V2Ray/V2Fly не поддерживает не-CONNECT-методы. Полагаю, что то же самое и в XRay.