@gozargah/xray-schema 0.0.4 → 0.0.5

package/dist/full/schema.json

@@ -1056,7 +1056,7 @@
               ]
             },
             "then": {
-              "$ref": "#/definitions/__schema810"
+              "$ref": "#/definitions/__schema815"
             }
           },
           {
@@ -1071,7 +1071,7 @@
               ]
             },
             "then": {
-              "$ref": "#/definitions/__schema822"
+              "$ref": "#/definitions/__schema827"
             }
           }
         ]
@@ -10837,28 +10837,39 @@
       "const": "vless"
     },
     "__schema798": {
+      "anyOf": [
+        {
+          "$ref": "#/definitions/__schema799"
+        },
+        {
+          "$ref": "#/definitions/__schema811"
+        }
+      ],
+      "markdownDescription": "`OutboundConfigurationObject` corresponds to the `settings` item in [`OutboundObject`](https://xtls.github.io/en/config/outbound.html).\n"
+    },
+    "__schema799": {
       "type": "object",
       "properties": {
         "address": {
-          "$ref": "#/definitions/__schema799"
+          "$ref": "#/definitions/__schema800"
         },
         "port": {
-          "$ref": "#/definitions/__schema800"
+          "$ref": "#/definitions/__schema801"
         },
         "id": {
-          "$ref": "#/definitions/__schema801"
+          "$ref": "#/definitions/__schema802"
         },
         "encryption": {
-          "$ref": "#/definitions/__schema802"
+          "$ref": "#/definitions/__schema803"
         },
         "flow": {
-          "$ref": "#/definitions/__schema804"
+          "$ref": "#/definitions/__schema805"
         },
         "level": {
-          "$ref": "#/definitions/__schema806"
+          "$ref": "#/definitions/__schema807"
         },
         "reverse": {
-          "$ref": "#/definitions/__schema808"
+          "$ref": "#/definitions/__schema809"
         }
       },
       "required": [
@@ -10870,11 +10881,11 @@
       "additionalProperties": false,
       "markdownDescription": "`OutboundConfigurationObject` corresponds to the `settings` item in [`OutboundObject`](https://xtls.github.io/en/config/outbound.html).\n"
     },
-    "__schema799": {
+    "__schema800": {
       "type": "string",
       "markdownDescription": "Server address, points to the server. Supports domain names, IPv4, and IPv6.\n"
     },
-    "__schema800": {
+    "__schema801": {
       "markdownDescription": "Server port, usually the same as the port the server is listening on.\n",
       "allOf": [
         {
@@ -10882,31 +10893,31 @@
         }
       ]
     },
-    "__schema801": {
+    "__schema802": {
       "type": "string",
       "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"
     },
-    "__schema802": {
+    "__schema803": {
       "default": "none",
       "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",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema803"
+          "$ref": "#/definitions/__schema804"
         }
       ]
     },
-    "__schema803": {
+    "__schema804": {
       "type": "string"
     },
-    "__schema804": {
+    "__schema805": {
       "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",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema805"
+          "$ref": "#/definitions/__schema806"
         }
       ]
     },
-    "__schema805": {
+    "__schema806": {
       "type": "string",
       "enum": [
         "",
@@ -10914,29 +10925,29 @@
         "xtls-rprx-vision-udp443"
       ]
     },
-    "__schema806": {
+    "__schema807": {
       "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",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema807"
+          "$ref": "#/definitions/__schema808"
         }
       ]
     },
-    "__schema807": {
+    "__schema808": {
       "default": 0,
       "type": "integer",
       "minimum": -9007199254740991,
       "maximum": 9007199254740991
     },
-    "__schema808": {
+    "__schema809": {
       "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",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema809"
+          "$ref": "#/definitions/__schema810"
         }
       ]
     },
-    "__schema809": {
+    "__schema810": {
       "type": "object",
       "properties": {
         "tag": {
@@ -10956,7 +10967,101 @@
       ],
       "additionalProperties": false
     },
-    "__schema810": {
+    "__schema811": {
+      "type": "object",
+      "properties": {
+        "vnext": {
+          "type": "array",
+          "items": {
+            "type": "object",
+            "properties": {
+              "address": {
+                "type": "string",
+                "markdownDescription": "Server address, points to the server. Supports domain names, IPv4, and IPv6.\n"
+              },
+              "port": {
+                "markdownDescription": "Server port, usually the same as the port the server is listening on.\n",
+                "allOf": [
+                  {
+                    "$ref": "#/definitions/__schema148"
+                  }
+                ]
+              },
+              "users": {
+                "type": "array",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "id": {
+                      "type": "string",
+                      "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": {
+                      "default": "none",
+                      "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",
+                      "allOf": [
+                        {
+                          "$ref": "#/definitions/__schema812"
+                        }
+                      ]
+                    },
+                    "flow": {
+                      "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",
+                      "allOf": [
+                        {
+                          "$ref": "#/definitions/__schema813"
+                        }
+                      ]
+                    },
+                    "level": {
+                      "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",
+                      "allOf": [
+                        {
+                          "$ref": "#/definitions/__schema814"
+                        }
+                      ]
+                    }
+                  },
+                  "required": [
+                    "id",
+                    "encryption"
+                  ],
+                  "additionalProperties": false
+                }
+              }
+            },
+            "required": [
+              "address",
+              "port",
+              "users"
+            ],
+            "additionalProperties": false
+          }
+        }
+      },
+      "required": [
+        "vnext"
+      ],
+      "additionalProperties": false
+    },
+    "__schema812": {
+      "type": "string"
+    },
+    "__schema813": {
+      "type": "string",
+      "enum": [
+        "",
+        "xtls-rprx-vision",
+        "xtls-rprx-vision-udp443"
+      ]
+    },
+    "__schema814": {
+      "default": 0,
+      "type": "integer",
+      "minimum": -9007199254740991,
+      "maximum": 9007199254740991
+    },
+    "__schema815": {
       "type": "object",
       "properties": {
         "sendThrough": {
@@ -10978,10 +11083,10 @@
           "$ref": "#/definitions/__schema705"
         },
         "protocol": {
-          "$ref": "#/definitions/__schema811"
+          "$ref": "#/definitions/__schema816"
         },
         "settings": {
-          "$ref": "#/definitions/__schema812"
+          "$ref": "#/definitions/__schema817"
         }
       },
       "required": [
@@ -10991,30 +11096,30 @@
       "additionalProperties": false,
       "markdownDescription": "[VMess](https://xtls.github.io/en/development/protocols/vmess.html) is an encrypted transport protocol, usually serving as a bridge between the Xray client and server.\n\n### DANGER\n\nVMess depends on system time. Please ensure that the UTC time of the system running Xray is within 120 seconds of the actual time, independent of the time zone. On Linux systems, you can install the `ntp` service to automatically synchronize the system time.\n\n[Documentation ↗](https://xtls.github.io/en/config/outbounds/vmess.html)\n"
     },
-    "__schema811": {
+    "__schema816": {
       "type": "string",
       "const": "vmess"
     },
-    "__schema812": {
+    "__schema817": {
       "type": "object",
       "properties": {
         "address": {
-          "$ref": "#/definitions/__schema813"
+          "$ref": "#/definitions/__schema818"
         },
         "port": {
-          "$ref": "#/definitions/__schema814"
+          "$ref": "#/definitions/__schema819"
         },
         "id": {
-          "$ref": "#/definitions/__schema815"
+          "$ref": "#/definitions/__schema820"
         },
         "security": {
-          "$ref": "#/definitions/__schema816"
+          "$ref": "#/definitions/__schema821"
         },
         "level": {
-          "$ref": "#/definitions/__schema818"
+          "$ref": "#/definitions/__schema823"
         },
         "experiments": {
-          "$ref": "#/definitions/__schema820"
+          "$ref": "#/definitions/__schema825"
         }
       },
       "required": [
@@ -11025,11 +11130,11 @@
       "additionalProperties": false,
       "markdownDescription": "`OutboundConfigurationObject` corresponds to the `settings` item in [`OutboundObject`](https://xtls.github.io/en/config/outbound.html).\n"
     },
-    "__schema813": {
+    "__schema818": {
       "type": "string",
       "markdownDescription": "Server address, supports IP address or domain name.\n"
     },
-    "__schema814": {
+    "__schema819": {
       "markdownDescription": "The port number the server is listening on. Required.\n",
       "allOf": [
         {
@@ -11037,19 +11142,19 @@
         }
       ]
     },
-    "__schema815": {
+    "__schema820": {
       "type": "string",
       "markdownDescription": "VMess User ID. It can be any string less than 30 bytes or a valid UUID.\n\nA custom string and its mapped UUID are equivalent. This means you can identify the same user in the configuration file like this:\n\n- Write `\"id\": \"我爱🍉老师1314\"`,\n- Or write `\"id\": \"5783a3e7-e373-51cd-8642-c83782b807c5\"` (This UUID is the UUID mapping of `我爱🍉老师1314`)\n\nThe mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to a 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 the custom string. You can also use the command `xray uuid` to generate a random UUID.\n"
     },
-    "__schema816": {
+    "__schema821": {
       "markdownDescription": "Encryption method. The client will use the configured encryption method to send data, and the server will automatically identify it without configuration.\n\n- `\"aes-128-gcm\"`: Use AES-128-GCM algorithm.\n- `\"chacha20-poly1305\"`: Use Chacha20-Poly1305 algorithm.\n- `\"auto\"`: Default value. Automatically selected (uses aes-128-gcm encryption when the running framework is AMD64, ARM64, or s390x; uses Chacha20-Poly1305 encryption in other cases).\n- `\"none\"`: No encryption, maintains the VMess message structure.\n- `\"zero\"`: No encryption, direct stream copy (similar to VLESS).\n\nIt is not recommended to use `\"none\"` or `\"zero\"` pseudo-encryption methods without enabling TLS encryption and enforcing certificate verification. Regardless of the encryption method used, the VMess packet header is protected by encryption and authentication.\n\nNote: `\"auto\"` only determines the AES hardware acceleration support status of the _client_. If the _server_ does not support AES hardware acceleration, you still need to manually set it to `chacha20-poly1305`. This is very important because Chacha20-Poly1305 takes about 48% more time than AES-128-GCM on platforms supporting AES acceleration, but on platforms _without_ AES acceleration, AES-128-GCM takes over 2000% more time than Chacha20-Poly1305.\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema817"
+          "$ref": "#/definitions/__schema822"
         }
       ]
     },
-    "__schema817": {
+    "__schema822": {
       "type": "string",
       "enum": [
         "aes-128-gcm",
@@ -11059,29 +11164,29 @@
         "zero"
       ]
     },
-    "__schema818": {
+    "__schema823": {
       "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, the default is 0.\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema819"
+          "$ref": "#/definitions/__schema824"
         }
       ]
     },
-    "__schema819": {
+    "__schema824": {
       "default": 0,
       "type": "integer",
       "minimum": -9007199254740991,
       "maximum": 9007199254740991
     },
-    "__schema820": {
+    "__schema825": {
       "markdownDescription": "Enabled VMess protocol experimental features. (Features here are unstable and may be removed at any time). Multiple enabled experiments can be separated by the `|` character, such as `\"AuthenticatedLength|NoTerminationSignal\"`.\n\n- `\"AuthenticatedLength\"`: Enable authenticated packet length experiment. This experiment requires both the client and server to enable it simultaneously and run the same version of the program.\n- `\"NoTerminationSignal\"`: Enable not sending the disconnection signal. This feature is now enabled by default.\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema821"
+          "$ref": "#/definitions/__schema826"
         }
       ]
     },
-    "__schema821": {
+    "__schema826": {
       "type": "string",
       "enum": [
         "AuthenticatedLength",
@@ -11089,7 +11194,7 @@
         "AuthenticatedLength|NoTerminationSignal"
       ]
     },
-    "__schema822": {
+    "__schema827": {
       "type": "object",
       "properties": {
         "sendThrough": {
@@ -11111,10 +11216,10 @@
           "$ref": "#/definitions/__schema705"
         },
         "protocol": {
-          "$ref": "#/definitions/__schema823"
+          "$ref": "#/definitions/__schema828"
         },
         "settings": {
-          "$ref": "#/definitions/__schema824"
+          "$ref": "#/definitions/__schema829"
         }
       },
       "required": [
@@ -11124,36 +11229,36 @@
       "additionalProperties": false,
       "markdownDescription": "Standard Wireguard protocol implementation.\n\n### DANGER\n\n**The Wireguard protocol is not designed specifically for bypassing firewalls. If used at the outermost layer to cross the Great Firewall, distinctive characteristics may lead to the server being blocked.**\n\n### TIP\n\nCurrently, configuring `streamSettings` is not supported in the Wireguard protocol outbound.\n\n[Documentation ↗](https://xtls.github.io/en/config/outbounds/wireguard.html)\n"
     },
-    "__schema823": {
+    "__schema828": {
       "type": "string",
       "const": "wireguard"
     },
-    "__schema824": {
+    "__schema829": {
       "type": "object",
       "properties": {
         "secretKey": {
-          "$ref": "#/definitions/__schema825"
+          "$ref": "#/definitions/__schema830"
         },
         "address": {
-          "$ref": "#/definitions/__schema826"
+          "$ref": "#/definitions/__schema831"
         },
         "peers": {
-          "$ref": "#/definitions/__schema828"
+          "$ref": "#/definitions/__schema833"
         },
         "noKernelTun": {
-          "$ref": "#/definitions/__schema833"
+          "$ref": "#/definitions/__schema838"
         },
         "mtu": {
-          "$ref": "#/definitions/__schema835"
+          "$ref": "#/definitions/__schema840"
         },
         "reserved": {
-          "$ref": "#/definitions/__schema837"
+          "$ref": "#/definitions/__schema842"
         },
         "workers": {
-          "$ref": "#/definitions/__schema839"
+          "$ref": "#/definitions/__schema844"
         },
         "domainStrategy": {
-          "$ref": "#/definitions/__schema841"
+          "$ref": "#/definitions/__schema846"
         }
       },
       "required": [
@@ -11165,30 +11270,30 @@
       "additionalProperties": false,
       "markdownDescription": "`OutboundConfigurationObject` corresponds to the `settings` item in [`OutboundObject`](https://xtls.github.io/en/config/outbound.html).\n"
     },
-    "__schema825": {
+    "__schema830": {
       "type": "string",
       "markdownDescription": "User private key. Required.\n"
     },
-    "__schema826": {
+    "__schema831": {
       "minItems": 1,
       "type": "array",
       "items": {
-        "$ref": "#/definitions/__schema827"
+        "$ref": "#/definitions/__schema832"
       },
       "markdownDescription": "Wireguard will start a virtual network interface (tun) locally. Use one or more IP addresses; IPv6 is supported.\n"
     },
-    "__schema827": {
+    "__schema832": {
       "type": "string"
     },
-    "__schema828": {
+    "__schema833": {
       "minItems": 1,
       "type": "array",
       "items": {
-        "$ref": "#/definitions/__schema829"
+        "$ref": "#/definitions/__schema834"
       },
       "markdownDescription": "List of Wireguard servers, where each item is a server configuration.\n"
     },
-    "__schema829": {
+    "__schema834": {
       "type": "object",
       "properties": {
         "endpoint": {
@@ -11203,7 +11308,7 @@
           "markdownDescription": "Additional symmetric encryption key.\n",
           "allOf": [
             {
-              "$ref": "#/definitions/__schema830"
+              "$ref": "#/definitions/__schema835"
             }
           ]
         },
@@ -11211,7 +11316,7 @@
           "markdownDescription": "Heartbeat interval in seconds. Default is 0, meaning no heartbeat.\n",
           "allOf": [
             {
-              "$ref": "#/definitions/__schema831"
+              "$ref": "#/definitions/__schema836"
             }
           ]
         },
@@ -11219,7 +11324,7 @@
           "markdownDescription": "Wireguard only allows traffic from specific source IPs.\n",
           "allOf": [
             {
-              "$ref": "#/definitions/__schema832"
+              "$ref": "#/definitions/__schema837"
             }
           ]
         }
@@ -11230,16 +11335,16 @@
       ],
       "additionalProperties": false
     },
-    "__schema830": {
+    "__schema835": {
       "type": "string"
     },
-    "__schema831": {
+    "__schema836": {
       "default": 0,
       "type": "integer",
       "minimum": -9007199254740991,
       "maximum": 9007199254740991
     },
-    "__schema832": {
+    "__schema837": {
       "default": [
         "0.0.0.0/0",
         "::/0"
@@ -11249,41 +11354,41 @@
         "type": "string"
       }
     },
-    "__schema833": {
+    "__schema838": {
       "markdownDescription": "By default, the core detects if it is running on Linux and if the current user has `CAP_NET_ADMIN` permissions to decide whether to enable the system virtual network interface; otherwise, it uses gVisor. Using the system virtual interface offers relatively higher performance. Note that this is only for processing IP packets and has nothing to do with the wireguard kernel module.\n\nThis detection may not always be accurate. For example, some LXC virtualization environments may not have TUN permissions at all, causing the outbound to fail. Therefore, you can set this option to manually disable it.\n\nWhen using the system virtual interface, it occupies IPv6 routing table number `10230`. Each additional Wireguard outbound will use subsequent routing tables sequentially; for example, the second one will use routing table `10231`, and so on.\n\nNote that if a second Xray instance is started on the same machine, it will not assign the next routing table number but will continue trying to use routing table `10230`. Since it is already occupied by the first Xray instance, it will fail to connect. If absolutely needed, you must set this option to disable the system virtual interface.\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema834"
+          "$ref": "#/definitions/__schema839"
         }
       ]
     },
-    "__schema834": {
+    "__schema839": {
       "default": false,
       "type": "boolean"
     },
-    "__schema835": {
+    "__schema840": {
       "default": 1420,
       "markdownDescription": "MTU size of the underlying Wireguard tun.\n\nThe structure of a Wireguard packet is as follows:\n\n- 20-byte IPv4 header or 40 byte IPv6 header\n- 8-byte UDP header\n- 4-byte type\n- 4-byte key index\n- 8-byte nonce\n- N-byte encrypted data\n- 16-byte authentication tag\n\n`N-byte encrypted data` is the MTU value we need. Depending on whether the endpoint is IPv4 or IPv6, the specific value can be 1440 (IPv4) or 1420 (IPv6). If in a special environment, subtract further (e.g., home broadband PPPoE requires an extra -8).\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema836"
+          "$ref": "#/definitions/__schema841"
         }
       ]
     },
-    "__schema836": {
+    "__schema841": {
       "type": "integer",
       "minimum": -9007199254740991,
       "maximum": 9007199254740991
     },
-    "__schema837": {
+    "__schema842": {
       "markdownDescription": "Wireguard reserved bytes, fill as needed.\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema838"
+          "$ref": "#/definitions/__schema843"
         }
       ]
     },
-    "__schema838": {
+    "__schema843": {
       "default": [],
       "type": "array",
       "items": {
@@ -11292,28 +11397,28 @@
         "maximum": 9007199254740991
       }
     },
-    "__schema839": {
+    "__schema844": {
       "markdownDescription": "Number of threads used by Wireguard. Defaults to the number of system cores.\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema840"
+          "$ref": "#/definitions/__schema845"
         }
       ]
     },
-    "__schema840": {
+    "__schema845": {
       "type": "integer",
       "minimum": -9007199254740991,
       "maximum": 9007199254740991
     },
-    "__schema841": {
+    "__schema846": {
       "markdownDescription": "Controls the domain resolution strategy when the Wireguard server address is a domain name or the target address of the proxied traffic is a domain name.\n\nUnlike most proxy protocols, Wireguard does not allow passing domain names as targets. Therefore, if the incoming target is a domain, it needs to be resolved to an IP address before transmission. This is handled by Xray's built-in DNS. The meaning of this field is the same as `domainStrategy` in `Freedom` outbound. The default value is `ForceIP`.\n\nThe `domainStrategy` of `Freedom` outbound includes options like `UseIP`, which are not provided here because Wireguard must obtain a usable IP and cannot perform the behavior of falling back to a domain name after `UseIP` resolution fails.\n\nNote: When applied to proxied traffic, this option is also constrained by the `address` option. For example, if you set `ForceIPv6v4` but no IPv6 address is set in `address`, even if the target domain has AAAA records, they will not be resolved/used.\n",
       "allOf": [
         {
-          "$ref": "#/definitions/__schema842"
+          "$ref": "#/definitions/__schema847"
         }
       ]
     },
-    "__schema842": {
+    "__schema847": {
       "default": "ForceIP",
       "type": "string",
       "enum": [