mcp-xray-pilot 0.10.0

package/data/docs/basic__metrics.md

@@ -0,0 +1,262 @@
+---
+url: https://xtls.github.io/en/config/metrics.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/metrics.md
+title: Metrics
+category: basic
+slug: metrics
+fetched_at: 2026-05-04T18:42:43.602Z
+---
+# Metrics
+
+A more direct (and hopefully better) way to export statistics.
+
+## Relevant Configuration
+
+Add `metrics` to the basic configuration:
+
+```json
+    "metrics": {
+        "tag": "Metrics",
+        "listen": "127.0.0.1:11111"
+    }
+```
+
+> `tag`: string
+
+The outbound proxy tag corresponding to metrics. You can access it by setting up a dokodemo-door inbound + routing rules that point the dokodemo-door to this outbound.
+
+> `listen`: string
+
+A simpler method: directly listen on an address and port to provide the service.
+
+When setting this field, if `tag` is empty, it will automatically be set to `Metrics`. If neither (`tag` nor `listen`) is set, the core will fail to start.
+
+## Usage
+
+### pprof
+
+Visit `http://127.0.0.1:11111/debug/pprof/` or use `go tool pprof` for debugging.
+
+To report excessive memory usage/memory leak issues, please provide files from `/debug/pprof/heap` and `/debug/pprof/goroutine`.
+
+### expvars
+
+Visit `http://127.0.0.1:11111/debug/vars`
+
+Variables included:
+
+- `stats`: Includes all inbound, outbound, and user data.
+- `observatory`: Includes observatory results.
+
+For example, in [luci-app-xray](https://github.com/yichya/luci-app-xray), you can get output like this (standard expvar content like cmdline and memstats are omitted):
+
+<details><summary>Click to view</summary><br>
+
+```json
+{
+  "observatory": {
+    "tcp_outbound": {
+      "alive": true,
+      "delay": 782,
+      "outbound_tag": "tcp_outbound",
+      "last_seen_time": 1648477189,
+      "last_try_time": 1648477189
+    },
+    "udp_outbound": {
+      "alive": true,
+      "delay": 779,
+      "outbound_tag": "udp_outbound",
+      "last_seen_time": 1648477191,
+      "last_try_time": 1648477191
+    }
+  },
+  "stats": {
+    "inbound": {
+      "api": {
+        "downlink": 0,
+        "uplink": 0
+      },
+      "dns_server_inbound_5300": {
+        "downlink": 14286,
+        "uplink": 5857
+      },
+      "http_inbound": {
+        "downlink": 74460,
+        "uplink": 10231
+      },
+      "https_inbound": {
+        "downlink": 0,
+        "uplink": 0
+      },
+      "metrics": {
+        "downlink": 6327,
+        "uplink": 1347
+      },
+      "socks_inbound": {
+        "downlink": 19925615,
+        "uplink": 5512
+      },
+      "tproxy_tcp_inbound": {
+        "downlink": 4739161,
+        "uplink": 1568869
+      },
+      "tproxy_udp_inbound": {
+        "downlink": 0,
+        "uplink": 2608142
+      }
+    },
+    "outbound": {
+      "blackhole_outbound": {
+        "downlink": 0,
+        "uplink": 0
+      },
+      "direct": {
+        "downlink": 97714548,
+        "uplink": 3234617
+      },
+      "dns_server_outbound": {
+        "downlink": 7116,
+        "uplink": 2229
+      },
+      "manual_tproxy_outbound_tcp_1": {
+        "downlink": 0,
+        "uplink": 0
+      },
+      "manual_tproxy_outbound_udp_1": {
+        "downlink": 0,
+        "uplink": 0
+      },
+      "tcp_outbound": {
+        "downlink": 23873238,
+        "uplink": 1049595
+      },
+      "udp_outbound": {
+        "downlink": 639282,
+        "uplink": 74634
+      }
+    },
+    "user": {}
+  }
+}
+```
+
+</details>
+
+To get better visualization output, you can use [Netdata](https://github.com/netdata/netdata) (with python.d plugin):
+
+1. Edit the relevant configuration file (`sudo /etc/netdata/edit-config python.d/go_expvar.conf`).
+2. Use the example configuration below:
+
+<details><summary>Click to view</summary><br>
+
+```yaml
+xray:
+  name: "xray"
+  update_every: 2
+  url: "http://127.0.0.1:11111/debug/vars"
+  collect_memstats: false
+  extra_charts:
+    - id: "inbounds"
+      options:
+        name: "inbounds"
+        title: "Xray System Inbounds"
+        units: bytes
+        family: xray
+        context: xray.inbounds
+        chart_type: line
+      lines:
+        - expvar_key: stats.inbound.tproxy_tcp_inbound.downlink
+          id: "tcp.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.tproxy_udp_inbound.downlink
+          id: "udp.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.http_inbound.downlink
+          id: "http.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.https_inbound.downlink
+          id: "https.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.socks_inbound.downlink
+          id: "socks.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.tproxy_tcp_inbound.uplink
+          id: "tcp.uplink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.tproxy_udp_inbound.uplink
+          id: "udp.uplink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.http_inbound.uplink
+          id: "http.uplink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.https_inbound.uplink
+          id: "https.uplink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.inbound.socks_inbound.uplink
+          id: "socks.uplink"
+          algorithm: incremental
+          expvar_type: int
+    - id: "outbounds"
+      options:
+        name: "outbounds"
+        title: "Xray System Outbounds"
+        units: bytes
+        family: xray
+        context: xray.outbounds
+        chart_type: line
+      lines:
+        - expvar_key: stats.outbound.tcp_outbound.downlink
+          id: "tcp.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.outbound.udp_outbound.downlink
+          id: "udp.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.outbound.direct.downlink
+          id: "direct.downlink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.outbound.tcp_outbound.uplink
+          id: "tcp.uplink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.outbound.udp_outbound.uplink
+          id: "udp.uplink"
+          algorithm: incremental
+          expvar_type: int
+        - expvar_key: stats.outbound.direct.uplink
+          id: "direct.uplink"
+          algorithm: incremental
+          expvar_type: int
+    - id: "observatory"
+      options:
+        name: "observatory"
+        title: "Xray Observatory Metrics"
+        units: milliseconds
+        family: xray
+        context: xray.observatory
+        chart_type: line
+      lines:
+        - expvar_key: observatory.tcp_outbound.delay
+          id: tcp
+          expvar_type: int
+        - expvar_key: observatory.udp_outbound.delay
+          id: udp
+          expvar_type: int
+```
+
+</details>
+
+You can get results similar to this:
+
+![160428235-2988bf69-5d6c-41ec-8267-1bd512508aa8](https://github.com/chika0801/Xray-docs-next/assets/88967758/455e88ce-ced2-4593-a9fa-425bb293215b)

package/data/docs/basic__observatory.md

@@ -0,0 +1,115 @@
+---
+url: https://xtls.github.io/en/config/observatory.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/observatory.md
+title: Observatory
+category: basic
+slug: observatory
+fetched_at: 2026-05-04T18:42:44.122Z
+---
+# Observatory
+
+The Observatory component uses HTTPing to probe the connection status of outbound proxies. The observation results can be used by other components, such as the Load Balancer. Currently, there are two types: [observatory](#observatoryobject) (Background Connection Observatory) and [burstObservatory](#burstobservatoryobject) (Burst Connection Observatory). Choose one according to your needs.
+
+## ObservatoryObject
+
+```json
+{
+  "subjectSelector": ["outbound"],
+  "probeUrl": "https://www.google.com/generate_204",
+  "probeInterval": "10s",
+  "enableConcurrency": false
+}
+```
+
+> `subjectSelector`: \[ string \]
+
+An array of strings, where each string is used for prefix matching against outbound proxy tags. Given the following outbound proxy tags: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` will match `[ "a", "ab" ]`.
+
+> `probeUrl`: string
+
+The URL used to probe the connection status of the outbound proxy.
+
+> `probeInterval`: string
+
+The interval for initiating probes. The time format is number + unit, such as `"10s"`, `"2h45m"`. Supported time units are `ns`, `us`, `ms`, `s`, `m`, `h`, corresponding to nanoseconds, microseconds, milliseconds, seconds, minutes, and hours respectively.
+
+Note that since the request interval is fixed, periodic fixed requests might lead to behavioral fingerprinting. Using protocols with multiplexing or enabling `mux` can alleviate this issue.
+
+> `enableConcurrency`: true | false
+
+- `true`: Probe all matched outbound proxies concurrently. Pauses for the time set in `probeInterval` after all are completed.
+- `false`: Probe matched outbound proxies one by one. Pauses for the time set in `probeInterval` after each outbound proxy is probed.
+
+## BurstObservatoryObject
+
+```json
+{
+  "subjectSelector": ["outbound"],
+  "pingConfig": {}
+}
+```
+
+> `subjectSelector`: \[ string \]
+
+An array of strings, where each string is used for prefix matching against outbound proxy tags. Given the following outbound proxy tags: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` will match `[ "a", "ab" ]`.
+
+> `pingConfig`: [PingConfigObject](#pingconfigobject)
+
+### PingConfigObject
+
+```json
+{
+  // For each outbound, probe 10 times within 10 minutes; specific probe times are random.
+  // If they all fail, it will be marked as a faulty node within 10 ~ 20 minutes.
+  // After failure, a single successful probe will mark it as a healthy node; at slowest, it takes 10 minutes.
+  "destination": "https://connectivitycheck.gstatic.com/generate_204",
+  "connectivity": "",
+  "interval": "1m",
+  "sampling": 10,
+  "timeout": "5s",
+  "httpMethod": "HEAD"
+}
+```
+
+> `destination`: string
+
+The URL used to probe the connection status of the outbound proxy. This URL should return an HTTP 204 success status code.
+Default `"https://connectivitycheck.gstatic.com/generate_204"`.
+
+> `connectivity`: string
+
+The URL used to check local network connectivity. This URL should return an HTTP 204 success status code.
+
+An empty string indicates no local network connectivity check.
+
+This probe is executed only when the `destination` probe fails. This makes the cause of network failure clearer in the logs.
+
+Note: In transparent proxy mode, this request might be captured by the transparent proxy and re-enter Xray for routing (depending on your configuration). You need to use extra means to ensure it is not captured by the transparent proxy, such as bypassing based on the URL IP, or using cgroup/pid routing to completely prevent Xray's requests from being captured. Alternatively, you can choose a URL that matches a direct connection rule and allow this request to be captured by the transparent proxy.
+
+> `interval`: string
+
+The expected **average** probe interval for each outbound proxy.
+
+The time format is number + unit, such as `"10s"`, `"2h45m"`. Supported time units are `ns`, `us`, `ms`, `s`, `m`, `h`, corresponding to nanoseconds, microseconds, milliseconds, seconds, minutes, and hours respectively.
+Default `"1m"`. Minimum allowed value is `"10s"`. If less is specified, `"10s"` will be used.
+
+> `sampling`: number
+
+The number of recent probe results to keep.
+Default `10`.
+
+> `timeout`: string
+
+Probe timeout. Format is the same as `interval` above.
+Default `"5s"`.
+
+> `httpMethod`: string
+
+The HTTP method used for probing (e.g. `"HEAD"`, `"GET"`).
+Default `"HEAD"`.
+
+::: tip
+The working principle of Burst Observatory is to immediately schedule probe tasks for each matched outbound at every `interval` \* `sampling` (hereinafter referred to as the probe cycle). However, within each task's cycle, the probe is executed at a random time. This means compared to `observatory` (Background Connection Observatory), the fingerprint of this detector is less obvious. But if `interval` is set too small, or `sampling` is too large causing frequent probing, the fingerprint will be more obvious.
+
+`interval` and `sampling` jointly affect the sensitivity of failover and recovery. When a node fails probes continuously, it takes at fastest 1 probe cycle to mark the node as faulty, and at slowest 2 probe cycles. Recovering from failure requires one successful probe, which depends on the probe density; at slowest, it takes 1 probe cycle.
+:::

package/data/docs/basic__outbound.md

@@ -0,0 +1,164 @@
+---
+url: https://xtls.github.io/en/config/outbound.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/outbound.md
+title: Outbound Proxy (Mux, XUDP)
+category: basic
+slug: outbound
+fetched_at: 2026-05-04T18:42:40.576Z
+---
+# Outbound Proxy (Mux, XUDP)
+
+Outbound connections are used to send data. For available protocols, please see [Outbound Protocols](./outbounds/).
+
+## OutboundObject
+
+`OutboundObject` corresponds to a sub-element of the `outbounds` item in the configuration file.
+
+::: tip
+The first element in the list serves as the primary outbound. When a routing match does not exist or fails, traffic is sent via the primary outbound.
+:::
+
+```json
+{
+  "outbounds": [
+    {
+      "sendThrough": "0.0.0.0",
+      "protocol": "protocol_name",
+      "settings": {},
+      "tag": "identifier",
+      "streamSettings": {},
+      "proxySettings": {
+        "tag": "another-outbound-tag",
+        "transportLayer": false
+      },
+      "mux": {},
+      "targetStrategy": "AsIs"
+    }
+  ]
+}
+```
+
+> `sendThrough`: address
+
+The IP address used to send data. This is effective when the host has multiple IP addresses. The default value is `"0.0.0.0"`.
+
+You can enter an IPv6 CIDR block (e.g., `114:514:1919:810::/64`), and Xray will use a random IP address from the address block to initiate external connections.
+You need to correctly configure the network access method, routing table, and kernel parameters to allow Xray to bind to any IP within the address block.
+
+For networks using NDP access, it is not recommended to set a subnet smaller than `/120`. Otherwise, it may cause issues such as NDP flooding, leading to the router's neighbor cache becoming full.
+
+Special value `origin`: If this value is used, the request will be sent using the IP address of the local machine that received the connection.
+
+For example, if the machine has a full IPv4 range `11.4.5.0/24` and listens on `0.0.0.0` (all IPv4 and IPv6 on the network interface), if a client connects to the local machine via `11.4.5.14`, the outbound request will also be sent via `11.4.5.14`. If the client connects via `11.4.5.10`, the outbound request will be sent via `11.4.5.10`. This also applies to cases where the machine has a full range/multiple IPv6 addresses.
+
+As mentioned in the inbound introduction, because of the connectionless nature of UDP, Xray cannot know the original destination IP where the request entered the core (for example, in the same QUIC connection, it might even change), so this feature cannot take effect for UDP.
+
+> `protocol`: "blackhole" | "dns" | "freedom" | "http" | "loopback" | "shadowsocks" | "socks" | "trojan" | "vless" | "vmess" | "hysteria" | "wireguard"
+
+The connection protocol name. For the list of optional protocols, see [Outbound Protocols](./outbounds/) on the left.
+
+> `settings`: OutboundConfigurationObject
+
+Specific configuration content, which varies by protocol. See `OutboundConfigurationObject` in each protocol for details.
+
+> `tag`: string
+
+The identifier for this outbound connection, used to locate this connection in other configurations.
+
+::: danger
+When not empty, its value must be **unique** among all `tag`s.
+:::
+
+> `streamSettings`: [StreamSettingsObject](./transport.md#streamsettingsobject)
+
+The underlying transport method is the way the current Xray node connects with other nodes.
+
+> `proxySettings`: [ProxySettingsObject](#proxysettingsobject)
+
+Outbound proxy configuration.
+
+> `mux`: [MuxObject](#muxobject)
+
+Specific configuration related to Mux.
+
+> `targetStrategy`: "AsIs" | "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4" | "ForceIP" | "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4"
+
+If this outbound attempts to send a domain request, this controls whether it is resolved/how it is resolved to an IP before sending.
+
+The default value is `AsIs`, meaning it is sent to the remote server as is. All parameter meanings are roughly equivalent to `domainStrategy` in [sockopt](./transport.md#sockoptobject).
+
+::: tip
+This controls **proxied requests**. If the address of the outbound proxy server is a domain name, and you need to select a resolution strategy for the domain name itself, you should configure `domainStrategy` in [sockopt](./transport.md#sockoptobject).
+:::
+
+### ProxySettingsObject
+
+```json
+{
+  "tag": "another-outbound-tag",
+  "transportLayer": false
+}
+```
+
+> `tag`: string
+
+When the identifier of another outbound is specified, data sent by this outbound will be forwarded to the specified outbound for transmission.
+
+::: danger
+This option conflicts with [SockOpt.dialerProxy](./transport.md#sockoptobject). Choose one as needed.
+
+By default, this forwarding method **does not go through** the underlying transport method (REALITY/XHTTP/gRPC...), meaning the `streamSettings` of this outbound will not take effect.<br>
+If you need forwarding that supports underlying transport methods, please use `SockOpt.dialerProxy` instead or set `transportLayer` to `true`.
+:::
+
+> `transportLayer`: true | false
+
+`true` converts this setting to `SockOpt.dialerProxy` to support forwarding via underlying transport methods. The default is `false`, meaning no conversion.
+
+### MuxObject
+
+The Mux function distributes data from multiple TCP connections over a single TCP connection. For implementation details, see [Mux.Cool](../development/protocols/muxcool.md). Mux is designed to reduce TCP handshake latency, not to increase connection throughput. Using Mux for watching videos, downloading, or speed testing usually has a negative effect. Mux only needs to be enabled on the client side; the server side adapts automatically. The second use of Mux is to distribute multiple UDP connections, i.e., XUDP.
+
+`MuxObject` corresponds to the `mux` item in `OutboundObject`.
+
+```json
+{
+  "enabled": true,
+  "concurrency": 8,
+  "xudpConcurrency": 16,
+  "xudpProxyUDP443": "reject"
+}
+```
+
+> `enabled`: true | false
+
+Whether to enable Mux for forwarding requests. Default is `false`.
+
+> `concurrency`: number
+
+Maximum concurrent connections. Minimum `1`, maximum `128`. If omitted or set to `0`, it equals `8`. Values greater than `128` are treated as 128, because once a connection reaches the maximum reuse count of 128, it will no longer be assigned any new sub-connections.
+
+This value represents the maximum number of sub-connections carried on a single TCP connection. For example, if `concurrency=8` is set, when the client issues 8 TCP requests, Xray will only issue one actual TCP connection, and all 8 requests from the client are transmitted over this TCP connection.
+
+When the maximum sub-connection capacity of all Mux connections is fully occupied, the core will initiate new connections to carry sub-connections. If a large number of sub-connections are concurrent in a short time and subsequently decrease, the internal scheduler of the core will tend to distribute requests to 2 connections alternately and leave other connections idle, waiting for all their sub-connections to end naturally before closing them to save resources. If the total number of sub-connections continues to be lower than `concurrency` for a long time, after one of the connections reaches the maximum reuse count, the core will revert to a single connection state.
+
+::: tip
+When set to a negative number, such as `-1`, the Mux module is not used to carry TCP traffic.
+:::
+
+> `xudpConcurrency`: number
+
+Use a new XUDP aggregation tunnel (i.e., another Mux connection) to proxy UDP traffic. Fill in the maximum number of concurrent sub-UoT. Minimum `1`, maximum `1024`.
+If omitted or set to `0`, it will follow the same path as TCP traffic, which is the traditional behavior.
+
+::: tip
+When set to a negative number, such as `-1`, the Mux module is not used to carry UDP traffic. The proxy protocol's original UDP transmission method will be used. For example, `Shadowsocks` will use native UDP, and `VLESS` will use UoT.
+:::
+
+> `xudpProxyUDP443`: string
+
+Controls how Mux handles proxied UDP/443 (QUIC) traffic:
+
+- Default `reject`: Rejects traffic (browsers typically fall back to TCP HTTP2 automatically).
+- `allow`: Allows traffic to go through the Mux connection.
+- `skip`: Does not use the Mux module to carry UDP 443 traffic. The proxy protocol's original UDP transmission method will be used. For example, `Shadowsocks` will use native UDP, and `VLESS` will use UoT.

package/data/docs/basic__policy.md

@@ -0,0 +1,140 @@
+---
+url: https://xtls.github.io/en/config/policy.html
+source_url: https://raw.githubusercontent.com/XTLS/Xray-docs-next/main/docs/en/config/policy.md
+title: Local Policy
+category: basic
+slug: policy
+fetched_at: 2026-05-04T18:42:41.083Z
+---
+# Local Policy
+
+Local policy allows setting different user levels and corresponding policy settings, such as connection timeout settings. Every connection processed by Xray corresponds to a user, and different policies are applied according to the user's level.
+
+## PolicyObject
+
+`PolicyObject` corresponds to the `policy` item in the configuration file.
+
+```json
+{
+  "policy": {
+    "levels": {
+      "0": {
+        "handshake": 4,
+        "connIdle": 300,
+        "uplinkOnly": 2,
+        "downlinkOnly": 5,
+        "statsUserUplink": false,
+        "statsUserDownlink": false,
+        "statsUserOnline": false,
+        "bufferSize": 4
+      }
+    },
+    "system": {
+      "statsInboundUplink": false,
+      "statsInboundDownlink": false,
+      "statsOutboundUplink": false,
+      "statsOutboundDownlink": false
+    }
+  }
+}
+```
+
+> `level`: map{string: [LevelPolicyObject](#levelpolicyobject)}
+
+A set of key-value pairs, where each key is a number in string format (required by JSON), such as `"0"`, `"1"`, etc. The double quotes cannot be omitted. This number corresponds to the user level. Each value is a [LevelPolicyObject](#levelpolicyobject).
+
+::: tip
+Each inbound and outbound proxy can now set a user level. Xray will apply different local policies based on the actual user level.
+:::
+
+> `system`: [SystemPolicyObject](#systempolicyobject)
+
+Xray system-level policies.
+
+### LevelPolicyObject
+
+```json
+{
+  "handshake": 4,
+  "connIdle": 300,
+  "uplinkOnly": 2,
+  "downlinkOnly": 5,
+  "statsUserUplink": false,
+  "statsUserDownlink": false,
+  "bufferSize": 10240
+}
+```
+
+> `handshake`: number
+
+Handshake time limit when establishing a connection. Unit is seconds. Default value is `4`. When an inbound proxy processes a new connection, if the time used during the handshake phase exceeds this time, the connection is interrupted.
+
+> `connIdle`: number
+
+Connection idle time limit. Unit is seconds. Default value is `300`. When an inbound/outbound processes a connection, if no data is transferred (including uplink and downlink data) within the `connIdle` time, the connection is interrupted.
+
+> `uplinkOnly`: number
+
+Time limit after the downlink connection is closed. Unit is seconds. Default value is `2`. When the server (such as a remote website) closes the downlink connection, the outbound proxy will interrupt the connection after waiting for the `uplinkOnly` time.
+
+> `downlinkOnly`: number
+
+Time limit after the uplink connection is closed. Unit is seconds. Default value is `5`. When the client (such as a browser) closes the uplink connection, the inbound proxy will interrupt the connection after waiting for the `downlinkOnly` time.
+
+::: tip
+In HTTP browsing scenarios, `uplinkOnly` and `downlinkOnly` can be set to `0` to improve connection closing efficiency.
+:::
+
+> `statsUserUplink`: true | false
+
+When set to `true`, enables uplink traffic statistics for all users of the current level.
+
+> `statsUserDownlink`: true | false
+
+When set to `true`, enables downlink traffic statistics for all users of the current level.
+
+> `statsUserOnline`: true | false
+> When set to `true`, enables online user count statistics for all users of the current level. (Online criteria: connection activity within 20 seconds).
+
+> `bufferSize`: number
+
+The internal buffer size for each request, in KB. Note that multiple requests may be carried on the same connection via multiplexing (e.g., when using mux.cool or gRPC). This means that even if they share an underlying connection, their buffer pools are independent.
+
+When the internal buffer is larger than this value, the next write operation will only be performed after the internal buffer is sent out until it is less than or equal to this value.
+
+Note that for a UDP request, if a write attempt is made while the buffer is full, the write operation will not be blocked but **discarded**. If set too low or to 0, it may cause unexpected bandwidth waste.
+
+Default values:
+
+- On ARM, MIPS, MIPSLE platforms, the default value is `0`.
+- On ARM64, MIPS64, MIPS64LE platforms, the default value is `4`.
+- On other platforms, the default value is `512`.
+
+The default value can be set via the environment variable `XRAY_RAY_BUFFER_SIZE`. Note that the unit in the environment variable is MB (setting the environment variable to 1 is equivalent to setting the config to 1024).
+
+### SystemPolicyObject
+
+```json
+{
+  "statsInboundUplink": false,
+  "statsInboundDownlink": false,
+  "statsOutboundUplink": false,
+  "statsOutboundDownlink": false
+}
+```
+
+> `statsInboundUplink`: true | false
+
+When set to `true`, enables uplink traffic statistics for all inbound proxies.
+
+> `statsInboundDownlink`: true | false
+
+When set to `true`, enables downlink traffic statistics for all inbound proxies.
+
+> `statsOutboundUplink`: true | false
+
+When set to `true`, enables uplink traffic statistics for all outbound proxies.
+
+> `statsOutboundDownlink`: true | false
+
+When set to `true`, enables downlink traffic statistics for all outbound proxies.