mcp-xray-pilot 0.10.0

package/data/docs/inbounds__inbounds_shadowsocks.md

@@ -0,0 +1,118 @@
+---
+url: https://xtls.github.io/en/config/inbounds/shadowsocks.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/shadowsocks.md
+title: Shadowsocks
+category: inbounds
+slug: inbounds/shadowsocks
+fetched_at: 2026-05-04T18:42:50.217Z
+---
+# Shadowsocks
+
+The [Shadowsocks](https://zh.wikipedia.org/wiki/Shadowsocks) protocol, compatible with most other version implementations.
+
+Current compatibility is as follows:
+
+- Supports TCP and UDP packet forwarding, where UDP can be optionally disabled;
+- Recommended encryption methods:
+  - 2022-blake3-aes-128-gcm
+  - 2022-blake3-aes-256-gcm
+  - 2022-blake3-chacha20-poly1305
+- Other encryption methods:
+  - aes-256-gcm
+  - aes-128-gcm
+  - chacha20-poly1305 (or chacha20-ietf-poly1305)
+  - xchacha20-poly1305 (or xchacha20-ietf-poly1305)
+  - none (or plain)
+
+The Shadowsocks 2022 new protocol format improves performance and includes complete replay protection, resolving the following security issues of the old protocol:
+
+- [Severe vulnerabilities in the design of Shadowsocks AEAD encryption, unable to guarantee communication reliability](https://github.com/shadowsocks/shadowsocks-org/issues/183)
+- The false positive rate of the original TCP replay filter increases over time
+- No UDP replay protection
+- TCP behavior that can be used for active probing
+
+::: danger
+Under the "none" encryption method, traffic will be transmitted in plain text. To ensure security, do not use it on public networks.
+:::
+
+## InboundConfigurationObject
+
+```json
+{
+  "settings": {
+    "network": "tcp,udp",
+    "method": "aes-256-gcm",
+    "password": "114514",
+    "level": 0,
+    "email": "love@xray.com",
+    "clients": [
+      {
+        "password": "1919810",
+        "method": "aes-128-gcm"
+      }
+    ]
+  }
+}
+```
+
+> `network`: "tcp" | "udp" | "tcp,udp"
+
+The network type that the server port **listens** on. The default value is `"tcp"`.
+
+Note that this is only for listening; it mainly affects and controls the native UDP transmission of Shadowsocks. Setting it to `"tcp"` does not mean the inbound will reject UDP proxy requests. UDP proxy requests can still be wrapped into TCP packets by Shadowsocks outbound features like UoT or mux.cool and sent to the server, and are not controlled by this option.
+
+> `method`: string
+
+Encryption method. See above for options.
+
+> `password`: string
+
+Required.
+
+- Shadowsocks 2022
+
+Uses a pre-shared key similar to WireGuard as the password.
+
+Use `openssl rand -base64 <length>` to generate a key compatible with shadowsocks-rust. The length depends on the encryption method used.
+
+| Encryption Method             | Key Length |
+| ----------------------------- | ---------: |
+| 2022-blake3-aes-128-gcm       |         16 |
+| 2022-blake3-aes-256-gcm       |         32 |
+| 2022-blake3-chacha20-poly1305 |         32 |
+
+In the Go implementation, 32-byte keys always work.
+
+- Other encryption methods
+
+Any string. There is no limit on password length, but short passwords are more likely to be cracked. It is recommended to use passwords of 16 characters or longer.
+
+> `level`: number
+
+User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
+The value of `level` corresponds to the `level` value in [policy](../policy.md#levelpolicyobject). If not specified, the default is 0.
+
+> `email`: string
+
+User email, used to distinguish traffic from different users (logs, statistics).
+
+## ClientObject
+
+```json
+{
+  "password": "1919810",
+  "method": "aes-256-gcm",
+  "level": 0,
+  "email": "love@xray.com"
+}
+```
+
+When this option exists, it indicates that multi-user mode is enabled.
+
+When the `method` in `InboundConfigurationObject` is not an SS2022 option, you can specify `"method"` for each user here (only non-SS2022 options are supported in `"method"`) along with `"password"` (at the same time, the `"password"` set in `InboundConfigurationObject` will be ignored).
+
+When the `method` in `InboundConfigurationObject` is an SS2022 option, for security reasons, setting `"method"` for individual users is no longer supported. It is unified to the `"method"` specified in `InboundConfigurationObject`.
+
+Note that SS2022 does not ignore the upper-level `"password"` like the old SS did. The correct password format for the client should be `ServerPassword:UserPassword`. For example: `"password": "114514:1919810"`.
+
+The remaining options have the same meaning as in `InboundConfigurationObject`.

package/data/docs/inbounds__inbounds_socks.md

@@ -0,0 +1,87 @@
+---
+url: https://xtls.github.io/en/config/inbounds/socks.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/socks.md
+title: Socks
+category: inbounds
+slug: inbounds/socks
+fetched_at: 2026-05-04T18:42:50.715Z
+---
+# Socks
+
+Standard Socks protocol implementation, compatible with [Socks 4](http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol), [Socks 4a](https://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4A.protocol), Socks 5, and **HTTP**.
+
+::: danger
+**The Socks protocol does not encrypt transmission and is not suitable for transmission over the public internet.**
+:::
+
+A more meaningful usage of `Socks` inbound is to listen within a LAN or on the local machine to provide local services for other programs.
+
+## InboundConfigurationObject
+
+```json
+{
+  "auth": "noauth",
+  "accounts": [
+    {
+      "user": "my-username",
+      "pass": "my-password"
+    }
+  ],
+  "udp": false,
+  "ip": "127.0.0.1",
+  "userLevel": 0
+}
+```
+
+> `auth`: "noauth" | "password"
+
+Authentication method for the Socks protocol. Supports `"noauth"` (anonymous) and `"password"` (user/password).
+
+When using password, HTTP requests sent to this inbound will also require the same account and password.
+
+Default value is `"noauth"`.
+
+> `accounts`: \[ [AccountObject](#accountobject) \]
+
+An array where each element is a user account.
+
+This option is only valid when `auth` is set to `password`.
+
+Default value is empty.
+
+> `udp`: true | false
+
+Whether to enable UDP protocol support.
+
+Default value is `false`.
+
+> `ip`: address
+
+When UDP is enabled, Xray needs to know the IP address of the local machine.
+
+"The IP address of the local machine" means the IP that the client can use to find the server when initiating a UDP connection. By default, it is the local IP address when the server accepts the TCP connection. It should work normally in most cases, but when passing through systems behind NAT, it may cause malfunctions, requiring this parameter to be modified to the correct public IP.
+
+Warning: If your machine has multiple IP addresses, you will be affected by the issue regarding UDP listening on 0.0.0.0 mentioned in [Inbound Listening](../inbound.md#inboundobject).
+
+> `userLevel`: number
+
+User level. Connections will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
+
+The value of `userLevel` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, the default is 0.
+
+### AccountObject
+
+```json
+{
+  "user": "my-username",
+  "pass": "my-password"
+}
+```
+
+> `user`: string
+
+Username, string type. Required.
+
+> `pass`: string
+
+Password, string type. Required.

package/data/docs/inbounds__inbounds_trojan.md

@@ -0,0 +1,78 @@
+---
+url: https://xtls.github.io/en/config/inbounds/trojan.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/trojan.md
+title: Trojan
+category: inbounds
+slug: inbounds/trojan
+fetched_at: 2026-05-04T18:42:51.217Z
+---
+# Trojan
+
+[Trojan](https://trojan-gfw.github.io/trojan/protocol) protocol.
+
+::: danger
+Trojan is designed to work over correctly configured encrypted TLS tunnels.
+:::
+
+## InboundConfigurationObject
+
+```json
+{
+  "clients": [
+    {
+      "password": "password",
+      "email": "love@xray.com",
+      "level": 0
+    }
+  ],
+  "fallbacks": [
+    {
+      "dest": 80
+    }
+  ]
+}
+```
+
+> `clients`: \[ [ClientObject](#clientobject) \]
+
+An array representing a group of users accepted by the server.
+
+Each item is a [ClientObject](#clientobject).
+
+> `fallbacks`: \[ [FallbackObject](../features/fallback.md) \]
+
+An array containing a series of powerful fallback configurations (optional).
+For specific configuration of fallbacks, please click [FallbackObject](../features/fallback.md#fallbackobject).
+
+::: tip
+Xray's Trojan has complete support for fallbacks, and the configuration method is exactly the same as VLESS.
+The conditions for triggering fallback are also similar to VLESS: the length of the first packet < 58, OR the 57th byte is not `\r` (because Trojan has no protocol version), OR authentication fails.
+:::
+
+### ClientObject
+
+```json
+{
+  "password": "password",
+  "email": "love@xray.com",
+  "level": 0
+}
+```
+
+> `password`: string
+
+Required, any string.
+
+> `email`: string
+
+Email address, optional, used to identify the user.
+
+::: danger
+If there are multiple ClientObjects, please note that emails must not be duplicated.
+:::
+
+> `level`: number
+
+User level. Connections will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
+
+The value of `userLevel` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.

package/data/docs/inbounds__inbounds_tun.md

@@ -0,0 +1,47 @@
+---
+url: https://xtls.github.io/en/config/inbounds/tun.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/tun.md
+title: TUN
+category: inbounds
+slug: inbounds/tun
+fetched_at: 2026-05-04T18:42:53.756Z
+---
+# TUN
+
+Creates a TUN interface; traffic sent to this interface will be processed by Xray. Currently, only Windows and Linux are supported.
+
+## InboundConfigurationObject
+
+```json
+{
+  "name": "xray0",
+  "MTU": 1500,
+  "UserLevel": 0
+}
+```
+
+> `name`: string
+
+The name of the created TUN interface. Default is `"xray0"`.
+
+> `MTU`: number
+
+The MTU of the interface. Default is `1500`.
+
+> `userLevel`: number
+
+User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
+
+The value of `userLevel` corresponds to the `level` value in [policy](../policy.md#policyobject). If not specified, the default is 0.
+
+## Usage Tips
+
+Currently, Xray does not automatically modify the system routing table. You need to manually configure routes to direct data to the created TUN interface; otherwise, it remains just an interface.
+
+If you only want to proxy specific process(es), the process name routing in the Xray routing system will be very useful.
+
+::: warning
+Be aware of potential traffic loop issues. After setting routes, requests initiated by Xray might be sent back to Xray, causing a loop!
+Use `interface` in `sockopt` to bind to the actual physical network interface to avoid this problem. `ipconfig` (Windows) or `ip a` (Linux) will help you find the interface name you need.
+Alternatively, use the outbound `sendThrough` setting. It is available directly in `OutboundObject` without the deep nesting level of `sockOpt.interface`. Here you need to use the IP address on the network card, such as 192.168.1.2 (As you can see, its disadvantage is that it cannot automatically support dual-stack; please choose according to the IP actually used for your outbound connection).
+:::

package/data/docs/inbounds__inbounds_tunnel.md

@@ -0,0 +1,86 @@
+---
+url: https://xtls.github.io/en/config/inbounds/tunnel.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/tunnel.md
+title: Tunnel (dokodemo-door)
+category: inbounds
+slug: inbounds/tunnel
+fetched_at: 2026-05-04T18:42:49.225Z
+---
+# Tunnel (dokodemo-door)
+
+Tunnel, formerly known as dokodemo-door (Arbitrary Door), can listen on multiple local ports and send all received data to a specific port on a specified server via an outbound, thereby achieving the effect of port mapping.
+
+## InboundConfigurationObject
+
+```json
+{
+  "address": "8.8.8.8",
+  "port": 53,
+  "portMap": {
+    "5555": "1.1.1.1:7777",
+    "5556": ":8888", // overrides port only
+    "5557": "example.com:" // overrides address only
+  },
+  "network": "tcp",
+  "followRedirect": false,
+  "userLevel": 0
+}
+```
+
+> `address`: address
+
+Forward traffic to this address. It can be an IP address, like `"1.2.3.4"`, or a domain name, like `"xray.com"`. String type, defaults to `"localhost"`.
+
+> `port`: number
+
+Forward traffic to the specified port of the target address. Range \[0, 65535\], numeric type. If omitted or 0, it defaults to the listening port.
+
+> `portMap`: map[string]string
+
+A map mapping local ports to required remote addresses/ports (if the inbound listens on multiple ports). If the local port is not included in this map, it is handled according to the `address`/`port` settings.
+
+> `network`: "tcp" | "udp" | "tcp,udp"
+
+Accepted network protocol types. For example, when specified as `"tcp"`, only TCP traffic will be received. Default value is `"tcp"`.
+
+> `followRedirect`: true | false
+
+When set to `true`, dokodemo-door will recognize data forwarded by iptables and forward it to the corresponding target address.
+
+Please refer to the `tproxy` setting in [Transport Configuration](../transport.md#sockoptobject).
+
+> `userLevel`: number
+
+User level. Connections will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
+
+The value of `userLevel` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.
+
+## Usage
+
+The "Arbitrary Door" has two main uses: one is for transparent proxy (see below), and the other is for mapping a port.
+
+Sometimes some services do not support forward proxies like Socks5, and using Tun or Tproxy is overkill. If these services only communicate with a single IP and port (e.g., iperf, Minecraft server, Wireguard endpoint), you can use dokodemo-door.
+
+For example, the following Config (assuming the default outbound is a valid proxy):
+
+```json
+{
+  "listen": "127.0.0.1",
+  "port": 25565,
+  "protocol": "tunnel",
+  "settings": {
+    "address": "mc.hypixel.net",
+    "port": 25565,
+    "network": "tcp",
+    "followRedirect": false,
+    "userLevel": 0
+  },
+  "tag": "mc"
+}
+```
+
+In this case, the core will listen on 127.0.0.1:25565 and forward it to mc.hypixel.net:25565 (a MC server) via the default outbound. Connecting the Minecraft client to 127.0.0.1:25565 is equivalent to connecting to the Hypixel server via a proxy.
+
+## Transparent Proxy Configuration Example
+
+For this section, please refer to [Transparent Proxy (TProxy) Configuration Tutorial](../../document/level-2/tproxy).

package/data/docs/inbounds__inbounds_vless.md

@@ -0,0 +1,135 @@
+---
+url: https://xtls.github.io/en/config/inbounds/vless.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/vless.md
+title: VLESS (XTLS Vision Seed)
+category: inbounds
+slug: inbounds/vless
+fetched_at: 2026-05-04T18:42:51.696Z
+---
+# VLESS (XTLS Vision Seed)
+
+VLESS is a stateless, lightweight transport protocol. It is divided into inbound and outbound parts and can serve as a bridge between Xray clients and servers.
+
+Unlike [VMess](./vmess.md), VLESS does not depend on system time. The authentication method is also UUID.
+
+## InboundConfigurationObject
+
+```json
+{
+  "clients": [
+    {
+      "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
+      "level": 0,
+      "email": "love@xray.com",
+      "flow": "xtls-rprx-vision",
+      "reverse": {}
+    }
+  ],
+  "decryption": "none",
+  "fallbacks": [
+    {
+      "dest": 80
+    }
+  ]
+}
+```
+
+> `clients`: \[ [ClientObject](#clientobject) \]
+
+An array representing a group of users approved by the server.
+
+Each item is a user [ClientObject](#clientobject).
+
+> `decryption`: "none"
+
+[VLESS Encryption](https://github.com/XTLS/Xray-core/pull/5067) settings. Cannot be left empty; to disable, explicitly set it to `"none"`.
+
+It is recommended for most users to use `./xray vlessenc` to automatically generate this field to ensure no errors in writing. The detailed configuration below is recommended for advanced users only.
+
+Its format is a string of detailed configuration fields connected by `.`. For example: `mlkem768x25519plus.native.600s.100-111-1111.75-0-111.50-0-3333.ptjHQxBQxTJ9MWr2cd5qWIflBSACHOevTauCQwa_71U`. This document refers to the individual parts separated by dots as blocks.
+
+- The 1st block is the handshake method. Currently, there is only `mlkem768x25519plus`. Requires the server and client to match.
+- The 2nd block is the encryption method. Options are `native`/`xorpub`/`random`, corresponding to: raw format packets / raw format + obfuscated public key part / full random numbers (similar to VMess/Shadowsocks). Requires the server and client to match.
+- The 3rd block is the session resumption ticket validity time. Format is `600s` or `100-500s`. The former will pick a random time between that duration and half of that duration (e.g., `600s` = `300-600s`); the latter manually specifies a random range.
+
+Following this is padding. After the connection is established, the server sends some garbage data to obfuscate length characteristics. This does not need to be the same as the client (the same part in the outbound is the padding sent from the client to the server). It is a variable-length part, formatted as `padding.delay.padding`+`(.delay.padding)`\*n (multiple paddings can be inserted, requiring a delay block between two padding blocks). For example, you can write an ultra-long `padding.delay.padding.delay.padding.delay.padding.delay.padding.delay.padding`.
+
+- The `padding` format is `probability-min-max`, e.g., `100-111-1111` means 100% probability of sending a padding with a length of 111~1111.
+- The `delay` format is also `probability-min-max`, e.g., `75-0-111` means 75% probability of waiting for 0~111 milliseconds.
+
+The first padding block has special requirements: it requires 100% probability and a 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.
+
+The last block is identified by the core as the parameter used to authenticate the client. It can be generated using `./xray x25519` (using the PrivateKey part) or `./xray mlkem768` (using the Seed part). It must correspond to the client. `mlkem768` is a post-quantum algorithm that prevents the private key from being cracked by quantum computers (in the future) to impersonate the server if client parameters are leaked. This parameter is only used for verification; the handshake process is post-quantum secure regardless, and existing encrypted data cannot be cracked by future quantum computers.
+
+> `fallbacks`: \[ [FallbackObject](../features/fallback.md) \]
+
+An array containing a series of powerful fallback distribution configurations (optional).
+For specific fallback configurations, please click [FallbackObject](../features/fallback.md#fallbacks-configuration).
+
+### ClientObject
+
+```json
+{
+  "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
+  "level": 0,
+  "email": "love@xray.com",
+  "flow": "xtls-rprx-vision",
+  "reverse" {}
+}
+```
+
+> `id`: string
+
+The 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, which means you can write the id in the configuration file to identify the same user like this:
+
+- Write `"id": "我爱🍉老师1314"`,
+- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the UUID mapping of `我爱🍉老师1314`).
+
+The mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
+
+You 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.
+
+> `level`: number
+
+User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
+
+The value of `level` corresponds to the `level` value in [policy](../policy.md#policyobject). If not specified, the default is 0.
+
+> `email`: string
+
+User email, used to distinguish traffic from different users (reflected in logs and statistics).
+
+> `flow`: string
+
+Flow control mode, used to select the XTLS algorithm.
+
+Currently, the following flow control modes are available in the inbound protocol:
+
+- No `flow` or empty string: Use standard TLS proxy.
+- `xtls-rprx-vision`: Use the new XTLS mode, including inner handshake random padding.
+
+XTLS is only available under the following combinations:
+
+- TCP+TLS/Reality: In this case, encrypted data is directly copied at the underlying layer (if transmitting TLS 1.3).
+- VLESS Encryption: No underlying transport restrictions. If the underlying layer does not support direct copying (see above), it only penetrates Encryption.
+
+> `reverse`: struct
+
+VLESS simplified reverse proxy configuration. It functions the same as the core's internal general reverse proxy but with simpler configuration.
+
+The presence of this item indicates that connections from this user can be used to establish a reverse proxy tunnel.
+
+Current syntax:
+
+```json
+"reverse": {
+  "tag": "r-outbound"
+}
+```
+
+`tag` is the outbound proxy tag for this reverse proxy. Routing traffic to this outbound using routing rules will forward it through the reverse proxy to the connected client's routing system (see VLESS Outbound for client configuration details).
+
+When multiple different connections (potentially from different devices) are connected, the core will randomly select one to dispatch reverse proxy data for each request.

package/data/docs/inbounds__inbounds_vmess.md

@@ -0,0 +1,95 @@
+---
+url: https://xtls.github.io/en/config/inbounds/vmess.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/vmess.md
+title: VMess
+category: inbounds
+slug: inbounds/vmess
+fetched_at: 2026-05-04T18:42:52.214Z
+---
+# VMess
+
+[VMess](../../development/protocols/vmess.md) is an encrypted transport protocol, commonly acting as a bridge between the Xray client and server.
+
+::: danger
+VMess depends on system time. Please ensure that the system UTC time of the device running Xray is within 120 seconds of the actual time, regardless of the time zone. On Linux systems, you can install the `ntp` service to automatically synchronize system time.
+:::
+
+## InboundConfigurationObject
+
+```json
+{
+  "clients": [
+    {
+      "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
+      "level": 0,
+      "email": "love@xray.com"
+    }
+  ],
+  "default": {
+    "level": 0
+  }
+}
+```
+
+> `clients`: \[ [ClientObject](#clientobject) \]
+
+An array representing a group of users accepted by the server.
+
+Each item is a [ClientObject](#clientobject).
+
+When this configuration is used for dynamic ports, Xray will automatically create users.
+
+> `default`: [DefaultObject](#defaultobject)
+
+Optional. Default configuration for clients. Only valid when used in conjunction with `detour`.
+
+### ClientObject
+
+```json
+{
+  "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
+  "level": 0,
+  "email": "love@xray.com"
+}
+```
+
+> `id`: string
+
+User ID for VMess. It can be any string less than 30 bytes, or a valid UUID.
+
+::: tip
+A custom string and its mapped UUID are equivalent. This means you can identify the same user in the configuration file by writing the ID in either way:
+
+- Write `"id": "我爱🍉老师1314"`,
+- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the UUID mapping of `我爱🍉老师1314`)
+  :::
+
+The mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
+
+You can use the command `xray uuid -i "custom string"` to generate the UUID mapped from a custom string.
+
+> You can also use the command `xray uuid` to generate a random UUID.
+
+> `level`: number
+
+User level. The connection will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
+
+The value of `level` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.
+
+> `email`: string
+
+User email address, used to distinguish traffic from different users.
+
+### DefaultObject
+
+```json
+{
+  "level": 0
+}
+```
+
+> `level`: number
+
+User level. The connection will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
+
+The value of `level` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.