pjandro/3x-ui
1
0
Fork 0
mirror of https://github.com/MHSanaei/3x-ui.git synced 2026-11-12 16:15:02 +03:00
Code Issues Packages Projects Releases Wiki Activity

feat(outbounds): TLS for XDRIVE outbounds

Browse Source 
xray-core 26.10.10 dials an XDRIVE outbound's storage API with the
stream's tlsSettings: their SNI, uTLS fingerprint and ALPN are what the
API sees, which is the point of fronting it. canEnableTls kept XDRIVE out
of the TLS-capable networks, so the security picker never offered TLS and
switching a TLS outbound to XDRIVE silently reset it to none.

canEnableOutboundTls admits a TLS-eligible protocol on xdrive and backs
both the picker and the network-change cascade. Inbounds keep the plain
predicate: their tlsSettings carry server certificates, not a client hello.

Also restores the plain oxfmt / oxlint --fix lint-staged commands, reverting
da6872a3: that hook change was not wanted.
This commit is contained in:
MHSanaei
2026-10-11 15:44:17 +02:00
parent ef4bda4e06
commit c7d89ceac2
9 changed files with 99 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/content/docs/en/config/transports.mdx
+3 -1
View File
@@ -135,7 +135,9 @@ client; XDRIVE inbounds get no share link or Clash entry.
The optional **Front address/port** (the stream-level `address`/`port`) is a domain
front the storage API is dialed through; TLS still names the API host. XDRIVE has
no TLS/REALITY layer of its own — its traffic is the storage API's HTTPS.
no TLS/REALITY layer of its own — its traffic is the storage API's HTTPS. On an
outbound, **TLS** security shapes that HTTPS connection: its SNI, uTLS fingerprint
and ALPN are what the storage API sees.
## FinalMask — late-layer obfuscation