mcp-xray-pilot 0.10.0

package/data/docs/inbounds__inbounds_wireguard.md

@@ -0,0 +1,78 @@
+---
+url: https://xtls.github.io/en/config/inbounds/wireguard.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/inbounds/wireguard.md
+title: WireGuard
+category: inbounds
+slug: inbounds/wireguard
+fetched_at: 2026-05-04T18:42:52.729Z
+---
+# WireGuard
+
+User-space WireGuard protocol implementation.
+
+::: danger
+**The WireGuard protocol is not designed specifically for bypassing firewalls. If used as the outer layer to cross the firewall, its distinct characteristics may lead to the server being blocked.**
+:::
+
+## InboundConfigurationObject
+
+```json
+{
+  "secretKey": "PRIVATE_KEY",
+  "peers": [
+    {
+      "publicKey": "PUBLIC_KEY",
+      "allowedIPs": [""]
+    }
+  ],
+  "mtu": 1420 // optional, default 1420
+}
+```
+
+> `secretKey`: string
+
+Private key. Required.
+
+> `mtu`: int
+
+The MTU size of the underlying WireGuard TUN.
+
+<details>
+<summary>Method to Calculate MTU</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 you are in a special network environment, you may need to subtract more (e.g., home broadband PPPoE requires an extra -8).
+
+</details>
+
+> `peers`: \[ [Peers](#peers) \]
+
+List of peers, where each item is a peer configuration.
+
+### Peers
+
+```json
+{
+  "publicKey": "PUBLIC_KEY",
+  "allowedIPs": ["0.0.0.0/0"] // optional, default ["0.0.0.0/0", "::/0"]
+}
+```
+
+> `publicKey`: string
+
+Public key, used for verification.
+
+> `allowedIPs`: string array
+
+Allowed source IPs.

package/data/docs/outbounds__outbounds_blackhole.md

@@ -0,0 +1,42 @@
+---
+url: https://xtls.github.io/en/config/outbounds/blackhole.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/blackhole.md
+title: Blackhole
+category: outbounds
+slug: outbounds/blackhole
+fetched_at: 2026-05-04T18:42:54.758Z
+---
+# Blackhole
+
+Blackhole is an outbound data protocol that blocks all outbound data. When used in conjunction with [Routing Configuration](../routing.md), it can achieve the effect of blocking access to certain websites.
+
+## OutboundConfigurationObject
+
+```json
+{
+  "response": {
+    "type": "none"
+  }
+}
+```
+
+> `response`: [ResponseObject](#responseobject)
+
+Configures the response data of the Blackhole.
+
+After receiving data to be forwarded, Blackhole will send the specified response data, then close the connection. The data to be forwarded will be discarded.
+If this item is not specified, Blackhole will close the connection immediately.
+
+### ResponseObject
+
+```json
+{
+  "type": "none"
+}
+```
+
+> `type`: "http" | "none"
+
+When `type` is `"none"` (default value), Blackhole will close the connection immediately.
+
+When `type` is `"http"`, Blackhole will send back a simple HTTP 403 response packet, then close the connection.

package/data/docs/outbounds__outbounds_dns.md

@@ -0,0 +1,97 @@
+---
+url: https://xtls.github.io/en/config/outbounds/dns.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/dns.md
+title: DNS
+category: outbounds
+slug: outbounds/dns
+fetched_at: 2026-05-04T18:42:55.246Z
+---
+# DNS
+
+DNS is an outbound protocol used to receive DNS queries sent in by routing, then forward or process them according to rules.
+
+This outbound only supports traditional plaintext DNS queries over UDP and TCP; non-plaintext DNS protocols such as DoH, DoT, and DoQ are not applicable to this outbound. Common scenarios include TUN, transparent proxy, or `dokodemo-door` receiving DNS traffic and then routing sending that traffic to this outbound.
+
+It can allow queries to the target DNS server, `hijack` them to the built-in [DNS server](../dns.md) for further processing, drop them, or explicitly refuse them according to rules. It can also rewrite the target address, port, and transport protocol.
+
+## OutboundConfigurationObject
+
+```json
+{
+  "network": "udp",
+  "address": "1.1.1.1",
+  "port": 53,
+  "userLevel": 0,
+  "rules": [
+    {
+      "action": "reject",
+      "domain": ["domain:example.com"]
+    },
+    {
+      "action": "direct",
+      "qtype": 65,
+      "domain": ["geosite:geolocation-!cn"]
+    }
+  ]
+}
+```
+
+The example above only demonstrates the field syntax. See the full example below for a complete configuration.
+
+> `network`: [ "tcp" | "udp" ]
+
+Modifies the transport protocol used for DNS traffic. Available values are `"tcp"` and `"udp"`. If omitted, the original transport method is preserved.
+
+> `address`: address
+
+Modifies the DNS server address. If omitted, the address specified by the source is preserved.
+
+> `port`: number
+
+Modifies the DNS server port. If omitted, the port specified by the source is preserved.
+
+> `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 `level` value in [policy](../policy.md#policyobject). If omitted, it defaults to `0`.
+
+> `rules`: \[[RuleObject](#ruleobject)\]
+
+Matches DNS query rules in order, and supports fine-grained control by `qtype` and `domain`.
+
+If no rule is matched, the built-in fallback rule is used: A and AAAA queries are imported into the built-in DNS module, while other query types are explicitly refused.
+
+## RuleObject
+
+```json
+{
+  "action": "hijack",
+  "qtype": 1,
+  "domain": ["geosite:cn"]
+}
+```
+
+All matching conditions in a rule are combined with AND logic. If a condition is omitted, that condition is not restricted.
+
+> `action`: [ "direct" | "hijack" | "drop" | "reject" ]
+
+Defines the action to take when the rule matches.
+
+- `direct`: Allows the query directly to the target DNS server. If outbound-level `network`, `address`, or `port` is also configured, the query is forwarded to the rewritten target.
+- `hijack`: Imports the query into the built-in [DNS server](../dns.md) for further processing. This can be used for additional routing based on the built-in DNS configuration. Currently, only A and AAAA records are supported.
+- `drop`: Drops the request directly without returning a response.
+- `reject`: Returns an explicit refusal response. Compared with `drop`, this can prevent some applications from waiting too long for a DNS timeout or repeatedly retrying.
+
+> `qtype`: number | string
+
+Matches DNS query types. The forms are as follows:
+
+- Integer value: a specific query type, such as `"qtype": 1` for an A query, or `"qtype": 28` for an AAAA query.
+- String: can be a digits-only string such as `"qtype": "28"`, or a numeric range such as `"qtype": "5-10"`, which represents the 6 types from type 5 to type 10. Commas can be used for segmentation, such as `11,13,15-17`, which represents the 5 types: type 11, type 13, and type 15 to type 17.
+
+For specific type numbers, refer to the [IANA documentation](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml).
+
+> `domain`: [string]
+
+Matches a list of domains. The syntax is the same as [`domain` in routing rules](../routing.md#ruleobject).

package/data/docs/outbounds__outbounds_freedom.md

@@ -0,0 +1,170 @@
+---
+url: https://xtls.github.io/en/config/outbounds/freedom.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/freedom.md
+title: Freedom (fragment, noises)
+category: outbounds
+slug: outbounds/freedom
+fetched_at: 2026-05-04T18:42:55.761Z
+---
+# Freedom (fragment, noises)
+
+Freedom is an outbound protocol used to send (normal) TCP or UDP data to any network.
+
+::: warning
+This outbound has a default safety policy in server-side and reverse-proxy scenarios, which may block some targets. See `finalRules` below for how to allow them.
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "domainStrategy": "AsIs",
+  "redirect": "127.0.0.1:3366",
+  "userLevel": 0,
+  "fragment": {
+    "packets": "tlshello",
+    "length": "100-200",
+    "interval": "10-20" // Unit: ms
+  },
+  "noises": [
+    {
+      "type": "base64",
+      "packet": "7nQBAAABAAAAAAAABnQtcmluZwZtc2VkZ2UDbmV0AAABAAE=",
+      "delay": "10-16"
+    }
+  ],
+  "proxyProtocol": 0,
+  "finalRules": [
+    {
+      "action": "block",
+      "network": "tcp",
+      "port": "22,25,465,587"
+    },
+    {
+      "action": "block",
+      "ip": ["geoip:cn"]
+    }
+  ]
+}
+```
+
+> `domainStrategy`: "AsIs"<br>
+> "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4"<br>
+> "ForceIP" | "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4"
+
+Default value `"AsIs"`.
+
+The meanings of all parameters are roughly equivalent to `domainStrategy` in [sockopt](../transport.md#sockoptobject).
+
+Only using `"AsIs"` here allows passing the domain name to the subsequent `sockopt` module. If set to non-`"AsIs"` here, causing the domain to be resolved to a specific IP, it will invalidate the subsequent `sockopt.domainStrategy` and its related `happyEyeballs`. (There is no negative impact if these two settings are not adjusted).
+
+When sending UDP, Freedom ignores `domainStrategy` in `sockopt` for some reasons and forcibly prefers IPv4 by default.
+
+> `redirect`: address_port
+
+Freedom will forcibly send all data to the specified address (instead of the address specified by the inbound).
+
+The value is a string, e.g., `"127.0.0.1:80"`, `":1234"`.
+
+When the address is not specified, e.g., `":443"`, Freedom will not modify the original destination address.
+When the port is `0`, e.g., `"xray.com:0"`, Freedom will not modify the original port.
+
+> `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.
+
+> `fragment`: map
+
+A set of key-value configuration items used to control outgoing TCP fragmentation. In some cases, it can deceive censorship systems, such as bypassing SNI blacklists.
+
+`"length"` and `"interval"` are both [Int32Range](../../development/intro/guide.md#int32range) types.
+
+`"packets"`: Supports two fragmentation modes. `"1-3"` is TCP stream slicing, applied to the 1st through 3rd data writes by the client. `"tlshello"` is TLS handshake packet slicing.
+
+`"length"`: Fragment packet length (byte).
+
+`"interval"`: Fragment interval (ms).
+
+When `interval` is 0 and `"packets": "tlshello"` is set, the fragmented Client Hello will be sent in one TCP packet (provided its original size does not exceed MSS or MTU causing automatic system fragmentation).
+
+> `noises`: array
+
+UDP noise, used to send some random data as "noise" before sending a UDP connection. Presence of this structure implies enablement. It might deceive sniffers, or it might disrupt normal connections. _Use at your own risk._ For this reason, it bypasses port 53 because that breaks DNS.
+
+It is an array where multiple noise packets to be sent can be defined. A single element in the array is defined as follows:
+
+`"type"`: Noise packet type. Currently supports `"rand"` (random data), `"str"` (user-defined string), `"base64"` (base64 encoded custom binary data).
+
+`"packet"`: The content of the packet to be sent based on the preceding `type`.
+
+- When `type` is `rand`, this specifies the length of the random data. It can be a fixed value `"100"` or a floating range `"50-150"`.
+- When `type` is `str`, this specifies the string to be sent.
+- When `type` is `hex`, this specifies binary data in hex format.
+- When `type` is `base64`, this specifies base64 encoded binary data.
+
+`"delay"`: Delay in milliseconds. After sending this noise packet, the core will wait for this time before sending the next noise packet or real data. Defaults to no wait. It is an [Int32Range](../../development/intro/guide.md#int32range) type.
+
+> `proxyProtocol`: number
+
+PROXY protocol is usually used with `redirect` to redirect traffic to Nginx or other backend services that have the PROXY protocol enabled. If the backend service does not support PROXY protocol, the connection will be disconnected.
+
+The value of `proxyProtocol` is the PROXY protocol version number. Options are `1` or `2`. If not specified, it defaults to `0` (disabled).
+
+> `finalRules`: \[[FinalRuleObject](#finalruleobject)\]
+
+Matches Freedom final outbound rules in order, and allows or blocks connection targets.
+
+Compared with blocking in `routing`, `finalRules` applies at Freedom's final outbound stage: matching happens after the final IP is resolved and before dialing; in addition, UDP is also matched packet by packet during send and receive, making it stricter and more thorough. Each rule match takes about 50-150 ns.
+
+Note: whenever Freedom needs to apply `finalRules`, if `domainStrategy` is `AsIs` and the target is a domain, Freedom still resolves the target to an IP through the operating system DNS before matching rules. At that point the target is no longer a domain, so the later `sockopt.domainStrategy` and its `happyEyeballs` no longer take effect.
+
+::: warning
+There is a default fallback safety policy for server-side and reverse-proxy scenarios:
+
+If no explicit rule matches, the built-in fallback rule is used: traffic from the VLESS reverse proxy blocks all targets by default; traffic from `VLESS`, `VMess`, `Trojan`, `Shadowsocks`, `Hysteria`, or `WireGuard` inbounds blocks private and reserved IP ranges by default; other traffic is fully allowed by default.
+
+If the server needs to allow clients to access some internal services, explicitly configure `allow` rules and limit them to the necessary `network`, `ip`, and `port` whenever possible.
+
+If the server also needs features that rely on passing the domain to `sockopt` (such as `sockopt.domainStrategy` or `happyEyeballs`), it cannot continue relying on this default safety policy. You can configure the first rule as an `allow` rule without any matching conditions to restore the previous behavior; this is also equivalent to disabling this default safety policy, so evaluate the security impact yourself.
+:::
+
+### FinalRuleObject
+
+```json
+{
+  "action": "block",
+  "network": "tcp,udp",
+  "port": "53,443",
+  "ip": ["10.0.0.0/8", "2001:db8::/32"],
+  "blockDelay": "30-90"
+}
+```
+
+All matching conditions in a rule are combined with AND logic. If a condition is omitted, that condition is not restricted.
+
+> `action`: "allow" | "block"
+
+Defines the action to take when the rule matches.
+
+- `allow`: Allows the target.
+- `block`: Blocks the target.
+
+> `network`: "tcp" | "udp" | "tcp,udp"
+
+Matches the network type. The rule takes effect when the connection method matches. It can also be written as a string array, such as `["tcp", "udp"]`. If omitted, all networks are matched.
+
+> `port`: number | string
+
+Target port range. The syntax is the same as [`port` in routing rules](../routing.md#ruleobject). If omitted, all ports are matched.
+
+> `ip`: \[string\]
+
+An array where each item represents an IP range. The rule takes effect when an item matches the target IP. The syntax is the same as [`ip` in routing rules](../routing.md#ruleobject). If omitted, all IPs are matched.
+
+> `blockDelay`: string
+
+Sets how long the blackhole state lasts after a blocking rule matches.
+
+When a rule's `action` is `block` and the target matches, Freedom puts the connection into a blackhole state and closes it after this duration expires. The unit is seconds. It can be written as a fixed value or a range, for example `30` or `30-90`. If omitted, it defaults to `30-90`, which means a random value within that range.

package/data/docs/outbounds__outbounds_http.md

@@ -0,0 +1,70 @@
+---
+url: https://xtls.github.io/en/config/outbounds/http.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/http.md
+title: HTTP
+category: outbounds
+slug: outbounds/http
+fetched_at: 2026-05-04T18:42:56.244Z
+---
+# HTTP
+
+HTTP protocol.
+
+::: danger
+**The HTTP protocol does not encrypt transmission, so it is not suitable for transmission over the public internet. It makes it easier to become a "zombie" (bot) used for attacks.**
+:::
+
+::: tip
+`http` can only proxy the TCP protocol; UDP-based protocols cannot pass through.
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "address": "192.168.108.1",
+  "port": 3128,
+  "user": "my-username",
+  "pass": "my-password",
+  "level": 0,
+  "email": "love@xray.com",
+  "headers": {
+    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36",
+    "Accept-Language": "zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2"
+  }
+}
+```
+
+::: tip
+Currently, `security` and `tlsSettings` in `streamSettings` are effective in the HTTP outbound protocol.
+:::
+
+> `address`: string
+
+HTTP proxy server address. Required.
+
+> `port`: int
+
+HTTP proxy 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.
+
+> `headers`: map{ string, string }
+
+HTTP headers, a map of key-value pairs. Each key represents the name of an HTTP header. All key-value pairs will be attached to every request.

package/data/docs/outbounds__outbounds_hysteria.md

@@ -0,0 +1,39 @@
+---
+url: https://xtls.github.io/en/config/outbounds/hysteria.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/hysteria.md
+title: Hysteria
+category: outbounds
+slug: outbounds/hysteria
+fetched_at: 2026-05-04T18:43:00.303Z
+---
+# Hysteria
+
+Client implementation of the Hysteria protocol.
+
+This page is very simple because the Hysteria protocol is actually composed of a simple proxy control protocol and a tuned QUIC underlying transport. In Xray, the proxy protocol and the underlying transport are separated. For more details (such as `brutal`), please refer to [hysteriaSettings](../transports/hysteria.md) [finalmask.quicParams](../transport.md#quicParams) in the underlying transport section.
+
+::: tip
+The `hysteria protocol` itself has no authentication. When using with a non `hysteria` transport layer, it will be unable to proxy `udp`, and using it with other transport layers is not recommended.
+:::
+
+## OutboundConfigurationObject
+
+```json
+{
+  "version": 2,
+  "address": "192.168.108.1",
+  "port": 3128
+}
+```
+
+> `version`: number
+
+Hysteria version, must be 2.
+
+> `address`: string
+
+Hysteria proxy server address, required.
+
+> `port`: int
+
+Hysteria proxy server port, required.

package/data/docs/outbounds__outbounds_index.md

@@ -0,0 +1,24 @@
+---
+url: https://xtls.github.io/en/config/outbounds/index.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/index.md
+title: Xray Outbound Protocols
+category: outbounds
+slug: outbounds/index
+fetched_at: 2026-05-04T18:42:54.250Z
+---
+# Xray Outbound Protocols
+
+Xray supports the following outbound protocols:
+
+- [Blackhole](blackhole.md)
+- [DNS](dns.md)
+- [Freedom (fragment, noises)](freedom.md)
+- [HTTP](http.md)
+- [Loopback](loopback.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)

package/data/docs/outbounds__outbounds_loopback.md

@@ -0,0 +1,65 @@
+---
+url: https://xtls.github.io/en/config/outbounds/loopback.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbounds/loopback.md
+title: Loopback
+category: outbounds
+slug: outbounds/loopback
+fetched_at: 2026-05-04T18:42:56.760Z
+---
+# Loopback
+
+Loopback is an outbound data protocol. Its function is to re-inject data sent through this outbound back into the routing inbound, allowing the data to be processed by the routing system again without leaving Xray-core.
+
+## OutboundConfigurationObject
+
+```json
+{
+  "inboundTag": "TagUseAsInbound"
+}
+```
+
+> `inboundTag`: string
+
+The inbound protocol identifier used for re-routing.
+
+This identifier can be used for `inboundTag` in routing rules, indicating that data from this outbound can be processed again by the corresponding routing rules.
+
+### How to use?
+
+If you need to perform finer-grained splitting on traffic that has already been split by routing rules—for example, if TCP traffic and UDP traffic split by the same group of routing rules need to go through different outbounds—you can use the `loopback` outbound to achieve this.
+
+```json
+{
+  "outbounds": [
+    {
+      "protocol": "loopback",
+      "tag": "need-to-split",
+      "settings": {
+        "inboundTag": "traffic-input" // This tag is used for the inboundTag of RuleObject below
+      }
+    },
+    {
+      "tag": "tcp-output"
+      // settings like protocol, settings, streamSettings
+    },
+    {
+      "tag": "udp-output"
+      // settings like protocol, settings, streamSettings
+    }
+  ],
+  "routing": {
+    "rules": [
+      {
+        "inboundTag": ["traffic-input"], // tag set in loopback
+        "network": "tcp",
+        "outboundTag": "tcp-output"
+      },
+      {
+        "inboundTag": ["traffic-input"], // tag set in loopback
+        "network": "udp",
+        "outboundTag": "udp-output"
+      }
+    ]
+  }
+}
+```