mcp-xray-pilot 0.10.0

package/data/docs/features__features_browser_dialer.md

@@ -0,0 +1,61 @@
+---
+url: https://xtls.github.io/en/config/features/browser_dialer.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/features/browser_dialer.md
+title: Browser Dialer
+category: features
+slug: features/browser_dialer
+fetched_at: 2026-05-04T18:42:46.683Z
+---
+# Browser Dialer
+
+## Background
+
+Through uTLS, Xray can simulate the TLS handshake fingerprints of mainstream browsers (see the `fingerprint` option in TLS for details). However, it still cannot guarantee that the simulated browser behavior is perfectly consistent with a real browser at all times.
+
+In response to this, the [Browser Dialer](https://github.com/v2ray/discussion/issues/754#issuecomment-647934994) was created. Users open a page at `localhost:8080` in their own browser. This page uses native JS to act as Xray's network stack, establishing TLS and HTTP connections with the proxy server.
+
+This method concisely implements real browser TLS fingerprints and behavioral characteristics, providing maximum anti-detection and anti-blocking capabilities.
+
+However, the current Browser Dialer has the following drawbacks:
+
+- Users need to manually open the browser.
+- Connections initiated by the browser must be direct. Users using `tun` need to pay special attention to avoid creating infinite routing loops.
+- The browser can only initiate HTTP connections, so currently, only [WebSocket](../transports/websocket.md) and [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) transport methods are supported.
+- When the browser connects from the `localhost:8080` page to the proxy server, [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) needs to be considered.
+- Since data is processed via JS, there will be some performance overhead.
+- Custom SNI or Host cannot be used; that is, `SNI == host == address`. Custom HTTP headers and other `tlsSettings` items will be ignored.
+
+## Configuration Method
+
+1. Prepare a WebSocket or XHTTP configuration. Note that the `address` must be a domain name. If you need to specify an IP, please configure DNS or the system `hosts` file.
+2. Start Xray using the environment variable `XRAY_BROWSER_DIALER=127.0.0.1:8080`.
+   - On Windows: `set XRAY_BROWSER_DIALER=127.0.0.1:8080`
+   - On Linux: `XRAY_BROWSER_DIALER=127.0.0.1:8080 ./xray -c config.json`
+3. Ensure the browser connects directly (or configure the routing so that the server address is sent directly via `freedom`). Open the page `localhost:8080`. You can also use `F12` to check `Console` and `Network`.
+4. Browsers limit the number of outbound connections, so it is recommended to enable `Mux.Cool`.
+
+## Internal Communication Mechanism
+
+- Xray listens on the address/port `http://127.0.0.1:8080` as an HTTP server. The browser visits this address and loads the JS in the webpage.
+- The JS actively establishes a WebSocket connection to `http://127.0.0.1:8080`. Upon success, Xray sends the connection to a channel.
+- When a connection needs to be established, Xray retrieves an available connection from the channel and sends the target URL and optional early data.
+- After the JS successfully connects to the target, it notifies Xray and continues to use this connection to forward data in full-duplex mode. Connection closure is synchronized.
+- The connection is closed after use, but the JS ensures that new idle connections are always available.
+
+## WebSocket
+
+<Badge text="v1.4.1+" type="warning"/>
+
+Based on browser requirements, the following adjustments were made to the early data mechanism:
+
+- The server response header will carry the requested `Sec-WebSocket-Protocol`, which preliminarily obfuscates the length characteristics of the WSS handshake response.
+- The early data encoding used for browsers is `base64.RawURLEncoding` instead of `StdEncoding`. The server has made compatibility adjustments.
+- Additionally, due to [Xray-core#375](https://github.com/XTLS/Xray-core/pull/375) recommending `?ed=2048`, this PR also expanded a `MaxHeaderBytes` limit on the server side to 4096. ~~ (Although it seems fine without changing it) ~~
+
+## XHTTP
+
+<Badge text="v1.8.19+" type="warning"/>
+
+[XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) itself supports QUIC. If you want to use the browser's own QUIC network stack, Chrome users can configure it in `chrome://flags`. Other browsers also have relevant options.
+
+In principle, `tlsSettings` items will be ignored, and the HTTP version used will be determined entirely by the browser.

package/data/docs/features__features_env.md

@@ -0,0 +1,66 @@
+---
+url: https://xtls.github.io/en/config/features/env.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/features/env.md
+title: Environment Variables
+category: features
+slug: features/env
+fetched_at: 2026-05-04T18:42:47.197Z
+---
+# Environment Variables
+
+Xray provides the following environment variables to modify some underlying configurations of Xray.
+
+## Resource File Path
+
+- Name: `xray.location.asset` or `XRAY_LOCATION_ASSET`.
+- Default value: Specific [FHS](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) directories or the same path as the Xray executable.
+
+This environment variable specifies a folder location that should contain the `geoip.dat` and `geosite.dat` files.
+If no variable value is specified, the program will look for resource files in the following order:
+
+```
+./
+/usr/local/share/xray
+/usr/share/xray
+```
+
+## Configuration File Location
+
+- Name: `xray.location.config` or `XRAY_LOCATION_CONFIG`.
+- Default value: The same path as the Xray executable.
+
+This environment variable specifies a folder location that should contain the `config.json` file.
+
+## Multiple Configuration Directory
+
+- Name: `xray.location.confdir` or `XRAY_LOCATION_CONFDIR`.
+- Default value: `""`.
+
+The `.json` files in this directory will be read in alphabetical order of their filenames as multiple configuration options.
+
+This item has lower priority than the startup argument `confdir`.
+
+## Strict JSON Parser
+
+- Name: `xray.json.strict` or `XRAY_JSON_STRICT`.
+- Default value: `false`.
+
+By default, on startup Xray uses a custom JSON parser that strips comments and other non-standard characters from the configuration. If you are sure that your configuration file strictly conforms to the JSON standard (RFC 8259), you can enable this option to use the standard JSON parser, which is faster when working with large configurations.
+
+## Other Available Configurations
+
+- xray.location.plugin
+- xray.location.tool
+- xray.location.cert
+
+- xray.buf.readv
+- xray.buf.splice
+- xray.vmess.padding
+- xray.cone.disabled
+
+- xray.ray.buffer.size
+- xray.browser.dialer
+- xray.xudp.show
+- xray.xudp.basekey
+
+These options are open to users with special needs; you can read the source code to discover their usage. ~PR Welcome~

package/data/docs/features__features_fallback.md

@@ -0,0 +1,110 @@
+---
+url: https://xtls.github.io/en/config/features/fallback.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/features/fallback.md
+title: Fallback
+category: features
+slug: features/fallback
+fetched_at: 2026-05-04T18:42:46.157Z
+---
+# Fallback
+
+> **Fallback is one of Xray's most powerful features, effectively preventing active probing and allowing multiple services to share common ports.**
+
+Fallback provides Xray with high-strength resistance against active probing and features a unique first-packet fallback mechanism.
+
+Fallback can also split different types of traffic based on `path`, allowing a single port to be shared by multiple services.
+
+Currently, you can use the fallback feature by configuring `fallbacks` when using VLESS or Trojan protocols, allowing for very rich configuration combinations.
+
+## Fallbacks Configuration
+
+```json
+  "fallbacks": [
+    {
+      "dest": 80
+    }
+  ]
+```
+
+> `fallbacks`: \[ [FallbackObject](#fallbackobject) \]
+
+An array containing a series of powerful fallback distribution configurations.
+
+### FallbackObject
+
+```json
+{
+  "name": "",
+  "alpn": "",
+  "path": "",
+  "dest": 80,
+  "xver": 0
+}
+```
+
+**`fallbacks` is an array; this is the configuration description for one of its child elements.**
+
+The `fallbacks` item is optional and can only be used with the TCP+TLS transport combination.
+
+- When this item has child elements, [Inbound TLS](../transport.md#tlsobject) must set `"alpn":["http/1.1"]`.
+
+Usually, you need to first set a default fallback with both `alpn` and `path` omitted or empty, and then configure other traffic splitting as needed.
+
+VLESS will forward traffic to the address specified by `dest` if, after TLS decryption, the first packet length is < 18, the protocol version is invalid, or authentication fails.
+
+For other transport combinations, the `fallbacks` item or all child elements must be deleted. In this case, Fallback will not be enabled. VLESS will wait to read the required length, and if the protocol version is invalid or authentication fails, it will directly disconnect.
+
+> `name`: string
+
+Attempts to match TLS SNI (Server Name Indication). Empty means any. Default is `""`.
+
+> `alpn`: string
+
+Attempts to match the TLS ALPN negotiation result. Empty means any. Default is `""`.
+
+Xray will only attempt to read the TLS ALPN negotiation result when necessary. If successful, it outputs `realAlpn =` to the info log.
+Usage: Solves the issue where Nginx's h2c service cannot be compatible with http/1.1 simultaneously. Nginx would require two `listen` lines, for 1.1 and h2c respectively.
+Note: When `fallbacks` `alpn` contains `"h2"`, [Inbound TLS](../transport.md#tlsobject) needs to set `"alpn":["h2","http/1.1"]` to support h2 access.
+
+::: tip
+The `alpn` set in Fallback matches the _actually negotiated_ ALPN, whereas the `alpn` set in Inbound TLS is the list of _optional_ ALPNs during the handshake. The meanings are different.
+:::
+
+> `path`: string
+
+Attempts to match the HTTP PATH of the first packet. Empty means any. Default is empty. If non-empty, it must start with `/`. h2c is not supported.
+
+Smart: Xray will only attempt to peek at the PATH when necessary (not exceeding 55 bytes; uses the fastest algorithm, does not fully parse HTTP). If successful, it outputs the INFO log `realPath =`.
+Usage: Offloading WebSocket traffic or HTTP camouflage traffic from other inbounds. It performs pure traffic forwarding without extra processing. Theoretical performance is stronger than Nginx.
+
+Note: **The inbound where fallbacks is located must itself be TCP+TLS**. This is used for offloading to other WS inbounds; the offloaded inbound does not need to configure TLS.
+
+> `dest`: string | number
+
+Decides the destination of the TCP traffic after TLS decryption. Currently supports two types of addresses: (This item is mandatory, otherwise it will not start)
+
+1. TCP, formatted as `"addr:port"`, where `addr` supports IPv4, domain name, and IPv6. If a domain name is filled, a TCP connection will be initiated directly (without going through the built-in DNS).
+2. Unix domain socket, formatted as an absolute path, like `"/dev/shm/domain.socket"`. Can handle [abstract](https://www.man7.org/linux/man-pages/man7/unix.7.html) by adding `@` at the beginning, or `@@` for abstract with padding.
+
+If only `port` is filled, it can be a number or a string, like `80` or `"80"`. It usually points to a cleartext http service (`addr` will be filled as `"localhost"`).
+
+Note: Only after v25.7.26 does a `dest` containing only a port point to `localhost`. Before this, it was `127.0.0.1`. After the change, the actual target is likely `::1`. Some webserver templates copied online might listen on `::1` but only allow `127` to enter or apply the proxy protocol, which may lead to different behaviors.
+
+> `xver`: number
+
+Sends [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt), specifically used to pass the real source IP and port. Fill 1 or 2. Default is 0, meaning it is not sent. It is recommended to fill 1 if needed.
+
+Currently, filling 1 or 2 functions identically, only the structure differs (the former is printable, the latter is binary). Both TCP and WS inbounds in Xray support receiving PROXY protocol.
+
+::: warning
+If you are [configuring Nginx to accept PROXY protocol](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#configuring-nginx-to-accept-the-proxy-protocol), besides setting `proxy_protocol`, you also need to set `set_real_ip_from`, otherwise issues may occur.
+:::
+
+### Supplementary Explanation
+
+- It will match the most precise child element, regardless of the order of child elements. If several child elements with identical `alpn` and `path` are configured, the last one will prevail.
+- Fallback offloading is forwarding at the decrypted TCP layer, not the HTTP layer. It only checks the first packet's PATH when necessary.
+- You can view more tips and insights on using Fallbacks here:
+  - [Analysis of Fallbacks Features](../../document/level-1/fallbacks-lv1)
+
+## Fallbacks Design Theory <Badge text="WIP" type="warning"/>

package/data/docs/features__features_index.md

@@ -0,0 +1,17 @@
+---
+url: https://xtls.github.io/en/config/features/index.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/features/index.md
+title: Xray Features in Detail
+category: features
+slug: features/index
+fetched_at: 2026-05-04T18:42:45.154Z
+---
+# Xray Features in Detail
+
+Xray has the following features:
+
+- [XTLS Deep Dive](xtls.md)
+- [Fallback](fallback.md)
+- [Browser Dialer](browser_dialer.md)
+- [Environment Variables](env.md)
+- [Multiple File Configuration](multiple.md)

package/data/docs/features__features_multiple.md

@@ -0,0 +1,144 @@
+---
+url: https://xtls.github.io/en/config/features/multiple.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/features/multiple.md
+title: Multiple Configuration Files
+category: features
+slug: features/multiple
+fetched_at: 2026-05-04T18:42:47.728Z
+---
+# Multiple Configuration Files
+
+Xray supports the use of multiple configuration files.
+
+The main purpose of multiple configuration files is to disperse the configuration of different functional modules, facilitating management and maintenance.
+
+This feature is designed mainly to enrich Xray's ecosystem. For example, GUI clients usually only implement fixed functions like node selection, making it difficult to graphically implement complex configurations. By leaving a custom configuration directory `confdir`, complex functions can be configured there. For server deployment scripts, simply adding files to `confdir` can achieve multi-protocol configuration.
+
+## Multi-file Startup
+
+::: tip
+The startup log will indicate each configuration file read in sequence. Pay attention to whether the startup information matches your expected order. You can control the order by adding numeric prefixes to file names, such as `01_filename`, `02_filename`. The larger the number, the later it is sorted.
+:::
+
+```shell
+$ xray run -confdir /etc/xray/confs
+```
+
+You can also use `Xray.location.confdir` or `Xray_LOCATION_CONFDIR` to specify `confdir`.
+
+The `-confdir` parameter takes precedence over environment variables. If the parameter specifies a valid directory, the path in the environment variable will not be read.
+
+## Rules Explanation
+
+### Ordinary Objects (`{}`)
+
+Top-level objects in later files overwrite or supplement those in earlier files.
+
+### Arrays (`[]`)
+
+`inbounds` and `outbounds` in JSON configuration are array structures, and they have special rules:
+
+- Look for existing elements with the same `tag` and overwrite them; if not found:
+  - For `inbounds`, append to the end (order within inbounds doesn't matter).
+  - For `outbounds`, prepend to the beginning (the first outbound is the default); however, if the filename contains "tail" (case-insensitive), append to the end.
+
+## Configuration Example
+
+Assume there are the following three configuration files in the `confs` folder.
+
+- 01.json
+
+```json
+{
+  "log": {
+    "loglevel": "warning"
+  },
+  "inbounds": [
+    {
+      "tag": "socks",
+      "protocol": "socks",
+      "listen": "0.0.0.0",
+      "port": 8888
+    }
+  ],
+  "outbounds": [
+    {
+      "tag": "direct",
+      "protocol": "freedom"
+    }
+  ]
+}
+```
+
+- 02.json
+
+```json
+{
+  "log": {
+    "loglevel": "debug"
+  },
+  "inbounds": [
+    {
+      "tag": "socks",
+      "protocol": "socks",
+      "listen": "127.0.0.1",
+      "port": 1080
+    }
+  ],
+  "outbounds": [
+    {
+      "tag": "block",
+      "protocol": "blackhole"
+    }
+  ]
+}
+```
+
+- 03_tail.json
+
+```json
+{
+  "outbounds": [
+    {
+      "tag": "direct2",
+      "protocol": "freedom"
+    }
+  ]
+}
+```
+
+The three configurations will be merged as follows:
+
+```json
+{
+  "log": {
+    "loglevel": "debug" // Top-level object overwrites the former
+  },
+  "inbounds": [
+    {
+      "tag": "socks", // Overwrites the former when tag is the same
+      "protocol": "socks",
+      "listen": "127.0.0.1",
+      "port": 1080
+    }
+  ],
+  "outbounds": [
+    {
+      "tag": "block", // outbounds added to the front
+      "protocol": "blackhole"
+    },
+    {
+      "tag": "direct",
+      "protocol": "freedom"
+    },
+    {
+      "tag": "direct2", // Filename of 03_tail.json contains 'tail' keyword, added to the end
+      "protocol": "freedom"
+    }
+  ]
+}
+```
+
+::: tip
+You can use the `xray run -confdir=./confs -dump` command to view the merged configuration. However, since the core uses the Protobuf data format internally, the configuration format output by the `-dump` option will look different.
+:::

package/data/docs/features__features_xtls.md

@@ -0,0 +1,13 @@
+---
+url: https://xtls.github.io/en/config/features/xtls.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/features/xtls.md
+title: XTLS Deep Dive
+category: features
+slug: features/xtls
+fetched_at: 2026-05-04T18:42:45.640Z
+---
+# XTLS Deep Dive
+
+> **XTLS is Xray's original cutting-edge technology and the core driving force behind its unmatched performance.**
+
+<Badge text="WIP" type="warning"/>

package/data/docs/inbounds__inbounds_dokodemo.md

@@ -0,0 +1,11 @@
+---
+url: https://xtls.github.io/en/config/inbounds/dokodemo.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/dokodemo.md
+title: Dokodemo-Door
+category: inbounds
+slug: inbounds/dokodemo
+fetched_at: 2026-05-04T18:42:48.732Z
+---
+# Dokodemo-Door
+
+See [Tunnel](./tunnel.md)

package/data/docs/inbounds__inbounds_http.md

@@ -0,0 +1,80 @@
+---
+url: https://xtls.github.io/en/config/inbounds/http.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/http.md
+title: HTTP
+category: inbounds
+slug: inbounds/http
+fetched_at: 2026-05-04T18:42:49.716Z
+---
+# HTTP
+
+HTTP protocol.
+
+::: danger
+**The HTTP protocol does not encrypt traffic and is not suitable for transmission over the public internet. Using it exposes you to the risk of becoming a zombie for attacks.**
+:::
+
+A more meaningful usage of `http` inbound is to listen within a LAN or on the local machine to provide local services for other programs.
+
+::: tip TIP 1
+`http proxy` can only proxy the TCP protocol; UDP-based protocols are not supported.
+:::
+
+::: tip TIP 2
+Use the following environment variables in Linux to enable a global HTTP proxy for the current session (supported by many software, but not all).
+
+- `export http_proxy=http://127.0.0.1:8080/` (Address must be changed to your configured HTTP inbound proxy address)
+- `export https_proxy=$http_proxy`
+  :::
+
+## InboundConfigurationObject
+
+```json
+{
+  "accounts": [
+    {
+      "user": "my-username",
+      "pass": "my-password"
+    }
+  ],
+  "allowTransparent": false,
+  "userLevel": 0
+}
+```
+
+> `accounts`: \[[AccountObject](#accountobject)\]
+
+An array where each element is a user account. Default value is empty.
+
+When `accounts` is not empty, the HTTP proxy will perform Basic Authentication on inbound connections.
+
+> `allowTransparent`: true | false
+
+When set to `true`, all HTTP requests will be forwarded, not just proxy requests.
+
+::: tip
+If configured improperly, enabling this option can cause infinite loops.
+:::
+
+> `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_hysteria.md

@@ -0,0 +1,60 @@
+---
+url: https://xtls.github.io/en/config/inbounds/hysteria.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/hysteria.md
+title: Hysteria
+category: inbounds
+slug: inbounds/hysteria
+fetched_at: 2026-05-04T18:42:53.243Z
+---
+# Hysteria
+
+::: tip
+The `hysteria protocol` itself has no authentication; `clients` only take effect when used with the `hysteria` transport layer.
+:::
+
+## InboundConfigurationObject
+
+```json
+{
+  "version": 2,
+  "clients": [
+    {
+      "auth": "5783a3e7-e373-51cd-8642-c83782b807c5",
+      "level": 0,
+      "email": "love@xray.com"
+    }
+  ]
+}
+```
+
+> `version`: number
+
+Hysteria version, must be 2.
+
+> `clients`: \[ [ClientObject](#clientobject) \]
+
+An array representing a group of users approved by the server.
+
+### ClientObject
+
+```json
+{
+  "auth": "5783a3e7-e373-51cd-8642-c83782b807c5",
+  "level": 0,
+  "email": "love@xray.com"
+}
+```
+
+> `auth`: string
+
+A string of any length.
+
+> `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).

package/data/docs/inbounds__inbounds_index.md

@@ -0,0 +1,22 @@
+---
+url: https://xtls.github.io/en/config/inbounds/index.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/index.md
+title: Xray Inbound Protocols
+category: inbounds
+slug: inbounds/index
+fetched_at: 2026-05-04T18:42:48.232Z
+---
+# Xray Inbound Protocols
+
+Xray supports the following inbound protocols:
+
+- [Tunnel](tunnel.md)
+- [HTTP](http.md)
+- [Shadowsocks](shadowsocks.md)
+- [Socks](socks.md)
+- [Trojan](trojan.md)
+- [VLESS (XTLS Vision Seed)](vless.md)
+- [VMess](vmess.md)
+- [WireGuard](wireguard.md)
+- [Hysteria](hysteria.md)
+- [TUN](tun.md)