mcp-xray-pilot 0.10.0

package/data/docs/outbounds__outbounds_shadowsocks.md

@@ -0,0 +1,105 @@
+---
+url: https://xtls.github.io/en/config/outbounds/shadowsocks.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/shadowsocks.md
+title: Shadowsocks
+category: outbounds
+slug: outbounds/shadowsocks
+fetched_at: 2026-05-04T18:42:57.244Z
+---
+# Shadowsocks
+
+The [Shadowsocks](https://en.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.
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "email": "love@xray.com",
+  "address": "127.0.0.1",
+  "port": 1234,
+  "method": "Encryption Method",
+  "password": "Password",
+  "uot": true,
+  "UoTVersion": 2,
+  "level": 0
+}
+```
+
+> `email`: string
+
+Email address, optional, used to identify the user.
+
+> `address`: address
+
+Shadowsocks server address. Supports IPv4, IPv6, and domain names. Required.
+
+> `port`: number
+
+Shadowsocks server port. Required.
+
+> `method`: string
+
+Shadowsocks encryption method. Required.
+
+> `password`: string
+
+Shadowsocks authentication password. Required.
+
+> `uot`: bool
+
+Enable `udp over tcp`.
+
+> `UoTVersion`: number
+
+Implementation version of `UDP over TCP`.
+
+Current optional values: `1`, `2`.
+
+- 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#policyobject). If not specified, the default is 0.

package/data/docs/outbounds__outbounds_socks.md

@@ -0,0 +1,58 @@
+---
+url: https://xtls.github.io/en/config/outbounds/socks.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/socks.md
+title: Socks
+category: outbounds
+slug: outbounds/socks
+fetched_at: 2026-05-04T18:42:57.742Z
+---
+# Socks
+
+Standard Socks protocol implementation, compatible with Socks 5.
+
+::: danger
+**The Socks protocol does not encrypt transmission and is not suitable for transmission over the public internet.**
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "address": "127.0.0.1",
+  "port": 1234,
+  "user": "test user",
+  "pass": "test pass",
+  "level": 0,
+  "email": "love@xray.com"
+}
+```
+
+> `address`: address
+
+Server address. Required.
+
+::: tip
+Only connections to Socks 5 servers are supported.
+:::
+
+> `port`: number
+
+Server port. Required.
+
+> `user`: string
+
+Username, string type. Required if the remote server requires authentication; otherwise, do not include this item.
+
+> `pass`: string
+
+Password, string type. Required if the remote server requires authentication; otherwise, do not include this item.
+
+> `level`: number
+
+User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level. Optional if the remote server requires authentication; otherwise, do not include this item.
+
+The value of `userLevel` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, the default is 0.
+
+> `email`: string
+
+Email address, used to identify the user. Optional if the remote server requires authentication; otherwise, do not include this item.

package/data/docs/outbounds__outbounds_trojan.md

@@ -0,0 +1,49 @@
+---
+url: https://xtls.github.io/en/config/outbounds/trojan.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/trojan.md
+title: Trojan
+category: outbounds
+slug: outbounds/trojan
+fetched_at: 2026-05-04T18:42:58.256Z
+---
+# Trojan
+
+[Trojan](https://trojan-gfw.github.io/trojan/protocol) protocol.
+
+::: danger
+Trojan is designed to work over a correctly configured encrypted TLS tunnel.
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "address": "127.0.0.1",
+  "port": 1234,
+  "password": "password",
+  "email": "love@xray.com",
+  "level": 0
+}
+```
+
+> `address`: address
+
+Server address. Supports IPv4, IPv6, and domain names. Required.
+
+> `port`: number
+
+Server port. Usually the same as the port the server is listening on.
+
+> `password`: string
+
+Password. Required, any string.
+
+> `email`: string
+
+Email address. Optional, used to identify the user.
+
+> `level`: number
+
+User level. Connections 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.

package/data/docs/outbounds__outbounds_vless.md

@@ -0,0 +1,122 @@
+---
+url: https://xtls.github.io/en/config/outbounds/vless.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/vless.md
+title: VLESS (XTLS Vision Seed)
+category: outbounds
+slug: outbounds/vless
+fetched_at: 2026-05-04T18:42:58.784Z
+---
+# VLESS (XTLS Vision Seed)
+
+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.
+
+Unlike [VMess](./vmess.md), VLESS does not depend on system time. The authentication method is also UUID.
+
+## OutboundConfigurationObject
+
+```json
+{
+  "address": "example.com",
+  "port": 443,
+  "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
+  "encryption": "none",
+  "flow": "xtls-rprx-vision",
+  "level": 0,
+  "reverse": {}
+}
+```
+
+> `address`: address
+
+Server address, points to the server. Supports domain names, IPv4, and IPv6.
+
+> `port`: number
+
+Server port, usually the same as the port the server is listening on.
+
+> `id`: string
+
+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. 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, or use the command `xray uuid` to generate a random UUID.
+
+> `encryption`: "none"
+
+[VLESS Encryption](https://github.com/XTLS/Xray-core/pull/5067) settings. Cannot be left empty; to disable, explicitly set 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 only for advanced users.
+
+Its 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".
+
+- **The 1st block** is the handshake method. Currently, there is only `mlkem768x25519plus`. Requires consistency between server and client.
+- **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.
+- **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.
+
+Following 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)` × n (multiple padding blocks can be inserted, requiring a delay block between two padding blocks). For example, you can write a very long `padding.delay.padding.delay.padding.delay.padding.delay.padding.delay.padding`.
+
+- `padding` format is `probability-min-max`. E.g., `100-111-1111` means 100% probability to send a padding of length 111~1111.
+- `delay` format is also `probability-min-max`. E.g., `75-0-111` means 75% probability to wait 0~111 milliseconds.
+
+The 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.
+
+**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.
+
+> `flow`: string
+
+Flow control mode, used to select the XTLS algorithm.
+
+Currently, the following flow control modes are available in the outbound protocol:
+
+- **No `flow` or empty string**: Use standard TLS proxy.
+- **`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.
+- **`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.
+
+XTLS is available only in the following combinations:
+
+- **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.
+- **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.
+
+::: tip About Splice
+Splice 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.
+
+When using Vision mode, Splice is automatically enabled if the following conditions are met:
+
+- Linux environment.
+- Inbound protocol is a pure TCP connection like `Dokodemo door`, `Socks`, `HTTP`, or other inbound protocols using XTLS.
+- Outbound protocol is VLESS + XTLS.
+
+When 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.
+:::
+
+> `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.
+
+> `reverse`: struct
+
+VLESS minimalist reverse proxy configuration. It functions the same as the core's built-in generic reverse proxy but is simpler to configure, and it preserves the real source IP information from the public-facing side.
+
+The 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.
+
+Current syntax:
+
+```json
+"reverse": {
+  "tag": "r-inbound",
+  "sniffing" : {}
+}
+```
+
+`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.
+
+The UUID used needs to be a UUID that is also configured with reverse on the server side (see VLESS Inbound for details).
+
+`sniffing` see [sniffingObject](../inbound.md#sniffingobject), performs sniffing on requests entering through this reverse proxy.

package/data/docs/outbounds__outbounds_vmess.md

@@ -0,0 +1,76 @@
+---
+url: https://xtls.github.io/en/config/outbounds/vmess.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/vmess.md
+title: VMess
+category: outbounds
+slug: outbounds/vmess
+fetched_at: 2026-05-04T18:42:59.291Z
+---
+# VMess
+
+[VMess](../../development/protocols/vmess.md) is an encrypted transport protocol, usually serving as a bridge between the Xray client and server.
+
+::: danger
+VMess 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.
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "address": "127.0.0.1",
+  "port": 37192,
+  "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
+  "security": "auto",
+  "level": 0,
+  "experiments": ""
+}
+```
+
+> `address`: address
+
+Server address, supports IP address or domain name.
+
+> `port`: number
+
+The port number the server is listening on. Required.
+
+> `id`: string
+
+VMess User ID. It can be any string less than 30 bytes or a valid UUID.
+
+A custom string and its mapped UUID are equivalent. This means you can identify the same user in the configuration file 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 value of `level` in [policy](../policy.md#policyobject). If not specified, the default is 0.
+
+> `security`: "aes-128-gcm" | "chacha20-poly1305" | "auto" | "none" | "zero"
+
+Encryption method. The client will use the configured encryption method to send data, and the server will automatically identify it without configuration.
+
+- `"aes-128-gcm"`: Use AES-128-GCM algorithm.
+- `"chacha20-poly1305"`: Use Chacha20-Poly1305 algorithm.
+- `"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).
+- `"none"`: No encryption, maintains the VMess message structure.
+- `"zero"`: No encryption, direct stream copy (similar to VLESS).
+
+It 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.
+
+Note: `"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.
+
+> `experiments`: string
+
+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"`.
+
+- `"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.
+- `"NoTerminationSignal"`: Enable not sending the disconnection signal. This feature is now enabled by default.

package/data/docs/outbounds__outbounds_wireguard.md

@@ -0,0 +1,141 @@
+---
+url: https://xtls.github.io/en/config/outbounds/wireguard.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/wireguard.md
+title: Wireguard
+category: outbounds
+slug: outbounds/wireguard
+fetched_at: 2026-05-04T18:42:59.805Z
+---
+# Wireguard
+
+Standard Wireguard protocol implementation.
+
+::: danger
+**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.**
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "secretKey": "PRIVATE_KEY",
+  "address": [
+    // optional, default ["10.0.0.1", "fd59:7153:2388:b5fd:0000:0000:0000:0001"]
+    "IPv4_CIDR",
+    "IPv6_CIDR",
+    "and more..."
+  ],
+  "peers": [
+    {
+      "endpoint": "ENDPOINT_ADDR",
+      "publicKey": "PUBLIC_KEY"
+    }
+  ],
+  "noKernelTun": false,
+  "mtu": 1420, // optional, default 1420
+  "reserved": [1, 2, 3],
+  "workers": 2, // optional, default runtime.NumCPU()
+  "domainStrategy": "ForceIP"
+}
+```
+
+::: tip
+Currently, configuring `streamSettings` is not supported in the Wireguard protocol outbound.
+:::
+
+> `secretKey`: string
+
+User private key. Required.
+
+> `address`: string array
+
+Wireguard will start a virtual network interface (tun) locally. Use one or more IP addresses; IPv6 is supported.
+
+> `noKernelTun`: true | false
+
+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.
+
+This 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.
+
+When 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.
+
+Note 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.
+
+> `mtu`: int
+
+MTU size of the underlying Wireguard tun.
+
+<details>
+<summary>MTU Calculation Method</summary>
+
+The structure of a Wireguard packet is as follows:
+
+```
+- 20-byte IPv4 header or 40 byte IPv6 header
+- 8-byte UDP header
+- 4-byte type
+- 4-byte key index
+- 8-byte nonce
+- N-byte encrypted data
+- 16-byte authentication tag
+```
+
+`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).
+
+</details>
+
+> `reserved` \[ number \]
+
+Wireguard reserved bytes, fill as needed.
+
+> `workers`: int
+
+Number of threads used by Wireguard. Defaults to the number of system cores.
+
+> `peers`: \[ [Peers](#peers) \]
+
+List of Wireguard servers, where each item is a server configuration.
+
+> `domainStrategy`: "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4" | "ForceIP"
+
+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.
+
+Unlike 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`.
+
+The `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.<br>
+Note: 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.
+
+### Peers
+
+```json
+{
+  "endpoint": "ENDPOINT_ADDR",
+  "publicKey": "PUBLIC_KEY",
+  "preSharedKey": "PRE_SHARED_KEY", // optional, default "0000000000000000000000000000000000000000000000000000000000000000"
+  "keepAlive": 0, // optional, default 0
+  "allowedIPs": ["0.0.0.0/0"] // optional, default ["0.0.0.0/0", "::/0"]
+}
+```
+
+> `endpoint`: address
+
+Server address, required.
+
+URL:Port format, e.g., `engage.cloudflareclient.com:2408`<br>
+IP:Port format, e.g., `162.159.192.1:2408` or `[2606:4700:d0::a29f:c001]:2408`
+
+> `publicKey`: string
+
+Server public key, used for verification, required.
+
+> `preSharedKey`: string
+
+Additional symmetric encryption key.
+
+> `keepAlive`: int
+
+Heartbeat interval in seconds. Default is 0, meaning no heartbeat.
+
+> `allowedIPs`: string array
+
+Wireguard only allows traffic from specific source IPs.