@gozargah/xray-schema 0.0.4 → 0.0.5

package/dist/full/index.d.ts

@@ -1387,7 +1387,7 @@ declare const xraySchema: z.ZodObject<{
       }>>>;
     }, z.core.$strip>>;
     protocol: z.ZodLiteral<"vless">;
-    settings: z.ZodObject<{
+    settings: z.ZodUnion<[z.ZodObject<{
       address: z.ZodString;
       port: z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodString]>;
       id: z.ZodString;
@@ -1414,7 +1414,22 @@ declare const xraySchema: z.ZodObject<{
           routeOnly: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         }, z.core.$strip>>;
       }, z.core.$strip>>;
-    }, z.core.$strip>;
+    }, z.core.$strip>, z.ZodObject<{
+      vnext: z.ZodArray<z.ZodObject<{
+        address: z.ZodString;
+        port: z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodString]>;
+        users: z.ZodArray<z.ZodObject<{
+          id: z.ZodString;
+          encryption: z.ZodDefault<z.ZodString>;
+          flow: z.ZodOptional<z.ZodEnum<{
+            "": "";
+            "xtls-rprx-vision": "xtls-rprx-vision";
+            "xtls-rprx-vision-udp443": "xtls-rprx-vision-udp443";
+          }>>;
+          level: z.ZodOptional<z.ZodDefault<z.ZodInt>>;
+        }, z.core.$strip>>;
+      }, z.core.$strip>>;
+    }, z.core.$strip>]>;
   }, z.core.$strip>, z.ZodObject<{
     sendThrough: z.ZodOptional<z.ZodUnion<[z.ZodString, z.ZodEnum<{
       origin: "origin";

package/dist/full/index.js

@@ -2732,26 +2732,65 @@ const trojan = outboundSchemaBase.extend({
 	settings: trojanServerSettings.or(z.object({ servers: z.array(trojanServerSettings).meta({ markdownDescription: trojanServers_default }) })).meta({ markdownDescription: trojanSettings_default })
 }).meta({ markdownDescription: trojan_default });
 //#endregion
+//#region src/outbounds/vless/vless.md?raw
+var vless_default = "VLESS is a stateless lightweight transport protocol. It consists of inbound and outbound parts and can serve as a bridge between the Xray client and server.\n\nUnlike [VMess](https://xtls.github.io/en/config/outbounds/vmess.html), VLESS does not depend on system time. The authentication method is also UUID.\n\n[Documentation ↗](https://xtls.github.io/en/config/outbounds/vless.html)\n";
+//#endregion
+//#region src/outbounds/vless/vlessSettings.md?raw
+var vlessSettings_default = "`OutboundConfigurationObject` corresponds to the `settings` item in [`OutboundObject`](https://xtls.github.io/en/config/outbound.html).\n";
+//#endregion
+//#region src/outbounds/vless/vlessAddress.md?raw
+var vlessAddress_default = "Server address, points to the server. Supports domain names, IPv4, and IPv6.\n";
+//#endregion
+//#region src/outbounds/vless/vlessPort.md?raw
+var vlessPort_default = "Server port, usually the same as the port the server is listening on.\n";
+//#endregion
+//#region src/outbounds/vless/vlessId.md?raw
+var vlessId_default = "User ID for VLESS. It can be any string less than 30 bytes, or a valid UUID. A custom string and its mapped UUID are equivalent.\n\nThe mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to UUIDv5](https://github.com/XTLS/Xray-core/issues/158).\n\nYou can use the command `xray uuid -i \"custom string\"` to generate the UUID mapped from a custom string, or use the command `xray uuid` to generate a random UUID.\n";
+//#endregion
+//#region src/outbounds/vless/vlessEncryption.md?raw
+var vlessEncryption_default = "[VLESS Encryption](https://github.com/XTLS/Xray-core/pull/5067) settings. Cannot be left empty; to disable, explicitly set to `\"none\"`.\n\nIt is recommended for most users to use the `xray vlessenc` command to automatically generate this field to avoid configuration mistakes. The detailed configuration below is recommended only for advanced users.\n\nIts format is a detailed configuration string of fields connected by `.`. For example: `mlkem768x25519plus.native.0rtt.100-111-1111.75-0-111.50-0-3333.ptjHQxBQxTJ9MWr2cd5qWIflBSACHOevTauCQwa_71U`. This document will refer to the separate parts separated by dots as \"blocks\".\n\n- **The 1st block** is the handshake method. Currently, there is only `mlkem768x25519plus`. Requires consistency between server and client.\n- **The 2nd block** is the encryption method. Options are `native`/`xorpub`/`random`, corresponding to: raw format packet / raw format + obfuscated public key part / fully random numbers (similar to VMESS/Shadowsocks). Requires consistency between server and client.\n- **The 3rd block** is session resumption. Choosing `0rtt` will follow the server settings to attempt to use previously generated tickets to skip the handshake for fast connection (can be manually disabled by the server). Choosing `1rtt` will force a 1-RTT handshake process. The meaning here differs from the server setting; see VLESS Inbound `decryption` settings for details.\n\nFollowing blocks are **padding**. After the connection is established, the client sends some garbage data to obfuscate length characteristics. It does not need to be the same as the server (the corresponding part in the inbound is the padding sent from the server to the client). It is a variable-length part with the format `padding.delay.padding` + `(.delay.padding)` x n (multiple padding blocks can be inserted, requiring a delay block between two padding blocks).\n\n- `padding` format is `probability-min-max`. E.g., `100-111-1111` means 100% probability to send a padding of length 111~1111.\n- `delay` format is also `probability-min-max`. E.g., `75-0-111` means 75% probability to wait 0~111 milliseconds.\n\nThe first padding block has special requirements: probability must be 100% and minimum length greater than 0. If no padding exists, the core automatically uses `100-111-1111.75-0-111.50-0-3333` as the padding setting.\n\n**The last block** will be recognized by the core as the parameter used to authenticate the server. It can be generated by `./xray x25519` (using the Password part) or `./xray mlkem768` (using the Client part). It must correspond to the server. `mlkem768` belongs to post-quantum algorithms, preventing (future) client parameter leaks from allowing quantum computers to crack the private key and impersonate the server. This parameter is only used for verification; the handshake process is post-quantum secure regardless, and existing encrypted data cannot be decrypted by future quantum computers.\n";
+//#endregion
+//#region src/outbounds/vless/vlessFlow.md?raw
+var vlessFlow_default = "Flow control mode, used to select the XTLS algorithm.\n\nCurrently, the following flow control modes are available in the outbound protocol:\n\n- **No `flow` or empty string**: Use standard TLS proxy.\n- **`xtls-rprx-vision`**: Use XTLS, including inner handshake random padding. Will intercept UDP traffic targeting port 443 (QUIC) to force browsers to use standard HTTPS, increasing traffic that can be Spliced.\n- **`xtls-rprx-vision-udp443`**: Same as `xtls-rprx-vision`, but does not intercept UDP 443. Used when a program forces the use of QUIC and would fail to work if intercepted.\n\nXTLS is available only in the following combinations:\n\n- **TCP+TLS/REALITY**: In this case, if transmitting TLS 1.3, the core will attempt to Splice encrypted data at the bottom layer. If successful, it saves all core IO overhead.\n- **VLESS Encryption**: No underlying transport restrictions. If the underlying transport is not TCP, it only attempts to penetrate Encryption, saving Encryption overhead. If it is TCP, it will still attempt to perform Splice.\n\n### TIP\n\nSplice is a function provided by the Linux Kernel. The system kernel forwards TCP directly, no longer passing through Xray's memory, greatly reducing data copying and CPU context switching.\n\nWhen using Vision mode, Splice is automatically enabled if the following conditions are met:\n\n- Linux environment.\n- Inbound protocol is a pure TCP connection like `Dokodemo door`, `Socks`, `HTTP`, or other inbound protocols using XTLS.\n- Outbound protocol is VLESS + XTLS.\n\nWhen using Splice, the network speed display will lag and will only be counted after the connection is disconnected because the core cannot know the traffic situation while the kernel takes over the connection.\n";
+//#endregion
+//#region src/outbounds/vless/vlessLevel.md?raw
+var vlessLevel_default = "User level. The connection will use the [Local Policy](https://xtls.github.io/en/config/policy.html#levelpolicyobject) corresponding to this user level.\n\nThe value of `level` corresponds to the value of `level` in [policy](https://xtls.github.io/en/config/policy.html#policyobject). If not specified, it defaults to 0.\n";
+//#endregion
 //#region src/outbounds/vless/vless.ts
-const vless = outboundSchemaBase.extend({
-	protocol: z.literal("vless"),
-	settings: z.object({
-		address: z.string().meta({ markdownDescription: "Server address, points to the server. Supports domain names, IPv4, and IPv6.\n" }),
-		port: portLikeSchema.meta({ markdownDescription: "Server port, usually the same as the port the server is listening on.\n" }),
-		id: z.string().meta({ markdownDescription: "User ID for VLESS. It can be any string less than 30 bytes, or a valid UUID. A custom string and its mapped UUID are equivalent.\n\nThe mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to UUIDv5](https://github.com/XTLS/Xray-core/issues/158).\n\nYou can use the command `xray uuid -i \"custom string\"` to generate the UUID mapped from a custom string, or use the command `xray uuid` to generate a random UUID.\n" }),
-		encryption: z.string().default("none").meta({ markdownDescription: "[VLESS Encryption](https://github.com/XTLS/Xray-core/pull/5067) settings. Cannot be left empty; to disable, explicitly set to `\"none\"`.\n\nIt is recommended for most users to use the `xray vlessenc` command to automatically generate this field to avoid configuration mistakes. The detailed configuration below is recommended only for advanced users.\n\nIts format is a detailed configuration string of fields connected by `.`. For example: `mlkem768x25519plus.native.0rtt.100-111-1111.75-0-111.50-0-3333.ptjHQxBQxTJ9MWr2cd5qWIflBSACHOevTauCQwa_71U`. This document will refer to the separate parts separated by dots as \"blocks\".\n\n- **The 1st block** is the handshake method. Currently, there is only `mlkem768x25519plus`. Requires consistency between server and client.\n- **The 2nd block** is the encryption method. Options are `native`/`xorpub`/`random`, corresponding to: raw format packet / raw format + obfuscated public key part / fully random numbers (similar to VMESS/Shadowsocks). Requires consistency between server and client.\n- **The 3rd block** is session resumption. Choosing `0rtt` will follow the server settings to attempt to use previously generated tickets to skip the handshake for fast connection (can be manually disabled by the server). Choosing `1rtt` will force a 1-RTT handshake process. The meaning here differs from the server setting; see VLESS Inbound `decryption` settings for details.\n\nFollowing blocks are **padding**. After the connection is established, the client sends some garbage data to obfuscate length characteristics. It does not need to be the same as the server (the corresponding part in the inbound is the padding sent from the server to the client). It is a variable-length part with the format `padding.delay.padding` + `(.delay.padding)` x n (multiple padding blocks can be inserted, requiring a delay block between two padding blocks).\n\n- `padding` format is `probability-min-max`. E.g., `100-111-1111` means 100% probability to send a padding of length 111~1111.\n- `delay` format is also `probability-min-max`. E.g., `75-0-111` means 75% probability to wait 0~111 milliseconds.\n\nThe first padding block has special requirements: probability must be 100% and minimum length greater than 0. If no padding exists, the core automatically uses `100-111-1111.75-0-111.50-0-3333` as the padding setting.\n\n**The last block** will be recognized by the core as the parameter used to authenticate the server. It can be generated by `./xray x25519` (using the Password part) or `./xray mlkem768` (using the Client part). It must correspond to the server. `mlkem768` belongs to post-quantum algorithms, preventing (future) client parameter leaks from allowing quantum computers to crack the private key and impersonate the server. This parameter is only used for verification; the handshake process is post-quantum secure regardless, and existing encrypted data cannot be decrypted by future quantum computers.\n" }),
+const vlessSettings = z.object({
+	address: z.string().meta({ markdownDescription: vlessAddress_default }),
+	port: portLikeSchema.meta({ markdownDescription: vlessPort_default }),
+	id: z.string().meta({ markdownDescription: vlessId_default }),
+	encryption: z.string().default("none").meta({ markdownDescription: vlessEncryption_default }),
+	flow: z.enum([
+		"",
+		"xtls-rprx-vision",
+		"xtls-rprx-vision-udp443"
+	]).optional().meta({ markdownDescription: vlessFlow_default }),
+	level: z.int().default(0).optional().meta({ markdownDescription: vlessLevel_default }),
+	reverse: z.object({
+		tag: z.string().meta({ markdownDescription: "The inbound proxy tag for this reverse proxy. When the server dispatches a reverse proxy request, it enters the routing system from the inbound using this tag, and the routing system routes it to the outbound you need.\n" }),
+		sniffing: sniffingSchema.optional()
+	}).optional().meta({ markdownDescription: "VLESS minimalist reverse proxy configuration. It preserves the real source IP information from the public-facing side.\n\nThe existence of this item indicates that this outbound can be used as a VLESS reverse proxy outbound, and it will automatically establish a connection to the server to register the reverse proxy tunnel.\n\n`tag` is the inbound proxy tag for this reverse proxy. When the server dispatches a reverse proxy request, it enters the routing system from the inbound using this tag, and the routing system routes it to the outbound you need.\n\nThe UUID used must be one that is also configured with `reverse` on the server side (see VLESS Inbound for details).\n\n`sniffing` see [SniffingObject](https://xtls.github.io/en/config/inbound.html#sniffingobject), performs sniffing on requests entering through this reverse proxy.\n\n### TIP\n\nFull tutorial: [VLESS Reverse Proxy Examples](https://xtls.github.io/en/document/level-2/vless_reverse.html)\n" })
+}).meta({ markdownDescription: vlessSettings_default });
+const vnext = z.object({ vnext: z.array(z.object({
+	address: z.string().meta({ markdownDescription: vlessAddress_default }),
+	port: portLikeSchema.meta({ markdownDescription: vlessPort_default }),
+	users: z.array(z.object({
+		id: z.string().meta({ markdownDescription: vlessId_default }),
+		encryption: z.string().default("none").meta({ markdownDescription: vlessEncryption_default }),
 		flow: z.enum([
 			"",
 			"xtls-rprx-vision",
 			"xtls-rprx-vision-udp443"
-		]).optional().meta({ markdownDescription: "Flow control mode, used to select the XTLS algorithm.\n\nCurrently, the following flow control modes are available in the outbound protocol:\n\n- **No `flow` or empty string**: Use standard TLS proxy.\n- **`xtls-rprx-vision`**: Use XTLS, including inner handshake random padding. Will intercept UDP traffic targeting port 443 (QUIC) to force browsers to use standard HTTPS, increasing traffic that can be Spliced.\n- **`xtls-rprx-vision-udp443`**: Same as `xtls-rprx-vision`, but does not intercept UDP 443. Used when a program forces the use of QUIC and would fail to work if intercepted.\n\nXTLS is available only in the following combinations:\n\n- **TCP+TLS/REALITY**: In this case, if transmitting TLS 1.3, the core will attempt to Splice encrypted data at the bottom layer. If successful, it saves all core IO overhead.\n- **VLESS Encryption**: No underlying transport restrictions. If the underlying transport is not TCP, it only attempts to penetrate Encryption, saving Encryption overhead. If it is TCP, it will still attempt to perform Splice.\n\n### TIP\n\nSplice is a function provided by the Linux Kernel. The system kernel forwards TCP directly, no longer passing through Xray's memory, greatly reducing data copying and CPU context switching.\n\nWhen using Vision mode, Splice is automatically enabled if the following conditions are met:\n\n- Linux environment.\n- Inbound protocol is a pure TCP connection like `Dokodemo door`, `Socks`, `HTTP`, or other inbound protocols using XTLS.\n- Outbound protocol is VLESS + XTLS.\n\nWhen using Splice, the network speed display will lag and will only be counted after the connection is disconnected because the core cannot know the traffic situation while the kernel takes over the connection.\n" }),
-		level: z.int().default(0).optional().meta({ markdownDescription: "User level. The connection will use the [Local Policy](https://xtls.github.io/en/config/policy.html#levelpolicyobject) corresponding to this user level.\n\nThe value of `level` corresponds to the value of `level` in [policy](https://xtls.github.io/en/config/policy.html#policyobject). If not specified, it defaults to 0.\n" }),
-		reverse: z.object({
-			tag: z.string().meta({ markdownDescription: "The inbound proxy tag for this reverse proxy. When the server dispatches a reverse proxy request, it enters the routing system from the inbound using this tag, and the routing system routes it to the outbound you need.\n" }),
-			sniffing: sniffingSchema.optional()
-		}).optional().meta({ markdownDescription: "VLESS minimalist reverse proxy configuration. It preserves the real source IP information from the public-facing side.\n\nThe existence of this item indicates that this outbound can be used as a VLESS reverse proxy outbound, and it will automatically establish a connection to the server to register the reverse proxy tunnel.\n\n`tag` is the inbound proxy tag for this reverse proxy. When the server dispatches a reverse proxy request, it enters the routing system from the inbound using this tag, and the routing system routes it to the outbound you need.\n\nThe UUID used must be one that is also configured with `reverse` on the server side (see VLESS Inbound for details).\n\n`sniffing` see [SniffingObject](https://xtls.github.io/en/config/inbound.html#sniffingobject), performs sniffing on requests entering through this reverse proxy.\n\n### TIP\n\nFull tutorial: [VLESS Reverse Proxy Examples](https://xtls.github.io/en/document/level-2/vless_reverse.html)\n" })
-	}).meta({ markdownDescription: "`OutboundConfigurationObject` corresponds to the `settings` item in [`OutboundObject`](https://xtls.github.io/en/config/outbound.html).\n" })
-}).meta({ markdownDescription: "VLESS is a stateless lightweight transport protocol. It consists of inbound and outbound parts and can serve as a bridge between the Xray client and server.\n\nUnlike [VMess](https://xtls.github.io/en/config/outbounds/vmess.html), VLESS does not depend on system time. The authentication method is also UUID.\n\n[Documentation ↗](https://xtls.github.io/en/config/outbounds/vless.html)\n" });
+		]).optional().meta({ markdownDescription: vlessFlow_default }),
+		level: z.int().default(0).optional().meta({ markdownDescription: vlessLevel_default })
+	}))
+})) });
+const vless = outboundSchemaBase.extend({
+	protocol: z.literal("vless"),
+	settings: vlessSettings.or(vnext).meta({ markdownDescription: vlessSettings_default })
+}).meta({ markdownDescription: vless_default });
 //#endregion
 //#region src/outbounds/vmess/vmess.ts
 const vmess = outboundSchemaBase.extend({