pjandro/3x-ui
1
0
Fork 0
mirror of https://github.com/MHSanaei/3x-ui.git synced 2026-10-21 13:25:00 +03:00
Code Issues Packages Projects Releases Wiki Activity

fix(xray): keep XDRIVE storage and Vision flow within what xray-core runs

Browse Source 
xray-core opens an XDRIVE stream's storage only when the inbound starts
listening, so a Google Drive inbound saved with the form's defaults (no
folder, no secrets), a local one without a folder, or a template one
whose template xray cannot use stopped xray and every other inbound with
it. validateXDriveStorage applies the core's storage rules at save, on
inbound add/update and on the xray template's inbounds and outbounds:
the service must be local, Google Drive or template; local and Google
Drive need a remoteFolder; Google Drive needs its three non-empty
secrets; a template must pass newTemplateStorage's checks (put, get,
list and delete urls, and a list namesRegex with one capture group).

A VLESS client kept its xtls-rprx-vision flow when its inbound moved to
a transport that cannot carry it, and GetXrayConfig only honoured
DisableFlow, so the server demanded Vision there and refused every
client. GetXrayConfig and the outbound form now apply the Vision gate,
and that gate now follows the core in the backend, the subscription
service and the frontend: TLS/REALITY on raw TCP, or VLESS encryption on
any transport (xray runs Vision inside encryption.CommonConn whatever
the transport, not only on XHTTP). The outbound modal passes the VLESS
encryption into the gate and gates Mux on the effective flow.
This commit is contained in:
MHSanaei
2026-10-12 00:49:11 +02:00
parent 8fe7be943f
commit c5e1e54c75
22 changed files with 439 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files
internal/sub/service.go
+5 -13
View File
@@ -1193,21 +1193,13 @@ func vlessEncryptionEnabled(settings map[string]any) bool {
return false
}
// vlessFlowAllowed reports whether a client's XTLS Vision flow belongs in
// generated links/configs. Mirrors inboundCanEnableTlsFlow in
// internal/web/service: Vision runs on TCP with tls/reality (classic), and on
// XHTTP whenever VLESS encryption (vlessenc / ML-KEM) is enabled — there the
// VLESS-level encryption stands in for the transport TLS that Vision relies
// on, regardless of the stream security layer (so XHTTP+REALITY+vlessenc
// keeps its flow too).
// vlessFlowAllowed mirrors inboundCanEnableTlsFlow in internal/web/service: Vision runs over
// TLS/REALITY on raw TCP, or inside VLESS encryption on any transport.
func vlessFlowAllowed(network, security string, settings map[string]any) bool {
switch network {
case "tcp":
return security == "tls" || security == "reality"
case "xhttp":
return vlessEncryptionEnabled(settings)
if network == "tcp" && (security == "tls" || security == "reality") {
return true
}
return false
return vlessEncryptionEnabled(settings)
}
func (s *SubService) genVlessLink(inbound *model.Inbound, email string) string {
internal/sub/service_flow_test.go
+2 -1
View File
@@ -26,7 +26,8 @@ func TestVlessFlowAllowed(t *testing.T) {
{"tcp tls", "tcp", "tls", noEnc, true},
{"tcp reality", "tcp", "reality", noEnc, true},
{"tcp none", "tcp", "none", noEnc, false},
{"tcp none vlessenc", "tcp", "none", enc, false},
{"tcp none vlessenc", "tcp", "none", enc, true},
{"ws none vlessenc", "ws", "none", enc, true},
{"xhttp none vlessenc", "xhttp", "none", enc, true},
{"xhttp reality vlessenc (#5232)", "xhttp", "reality", enc, true},
{"xhttp tls vlessenc", "xhttp", "tls", enc, true},