-When the `"queryStrategy"` value in the child item conflicts with the global `"queryStrategy"` value, the query for the child item will respond null. +::: tip TIP 1 +The global `"queryStrategy"` value takes precedence. When the `"queryStrategy"` value in a sub-item conflicts with the global `"queryStrategy"` value, the query for that sub-item will return an empty response. +::: + +::: tip TIP 2 +When the `"queryStrategy"` parameter is not written in a sub-item, the global `"queryStrategy"` parameter value is used. This behavior is the same as versions prior to Xray-core v1.8.6. +::: + +For example:
+Global `"queryStrategy": "UseIPv6"` conflicts with sub-item `"queryStrategy": "UseIPv4"`.
+Global `"queryStrategy": "UseIPv4"` conflicts with sub-item `"queryStrategy": "UseIPv6"`.
+Global `"queryStrategy": "UseIP"` does not conflict with sub-item `"queryStrategy": "UseIPv6"`.
+Global `"queryStrategy": "UseIP"` does not conflict with sub-item `"queryStrategy": "UseIPv4"`. ```json "dns": { "servers": [ - "https://1.1.1.1/dns-query", + "[https://1.1.1.1/dns-query](https://1.1.1.1/dns-query)", { - "address": "https://8.8.8.8/dns-query", + "address": "[https://8.8.8.8/dns-query](https://8.8.8.8/dns-query)", "domains": [ "geosite:netflix" ], "skipFallback": true, - "queryStrategy": "UseIPv6" // "UseIPv6" conflicts with "UseIPv4". + "queryStrategy": "UseIPv6" // Global "UseIPv4" conflicts with sub-item "UseIPv6" } ], "queryStrategy": "UseIPv4" } ``` -Subterm geosite:netflix query gets null response due to conflicting `"queryStrategy"` values. geosite:netflix domain is queried by global DNS `https://1.1.1.1/dns-query` and gets A record. +The sub-item query for the Netflix domain returns an empty response due to the conflicting `"queryStrategy"` value. The Netflix domain is then queried by `https://1.1.1.1/dns-query`, returning an A record. > `disableCache`: true | false -`true` disables DNS caching for all DNS servers, default is `false` which means caching is not disabled. +`true` disables DNS caching. Defaults to `false` (not disabled). -this option has no effect on `localhost` DNS and `localhost` DNS always use system DNS cache. +This does not affect `localhost` DNS (system DNS), which always follows Golang's DNS caching behavior (cgo and pure go may differ slightly). + +> `serveStale`: true | false + +`true` enables DNS optimistic caching. Defaults to `false` (not enabled). + +Only effective when the server has DNS caching enabled (i.e., this option is constrained by `disableCache`). + +> `serveExpiredTTL`: number + +Validity period for optimistic caching in seconds. Defaults to 0, meaning it never expires. + +If the server has caching enabled and optimistic caching is turned on: when the cache has expired but the optimistic cache has not, the stale DNS record in the cache is returned immediately, and the cache is refreshed in the background. This can reduce latency. > `disableFallback`: true | false -`true` disables fallback DNS queries, default is `false` which means fallback queries are not disabled. +`true` disables DNS fallback queries. Defaults to `false` (not disabled). > `disableFallbackIfMatch`: true | false -`true` disables fallback DNS queries when the matching domain list of the DNS server is hit, default is `false` which means fallback queries are not disabled. +`true` disables fallback queries when the DNS server's priority domain list is matched. Defaults to `false` (not disabled). + +> `enableParallelQuery`: true | false + +`true` enables parallel queries. Defaults to `false` (not enabled). + +DNS failover is serial by default, meaning a query is sent to the next server only after the selected DNS server fails or `expectedIPs` and `unexpectedIPs` do not match. + +When parallel query is enabled, queries are initiated asynchronously to all selected DNS servers in advance, executing a strategy of "dynamic grouping, intra-group racing, and inter-group fallback". + +**Dynamic Grouping**: Adjacent servers in the selected server list are considered the same group if their `clientIP`, `skipFallback`, `queryStrategy`, `tag`, `domains`, `expectedIPs`, and `unexpectedIPs` are **exactly** the same. + +**Intra-group Racing**: If any DNS server in the same group queries successfully and the IP matches `expectedIPs` and `unexpectedIPs`, the group is considered successful, and results from other servers in the group are ignored. + +**Inter-group Fallback**: If the first group is still querying, wait. If the first group succeeds, return the IP. If all servers in the first group fail or IPs do not match, fallback to the next group. Finally, if all groups fail, return an empty resolution. > `useSystemHosts`: true | false -if true, system-hosts appends to config-hosts at start, default is false. +If true, appends the system hosts file to the built-in DNS hosts. > `tag`: string -Traffic generated by built-in DNS, except for `localhost`, `fakedns`, `TCPL`, `DOHL`, and `DOQL` modes, can be matched with `inboundTag` in routing using this identifier. +For query traffic generated by the built-in DNS, except for `localhost`, `fakedns`, `TCPL`, `DOHL`, and `DOQL` modes, this tag can be used in routing for matching via `inboundTag`. ### DnsServerObject @@ -229,86 +265,94 @@ Traffic generated by built-in DNS, except for `localhost`, `fakedns`, `TCPL`, `D "expectedIPs": ["geoip:cn"], "unexpectedIPs": ["geoip:cloudflare"], "skipFallback": false, + "finalQuery": false, + "tag": "dns-tag", "clientIP": "1.2.3.4", "queryStrategy": "UseIPv4", - "tag": "server-1", - "timeoutMs": 4000, - "disableCache": false, - "finalQuery": false + "disableCache": false } ``` > `address`: address -A list of DNS servers, which can be either DNS addresses (in string form) or DnsServerObjects. +A list of DNS servers. Two types are supported: DNS address (string format) and DnsServerObject. -When the value is `"localhost"`, it means using the local DNS configuration. +When the value is `"localhost"`, it indicates using the local machine's preset DNS configuration. -When the value is a DNS `"IP"` address, such as `"8.8.8.8"`, Xray will use the specified UDP port of this address for DNS queries. The query follows routing rules. By default, port 53 is used. +When the value is a DNS `"IP"` address, such as `"8.8.8.8"`, Xray will use the specified UDP port of this address for DNS queries. The query follows routing rules. Defaults to port 53. -When the value is in the form of `"tcp://host"`, such as `"tcp://8.8.8.8"`, Xray will use `DNS over TCP` for the query. The query follows routing rules. By default, port 53 is used. +When the value is in the form of `"tcp://host"`, such as `"tcp://8.8.8.8"`, Xray will use `DNS over TCP` for queries. The query follows routing rules. Defaults to port 53. -When the value is in the form of `"tcp+local://host"`, such as `"tcp+local://8.8.8.8"`, Xray will use `TCP local mode (TCPL)` for the query. That is, the DNS request will not go through the routing component and will be sent directly through the Freedom outbound to reduce latency. When no port is specified, port 53 is used by default. +When the value is in the form of `"tcp+local://host"`, such as `"tcp+local://8.8.8.8"`, Xray will use `TCP Local Mode (TCPL)` for queries. This means the DNS request will **not** pass through the routing component but will request directly via the Freedom outbound to reduce latency. If no port is specified, port 53 is used by default. -When the value is in the form of `"https://host:port/dns-query"`, such as `"https://dns.google/dns-query"`, Xray will use `DNS over HTTPS` (RFC8484, abbreviated as DOH) for the query. Some service providers have IP alias certificates, which can be directly written in IP form, such as `https://1.1.1.1/dns-query`. Non-standard ports and paths can also be used, such as `"https://a.b.c.d:8443/my-dns-query"`. +When the value is in the form of `"https://host:port/dns-query"`, such as `"https://dns.google/dns-query"`, Xray will use `DNS over HTTPS` (RFC8484, abbreviated as DOH) for queries. Some providers have certificates for IP aliases, so you can write the IP directly, such as `https://1.1.1.1/dns-query`. Non-standard ports and paths can also be used, such as `"https://a.b.c.d:8443/my-dns-query"`. -When the value is in the form of `"https+local://host:port/dns-query"`, such as `"https+local://dns.google/dns-query"`, Xray will use `DOH local mode (DOHL)` for the query, which means that the DOH request will not go through the routing component and will be sent directly through the Freedom outbound to reduce latency. This is generally suitable for server-side use. Non-standard ports and paths can also be used. +When the value is in the form of `"https+local://host:port/dns-query"`, such as `"https+local://dns.google/dns-query"`, Xray will use `DOH Local Mode (DOHL)` for queries. This means the DOH request will **not** pass through the routing component but will request directly via the Freedom outbound to reduce latency. Generally suitable for server-side use. Non-standard ports and paths can also be used. -When the value is in the form of `"quic+local://host:port"`, such as `"quic+local://dns.adguard.com"`, Xray will use `DOQ local mode (DOQL)` for the query, which means that the DNS request will not go through the routing component and will be sent directly through the Freedom outbound. This method requires DNS server support for DNS over QUIC. By default, port 853 is used for the query, and non-standard ports can be used. +When the value is in the form of `"quic+local://host:port"`, such as `"quic+local://dns.adguard.com"`, Xray will use `DOQ Local Mode (DOQL)` for queries. This means the DNS request will **not** pass through the routing component but will request directly via the Freedom outbound. This method requires the DNS server to support DNS over QUIC. By default, port 853 is used for queries, and non-standard ports can be used. -When the value is `fakedns`, FakeDNS functionality will be used for the query. +When the value is `fakedns`, the FakeDNS feature will be used for queries. + +::: tip About Local Mode and the Domain of the DNS Server Itself +There are two scenarios for DNS requests sent by the DNS module: + +**Local Mode** connections are made directly outwards by the core. In this case, if the address is a domain name, it will be resolved by the system itself. The logic is relatively simple. + +**Non-Local** modes will essentially be treated as requests coming from an inbound with the tag `dns.tag` (Don't know where it is? Ctrl+F in your browser to search for `inboundTag`). They will go through the normal core processing flow and may be assigned by the routing module to a local freedom or other remote outbounds. They will be resolved by the freedom's `domainStrategy` (beware of potential loops) or sent directly as domains to the remote end to be resolved according to the server's own resolution method. + +Since it might be difficult for average users to clarify the logic involved, it is recommended (especially in a transparent proxy environment) to **directly set the corresponding IPs for servers with domain names in the host option of the DNS module** to prevent loops. + +Incidentally, DNS requests sent by the DNS module in non-local modes will automatically skip the `IPIfNonMatch` and `IPOnDemand` resolution processes in the routing module. This prevents their resolution from being sent back to the DNS module, causing a loop. +::: > `port`: number -The port number of the DNS server, such as `53`. If not specified, the default is `53`. This item is not applicable when using DOH, DOHL, or DOQL modes, and non-standard ports should be specified in the URL. +DNS server port, e.g., `53`. Defaults to `53` if omitted. This item is invalid when using DOH, DOHL, or DOQL modes; non-standard ports should be specified in the URL. -> `domains`: [string] +> `domains`: \[string\] -A list of domain names. The domain names in this list will be queried using this server first. The format of domain names is the same as in [routing configuration](./routing.md#ruleobject). +A list of domains. Domains included in this list will prioritize using this server for queries. The domain format is the same as in [Routing Configuration](./routing.md#ruleobject). -> `expectedIPs`: [string] +> `expectedIPs`:\[string\] -A list of IP ranges in the same format as in [routing configuration](./routing.md#ruleobject). +A list of IP ranges. The format is the same as in [Routing Configuration](./routing.md#ruleobject). -When this item is configured, Xray DNS will verify the returned IP addresses and only return addresses that are included in the `expectedIPs` list. +When configured, Xray DNS will verify the returned IP and only return addresses included in the `expectedIPs` list. -If this item is not configured, the IP address will be returned as is. - -if you add "\*" in this list, the original-IPs still returned if no IP matched. +If `*` exists in the list, and if no IP exists after filtering, the original IP is still returned so that the request does not fail. > `unexpectedIPs`: [string] -reverse of `expectedIPs`, an IP is matched if and only if does not match any of the IP-ranges in the list, in other words: -`expectedIPs = [0.0.0.0/0, ::/0] - unexpectedIPs.` - -if you add "\*" in this list, the original-IPs still returned if no IP matched. +The reverse version of `expectedIPs`. IPs included in this list are removed. The asterisk works the same way. > `skipFallback`: true | false -`true` means to skip this server when performing DNS fallback queries, and the default is `false`, which means not to skip. - -> `finalQuery`: true | false - -if true, the query result is returned in any case(even when IP-list is empty) and no other fallback will be performed. - -> `disableCache`: true | false - -if true, the cache is disabled only for this DNS server. - -this option has no effect on `localhost` DNS and `localhost` DNS always use system DNS cache. +`true`: Skip this server during DNS fallback queries. Defaults to `false` (not skipped). > `timeoutMs`: number -DNS server timeout, default 4000 ms. +DNS server timeout in milliseconds. Default is 4000 ms. -this option has no effect on `localhost` DNS and `localhost` DNS always use system DNS timeout. +This does not affect `localhost` DNS (system DNS), which always follows Golang's DNS timeout behavior (cgo and pure go may differ slightly). -> `tag`: string +> `finalQuery`: true | false -The tag of this DNS server. If set, it will use this tag as the inbound tag to initiate the request (non-local mode), overwriting the global tag option. +If set to true, the request to this DNS server will be the final attempt and will not trigger fallback behavior. > `queryStrategy`: "UseIP" | "UseIPv4" | "UseIPv6" | "UseSystem" -`UseIPv4` only queries A records; `UseIPv6` only queries AAAA records. The default value is `UseIP`, which queries both A and AAAA records. +If not specified, it inherits from the global configuration; if specified, it allows further limiting the capabilities of this server and setting the default value for IP query types initiated by Xray itself. -`UseSystem`, every time dns-Query call, it check the system-network to see if it supports IPv6(and IPv4) or not, if it support IPv6(or IPv4), the IPv6(or IPv4) is also returned, otherwise not returned. +Note: It is always constrained by the global `queryStrategy`. + +### The following configuration items, if not specified, will inherit from the global configuration, or can override the global configuration here + +> `tag`: string + +> `clientIP`: [string] + +> `disableCache`: true | false + +> `serveStale`: true | false + +> `serveExpiredTTL`: number diff --git a/docs/en/config/fakedns.md b/docs/en/config/fakedns.md index 0cea9085..3776e73b 100644 --- a/docs/en/config/fakedns.md +++ b/docs/en/config/fakedns.md @@ -1,9 +1,9 @@ # FakeDNS -FakeDNS is used to obtain target domain names by forging DNS, which can reduce the delay in DNS queries and work with transparent proxies to obtain target domain names. +FakeDNS obtains target domain names by forging DNS responses. It can reduce latency during DNS queries and assist transparent proxies in acquiring target domain names. ::: warning -FakeDNS may contaminate the local DNS and cause "network unreachable" after Xray is closed. +FakeDNS may pollute the local DNS cache, causing "no network access" after Xray is closed. ::: ## FakeDNSObject @@ -17,7 +17,7 @@ FakeDNS may contaminate the local DNS and cause "network unreachable" after Xray } ``` -`FakeDnsObject` can also be configured as an array containing multiple FakeIP Pools. When a DNS query request is received, FakeDNS returns a group of FakeIPs obtained by multiple FakeIP Pools at the same time. +`FakeDnsObject` can also be configured as an array containing multiple FakeIP Pools. When a DNS query request is received, FakeDNS will return a set of FakeIPs derived from multiple FakeIP Pools simultaneously. ```json [ @@ -34,20 +34,20 @@ FakeDNS may contaminate the local DNS and cause "network unreachable" after Xray > `ipPool`: CIDR -FakeDNS will use the IP block specified by this option to allocate addresses. +FakeDNS will allocate addresses using the IP block specified in this option. > `poolSize`: int -Specifies the maximum number of domain name-IP mappings stored by FakeDNS. When the number of mappings exceeds this value, mappings will be eliminated according to the LRU rule. The default is 65535. +Specifies the maximum number of Domain-IP mappings stored by FakeDNS. When the number of mappings exceeds this value, mappings will be evicted according to LRU rules. Default is 65535. ::: warning -`poolSize` must be less than or equal to the total number of addresses corresponding to `ipPool`. +`poolSize` must be less than or equal to the total number of addresses in the `ipPool`. ::: ::: tip -If the `dns` item in the configuration file sets `fakedns`, but the configuration file does not set `FakeDNSObject`, Xray will initialize `FakeDNSObject` based on the `queryStrategy` of the DNS component. +If `fakedns` is set in the `dns` item of the configuration file but `FakeDnsObject` is not configured, Xray will initialize `FakeDnsObject` based on the `queryStrategy` of the DNS component. -When `queryStrategy` is set to `UseIP`, the initialized FakeIP Pool is equivalent to +When `queryStrategy` is `UseIP`, the initialized FakeIP Pool is equivalent to: ```json [ @@ -62,7 +62,7 @@ When `queryStrategy` is set to `UseIP`, the initialized FakeIP Pool is equivalen ] ``` -When `queryStrategy` is set to `UseIPv4`, the initialized FakeIP Pool is equivalent to +When `queryStrategy` is `UseIPv4`, the initialized FakeIP Pool is equivalent to: ```json { @@ -71,7 +71,7 @@ When `queryStrategy` is set to `UseIPv4`, the initialized FakeIP Pool is equival } ``` -When `queryStrategy` is set to `UseIPv6`, the initialized FakeIP Pool is equivalent to +When `queryStrategy` is `UseIPv6`, the initialized FakeIP Pool is equivalent to: ```json { @@ -84,9 +84,9 @@ When `queryStrategy` is set to `UseIPv6`, the initialized FakeIP Pool is equival ### How to use? -FakeDNS is essentially a [DNS server](./dns.md#serverobject) that can be used in conjunction with any DNS rules. +FakeDNS is essentially a [DNS Server](./dns.md#serverobject) that can be used in conjunction with any DNS rules. -Only by routing DNS queries to FakeDNS can it be effective. +It only works when DNS queries are routed to FakeDNS. ```json { @@ -105,7 +105,7 @@ Only by routing DNS queries to FakeDNS can it be effective. "routing": { "rules": [ { - "inboundTag": ["dns-in"], // Intercept DNS traffic from DNS query inbound or from inbound traffic of transparent proxies. + "inboundTag": ["dns-in"], // Hijack DNS traffic from DNS query entry points, or hijack DNS traffic from transparent proxy inbounds. "port": 53, "outboundTag": "dns-out" } @@ -114,27 +114,27 @@ Only by routing DNS queries to FakeDNS can it be effective. } ``` -When external DNS requests enter the FakeDNS component, it will return IP addresses within its own `ipPool` as the virtual resolution results of the domain name, and record the mapping relationship between the domain name and the virtual resolution results. +When an external DNS request enters the FakeDNS component, it returns an IP address within its `ipPool` as the fictitious resolution result for the domain and records the mapping between the domain and the fictitious IP. -In addition, you need to enable `Sniffing` in the **client** for incoming traffic that needs to be proxied, and use the `fakedns` target address reset. +Additionally, you need to enable `Sniffing` on the inbound of the **client** that receives traffic to be proxied, and use `fakedns` for destination address resetting. ```json "sniffing": { "enabled": true, - "destOverride": ["fakedns"], // Use "fakedns", or use it with other sniffer. - "metadataOnly": false // When this item is true, destOverride can only use fakedns. + "destOverride": ["fakedns"], // Use "fakedns", or combine with other sniffers + "metadataOnly": false // When this is true, destOverride can only use fakedns } ``` ::: warning -If the FakeIP is not correctly restored to the domain name, the server will not be accessible. +If the FakeIP is not correctly reverted to the domain name, connection to the server will fail. ::: -### Using with other types of DNS +### Using with other DNS types -#### Coexistence with DNS shunting +#### Coexisting with DNS Routing -When using DNS shunting, to give `fakedns` a higher priority, you need to add the same `domains` as other types of DNS. +When using DNS routing (traffic splitting), to ensure `fakedns` has high priority, you need to add the same `domains` to it as you would for other DNS types. ```json { @@ -142,7 +142,7 @@ When using DNS shunting, to give `fakedns` a higher priority, you need to add th { "address": "fakedns", "domains": [ - // consistent with the content used in the shunt below + // Consistent with the content used for routing below "geosite:cn", "domain:example.com" ] @@ -161,9 +161,9 @@ When using DNS shunting, to give `fakedns` a higher priority, you need to add th } ``` -#### FakeDNS blacklist +#### FakeDNS Blacklist -If you do not want certain domain names to use FakeDNS, you can add `domains` configuration in other types of DNS configurations so that when the specified domain names are matched, other DNS servers have a higher priority than FakeDNS, thereby achieving the FakeDNS blacklist mechanism. +If you do not want certain domains to use FakeDNS, you can add `domains` configuration to other types of DNS servers. This gives other DNS servers higher priority than FakeDNS when matching specific domains, thereby implementing a FakeDNS blacklist mechanism. ```json { @@ -177,9 +177,9 @@ If you do not want certain domain names to use FakeDNS, you can add `domains` co } ``` -#### FakeDNS whitelist +#### FakeDNS Whitelist -If you only want certain domain names to use FakeDNS, you can add `domains` configuration to `fakedns` so that when the specified domain names are matched, `fakedns` has a higher priority than other DNS servers, thereby achieving the FakeDNS whitelist mechanism. +If you want only certain domains to use FakeDNS, you can add `domains` configuration to `fakedns`. This gives `fakedns` higher priority than other DNS servers when matching specific domains, thereby implementing a FakeDNS whitelist mechanism. ```json { diff --git a/docs/en/config/features/browser_dialer.md b/docs/en/config/features/browser_dialer.md index afaf5a7f..989ad1dd 100644 --- a/docs/en/config/features/browser_dialer.md +++ b/docs/en/config/features/browser_dialer.md @@ -1,53 +1,53 @@ # Browser Dialer -
+If you need to troubleshoot the cause of certain problems, you can test by disabling `"sniffing"` or enabling `"routeOnly"`. +::: + +```json +"domainsExcluded": [ + "courier.push.apple.com", // iOS push notifications + "Mijia Cloud", // Mijia smart devices + "dlg.io.mi.com" +] +``` ::: warning -Currently, `domainsExcluded` does not support domain name matching in the routing sense. This option may change in the future and cross-version compatibility is not guaranteed. +Currently, `domainsExcluded` does not support the domain matching methods used in routing. This option may change in the future and cross-version compatibility is not guaranteed. ::: > `routeOnly`: true | false -Use the sniffed domain name for routing only, and keep the target address as the IP address. The default value is `false`. +Use the sniffed domain only for routing; the proxy destination address remains the IP. The default value is `false`. -This option requires `destOverride` to be enabled. +This item requires `destOverride` to be enabled to work. ::: tip -When it is possible to ensure that **the proxied connection can obtain correct DNS resolution**, by using `routeOnly` and enabling `destOverride`, and setting the routing matching strategy `domainStrategy` to `AsIs`, it is possible to achieve domain and IP separation without DNS resolution throughout the process. The IP used when encountering an IP rule match is the original IP of the domain. +When it is guaranteed that **the proxied connection can obtain correct DNS resolution**, using `routeOnly` while enabling `destOverride`, and setting the routing matching strategy `domainStrategy` to `AsIs`, allows for domain and IP traffic splitting without DNS resolution throughout the process. In this case, the IP used when matching IP rules is the original IP of the domain name. ::: - -### AllocateObject - -```json -{ - "strategy": "always", - "refresh": 5, - "concurrency": 3 -} -``` - -> `strategy`: "always" | "random" - -The port allocation strategy. - -- `"always"` means all specified ports in `port` will be allocated, and Xray will listen on these ports. -- `"random"` means ports will be randomly selected from the `port` range every `refresh` minutes, and `concurrency` ports will be listened on. - -> `refresh`: number - -The interval for refreshing randomly allocated ports in minutes. The minimum value is `2`, and it is recommended to set to `5`. This property is only effective when `strategy` is set to `"random"`. - -> `concurrency`: number - -The number of randomly allocated ports. The minimum value is `1`, and the maximum value is one-third of the `port` range. It is recommended to set to `3`. diff --git a/docs/en/config/inbounds/http.md b/docs/en/config/inbounds/http.md index 485a1e27..75319224 100644 --- a/docs/en/config/inbounds/http.md +++ b/docs/en/config/inbounds/http.md @@ -2,22 +2,22 @@ HTTP protocol. -::: warning -**The HTTP protocol does not provide encryption for transmission and is not suitable for transmission over public networks, as it can easily be used as a target for attacks.** +::: 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.** ::: -The more meaningful use of `http` inbound is to listen in a local network or on the local machine to provide local services for other programs. +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 and cannot handle protocols based on UDP. +`http proxy` can only proxy the TCP protocol; UDP-based protocols are not supported. ::: ::: tip TIP 2 -In Linux, you can use the following environment variables to enable global HTTP proxy for the current session (many software support this setting, but some may not). +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/` (Change the address to the configured inbound HTTP proxy address) +- `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 @@ -36,23 +36,23 @@ In Linux, you can use the following environment variables to enable global HTTP > `accounts`: \[[AccountObject](#accountobject)\] -An array where each element represents a user account. The default value is an empty array. +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 verification for inbound connections. +When `accounts` is not empty, the HTTP proxy will perform Basic Authentication on inbound connections. > `allowTransparent`: true | false -When set to `true`, it will forward all HTTP requests instead of just proxy requests. +When set to `true`, all HTTP requests will be forwarded, not just proxy requests. ::: tip -Enabling this option without proper configuration may cause an infinite loop. +If configured improperly, enabling this option can cause infinite loops. ::: > `userLevel`: number -The user level that the connection will use to determine the corresponding [Local Policy](../policy.md#levelpolicyobject). +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 the [policy](../policy.md#policyobject). If not specified, the default value is 0. +The value of `userLevel` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, the default is 0. ### AccountObject @@ -65,8 +65,8 @@ The value of `userLevel` corresponds to the value of `level` in the [policy](../ > `user`: string -The username. It is a string and is required. +Username, string type. Required. > `pass`: string -The password. It is a string and is required. +Password, string type. Required. diff --git a/docs/en/config/inbounds/index.md b/docs/en/config/inbounds/index.md index a06169e0..e8a0e976 100644 --- a/docs/en/config/inbounds/index.md +++ b/docs/en/config/inbounds/index.md @@ -1,4 +1,4 @@ -# Xray Inbound Protocols List +# Xray Inbound Protocols Xray supports the following inbound protocols: diff --git a/docs/en/config/inbounds/shadowsocks.md b/docs/en/config/inbounds/shadowsocks.md index d0d6dd9d..c9cccd4c 100644 --- a/docs/en/config/inbounds/shadowsocks.md +++ b/docs/en/config/inbounds/shadowsocks.md @@ -1,31 +1,30 @@ # Shadowsocks -The [Shadowsocks](https://en.wikipedia.org/wiki/Shadowsocks) protocol is compatible with most other implementations of Shadowsocks. The server supports TCP and UDP packet forwarding, with an option to selectively disable UDP. +The [Shadowsocks](https://zh.wikipedia.org/wiki/Shadowsocks) protocol, compatible with most other version implementations. -### Supported Encryption Methods - -The currently supported methods are following: +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` + - 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`/`chacha20-ietf-poly1305` - - `xchacha20-poly1305`/`xchacha20-ietf-poly1305` - - `none`/`plain` + - 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, addressing the following security issues in the old protocol: +The Shadowsocks 2022 new protocol format improves performance and includes complete replay protection, resolving the following security issues of the old protocol: -- [Serious vulnerabilities in Shadowsocks AEAD encryption, which cannot guarantee the integrity of the communication content](https://github.com/shadowsocks/shadowsocks-org/issues/183) -- Increasing false positive rate of the original TCP replay filter over time -- Lack of UDP replay protection -- TCP behaviors that can be used for active probing +- [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 -Traffic transmitted without encryption using the "none" method will be in plain text. **Do not use it on public networks** for security reasons. +Under the "none" encryption method, traffic will be transmitted in plain text. To ensure security, do not use it on public networks. ::: ## InboundConfigurationObject @@ -33,69 +32,79 @@ Traffic transmitted without encryption using the "none" method will be in plain ```json { "settings": { - "clients": [], - "password": "password", + "network": "tcp,udp", "method": "aes-256-gcm", + "password": "114514", "level": 0, "email": "love@xray.com", - "network": "tcp,udp" + "clients": [ + { + "password": "1919810", + "method": "aes-128-gcm" + } + ] } } ``` -> `clients`: a list of [`ClientObject`](#clientobject), empty list considered valid - -The `password` parameter can be specified for the server at all, but also in the [`ClientObject`](#clientobject) being dedicated to the given user. Server-level `password` is not guaranteed to override the client-specific one. - > `network`: "tcp" | "udp" | "tcp,udp" -The supported network protocol type. For example, when specified as `"tcp"`, it will only handle TCP traffic. The default value is `"tcp"`. +The network type that the server port **listens** on. The default value is `"tcp"`. + +Note that this is only for listening; it mainly affects and controls the native UDP transmission of Shadowsocks. Setting it to `"tcp"` does not mean the inbound will reject UDP proxy requests. UDP proxy requests can still be wrapped into TCP packets by Shadowsocks outbound features like UoT or mux.cool and sent to the server, and are not controlled by this option. + +> `method`: string + +Encryption method. See above for options. + +> `password`: string + +Required. + +- Shadowsocks 2022 + +Uses a pre-shared key similar to WireGuard as the password. + +Use `openssl rand -base64
-
> `peers`: \[ [Peers](#peers) \]
-List of peer servers, where each entry is a server configuration.
+List of peers, where each item is a peer configuration.
### Peers
diff --git a/docs/en/config/index.md b/docs/en/config/index.md
index 4b11bd7a..56f66666 100644
--- a/docs/en/config/index.md
+++ b/docs/en/config/index.md
@@ -1,16 +1,18 @@
---
-title: Configurations
+title: Configuration File
lang: en-US
---
-> **This section will tell you all the details of Xray configuration. By mastering these contents, Xray will unleash its full power in your hands.**
+> **This chapter will tell you all the details of Xray configuration. Mastering this content will allow you to unleash the greater power of Xray.**
## Overview
-The configuration file of Xray is in JSON format, and the configuration format for the client and server is the same, except for the actual configuration content. It takes the following form:
+The configuration file for Xray is in JSON format. There is no difference in the configuration format between the client and the server; only the actual configuration content differs.
+The format is as follows:
```json
{
+ "vsersion": {},
"log": {},
"api": {},
"dns": {},
@@ -29,85 +31,96 @@ The configuration file of Xray is in JSON format, and the configuration format f
```
::: warning
-If you are new to Xray, you can first click to view [configuration and running in the Quick Start guide](../document/install.md), to learn the most basic configuration method, and then refer to the contents of this section to master all the configuration methods of Xray.
+If you are new to Xray, you can click to view [Configuration & Run in Quick Start](../document/install.md) first to learn the most basic configuration methods, and then check the content of this chapter to master all configuration methods of Xray.
:::
-::: details Click to expand: How to make AI generate the correct configuration directly
-Copy the following prompt to ensure the AI generates the correct configuration:
+::: details Click to expand: Learn how to make AI write the correct configuration file directly
+It is recommended to copy the following content and send it to the AI, which can significantly improve the usability of the generated configuration:
```text
-[https://xtls.github.io/llms-full.txt](https://xtls.github.io/llms-full.txt) This link contains the full official documentation for Xray-core.
+[https://xtls.github.io/llms-full.txt](https://xtls.github.io/llms-full.txt) This link is the official full documentation of Xray-core.
-[Role]
-You are an expert in network protocols and Xray-core configuration.
+【Role Setting】
+You are an expert proficient in network protocols and Xray-core configuration.
-[Instructions]
-1. Knowledge Base: Crawl and fully comprehend the content of the link. Use it as your SOLE source of truth.
-2. NO Hallucinations: Absolutely DO NOT fabricate any fields not mentioned in the documentation.
-3. Default Format: While Xray supports multiple formats, please default to standard JSON output (unless I explicitly request YAML or TOML), with comments for key parameters.
-4. Error Handling: If you cannot access the link, explicitly notify me and ask me to manually download and upload the document to you.
+【Task Requirements】
+1. Knowledge Base: Please read and deeply understand the content of this link, and use it as the sole basis for answering questions and writing configurations.
+2. No Hallucinations: Absolutely do not fabricate fields that do not exist in the documentation. If the documentation does not mention it, please tell me directly "Documentation does not mention".
+3. Default Format: Although Xray supports multiple formats, please output standard JSON format configuration by default (unless I explicitly request YAML or TOML), and add key comments.
+4. Exception Handling: If you cannot access this link, please inform me clearly and prompt me to manually download the documentation and upload it to you.
+```
-Please answer my questions in English.
:::
-
-
-
## Basic Configuration Modules
+> version
+
+Optional. Controls the version on which this config can run. This prevents accidental running on unexpected client versions when sharing the config. The client will check if the current version matches this requirement at runtime.
+
+```json
+"version": {
+ "min": "25.8.3",
+ "max": ""
+}
+```
+
+Both `min` and `max` are optional. Not setting them or leaving them empty means no restrictions. It does not need to be an actual existing version, as long as it complies with the Xray version syntax x.y.z.
+
+25.8.3 is the version where Xray added this feature. Setting a version lower than this is meaningless (older versions will not check it).
+
> log:[LogObject](./log.md)
-Log configurations, controlling how Xray emits logs.
+Log configuration, controls how Xray outputs logs.
> api:[ApiObject](./api.md)
-Configures how Xray provides API interfaces for calling remotely.
+Provides some API interfaces for remote calls.
> dns: [DnsObject](./dns.md)
-Configures the built-in DNS server. System DNS will be used if not configured.
+Built-in DNS server. If this item is not configured, the system DNS settings are used.
> routing: [RoutingObject](./routing.md)
-Configures routing. Specify rules to route connections through different outbounds.
+Routing function. You can set rules to divert data to be sent out from different outbounds.
> policy: [PolicyObject](./policy.md)
-Local policy configurations, specifying different user levels and corresponding policies.
+Local policy. You can set different user levels and corresponding policy settings.
> inbounds: \[ [InboundObject](./inbound.md) \]
-An array of inbound connection configurations.
+An array. Each element is an inbound connection configuration.
> outbounds: \[ [OutboundObject](./outbound.md) \]
-An array of outbound connection configurations.
+An array. Each element is an outbound connection configuration.
> transport: [TransportObject](./transport.md)
-Configures how Xray establishes and uses network connections to other servers.
+Used to configure how Xray establishes and uses network connections with other servers.
> stats: [StatsObject](./stats.md)
-Configures traffic statistics.
+Used to configure traffic statistics.
> reverse: [ReverseObject](./reverse.md)
-Configures the built-in reverse proxy. You can forward server traffic to the client, effectively achieving reverse proxying.
+Reverse proxy. Can forward server-side traffic to the client, i.e., reverse traffic forwarding.
> fakedns: [FakeDnsObject](./fakedns.md)
-FakeDNS configuration. Can be used with a transparent proxy to obtain the actual domains.
+FakeDNS configuration. Can be used with transparent proxies to obtain the actual domain name.
> metrics: [metricsObject](./metrics.md)
-Metrics configuration. A more straightforward (and hopefully better) way to export metrics.
+Metrics configuration. A more direct (hopefully better) way to export statistics.
> observatory: [ObservatoryObject](./observatory.md#observatoryobject)
-Background connection observation. Detect the connection status of outbound proxies.
+Background connection observatory. Detects the connection status of outbound proxies.
> burstObservatory: [BurstObservatoryObject](./observatory.md#burstobservatoryobject)
-Concurrent connection observation. Detect the connection status of outbound proxies.
-```
+Burst connection observatory. Detects the connection status of outbound proxies.
diff --git a/docs/en/config/log.md b/docs/en/config/log.md
index a9678f13..04722f2c 100644
--- a/docs/en/config/log.md
+++ b/docs/en/config/log.md
@@ -2,15 +2,11 @@
Log configuration controls how Xray outputs logs.
-Xray has two types of logs: access logs and error logs. You can configure the output method for each type of log separately.
-
-::: tip
-The log configuration is not applied immediately. This means that you may see some log entries made by an unconfigured logger during startup. For example, you may see several `"info"` log entries while you have configured a `"warning"` log level.
-:::
+Xray has two types of logs: access logs and error logs. You can configure the output method for each type independently.
## LogObject
-LogObject corresponds to the `log` item in the configuration file.
+`LogObject` corresponds to the `log` entry in the configuration file.
```json
{
@@ -26,44 +22,36 @@ LogObject corresponds to the `log` item in the configuration file.
> `access`: string
-The file path for the access log. The value is a valid file path, such as `"/var/log/Xray/access.log"` (Linux) or `"C:\\Temp\\Xray\\_access.log"` (Windows). When this item is not specified or is an empty value, the log is output to stdout.
+The file path for the access log. Its value must be a valid file path, such as `"/var/log/Xray/access.log"` (Linux) or `"C:\\Temp\\Xray\\_access.log"` (Windows). When this item is unspecified or empty, logs are output to stdout.
-- The special value `none` disables access logs.
+- Special value `none`: disables the access log.
> `error`: string
-The file path for the error log. The value is a valid file path, such as `"/var/log/Xray/error.log"` (Linux) or `"C:\\Temp\\Xray\\_error.log"` (Windows). When this item is not specified or is an empty value, the log is output to stdout.
+The file path for the error log. Its value must be a valid file path, such as `"/var/log/Xray/error.log"` (Linux) or `"C:\\Temp\\Xray\\_error.log"` (Windows). When this item is unspecified or empty, logs are output to stdout.
-- The special value `none` disables error logs.
+- Special value `none`: disables the error log.
> `loglevel`: "debug" | "info" | "warning" | "error" | "none"
-The log level for error logs, indicating the information that needs to be recorded. The default value is `"warning"`. Note that this setting applies to the error log only. It doesn't affect the access log (except for `"none"` value). The access log doesn't have log levels.
+The level of the error log, indicating the information that needs to be recorded.
+The default value is `"warning"`.
-- `"debug"`: Output information used for debugging the program. Includes all `"info"` content.
-- `"info"`: Runtime status information, etc., which does not affect normal use. Includes all `"warning"` content.
-- `"warning"`: Information output when there are some problems that do not affect normal operation but may affect user experience. Includes all `"error"` content.
-- `"error"`: Xray encountered a problem that cannot be run normally and needs to be resolved immediately.
-- `"none"`: Disable all logs.
+- `"debug"`: Output information used for debugging. Includes all `"info"` content.
+- `"info"`: Runtime status information, etc., which does not affect normal usage. Includes all `"warning"` content.
+- `"warning"`: Information output when issues occur that do not affect normal operation but may impact user experience. Includes all `"error"` content.
+- `"error"`: Xray encountered a problem where it cannot operate normally and requires immediate resolution.
+- `"none"`: Do not record any content.
> `dnsLog`: bool
-Log DNS queries made by built-in [DNS clients](./dns.md) to the access log. Example log record: `DOH//doh.server got answer: domain.com -> [ip1, ip2] 2.333ms`.
-
-::: tip
-
-1. Xray doesn't perform all DNS queries via its built-in clients. Therefore, enabling this option doesn't mean that all DNS queries performed by Xray will be logged.
-
-2. DNS queries made by built-in [DNS clients](./dns.md) are also logged to the error log (with "Info" level) even if this option is disabled.
-3.
-4. FakeDNS client queries are never logged to the access log.
- :::
+Whether to enable DNS query logs, for example: `DOH//doh.server got answer: domain.com -> [ip1, ip2] 2.333ms`
> `maskAddress`: "quarter" | "half" | "full"
-IP address masking, when enabled, will automatically replace the IP address appearing in the log. It is used to protect privacy when sharing logs. The default is empty and is not enabled.
+IP address mask. When enabled, it automatically replaces IP addresses appearing in the log to protect privacy when sharing logs. The default is empty (disabled).
-Currently available levels are `quarter`, `half`, `full`. The mask form corresponds to the following:
+Currently, the available levels are `quarter`, `half`, and `full`. The masking formats correspond as follows:
- ipv4 `1.2.*.*` `1.*.*.*` `[Masked IPv4]`
- ipv6 `1234:5678::/32` `1234::/16` `[Masked IPv6]`
diff --git a/docs/en/config/metrics.md b/docs/en/config/metrics.md
index b9d42c3c..df690f78 100644
--- a/docs/en/config/metrics.md
+++ b/docs/en/config/metrics.md
@@ -1,66 +1,48 @@
# Metrics
-A more straightforward (and hopefully better) way to export metrics.
+A more direct (and hopefully better) way to export statistics.
-## Related configurations
+## Relevant Configuration
-It's possible to add a metrics inbound among inbounds.
-
-```json
- "inbounds": [
- {
- "listen": "127.0.0.1",
- "port": 11111,
- "protocol": "dokodemo-door",
- "settings": {
- "address": "127.0.0.1"
- },
- "tag": "metrics_in"
- }
- ]
-```
-
-And add routing rules regarding the metrics inbound in the routing configuration.
-
-```json
- "routing": {
- "rules": [
- {
- "inboundTag": [
- "metrics_in"
- ],
- "outboundTag": "metrics_out"
- }
- ]
- }
-```
-
-Then finally, enable metrics under the root object.
+Add `metrics` to the basic configuration:
```json
"metrics": {
- "tag": "metrics_out"
+ "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
-Access `http://127.0.0.1:11111/debug/pprof/` or use go tool pprof to start profiling or inspect running goroutines.
+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
-Access `http://127.0.0.1:11111/debug/vars`
+Visit `http://127.0.0.1:11111/debug/vars`
-Variables exported include:
+Variables included:
-- `stats` includes statistics about inbounds, outbounds and users
-- `observatory` includes observatory results
+- `stats`: Includes all inbound, outbound, and user data.
+- `observatory`: Includes observatory results.
-for example with [luci-app-xray](https://github.com/yichya/luci-app-xray) you are likely to get a result like this (standard expvar things like `cmdline` and `memstats` are omitted)
+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):
-MTU Calculation Method
+Method to Calculate MTU
-The structure of a Wireguard packet is as follows: +The structure of a WireGuard packet is as follows: ``` - 20-byte IPv4 header or 40 byte IPv6 header @@ -45,13 +44,13 @@ The structure of a Wireguard packet is as follows: - 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 values can be 1440 (IPv4) or 1420 (IPv6). If in a special environment, subtract additional bytes accordingly (e.g., subtract 8 more bytes for PPPoE over home broadband). +`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).Click to expand
+
Click to view
```json { @@ -152,14 +134,14 @@ for example with [luci-app-xray](https://github.com/yichya/luci-app-xray) you ar
Click to expand
+
Click to view
-``` +```yaml xray: name: 'xray' update_every: 2 @@ -267,12 +249,6 @@ xray:
+If you need forwarding that supports underlying transport methods, please use `SockOpt.dialerProxy` instead or set `transportLayer` to `true`. ::: -::: danger -This option is incompatible with SockOpt.dialerProxy. -::: +> `transportLayer`: true | false -::: tip -Compatible with v2fly/v2ray-core's configuration [transportLayer](https://www.v2fly.org/config/outbounds.html#proxysettingsobject). -::: +`true` converts this setting to `SockOpt.dialerProxy` to support forwarding via underlying transport methods. The default is `false`, meaning no conversion. ### MuxObject -The Mux feature distributes the data of multiple TCP connections on a single TCP connection. For implementation details, see [Mux.Cool](../development/protocols/muxcool.md). Mux is designed to reduce the latency of TCP handshake, not to increase the throughput of connections. Using Mux for watching videos, downloading, or speed testing usually has negative effects. Mux only needs to be enabled on the client side, and the server side automatically adapts. Mux has an additional function: to run multiple UDP connections, i.e. XUDP. +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": false, - "concurrency": 8 + "enabled": true, + "concurrency": 8, + "xudpConcurrency": 16, + "xudpProxyUDP443": "reject" } ``` > `enabled`: true | false -Whether to enable Mux forwarding requests, default is `false`. +Whether to enable Mux for forwarding requests. Default is `false`. > `concurrency`: number -Maximum concurrent connections. Minimum value is `1`, maximum value is `1024`. -If this parameter is omitted or equal to `0`, the value will be `8`. +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 Mux connections that can be carried on a TCP connection. For example, when `concurrency=8` is set, if the client sends 8 TCP requests, Xray will only send one actual TCP connection, and all 8 requests from the client will be transmitted through this TCP connection. +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 filling in a negative number, such as `-1`, the mux module is not loaded. +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 aggregate tunnel (that is, another Mux connection) to proxy UDP -traffic and fill in the maximum number of concurrent sub-UoTs. minimum value -`1`, the maximum value `1024`. If this parameter is omitted or equal to `0`, -UDP traffic will use the same path as TCP traffic. +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 filling in negative numbers, such as `-1`, UDP will not be transmitted via -Mux. The original UDP transmission method of the proxy protocol will be used. -For example, Shadowsocks will use native UDP, VLESS will use UoT. +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 -Control how Mux handles proxied UDP/443 (QUIC) traffic: +Controls how Mux handles proxied UDP/443 (QUIC) traffic: -- Default `reject`: Deny traffic (generaly, browsers will fall back to to TCP HTTP/2) -- `allow`: Allow connections. -- `skip`: The Mux module is not used to carry UDP 443 traffic. The original UDP - transmission method of the proxy protocol will be used. For example, - Shadowsocks will use native UDP, VLESS will use UoT. +- 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. diff --git a/docs/en/config/outbounds/blackhole.md b/docs/en/config/outbounds/blackhole.md index 57bfa086..15a73ba8 100644 --- a/docs/en/config/outbounds/blackhole.md +++ b/docs/en/config/outbounds/blackhole.md @@ -1,6 +1,6 @@ # Blackhole -Blackhole is an outbound data protocol that blocks all outbound data. When used in conjunction with [routing configurations](../routing.md), it can be used to block access to certain websites. +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 @@ -14,9 +14,10 @@ Blackhole is an outbound data protocol that blocks all outbound data. When used > `response`: [ResponseObject](#responseobject) -Configures the response data for the blackhole. +Configures the response data of the Blackhole. -After receiving the data to be forwarded, the blackhole will send the specified response data and then close the connection. The data to be forwarded will be discarded. If this field is not specified, the blackhole will simply close the connection. +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 @@ -28,6 +29,6 @@ After receiving the data to be forwarded, the blackhole will send the specified > `type`: "http" | "none" -When `type` is set to `"none"` (default value), the blackhole will simply close the connection. +When `type` is `"none"` (default value), Blackhole will close the connection immediately. -When `type` is set to `"http"`, the blackhole will send a simple HTTP 403 packet as the response and then close the connection. +When `type` is `"http"`, Blackhole will send back a simple HTTP 403 response packet, then close the connection. diff --git a/docs/en/config/outbounds/dns.md b/docs/en/config/outbounds/dns.md index af9abbb0..bbb50279 100644 --- a/docs/en/config/outbounds/dns.md +++ b/docs/en/config/outbounds/dns.md @@ -1,10 +1,10 @@ # DNS -DNS is an outbound protocol used for intercepting and forwarding DNS queries. +DNS is an outbound protocol, mainly used to intercept and forward DNS queries. -This outbound protocol can only handle DNS traffic, including queries based on UDP and TCP protocols. Other types of traffic will result in an error. +This outbound protocol can only receive DNS traffic (including queries based on UDP and TCP protocols); other types of traffic will cause errors. -When handling DNS queries, this outbound protocol will forward IP queries (A and AAAA) to the built-in [DNS server](../dns.md). Other types of query traffic will be forwarded to their original destination addresses. +When processing DNS queries, this outbound protocol forwards IP queries (i.e., A and AAAA) to the built-in [DNS server](../dns.md). For other types of query traffic, see `nonIPQuery` below. ## OutboundConfigurationObject @@ -13,24 +13,35 @@ When handling DNS queries, this outbound protocol will forward IP queries (A and "network": "tcp", "address": "1.1.1.1", "port": 53, - "nonIPQuery": "drop" + "nonIPQuery": "drop", + "blockTypes": [] } ``` > `network`: "tcp" | "udp" -Modifies the transport layer protocol for DNS traffic. The possible values are `"tcp"` and `"udp"`. When not specified, the original transport method will be retained. +Modifies the transport layer protocol for DNS traffic. Optional values are `"tcp"` and `"udp"`. When unspecified, the source transport method remains unchanged. > `address`: address -Modifies the DNS server address. When not specified, the original address specified in the source will be retained. +Modifies the DNS server address. When unspecified, the address specified in the source remains unchanged. > `port`: number -Modifies the DNS server port. When not specified, the original port specified in the source will be retained. +Modifies the DNS server port. When unspecified, the port specified in the source remains unchanged. > `nonIPQuery`: string -Control non IP queries (neither A or AAAA), `"drop"` this request or `"skip"` processing in DNS module，the request will be forwarded to target. By default is `"drop"`. +Controls non-IP queries (non-A and non-AAAA). `"drop"` means discard; `"skip"` means it is not processed by the built-in DNS server and is forwarded to the destination; `"reject"` returns a DNS reject response, explicitly refusing the request immediately. Compared to `"drop"`, this avoids applications waiting too long for a DNS response until timeout. -## DNS Configuration Example
+> "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4"
> "ForceIP" | "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4" -When the destination address is a domain name, configure the corresponding value for Freedom's behavior: +Default value `"AsIs"`. -- `"AsIs"`: Freedom resolves the domain name using the system DNS server and connects to it. -- `"UseIP"`, `"UseIPv4"`, and `"UseIPv6"`: Xray resolves the domain name using the built-in [DNS server](../dns.md) and connects to it. The default value is `"AsIs"`. -- "IPv4" means that you are trying to connect using only IPv4, "IPv4v6" means that you are trying to connect using either IPv4 or IPv6, but for dual-stack domain names, IPv4 is used. (The same applies to the v4v6 switch, so I won't go into details.) -- When using "Use"the option beginning with , if the resolution result does not meet the requirements (for example, the domain name only has IPv4 resolution results but UseIPv6 is used), it will fall back to AsIs. -- When using "Force"an option beginning with , if the parsing result does not meet the requirements, the connection cannot be established. +The meanings of all parameters are roughly equivalent to `domainStrategy` in [sockopt](../transport.md#sockoptobject). -::: warning -if we have multiple IPs and using `UseIP` or `ForceIP` only a random IP will replace the domain, for using `happyEyeballs` we should use `sockopt domainStrategy` instead. -::: +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). -::: tip TIP 1 -When using the `"UseIP"` mode and the `sendThrough` field is specified in the [outbound connection configuration](../outbound.md#outboundobject), Freedom will automatically determine the required IP type, IPv4 or IPv6, based on the value of `sendThrough`. -::: - -::: tip TIP 2 -When using the `"UseIPv4"` or `"UseIPv6"` mode, Freedom will only use the corresponding IPv4 or IPv6 address. If `sendThrough` specifies a mismatched local address, the connection will fail. -::: - -::: tip TIP 3 -When using the `"UseIP"` or `ForceIP` mode, and when network is UDP, Freedom tries to select the same IP-type as original-target-ip-type(before sniffing), to prevent MTU problems, and prevent detection by GFW. -::: +When sending UDP, Freedom ignores `domainStrategy` in `sockopt` for some reasons and forcibly prefers IPv4 by default. > `redirect`: address_port -Freedom will force all data to be sent to the specified address (instead of the address specified in the inbound). +Freedom will forcibly send all data to the specified address (instead of the address specified by the inbound). -It is a string value, for example: `"127.0.0.1:80"`, `":1234"`. +The value is a string, e.g., `"127.0.0.1:80"`, `":1234"`. -When the address is not specified, such as `":443"`, Freedom will not modify the original destination address. When the port is `0`, such as `"xray.com:0"`, Freedom will not modify the original port. +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. The connection will use the corresponding [local policy](../policy.md#levelpolicyobject) for this user level. +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 the [policy](../policy.md#policyobject). If not specified, the default value is 0. +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 key-value map used to control TCP fragmentation，under some circumstances it can cheat the censor system, like bypass a SNI blacklist. +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. -`"packets"`：support two different methods. "1-3" is for segmentation at TCP layer, applying to the beginning 1 to 3 data writes by the client. "tlshello" is for TLS client hello packet fragmentation. +`"length"` and `"interval"` are both [Int32Range](../../development/intro/guide.md#int32range) types. -`"length"`: length to make the cut +`"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. -`"interval"`: time between fragments（ms） +`"length"`: Fragment packet length (byte). -`"maxSplit"`: the maximum number of split fragments per packet, for example if we have a packet with 100-bytes size, and we set length to "1", and set maxSplit to "50", we send 49 1-bytes-packet with one 51-bytes-packet. +`"interval"`: Fragment interval (ms). -::: warning -⚠️ "noise":{} is deptecated,only "noises":[{}] is supported in 24.9.16 and later -::: +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`: [ noiseObject ] +> `noises`: array -A Array used to control UDP noise，under some circumstances it can bypass some udp based protocol restrictions. -xray will loop through this array and send each noise packet one by one +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. -`"type"`：Three types are supported. "rand" generates a random byte , "str" uses a user input string, "base64" uses a user input base64 encoded string +It is an array where multiple noise packets to be sent can be defined. A single element in the array is defined as follows: -`"packet"`：If type is set to "rand" this field will take a range "50-100" or a single value "50" +`"type"`: Noise packet type. Currently supports `"rand"` (random data), `"str"` (user-defined string), `"base64"` (base64 encoded custom binary data). -if type is set to "str" this field will take a string +`"packet"`: The content of the packet to be sent based on the preceding `type`. -if type is set to "base64" this field will take a base64 encoded string +- 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 before sending real data (ms). can be a string range like "10-20" or a single integer - -If not specified, the default value is 0. - -`"applyTo"`: three mode are supported: "ipv4"/"ipv6"/"ip", if not specified, the default value is "ip". - -if "ipv4", noise is sent only when remote address(after resolving domain to ip) is IPv4. - -if "ipv6", noise is sent only when remote address(after resolving domain to ip) is IPv6. - -if "ip", noise is always sent. +`"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 -The value of `proxyProtocol` represents the PROXY Protocol version. default value is `0`. +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). diff --git a/docs/en/config/outbounds/http.md b/docs/en/config/outbounds/http.md index 44bbc1dc..9c6cb10a 100644 --- a/docs/en/config/outbounds/http.md +++ b/docs/en/config/outbounds/http.md @@ -1,82 +1,62 @@ # HTTP -HTTP is a protocol that is used for communication over the internet. Please note that HTTP does not provide encryption for data transmission and is not suitable for transmitting sensitive information over public networks, as it can be easily targeted for attacks. +HTTP protocol. ::: danger -**The HTTP protocol does not provide encryption for transmission, making it unsuitable for transmitting over public networks and more susceptible to being used as a compromised host for attacks.** +**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 TCP protocols, and cannot handle UDP-based protocols. +`http` can only proxy the TCP protocol; UDP-based protocols cannot pass through. ::: ## OutboundConfigurationObject ```json { - "servers": [ - { - "address": "192.168.108.1", - "port": 3128, - "users": [ - { - "user": "my-username", - "pass": "my-password" - } - ] - } - ] + "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, in the HTTP outbound protocol, the `streamSettings` configuration with `security` and `tlsSettings` is effective. +Currently, `security` and `tlsSettings` in `streamSettings` are effective in the HTTP outbound protocol. ::: -> `servers`: \[ [ServerObject](#serverobject) \] - -A list of HTTP servers, where each item represents a server configuration. If multiple servers are configured, they will be used in a round-robin manner. - -### ServerObject - -```json -{ - "address": "192.168.108.1", - "port": 3128, - "users": [ - { - "user": "my-username", - "pass": "my-password" - } - ] -} -``` - > `address`: string -The address of the HTTP proxy server. Required. +HTTP proxy server address. Required. > `port`: int -The port of the HTTP proxy server. Required. - -> `user`: \[[AccountObject](#accountobject)\] - -An array of user accounts. Default value is an empty array. - -#### AccountObject - -```json -{ - "user": "my-username", - "pass": "my-password" -} -``` +HTTP proxy server port. Required. > `user`: string -The username. Required. +Username, string type. Required if the remote server requires authentication; otherwise, do not include this item. > `pass`: string -The password. Required. +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. diff --git a/docs/en/config/outbounds/hysteria.md b/docs/en/config/outbounds/hysteria.md new file mode 100644 index 00000000..7d60118e --- /dev/null +++ b/docs/en/config/outbounds/hysteria.md @@ -0,0 +1,27 @@ +# 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) in the underlying transport section. + +## 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. diff --git a/docs/en/config/outbounds/index.md b/docs/en/config/outbounds/index.md index 9ed90d6a..631008bd 100644 --- a/docs/en/config/outbounds/index.md +++ b/docs/en/config/outbounds/index.md @@ -1,4 +1,4 @@ -# Xray Outbound Protocols List +# Xray Outbound Protocols Xray supports the following outbound protocols: @@ -13,3 +13,4 @@ Xray supports the following outbound protocols: - [VLESS (XTLS Vision Seed)](vless.md) - [VMess](vmess.md) - [WireGuard](wireguard.md) +- [Hysteria](hysteria.md) diff --git a/docs/en/config/outbounds/loopback.md b/docs/en/config/outbounds/loopback.md index 1a6bf55d..792d2130 100644 --- a/docs/en/config/outbounds/loopback.md +++ b/docs/en/config/outbounds/loopback.md @@ -1,6 +1,6 @@ # Loopback -Loopback is an outbound protocol. It can send traffics through corresponding outbound to routing inbound, thus rerouting traffics to other routing rules without leaving Xray-core. +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 @@ -12,13 +12,13 @@ Loopback is an outbound protocol. It can send traffics through corresponding out > `inboundTag`: string -Use as an inbound tag for routing. +The inbound protocol identifier used for re-routing. -This tag can be used as `inboundTag` in routing rules, all traffics going through this outbound can be rerouted with routing rules with corresponding inbound tag. +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 do some more detailed routing for traffics that have been routed by routing rules, like splitting routed traffics to TCP traffics and UDP traffics and send them to different outbounds, this can be done with `loopback` outbound. +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 { @@ -27,27 +27,27 @@ If you need to do some more detailed routing for traffics that have been routed "protocol": "loopback", "tag": "need-to-split", "settings": { - "inboundTag": "traffic-input" // This tag will be used as the inboundTag inside the RuleObject + "inboundTag": "traffic-input" // This tag is used for the inboundTag of RuleObject below } }, { "tag": "tcp-output" - // protocol, settings, streamSettings etc. + // settings like protocol, settings, streamSettings }, { "tag": "udp-output" - // protocol, settings, streamSettings etc. + // settings like protocol, settings, streamSettings } ], "routing": { "rules": [ { - "inboundTag": ["traffic-input"], // tag set in the loopback outbound setting + "inboundTag": ["traffic-input"], // tag set in loopback "network": "tcp", "outboundTag": "tcp-output" }, { - "inboundTag": ["traffic-input"], // tag set in the loopback outbound + "inboundTag": ["traffic-input"], // tag set in loopback "network": "udp", "outboundTag": "udp-output" } diff --git a/docs/en/config/outbounds/shadowsocks.md b/docs/en/config/outbounds/shadowsocks.md index 0eff4555..8c83e1df 100644 --- a/docs/en/config/outbounds/shadowsocks.md +++ b/docs/en/config/outbounds/shadowsocks.md @@ -1,10 +1,10 @@ # Shadowsocks -[Shadowsocks](https://en.wikipedia.org/wiki/Shadowsocks) protocol is compatible with most other implementations. +The [Shadowsocks](https://en.wikipedia.org/wiki/Shadowsocks) protocol, compatible with most other version implementations. -Here are the features and compatibility of Shadowsocks: +Current compatibility is as follows: -- It supports TCP and UDP packet forwarding, with the option to disable UDP. +- 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 @@ -12,85 +12,71 @@ Here are the features and compatibility of Shadowsocks: - Other encryption methods: - aes-256-gcm - aes-128-gcm - - chacha20-poly1305 (also known as chacha20-ietf-poly1305) - - none or plain + - chacha20-poly1305 (or chacha20-ietf-poly1305) + - xchacha20-poly1305 (or xchacha20-ietf-poly1305) + - none (or plain) -The new protocol format of Shadowsocks 2022 improves performance and includes full replay protection, addressing security issues present in the old protocol: +The Shadowsocks 2022 new protocol format improves performance and includes complete replay protection, resolving the following security issues of the old protocol: -- [Serious vulnerabilities in Shadowsocks AEAD encryption methods that compromise the integrity of communications](https://github.com/shadowsocks/shadowsocks-org/issues/183) -- Increasing false-positive rate of TCP replay filters over time -- Lack of replay protection for UDP -- TCP behaviors that can be used for active probing +- [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 -Using the "none" encryption method will transmit traffic in plaintext. It is not recommended to use "none" encryption on public networks to ensure security. +Under the "none" encryption method, traffic will be transmitted in plain text. To ensure security, do not use it on public networks. ::: ## OutboundConfigurationObject -```json -{ - "servers": [ - { - "email": "love@xray.com", - "address": "127.0.0.1", - "port": 1234, - "method": "encryption method", - "password": "password", - "uot": true, - "level": 0 - } - ] -} -``` - -> `servers`: \[[ServerObject](#serverobject)\] - -An array representing a group of Shadowsocks server settings, where each item is a [ServerObject](#serverobject). - -### ServerObject - ```json { "email": "love@xray.com", "address": "127.0.0.1", "port": 1234, - "method": "encryption method", - "password": "password", + "method": "Encryption Method", + "password": "Password", "uot": true, + "UoTVersion": 2, "level": 0 } ``` > `email`: string -Email address (optional) used to identify the user. +Email address, optional, used to identify the user. > `address`: address -The address of the Shadowsocks server, supporting IPv4, IPv6, and domain names. Required. +Shadowsocks server address. Supports IPv4, IPv6, and domain names. Required. > `port`: number -The port of the Shadowsocks server. Required. +Shadowsocks server port. Required. > `method`: string -Encryption method. Required. +Shadowsocks encryption method. Required. > `password`: string -Password. Required. +Shadowsocks authentication password. Required. > `uot`: bool -When enabled, UDP over TCP (UOT) will be used. +Enable `udp over tcp`. + +> `UoTVersion`: number + +Implementation version of `UDP over TCP`. + +Current optional values: `1`, `2`. - Shadowsocks 2022 -Use a pre-shared key (PSK) similar to WireGuard as the password. +Uses a pre-shared key similar to WireGuard as the password. -To generate a compatible key with shadowsocks-rust, use `openssl rand -base64
+
> `reserved` \[ number \]
-Wireguard Reserved Bytes.
-
-Xray-core v1.8.0 New parameter.MTU Calculation Method
+ +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). + +-When connecting to warp via wireguard, due to cloudflare limitations, some IPs in Hong Kong and Los Angeles need to have a `reserved` value in order to connect successfully.
-The value of `reserved` can be obtained using third-party tools such as [warp-reg](https://github.com/badafans/warp-reg), [warp-reg.sh](https://github.com/chise0713/warp-reg.sh).。 +Wireguard reserved bytes, fill as needed. > `workers`: int -The number of threads used by Wireguard. +Number of threads used by Wireguard. Defaults to the number of system cores. > `peers`: \[ [Peers](#peers) \] -A list of Wireguard servers, where each item is a server configuration. +List of Wireguard servers, where each item is a server configuration. > `domainStrategy`: "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4" | "ForceIP" -Xray-core v1.8.6 New parameter.
-If you do not write this parameter, or leave it blank, the default value is `"ForceIP"`.
-When the destination address is a domain name, use the Xray-core [built-in DNS server](./dns.md) to get an IP (if no `"dns"` configuration is written, system DNS is used), and send a connection to this IP via wireguard.
+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. -| domainStrategy | test-ipv6.com | bgp.he.net | chat.openai.com | -| :------------- | :---------------------: | :--------: | :-------------: | -| ForceIPv6v4 | IPv6v4 | IPv6 | IPv6 | -| ForceIPv6 | The website won't open. | IPv6 | IPv6 | -| ForceIPv4v6 | IPv6v4 **1** | IPv4 | IPv4 | -| ForceIPv4 | IPv4 | IPv4 | IPv4 | -| ForceIP | IPv6v4 **2** | IPv6 | IPv6 | +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`. -**1：** Tip `You already have an IPv6 address, but your browser is less inclined to use it, which is more worrying. `
-**2：** The chances of prompting `You already have an IPv6 address, but your browser is less inclined to use it, which is more worrisome. ` - -**Note 1**： - -- Conflicts with `"queryStrategy"` may cause the site to fail to open. -- For example when `domainStrategy: "ForceIPv4"` is used, geosite:openai's site with `"queryStrategy": "UseIPv6"` will fail to open. - -```json - "dns": { - "servers": [ - "https://1.1.1.1/dns-query", - { - "address": "https://1.1.1.1/dns-query", - "domains": [ - "geosite:openai" - ], - "skipFallback": true, - "queryStrategy": "UseIPv6" // Query only AAAA records. - } - ], - "queryStrategy": "UseIP" // If this parameter is not written, the default value is UseIP, i.e. both A and AAAA records are queried, optional values are UseIPv4 and UseIPv6, other record types are queried by the system DNS. - } -``` - -**Note 2**： - -- Xray-core v1.8.0 - v1.8.4 without `"domainStrategy"`. -- When the destination address is a domain name, use the Xray-core built-in DNS server query to obtain the IP, using the value of `"queryStrategy"` in the `"dns"` configuration to control the IPv4 or IPv6 priority. -- If the `"dns"` configuration is not written, the system DNS query is used to obtain IP, and the IPv4 or IPv6 priority is controlled by the system. +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.
+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 @@ -121,23 +111,23 @@ When the destination address is a domain name, use the Xray-core [built-in DNS s > `endpoint`: address -The server address. Required. +Server address, required. -URL:port format, e.g. `engage.cloudflareclient.com:2408`.
-IP:port format, e.g. `162.159.192.1:2408` or `[2606:4700:d0::a29f:c001]:2408`. +URL:Port format, e.g., `engage.cloudflareclient.com:2408`
+IP:Port format, e.g., `162.159.192.1:2408` or `[2606:4700:d0::a29f:c001]:2408` > `publicKey`: string -The server's public key used for verification. Required. +Server public key, used for verification, required. > `preSharedKey`: string -An additional symmetric encryption key. +Additional symmetric encryption key. > `keepAlive`: int -The interval of keep-alive packets in seconds. The default is 0, which means no keep-alive. +Heartbeat interval in seconds. Default is 0, meaning no heartbeat. > `allowedIPs`: string array -Only allow traffic from specific source IP addresses in Wireguard. +Wireguard only allows traffic from specific source IPs. diff --git a/docs/en/config/policy.md b/docs/en/config/policy.md index a59a3ae0..a7342ee4 100644 --- a/docs/en/config/policy.md +++ b/docs/en/config/policy.md @@ -1,10 +1,10 @@ # Local Policy -Local policy can be used to set different policy settings for different user levels, such as connection timeout settings. Each connection handled by Xray corresponds to a user, and different policies are applied based on the user's level. +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` field in the configuration file. +`PolicyObject` corresponds to the `policy` item in the configuration file. ```json { @@ -33,15 +33,15 @@ Local policy can be used to set different policy settings for different user lev > `level`: map{string: [LevelPolicyObject](#levelpolicyobject)} -A set of key-value pairs, where each key is a string representation of a number (as required by JSON), such as `"0"`, `"1"`, etc., with the number corresponding to the user level. Each value is a [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 the user level, and Xray will apply different local policies based on the actual user level. +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 policy. +Xray system-level policies. ### LevelPolicyObject @@ -59,46 +59,51 @@ Xray system-level policy. > `handshake`: number -The time limit for handshake during connection establishment. Unit: seconds. Default: `4`. When processing a new inbound connection, if the time used in the handshake phase exceeds this limit, the connection will be aborted. +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 -The time limit for connection idle time. Unit: seconds. Default: `300`. When processing an inbound/outbound connection, if no data is transferred (including upstream and downstream data) within `connIdle` time, the connection will be aborted. +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 -The time limit after the downstream connection is closed. Unit: seconds. Default: `2`. When the server (such as a remote website) closes the downstream connection, the outbound proxy will abort the connection after waiting for `uplinkOnly` time. +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 -The time limit after the upstream connection is closed. Unit: seconds. Default: `5`. When the client (such as a browser) closes the upstream connection, the inbound proxy will abort the connection after waiting for `downlinkOnly` time. +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 the scenario of HTTP browsing, you can set `uplinkOnly` and `downlinkOnly` to `0` to improve the efficiency of connection closing. +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 upstream traffic statistics for all users at the current level. +When set to `true`, enables uplink traffic statistics for all users of the current level. > `statsUserDownlink`: true | false -When set to `true`, enables downstream traffic statistics for all users at the current level. +When set to `true`, enables downlink traffic statistics for all users of the current level. > `statsUserOnline`: true | false - -When set to `true`, enables counting online users for all users at the current level by email. +> 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 of each connection. Unit: kB. When set to `0`, the internal buffer is disabled. +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, and MIPSLE platforms, the default value is `0`. -- On ARM64, MIPS64, and MIPS64LE platforms, the default value is `4`. +- 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 @@ -112,16 +117,16 @@ Default values: > `statsInboundUplink`: true | false -When set to `true`, enables upstream traffic statistics for all inbound proxies. +When set to `true`, enables uplink traffic statistics for all inbound proxies. > `statsInboundDownlink`: true | false -When set to `true`, enables downstream traffic statistics for all inbound proxies. +When set to `true`, enables downlink traffic statistics for all inbound proxies. > `statsOutboundUplink`: true | false -When set to `true`, enables upstream traffic statistics for all outbound proxies. +When set to `true`, enables uplink traffic statistics for all outbound proxies. > `statsOutboundDownlink`: true | false -When set to `true`, enables downstream traffic statistics for all outbound proxies. +When set to `true`, enables downlink traffic statistics for all outbound proxies. diff --git a/docs/en/config/reverse.md b/docs/en/config/reverse.md index ced043c0..243f6695 100644 --- a/docs/en/config/reverse.md +++ b/docs/en/config/reverse.md @@ -1,26 +1,41 @@ # Reverse Proxy -A reverse proxy forwards traffic from a server to a client, which is known as reverse traffic forwarding. - -Here's how a reverse proxy generally works: - -- Suppose there is a web server in host A, which does not have a public IP address and cannot be accessed directly on the Internet. There is another host B that can be accessed via the public network. Now we need to use B as the entry point to forward traffic from B to A. -- Configure Xray in host A as a `bridge`, and also configure Xray in B as a `portal`. -- `Bridge` will actively establish a connection to `portal`, and the destination address of this connection can be set by itself. `Portal` will receive two types of connections: one is the connection sent by `bridge`, and the other is the connection sent by public network users. `Portal` will automatically merge the two types of connections. So `bridge` can receive public network traffic. -- After receiving the public network traffic, `bridge` will forward it unchanged to the web server in host A. Of course, this step requires the cooperation of routing. -- `Bridge` will dynamically load balance according to the size of the traffic. +A reverse proxy can forward traffic from the server side to the client side, effectively performing reverse traffic forwarding. ::: tip -Reverse proxy has Mux enabled by default, so please do not enable Mux again on the outbound it uses. +This reverse proxy is a general-purpose reverse proxy (it does not limit the proxy protocol type). The configuration is more complex. Do not confuse it with the VLESS simplified reverse configuration (refer to the relevant sections in the VLESS inbound/outbound documentation). +::: + +Its underlying protocol is Mux.cool, but the direction is reversed: the server initiates requests to the client. + +The general working principle of the reverse proxy is as follows: + +- Assume there is a web server on Host A. This host does not have a public IP and cannot be accessed directly from the public internet. There is another Host B, which is accessible from the public internet. We need to use B as the entry point to forward traffic from B to A. + - Configure Xray on Host B to receive external requests; this is called the `portal`. + - Configure Xray on Host A to bridge the forwarding from B to the web server; this is called the `bridge`. + +- `bridge` + - The `bridge` actively establishes a connection to the `portal` to register a reverse tunnel. The destination address (domain) of this connection can be defined by the user. + - After receiving public traffic forwarded by the `portal`, the `bridge` sends it intact to the web server on Host A. Naturally, this step requires configuration in the routing module. + - Upon receiving a response, the `bridge` returns the response intact to the `portal`. + +- `portal` + - If the `portal` receives a request and the domain matches, it indicates response data sent by the `bridge`. This connection will be used to establish the reverse tunnel. + - If the `portal` receives a request and the domain does *not* match, it indicates a connection from a public user. This connection data will be forwarded to the bridge. + +- The `bridge` performs dynamic load balancing based on traffic volume. + +::: tip +As mentioned above, the reverse proxy has [Mux](../development/protocols/muxcool.md) enabled by default. Please do not enable Mux again on the outbounds used by it. ::: ::: warning -The reverse proxy function is still in the testing phase and may have some issues. +The reverse proxy function is currently in the testing stage and may have some issues. ::: ## ReverseObject -`ReverseObject` corresponds to the `reverse` field in the configuration file. +`ReverseObject` corresponds to the `reverse` item in the configuration file. ```json { @@ -28,13 +43,13 @@ The reverse proxy function is still in the testing phase and may have some issue "bridges": [ { "tag": "bridge", - "domain": "test.xray.com" + "domain": "reverse-proxy.xray.internal" } ], "portals": [ { "tag": "portal", - "domain": "test.xray.com" + "domain": "reverse-proxy.xray.internal" } ] } @@ -43,92 +58,95 @@ The reverse proxy function is still in the testing phase and may have some issue > `bridges`: \[[BridgeObject](#bridgeobject)\] -An array in which each item represents a `bridge`. The configuration of each `bridge` is a [BridgeObject](#bridgeobject). +An array, where each item represents a `bridge`. The configuration for each `bridge` is a [BridgeObject](#bridgeobject). -> `portals`: [[PortalObject](#portalobject)] +> `portals`: \[[PortalObject](#portalobject)\] -An array in which each item represents a `portal`. The configuration of each `portal` is a [PortalObject](#bridgeobject). +An array, where each item represents a `portal`. The configuration for each `portal` is a [PortalObject](#bridgeobject). ### BridgeObject ```json { "tag": "bridge", - "domain": "test.xray.com" + "domain": "reverse-proxy.xray.internal" } ``` > `tag`: string -All connections initiated by `bridge` will have this tag. It can be used to identify the connections in [routing configuration](./routing.md). +All connections initiated by the `bridge` will carry this tag. It can be identified using `inboundTag` in the [Routing Configuration](./routing.md). > `domain`: string -Specifies a domain name that will be used by `bridge` to send connections to `portal`. This domain name is only used for communication between `bridge` and `portal`, and does not need to actually exist. +Specifies a domain name. Connections established by the `bridge` to the `portal` will be sent using this domain. +This domain is used solely for communication between the `bridge` and the `portal` and does not need to exist in reality. ### PortalObject ```json { "tag": "portal", - "domain": "test.xray.com" + "domain": "reverse-proxy.xray.internal" } ``` > `tag`: string -The identifier for the `portal`. Use `outboundTag` in [routing configuration](./routing.md) to forward traffic to this `portal`. +The identifier for the `portal`. Use `outboundTag` in the [Routing Configuration](./routing.md) to forward traffic to this `portal`. > `domain`: string -A domain name. When the `portal` receives traffic, if the destination domain of the traffic is this domain, the `portal` assumes that the current connection is a communication connection sent by the `bridge`. Other traffic will be considered as traffic that needs to be forwarded. The work of the `portal` is to identify and splice these two types of connections. +A domain name. When the `portal` receives traffic, if the target domain of the traffic matches this domain, the `portal` considers the current connection to be a communication connection sent by the `bridge`. Other traffic will be treated as traffic that needs to be forwarded. The job of the `portal` is to identify these two types of connections and perform the corresponding forwarding. ::: tip -An Xray can act as a `bridge`, a `portal`, or both at the same time, depending on the needs of different scenarios. +A single Xray instance can act as a `bridge`, a `portal`, or both simultaneously to suit different scenario requirements. ::: ## Complete Configuration Example -::: -tip During operation, it is recommended to enable `bridge` first, then enable `portal`. +::: tip +During operation, it is recommended to enable the `bridge` first, and then enable the `portal`. ::: ### Bridge Configuration -A `bridge` usually requires two outbounds, one for connecting to the `portal`, and the other for sending actual traffic. That is, you need to use routing to distinguish between the two types of traffic. +The `bridge` usually requires two outbounds: one for connecting to the `portal` and another for sending actual traffic. This means you need to use routing to distinguish between the two types of traffic. -Reverse proxy configuration: +Reverse Proxy Configuration: ```json -{ +"reverse": { "bridges": [ { "tag": "bridge", - "domain": "test.xray.com" + "domain": "reverse-proxy.xray.internal" } ] } ``` -outbound: +Outbounds: ```json { + // Forward to web server "tag": "out", "protocol": "freedom", "settings": { - "redirect": "127.0.0.1:80" // Forward all traffic to web server + "redirect": "127.0.0.1:80" } } ``` ```json { + // Connect to portal "protocol": "vmess", "settings": { "vnext": [ { - "address": "portal's IP address", + "address": "IP Address of Portal", "port": 1024, "users": [ { @@ -148,11 +166,16 @@ Routing Configuration: { "rules": [ { + // Requests initiated by the bridge with the configured domain indicate an attempt + // to establish a reverse tunnel to the portal. + // Therefore, route to interconn (connect to portal). "inboundTag": ["bridge"], - "domain": ["full:test.xray.com"], + "domain": ["full:reverse-proxy.xray.internal"], "outboundTag": "interconn" }, { + // Traffic coming from the portal will also exit from the bridge, but without the domain above. + // Therefore, route to out (forward to the web server). "inboundTag": ["bridge"], "outboundTag": "out" } @@ -162,25 +185,26 @@ Routing Configuration: ### Portal Configuration -`portal` usually requires two inbounds, one for receiving connections from `bridge`, and the other for receiving actual traffic. You also need to distinguish between these two types of traffic using routing. +The `portal` usually requires two inbounds: one to receive connections from the `bridge` and another to receive actual traffic. You also need to use routing to distinguish between the two types of traffic. -Reverse proxy configuration: +Reverse Proxy Configuration: ```json -{ +"reverse": { "portals": [ { "tag": "portal", - "domain": "test.xray.com" // Must be the same as the bridge's configuration + "domain": "reverse-proxy.xray.internal" // Must be the same as the bridge configuration } ] } ``` -inbound: +Inbounds: ```json { + // Directly receive requests from the public internet "tag": "external", "port": 80, "protocol": "dokodemo-door", @@ -194,8 +218,9 @@ inbound: ```json { - "port": 1024, + // Receive requests from the bridge attempting to establish a reverse tunnel "tag": "interconn", + "port": 1024, "protocol": "vmess", "settings": { "clients": [ @@ -213,10 +238,16 @@ Routing Configuration: { "rules": [ { + // If the inbound is external, it indicates a request from the public internet. + // Route to portal, which will eventually forward to the bridge. "inboundTag": ["external"], "outboundTag": "portal" }, { + // If the inbound is interconn, it indicates a request from the bridge to establish a reverse tunnel. + // Route to portal, which will eventually forward to the corresponding public client. + // Note: The request entering here will carry the domain configured earlier, + // so the portal can distinguish between the two types of requests routed to it. "inboundTag": ["interconn"], "outboundTag": "portal" } diff --git a/docs/en/config/routing.md b/docs/en/config/routing.md index 41b38ac0..d610607d 100644 --- a/docs/en/config/routing.md +++ b/docs/en/config/routing.md @@ -1,10 +1,10 @@ # Routing -The routing module can send inbound data through different outbound connections according to different rules to achieve on-demand proxying. +The routing module can send inbound data through different outbound connections based on different rules, achieving the purpose of on-demand proxying. -A common use case is to split domestic and foreign traffic. Xray can use its internal mechanisms to determine the traffic from different regions and then send them to different outbound proxies. +A common usage is splitting traffic between domestic and foreign destinations. Xray can determine the region of the traffic through internal mechanisms and then send them to different outbound proxies. -For a more detailed analysis of the routing function, please refer to [Routing Function Analysis](../document/level-1/routing-lv1-part1.md). +For a more detailed analysis of the routing function: [Analysis of Routing (Part 1)](../document/level-1/routing-lv1-part1.md). ## RoutingObject @@ -22,35 +22,35 @@ For a more detailed analysis of the routing function, please refer to [Routing F > `domainStrategy`: "AsIs" | "IPIfNonMatch" | "IPOnDemand" -The domain name resolution strategy, which uses different strategies based on different settings. +Domain resolution strategy. Different strategies are used based on different settings. -- `"AsIs"`: No additional processing is performed. The domain name from the destination address or the sniffed domain is used for routing selection. Default value. -- `"IPIfNonMatch"`: After a full round of matching, if no rule is matched, the domain name is resolved to an IP address and a second matching pass is performed; -- `"IPOnDemand"`: Before starting the matching process, directly resolve the domain name to the IP address for matching; +- `"AsIs"`: No extra operation. Uses the domain in the destination address or the sniffed domain. Default value. +- `"IPIfNonMatch"`: When no rule is matched after a full round of matching, resolve the domain to an IP and perform a second round of matching. +- `"IPOnDemand"`: Before starting matching, resolve the domain to an IP immediately for matching. -The actual resolution action is deferred until the first encounter with an IP rule to reduce latency. The result will include both IPv4 and IPv6 (you can further restrict this using the built-in DNS's `queryStrategy`). When a domain name resolves to multiple IPs, each rule will try all IPs sequentially; a rule is considered a hit if any IP matches the requirement. +Actual resolution behavior will be delayed until the first IP rule is encountered to reduce latency. The result will contain both IPv4 and IPv6 (you can further restrict this via `queryStrategy` in the built-in DNS). When a domain resolves to multiple IPs, each rule will try all IPs in turn. If any IP meets the requirement, the rule is considered matched. -When `sniff + routeOnly` is enabled, allowing the routing system to see both the IP and the domain name simultaneously, if the above resolution occurs, the routing system will only see the IP resolved from the domain name and not the original target IP, unless the resolution fails. +When `sniff` + `routeOnly` is enabled, allowing the routing system to see both IP and domain, if the aforementioned resolution occurs, the routing system can only see the IP resolved from the domain and cannot see the original destination IP, unless resolution fails. -When two domains exist (target domain + sniff result), the sniff result always has higher priority, whether used for resolution or domain name matching. +When two domains exist (target domain + sniffed result), the priority of the sniffed result is always higher, whether for resolution or domain matching. -Regardless of whether the resolution is performed or not, the routing system does not affect the actual target address; the requested target remains the original target. +Regardless of whether resolution occurs, the routing system will not affect the actual destination address. The requested target remains the original target. -> `rules`: [[RuleObject](#ruleobject)] +> `rules`: \[[RuleObject](#ruleobject)\] -An array corresponding to a list of rules. +Corresponds to an array, where each item is a rule. -For each connection, the routing will judge these rules from top to bottom in order. When it encounters the first effective rule, it will forward the connection to the `outboundTag` or `balancerTag` specified by the rule. +For each connection, routing will judge these rules from top to bottom. When the first effective rule is encountered, the connection is forwarded to the `outboundTag` or `balancerTag` specified by it. ::: tip -When no rules match, the traffic is sent out by the first outbound by default. +When no rule is matched, traffic is sent via the first outbound by default. ::: -> `balancers`: [ [BalancerObject](#balancerobject) ] +> `balancers`: \[ [BalancerObject](#balancerobject) \] -An array corresponding to a list of load balancers. +An array, where each item is a load balancer configuration. -When a rule points to a load balancer, Xray selects an outbound through this load balancer, and then it forwards the traffic through it. +When a rule points to a load balancer, Xray will select an outbound through this load balancer and then forward traffic using it. ### RuleObject @@ -69,6 +69,7 @@ When a rule points to a load balancer, Xray selects an outbound through this loa "inboundTag": ["tag-vmess"], "protocol": ["http", "tls", "quic", "bittorrent"], "attrs": { ":method": "GET" }, + "process": ["curl"], "outboundTag": "direct", "balancerTag": "balancer", "ruleTag": "rule name" @@ -76,149 +77,166 @@ When a rule points to a load balancer, Xray selects an outbound through this loa ``` ::: danger -When multiple attributes are specified at the same time, these attributes need to be satisfied **simultaneously** in order for the current rule to take effect. +When multiple attributes are specified simultaneously, these attributes must be satisfied **simultaneously** for the current rule to take effect. ::: -> `domain`: [string] - -An array where each item is a domain match. There are several forms: - -- Plain string: Same as the substring below, but the "keyword:" prefix can be omitted. -- Regular expression: Starts with `"regexp:"` followed by a regular expression. When this regular expression matches the target domain, the rule takes effect. For example, "regexp:\\\\.goo.\*\\\\.com$" matches "www.google.com" and "fonts.googleapis.com", but not "google.com". Case sensitive. -- Subdomain (recommended): Starts with `"domain:"` followed by a domain. When this domain is the target domain or a subdomain of the target domain, the rule takes effect. For example, "domain:xray.com" matches "www.xray.com" and "xray.com", but not "wxray.com". -- Substring: Begins with `"keyword:"`, the remainder is a string. This rule applies when this string matches any part of the target domain. For example, "keyword:sina.com" can match "sina.com", "sina.com.cn", and "www.sina.com", but not "sina.cn". -- Exact match: Starts with `"full:"` followed by a domain. When this domain is an exact match for the target domain, the rule takes effect. For example, "full:xray.com" matches "xray.com" but not "www.xray.com". -- Dotless domain name: Begins with `"dotless:"`, followed by a string that cannot contain periods (.). This rule applies when the domain name does not contain periods (.) and this string matches any part of the target domain name. For example, "dotless:pc-" can match "pc-alice" and "mypc-alice", suitable for internal NetBIOS domains, etc. Case sensitive. -- Predefined domain list: Starts with `"geosite:"` followed by a name such as `geosite:google` or `geosite:cn`. The names and domain lists are listed in [Predefined Domain List](#predefined-domain-lists). -- Load domains from a file: Formatted as `"ext:file:tag"`, where the file is stored in the [resource directory](./features/env.md#resource-file-path) and has the same format as `geosite.dat`. The tag must exist in the file. +- **Pure string**: Same as substring below, but the `"keyword:"` prefix can be omitted. +- **Regular expression**: Starts with `"regexp:"`, the rest is a regular expression. The rule takes effect when the regular expression matches the target domain. For example, "regexp:\\\\.goo.\*\\\\.com\$" matches "www.google.com" and "fonts.googleapis.com", but not "google.com". Case sensitive. +- **Subdomain (Recommended)**: Starts with `"domain:"`, the rest is a domain name. The rule takes effect when the domain is the target domain or its subdomain. For example, "domain:xray.com" matches "www.xray.com" and "xray.com", but not "wxray.com". +- **Substring**: Starts with `"keyword:"`, the rest is a string. The rule takes effect when this string matches any part of the target domain. For example, "keyword:sina.com" matches "sina.com", "sina.com.cn", and "www.sina.com", but not "sina.cn". +- **Full match**: Starts with `"full:"`, the rest is a domain name. The rule takes effect when this domain exactly matches the target domain. For example, "full:xray.com" matches "xray.com" but not "www.xray.com". +- **Dotless domain**: Starts with `"dotless:"`, the rest is a string that cannot contain `.`. The rule takes effect when the domain contains no `.` and this string matches any part of the target domain. For example, "dotless:pc-" matches "pc-alice", "mypc-alice". Suitable for intranet NetBIOS domains, etc. Case sensitive. +- **Predefined domain list**: Starts with `"geosite:"`, the rest is a name, such as `geosite:google` or `geosite:cn`. Refer to [Predefined Domain List](#predefined-domain-list) for names and domain lists. +- **Load domains from file**: In the form of `"ext:file:tag"`. Must start with `ext:` (lowercase), followed by filename and tag. The file is stored in the [Resource Directory](./features/env.md#resource-file-path). The file format is the same as `geosite.dat`, and the tag must exist in the file. ::: tip `"ext:geoip.dat:cn"` is equivalent to `"geoip:cn"` ::: -`ip`: [string] +> `ip`: \[string\] -An array where each item represents an IP range. This rule will take effect when the target IP matches any of the IP ranges in the array. There are several types of IP ranges: +An array, where each item represents an IP range. The rule takes effect when an item matches the target IP. Available forms: -- IP: In the format of `"127.0.0.1"`. -- [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing): In the format of `"10.0.0.0/8"`, or you can use `"0.0.0.0/0"` `::/0"` to specify all IPv4 or IPv6. -- Predefined IP lists: These lists are included in every Xray installation package under the file name `geoip.dat`. They can be used in the format of `"geoip:cn"`, where `cn` is a two-letter country code. The prefix `geoip:`(all lowercase) must be used, and nearly all countries that have internet access are supported. - - Special value: `"geoip:private"`, which includes all private addresses, such as `127.0.0.1`. - - The `!` function negates the selection; `"geoip:!cn"` represents results other than those in `geoip:cn`. Multiple negations are related by `AND`, while positive options, positive options, and all negations are related by `OR`. For example, `ip: ["geoip:!cn", "geoip:!us", "geoip:telegram"]` matches IPs that are neither in the US nor China, or IPs from Telegram. -- Loading IP from a file: In the format of `"ext:file:tag"`, where `file` is the file name and `tag` is a label that must exist in the file. The prefix `ext:` (all lowercase) must be used, and the file should be located in the [resource directory](./features/env.md#resource-file-path) with the same format as `geoip.dat`. +- **IP**: Like `"127.0.0.1"`. +- **[CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)**: Like `"10.0.0.0/8"`. You can also use `"0.0.0.0/0"` or `"::/0"` to specify all IPv4 or IPv6. +- **Predefined IP list**: This list is pre-installed in every Xray installation package, named `geoip.dat`. Usage is like `"geoip:cn"`. Must start with `geoip:` (lowercase), followed by a two-character country code. Supports almost all countries with internet access. + - **Special value**: `"geoip:private"`, includes all private addresses, such as `127.0.0.1`. + - **Inverse selection `!`**: `"geoip:!cn"` means results not in geoip:cn. Multiple inverse options have an `AND` relationship, while positive options, or positive options and all inverse options, have an `OR` relationship. For example, `ip: ["geoip:!cn", "geoip:!us", "geoip:telegram"]` matches IPs that are not from the US AND not from China, OR are Telegram IPs. +- **Load IPs from file**: In the form of `"ext:file:tag"`. Must start with `ext:` (lowercase), followed by filename and tag. The file is stored in the [Resource Directory](./features/env.md#resource-file-path). The file format is the same as `geoip.dat`, and the tag must exist in the file. > `port`: number | string -The target port range, which can take on three forms: +Target port range. Three forms: -- `"a-b"`: `a` and `b` are both positive integers less than 65536. This range is a closed interval, and this rule will take effect when the target port falls within this range. -- `a`: `a` is a positive integer less than 65536. This rule will take effect when the target port is `a`. +- `"a-b"`: a and b are positive integers less than 65536. This is a closed interval. The rule takes effect when the target port falls within this range. +- `a`: a is a positive integer less than 65536. The rule takes effect when the target port is a. - A mixture of the above two forms, separated by commas ",". For example: `"53,443,1000-2000"`. > `sourcePort`: number | string -The source port, which can take on three forms: +Source port. Three forms: -- `"a-b"`: `a` and `b` are both positive integers less than 65536. This range is a closed interval, and this rule will take effect when the source port falls within this range. -- `a`: `a` is a positive integer less than 65536. This rule will take effect when the source port is `a`. +- `"a-b"`: a and b are positive integers less than 65536. This is a closed interval. The rule takes effect when the source port falls within this range. +- `a`: a is a positive integer less than 65536. The rule takes effect when the source port is a. - A mixture of the above two forms, separated by commas ",". For example: `"53,443,1000-2000"`. -> `localPort`：number | string +> `localPort`: number | string -The local inbound port, in the same format as `port`/`sourcePort`, may be useful when listening on a range of inbound ports. +Local inbound port. Format matches `port`/`sourcePort`. Useful when the inbound listens on a port range. > `network`: "tcp" | "udp" | "tcp,udp" -This can be "tcp", "udp", or "tcp,udp". This rule will take effect when the connection method is the specified one. +Optional values are "tcp", "udp", or "tcp,udp". The rule takes effect when the connection method matches. -Since the core clearly supports only two Layer-4 protocols, TCP and UDP, a routing rule that contains only the "network": "tcp,udp" condition can be used as a catch-all to match any traffic. A typical use case is to place such a rule at the very end of the routing rule list to specify the default outbound when no other rules match (otherwise, the core uses the first one by default). +Since the core obviously only supports TCP and UDP layer 4 protocols, a routing rule containing only `"network": "tcp,udp"` can be used as a "catch-all" to match any traffic. An example usage is placing it at the very end of all routing rules to specify the default outbound when no other rules match (otherwise the core defaults to the first outbound). -Of course, other obvious ways to match all traffic—such as specifying ports 1–65535, or using 0.0.0.0/0 together with ::/0 as IP conditions—serve a similar purpose. +Of course, other ways that obviously match any traffic, such as specifying ports 1-65535 or IPs 0.0.0.0/0 + ::/0, have a similar effect. -> `sourceIP`: [string] +> `sourceIP`: \[string\] -An array where each item represents an IP range in the format of IP, CIDR, GeoIP, or loading IP from a file. This rule will take effect when the source IP matches any of the IP ranges in the array. +An array, where each item represents an IP range. Forms include IP, CIDR, GeoIP, and loading IPs from a file. The rule takes effect when an item matches the source IP. -alias: `source` +Alias: `source` > `localIP`: \[string\] -The format is the same as other IP fields and is used to specify the IP address on which the local inbound connection is received. When listening on 0.0.0.0, different actual incoming IP addresses will result in different localIP values. +Format is the same as other IPs. Used to specify the IP used by the local inbound (when using 0.0.0.0 to listen on all IPs, different actual incoming IPs will produce different localIPs). -This field is not effective for UDP. Due to the message-oriented nature of UDP, the local IP cannot be tracked, and the listener IP is always reported. +Ineffective for UDP (due to UDP being message-oriented, tracking is not possible); it always sees the listening IP. -> `user`: [string] +> `user`: \[string\] -An array where each item represents an email address. This rule will take effect when the source user matches any of the email addresses in the array. +An array, where each item is an email address. The rule takes effect when an item matches the source user. -Similar to domain matching, this field also supports regular-expression matching with the `regexp:` prefix (note that `\` must be escaped as `\\`; see the explanation in the domain section). +Similar to domains, it also supports regex matching starting with `regexp:`. (Similarly, need to replace `\` with `\\`, see explanation in domain section). > `vlessRoute`: number | string -For VLESS inbounds, the client is allowed to modify the 7th and 8th bytes of the configured UUID to any value. The server-side routing system uses these two bytes as vlessRoute data, allowing users to customize server-side routing behavior without changing any external fields. +VLESS inbound allows the client to modify the 7th and 8th bytes of the configured UUID to any bytes. The server routing will use this as `vlessRoute` data, allowing users to customize parts of the server routing based on needs without changing any external fields. ``` --------------↓↓↓↓------------------ xxxxxxxx-xxxx-0000-xxxx-xxxxxxxxxxxx ``` -In the configuration, the value is interpreted as a big-endian uint16. (If this sounds confusing, simply treat these four hexadecimal digits as a single hexadecimal number and convert it to decimal). For example: `0001 → 1`, `000e → 14`, `38b2 → 14514`. This design is used so that the syntax matches `port`, allowing multiple ranges to be specified freely for routing, just like port-based routing. +The configuration uses data after Big-Endian encoding to uint16 (if you don't understand, treat these four digits as a hexadecimal number and convert to decimal). E.g., `0001→1`, `000e→14`, `38b2→14514`. The reason for this is that the syntax here is the same as `port`; you can freely specify many segments for routing just like specifying ports. -> `inboundTag`: [string] +> `inboundTag`: \[string\] -An array where each item represents an identifier. This rule will take effect when the inbound protocol matches any of the identifiers in the array. +An array, where each item is an identifier. The rule takes effect when an item matches the identifier of the inbound protocol. -> `protocol`: [ "http" | "tls" | "quic" | "bittorrent" ] +> `protocol`: \[ "http" | "tls" | "quic" | "bittorrent" \] -An array where each item represents a protocol. This rule will take effect when the protocol of the current connection matches any of the protocols in the array. +An array, where each item represents a protocol. The rule takes effect when a protocol matches the protocol type of the current connection. -`http` Only HTTP/1.0 and HTTP/1.1 are supported; HTTP/2 (h2) is not currently supported. (Plaintext h2 traffic is also very rare.) +`http` only supports 1.0 and 1.1; h2 is not supported yet (plaintext h2 traffic is also very rare). -`tls` TLS versions 1.0 through 1.3 are supported. +`tls` TLS 1.0 ~ 1.3. -`quic` Due to the complexity of the protocol, sniffing may occasionally fail. +`quic` Due to the complexity of this protocol, sniffing may sometimes fail. -`bittorrent` Only very basic sniffing is supported and may not work with many encrypted or obfuscated variants. +`bittorrent` Only has the most basic sniffing; may not work for much encrypted and obfuscated traffic. ::: tip -The `sniffing` option in the inbound proxy must be enabled to detect the protocol type used by the connection. +You must enable the `sniffing` option in the inbound proxy to sniff the protocol type used by the connection. ::: -`attrs`: object +> `attrs`: object -A JSON object in which both keys and values are strings. It is used to match attributes of HTTP traffic (for obvious reasons, only HTTP/1.0 and HTTP/1.1 are supported). A rule is considered matched when the HTTP headers contain **all** specified keys and the corresponding values contain the specified substrings.Header names are case-insensitive. Values support regular-expression matching. +A JSON object where keys and values are strings. Used to detect HTTP traffic attribute values (due to obvious reasons, only supports 1.0 and 1.1). The rule is matched when HTTP headers contain all specified keys and values contain the specified substrings. Keys are case-insensitive. Values support regular expressions. -Pseudo-headers similar to those in HTTP/2, such as `:method` and `:path`, are also supported for matching the request method and path (even though these headers do not exist in HTTP/1.1). +It also supports pseudo-headers like `:method` and `:path` from h2 for matching methods and paths (although these headers do not exist in HTTP/1.1). -For HTTP inbounds using non-`CONNECT` methods, the attributes can be obtained directly. For other inbounds, sniffing must be enabled in order to obtain these values for matching. +For non-CONNECT methods of HTTP inbounds, `attrs` can be obtained directly. For other inbounds, sniffing must be enabled to obtain these values for matching. -Examples: +Example: -- Detect HTTP GET：`{":method": "GET"}` -- Detect HTTP Path：`{":path": "/test"}` -- Detect Content Type：`{"accept": "text/html"}` +- Detect HTTP GET: `{":method": "GET"}` +- Detect HTTP Path: `{":path": "/test"}` +- Detect Content Type: `{"accept": "text/html"}` + +> `process`: \[string\] + +If the connection originates from the local machine, match its process. If not from local, it is directly regarded as a match failure. Only supports Windows and Linux. + +This option is an array, where each item has three matching modes. + +1. **No slash**: Matches process name. +2. **Contains slash, does not end with slash**: Matches absolute path. +3. **Contains slash, ends with slash**: Matches folder; all processes under this folder are considered a match. + +Note: + +- All options are case-sensitive. +- On Windows, use backslash `\` for paths. Here it is uniformly required to use forward slash `/`, e.g., `C:/Windows/System32/curl.exe`, because backslashes are treated as escape characters in JSON, which is inconvenient (unless you choose to double the backslashes, which also works). +- When matching by process name, the core automatically removes the `.exe` suffix. Similarly, `["curl"]` can match curl on both Linux and Windows. When using absolute paths, the `.exe` suffix cannot be ignored. + +Special syntax sugar: + +- `self/`: Matches the current core process, very useful for avoiding routing loops. +- `xray/`: Will be replaced by the absolute path where the current core resides, matching all Xray processes started from this binary. > `outboundTag`: string -Corresponds to the identifier of an outbound. +Corresponds to an outbound identifier. > `balancerTag`: string -Corresponds to the identifier of a balancer. +Corresponds to a Balancer identifier. ::: tip -`balancerTag` and `outboundTag` are mutually exclusive. When both are specified, `outboundTag` takes effect. +You must choose one between `balancerTag` and `outboundTag`. When both are specified, `outboundTag` takes effect. ::: > `ruleTag`: string -Optional. Has no functional effect and is used only to identify the rule. +Optional. No actual effect, only used to identify the name of this rule. -When set, relevant information will be logged at the Info level when this rule is matched, which is useful for debugging and determining which routing rule was applied. +If set, information regarding this rule will be output at the Info level when the rule is matched, used for debugging which specific rule was hit. ### BalancerObject -Load balancer configuration. When a load balancer is in effect, it selects the most appropriate outbound from the specified outbound according to the configuration and forwards traffic. +Load balancer configuration. When a load balancer takes effect, it selects the most suitable outbound from the specified outbounds according to the configuration and forwards the traffic. ```json { @@ -233,17 +251,17 @@ Load balancer configuration. When a load balancer is in effect, it selects the m The identifier of this load balancer, used to match `balancerTag` in `RuleObject`. -> `selector`: [ string ] +> `selector`: \[ string \] -An array of strings, each of which will be used to match the prefix of the outbound identifier. For example, in the following outbound identifiers: `[ "a", "ab", "c", "ba" ]`, `"selector": ["a"]` will match `[ "a", "ab" ]`. +An array of strings. Each string is used for prefix matching against outbound identifiers. Among the following outbound identifiers: `[ "a", "ab", "c", "ba" ]`, `"selector": ["a"]` will match `[ "a", "ab" ]`. -Generally, multiple outbounds are matched to distribute the load evenly. +Generally matches multiple outbounds to distribute load among them. > `fallbackTag`: string -If all outbounds fail to connect based on the connection observation results, the outbound specified by this configuration item will be used. +If all outbounds cannot be connected based on observation results, the outbound specified by this configuration item is used. -Note: You need to add either the [observatory](./observatory.md#observatoryobject) or [burstObservatory](./observatory.md#burstobservatoryobject) configuration item. +Note: Requires adding [observatory](./observatory.md#observatoryobject) or [burstObservatory](./observatory.md#burstobservatoryobject) configuration items. > `strategy`: [StrategyObject](#strategyobject) @@ -256,22 +274,22 @@ Note: You need to add either the [observatory](./observatory.md#observatoryobjec } ``` -> `type`: `"random"` | `"roundRobin"` | `"leastPing"` | `"leastLoad"` +> `type` : "random" | "roundRobin" | "leastPing" | "leastLoad" -- `random` Default value. Randomly selects one of the matched outbound proxies. -- `roundRobin` Selects matched outbound proxies in sequential order. -- `leastPing` Selects the matched outbound proxy with the lowest latency based on connection observation results. Requires either the [observatory](./observatory.md#observatoryobject) or [burstObservatory](./observatory.md#burstobservatoryobject) configuration to be enabled. -- `leastLoad` Selects the most stable matched outbound proxy based on connection observation results. Requires either the [observatory](./observatory.md#observatoryobject) or [burstObservatory](./observatory.md#burstobservatoryobject) configuration to be enabled. +- `random`: Default value. Randomly selects a matched outbound proxy. +- `roundRobin`: Selects matched outbound proxies in order. +- `leastPing`: Selects the matched outbound proxy with the lowest latency based on observation results. Requires [observatory](./observatory.md#observatoryobject) or [burstObservatory](./observatory.md#burstobservatoryobject). +- `leastLoad`: Selects the most stable outbound proxy based on observation results. Requires [observatory](./observatory.md#observatoryobject) or [burstObservatory](./observatory.md#burstobservatoryobject). ::: tip -Regardless of the selected strategy, once all nodes referenced by the `selector` are configured with either `observatory` or `burstObservatory`, unhealthy nodes can be filtered out. If no healthy nodes are available, `fallbackTag` will be attempted. +Regardless of the mode, if all nodes corresponding to its `selector` have `observatory` or `burstObservatory` configured, healthy nodes can be filtered out. If no healthy nodes are available, it attempts `fallbackTag`. ::: > `settings`: [StrategySettingsObject](#strategysettingsobject) ##### StrategySettingsObject -This is an optional configuration object. The configuration format varies depending on the load-balancing strategy. Currently, only the `leastLoad` strategy supports this configuration. +This is an optional configuration item. The configuration format varies for different load balancing strategies. Currently, only the `leastLoad` strategy supports this item. ```json { @@ -295,94 +313,94 @@ The number of optimal nodes selected by the load balancer. Traffic will be rando > `maxRTT`: string -The maximum acceptable RTT for latency measurements. +The maximum acceptable RTT duration for speed tests. -> `tolerance`: float +> `tolerance`: float number -The maximum acceptable ratio of failed latency measurements. For example, `0.01` allows up to 1% of measurements to fail. (Appears to be not yet implemented.) +The maximum acceptable failure rate for speed tests. For example, 0.01 means accepting a 1% failure rate. (Seemingly unimplemented). -> `baselines`: [string] +> `baselines`: \[ string \] -The maximum acceptable standard deviation of RTT measurements. +The maximum acceptable standard deviation duration for RTT speed tests. -> `costs`: [CostObject] +> `costs`: \[ CostObject \] -Optional. An array used to assign weights to outbounds. +Optional configuration item. An array to assign weights to all outbounds. -> `regexp`: `true` | `false` +> `regexp`: true | false -Whether to use a regular expression to match the outbound `tag`. +Whether to use regular expressions to select outbound `Tag`. > `match`: string -The outbound `tag` to match. +Matches outbound `Tag`. -> `value`: float +> `value`: float number -The weight value. A higher value makes the corresponding node less likely to be selected. +Weight value. The larger the value, the less likely the corresponding node is to be selected. -### Load Balancing Configuration Example +### Load Balancer Configuration Example ```json -"routing": { - "rules": [ - { - "inboundTag": [ - "in" - ], - "balancerTag": "round" - } - ], - "balancers": [ - { - "selector": [ - "out" - ], - "strategy": { - "type": "roundRobin" - }, - "tag": "round" - } - ] -}, + "routing": { + "rules": [ + { + "inboundTag": [ + "in" + ], + "balancerTag": "round" + } + ], + "balancers" : [ + { + "selector": [ + "out" + ], + "strategy": { + "type":"roundRobin" + }, + "tag": "round" + } + ] + }, -"inbounds": [ - { - // inbound configuration - "tag": "in" - } -], + "inbounds": [ + { + // Inbound config + "tag": "in" + } + ], -"outbounds": [ - { - // outbound configuration - "tag": "out1" - }, - { - // outbound configuration - "tag": "out2" - } -] + "outbounds": [ + { + // Outbound config + "tag": "out1" + }, + { + // Outbound config + "tag": "out2" + } + ] ``` -### Predefined Domain Lists +### Predefined Domain List -This list is included in every Xray installation package, and the file name is `geosite.dat`. This file contains some common domain names, which can be used as `geosite:filename` to perform routing or DNS filtering for domain names that match those in the file. +This list is pre-installed in every Xray installation package, named `geosite.dat`. This file contains some common domain names. Usage: `geosite:filename`, e.g., `geosite:google` represents routing filtering or DNS filtering for domains included within `google` in the file. -Common domain lists include: +Common domains include: -- `category-ads`: Contains common advertising domain names. -- `category-ads-all`: Contains common advertising domain names and advertising provider domain names. -- `cn`: Equivalent to the combination of `geolocation-cn` and `tld-cn`. -- `apple`: Contains most of the domain names under Apple. -- `google`: Contains most of the domain names under Google. -- `microsoft`: Contains most of the domain names under Microsoft. -- `facebook`: Contains most of the domain names under Facebook. -- `twitter`: Contains most of the domain names under Twitter. -- `telegram`: Contains most of the domain names under Telegram. -- `geolocation-cn`: Contains common domain names of mainland Chinese websites. -- `geolocation-!cn`: Contains common domain names of non-mainland Chinese websites. -- `tld-cn`: Contains top-level domain names managed by CNNIC for mainland China, such as domain names ending in `.cn` and `.中国`. -- `tld-!cn`: Contains top-level domain names used outside mainland China, such as domain names ending in `.tw` (Taiwan), `.jp` (Japan), `.sg` (Singapore), `.us` (United States), and `.ca` (Canada). +- `category-ads`: Contains common advertising domains. +- `category-ads-all`: Contains common advertising domains, as well as domains of advertising providers. +- `cn`: Equivalent to the collection of `geolocation-cn` and `tld-cn`. +- `apple`: Contains the vast majority of Apple domains. +- `google`: Contains the vast majority of Google domains. +- `microsoft`: Contains the vast majority of Microsoft domains. +- `facebook`: Contains the vast majority of Facebook domains. +- `twitter`: Contains the vast majority of Twitter domains. +- `telegram`: Contains the vast majority of Telegram domains. +- `geolocation-cn`: Contains common mainland China site domains. +- `geolocation-!cn`: Contains common non-mainland China site domains. +- `tld-cn`: Contains top-level domains managed by CNNIC for mainland China, such as domains ending in `.cn`, `.中国`. +- `tld-!cn`: Contains top-level domains not used in mainland China, such as domains ending in `.tw` (Taiwan), `.jp` (Japan), `.sg` (Singapore), `.us` (USA), `.ca` (Canada), etc. -You can also find the complete list of domain names here: [Domain list community](https://github.com/v2fly/domain-list-community). +You can also view the complete domain list here: [Domain list community](https://github.com/v2fly/domain-list-community). diff --git a/docs/en/config/stats.md b/docs/en/config/stats.md index b7296695..7a89f3f6 100644 --- a/docs/en/config/stats.md +++ b/docs/en/config/stats.md @@ -1,10 +1,10 @@ -# Traffic Statistics +# Statistics -Used to configure traffic statistics for Xray. +Used to configure Xray traffic data statistics. ## StatsObject -The `StatsObject` corresponds to the `stats` item in the configuration file. +`StatsObject` corresponds to the `stats` item in the configuration file. ```json { @@ -12,42 +12,42 @@ The `StatsObject` corresponds to the `stats` item in the configuration file. } ``` -Currently, no parameters are required for traffic statistics, and internal statistics will be enabled as long as the `StatsObject` item exists. +Currently, statistics do not require any parameters. As long as the `StatsObject` item exists, internal statistics are enabled. -After statistics are enabled, you only need to enable the corresponding items in the [Policy](./policy.md) to collect the corresponding data. +After enabling statistics, you only need to enable the corresponding items in [Policy](./policy.md) to collect the corresponding data. -## Retrieving Traffic Statistics +## Retrieving Statistics -You can use the `xray api` command to retrieve traffic statistics. +You can use relevant `xray api` commands to retrieve statistics. -The current traffic statistics are as follows: +The currently available statistics are as follows: - User Data - `user>>>[email]>>>traffic>>>uplink` - The uplink traffic of a specific user, in bytes. + Uplink traffic for a specific user, in bytes. - `user>>>[email]>>>traffic>>>downlink` - The downlink traffic of a specific user, in bytes. + Downlink traffic for a specific user, in bytes. ::: tip -If the corresponding user does not have an email specified, statistics will not be enabled. +If the corresponding user does not specify an Email, statistics will not be enabled. ::: - Global Data - `inbound>>>[tag]>>>traffic>>>uplink` - The uplink traffic of a specific inbound, in bytes. + Uplink traffic for a specific inbound, in bytes. - `inbound>>>[tag]>>>traffic>>>downlink` - The downlink traffic of a specific inbound, in bytes. + Downlink traffic for a specific inbound, in bytes. - `outbound>>>[tag]>>>traffic>>>uplink` - The uplink traffic of a specific outbound, in bytes. + Uplink traffic for a specific outbound, in bytes. - `outbound>>>[tag]>>>traffic>>>downlink` - The downlink traffic of a specific outbound, in bytes. + Downlink traffic for a specific outbound, in bytes. diff --git a/docs/en/config/transport.md b/docs/en/config/transport.md index 911d2678..275a477e 100644 --- a/docs/en/config/transport.md +++ b/docs/en/config/transport.md @@ -1,12 +1,14 @@ -# Transport +# Transport (uTLS, REALITY) -Transports specify how Xray communicates with peers. +Transport is the method used by the current Xray node to establish connections with other nodes. -Transports specify how to achieve stable data transmission. Both ends of a connection often need to specify the same transport protocol to successfully establish a connection. Like, if one end uses WebSocket, the other end must also use WebSocket, or else the connection cannot be established. +Transport specifies a stable method for data transmission. Generally, both ends of a network connection need to have symmetrical transport methods. For example, if one end uses WebSocket, the other end must also use WebSocket; otherwise, the connection cannot be established. ## StreamSettingsObject -`StreamSettingsObject` corresponds to the `streamSettings` property in the inbound or outbound config. Each inbound or outbound can be configured with different transports and can use `streamSettings` to specify local configs. +`StreamSettingsObject` corresponds to the `streamSettings` item in inbound or outbound configurations. Each inbound or outbound can be configured with different transport settings independently, and `streamSettings` can be set to perform some transport configurations. + + ```json { @@ -26,7 +28,7 @@ Transports specify how to achieve stable data transmission. Both ends of a conne "tcpFastOpen": false, "tproxy": "off", "domainStrategy": "AsIs", - "happyEyeballs": { "tryDelayMs": 250 }, + "happyEyeballs": {}, "dialerProxy": "", "acceptProxyProtocol": false, "tcpKeepAliveInterval": 0, @@ -36,308 +38,461 @@ Transports specify how to achieve stable data transmission. Both ends of a conne "interface": "wg0", "v6only": false, "tcpWindowClamp": 600, - "tcpMptcp": false, - "tcpNoDelay": false + "tcpMptcp": false } } ``` -> `network`: "raw" | "xhttp" | "kcp" | "grpc" | "ws" | "httpupgrade" +> `network`: "raw" | "xhttp" | "kcp" | "grpc" | "ws" | "httpupgrade" | "hysteria" -The underlying protocol of the transport used by the data stream of the connection, defaulting to `"raw"`. +The type of transport method used for the connection data stream. The default value is `"raw"`. ::: tip -After v24.9.30, the TCP transport has been renamed to RAW to more closely match actual behavior. `"network": "raw"` and `"network": "tcp"`, `rawSettings` and `tcpSettings` are aliases for each other for compatibility. +After version v24.9.30, to better reflect actual behavior, the TCP transport method has been renamed to RAW. For compatibility, `"network": "raw"` and `"network": "tcp"`, as well as `rawSettings` and `tcpSettings`, are aliases for each other. ::: > `security`: "none" | "tls" | "reality" -Whether to enable transport layer encryption. Supported options below. +Whether to enable transport layer encryption. Supported options are: -- `"none"` enables no encryption (default). -- `"tls"` enables encryption with [TLS](https://en.wikipedia.org/wiki/transport_Layer_Security). -- `"reality"` enables encryption with REALITY. +- `"none"`: Indicates no encryption (default value). +- `"tls"`: Indicates using [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security). +- `"reality"`: Indicates using REALITY. > `tlsSettings`: [TLSObject](#tlsobject) -Configures vanilla TLS. The TLS encryption suite is provided by Golang, which often uses TLS 1.3, and has no support for DTLS. +TLS configuration. TLS is provided by Golang. Usually, the TLS negotiation result is TLS 1.3. DTLS is not supported. > `realitySettings`: [RealityObject](#realityobject) -Configures REALITY. REALITY is a piece of advanced encryption technology developed in-house, with higher security than vanilla TLS, but configs of both are largely the same. +Reality configuration. Reality is an original black technology from Xray. Reality offers higher security than TLS, and its configuration method is consistent with TLS. ::: tip -REALITY is by far the most secure transport encryption solution, perfectly mimicking normal web browsing when observed. Enabling REALITY with appropriate XTLS Vision flow control schemes has the potential of reaching magnitudes of performance boosts. +Reality is currently the most secure transport encryption scheme, and the traffic type appears consistent with normal web browsing from the outside. Enabling Reality and configuring an appropriate XTLS Vision flow control mode can achieve several times or even more than ten times performance improvement. ::: > `rawSettings`: [RawObject](./transports/raw.md) -Configures the current RAW connection. Valid only when RAW is used. Same schema as global. +RAW configuration for the current connection. Only valid when this connection uses RAW. > `xhttpSettings`: [XHTTP: Beyond REALITY](https://github.com/XTLS/Xray-core/discussions/4113) -Configures XHTTP connections. Valid only when XHTTP is used. Same schema as global. +XHTTP configuration for the current connection. Only valid when this connection uses XHTTP. > `kcpSettings`: [KcpObject](./transports/mkcp.md) -Configures the current mKCP connection. Valid only when mKCP is used. Same schema as global. +mKCP configuration for the current connection. Only valid when this connection uses mKCP. > `grpcSettings`: [GRPCObject](./transports/grpc.md) -Configures the current gRPC connection. Valid only when gRPC is used. Same schema as global. +gRPC configuration for the current connection. Only valid when this connection uses gRPC. > `wsSettings`: [WebSocketObject](./transports/websocket.md) -Configures the current WebSocket connection. Valid only when WebSocket is used. Same schema as global. +WebSocket configuration for the current connection. Only valid when this connection uses WebSocket. > `httpupgradeSettings`: [HttpUpgradeObject](./transports/httpupgrade.md) -Configures the current HTTPUpgrade connection. Valid only when HTTPUpgrade is used. Same schema as global. +HTTPUpgrade configuration for the current connection. Only valid when this connection uses HTTPUpgrade. + +> `hysteriaSettings`: [HysteriaObject](./transports/hysteria.md) + +Hysteria configuration for the current connection. Only valid when this connection uses Hysteria. > `sockopt`: [SockoptObject](#sockoptobject) -Configures transparent proxies. +Specific configurations related to transparent proxying. ### TLSObject + + ```json { "serverName": "xray.com", + "verifyPeerCertInNames": [], "rejectUnknownSni": false, - "verifyPeerCertInNames": ["xray.com"], "allowInsecure": false, "alpn": ["h2", "http/1.1"], "minVersion": "1.2", "maxVersion": "1.3", - "cipherSuites": "Specify encryption suites here, separated by :", + "cipherSuites": "Enter the cipher suite names you need here, separated by :", "certificates": [], "disableSystemRoot": false, "enableSessionResumption": false, "fingerprint": "", - "pinnedPeerCertificateChainSha256": [""], - "masterKeyLog": "" + "pinnedPeerCertSha256": "", + "curvePreferences": [""], + "masterKeyLog": "", + "echServerKeys": "", + "echConfigList": "", + "echForceQuery": "", + "echSockopt": {} } ``` > `serverName`: string -Specifies the domain of the server-side certificate, useful when connecting only via IP addresses. +Server name. The server certificate's SAN must contain this value. It can be a domain name or an IP address. If it is a domain name, it will be sent in the SNI extension of the Client Hello. IP addresses will not send the SNI extension (SNI extension does not allow IP addresses). If filling in IPv6, use `[]` to wrap it. -When the target is specified by domains, like when the domain is received by SOCKS inbounds or detected via sniffing, the extracted domain will automatically be used as `serverName`, without any need for manual configuration. +When left empty, the value in `address` (if it is a domain name) is automatically used. + +Special value `"FromMitM"`: This causes it to use the SNI contained in the TLS decrypted from the dokodemo-door inbound. + +::: tip +As mentioned above, since this value is used to verify whether the server certificate is valid, if you modify it to be inconsistent with the server certificate domain for special purposes, you need to enable `allowInsecure`; otherwise, certificate authentication will fail. For security reasons, we do not recommend using this method for a long time. If you want to securely spoof SNI, please consider using REALITY. +::: + +> `verifyPeerCertInNames`: \[ string \] + +Client-only. List of SNIs used to verify certificates (only one SAN in the certificate needs to be in this list). This will override `serverName` used for verification, used for special purposes like domain fronting. It is safer than modifying `serverName` and enabling `allowInsecure` because it still performs certificate signature verification. + +Special value `"FromMitM"`: This causes it to additionally include the SNI contained in the TLS decrypted from the dokodemo-door inbound. > `rejectUnknownSni`: bool -When `true`, the server rejects TLS handshakes if the SNI received does not match domains specified in the certificate. The default value is `false`. +When set to `true`, the server refuses the TLS handshake if the received SNI does not match the certificate domain. Default is `false`. -> `verifyPeerCertInNames`: [string] +> `alpn`: \[ string \] -only client, used to verify the SNI used by the certificate, The certificate is verified if and only if it is verified for one of the domains in this list, the default is [serverName]. -for using MitM+domainFronting there is special case "fromMitM", if the list contain "fromMitM" the domain and all subdomain of the real sni(initial sni before change) automatically added to the list. +An array of strings specifying the ALPN values during TLS handshake. Default value is `["h2", "http/1.1"]`. -> `alpn`: [ string ] +Special value: `["FromMitM"]` (when this is the only element) will cause the outbound TLS to use the ALPN used by the TLS connection decrypted from the dokodemo-door inbound. -An array of strings specifying the ALPN values used in TLS handshakes. Defaults to `["h2", "http/1.1"]`. -for using MitM+domainFronting, there is special case ["fromMitM"], and this is selected alpn of initial tls request termination. -(also, when using `h2c` dns, this is equal to domain of the URL) +> `minVersion`: string -> `minVersion`: [ string ] +`minVersion` is the minimum acceptable TLS version. -`minVersion` specifies the minimum SSL/TLS version accepted. +> `maxVersion`: string -> `maxVersion`: [ string ] +`maxVersion` is the maximum acceptable TLS version. -`maxVersion` specifies the maximum SSL/TLS version accepted. +> `cipherSuites`: string -> `cipherSuites`: [ string ] +`CipherSuites` is used to configure the list of supported cipher suites, separated by `:`. -`CipherSuites` specifies a list of supported cryptographic suites, with names of each separated by a colon. - -You can find the names and descriptions of encryption suites in Go [here](https://golang.org/src/crypto/tls/cipher_suites.go#L500) or [here](https://golang.org/src/crypto/tls/cipher_suites.go#L44). +You can find Golang cipher suite names and descriptions [here](https://golang.org/src/crypto/tls/cipher_suites.go#L500) or [here](https://golang.org/src/crypto/tls/cipher_suites.go#L44). ::: danger -The above two configs are optional and do not have impact on security under normal circumstances. When not configured, Go will select the parameters automatically on a per-device basis. If you are not familiar with these configs, leave them as is, or you will bear consequences of potential problems caused by your improper configuration. +The above two configuration items are optional and usually do not affect security. Golang automatically selects based on the device when not configured. Do not configure this option if you are unfamiliar with it; you are responsible for issues caused by improper configuration. ::: > `allowInsecure`: true | false -Whether to allow insecure connections (client-only). Defaults to `false`. +Whether to allow insecure connections (client-only). Default value is `false`. -When `true`, Xray will not verify the validity of the TLS certificate provided by the outbound. +When set to `true`, Xray will not check the validity of the TLS certificate provided by the remote host. ::: danger -This should not be set to `true` in deployments for security reaons, or it can be susceptible to man-in-the-middle attacks. +For security reasons, this option should not be set to `true` in actual scenarios, otherwise, you may suffer from Man-in-the-Middle attacks. ::: > `disableSystemRoot`: true | false -Whether to disable the CA certificates provided by the operating system. Defaults to `false`. +Whether to disable the operating system's built-in CA certificates. Default value is `false`. -When `true`, Xray will only use the certificates specified in `certificates` for TLS handshakes. When `false`, Xray will only use the CA certificates provided by the operating system for TLS handshakes. +When set to `true`, Xray will only use certificates specified in `certificates` for TLS handshake. When set to `false`, Xray will only use the OS's built-in CA certificates for TLS handshake. > `enableSessionResumption`: true | false -When `false`, the `session_ticket` extension will not be included in ClientHello. Oftentimes the ClientHello in Go programs does not have this extension enabled, so it is recommended to leave it as-is. Defaults to `false`. +Whether to enable session resumption. Disabled by default. Session resumption negotiation will only be attempted when both the server and client enable it. -> `fingerprint`: string +If negotiation is successful, certificates do not need to be transmitted during the handshake. Saves a tiny bit of handshake time (almost negligible). -Specifies the fingerprint of the `TLS Client Hello` message. When empty, fingerprint simulation will not be enabled. When enabled, Xray will **simulate** the `TLS` fingerprint through the uTLS library or have it generated randomly. Three types of options are supported: +Note: This is not TLS 0-RTT. gotls does not support this feature yet. It will not reduce the RTT of the TLS handshake. -1. Simulate TLS fingerprints of the latest versions of popular browsers, including: +> `fingerprint` : string -- `"chrome"` -- `"firefox"` -- `"safari"` -- `"ios"` -- `"android"` -- `"edge"` -- `"360"` -- `"qq"` +This parameter is used to configure the fingerprint of the specified `TLS Client Hello`. Default is `chrome`. To revert to native go TLS, set to `unsafe`. When enabled, Xray will **simulate** `TLS` fingerprints via the uTLS library or generate them randomly. Supports three configuration methods: -1. Have a fingerprint generated automatically when xray starts +1. Latest versions of common browsers, including: + - `"chrome"` + - `"firefox"` + - `"safari"` + - `"ios"` + - `"android"` + - `"edge"` + - `"360"` + - `"qq"` -- `"random"`: randomly select one of the up-to-date browsers -- `"randomized"`: generate a completely random and unique fingerprint (100% compatible with TLS 1.3 using X25519) +2. Automatically generate a fingerprint when Xray starts: + - `"random"`: Randomly select one from newer browser versions. + - `"randomized"`: Completely randomly generate a unique fingerprint (100% supports TLS 1.3 using X25519). -1. Use uTLS native fingerprint variable names, such as `"HelloRandomizedNoALPN"` `"HelloChrome_106_Shuffle"`. See the full list in the [uTLS library](https://github.com/refraction-networking/utls/blob/master/u_common.go#L162). +3. Use uTLS native fingerprint variable names, e.g., `"HelloRandomizedNoALPN"`, `"HelloChrome_106_Shuffle"`. See the [uTLS library](https://github.com/refraction-networking/utls/blob/master/u_common.go#L434) for the full list. ::: tip -This feature only **simulates** the fingerprint of `TLS Client Hello` message, leaving other behaviours the same as vanilla Go TLS. If you want to simulate a browser `TLS` more completely, use the [Browser Dialer](./transports/websocket.md#browser-dialer). +This feature only **simulates** the `TLS Client Hello` fingerprint. Behavior and other fingerprints are the same as Golang. If you wish to simulate browser `TLS` fingerprints and behavior more completely, you can use [Browser Dialer](./transports/websocket.md#browser-dialer). ::: ::: tip -When using this feature, some TLS options that affect the TLS fingerprint will be overridden by the utls library and will no longer be effective, such as ALPN. -The parameters that will be passed are -`"serverName" "allowInsecure" "disableSystemRoot" "pinnedPeerCertificateChainSha256" "masterKeyLog"` +When using this feature, some TLS options affecting TLS fingerprints will be overwritten by the uTLS library and will no longer take effect, such as ALPN. +Parameters passed include: +`"serverName"`, `"allowInsecure"`, `"disableSystemRoot"`, `"pinnedPeerCertSha256"`, `"masterKeyLog"`. ::: -> `pinnedPeerCertificateChainSha256`: [string] +> `pinnedPeerCertSha256`: string -Specifies the SHA256 hash values of the certificate chain of the remote server, using the standard encoding format. Only when the hash value of the server-side certificate chain matches any of the specified can a TLS connection be successfully established. +Used to specify the remote server's certificate SHA256 hash. Uses hex and is case-insensitive. Example: `e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9`. This encoding is the same as the SHA-256 certificate fingerprint in Chrome certificate viewer and the Certificate Fingerprints SHA-256 format on crt.sh. It can also be calculated using `xray tls leafCertHash --cert
+> "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4"
> "ForceIP" | "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4" -In previous versions, when Xray attempted to establish a system connection using a domain name, the resolution of the domain name was completed by the system and not controlled by Xray. This led to issues such as the inability to resolve domain names in non-standard Linux environments. To solve this problem, Xray 1.3.1 introduced Freedom's `domainStrategy` into Sockopt. +Default value `"AsIs"`. -When the target address is a domain name, the corresponding value is configured, and the behavior of SystemDialer is as follows: +When the target address is a domain name, configure the value to control the Outbound connection behavior: -- `"AsIs"`: Resolve the IP address using the system DNS server and connect to the domain name. -- `"UseIP"`, `"UseIPv4"`, and `"UseIPv6"`: Resolve the IP address using the [built-in DNS server](./dns.md) and connect to the IP address directly. -- "IPv4" means that you are trying to connect using only IPv4, "IPv4v6" means that you are trying to connect using either IPv4 or IPv6, but for dual-stack domain names, IPv4 is used. (The same applies to the v4v6 switch, so I won't go into details.) -- When using "Use" the option beginning with , if the resolution result does not meet the requirements (for example, the domain name only has IPv4 resolution results but UseIPv6 is used), it will fall back to AsIs. -- When using "Force" an option beginning with , if the parsing result does not meet the requirements, the connection cannot be established. +- `"AsIs"`: Xray does no special handling of domains. Finally, Xray uses Go's built-in Dial to initiate connection. Priority is fixed to RFC6724 default (will not follow gai.conf etc.), usually IPv6 preferred. +- Other values: Use Xray-core [Built-in DNS Server](dns.md) for resolution. If no DNSObject exists, system DNS is used. If multiple IPs match, the core randomly selects one as the target IP. +- `"IPv4"`: Attempt to connect using only IPv4. +- `"IPv4v6"`: Attempt to connect using IPv4 or IPv6, but use IPv4 for dual-stack domains. (v4v6 swapped is analogous). +- When `"queryStrategy"` is set in built-in DNS, actual behavior intersects with this option. Only IP types included in both will be resolved. E.g., `"queryStrategy": "UseIPv4"` + `"domainStrategy": "UseIP"` is effectively `"domainStrategy": "UseIPv4"`. +- `"Use"` prefix: If resolution result doesn't meet requirements (e.g., domain only has IPv4 but used UseIPv6), fallback to AsIs. +- `"Force"` prefix: If resolution result doesn't meet requirements, connection fails. -The default value is `"AsIs"`. +::: tip TIP +When using `"UseIP"` or `"ForceIP"` modes, and `sendThrough` is specified in [Outbound Connection Configuration](outbound.md#outboundobject), the core automatically judges required IP type (IPv4 or IPv6) based on `sendThrough`. If a single IP type is manually specified (e.g., UseIPv4) but mismatches `sendThrough` local address, connection fails. +::: ::: danger +Enabling this feature with improper configuration may cause infinite loops. -Improper configuration may cause infinite loops when this feature is enabled. +TL;DR: Connecting to server requires waiting for DNS result; finishing DNS query requires connecting to server. -In short, connecting to the server requires waiting for the DNS query result, and completing the DNS query requires connecting to the server. +> Tony: Chicken or egg first? -> Tony: Which came first, the chicken or the egg? +Detailed explanation: +1. Trigger: Proxy server (`proxy.com`). Built-in DNS server, non-Local mode. +2. Xray attempts to establish TCP connection to `proxy.com`. **Before** that, query `proxy.com` via built-in DNS. +3. Built-in DNS connects to `dns.com` to query IP of `proxy.com`. +4. **Improper** routing rules cause `proxy.com` to proxy the query sent in step 3. +5. Xray attempts to establish another TCP connection to `proxy.com`. +6. Before establishing, query `proxy.com` via built-in DNS. +7. Built-in DNS reuses connection from step 3 to send query. +8. Problem: Connection in step 3 waits for query result in step 7; query in step 7 waits for connection in step 3 to fully establish. +9. Good Game! -Explanation: - -1. Trigger condition: proxy server (proxy.com). Built-in DNS server, non-local mode. -2. Before Xray attempts to establish a TCP connection to proxy.com, it queries proxy.com using the built-in DNS server. -3. The built-in DNS server establishes a connection to dns.com and sends a query to obtain the IP address of proxy.com. -4. Improper routing rules cause proxy.com to proxy the query sent in step 3. -5. Xray attempts to establish another TCP connection to proxy.com. -6. Before establishing the connection, Xray queries proxy.com using the built-in DNS server. -7. The built-in DNS server reuses the connection established in step 3 to send a query. -8. A problem arises. The establishment of the connection in step 3 requires waiting for the query result in step 7, and the completion of the query in step 7 requires waiting for the connection in step 3 to be fully established. -9. Good game! - -Solution: - -- Adjust the split of internal DNS servers. -- Use Hosts file. -- ~~If you still don't know the solution, then don't use this feature.~~ - -Therefore, it is **not recommended** for inexperienced users to use this feature. +Solutions: +- Change traffic splitting for built-in DNS server. +- Use Hosts. +- ~~If you still don't know the solution, don't use this feature.~~ +Therefore, inexperienced users are **not recommended** to use this feature unauthorized. ::: > `dialerProxy`: "" -An identifier for an outbound proxy. When the value is not empty, the specified outbound will be used to establish the connection. This option can be used to support chain forwarding of underlying transport protocols. +An outbound proxy identifier. When not empty, connection is made using specified outbound. Used for chain forwarding supporting underlying transports. ::: danger -This option is incompatible with ProxySettingsObject.Tag +Incompatible with ProxySettingsObject.Tag. ::: > `acceptProxyProtocol`: true | false -Only used for inbound, indicates whether to accept the PROXY protocol. +Inbound only. Indicates whether to accept PROXY protocol. -[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is used to pass the true source IP and port of a request. **If you are not familiar with it, please ignore this option first**. +[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is for passing real source IP and port. **Ignore if you don't understand it**. -Common reverse proxy software (such as HAProxy, Nginx) can be configured to send it, and VLESS fallbacks xver can also send it. +Common reverse proxies (HAProxy, Nginx) can be configured to send it. VLESS fallbacks xver can also send it. -When set to `true`, after the lowest-level TCP connection is established, the requesting party must first send PROXY protocol v1 or v2, otherwise the connection will be closed. +When `true`, requester must send PROXY protocol v1 or v2 after bottom-layer TCP establishment, otherwise connection closes. + +> `tcpKeepAliveIdle`: number + +TCP idle time threshold in seconds. Keep-Alive probes start after connection is idle for this duration. + +For outbound, Xray uses Chrome defaults (idle & interval both 45s). Setting this or `tcpKeepAliveInterval` to negative disables default keepalive; positive overrides default. + +For inbound, Keep-Alive is disabled by default. Enabled if either this or `tcpKeepAliveInterval` is non-zero. If only one is set, the other follows OS settings. > `tcpKeepAliveInterval`: number -Interval between TCP keep-alive packets, in seconds. ~~This setting only applies to Linux.~~ +Interval between Keep-Alive packets in seconds after TCP enters Keep-Alive state. See above for behavior. -Not configuring this item or configuring it as 0 means using the default value of Go. +> `tcpUserTimeout`: number -::: tip -When filling in a negative number, such as `-1`, TCP keep-alive is not enabled. -::: +In milliseconds. Details: https://github.com/grpc/proposal/blob/master/A18-tcp-user-timeout.md > `tcpcongestion`: "" -TCP congestion control algorithm. Only supported by Linux. Not configuring this item means using the system default value. +TCP congestion control algorithm. Linux only. +Not configuring means using system default. -::: tip -Common algorithms - -- bbr (recommended) +::: tip Common Algorithms +- bbr (Recommended) - cubic - reno - ::: ::: tip -Execute the command `sysctl net.ipv4.tcp_congestion_control` to get the system default value. +Run `sysctl net.ipv4.tcp_congestion_control` to get system default. ::: > `interface`: "" -Specifies the name of the bound outbound network interface. supported by Linux MacOS iOS.
-MacOS iOS Requires Xray-core v1.8.6 or higher. +Bind outbound network interface name. Supports Linux / iOS / Mac OS / Windows. + +> `V6Only`: true | false + +When `true`, listening on `::` only accepts IPv6 connections. Linux only. + +> `tcpWindowClamp`: number + +Bind advertised window size to this value. Kernel picks max between this and SOCK_MIN_RCVBUF/2. > `tcpMptcp`: true | false -Xray-core v1.8.6 New parameter.
-Default value `false`, fill in `true` to enable [Multipath TCP](https://en.wikipedia.org/wiki/Multipath_TCP), need to be enabled in both server and client configuration. +Default `false`. When `true`, enables [Multipath TCP](https://en.wikipedia.org/wiki/Multipath_TCP). Client-only parameter, as golang 1.24+ enables MPTCP by default on listen. +Currently only supports Linux, requires Kernel 5.6+. > `tcpNoDelay`: true | false -Default value `false`, recommended to be enabled with "tcpMptcp": true. +Option removed as golang enables TCP no delay by default. To disable, use customSockopt. + +> `addressPortStrategy`: "none" | "SrvPortOnly" | "SrvAddressOnly" | "SrvPortAndAddress" | "TxtPortOnly" | "TxtAddressOnly" | "TxtPortAndAddress" + +Use SRV or TXT records to specify target address/port for outbound. Default `none` (off). + +Query goes through system DNS, not Xray built-in DNS. Domain queried is the outbound domain. If query fails, request proceeds with original address/port. + +`Srv` prefix: Query SRV record (standard format). `Txt` prefix: Query TXT record (format like `127.0.0.1:80`). + +`PortOnly`: Reset port only. `AddressOnly`: Reset address only. `PortAndAddress`: Reset both. + +Effective before sockopt `domainStrategy` resolution. After reset, still resolves per `domainStrategy` (if any), but ineffective if Freedom `domainStrategy` is set to resolve to IP beforehand. + +PS: If normal domain traffic comes to AsIs Freedom outbound, it attempts resolution and reset here. E.g., core queries SRV record for google.com and resets target accordingly. > `customSockopt`: [] -An array for advanced users to specify any sockopt. In theory, all the above connection-related settings can be set equivalently here. Naturally, other options that exist in Linux but have not been added to the core can also be set. The example below is equivalent to `"tcpcongestion": "bbr"` in core. +Array for advanced users to specify any sockopt. Theoretically covers all connection settings. Supports Linux, Windows, Darwin. Example equivalent to `"tcpcongestion": "bbr"`: -Please make sure you understand Linux socket programming before using it. +Ensure you understand Socket programming. ```json "customSockopt": [ { + "system": "linux", "type": "str", "level":"6", "opt": "13", @@ -641,35 +832,39 @@ Please make sure you understand Linux socket programming before using it. ] ``` +> `system`: "" + +Optional. Target system. Skipped if mismatch. Options: `linux`, `windows`, `darwin` (lowercase). Executes if empty. + > `type`: "" -Required, the type of setting, valid values are `int` or `str`. +Required. Type, `int` or `str`. > `level`: "" -Optional, protocol level, used to specify the effective range, the default is `6`, which is TCP. +Optional. Protocol level. Default 6 (TCP). > `opt`: "" -The option name of the operation, using decimal (the example here is that the value of `TCP_CONGESTION` is defined as `0xd` and converted to decimal is 13) +Option name in decimal (Example TCP_CONGESTION 0xd is 13). > `value`: "" -The option value to be set, the example here is set to bbr. +Value to set. Example sets bbr. +Use decimal number if type is int. -Decimal numbers are required when type is specified as int. +> `happyEyeballs`: [HappyEyeballsObject](#happyeyeballsobject) -> `happyEyeballs`: map +RFC-8305 Happy Eyeballs implementation, TCP only. Races target domains and selects first success. Only effective when `Sockopt.domainStrategy` is not `AsIs`. -only TCP, this is RFC-8305 implementation of happyEyeballs, only apply when built-in-dns is used(domainStrategy is `UseIP`/`ForceIP`). -When we have multiple IPs, this algorithm tries to connect to each IP, the first-stablished-connection is winner connection and selected for sending/receiving data. +Note: `UseIPv4v6` / `ForceIPv4v6` reduces available IPs to IPv4 only, falling back to IPv6 query only on failure. Not recommended. Suggest `UseIP` / `ForceIP` with `HappyEyeballs.interleave`. ::: warning - -in `freedom` settings when you set `domainStrategy` to `UseIP`/`ForceIP` just a random IP will replace the domain and `happyEyeballs` does not apply, so for using `happyEyeballs` you should set `sockopt domainStrategy` to `UseIP/ForceIP` not `freedom domainStrategy`. - +Do not use `Freedom` outbound's `domainStrategy` with this, as `Sockopt` will only see the replaced IP. ::: +#### HappyEyeballsObject + ```json "happyEyeballs": { "tryDelayMs": 250, @@ -681,23 +876,18 @@ in `freedom` settings when you set `domainStrategy` to `UseIP`/`ForceIP` just a > `tryDelayMs`: number -delay time between each attempt in millisecond, RFC-8305 recommend `250`, default is `0`. -(if it is `0`, happy-eyeballs is disabled) +Interval between race requests in ms. Default 0 (disabled). Recommended 250. > `prioritizeIPv6`: bool -indicate "First Address Family" in RFC-8305, default is false(= prioritizeIPv4) +Whether first IP is IPv6 when sorting. Default `false` (IPv4 first). > `interleave`: number -indicate "First Address Family count" in RFC-8305, default is 1. +"First Address Family count" in RFC-8305. Default 1. Defines interleaving behavior for sorting IP versions. -for example suppose our IP-list is [ip4-1, ip4-2, ip4-3, ip4-4, ip6-1, ip6-2, ip6-3, ip6-4] -when interleave is 1 and prioritizeIPv6 is false, the sorted-ip-list is: -[ip4-1, ip6-1, ip4-2, ip6-2, ip4-3, ip6-3, ip4-4, ip6-4] -and when for example interleave is 2 and prioritizeIPv6 is true: -[ip6-1, ip6-2, ip4-1, ip4-2, ip6-3, ip6-4, ip4-3, ip4-4] +E.g., waiting IP queue sorted as 46464646 (set to 1), 44664466 (set to 2). > `maxConcurrentTry`: number -maximum concurrent attempt (this is only maximum and in most cases our concurrent attempts is less, unless all connection fail to connect) also we can always have a maximum of concurrent-attempt as many IPs as we have, and this option is useful when the number of IPs is too high, and we want to control the number of concurrent-attempts, default is 4. if it is 0, happy-eyeballs is disabled. +Max concurrent attempts. Prevents core from making massive connections if many IPs resolve but fail. Default 4. Set to 0 to disable happyEyeballs. diff --git a/docs/en/config/transports/grpc.md b/docs/en/config/transports/grpc.md index fa293e7a..e982f5e4 100644 --- a/docs/en/config/transports/grpc.md +++ b/docs/en/config/transports/grpc.md @@ -1,47 +1,48 @@ # gRPC -An modified transport protocol based on gRPC. +A transport protocol based on gRPC. -gRPC is based on the HTTP/2 protocol and can theoretically be relayed by other servers that support HTTP/2, such as Nginx. - -gRPC and HTTP/2 has built-in multiplexing, so it is not recommended to enable `mux.cool` when using gRPC or HTTP/2. +It is based on the HTTP/2 protocol and, theoretically, can be relayed through other servers that support HTTP/2 (such as Nginx). +gRPC (HTTP/2) has built-in multiplexing. It is not recommended to enable mux.cool when using gRPC and HTTP/2. ::: danger -**It is recommended to switch to [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113), whose advantages over gRPC are noted in the STREAM-UP/ONE section.** +**It is recommended to switch to [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113). Its advantages over gRPC are noted in the STREAM-UP/ONE section.** ::: ::: warning ⚠⚠⚠ -- gRPC doesn't support specifying the Host. Please enter the **correct domain name** in the outbound proxy address, or fill in `ServerName` in `(x)tlsSettings`, otherwise connection cannot be established. -- gRPC doesn't support fallback to other services. -- gRPC services are at risk of being actively probed. It is recommended to use reverse proxy tools such as Caddy or Nginx to perform path-based routing. +- gRPC does not support specifying Host. Please fill in the **correct domain name** in the outbound proxy address, or fill in `ServerName` in `(x)tlsSettings`, otherwise the connection will fail. +- gRPC does not support falling back to other services. +- gRPC services are at risk of active probing. It is recommended to use reverse proxy tools such as Caddy or Nginx to split traffic via Path prefix. ::: ::: tip -If you are using a reverse proxy such as Caddy or Nginx, please note the following: +If you use reverse proxies like Caddy or Nginx, please note the following: -- Make sure that the reverse proxy server has enabled HTTP/2. +- Ensure the reverse proxy server has enabled HTTP/2. - Use HTTP/2 or h2c (Caddy), grpc_pass (Nginx) to connect to Xray. -- The path for regular mode is `/${serviceName}/Tun`, and for Multi mode it is `/${serviceName}/TunMulti`. -- If you need to receive the client IP address, you can use the `X-Real-IP` header sent by Caddy / Nginx to pass the client IP. +- The Path for normal mode is `/${serviceName}/Tun`, and for Multi mode is `/${serviceName}/TunMulti`. +- If you need to receive the client IP, you can pass the client IP by having Caddy / Nginx send the `X-Real-IP` header. ::: ::: tip If you are using fallback, please note the following: -- Fallback to gRPC is not recommended, as there is a risk of being actively probed. -- Please make sure that `h2` is the first priority in `(x)tlsSettings.alpn`, otherwise gRPC (HTTP/2) may not be able to complete TLS handshake. -- gRPC cannot perform path-based routing by Xray. +- Falling back to gRPC is not recommended due to the risk of active probing. +- Please ensure `h2` is in the first position in (x)tlsSettings.alpn, otherwise gRPC (HTTP/2) may fail to complete the TLS handshake. +- gRPC cannot be split by Path. ::: ## GRPCObject -`GRPCObject` corresponds to the `grpcSettings` item. +`GRPCObject` corresponds to the `grpcSettings` item in the transport configuration. ```json { + "authority": "grpc.example.com", "serviceName": "name", "multiMode": false, + "user_agent": "custom user agent", "idle_timeout": 60, "health_check_timeout": 20, "permit_without_stream": false, @@ -49,65 +50,80 @@ If you are using fallback, please note the following: } ``` +> `authority`: string + +A string. Can be used as Host to achieve some other purposes. + > `serviceName`: string -A string that specifies the service name, similar to the `path` in HTTP/2. +A string. Specifies the service name, **similar to** Path in HTTP/2. +The client uses this name for communication, and the server verifies if the service name matches. -The client will use this name for communication, and the server will verify whether the service name matches. +::: tip +When `serviceName` starts with a slash, you can customize the path. It requires at least two slashes.
+For example, fill in `"serviceName": "/my/sample/path1|path2"` on the server side, and the client can fill in `"serviceName": "/my/sample/path1"` or `"/my/sample/path2"`. +::: + +> `user_agent`: string + +::: tip +**Only** needs to be configured on **outbound** (**client**). +::: + +Set the User-Agent for gRPC. This may prevent some CDNs from blocking gRPC traffic. > `multiMode`: true | false
[@DuckSoft](https://github.com/DuckSoft) for the proposal!
-Please see [VMessAEAD/VLESS Sharing Link Standard Proposal](https://github.com/XTLS/Xray-core/issues/91) for more details.
+For details, please see [VMessAEAD / VLESS Sharing Link Standard Proposal](https://github.com/XTLS/Xray-core/issues/91)
diff --git a/docs/en/development/protocols/vmess.md b/docs/en/development/protocols/vmess.md
index c318e44f..d68c4f5e 100644
--- a/docs/en/development/protocols/vmess.md
+++ b/docs/en/development/protocols/vmess.md
@@ -1,6 +1,6 @@
# VMess Protocol
-VMess is an encrypted transmission protocol that can serve as a bridge between the Xray client and server.
+VMess is an encrypted transport protocol that can act as a bridge between Xray clients and servers.
## Version
@@ -10,165 +10,166 @@ The current version number is 1.
### Underlying Protocol
-VMess is a TCP-based protocol where all data is transmitted over TCP.
+VMess is a TCP-based protocol; all data is transmitted using TCP.
### User ID
-An ID is equivalent to a [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier), which is a 16-byte long random number. Its function is similar to a token. An ID looks like: `de305d54-75b4-431b-adb2-eb6b9e546014`, it is almost entirely random and can be generated using any UUID generator, such as [this one](https://www.uuidgenerator.net/).
+The ID is equivalent to a [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier). It is a 16-byte random number that acts as a token.
+An ID looks like: `de305d54-75b4-431b-adb2-eb6b9e546014`. It is almost completely random and can be generated using any UUID generator, such as [this one](https://www.uuidgenerator.net/).
-User ID can be specified in the [configuration file](../../config/).
+The User ID can be specified in the [configuration file](../../config/).
### Functions
- MD5: [MD5 Function](https://en.wikipedia.org/wiki/MD5)
- - Input parameter is any length byte array
- - Output is a 16-byte array
+ - Input parameter: Byte array of arbitrary length
+ - Output: A 16-byte array
- HMAC: [HMAC Function](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
- - Input parameters are:
+ - Input parameters:
- H: Hash function
- - K: Key, any length byte array
- - M: Message, any length byte array
+ - K: Key, byte array of arbitrary length
+ - M: Message, byte array of arbitrary length
- Shake: [SHA3-Shake128 Function](https://en.wikipedia.org/wiki/SHA-3)
- - Input parameter is any length string
- - Output is any length string
+ - Input parameter: String of arbitrary length
+ - Output: String of arbitrary length
## Communication Process
-VMess is a stateless protocol, which means that data can be transmitted directly between the client and the server without the need for a handshake. Each data transmission has no impact on other data transmissions before or after it.
+VMess is a stateless protocol, meaning no handshake is required between the client and server to transmit data. Each data transmission has no effect on previous or subsequent transmissions.
-When a VMess client initiates a request, the server checks whether the request comes from a legitimate client. If the validation passes, the server forwards the request and sends the obtained response back to the client.
+The VMess client initiates a request. The server determines if the request comes from a legitimate client. If verification passes, the request is forwarded, and the received response is sent back to the client.
-VMess uses an asymmetric format, meaning that the requests sent by the client and the responses from the server use different formats.
+VMess uses an asymmetric format, meaning the request sent by the client and the response from the server use different formats.
## Client Request
-| 16 Bytes | X Bytes | Remaining |
-| -------------------------- | ---------------- | --------- |
-| Authentication Information | Instruction Part | Data Part |
+| 16 bytes | X bytes | Remaining part |
+| ------------------ | -------------- | -------------- |
+| Authentication Info| Command Section| Data Section |
-### Authentication Information
+### Authentication Info
-The authentication information is a 16-byte hash (hash) value, which is calculated as follows:
+The authentication info is a 16-byte hash value, calculated as follows:
- H = MD5
- K = User ID (16 bytes)
-- M = UTC time accurate to seconds, with a random value of ±30 seconds from the current time (8 bytes, Big Endian)
+- M = UTC time, precise to seconds, a random value within 30 seconds before or after the current time (8 bytes, Big Endian)
- Hash = HMAC(H, K, M)
### Command Section
-The instruction part is encrypted using AES-128-CFB.
+The command section is encrypted using AES-128-CFB:
-- Key: MD5(user ID + []byte('c48619fe-8f02-49e0-b9e9-edf763e17e21'))
-- IV: MD5(X + X + X + X), X = []byte(time generated by authentication information) (8 bytes, Big Endian)
+- Key: MD5(User ID + []byte('c48619fe-8f02-49e0-b9e9-edf763e17e21'))
+- IV: MD5(X + X + X + X), where X = []byte(Time used for generating authentication info) (8 bytes, Big Endian)
-| 1 Byte | 16 Bytes | 16 Bytes | 1 Byte | 1 Byte | 4 bits | 4 bits | 1 Byte | 1 Byte | 2 Bytes | 1 Byte | N Bytes | P Bytes | 4 Bytes |
-| :-----: | :----------------: | :-----------------: | :---------------------------: | :-----: | :------: | :---------------: | :------: | :-----: | :-----: | :----------: | :-----: | :----------: | :------: |
-| Version | Data Encryption IV | Data Encryption Key | Response Authentication Value | Options | Reserved | Encryption Method | Reserved | Command | Port | Address Type | Address | Random Value | Checksum |
+| 1 byte | 16 bytes | 16 bytes | 1 byte | 1 byte | 4 bits | 4 bits | 1 byte | 1 byte | 2 bytes | 1 byte | N bytes | P bytes | 4 bytes |
+| :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| Version Ver | Data Encryption IV | Data Encryption Key | Response Auth V | Option Opt | Margin P | Encryption Sec | Reserved | Command Cmd | Port | Address Type T | Address A | Random Value | Checksum F |
-Options Opt Details: (When a bit is 1, it means the option is enabled)
+Option Opt details: (When a bit is 1, the option is enabled)
-| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
-| X | X | X | X | X | M | R | S |
+| X | X | X | X | X | M | R | S |
-of which:
+Where:
-- Version Number Ver: Always 1;
-- Data Encryption IV: Random value;
-- Data Encryption Key: Random value;
-- Response Authentication V: Random value;
-- Option Opt:
- - S (0x01): Standard format data stream (recommended);
- - R (0x02): Client expects to reuse TCP connection (deprecated in Xray 2.23+);
- - This item only takes effect when S is enabled;
- - M (0x04): Enable metadata obfuscation (recommended);
- - This item only takes effect when S is enabled;
- - When this item is enabled, the client and server need to construct two Shake instances respectively, RequestMask = Shake (request data IV), ResponseMask = Shake (response data IV).
- - X: Reserved
-- Redundancy P: Random value added before checksum value;
-- Encryption Method: Specify the encryption method for the data part, and the optional values are:
- - 0x00: AES-128-CFB;
- - 0x01: No encryption;
- - 0x02: AES-128-GCM;
- - 0x03: ChaCha20-Poly1305;
-- Instruction Cmd:
- - 0x01: TCP data;
- - 0x02: UDP data;
-- Port Port: Integer port number in Big Endian format;
-- Address Type T:
+- **Version Ver**: Always 1.
+- **Data Encryption IV**: Random value.
+- **Data Encryption Key**: Random value.
+- **Response Auth V**: Random value.
+- **Option Opt**:
+ - S (0x01): Standard format data stream (Recommended enabled).
+ - R (0x02): Client expects to reuse TCP connection (Deprecated in Xray 2.23+).
+ - Valid only when S is enabled.
+ - M (0x04): Enable metadata obfuscation (Recommended enabled).
+ - Valid only when S is enabled.
+ - When enabled, both client and server need to construct two Shake instances respectively: RequestMask = Shake(Request Data IV), ResponseMask = Shake(Response Data IV).
+ - X: Reserved.
+- **Margin P**: Adds P bytes of random value before the checksum.
+- **Encryption Sec**: Specifies the encryption method for the data section. Options:
+ - 0x00: AES-128-CFB
+ - 0x01: No encryption
+ - 0x02: AES-128-GCM
+ - 0x03: ChaCha20-Poly1305
+- **Command Cmd**:
+ - 0x01: TCP data
+ - 0x02: UDP data
+- **Port**: Integer port number in Big Endian format.
+- **Address Type T**:
- 0x01: IPv4
- 0x02: Domain name
- 0x03: IPv6
-- Address A:
- - When T = 0x01, A is a 4-byte IPv4 address;
- - When T = 0x02, A is a 1-byte length (L) + L-byte domain name;
- - When T = 0x03, A is a 16-byte IPv6 address;
-- Check F: FNV1a hash of all content in the instruction except F.
+- **Address A**:
+ - When T = 0x01, A is a 4-byte IPv4 address.
+ - When T = 0x02, A is 1-byte length (L) + L bytes domain name.
+ - When T = 0x03, A is a 16-byte IPv6 address.
+- **Checksum F**: FNV1a hash of all content in the command section except F.
### Data Section
-When Opt(S) is enabled, this format is used for the data section. The actual request data is divided into several small chunks, and each chunk has the following format. After the server verifies all the small chunks, it will be forwarded in the basic format.
+When Opt(S) is enabled, the data section uses this format. The actual request data is split into several small chunks, each formatted as follows. The server verifies all small chunks before forwarding them according to the basic format.
-| 2 Bytes | L Bytes |
-| :------: | :---------: |
+| 2 bytes | L bytes |
+| :---: | :---: |
| Length L | Data Packet |
-in which:
+Where:
-- Length L: A big-endian integer with a maximum value of 2^14.
- - When Opt(M) is enabled, the value of L is equal to the true value xor Mask. Mask = (RequestMask.NextByte() << 8) + RequestMask.NextByte();
-- Packet: A data packet encrypted by the specified encryption method.
+- **Length L**: Integer in Big Endian format, maximum value is 2^14.
+ - When Opt(M) is enabled, Value of L = Real Value xor Mask. Mask = (RequestMask.NextByte() << 8) + RequestMask.NextByte().
+- **Data Packet**: Data packet encrypted by the specified encryption method.
-Before the transmission is completed, the data packet must contain actual data, in addition to the length and authentication data. When the transmission is complete, the client must send an empty data packet, that is, L = 0 (unencrypted) or the length of the authentication data (encrypted), to indicate the end of the transmission.
+Before transmission ends, the data packet must contain actual data (data other than length and authentication data). When transmission ends, the client must send an empty data packet, i.e., L = 0 (no encryption) or length of authentication data (with encryption), to indicate the end of transmission.
-The packets are formatted as follows, depending on the encryption method:
+Depending on the encryption method, the data packet format is as follows:
-- Unencrypted:
- - L bytes: actual data;
-- AES-128-CFB: The entire data section is encrypted using AES-128-CFB.
- - 4 bytes: FNV1a hash of actual data;
- - L - 4 bytes: actual data;
-- AES-128-GCM: Key is the Key of the instruction section, IV = count (2 bytes) + IV (10 bytes). count starts at 0 and increases by 1 for each packet; IV is the 3rd to 12th byte of the instruction section IV.
- - L - 16 bytes: actual data;
- - 16 bytes: GCM authentication information
-- ChaCha20-Poly1305: Key = MD5 (instruction part Key) + MD5 (MD5 (instruction part Key)), IV = count (2 bytes) + IV (10 bytes). count starts at 0 and increases by 1 for each packet; IV is the 3rd to 12th byte of the instruction section IV.
- - L - 16 bytes: actual data;
- - 16 bytes: Poly1305 authentication information
+- **No encryption**:
+ - L bytes: Actual data.
+- **AES-128-CFB**: The entire data section is encrypted using AES-128-CFB.
+ - 4 bytes: FNV1a hash of actual data.
+ - L - 4 bytes: Actual data.
+- **AES-128-GCM**: Key is the Key from the Command Section, IV = count (2 bytes) + IV (10 bytes). count starts from 0 and increments by 1 for each packet; IV is the 3rd to 12th bytes of the Command Section IV.
+ - L - 16 bytes: Actual data.
+ - 16 bytes: GCM authentication info.
+- **ChaCha20-Poly1305**: Key = MD5(Command Section Key) + MD5(MD5(Command Section Key)), IV = count (2 bytes) + IV (10 bytes). count starts from 0 and increments by 1 for each packet; IV is the 3rd to 12th bytes of the Command Section IV.
+ - L - 16 bytes: Actual data.
+ - 16 bytes: Poly1305 authentication info.
## Server Response
-The header data is encrypted using AES-128-CFB encryption. The IV is MD5 of the data encryption IV, and the Key is MD5 of the data encryption Key. The actual response data varies depending on the encryption settings.
+The response header data is encrypted using AES-128-CFB, with IV being MD5(Data Encryption IV) and Key being MD5(Data Encryption Key). The actual response data varies depending on encryption settings.
-| 1 Byte | 1 Byte | 1 Byte | 1 Byte | M Bytes | Remaining Part |
-| ------------------------- | ---------- | ----------- | ---------------- | --------------- | -------------------- |
-| Response Authentication V | Option Opt | Command Cmd | Command Length M | Command Content | Actual Response Data |
+| 1 byte | 1 byte | 1 byte | 1 byte | M bytes | Remaining part |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| Response Auth V | Option Opt | Command Cmd | Command Length M | Command Content | Actual Response Data |
-in which：
+Where:
-- Response Authentication V: must match the response authentication V in the client request.
-- Option Opt:
- - 0x01: server prepares to reuse TCP connections (deprecated in Xray 2.23+).
-- Command Cmd:
- - 0x01: dynamic port command.
-- Actual response data:
- - If Opt(S) in the request is enabled, the standard format is used. Otherwise, the basic format is used.
- - Both formats are identical to the request data.
- - When Opt(M) is enabled, the value of length L is equal to the true value XOR Mask. Mask = (ResponseMask.NextByte() << 8) + ResponseMask.NextByte().
+- **Response Auth V**: Must match the Response Auth V in the client request.
+- **Option Opt**:
+ - 0x01: Server is ready to reuse TCP connection (Deprecated in Xray 2.23+).
+- **Command Cmd**:
+ - 0x01: Dynamic port command.
+- **Actual Response Data**:
+ - If Opt(S) in the request was enabled, standard format is used; otherwise, basic format is used.
+ - The format is the same as the request data.
+ - When Opt(M) is enabled, Value of Length L = Real Value xor Mask. Mask = (ResponseMask.NextByte() << 8) + ResponseMask.NextByte().
-### Dynamic Port Instructions
+### Dynamic Port Command
-| 1 Byte | 2 Bytes | 16 Bytes | 2 Bytes | 1 Byte | 1 Byte |
-| -------- | ------- | -------- | ------- | ---------- | ----------------- |
-| Reserved | Port | User ID | AlterID | User level | Validity period T |
+| 1 byte | 2 bytes | 16 bytes | 2 bytes | 1 byte | 1 byte |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| Reserved | Port | User ID | AlterID | User Level | Validity Time T |
-in which:
+Where:
-- Port: Integer port number in Big Endian format
-- T: Number of minutes as integer value.
+- **Port**: Integer port number in Big Endian format.
+- **Validity Time T**: Number of minutes.
-When the client receives a dynamic port command, the server opens a new port for communication. The client can then send data to the new port. After T minutes, the port will expire, and the client must use the main port to communicate again.
+When the client receives a dynamic port command, the server has opened a new port for communication, and the client can send data to the new port. After T minutes, this port will expire, and the client must resume using the main port for communication.
-## Comment
+## Notes
- To ensure forward compatibility, the values of all reserved fields must be 0.
diff --git a/docs/en/document/command.md b/docs/en/document/command.md
index 5a1a6ce8..d918a739 100644
--- a/docs/en/document/command.md
+++ b/docs/en/document/command.md
@@ -1,12 +1,12 @@
-# Command Parameters
+# Command Line Parameters
::: tip
-Xray uses Go-style commands and parameters
+Xray uses Go-style commands and parameters.
:::
-## Get Basic Commands
+## Getting Basic Commands
-You can run `xray help`to get the most basic usage of all xray, as well as available commands and instructions.
+You can run `xray help` to get the most basic usage of Xray, as well as available commands and descriptions.
```
Xray is a platform for building proxies.
@@ -20,13 +20,16 @@ The commands are:
run Run Xray with config, the default command
version Show current version of Xray
api Call an API in an Xray process
+ convert Convert configs
tls TLS tools
- uuid Generate UUIDv4 or UUIDv5
- x25519 Generate key pair for x25519 key exchange
- wg Generate key pair for wireguard key exchange
+ uuid Generate UUIDv4 or UUIDv5 (VLESS)
+ x25519 Generate key pair for X25519 key exchange (REALITY, VLESS Encryption)
+ wg Generate key pair for X25519 key exchange (WireGuard)
+ mldsa65 Generate key pair for ML-DSA-65 post-quantum signature (REALITY)
+ mlkem768 Generate key pair for ML-KEM-768 post-quantum key exchange (VLESS Encryption)
+ vlessenc Generate decryption/encryption json pair (VLESS Encryption)
Use "xray help +You should use `xray uuid` or `uuidgen` to generate a unique UUID.
+On the server side, put it in `inbounds[0].settings.clients[0].id`.
+On the client side, put it in `outbounds[0].settings.vnext[0].users[0].id`.
+::: ## Server Configuration -You need a server outside the firewall to run server-side Xray. The configuration is as follows: +You need a server outside the firewall to run the server-side Xray. The configuration is as follows: ```json { "inbounds": [ { - "port": 10086, // The port on which the server is listening + "port": 10086, // Server listening port "protocol": "vmess", "settings": { "clients": [ { - "id": "b831381d-6324-4d53-ad4f-8cda48b30811" + "id": "b831381d-6324-4d53-ad4f-8cda48b30811" // Remember to replace this field, generate using `xray uuid` or `uuidgen` } ] } @@ -33,17 +40,17 @@ You need a server outside the firewall to run server-side Xray. The configuratio } ``` -In server configuration, it is necessary to ensure that the `id` and port are consistent with the client in order to establish a normal connection. +Ensure that the `id` and port in the server configuration match the client's, and you will be able to connect normally. ## Client Configuration -On your PC (or phone), you need to run Xray with the following configuration: +On your PC (or mobile phone), you need to run Xray with the following configuration: ```json { "inbounds": [ { - "port": 1080, // SOCKS代理端口，需要在浏览器中配置代理并指向该端口 + "port": 1080, // SOCKS proxy port. You need to configure the proxy in the browser to point to this port. "listen": "127.0.0.1", "protocol": "socks", "settings": { @@ -57,11 +64,11 @@ On your PC (or phone), you need to run Xray with the following configuration: "settings": { "vnext": [ { - "address": "server", // 服务器地址，请将其更改为您自己的服务器IP或域名 - "port": 10086, // 服务器端口 + "address": "server", // Server address. Please change to your own server IP or domain name. + "port": 10086, // Server port "users": [ { - "id": "b831381d-6324-4d53-ad4f-8cda48b30811" + "id": "b831381d-6324-4d53-ad4f-8cda48b30811" // Remember to replace this field, generate using `xray uuid` or `uuidgen` } ] } @@ -77,7 +84,7 @@ On your PC (or phone), you need to run Xray with the following configuration: "domainStrategy": "IPOnDemand", "rules": [ { - "ip": ["geoip:private"], + "ip": ["geoip:private", "geoip:cn"], // Bypass LAN and mainland China IPs "outboundTag": "direct" } ] @@ -85,14 +92,14 @@ On your PC (or phone), you need to run Xray with the following configuration: } ``` -The only thing you need to modify in the above configuration is your server's IP address, which is indicated in the configuration. This configuration will redirect all traffic to your server, except for traffic on the local area network (such as the access router). +The only places you need to change in the above configuration are your server IP and user UUID, as noted in the configuration. The above configuration will forward all traffic to your server except for LAN (e.g., accessing the router) and mainland China IP ranges (e.g., accessing Bilibili, AcFun). ## Run -- On Windows and macOS, the configuration files are usually named `config.json`. - - To start Xray, simply run `Xray` or `Xray.exe`. -- On Linux, the configuration files are usually located in `/etc/xray/` or `/usr/local/etc/xray/`. - - To start Xray, run the command `xray run -c /etc/xray/config.json`. - - Alternatively, you can use a tool like systemd to run Xray as a background service. +- In Windows and macOS, the configuration file is usually the `config.json` file in the same directory as Xray. + - Simply run `Xray` or `Xray.exe`. +- In Linux, the configuration file is usually located in the `/etc/xray/` or `/usr/local/etc/xray/` directory. + - Run `xray run -c /etc/xray/config.json`. + - Or use tools like systemd to run Xray as a service in the background. -For more detailed instructions, please refer to the [Configuration](../config/) Document and [Layman's Terms](./level-0/). +For more detailed instructions, please refer to [Configuration Documentation](../config/) and [Project X for Dummies](./level-0/). diff --git a/docs/en/document/index.md b/docs/en/document/index.md index ceda1f44..952d1cd6 100644 --- a/docs/en/document/index.md +++ b/docs/en/document/index.md @@ -1,51 +1,53 @@ ---- -sidebar: auto ---- - # Quick Start -> **This chapter will tell you how to get Xray in the easiest way and start using Xray.** +> **This chapter will show you the simplest way to obtain and start using Xray.** + +::: tip +This section has not been updated for quite a long time, so some parts may not be entirely reliable. We mainly strive to keep the configuration file documentation up to date. If you encounter any pitfalls, suggestions for modifications via PR are welcome. + +ℱ. +::: ## Download and Install -Xray supports various platforms, and you can get various versions of Xray from various sources and methods. +Xray supports a wide range of platforms, and you can obtain various versions of Xray through multiple channels and methods. -Please click [How to Download and Install Xray](./install.md) to get Xray. +Please click [Download and Install](./install.md) to get Xray. ## Configure and Run -After downloading and installing Xray, you need to configure it. +After downloading and installing Xray, you only need to configure it to start using it. -Please click [How to Configure and Run Xray](./config.md) to learn the easiest way to configure Xray. +Please click [Configure and Run](./config.md) to learn the simplest way to configure it. ## Command Parameters Xray has a variety of commands and parameters available, making it flexible and powerful. -Please click [Command Parameters for Xray](./command.md) to view more commands and parameters usages. +Please click [Command Parameters](./command.md) to view more usage details of Xray's commands and parameters. -## Improve Documents +## Improve Documentation -If you're interested, please click [Documents](./document.md) to help us improve the documents, or click the `Help us improve this page!` +If you are interested, please click [Documentation Guide](./document.md) to help us improve the documentation, or click `Help us improve this page!` at the bottom of the page. -We are very grateful to every Contributor for their contribution! You guys make Project X even stronger! +We are very grateful for the contributions made by every Contributor! It is you who make Project X more powerful! -## Beginner Tutorial +## Project X for Dummies -An easy tutorial for beginner. +User insights and guidance for beginners. -Please click [Beginner Tutorial](./level-0/) to view it. +Please click [Project X for Dummies](./level-0/) to view. -## Getting Started Tips +## Beginner Tips -After you have the basics, you can explore more ways to use them through [Getting Started Tips](./level-1/). +Once you have the basics down, you can explore more usage methods through [Beginner Tips](./level-1/). ## Advanced Documentation -Tips for advanced user guidance +Usage tips and guidance for advanced users. -Click on [Advanced Documentation](./level-2/) to view it +Click [Advanced Documentation](./level-2/) to view. -::: tip Appreciations -Thank you very much for your selfless sharing of usage skills and experience, which makes Xray more and more powerful. +::: tip Acknowledgements +Many thanks to everyone for selflessly sharing their tips and insights, making Xray increasingly powerful. ::: diff --git a/docs/en/document/install.md b/docs/en/document/install.md index d846ee17..1840d268 100644 --- a/docs/en/document/install.md +++ b/docs/en/document/install.md @@ -2,53 +2,55 @@ ## Platform Support -- Xray is available on the following platforms: - - Windows 7 and later (x86 / amd64 / arm32 / arm64); - - If you need to use these version (1.8.18 and later marked with `win7`, 1.8.6, 1.8.4) in Windows 7, operating system update **KB4474419** is required. For better Internet security, it is recommended to install KB4490628 to acquire later operating system updates from Windows Update. - - macOS 10.10 Yosemite and later (amd64 / arm64); - - Linux 2.6.23 and later (x86 / amd64 / arm / arm64 / mips64 / mips / ppc64 / s390x / riscv64); - - Including but not limited to Debian 7 / 8, Ubuntu 12.04 / 14.04 and subsequent versions, CentOS 7 / 8, Arch Linux, etc.; - - FreeBSD (x86 / amd64); - - OpenBSD (x86 / amd64); +Xray is available on the following platforms: + +- Windows 7 and later (x86 / amd64 / arm32 / arm64); + - To use regular versions 1.8.4, 1.8.6, and `win7` versions after 1.8.18 on Windows 7, the system must have the **KB4474419** update installed; it is recommended to also install KB4490628 to receive subsequent operating system security updates after connecting to the internet. + - Starting from v25, running the `win7` version on Windows 7 only requires SP1 to function normally, but installing subsequent OS security updates is still strongly recommended for networked systems. +- macOS 10.10 Yosemite and later (amd64 / arm64); +- Linux 2.6.23 and later (x86 / amd64 / arm / arm64 / mips64 / mips / ppc64 / s390x / riscv64); + - Including but not limited to Debian 7 / 8, Ubuntu 12.04 / 14.04 and later, CentOS 7 / 8, Arch Linux, etc.; +- FreeBSD (x86 / amd64); +- OpenBSD (x86 / amd64); ## Download Xray -Precompiled binaries in ZIP format are available at [GitHub Releases](https://github.com/xtls/Xray-core/releases) found in. +Pre-compiled binary ZIP archives can be found in [Github Releases](https://github.com/xtls/Xray-core/releases). -Download the compressed package of the corresponding platform, and use it after decompression. +Download the archive for your platform, extract it, and it is ready to use. -## Verify the Installation Package +## Verify Installation Packages Xray provides two verification methods: -- SHA1/SHA256 digest of the ZIP archive -- Reproducible build: Please refer to [Compile Xray](../development/intro/compile.html) +- SHA1 / SHA256 digests of the ZIP archive. +- Reproducible Builds: Please refer to [Compiling Xray](../development/intro/compile.md). -## Install on Windows +## Windows Installation -- Download the ZIP archive suitable for the Windows platform on [Github Releases](https://github.com/xtls/Xray-core/releases). After decompression, you can get an executable file `xray.exe`, and then run it with [parameters](./command) through the command line. -- By [Scoop](https://scoop.sh/) Package manager installation: Xray has been added to [Mochi](https://github.com/Qv2ray/mochi). +- Download the ZIP archive for the Windows platform from [Github Releases](https://github.com/xtls/Xray-core/releases). After extraction, you will get the executable file `xray.exe`. You can then [run it via the command line with parameters](./command). +- Install via [Scoop](https://scoop.sh) package manager: Xray has been added to [Mochi](https://github.com/Qv2ray/mochi). -## Install on macOS +## macOS Installation -- Download the ZIP archive suitable for the macOS platform on [Github Releases](https://github.com/xtls/Xray-core/releases). After decompression, you can get an executable file `xray`, and then run it with [parameters](./command) through the command line. -- By [Homebrew](https://brew.sh/) Package manager installation: `brew install xray` -- [homebrew-xray](https://github.com/N4FA/homebrew-xray): Thanks [@N4FA](https://github.com/N4FA) +- Download the ZIP archive for the macOS platform from [Github Releases](https://github.com/xtls/Xray-core/releases). After extraction, you will get the executable file `xray`. You can then [run it via the command line with parameters](./command.md). +- Install via [Homebrew](https://brew.sh) package manager: `brew install xray` +- [homebrew-xray](https://github.com/N4FA/homebrew-xray) thanks to [@N4FA](https://github.com/N4FA). -## Install on Linux +## Linux Installation -### Install Script +### Installation Scripts - Linux Script - - [XTLS/Xray-install](https://github.com/XTLS/Xray-install) (**Official**) - - [tempest](https://github.com/team-cloudchaser/tempest) (supports [`systemd`](https://systemd.io) and [OpenRC](https://github.com/OpenRC/openrc); Linux-only) + - [XTLS/Xray-install](https://github.com/XTLS/Xray-install) (**Official Script**) + - [tempest](https://github.com/team-cloudchaser/tempest) (Supports [`systemd`](https://systemd.io) and [OpenRC](https://github.com/OpenRC/openrc); Linux only) -* One Click +- One Click - [Xray-REALITY](https://github.com/zxcvos/Xray-script), [xray-reality](https://github.com/sajjaddg/xray-reality), [reality-ezpz](https://github.com/aleskxyz/reality-ezpz) - [Xray_bash_onekey](https://github.com/hello-yunshu/Xray_bash_onekey), [XTool](https://github.com/LordPenguin666/XTool) - [v2ray-agent](https://github.com/mack-a/v2ray-agent), [Xray_onekey](https://github.com/wulabing/Xray_onekey), [ProxySU](https://github.com/proxysu/ProxySU) -* Magisk +- Magisk - [Xray4Magisk](https://github.com/Asterisk4Magisk/Xray4Magisk) - [Xray_For_Magisk](https://github.com/E7KMbb/Xray_For_Magisk) @@ -56,15 +58,15 @@ Xray provides two verification methods: #### Arch User Repository -Need to use [AUR helpers](https://wiki.archlinux.org/index.php/AUR_helpers), [yay](https://github.com/Jguer/yay) as an example, it can be installed via `yay -S xray`. +Requires [AUR helpers](https://wiki.archlinux.org/index.php/AUR_helpers). Taking [yay](https://github.com/Jguer/yay) as an example, you can install via `yay -S xray`. #### Arch Linux CN -First add [Arch Linux CN](https://www.archlinuxcn.org/archlinux-cn-repo-and-mirror/) repository, and then use the root user `pacman -S xray`to install. +First add the [Arch Linux CN repository](https://www.archlinuxcn.org/archlinux-cn-repo-and-mirror/), then install using `pacman -S xray` under the root user. ### Linuxbrew -The Linuxbrew package manager is used in the same way as Homebrew: `brew install xray` +The usage of the Linuxbrew package manager is consistent with Homebrew: `brew install xray` ### Debian
Enter the main heading, usually the same as the title.
-Be bold in stating your key points. Put them in a list:
--
-
- The first item in your list -
- The second item; italicize key words -
Improve your image by including an image.
-
- 
-
- Add a link to your favorite - Web site. Break up your page - with a horizontal rule or two. -
--
- Finally, link to another page in your own Web - site. -
- -© Wiley Publishing, 2011
- - - ``` + d. Enter the command from step a again to verify. If the output is as follows, it means Nginx traffic has been allowed by the firewall, and you should be able to see the Nginx default page mentioned in point 2. -5. Modify `nginx.conf` and restart the `Nginx` service, directing the http access on port 80 to the newly created `html` page. - 1. Modify `nginx.conf`. + ```shell + Status: active + To Action From + -- ------ ---- + 22/tcp ALLOW Anywhere + Nginx Full ALLOW Anywhere + 22/tcp (v6) ALLOW Anywhere (v6) + Nginx Full (v6) ALLOW Anywhere (v6) + ``` - ```shell - sudo nano /etc/nginx/nginx.conf - ``` +## 5.3 Create a Very Simple Web Page - 2. Add the following content inside`http{}`, then save (`ctrl+o`) and exit (`ctrl+x`). (Remember to replace the domain name with the real domain name you prepared earlier, including the subdomain) +1. **Basic Linux Commands for Beginners:** - ``` + | Code | Command Name | Description | + | :---: | :---: | :---: | + | `cmd-10` | `mkdir` | Create a new directory | + | `cmd-11` | `systemctl reload` | Reload a service | + +2. **Basic Linux Configuration Files for Beginners:** + + | Code | File Location | Description | + | :---: | :---: | :---: | + | `conf-02` | `/etc/nginx/nginx.conf` | Nginx program settings | + +3. Create a dedicated folder for the website `/home/vpsadmin/www/webpage/` and create the webpage file `index.html`. + + ```shell + mkdir -p ~/www/webpage/ && nano ~/www/webpage/index.html + ``` + + ::: warning + If you are not using the username `vpsadmin`, please understand the meaning of the `“~”` symbol in this command (this relates to the content you will write in [Step 5]): + + - If you are a [non-root user], `“~”` is equivalent to `/home/username`. + - If you are the [root user], `“~”` is equivalent to `/root`. + ::: + +4. Copy the content below completely into the file, then save (`ctrl+o`) and exit (`ctrl+x`). + + ```html + + +Enter the main heading, usually the same as the title.
+Be bold in stating your key points. Put them in a list:
+-
+
- The first item in your list +
- The second item; italicize key words +
Improve your image by including an image.
+
+ )
+
+ Add a link to your favorite + Web site. Break up your page + with a horizontal rule or two. +
++
+ Finally, link to another page in your own Web + site. +
+© Wiley Publishing, 2011
+ + + ``` + + Grant read permissions to other users for this file: + + ```shell + chmod -R a+r . + ``` + +5. Modify `nginx.conf` and restart the `Nginx` service to point http access on port `80` to the `html` page just created. + + 1. Modify `nginx.conf`. + + ```shell + sudo nano /etc/nginx/nginx.conf + ``` + + 2. Add the following segment inside `http{}`, then save (`ctrl+o`) and exit (`ctrl+x`). (Remember to replace the domain name with the real domain name including the subdomain you prepared earlier). + + ```nginx server { listen 80; - server_name subdomain.your_domain.com; + server_name subdomain.yourdomain.com; root /home/vpsadmin/www/webpage; index index.html; } - ``` + ``` - ::: warning Be extra careful! - As mentioned in Step 3 of section 5.3, make sure to change `/home/vpsadmin/www/webpage` to your actual file path. - ::: + ::: warning Special Note! + As mentioned in my hint in [Step 3], please make sure `/home/vpsadmin/www/webpage` is changed to your actual file path. + ::: - 3. Make `nginx` reload the configuration to take effect. + 3. Reload the `nginx` configuration to make it effective. - ```shell - sudo systemctl reload nginx - ``` + ```shell + sudo systemctl reload nginx + ``` - 4. The complete setup process is as follows: + 4. The complete setup process is shown below: -  +  - 5. Now, if you visit `http://subdomain.your_domain.com`, you should see this page, indicating success: + 5. Now, if you visit `http://subdomain.yourdomain.com` and see a page like this, it means success: -  +  -## 5.4 Common error explanations +## 5.4 Explanation of Common Errors -First of all, if you follow the instructions in the article step by step and are careful enough, you will definitely not encounter any errors. So, I don't intend to change how this article is written. +First, if you followed the instructions in the article step by step and were careful enough, you definitely wouldn't encounter errors. Therefore, I do not intend to modify how this article is written. -Then why do some students still get stuck at this step, and the web page just won't open? There are basically two words: **carelessness**. Because there are only two possible issues with the configuration here, and there are only two reasons for them. +So why do many students still get stuck at this step and can't open the webpage? Basically, it comes down to one word: **carelessness**. There are only two potential configuration problems here, and only two causes. -I. Two types of issues: +**I. Two Problems:** -- In `nginx.conf`, the `/home/vpsadmin/www/webpage` does not match the actual file path; `nginx` cannot find the file -- The path is correct, but `nginx` doesn't have permission to access it +- The path `/home/vpsadmin/www/webpage` in `nginx.conf` does not match your actual file path, so `nginx` cannot find the file. +- The path is correct, but `nginx` does not have permission to read it. -II. Two reasons: +**II. Two Causes:** -- Use a **non-root user** but still directly copy the commands in the text without modification. (This is basically like copying the name of another student when copying answers) -- Insist on using a **root user** +- Using a [non-root user] but still copying the commands from the article directly without modification. (This is basically like copying a classmate's name along with their answers during a test). +- Insisting on using the [root user]. -If you encounter any errors, please carefully review the explanations in Steps 3 and 5-2 of Section 5.3. +Students encountering errors should look back carefully at the instructions in [Step 3] and [Step 5-2] of section [5.3]. ::: warning -In the early stages of this article, a lot of space has been devoted to explaining the importance of using a **non-root user** for security, and the entire article is written based on this premise. So, issues caused by using a **root user** are not within the scope of this article. +Earlier in this article, a significant amount of space was dedicated to explaining the importance of using a [non-root user] for security, and the entire text is written based on this premise. Therefore, problems caused by using the [root user] are not within the scope of this article's design. -But I believe that students who persist in using the `root` user should have their own opinions, strong hands-on ability, or have a certain foundation in Linux. I have already explained the crux of the problem, and I believe you can solve it on your own. +However, I believe that students who insist on using the [root user] likely have their own opinions, strong hands-on abilities, or a certain Linux foundation. I have explained the crux of the problem, and I trust you can solve it on your own. +::: ## 5.5 Your Progress -So far, Xray's first infrastructure [webpage] has been established. Let's now move on to the second infrastructure [certificate]! +At this point, Xray's first infrastructure component, the [Website], is in place. We will immediately move on to the second infrastructure component: [Certificates]! > ⬛⬛⬛⬛⬛⬜⬜⬜ 62.5% diff --git a/docs/en/document/level-0/ch06-certificates.md b/docs/en/document/level-0/ch06-certificates.md index b1d806cb..132bbcce 100644 --- a/docs/en/document/level-0/ch06-certificates.md +++ b/docs/en/document/level-0/ch06-certificates.md @@ -2,222 +2,173 @@ ## 6.1 Applying for a TLS Certificate -Next, we need to apply for a real TLS certificate for our domain name, so that the website has the ability to encrypt with standard TLS and the ability to access via HTTPS. This is the most important tool for Xray and other current security proxy tools to ensure fully encrypted traffic. +Next, we need to apply for a real TLS certificate for our domain name. This enables standard TLS encryption and HTTPS access for the website. This is the most crucial tool for modern secure proxy tools like Xray to ensure traffic is fully encrypted. ::: warning -Please do not use self-signed certificates lightly. It does not make the operation much simpler, but adds unnecessary risks (such as man-in-the-middle attacks). +Please do not use self-signed certificates lightly. They don't make the operation much simpler, but they add senseless risks (such as Man-in-the-Middle attacks). ::: -Here, I will use a certificate management tool called [`acme.sh`](https://github.com/acmesh-official/acme.sh), which is simple, lightweight, efficient, and capable of automatically updating certificates. +Here, I will use a certificate management tool called [`acme.sh`](https://github.com/acmesh-official/acme.sh). It is simple, lightweight, efficient, and handles automatic certificate renewals. -In addition, I believe that you have gradually become familiar with the basic operations of Linux. Therefore, from this chapter on, commands that have appeared multiple times will no longer have screenshots and will only be briefly described. If you really can't remember how to use them, just review the previous chapters. +Additionally, I trust that by now you are gradually becoming familiar with basic Linux operations. Therefore, starting from this chapter, commands that have appeared multiple times will no longer be accompanied by screenshots, but only simple descriptions. If you really can't remember how to use them, please review the previous chapters. -## 6.2 Install `acme.sh` +## 6.2 Installing `acme.sh` -1. Basic Linux commands for beginners: - | Number | Command | Description | - | :------: | :-------: | :------------------------------------------------: | - | `cmd-12` | `wget` | Retrieve (or download) a webpage file | - | `cmd-13` | `acme.sh` | Commands related to acme.sh certificate management | +1. Basic Linux Commands for Beginners: -2. Run the installation script. + | ID | Command | Description | + |:--:|:--:|:--:| + | `cmd-12` | `wget` | Visit (or download) a web file | + | `cmd-13` | `acme.sh` | Commands related to acme.sh certificate management | -```shell -wget -O - https://get.acme.sh | sh -``` +2. Run the installation script -3. Make the `acme.sh` command effective. + ```shell + wget -O - [https://get.acme.sh](https://get.acme.sh) | sh + ``` -```shell -. .bashrc -``` +3. Make the `acme.sh` command effective -(Note: This command is used to source (load) the `.bashrc` file in the shell environment.) + ```shell + . .bashrc + ``` -4. Enable `acme.sh` automatic upgrade. +4. Enable auto-upgrade for `acme.sh` -```shell -acme.sh --upgrade --auto-upgrade -``` + ```shell + acme.sh --upgrade --auto-upgrade + ``` -5. The complete process up to this point is shown in the following diagram: +5. The complete process up to this step is shown below: - +  -## 6.3 Testing Certificate Application +## 6.3 Testing Certificate Issuance -Before officially applying for the certificate, we use the testing command (`--issue --server letsencrypt_test`) to verify if the application can be successfully submitted. This can avoid repeated failures in applying for a certificate due to incorrect local configuration, exceeding the frequency limit of Let's Encrypt (such as a maximum of 5 failures per hour, per domain, or per user), which may prevent the subsequent steps from being carried out. +Before officially applying for a certificate, let's use a test command (`--issue --server letsencrypt_test`) to verify if the application can be successful. This avoids repeated failures due to local configuration errors, which could exceed Let's Encrypt's frequency limits (e.g., maximum of 5 failures per hour, per domain, per user), blocking subsequent steps. -1. The command to apply for a test certificate is as follows (this article uses ECC certificate as an example, because there is really no reason not to use it nowadays): +1. The command to test certificate issuance is as follows (This article uses `ECC` certificates as an example, because nowadays, there is really no reason not to use them): -```shell -acme.sh --issue --server letsencrypt_test -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 -``` + ```shell + acme.sh --issue --server letsencrypt_test -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 + ``` -(Note: This is a command in shell script for obtaining SSL certificate from Let's Encrypt CA using ACME protocol. It specifies the test server, the subdomain for which the certificate is requested, the webroot directory of the subdomain, and the key length to use for the certificate.) + ::: warning Note + The main advantage of `ECC` certificates lies in their smaller Key size, which means improved security and faster encryption/decryption speeds for the same size. For instance, the strength of ECC-256bit is roughly equivalent to RSA-3072bit, so why not? Of course, some say ECC certificate handshakes are noticeably faster; I think that's a bit of an exaggeration. RSA handshakes aren't that slow, and even if there is a difference, it should be in milliseconds, which is hard to perceive directly. -::: warning Explanation -The main advantage of the `ECC` certificate is that its `Keysize` is smaller, which means that security is improved and encryption and decryption speed is faster for the same size. Why not choose ECC-256bit, which is approximately equivalent to RSA-3072bit in strength? Of course, some people say that the ECC certificate handshake is significantly faster, which I think is a bit exaggerated, because RSA handshake is not too slow either. Even if there is a difference, it should be in milliseconds and difficult to perceive directly. + However, if some websites specifically need to be compatible with very ancient devices, please choose `RSA` certificates as needed. + ::: -In addition, if some websites do need to be compatible with certain old devices, please still choose RSA certificates according to your needs. +2. You should ultimately see a log similar to this: -2. You should eventually see a prompt similar to this: + ```log + [Wed 30 Dec 2022 04:25:12 AM EST] Using ACME_DIRECTORY: [https://acme-staging-v02.api.letsencrypt.org/directory](https://acme-staging-v02.api.letsencrypt.org/directory) + [Wed 30 Dec 2022 04:25:13 AM EST] Using CA: [https://acme-staging-v02.api.letsencrypt.org/directory](https://acme-staging-v02.api.letsencrypt.org/directory) + [Wed 30 Dec 2022 04:25:13 AM EST] Create account key ok. + [Wed 30 Dec 2022 04:25:13 AM EST] Registering account: [https://acme-staging-v02.api.letsencrypt.org/directory](https://acme-staging-v02.api.letsencrypt.org/directory) + [Wed 30 Dec 2022 04:25:13 AM EST] Registered + [Wed 30 Dec 2022 04:25:13 AM EST] ACCOUNT_THUMBPRINT='CU6qmPKuRqhyTAIrF4swosR375194z_1ddUlWef8xDc' + [Wed 30 Dec 2022 04:25:13 AM EST] Creating domain key + [Wed 30 Dec 2022 04:25:13 AM EST] The domain key is here: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key + [Wed 30 Dec 2022 04:25:13 AM EST] Single domain='subdomain.yourdomain.com' + [Wed 30 Dec 2022 04:25:13 AM EST] Getting domain auth token for each domain + [Wed 30 Dec 2022 04:25:14 AM EST] Getting webroot for domain='subdomain.yourdomain.com' + [Wed 30 Dec 2022 04:25:14 AM EST] Verifying: subdomain.yourdomain.com + [Wed 30 Dec 2022 04:25:23 AM EST] Pending + [Wed 30 Dec 2022 04:25:25 AM EST] Success + [Wed 30 Dec 2022 04:25:25 AM EST] Verify finished, start to sign. + [Wed 30 Dec 2022 04:25:25 AM EST] Lets finalize the order. + [Wed 30 Dec 2022 04:25:25 AM EST] Le_OrderFinalize='[https://acme-staging-v02.api.letsencrypt.org/acme/finalize/490205995/7730242871](https://acme-staging-v02.api.letsencrypt.org/acme/finalize/490205995/7730242871)' + [Wed 30 Dec 2022 04:25:25 AM EST] Downloading cert. + [Wed 30 Dec 2022 04:25:25 AM EST] Le_LinkCert='[https://acme-staging-v02.api.letsencrypt.org/acme/cert/xujss5xt8i38waubafz2xujss5xt8i38waubz2](https://acme-staging-v02.api.letsencrypt.org/acme/cert/xujss5xt8i38waubafz2xujss5xt8i38waubz2)' + [Wed 30 Dec 2022 15:21:52 AM EST] Cert success. + --BEGIN CERTIFICAT-- + sxlYqPvWreKgD5b8JyOQX0Yg2MLoRUoDyqVkd31PthIiwzdckoh5eD3JU7ysYBtN + cTFK4LGOfjqi8Ks87EVJdK9IaSAu7ZC6h5to0eqpJ5PLhaM3e6yJBbHmYA8w1Smp + wAb3tdoHZ9ttUIm9CrSzvDBt6BBT6GqYdDamMyCYBLooMyDEM4CUFsOzCRrEqqvC + ... (omitted for brevity) ... + yiLKcBFc5H7dgJCImo7us7aJeftC44uWkPIjw9AKH= + --END CERTIFICAT-- + [Wed 30 Dec 2022 15:21:52 AM EST] Your cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.cer + [Wed 30 Dec 2022 15:21:52 AM EST] Your cert key is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key + [Wed 30 Dec 2022 15:21:52 AM EST] The intermediate CA cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/ca.cer + [Wed 30 Dec 2022 15:21:52 AM EST] And the full chain certs is there: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/fullchain.cer + ``` -```log -[Wed 30 Dec 2022 04:25:12 AM EST] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory -[Wed 30 Dec 2022 04:25:13 AM EST] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory -[Wed 30 Dec 2022 04:25:13 AM EST] Create account key ok. -[Wed 30 Dec 2022 04:25:13 AM EST] Registering account: https://acme-staging-v02.api.letsencrypt.org/directory -[Wed 30 Dec 2022 04:25:13 AM EST] Registered -[Wed 30 Dec 2022 04:25:13 AM EST] ACCOUNT_THUMBPRINT='CU6qmPKuRqhyTAIrF4swosR375194z_1ddUlWef8xDc' -[Wed 30 Dec 2022 04:25:13 AM EST] Creating domain key -[Wed 30 Dec 2022 04:25:13 AM EST] The domain key is here: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key -[Wed 30 Dec 2022 04:25:13 AM EST] Single domain='subdomain.yourdomain.com' -[Wed 30 Dec 2022 04:25:13 AM EST] Getting domain auth token for each domain -[Wed 30 Dec 2022 04:25:14 AM EST] Getting webroot for domain='subdomain.yourdomain.com' -[Wed 30 Dec 2022 04:25:14 AM EST] Verifying: subdomain.yourdomain.com -[Wed 30 Dec 2022 04:25:23 AM EST] Pending -[Wed 30 Dec 2022 04:25:25 AM EST] Success -[Wed 30 Dec 2022 04:25:25 AM EST] Verify finished, start to sign. -[Wed 30 Dec 2022 04:25:25 AM EST] Lets finalize the order. -[Wed 30 Dec 2022 04:25:25 AM EST] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/490205995/7730242871' -[Wed 30 Dec 2022 04:25:25 AM EST] Downloading cert. -[Wed 30 Dec 2022 04:25:25 AM EST] Le_LinkCert='https://acme-staging-v02.api.letsencrypt.org/acme/cert/xujss5xt8i38waubafz2xujss5xt8i38waubz2' -[Wed 30 Dec 2022 15:21:52 AM EST] Cert success. ---BEGIN CERTIFICAT-- -sxlYqPvWreKgD5b8JyOQX0Yg2MLoRUoDyqVkd31PthIiwzdckoh5eD3JU7ysYBtN -cTFK4LGOfjqi8Ks87EVJdK9IaSAu7ZC6h5to0eqpJ5PLhaM3e6yJBbHmYA8w1Smp -wAb3tdoHZ9ttUIm9CrSzvDBt6BBT6GqYdDamMyCYBLooMyDEM4CUFsOzCRrEqqvC -2mTTEmhvpojo5rhdTSJxibozyNWTGwoTj0v9pTUeQcGqLIzqi4DowjBHD5guwRid -SjAFnm6JT2xUQgWFm58A1gv1OhbH1TRPUUmtE1nFEN7YiSjI4xgxqAXT3CLD2EUb -wXlUrO6c75zSsQP4bRMzgOjJUqHtSb6IEqELzt4M7KzL5iCOruCChCo2DZxUwvVX -tOoaAyQJzCbTqE6aUqwiKi3gVyoxvDP9mI5JdRYzsDL6GVud7EHPnYeMl9ubLZAK -0vg84mbMP3f6mYM4KRa1cqiyOIcQPT4AzGFYVv4sm049bZQg7sd0Bz9CaFvE7yDA -1y17XlgCDnsjxl66bqI1vkENN9XT5xeFHONqc18b5fZEKSIvdX7iWPFWp1PyMPpG -0pMCP1EymZNFxIMJLgbWqExwLWfPc5Ib3PjBaIqhXPnw6sT2MQSxXwDupq1UJVhV -7E3hQRVlwI4CXi6WLHJMNvNRyyK87gCrLH1bKYsPeRVaz77poWBq49zwBCts6hPY -IeF4ltGXyANNIOPEi8vy138fRU4LYh81d8FjOtFfJZogMjwhfNvapqxPMsioPlmX -TnZu0n7setrVNUEfTMHWqPpDgk5MPrWLA4LapqaDfEX4pwnQJLMwMi6s94z165c0 -iMRSKA1yU5zqv8aNsDfPoY4OkSPWs4MaXgRRSLBsUfZ15DwQXPk76kegHIyxWvwF -tYw9HKR5QCMK66fa0z4aJoFVFLK0IIOGEZOanRFUCnkLUDd3QZ3YU8lEcrj7Uxos -haiRNICyC6UfsCJ94a8vcNyMosPv3xBLMp19WXgiFYqEFQkntkv1FLRI35fjeJmg -0fmD9VG9bkzGPHihJgQLRlCHasGf6XrdfkSsODAyCUHUHJ0RzqF4YEZMcxDxzuQ2 -YO7bFwj7S3mUdVPZ6MPasjxdyBjJgEBMch2uy4AhmudXfEBQBye8W6ZI4ztZjLVV -FmP4SIuaNUmMe20TjR8b9NVC96AhxOanWT3mRROsdokpKQGTJvl27EHH8KuAbUOc -G6KtPy4wslNZNXWcBy9n63RcWak12r7kAIFn38tZxmlw2WUKoRSMAH64GcDTjRQd -Am65hBHzvGrj93wEuVNIebvNIsJOlng3HFjpIxVqKGMCIfWIKGDE3YzK3p4LbGZ6 -NZFQWYJLNVf2M9CCJfbEImPYgvctrxl39H6KVYPCw1SAdaj9NneUqmREOQkKoEB0 -x6PmNirbMscHhQPSC0JQaqUgaQFgba1ALmzRYAnYhNb0twkTxWbY7DBkAarxqMIp -yiLKcBFc5H7dgJCImo7us7aJeftC44uWkPIjw9AKH= ---END CERTIFICAT-- -[Wed 30 Dec 2022 15:21:52 AM EST] Your cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.cer -[Wed 30 Dec 2022 15:21:52 AM EST] Your cert key is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key -[Wed 30 Dec 2022 15:21:52 AM EST] The intermediate CA cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/ca.cer -[Wed 30 Dec 2022 15:21:52 AM EST] And the full chain certs is there: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/fullchain.cer -``` +3. Note: What we applied for here is a test certificate. It cannot be used directly; it merely proves that your domain and configuration are all correct. Look closely, and you will find that the issuer domain is `https://acme-staging-v02.api.letsencrypt.org`. You can understand this `staging` as the "Test Server"! -3. Note: The certificate applied for here is a test certificate, which cannot be used directly. It is only used to prove that your domain and configuration are correct. If you observe carefully, you will find that the domain that issues the certificate to you is `https://acme-staging-v02.api.letsencrypt.org`, and this `staging` can be understood as a "test server"! +4. If an error occurs in this step, you can run the following command to view the detailed application process and specific errors. (If you don't understand it, hide sensitive information and ask in the Xray community group). -4. If this step goes wrong, you can run the following command to check the detailed application process and specific errors. If you don't understand, you can hide sensitive information and ask in the Xray group. + ```shell + acme.sh --issue --server letsencrypt_test -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 --debug + ``` -```shell -acme.sh --issue --server letsencrypt_test -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 --debug -``` + Yes, that's right, just add a `--debug` parameter at the end of the command. -(Note: This command is written in Chinese characters, therefore I have translated it into English. The command is used to issue SSL/TLS certificates using acme.sh client with Let's Encrypt CA in test mode for a subdomain of your domain with the specified webroot path, key length and in debug mode.) +5. After confirming this step is successful, you can apply for the official certificate. (You don't need to delete the test certificate; it will be automatically overwritten by the official certificate). -Hmm, that's right. Just added a `--debug` parameter at the end of the command. +## 6.4 Official Certificate Issuance -5. Once this step is confirmed to be successful, you can apply for the formal certificate. (The test certificate does not need to be deleted, as it will be automatically replaced by the formal certificate.) +1. The command to apply for the official certificate is as follows (change the `--server letsencrypt_test` parameter to `--server letsencrypt`, and add the `--force` parameter at the end): -## 6.4 Application for Official Certification + ```shell + acme.sh --set-default-ca --server letsencrypt + ``` -1. The command for applying for an official certificate is as follows (i.e., replace `letsencrypt_test` with `letsencrypt` and add the `--force` parameter at the end): + ```shell + acme.sh --issue -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 --force + ``` -```shell -acme.sh --set-default-ca --server letsencrypt -``` + ::: warning Note + The `--force` parameter means to manually (forcefully) update the certificate before the existing certificate expires. Although the certificate we applied for from the "Test Server" in the previous step cannot be used directly, it has not yet expired, so this parameter is needed. + ::: -This is a command in the shell language. It sets the default Certificate Authority (CA) to Let's Encrypt by using the `acme.sh` script. +2. You should ultimately see a log very similar to the one above: -```shell -acme.sh --issue -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 --force -``` + ```log + vpsadmin@vps-server:~$ acme.sh --issue -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 + [Wed 30 Dec 2022 15:22:51 AM EST] Using CA: [https://acme-v02.api.letsencrypt.org/directory](https://acme-v02.api.letsencrypt.org/directory) + [Wed 30 Dec 2022 15:22:51 AM EST] Creating domain key + [Wed 30 Dec 2022 15:22:51 AM EST] The domain key is here: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key + [Wed 30 Dec 2022 15:22:51 AM EST] Single domain='subdomain.yourdomain.com' + [Wed 30 Dec 2022 15:22:51 AM EST] Getting domain auth token for each domain + [Wed 30 Dec 2022 15:22:51 AM EST] Getting webroot for domain='subdomain.yourdomain.com' + [Wed 30 Dec 2022 15:22:51 AM EST] Verifying: subdomain.yourdomain.com + [Wed 30 Dec 2022 15:22:51 AM EST] Pending + [Wed 30 Dec 2022 15:22:51 AM EST] Success + [Wed 30 Dec 2022 15:22:51 AM EST] Verify finished, start to sign. + [Wed 30 Dec 2022 15:22:51 AM EST] Lets finalize the order. + [Wed 30 Dec 2022 15:22:51 AM EST] Le_OrderFinalize='[https://acme-v02.api.letsencrypt.org/acme/finalize/490205996/7730242872](https://acme-v02.api.letsencrypt.org/acme/finalize/490205996/7730242872)' + [Wed 30 Dec 2022 15:22:51 AM EST] Downloading cert. + [Wed 30 Dec 2022 15:22:51 AM EST] Le_LinkCert='[https://acme-v02.api.letsencrypt.org/acme/cert/vsxvk0oldnuobe51ayxz4dms62sk2dwmw9zhuw](https://acme-v02.api.letsencrypt.org/acme/cert/vsxvk0oldnuobe51ayxz4dms62sk2dwmw9zhuw)' + [Wed 30 Dec 2022 15:22:51 AM EST] Cert success. + --BEGIN CERTIFICAT-- + sxlYqPvWreKgD5b8JyOQX0Yg2MLoRUoDyqVkd31PthIiwzdckoh5eD3JU7ysYBtN + cTFK4LGOfjqi8Ks87EVJdK9IaSAu7ZC6h5to0eqpJ5PLhaM3e6yJBbHmYA8w1Smp + ... (omitted for brevity) ... + yiLKcBFc5H7dgJCImo7us7aJeftC44uWkPM= + --END CERTIFICAT-- + [Wed 30 Dec 2022 15:22:52 AM EST] Your cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.cer + [Wed 30 Dec 2022 15:22:52 AM EST] Your cert key is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key + [Wed 30 Dec 2022 15:22:52 AM EST] The intermediate CA cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/ca.cer + [Wed 30 Dec 2022 15:22:52 AM EST] And the full chain certs is there: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/fullchain.cer + ``` -(Note: This is a command written in shell script that requests a SSL certificate from ACME server using the ACME client "acme.sh". It specifies the subdomain of the domain name, the web root directory of the website, the key length, and forces the re-issuance of the certificate.) - -::: warning Explanation -The meaning of the `--force` parameter is to manually (forcefully) update the certificate before the existing certificate expires. Although the certificate we applied for from the "test server" in the previous step cannot be used directly, it has not expired yet, so this parameter is needed. -::: - -2. You should eventually see a prompt that looks similar to the one above. - -```log -vpsadmin@vps-server:~$ acme.sh --issue -d subdomain.yourdomain.com -w /home/vpsadmin/www/webpage --keylength ec-256 -[Wed 30 Dec 2022 15:22:51 AM EST] Using CA: https://acme-v02.api.letsencrypt.org/directory -[Wed 30 Dec 2022 15:22:51 AM EST] Creating domain key -[Wed 30 Dec 2022 15:22:51 AM EST] The domain key is here: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key -[Wed 30 Dec 2022 15:22:51 AM EST] Single domain='subdomain.yourdomain.com' -[Wed 30 Dec 2022 15:22:51 AM EST] Getting domain auth token for each domain -[Wed 30 Dec 2022 15:22:51 AM EST] Getting webroot for domain='subdomain.yourdomain.com' -[Wed 30 Dec 2022 15:22:51 AM EST] Verifying: subdomain.yourdomain.com -[Wed 30 Dec 2022 15:22:51 AM EST] Pending -[Wed 30 Dec 2022 15:22:51 AM EST] Success -[Wed 30 Dec 2022 15:22:51 AM EST] Verify finished, start to sign. -[Wed 30 Dec 2022 15:22:51 AM EST] Lets finalize the order. -[Wed 30 Dec 2022 15:22:51 AM EST] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/490205996/7730242872' -[Wed 30 Dec 2022 15:22:51 AM EST] Downloading cert. -[Wed 30 Dec 2022 15:22:51 AM EST] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/vsxvk0oldnuobe51ayxz4dms62sk2dwmw9zhuw' -[Wed 30 Dec 2022 15:22:51 AM EST] Cert success. ---BEGIN CERTIFICAT-- -sxlYqPvWreKgD5b8JyOQX0Yg2MLoRUoDyqVkd31PthIiwzdckoh5eD3JU7ysYBtN -cTFK4LGOfjqi8Ks87EVJdK9IaSAu7ZC6h5to0eqpJ5PLhaM3e6yJBbHmYA8w1Smp -wAb3tdoHZ9ttUIm9CrSzvDBt6BBT6GqYdDamMyCYBLooMyDEM4CUFsOzCRrEqqvC -2mTTEmhvpojo5rhdTSJxibozyNWTGwoTj0v9pTUeQcGqLIzqi4DowjBHD5guwRid -SjAFnm6JT2xUQgWFm58A1gv1OhbH1TRPUUmtE1nFEN7YiSjI4xgxqAXT3CLD2EUb -wXlUrO6c75zSsQP4bRMzgOjJUqHtSb6IEqELzt4M7KzL5iCOruCChCo2DZxUwvVX -tOoaAyQJzCbTqE6aUqwiKi3gVyoxvDP9mI5JdRYzsDL6GVud7EHPnYeMl9ubLZAK -0vg84mbMP3f6mYM4KRa1cqiyOIcQPT4AzGFYVv4sm049bZQg7sd0Bz9CaFvE7yDA -1y17XlgCDnsjxl66bqI1vkENN9XT5xeFHONqc18b5fZEKSIvdX7iWPFWp1PyMPpG -0pMCP1EymZNFxIMJLgbWqExwLWfPc5Ib3PjBaIqhXPnw6sT2MQSxXwDupq1UJVhV -7E3hQRVlwI4CXi6WLHJMNvNRyyK87gCrLH1bKYsPeRVaz77poWBq49zwBCts6hPY -IeF4ltGXyANNIOPEi8vy138fRU4LYh81d8FjOtFfJZogMjwhfNvapqxPMsioPlmX -TnZu0n7setrVNUEfTMHWqPpDgk5MPrWLA4LapqaDfEX4pwnQJLMwMi6s94z165c0 -iMRSKA1yU5zqv8aNsDfPoY4OkSPWs4MaXgRRSLBsUfZ15DwQXPk76kegHIyxWvwF -tYw9HKR5QCMK66fa0z4aJoFVFLK0IIOGEZOanRFUCnkLUDd3QZ3YU8lEcrj7Uxos -haiRNICyC6UfsCJ94a8vcNyMosPv3xBLMp19WXgiFYqEFQkntkv1FLRI35fjeJmg -0fmD9VG9bkzGPHihJgQLRlCHasGf6XrdfkSsODAyCUHUHJ0RzqF4YEZMcxDxzuQ2 -YO7bFwj7S3mUdVPZ6MPasjxdyBjJgEBMch2uy4AhmudXfEBQBye8W6ZI4ztZjLVV -FmP4SIuaNUmMe20TjR8b9NVC96AhxOanWT3mRROsdokpKQGTJvl27EHH8KuAbUOc -G6KtPy4wslNZNXWcBy9n63RcWak12r7kAIFn38tZxmlw2WUKoRSMAH64GcDTjRQd -Am65hBHzvGrj93wEuVNIebvNIsJOlng3HFjpIxVqKGMCIfWIKGDE3YzK3p4LbGZ6 -NZFQWYJLNVf2M9CCJfbEImPYgvctrxl39H6KVYPCw1SAdaj9NneUqmREOQkKoEB0 -x6PmNirbMscHhQPSC0JQaqUgaQFgba1ALmzRYAnYhNb0twkTxWbY7DBkAarxqMIp -yiLKcBFc5H7dgJCImo7us7aJeftC44uWkPM= ---END CERTIFICAT-- -[Wed 30 Dec 2022 15:22:52 AM EST] Your cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.cer -[Wed 30 Dec 2022 15:22:52 AM EST] Your cert key is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/subdomain.yourdomain.com.key -[Wed 30 Dec 2022 15:22:52 AM EST] The intermediate CA cert is in /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/ca.cer -[Wed 30 Dec 2022 15:22:52 AM EST] And the full chain certs is there: /home/vpsadmin/.acme.sh/subdomain.yourdomain.com_ecc/fullchain.cer -``` - -3. If you observe carefully, you will find that the domain name that issues the certificate to you this time is `https://acme-v02.api.letsencrypt.org`, which lacks the word `staging`. Therefore, this is the [Production Environment]! +3. Look closely, and you will find that the issuer domain this time is `https://acme-v02.api.letsencrypt.org`. The `staging` is gone, which naturally means it is the "Official Server" (Production)! ## 6.5 Certificate Installation -1. After completing the certificate application, it needs to be installed to a specified location and referenced in the configuration file to take effect: +1. After the certificate application is complete, it needs to be installed. Install it to the specified location and reference it in the configuration file: -```shell -vpsadmin@vps-server:~$ acme.sh --installcert -d subdomain.yourdomain.com --cert-file /path/to/install/cert.crt --key-file /path/to/install/cert.key --fullchain-file /path/to/install/fullchain.crt --ecc -[Mon 14 Feb 2022 03:00:25 PM CST] Installing cert to: /etc/xray/cert/cert.crt -[Mon 14 Feb 2022 03:00:25 PM CST] Installing key to: /etc/xray/cert/cert.key -[Mon 14 Feb 2022 03:00:25 PM CST] Installing full chain to: /etc/xray/cert/fullchain.crt -``` - -(Note: This is a shell command for installing a SSL certificate using acme.sh. The command is specifying the domain, file paths for the certificate, private key, and full chain, as well as indicating that an ECC certificate should be used.) + ```shell + vpsadmin@vps-server:~$ acme.sh --installcert -d subdomain.yourdomain.com --cert-file /path/to/installation/cert.crt --key-file /path/to/installation/cert.key --fullchain-file /path/to/installation/fullchain.crt --ecc + [Mon 14 Feb 2022 03:00:25 PM CST] Installing cert to: /etc/xray/cert/cert.crt + [Mon 14 Feb 2022 03:00:25 PM CST] Installing key to: /etc/xray/cert/cert.key + [Mon 14 Feb 2022 03:00:25 PM CST] Installing full chain to: /etc/xray/cert/fullchain.crt + ``` ## 6.6 Your Progress -At this point, the two basic infrastructures required by Xray are finally in place! Xray, which has been eagerly awaited, is about to be revealed, and we are finally about to enter the most exciting chapter! +At this point, the two pieces of infrastructure required by Xray are finally in place! The long-awaited Xray is about to be unveiled. We are finally entering the most exciting chapter! > ⬛⬛⬛⬛⬛⬛⬜⬜ 75% diff --git a/docs/en/document/level-0/ch07-xray-server.md b/docs/en/document/level-0/ch07-xray-server.md index 079bdb9d..96492a07 100644 --- a/docs/en/document/level-0/ch07-xray-server.md +++ b/docs/en/document/level-0/ch07-xray-server.md @@ -1,580 +1,565 @@ -# [Chapter 7]Xray Server +# [Chapter 7] Xray Server Guide -## 7.1 Study broadly, Act decisively. +## 7.1 Extensive Preparation, Effortless Execution -During the writing of this article, the boss joked: Your tutorial has been serialized for 6 chapters and has not yet reached Xray. People who don’t know would think that you are a "hand-in-hand teaching you to build a website" tutorial. (I can't refute it.jpg!) +During the writing of this article, a pro jokingly complained to me: "Your tutorial has been running for 6 chapters and still hasn't reached Xray? People who don't know better might think this is a 'Build Your Own Website' tutorial." (I couldn't even refute that.jpg!) -In fact, this structure is my decision after much thinking. After all, only by laying a solid foundation can you quickly surpass others with half the effort. I saw many newcomers in the group who can't even use `nano` correctly, nor can they use `WinSCP`. The `config.json` edited by remote handwriting is naturally full of errors, and even error checking becomes difficult. +Actually, this structure was a decision made after much deliberation. Only by laying a solid foundation can you achieve twice the result with half the effort later on and overtake others quickly. I've seen many newcomers in groups who can't even use `nano` correctly, don't know how to use `WinSCP`, and naturally, the `config.json` they hand-edit remotely is full of errors, making debugging a struggle. ::: warning -After the preparation of the first 6 chapters, you have already climbed over several mountains with me, such as basic Linux operations, VPS remote management, web page construction, domain name management, certificate application, etc. Do you think it is actually very simple when you look back? Now that we have such solid preparations, we will have a light feeling of [smooth success] when installing and configuring Xray. +After the preparations in the first 6 chapters, we have climbed over several mountains together: Basic Linux operations, VPS remote management, website setup, domain management, certificate application, etc. Looking back, doesn't it seem quite simple? Now that we have such solid preparation, the upcoming installation and configuration of Xray will feel completely natural and effortless. ::: -The things to do next are very simple: +What needs to be done next is very simple: -1. Installation -2. Configuration (such as installing TLS certificates, `config.json`) -3. Run -4. Optimization (such as updating the kernel, enabling `bbr`, automatically redirecting `http` visits to `https`, etc.) +1. Installation +2. Configuration (e.g., installing TLS certificates, `config.json`) +3. Running +4. Optimization (e.g., updating the kernel, enabling `bbr`, auto-redirecting `http` to `https`, etc.) -## 7.2 Install Xray +## 7.2 Installing Xray -First of all, the official carrier of Xray is the binary program generated by the open source project [xray-core](https://github.com/XTLS/Xray-core) (Open sourced with License `MPL 2.0` -). If you put this binary on the server and run it, it is the server side; if you download it to the local computer and run it, it is the client side. The main difference comes from [configuration]. +First, the official carrier of Xray is the binary program generated by the [xray-core](https://github.com/XTLS/Xray-core) open-source project (based on the `MPL 2.0` open-source license). If you run this binary on a server, it is the server-side; if you download it to your local computer and run it, it is the client-side. The main difference lies in the [Configuration]. -When installing, it is very simple and direct to use the official installation script directly. It provides a variety of installation options. If you are interested, you can go to the official [installation script repository](https://github.com/XTLS/Xray-install) to see the script instructions. **This article uses the [non-root -user] installation mode**. +For installation, using the official installation script is simple and direct. It provides multiple installation options. Interested users can check the script instructions in the official [installation script repository](https://github.com/XTLS/Xray-install). **This article uses the [Non-root User] installation mode.** -When writing this article, the installation script had some minor bugs when using a non-root account, so I decided to separate these steps and explain the deletion command under Linux. +At the time of writing, the installation script has a few small bugs when using a non-root account, so I decided to separate these steps. This also serves as a good opportunity to explain the delete command in Linux. -1. Basic Linux commands for beginners: +1. Linux 101 - Basic Commands: - | Number | Command name | Command description | - | :------: | :----------: | :-----------------: | - | `cmd-14` | `rm` | delete | + | Number | Command Name | Command Description | + | :---: | :---: | :---: | + | `cmd-14` | `rm` | Delete command | -2. Download the installation script: +2. Download the installation script locally: -```shell -wget https://github.com/XTLS/Xray-install/raw/main/install-release.sh -``` + ```shell + wget [https://github.com/XTLS/Xray-install/raw/main/install-release.sh](https://github.com/XTLS/Xray-install/raw/main/install-release.sh) + ``` -3. Execute the installation command +3. Execute the installation command: -```shell -sudo bash install-release.sh -``` + ```shell + sudo bash install-release.sh + ``` -4. You can delete the script after use +4. After use, you can delete the script: -```shell -rm ~/install-release.sh -``` - -::: warning -When you use the `rm` command to delete files, the default is to delete the files in the current folder. However, **I still wrote the full path**: `~/install-release.sh`, which is a safety habit I have when using `rm`, and it is also what I want to emphasize after I divide the installation into several steps. If you have heard some jokes like "Programmers go from deleting libraries to running away", you probably know why. -::: - -5. The complete process is demonstrated as follows: - - - -## 7.3 Configure TLS certificate for Xray - -Although we have applied for TLS -certificate before, according to the official instructions of [`acme.sh`](https://github.com/acmesh-official/acme.sh/wiki/%E8%AF%B4%E6%98%8E#3-copy%E5%AE%89%E8%A3%85-%E8%AF%81%E4%B9%A6), it is not recommended to use the applied certificate directly. The correct way is to use the `--install-cert` -command to install it for the required program. Let's install the certificate for `xray-core` now. - -1. In order to avoid various potential permission problems of non-root accounts, we create a certificate folder under the vpsadmin account - -```shell -mkdir ~/xray_cert -``` - -2. Use `--install-cert` of `acme.sh` to correctly install (copy) the certificate file - -```shell -acme.sh --install-cert -d secondary domain name.your domain name.com --ecc \ ---fullchain-file ~/xray_cert/xray.crt \ ---key-file ~/xray_cert/xray.key -``` - -3. The `xray.key` file is not readable by other users by default, so it needs to be given readability - -```shell -chmod +r ~/xray_cert/xray.key -``` - -4. The process is relatively simple, so no animated picture: - - - -5. `acme.sh` will check the certificate every 60 days and automatically renew the expiring certificate. But as far as I know, it does not automatically install the new certificate to `xray-core`, so we need to add a system automatic periodic task to complete this step. - 1. Basic Linux commands for beginners: - - | Number | Command name | Command description | - | :------: | :----------: | :------------------------------------: | - | `cmd-15` | `crontab -e` | Edit the current user's scheduled task | - - 2. Create a script file (`xray-cert-renew.sh`) - - ```shell - nano ~/xray_cert/xray-cert-renew.sh - ``` - - 3. Copy the following content, remember to replace your real domain name, then save and exit - - ```bash - #!/bin/bash - - /home/vpsadmin/.acme.sh/acme.sh --install-cert -d a-name.yourdomain.com --ecc --fullchain-file /home/vpsadmin/xray_cert/xray.crt --key-file /home/vpsadmin/xray_cert/xray.key - echo "Xray Certificates Renewed" - - chmod +r /home/vpsadmin/xray_cert/xray.key - echo "Read Permission Granted for Private Key" - - sudo systemctl restart xray - echo "Xray Restarted" - ``` + ```shell + rm ~/install-release.sh + ``` ::: warning - As you have reminded, `acme.sh` has a `reloadcmd` command that can automatically execute a specific command when the certificate is updated, so you can specify to automatically install the certificate for `Xray`, but because `crontab` is a very useful and commonly used function in Linux, this article retains the `crontab` method to update the `Xray` certificate. (If you interested in `reloadcmd` can check out the [official documentation](https://github.com/acmesh-official/acme.sh) of `acme.sh`) + When using the `rm` command to delete a file, it defaults to deleting the file in the current folder. However, **I still wrote the full path**: `~/install-release.sh`. This is a safety habit of mine when using `rm`, and it is also something I wanted to emphasize by breaking the installation into steps. If you've heard jokes about "programmers deleting the database and running away," you probably understand why. + ::: - In addition, when recording animated images, the script did not include a command to restart `Xray` because `Xray` plans to support the [Certificate Hot Update] function, which means that `Xray` will automatically identify certificate updates and reload certificates without manual restart. After the function is added, I will modify `config.json` appropriately - to enable this setting and delete the restart command in the script. - ::: 4. Add [executable] permissions to this file +5. The complete process demonstration is as follows: +  + +## 7.3 Configuring TLS Certificates for Xray + +Although we have already applied for TLS certificates earlier, according to the [official documentation of `acme.sh`](https://github.com/acmesh-official/acme.sh/wiki/%E8%AF%B4%E6%98%8E#3-copy%E5%AE%89%E8%A3%85-%E8%AF%81%E4%B9%A6), it is not recommended to use the applied certificates directly. The correct method is to use the `--install-cert` command to install them for the required program. Now, let's install the certificate for `xray-core` to use. + +1. To avoid various potential permission issues with non-root accounts, we create a certificate folder under the vpsadmin account. + + ```shell + mkdir ~/xray_cert + ``` + +2. Use `acme.sh`'s `--install-cert` to correctly install (copy) the certificate files. + + ```shell + acme.sh --install-cert -d subdomain.yourdomain.com --ecc \ + --fullchain-file ~/xray_cert/xray.crt \ + --key-file ~/xray_cert/xray.key + ``` + +3. The `xray.key` file is not readable by other users by default, so we need to grant it read permissions. + + ```shell + chmod +r ~/xray_cert/xray.key + ``` + +4. The process is simple, so no GIF is provided: + +  + +5. `acme.sh` checks the certificate every 60 days and automatically renews it if it's close to expiration. However, as far as I know, it does not automatically install the new certificate to `xray-core`, so we need to add a system automatic periodic task to complete this step. + + 1. Linux 101 - Basic Commands: + + | Number | Command Name | Command Description | + | :---: | :---: | :---: | + | `cmd-15` | `crontab -e` | Edit the current user's scheduled tasks | + + 2. Create a script file (`xray-cert-renew.sh`): + + ```shell + nano ~/xray_cert/xray-cert-renew.sh ``` + + 3. Copy the content below into it, remembering to replace it with your real domain name, then save and exit. + + ```bash + #!/bin/bash + + /home/vpsadmin/.acme.sh/acme.sh --install-cert -d a-name.yourdomain.com --ecc --fullchain-file /home/vpsadmin/xray_cert/xray.crt --key-file /home/vpsadmin/xray_cert/xray.key + echo "Xray Certificates Renewed" + + chmod +r /home/vpsadmin/xray_cert/xray.key + echo "Read Permission Granted for Private Key" + + sudo systemctl restart xray + echo "Xray Restarted" + ``` + + ::: warning + As pointed out by others, `acme.sh` has a `reloadcmd` command that can automatically execute specific commands when the certificate is updated. This could be used to automatically install certificates for `Xray`. However, since `crontab` is a very useful and common function in Linux systems, this article retains the `crontab` method for updating `Xray` certificates. (Those interested in `reloadcmd` can check the [official documentation](https://github.com/acmesh-official/acme.sh) of `acme.sh`). + + Additionally, in the GIF recording, the script did not include the `Xray` restart command because `Xray` plans to support [Certificate Hot Reload], meaning `Xray` will automatically recognize certificate updates and reload them without a manual restart. Once this feature is added, I will modify `config.json` appropriately to enable this setting and remove the restart command from the script. + ::: + + 4. Add [Executable] permission to this file. + + ```shell chmod +x ~/xray_cert/xray-cert-renew.sh ``` - 5. Run `crontab -e` and add an automatic task [Automatically run `xray-cert-renew.sh` once a month] (Note that you should not add `sudo`, because we are adding an automatic task for the `vpsadmin` - account. When you run it for the first time, you will be asked to choose an editor. Of course, choose the familiar `nano`!) + 5. Run `crontab -e` to add an automatic task [Run `xray-cert-renew.sh` automatically once a month] (Note: do not add `sudo`, because we are adding the automatic task for the `vpsadmin` account. When running for the first time, it will ask you to choose an editor; choose the familiar `nano`!). - ```shell - crontab -e - ``` + ```shell + crontab -e + ``` - 6. Add the following content to the end of the file, save and exit. + 6. Add the following content to the end of the file, save, and exit. ``` # 1:00am, 1st day each month, run `xray-cert-renew.sh` 0 1 1 * * bash /home/vpsadmin/xray_cert/xray-cert-renew.sh ``` - 7. The complete process is demonstrated as follows: + 7. The complete process demonstration is as follows: -  +  -## 7.4 Configure Xray +## 7.4 Configuring Xray -First, you can refer to the [official VLESS configuration example](https://github.com/XTLS/Xray-examples) for various configurations. This article will configure a simplest method based on the official example: [Single `VLESS` protocol inbound + `80` Port fallback], which meets the maximum speed and necessary security of most scenarios. +First, various configurations can refer to the [official VLESS configuration examples](https://github.com/XTLS/Xray-examples). This article will configure a most streamlined method based on the official examples: [Single `VLESS` protocol inbound + Port `80` fallback], satisfying maximum speed and necessary security for most scenarios. -1. Generate a legal `UUID` and save it for backup (`UUID` can be simply and roughly understood as an ID that is almost never repeated like a fingerprint) +1. Generate a valid `UUID` and save it for later use (`UUID` can be simply understood as an ID, like a fingerprint, that almost never repeats). - ```shell - xray uuid - ``` + ```shell + xray uuid + ``` -2. Create log files and folders for backup - 1. Basic Linux commands for beginners: - | Number | Command name | Command description | - |:--:|:--:|:--:| - | `cmd-16` | `touch` | Create a blank file | +2. Create log files and folders for later use. + 1. Linux 101 - Basic Commands: - 2. Create a [log dedicated folder] in the `vpsadmin` folder + | Number | Command Name | Command Description | + | :---: | :---: | :---: | + | `cmd-16` | `touch` | Create a blank file | - ```shell - mkdir ~/xray_log - ``` + 2. Create a [Log Dedicated Folder] inside the `vpsadmin` folder. - 3. Generate the two required log files (access log, error log) + ```shell + mkdir ~/xray_log + ``` - ```shell - touch ~/xray_log/access.log && touch ~/xray_log/error.log - ``` + 3. Generate the two required log files (access log, error log). - ::: warning - This location is not the standard log file location of `Xray`. It is placed here to avoid permission issues that cause trouble for new users. Once you are familiar with it, it is recommended to return to the default location: `/var/log/xray/access.log` and `/var/log/xray/error.log`. - ::: 4. Because Xray is used by the nobody user by default, we need to allow other users to have "write" permissions (`*.log` means all files with the suffix `log`, and the efficiency advantage of the `CLI` interface gradually appears at this time) + ```shell + touch ~/xray_log/access.log && touch ~/xray_log/error.log + ``` - ```shell - chmod a+w ~/xray_log/*.log - ``` + ::: warning + This location is not the standard `Xray` log file location. Placing it here is to avoid permission issues causing trouble for newcomers. Once you are familiar with it, it is recommended to revert to the default location: `/var/log/xray/access.log` and `/var/log/xray/error.log`. + ::: -3. Use `nano` to create the configuration file of `Xray` + 4. Since Xray defaults to running as the `nobody` user, we need to allow other users to have "write" permissions (`*.log` means all files with the `log` suffix; the efficiency advantage of the `CLI` interface gradually appears here). -```shell -sudo nano /usr/local/etc/xray/config.json -``` + ```shell + chmod a+w ~/xray_log/*.log + ``` -4. Copy all the files below and fill in the previously generated `UUID` into the 61st line `"id": "",`. (After filling in, it will look like `"id": "uuiduuid-uuid-uuid-uuid-uuiduuiduuid"` - ) This configuration file in this article adds my various verbose comments to help you understand the function of each configuration module. +3. Use `nano` to create the `Xray` configuration file. -```json -// REFERENCE: -// https://github.com/XTLS/Xray-examples -// https://xtls.github.io/config/ -// Commonly used config files, whether server or client, have 5 parts. Plus Xiao Xiaobai's interpretation: -// ┌─ 1*log Log settings - what to write in the log and where to write (there is evidence when errors occur) -// ├─ 2_dns DNS-settings - how to check DNS (anti-DNS pollution, anti-peeping, avoid matching domestic and foreign sites to foreign servers, etc.) -// ├─ 3_routing Diversion settings - how to classify and process traffic (whether to filter ads, whether to divert traffic domestically and internationally) -// ├─ 4_inbounds Inbound settings - what traffic can flow into Xray -// └─ 5_outbounds Outbound settings - where does the traffic out of Xray go -{ - // 1\_Log settings - "log": { - "loglevel": "warning", // content from less to more: "none", "error", "warning", "info", "debug" - "access": "/home/vpsadmin/xray_log/access.log", // access record - "error": "/home/vpsadmin/xray_log/error.log" // Error log - }, - // 2_DNS settings - "dns": { - "servers": [ - "https+local://1.1.1.1/dns-query", // Prefer 1.1.1.1 DoH query, sacrificing speed but preventing ISP snooping - "localhost" - ] - }, - // 3*Diversion settings - "routing": { - "domainStrategy": "IPIfNonMatch", - "rules": [ - // 3.1 Prevent local server flow problems: such as intranet attacks or abuse, incorrect local loopbacks, etc. - { - "ip": [ - "geoip:private" // Diversion condition: In the geoip file, the rule named "private" (local) - ], - "outboundTag": "block" // Diversion strategy: Hand over to the outbound "block" for processing (black hole shielding) - }, - { - // 3.2 Prevent the server from connecting directly to China - "ip": ["geoip:cn"], - "outboundTag": "block" - }, - // 3.3 Block ads - { - "domain": [ - "geosite:category-ads-all" // Diversion conditions: In the geosite file, the rule named "category-ads-all" (various advertising domain names) - ], - "outboundTag": "block" // Diversion strategy: Hand it over to the outbound "block" for processing (black hole shielding) - } - ] - }, - // 4* Inbound settings - // 4.1 Here is only the simplest vless+xtls inbound, because this is the most powerful mode of Xray. If you need other, please add it according to the template. - "inbounds": [ + ```shell + sudo nano /usr/local/etc/xray/config.json + ``` + +4. Copy the entire file below into it, and fill in the previously generated `UUID` into line 61 `"id": "",`. (After filling it in, it looks like `"id": "uuiduuid-uuid-uuid-uuid-uuiduuiduuid"`). I have added various verbose annotations to this configuration file in this article to help you understand the function of each configuration module. + + ```json + // REFERENCE: + // [https://github.com/XTLS/Xray-examples](https://github.com/XTLS/Xray-examples) + // [https://xtls.github.io/config/](https://xtls.github.io/config/) + // Common config files, whether server or client, have 5 parts. Plus newbie interpretation: + // ┌─ 1*log Log Settings - What to write, where to write (evidence available when errors occur) + // ├─ 2_dns DNS Settings - How to query DNS (prevent DNS pollution, prevent snooping, avoid matching domestic sites to foreign servers, etc.) + // ├─ 3_routing Routing Settings - How to classify and process traffic (whether to filter ads, split domestic/international traffic) + // ├─ 4_inbounds Inbound Settings - What traffic can flow into Xray + // └─ 5_outbounds Outbound Settings - Where the traffic flowing out of Xray goes { - "port": 443, - "protocol": "vless", - "settings": { - "clients": [ + // 1_Log Settings + "log": { + "loglevel": "warning", // Content from least to most: "none", "error", "warning", "info", "debug" + "access": "/home/vpsadmin/xray_log/access.log", // Access record + "error": "/home/vpsadmin/xray_log/error.log" // Error record + }, + // 2_DNS Settings + "dns": { + "servers": [ + "https+local://1.1.1.1/dns-query", // Prefer 1.1.1.1 DoH query, sacrifices speed but prevents ISP snooping + "localhost" + ] + }, + // 3_Routing Settings + "routing": { + "domainStrategy": "IPIfNonMatch", + "rules": [ + // 3.1 Prevent local server loop issues: e.g., intranet attacks or abuse, wrong local loops, etc. { - "id": "", // Fill in your UUID - "flow": "xtls-rprx-vision", - "level": 0, - "email": "vpsadmin@yourdomain.com" - } - ], - "decryption": "none", - "fallbacks": [ + "ip": [ + "geoip:private" // Routing condition: rules named "private" in the geoip file (local) + ], + "outboundTag": "block" // Routing strategy: hand over to outbound "block" processing (blackhole blocking) + }, { - "dest": 80 // Fall back to anti-detection proxy by default + // 3.2 Prevent server from directly connecting to domestic (CN) IPs + "ip": ["geoip:cn"], + "outboundTag": "block" + }, + // 3.3 Block Ads + { + "domain": [ + "geosite:category-ads-all" // Routing condition: rules named "category-ads-all" in the geosite file (various ad domains) + ], + "outboundTag": "block" // Routing strategy: hand over to outbound "block" processing (blackhole blocking) } ] }, - "streamSettings": { - "network": "tcp", - "security": "tls", - "tlsSettings": { - "alpn": "http/1.1", - "certificates": [ - { - "certificateFile": "/home/vpsadmin/xray_cert/xray.crt", - "keyFile": "/home/vpsadmin/xray_cert/xray.key" + // 4_Inbound Settings + // 4.1 Here only one simplest vless+xtls inbound is written, because this is Xray's most powerful mode. If needed, please add others based on templates. + "inbounds": [ + { + "port": 443, + "protocol": "vless", + "settings": { + "clients": [ + { + "id": "", // Fill in your UUID + "flow": "xtls-rprx-vision", + "level": 0, + "email": "vpsadmin@yourdomain.com" + } + ], + "decryption": "none", + "fallbacks": [ + { + "dest": 80 // Default fallback to the probe-resistant proxy + } + ] + }, + "streamSettings": { + "network": "tcp", + "security": "tls", + "tlsSettings": { + "alpn": "http/1.1", + "certificates": [ + { + "certificateFile": "/home/vpsadmin/xray_cert/xray.crt", + "keyFile": "/home/vpsadmin/xray_cert/xray.key" + } + ] } - ] + } } - } + ], + // 5_Outbound Settings + "outbounds": [ + // 5.1 The first outbound is the default rule, freedom is direct connection (VPS is already on the external network, so direct connection) + { + "tag": "direct", + "protocol": "freedom" + }, + // 5.2 Blocking rule, blackhole protocol sends traffic into a black hole (blocking) + { + "tag": "block", + "protocol": "blackhole" + } + ] } - ], - // 5*Outbound settings - "outbounds": [ - // 5.1 The first outbound is the default rule, freedom is a direct connection to the outside (vps is already an external network, so it is a direct connection) - { - "tag": "direct", - "protocol": "freedom" - }, - // 5.2 Blocking rules, blackhole protocol is to import traffic into the black hole (blocking) - { - "tag": "block", - "protocol": "blackhole" - } - ] -} -``` + ``` -5. The complete process is demonstrated as follows: -  +5) The complete process demonstration is as follows: +  -## 7.5 Start Xray service! ! (and check the service status) +## 7.5 Start Xray Service!! (And check service status) -If you follow this article step by step, you have actually avoided the two most common pitfalls of **insufficient log file permissions** and **insufficient certificate file permissions**. Now running `Xray` should be very smooth. +If you have followed this article step by step, you have actually avoided the most common pitfalls of **insufficient log file permissions** and **insufficient certificate file permissions**. So now, running `Xray` should naturally be incredibly smooth. -1. Enter the following command and enjoy the historic moment of starting `Xray`! ! ! +1. Enter the command below and enjoy the historic moment of starting `Xray`!!! -```shell -sudo systemctl start xray -``` + ```shell + sudo systemctl start xray + ``` -2. Just `start` does not determine whether the Xray service has been successfully started. To determine its status, use the following command. +2. Just `start` doesn't confirm if we have successfully opened the Xray service. To determine its status, use the following command. -```shell -sudo systemctl status xray + ```shell + sudo systemctl status xray + ``` -``` + See that green, delightful `active (running)`? It says `Xray` is running correctly. -Do you see the green, pleasant `active (running)`? It means that `Xray` is running correctly +3. The complete process demonstration is as follows: -3. The complete process is demonstrated as follows: +  - +## 7.6 Reviewing `systemd` for Basic Service Management -## 7.6 Review `systemd` for basic service management +So far, we have used `systemctl` related commands like `start`, `status`, `reload`, etc. These are general commands for managing various services in the Linux system based on the `systemd` management module. Now is a good time to familiarize yourself with a few other related commands. -So far, we have used `systemctl` related commands such as `start`, `status`, `reload`, etc. These are general commands based on the `systemd` management module to manage various services in the Linux -system. Now it is a good time to get familiar with several other related commands. +1. If you need to temporarily stop the `Xray` service, use the `stop` command: -1. If you need to temporarily shut down the `Xray` service, use the `stop` command + ```shell + sudo systemctl stop xray + ``` -```shell -sudo systemctl stop xray -``` +2. If you need to restart the `Xray` service, use the `restart` command: -2. If you need to restart the `Xray` service, use the `restart` command + ```shell + sudo systemctl restart xray + ``` -```shell -sudo systemctl restart xray -``` +3. If you need to disable the `Xray` service (prevent Xray from running automatically after computer restart), use the `disable` command: -3. If you need to disable the `Xray` service (disable Xray from running automatically after the computer is restarted), use the `disable` command + ```shell + sudo systemctl disable xray + ``` -```shell -sudo systemctl disable xray -``` +4. If you need to enable the `Xray` service (ensure Xray runs automatically after computer restart), use the `enable` command: -4. If you need to enable the `Xray` service (ensure that Xray runs automatically after the computer is restarted), use the `enable` command - -```shell -sudo systemctl enable xray -``` + ```shell + sudo systemctl enable xray + ``` ## 7.7 Server Optimization 1: Enable BBR -1. The legendary `BBR` +1. The Legendary `BBR` -I believe that when you search for various scientific Internet technologies, you must have heard of the thing `bbr` more than once. With the exaggeration of various blogs, people feel that it is magical. There are also a lot of derivatives such as `bbrplus`, `bbr2`, `magic bbr`, etc. It's like a magic, which can turn a poorly routed lines become dedicated connections. + I believe that when you search for various scientific internet access technologies (censorship circumvention), you must have heard of `bbr` more than once. Under the embellishment of various blogs, it seems miraculous. There are also a bunch of derivatives like `bbrplus`, `bbr2`, `modified bbr`, etc., as if they were magic oils that can turn a cheap line into a dedicated line. -So, what is this thing? Is it useful? Which version should I use? + So, what exactly is this thing? Is it useful? And which version should be used? -2. The actual `BBR` +2. The Actual `BBR` -**BBR** = **B**ottleneck **B**andwidth and **R**ound-trip propagation time, which is a **congestion control algorithm** of TCP. A simple and rough understanding is **traffic management of data traffic** -: When the road is no longer congested, each car can naturally maintain a faster speed. + **BBR** = **B**ottleneck **B**andwidth and **R**ound-trip propagation time. It is a TCP **congestion control algorithm**. To understand it simply and crudely, it is **traffic management for data**: when the highway is not jammed, every car can naturally maintain a faster speed. -So is it useful? Generally speaking, there will be a perceptible difference between `with BBR` and `without BBR` (there will be some improvements in speed, stability, and latency), so **[It is highly recommended to turn on `BBR`]**. + So is it useful? Generally speaking, there is a perceptible difference between `With BBR` and `Without BBR` (improvements in speed, stability, and latency), so **[It is highly recommended to enable `BBR`]**. -But after it is enabled, the difference between `BBR` in `4.x` and `5.x` is often subtle and subjective, and the decisive factor that causes the difference in experience is still the line quality. So **[Don't worry about the version, don't blindly chase the new, just follow your distribution to update the kernel]** + However, after enabling it, the difference between `BBR` in `4.x` and `5.x` is often subtle and subjective. The decisive factor causing the experience difference is still the line quality. So **[Do not obsess over versions, do not blindly chase the new, just follow your distribution's kernel updates]**. -3. Are `bbrplus`, `bbr2`, `magic bbr` and other versions that sound cool better? +3. Are `bbrplus`, `bbr2`, `modified bbr` and other versions with cool-sounding names better? -In a word: **No! Don't use these! These names are just to attract attention! ** + In one word: **No! Don't use these! These are names made up just to attract attention!** -The update and release of `BBR` are all carried out in accordance with the Linux kernel (`Kernel`). In other words, as long as you use a relatively new kernel, you will naturally use the new version of `BBR`. + The update and release of `BBR` follow the Linux kernel (`Kernel`). In other words, as long as you use a relatively new kernel, you will naturally use the new version of `BBR`. -And these things with cool names are, to put it bluntly, kernels that have not yet been officially released and are still in the testing stage and their corresponding `BBR` versions. These scripts are just the first to enable by downloading the preview version of the kernel (even a third-party magic kernel). + And those things with cool names are essentially unreleased kernels still in the testing phase and their corresponding `BBR` versions. These scripts merely enable them by downloading preview kernels (or even third-party modified kernels). -The stability of the kernel is the cornerstone of the stable operation of a server. **The slight performance difference brought by the BBR beta is definitely not worth changing to an unstable Kernel. 】** Please choose the latest kernel supported by your Linux distribution, so as to maximize the long-term stability and compatibility of the server. + Kernel stability is the cornerstone of a stable server operation. **[The subtle performance difference brought by the BBR beta version is absolutely not worth swapping for an unstable kernel.]** Please choose the latest kernel supported by your Linux distribution, which maximizes the long-term stability and compatibility of the server. -::: warning -The so-called "leading" of the magic modification `bbr` is very time-sensitive. For example, many `bbrplus` scripts, because they have not been updated for several years, will still change your kernel to `4.19`. You should know that Debian is now stable and it is already the era of `5.9`. Then this script may be a little ahead in January 2018, but it has lost its meaning when 4.19 is released in October 2018. It can even be said to be completely [downgraded] and [degraded] now. -::: + ::: warning + The so-called "lead" of modified `bbr` has a very strong timeliness. For example, many `bbrplus` scripts have not been updated for several years, and even now they will replace your kernel with `4.19`. You should know that stable distributions like Debian are already in the `5.9` era. So maybe this script was a little ahead in January 2018, but by October 2018 when 4.19 was officially released, it had lost its meaning. Putting it in use now can even be considered a complete [Downgrade] and [Degradation]. + ::: -4. Which of `fq`, `fq_codel`, `fq_pie`, `cake` and other algorithms is better? +4. Which algorithm is better: `fq`, `fq_codel`, `fq_pie`, `cake` or others? -In one sentence: **If you don't understand, please keep `fq`, which is enough and will not degrade your line** + In one word: **If you don't understand, please keep `fq`. It is sufficient and will not degrade your line.** -5. Ruisu, Finalspeed, LotServer and other "acceleration tools" +5. RuiSu (ServerSpeeder), Finalspeed, LotServer, and other "Acceleration Tools" -In one sentence: **Don't use these! Throw them into the trash can of history! ** + In one word: **Do not use these! Throw them into the trash bin of history!** -It can only solve the problem of packet loss rate. A not very accurate analogy is that you originally used a car to deliver your goods, and sometimes the car broke down halfway (packet loss). After using these, you directly sent out 3 copies of the same goods and let three cars deliver them at the same time. As long as one of them is not broken, it can be delivered. The road is full of your cars, so you can naturally squeeze others out. But it is conceivable that when you squeeze others, others will also squeeze you, and the exit road of the entire computer room is so wide, and it is bound to become a collective traffic jam in the end. + The only problem they can solve is the packet loss rate. To use an imprecise analogy: originally you used one car to deliver your goods, sometimes the car broke down halfway (packet loss). After using these, you directly send out 3 identical copies of the goods, letting three cars deliver at the same time. As long as one doesn't break down, it gets delivered. The road is full of your cars, so naturally, you squeeze others out. But predictably, when you squeeze others, others will also squeeze you. The exit road of the entire computer room is only so wide, and eventually, it is bound to turn into a massive collective traffic jam. -::: warning Description -Their principle is not algorithm optimization, not speed-up, most of them are simple and crude **multiple packet delivery**. It may be useful for bad lines with very high packet loss rates, but it has no optimization effect on good lines with low packet loss rates. Instead, it will consume your traffic exponentially, causing unnecessary pressure on the server and your neighbors. + ::: warning Note + Their principle is not algorithm optimization or speed boosting; most are simple and crude **multi-packet sending**. For poor lines with [very high packet loss rates], they might have some effect, but for good lines with low packet loss rates, [they have no optimization effect, and instead will multiply your traffic consumption], thereby causing unnecessary pressure on the server and your neighbors. -If your line really has a very high packet loss rate, the only reliable solution is to **change the line**. -::: + If your line really has a ridiculously high packet loss rate, the truly reliable solution is to [Change the Line]. + ::: -6. I have said so much because there are too many misconceptions and scam scripts around `BBR` to fool novices. I hope you now have a relatively clear understanding of `BBR`. Next, let's install the latest Debian kernel and enable `BBR`! (It's really simple) +6. I've been rambling so much because there are too many misconceptions and pitfall scripts fooling newbies surrounding `BBR`. I hope you now have a relatively clear understanding of `BBR`. Next, let's install the latest Debian kernel and enable `BBR`! (It's really simple) -7. Add the official `backports` source to Debian 10 to get the updated software library +7. Add the official `backports` source to Debian 10 to get updated software libraries. -```shell -sudo nano /etc/apt/sources.list -``` + ```shell + sudo nano /etc/apt/sources.list + ``` -::: warning Description -This article takes Debian 10 as an example, so there is still no problem using `/etc/apt/sources.list`, but if you are not starting from scratch according to this article, or using other Linux -distributions, it is recommended that you create a `/etc/apt/sources.list.d/` folder and create your own configuration file in this folder, such as `/etc/apt/sources.list.d/vpsadmin.list` -, to ensure compatibility and avoid the default file being overwritten in unforeseen circumstances and causing configuration loss. -::: + ::: warning Note + This article takes Debian 10 as an example, so using `/etc/apt/sources.list` is fine. However, if you are not starting from scratch following this article, or are using another Linux distribution, I suggest you create a `/etc/apt/sources.list.d/` folder and create your own configuration file inside this folder, like `/etc/apt/sources.list.d/vpsadmin.list`. This ensures compatibility and avoids configuration loss caused by default files being overwritten in unforeseen circumstances. + ::: -8. Then add the following item at the end, save and exit. +8. Then add the following line at the end, save, and exit. -``` -deb http://deb.debian.org/debian buster-backports main -``` + ``` + deb [http://archive.debian.org/debian](http://archive.debian.org/debian) buster-backports main + ``` -9. Refresh the software library and query the latest version of the official Debian kernel and install it. Please be sure to install the version corresponding to your VPS (this article takes the more common [amd64] as an example). +9. Refresh the software library, query the latest official Debian kernel, and install it. Please be sure to install the version corresponding to your VPS (this article uses the common [amd64] as an example). -```shell -sudo apt update && sudo apt -t buster-backports install linux-image-amd64 -``` + ```shell + sudo apt update && sudo apt -t buster-backports install linux-image-amd64 + ``` -::: warning Note + ::: warning Attention + If your VPS supports it, you can try the [Cloud Server Dedicated Kernel] `linux-image-cloud-amd64`. The advantage is that it is streamlined and uses fewer resources. The downside is that some students reported that forcing installation on unsupported systems leads to boot failure (Kernel cannot be recognized). -If your VPS supports it, you can try the [cloud server dedicated kernel] `linux-image-cloud-amd64`. The advantages are simplicity and low resource usage. The disadvantage is that some students have reported that forced installation on an unsupported system will cause the system to fail to boot (the kernel cannot be recognized). + To avoid the tragedy of being unable to recognize the kernel, please ensure: + - Take a system snapshot before trying, or + - You have `vnc` to save the situation (and you know how to use it) + ::: -To avoid the tragedy of being unable to identify, please make sure: +10. Modify the `kernel` parameter configuration file `sysctl.conf` and specify enabling `BBR`. -- Take a system snapshot before trying, or -- You have `vnc` to save the day (and you know how to use it) + ```shell + sudo nano /etc/sysctl.conf + ``` -::: + ::: warning Note + This article takes Debian 10 as an example, so using `/etc/sysctl.conf` is fine. However, if you are not starting from scratch following this article, or are using another Linux distribution, I suggest you create a `/etc/sysctl.d/` folder and create your own configuration file inside this folder, like `/etc/sysctl.d/vpsadmin.conf`. This ensures compatibility because some distributions no longer read parameters from `/etc/sysctl.conf` after `systemd` version 207. Using a custom configuration file also avoids configuration loss caused by default files being overwritten in unforeseen circumstances. + ::: -10. Modify the `kernel` parameter configuration file `sysctl.conf` and specify to enable `BBR` +11. Add the following content into it: -```shell -sudo nano /etc/sysctl.conf -``` + ``` + net.core.default_qdisc=fq + net.ipv4.tcp_congestion_control=bbr + ``` -::: warning Description -This article takes Debian 10 as an example, so it is still no problem to use `/etc/sysctl.conf`, but if you are not following this article from scratch, or use other Linux distributions, it is recommended that you create a `/etc/sysctl.d/` -folder and create your own configuration file in this folder, such as `/etc/sysctl.d/vpsadmin.conf`, to ensure compatibility, because some distributions no longer read parameters from `/etc/sysctl.conf` after `systemd` -207 version. Using a custom configuration file can also prevent the default file from being overwritten in unexpected circumstances, resulting in configuration loss. -::: +12. Reboot the VPS to make the kernel update and `BBR` settings take effect. -11. Add the following content + ```shell + sudo reboot + ``` -``` -net.core.default_qdisc=fq -net.ipv4.tcp_congestion_control=bbr -``` +13. The complete process demonstration is as follows: -12. Restart the VPS to make the kernel update and `BBR` settings take effect + ::: tip Mr. Verbose + Because the VPS I used for the demonstration supports the cloud server dedicated kernel, I used `linux-image-cloud-amd64` in the GIF. If you are not sure if your VPS supports it, please be sure to follow the command in step 3 and use the regular kernel `linux-image-amd64`. + ::: -```shell -sudo reboot -``` +  -13. The complete process is demonstrated as follows: +14. Confirm `BBR` is enabled -::: tip -Because the VPS I am demonstrating supports the cloud server-specific kernel, I used `linux-image-cloud-amd64` in the animation. + If you want to confirm if `BBR` is enabled correctly, you can use the following command: -If you are not sure whether your VPS supports it, please follow the command in step 3 and use the regular kernel `linux-image-amd64`. -::: + ```shell + lsmod | grep bbr + ``` - + It should return a result like this: -14. Confirm that `BBR` is enabled + ``` + tcp_bbr + ``` -If you want to confirm whether `BBR` is enabled correctly, you can use the following command: + If you want to confirm if the `fq` algorithm is enabled correctly, you can use the following command: -```shell -lsmod | grep bbr -``` + ```shell + lsmod | grep fq + ``` -This should return the following result: + It should return a result like this: -``` -tcp_bbr -``` + ``` + sch_fq + ``` -If you want to confirm whether the `fq` algorithm is enabled correctly, you can use the following command: +## 7.8 Server Optimization 2: Enable Auto-Redirect from HTTP to HTTPS -```shell -lsmod | grep fq -``` +1. We previously set up an `http` webpage on port `80` and used it to apply for a TLS certificate. -This should return the following result: + But if you tried to access our interface using a browser, you would find that `http` access does not automatically upgrade to `https` access like most websites. In other words, under our current settings, `http(80)` and `https(443)` are completely independent. To solve this problem, some modifications are needed. -``` -sch_fq -``` +2. Edit the Nginx configuration file. -## 7.8 Server Optimization 2: Enable HTTP to automatically redirect to HTTPS + ```shell + sudo nano /etc/nginx/nginx.conf + ``` -1. We have previously built an `http` webpage on port `80` and applied for a TLS certificate. +3. Add the following statement to the Server block listening on port 80 that we set up, then save and exit (you can also delete the `root` and `index` lines): -But if you try to access our interface with a browser, you will find that `http` access will not automatically upgrade to `https` access like most websites. In other words, under our current settings, `http(80)` and `https(443)` are completely independent. If you want to solve this problem, you need to make some changes. + ``` + return 301 https://$http_host$request_uri; + ``` -2. Edit the Nginx configuration file +4. Add a local port listener at the same level as port `80` to provide webpage display. This article uses port `8080` for demonstration. (It can be any port). -```shell -sudo nano /etc/nginx/nginx.conf -``` + ``` + server { + listen 127.0.0.1:8080; + root /home/vpsadmin/www/webpage; + index index.html; + add_header Strict-Transport-Security "max-age=63072000" always; + } + ``` -3. Add the following statement to the 80 port server we set, save and exit (you can delete the `root` and `index` lines at the same time) +5. Restart the Nginx service. -``` -return 301 https://$http_host$request_uri; -``` + ```shell + sudo systemctl restart nginx + ``` -4. Add a local port listener at the same level as the `80` port to provide web page display. This article uses the `8080` port for demonstration. (Can be any port) +6. Modify the Xray fallback setting, changing the fallback from port `80` to port `8080`. (Find `"dest": 80` and change it to `"dest": 8080`). -``` -server { -listen 127.0.0.1:8080; -root /home/vpsadmin/www/webpage; -index index.html; -add_header Strict-Transport-Security "max-age=63072000" always; -} -``` + ```shell + sudo nano /usr/local/etc/xray/config.json + ``` -5. Restart Nginx service +7. Restart the `Xray` service to complete the setup. -```shell -sudo systemctl restart nginx -``` + ```shell + sudo systemctl restart xray + ``` -6. Modify the fallback settings of Xray, changing the fallback from `80` port to `8080` port. (Find `"dest": 80`, and change it to `"dest": 8080`) +8. The complete process demonstration is as follows: -```shell -sudo nano /usr/local/etc/xray/config.json -``` +  -7. Restart the `Xray` service to complete the configuration +9. When you enter `http://a-name.yourdomain.com`, it should now automatically redirect to https. -```shell -sudo systemctl restart xray -``` +  -8. The complete process is demonstrated as follows: +## 7.9 Server Optimization 3: Richer Fallbacks - +If you need richer fallback functionality, you can refer to [《Fallbacks (fallbacks) Feature Analysis》](../level-1/fallbacks-lv1.md) -9. When you enter `http://a-name.yourdomain.com`, it should automatically jump to https +## 7.10 Your Progress - - -## 7.9 Server Optimization 3: More Fallbacks - -If you need more fallback functions, please refer to [《Fallbacks (fallbacks) Functional Analysis》](../level-1/fallbacks-lv1.md) - -## 7.10 Your progress - -Congratulations!! At this point, you already have a server that can access the Internet normally and scientifically, and also have a disguised website that can prevent active detection attacks. Next, just install the appropriate software on your client and you can enjoy a smooth network! +Congratulations!! At this step, you already possess a server capable of proper scientific internet access (censorship circumvention), and also a camouflage website that prevents active probing attacks. Next, just install the appropriate software on your client, and you can enjoy a smooth network! > ⬛⬛⬛⬛⬛⬛⬛⬜ 87.5% -## 7.11 Important errata +## 7.11 Important Errata -1. The folder location of the `Xray` configuration file `config.json` in the first version is wrong. If you have already operated according to the previous location, `Xray` will not start correctly. Therefore, the errata is explained here, please check it yourself, and I am very sorry for the inconvenience! +1. In the first edition, the `Xray` configuration file `config.json` folder location was incorrect. If you operated according to the previous location, `Xray` would not start correctly. Therefore, the correction is explained here. Please check yourself. Sorry for the inconvenience! -- Correct location: `/usr/local/etc/xray/config.json` -- Wrong location: `/usr/local/etc/config.json` + - Correct location: `/usr/local/etc/xray/config.json` + - Incorrect location: `/usr/local/etc/config.json` -Affected sections: + Affected sections: + - 7.4 Configuring `Xray` - 3. Use `nano` to create the `Xray` configuration file + - 7.8 Server Optimization 2 - 6. Modify `Xray`'s fallback settings -- 7.4 Configure `Xray` - 3. Use `nano` to create `Xray` configuration file -- 7.8 Server Optimization 2 - 6. Modify `Xray` fallback settings +2. In the first edition, when modifying the `Nginx` configuration file `nginx.conf`, the content was incorrect (webpage folder location error). If you operated according to the previous location, `Nginx` would not find the correct website. Please check yourself. Sorry for the inconvenience! -2. In the first version, the content of the `Nginx` configuration file `nginx.conf` was modified incorrectly (the webpage folder location was incorrect). If you have already performed the operation according to the previous location, `Nginx` will not be able to find the correct website. Please check it yourself. Sorry for the inconvenience! + - Correct folder location: `root /home/vpsadmin/www/webpage;` + - Incorrect folder location: `root /var/www/website/html` -- Correct folder location: `root /home/vpsadmin/www/webpage;` -- Wrong folder location: `root /var/www/website/html` - -Affected sections: - -- 7.8 Server Optimization 2 - 4. Add a local port listener at the same level as the `80` port to provide web page display + Affected sections: + - 7.8 Server Optimization 2 - 4. Add a local port listener at the same level as port `80` to provide webpage display diff --git a/docs/en/document/level-0/ch08-xray-clients.md b/docs/en/document/level-0/ch08-xray-clients.md index 01372c18..a328f3f0 100644 --- a/docs/en/document/level-0/ch08-xray-clients.md +++ b/docs/en/document/level-0/ch08-xray-clients.md @@ -1,220 +1,218 @@ -# 【第 8 章】Xray 客户端篇 +# 【Chapter 8】 Xray Clients -## 8.1 Xray 的工作原理简述 +## 8.1 Brief Description of Xray's Working Principles -要正确的配置和使用`Xray`，就需要正确的理解其工作原理，对于新人，可以先看看下面简化的示意图（省略了许多复杂的设置）： +To configure and use `Xray` correctly, you need to properly understand how it works. For newcomers, you can first take a look at the simplified diagram below (many complex settings have been omitted): - + -这其中的关键点是： +The key points are: -1. APP 要主动或借助转发工具，将数据【流入(`inbounds`)】`Xray` 客户端 +1. Apps must, either actively or via a forwarding tool, send data so it **[flows in (`inbounds`)]** to the `Xray` client. -2. 流量进入客户端后，会被【客户端路由(`routing`)】按规则处理后，向不同方向【流出`(outbounds)`】`Xray` 客户端。比如： - 1. 国内流量直连（`direct`） - 2. 国外流量转发 VPS（`proxy`） - 3. 广告流量屏蔽（`block`） +2. After traffic enters the client, it is processed by the **[Client Routing (`routing`)]** according to rules, and then sent to **[flow out (`outbounds`)]** of the `Xray` client in different directions. For example: + 1. Domestic traffic connects directly (`direct`). + 2. Foreign traffic is forwarded to the VPS (`proxy`). + 3. Ad traffic is blocked (`block`). -3. 向 VPS 转发的国外流量，会跨过防火墙，【流入(`inbounds`)】 `Xray` 服务器端 +3. Foreign traffic forwarded to the VPS will cross the firewall and **[flow in (`inbounds`)]** to the `Xray` server-side. -4. 流量进入服务器端后，与客户端一样，会被【服务器端路由(`routing`)】按规则处理后，向不同方向【流出`(outbounds)`】： - 1. 因为已经在防火墙之外，所以流量默认直连，你就可以访问到不存在网站们了（`direct`） - 2. 如果需要在不同的 VPS 之间做链式转发，就可以继续配置转发规则（`proxy`） - 3. 你可以在服务器端继续禁用各种你想禁用的流量，如广告、BT 下载等（`block`） +4. After traffic enters the server-side, just like on the client, it is processed by the **[Server Routing (`routing`)]** according to rules, and then sent to **[flow out (`outbounds`)]** in different directions: + 1. Since it is already outside the firewall, traffic connects directly by default, allowing you to access those "non-existent" websites (`direct`). + 2. If you need to perform chained forwarding between different VPSs, you can continue to configure forwarding rules (`proxy`). + 3. You can continue to disable various traffic you want to ban on the server side, such as ads, BitTorrent downloads, etc. (`block`). -:::warning 注意 +:::warning Note -请务必记得，`Xray` 的路由配置非常灵活，上面的说明只是无限可能性中的一种。 +Please remember that `Xray`'s routing configuration is extremely flexible. The explanation above is just one of infinite possibilities. -借助 `geosite.dat` 和 `geoip.dat` 这两个文件，可以很灵活的从【域名】和【IP】这两个角度、不留死角的控制流量流出的方向。这比曾经单一笼统的 `GFWList` 强大很多很多，可以做到非常细致的微调：比如可以指定 Apple 域名直连或转发、指定亚马逊域名代理或转发，百度的域名屏蔽等等。。。） +With the help of the `geosite.dat` and `geoip.dat` files, you can flexibly control the direction of traffic outflow from the perspectives of [Domain Name] and [IP], leaving no blind spots. This is much, much more powerful than the old, singular, and generalized `GFWList`, allowing for very fine-grained tuning: for example, you can specify Apple domains to connect directly or be forwarded, Amazon domains to be proxied or forwarded, Baidu domains to be blocked, etc... -现在，[《路由 (routing) 功能简析》](../level-1/routing-lv1-part1.md) 已经上线，我建议对路由功能有兴趣的同学，先继续跟着本文完成客户端的基础配置，之后再去这里详细学习。 +Now, [《Analysis of the Routing Feature》](../level-1/routing-lv1-part1.md) is online. I suggest that students interested in routing functions continue to follow this article to complete the basic client configuration first, and then go there for detailed learning. ::: -## 8.2 客户端与服务器端正确连接 +## 8.2 Connecting Client and Server Correctly -现在你已经理解了 `Xray` 的工作原理，那么接下来的配置，其实就是【告诉你的客户端如何连接 VPS 服务器】。这和你已经很熟悉的、告诉`PuTTY`如何远程连接服务器是一样的。只不过 Xray 连接时的要素不止是【IP 地址】+【端口】+【用户名】+【密码】这四要素了。 +Now that you understand how `Xray` works, the next configuration step is simply **[telling your client how to connect to the VPS server]**. This is exactly the same as what you are already familiar with: telling `PuTTY` how to remotely connect to a server. The only difference is that the connection elements for Xray are more than just the four elements of [IP Address] + [Port] + [Username] + [Password]. -实际上，`Xray`的连接要素是由不同的[协议](../../config/inbounds/)决定的。本文在第 7 章的配置文件 `config.json` 里，我们使用 `Xray` 下独特而强大的 `VLESS` 协议 + `XTLS` 流控。所以看看那个配置文件的内容就能知道，这个协议组合的连接要素有： +In fact, `Xray`'s connection elements are determined by different [protocols](../../config/inbounds/). In the `config.json` configuration file in Chapter 7, we used the unique and powerful `VLESS` protocol + `XTLS` flow control found in `Xray`. So, looking at the content of that configuration file, we know the connection elements for this protocol combination are: -- 服务器【地址】: `a-name.yourdomain.com` -- 服务器【端口】: `443` -- 连接的【协议】: `vless` -- 连接的【流控】: `xtls-rprx-vision` (vision 模式适合全平台) -- 连接的【验证】: `uuiduuid-uuid-uuid-uuiduuiduuid` -- 连接的【安全】: `"allowInsecure": false` +- Server [Address]: `a-name.yourdomain.com` +- Server [Port]: `443` +- Connection [Protocol]: `vless` +- Connection [Flow]: `xtls-rprx-vision` (vision mode is suitable for all platforms) +- Connection [Authentication]: `uuiduuid-uuid-uuid-uuiduuiduuid` +- Connection [Security]: `"allowInsecure": false` -鉴于新人一般都会使用手机 APP 或者电脑的 GUI 客户端，我就把常用的客户端罗列在下面。每个客户端都有自己独特的配置界面，逐一截图展示并不现实，所以请你务必仔细阅读这些客户端的说明、然后把上述要素填入合适的地方即可。 +Given that newcomers generally use mobile apps or GUI clients on computers, I have listed common clients below. Each client has its own unique configuration interface, and it is not realistic to take screenshots of each one. Therefore, please be sure to read the instructions for these clients carefully, and then fill in the above elements in the appropriate places. -:::warning 注意 -许多工具其实是同时支持 `xray-core` 和 `v2fly-core` 的，但默认内置的不一定是哪个，所以别忘记检查一下是否是你想要的那个在工作哦！ +:::warning Note +Many tools actually support both `xray-core` and `v2fly-core` simultaneously, but the default built-in core may vary. Don't forget to check if the one you want is the one working! ::: -- **v2rayN - 适用于 Windows 平台** - - 请从它的[GitHub 仓库 Release 页面](https://github.com/2dust/v2rayN/releases)获取最新版 - - 请根据该客户端的说明进行设置 +- **v2rayN - Suitable for Windows Platform** + - Please get the latest version from its [GitHub Repository Release Page](https://github.com/2dust/v2rayN/releases) + - Please configure according to the client's instructions -- **v2rayNG - 适用于 Android 平台** - - 请从它的[GitHub 仓库 Release 页面](https://github.com/2dust/v2rayNG/releases)获取最新版 - - 请根据该客户端的说明进行设置 +- **v2rayNG - Suitable for Android Platform** + - Please get the latest version from its [GitHub Repository Release Page](https://github.com/2dust/v2rayNG/releases) + - Please configure according to the client's instructions -- **Shadowrocket - 适用于 iOS, 基于苹果 M 芯片的 macOS** - - 你需要注册一个【非中国区】的 iCloud 账户 - - 你需要通过 App Store 搜索并购买 - - 请根据该客户端的说明进行设置 +- **Shadowrocket - Suitable for iOS, and macOS with Apple M chips** + - You need to register a [Non-Mainland China] iCloud account + - You need to search for and purchase it in the App Store + - Please configure according to the client's instructions -- **Qv2ray - 跨平台图形界面，适用于 Linux, Windows, macOS** - - 请从它的[GitHub 仓库 Release 页面](https://github.com/Qv2ray/Qv2ray/releases)获取最新版（还可以从它的[GitHub 自动构建仓库](https://github.com/Qv2ray/Qv2ray/actions)寻找更新的版本） - - 请从它的[项目主页](https://qv2ray.net/)学习文档 - - 请根据该客户端的说明进行设置 +- **Qv2ray - Cross-platform GUI, suitable for Linux, Windows, macOS** + - Please get the latest version from its [GitHub Repository Release Page](https://github.com/Qv2ray/Qv2ray/releases) (You can also find newer versions from its [GitHub Actions builds](https://github.com/Qv2ray/Qv2ray/actions)) + - Please study the documentation from its [Project Homepage](https://qv2ray.net/) + - Please configure according to the client's instructions -- **V2RayXS - 基于 V2RayX 开发的一款使用 xray-core 的 macOS 客户端** - - 请从它的 [GitHub 仓库 Release 页面](https://github.com/tzmax/v2rayXS/releases) 获取最新版 - - 支持一键导入 [VMessAEAD / VLESS 分享链接标准提案](https://github.com/XTLS/Xray-core/issues/91) 为标准的分享链接 - - 请根据该客户端的说明进行设置 +- **V2RayXS - A macOS client using xray-core, based on V2RayX** + - Please get the latest version from its [GitHub Repository Release Page](https://github.com/tzmax/v2rayXS/releases) + - Supports one-click import of [VMessAEAD / VLESS Share Link Standard Proposal](https://github.com/XTLS/Xray-core/issues/91) as standard share links + - Please configure according to the client's instructions -到这一步，你的全套配置就已经可以正常使用啦！ +At this step, your full set of configurations is ready for normal use! -## 8.3 附加题 1：在 PC 端手工配置 `xray-core` +## 8.3 Bonus Task 1: Manually Configuring `xray-core` on PC -虽然到上面一步已经可以结束了，但是如果你是个好奇心强、记忆力好的的同学，一定会想起来我在上一章说过，你把`xray-core` 的二进制文件“放在服务器运行，它就是服务器端；你把它下载到本地电脑运行，它就是客户端。” 那究竟要怎样直接使用 `xray-core` 做客户端呢？ +Although you could stop at the previous step, if you are a student with strong curiosity and a good memory, you will definitely recall that I said in the previous chapter: "Put the `xray-core` binary on the server and run it, and it is the server-side; download it to your local computer and run it, and it is the client." So, how exactly do you use `xray-core` directly as a client? -为了回答这个问题，我加入了附加题章节，有一点点超纲，有一点点麻烦，但费这个笔墨是因为这个方式有它的优势： +To answer this question, I added this bonus chapter. It's a bit beyond the syllabus and a bit troublesome, but I spent the ink on this because this method has its advantages: -- 第一时间获得最新版而无需等待 APP 升级适配 +- Get the latest version immediately without waiting for APP updates and adaptations. +- Flexible and free routing configuration capabilities (Of course, the advanced routing editor in the GUI client Qv2ray is also very powerful and can fully implement xray-core's routing configuration functions). +- Save system resources (GUI interfaces will inevitably consume resources; the amount depends on the client's implementation). -- 灵活自由的路由配置能力（当然 GUI 客户端中 Qv2ray 的高级路由编辑器非常强大，也可以完整实现 xray-core 的路由配置功能） +Its disadvantage is probably that [hand-writing configuration files] is a bit troublesome. But actually, think about it, you have already successfully written it once on the server, so what is the difference now? Next, as usual, let's break down the steps: -- 节约系统资源 （GUI 界面一定会有资源消耗，消耗的多少则取决于客户端的实现） - -它的劣势应该就是【需要手写配置文件】有点麻烦了。但其实，你想想，服务器上你已经成功的写过一次了，现在又有什么区别呢？接下来，还是老样子，我们分解一下步骤： - -1. 首先请从 Xray 官方的 [GitHub 仓库 Release 页面](https://github.com/XTLS/Xray-core/releases) 获取对应平台的版本，并解压缩到合适的文件夹 -2. 在合适的文件夹建立空白配置文件：`config.json` （自己常用平台下新建文件大家肯定都会，这就真不用啰嗦了） -3. 至于什么是“合适的文件夹”？这就取决于具体的平台了~ -4. 填写客户端配置 - - 我就以 `8.1` 原理说明里展示的基本三类分流（国内流量直连、国际流量转发 VPS、广告流量屏蔽），结合 `8.2` 的连接要素，写成一个配置文件 - - 请将 `uuid` 替换成与你服务器一致的 `uuid` - - 请将 `address` 替换成你的真实域名 - - 请将 `serverName` 替换成你的真实域名 - - 各个配置模块的说明我都已经（很啰嗦的）放在对应的配置点上了 +1. First, please get the version for your platform from the official Xray [GitHub Repository Release Page](https://github.com/XTLS/Xray-core/releases) and unzip it to a suitable folder. +2. Create a blank configuration file in that folder: `config.json`. (I surely don't need to nag about how to create a new file on your OS). +3. As for what constitutes a "suitable folder"? That depends on the specific platform~ +4. Fill in the client configuration. + - I will use the three basic categories of traffic splitting demonstrated in the `8.1` principle explanation (Domestic traffic direct, International traffic forwarded to VPS, Ad traffic blocked), combined with the connection elements from `8.2`, to write a configuration file. + - Please replace `uuid` with the `uuid` consistent with your server. + - Please replace `address` with your real domain name. + - Please replace `serverName` with your real domain name. + - Explanations for each configuration module have been (very verbosely) placed on the corresponding configuration points. ```json // REFERENCE: // https://github.com/XTLS/Xray-examples // https://xtls.github.io/config/ - // 常用的config文件，不论服务器端还是客户端，都有5个部分。外加小小白解读： - // ┌─ 1_log 日志设置 - 日志写什么，写哪里（出错时有据可查） - // ├─ 2_dns DNS-设置 - DNS怎么查（防DNS污染、防偷窥、避免国内外站匹配到国外服务器等） - // ├─ 3_routing 分流设置 - 流量怎么分类处理（是否过滤广告、是否国内外分流） - // ├─ 4_inbounds 入站设置 - 什么流量可以流入Xray - // └─ 5_outbounds 出站设置 - 流出Xray的流量往哪里去 + // A common config file, whether for server or client, has 5 parts. plus Newbie interpretation: + // ┌─ 1_log Log Settings - What to write, where to write (evidence for troubleshooting) + // ├─ 2_dns DNS Settings - How to query DNS (prevent DNS pollution, prevent snooping, avoid matching domestic/foreign sites to foreign servers, etc.) + // ├─ 3_routing Routing Settings - How to classify and process traffic (filter ads? split domestic/foreign traffic?) + // ├─ 4_inbounds Inbound Settings - What traffic can flow into Xray + // └─ 5_outbounds Outbound Settings - Where the traffic flowing out of Xray goes { - // 1_日志设置 - // 注意，本例中我默认注释掉了日志文件，因为windows, macOS, Linux 需要写不同的路径，请自行配置 + // 1_Log Settings + // Note: In this example, I commented out the log file by default because windows, macOS, and Linux require different paths. Please configure it yourself. "log": { - // "access": "/home/local/xray_log/access.log", // 访问记录 - // "error": "/home/local/xray_log/error.log", // 错误记录 - "loglevel": "warning" // 内容从少到多: "none", "error", "warning", "info", "debug" + // "access": "/home/local/xray_log/access.log", // Access record + // "error": "/home/local/xray_log/error.log", // Error record + "loglevel": "warning" // Content from least to most: "none", "error", "warning", "info", "debug" }, - // 2_DNS设置 + // 2_DNS Settings "dns": { "servers": [ - // 2.1 国外域名使用国外DNS查询 + // 2.1 Foreign domains use foreign DNS queries { "address": "1.1.1.1", "domains": ["geosite:geolocation-!cn"] }, - // 2.2 国内域名使用国内DNS查询，并期待返回国内的IP，若不是国内IP则舍弃，用下一个查询 + // 2.2 Domestic domains use domestic DNS queries, expecting a domestic IP return. If not a domestic IP, discard and use the next query. { "address": "223.5.5.5", "domains": ["geosite:cn"], "expectIPs": ["geoip:cn"] }, - // 2.3 作为2.2的备份，对国内网站进行二次查询 + // 2.3 As a backup for 2.2, perform a secondary query for domestic websites { "address": "114.114.114.114", "domains": ["geosite:cn"] }, - // 2.4 最后的备份，上面全部失败时，用本机DNS查询 + // 2.4 Final backup: if all above fail, use local machine DNS "localhost" ] }, - // 3_分流设置 - // 所谓分流，就是将符合否个条件的流量，用指定`tag`的出站协议去处理（对应配置的5.x内容） + // 3_Routing Settings + // Traffic splitting means traffic meeting certain conditions is processed by the outbound protocol with a specific `tag` (corresponding to content in 5.x) "routing": { "domainStrategy": "IPIfNonMatch", "rules": [ - // 3.1 广告域名屏蔽 + // 3.1 Ad domain blocking { "domain": ["geosite:category-ads-all"], "outboundTag": "block" }, - // 3.2 国内域名直连 + // 3.2 Domestic domains direct connection { "domain": ["geosite:cn"], "outboundTag": "direct" }, - // 3.3 国外域名代理 + // 3.3 Foreign domains proxy { "domain": ["geosite:geolocation-!cn"], "outboundTag": "proxy" }, - // 3.4 走国内"223.5.5.5"的DNS查询流量分流走direct出站 + // 3.4 Traffic for domestic DNS query "223.5.5.5" is split to go through direct outbound { "ip": ["223.5.5.5"], "outboundTag": "direct" }, - // 3.5 国内IP直连 + // 3.5 Domestic IPs direct connection { "ip": ["geoip:cn", "geoip:private"], "outboundTag": "direct" } - // 3.6 默认规则 - // 在Xray中，任何不符合上述路由规则的流量，都会默认使用【第一个outbound（5.1）】的设置，所以一定要把转发VPS的outbound放第一个 + // 3.6 Default Rule + // In Xray, any traffic that does not match the above routing rules will default to using the setting of the [First Outbound (5.1)]. So be sure to put the VPS forwarding outbound first. ] }, - // 4_入站设置 + // 4_Inbound Settings "inbounds": [ - // 4.1 一般都默认使用socks5协议作本地转发 + // 4.1 Generally, socks5 protocol is used by default for local forwarding { "tag": "socks-in", "protocol": "socks", - "listen": "127.0.0.1", // 这个是通过socks5协议做本地转发的地址 - "port": 10800, // 这个是通过socks5协议做本地转发的端口 + "listen": "127.0.0.1", // This is the address for local forwarding via socks5 + "port": 10800, // This is the port for local forwarding via socks5 "settings": { "udp": true } }, - // 4.2 有少数APP不兼容socks协议，需要用http协议做转发，则可以用下面的端口 + // 4.2 A few APPs are incompatible with socks protocol and need http protocol for forwarding, use the port below { "tag": "http-in", "protocol": "http", - "listen": "127.0.0.1", // 这个是通过http协议做本地转发的地址 - "port": 10801 // 这个是通过http协议做本地转发的端口 + "listen": "127.0.0.1", // This is the address for local forwarding via http + "port": 10801 // This is the port for local forwarding via http } ], - // 5_出站设置 + // 5_Outbound Settings "outbounds": [ - // 5.1 默认转发VPS - // 一定放在第一个，在routing 3.6 里面已经说明了，这等于是默认规则，所有不符合任何规则的流量都走这个 + // 5.1 Default forwarding to VPS + // Must be placed first. As explained in routing 3.6, this acts as the default rule; all unmatched traffic goes here. { "tag": "proxy", "protocol": "vless", "settings": { "vnext": [ { - "address": "a-name.yourdomain.com", // 替换成你的真实域名 + "address": "a-name.yourdomain.com", // Replace with your real domain "port": 443, "users": [ { - "id": "uuiduuid-uuid-uuid-uuid-uuiduuiduuid", // 和服务器端的一致 + "id": "uuiduuid-uuid-uuid-uuid-uuiduuiduuid", // Consistent with server-side "flow": "xtls-rprx-vision", "encryption": "none", "level": 0 @@ -227,18 +225,18 @@ "network": "tcp", "security": "tls", "tlsSettings": { - "serverName": "a-name.yourdomain.com", // 替换成你的真实域名 - "allowInsecure": false, // 禁止不安全证书 - "fingerprint": "chrome" // 通过 uTLS 库 模拟 Chrome / Firefox / Safari 或随机生成的指纹 + "serverName": "a-name.yourdomain.com", // Replace with your real domain + "allowInsecure": false, // Disallow insecure certificates + "fingerprint": "chrome" // Use uTLS library to simulate Chrome / Firefox / Safari or randomized fingerprint } } }, - // 5.2 用`freedom`协议直连出站，即当routing中指定'direct'流出时，调用这个协议做处理 + // 5.2 Direct outbound using `freedom` protocol. Called when routing specifies 'direct'. { "tag": "direct", "protocol": "freedom" }, - // 5.3 用`blackhole`协议屏蔽流量，即当routing中指定'block'时，调用这个协议做处理 + // 5.3 Block traffic using `blackhole` protocol. Called when routing specifies 'block'. { "tag": "block", "protocol": "blackhole" @@ -247,76 +245,76 @@ } ``` -## 8.4 附加题 2：在 PC 端手工运行 `xray-core` +## 8.4 Bonus Task 2: Manually Running `xray-core` on PC -写好了配置文件该，要怎么让 `xray-core` 运行起来呢？双击好像并没有反应啊？ +After writing the configuration file, how do you make `xray-core` run? Double-clicking seems to have no reaction? -首先，你要找到电脑上的【命令行界面】。 +First, you need to find the [Command Line Interface] on your computer. -1. Linux 桌面、macOS 系统的同学肯定已经比较熟悉了，搜索 `Console` 或者 `Terminal` 就可以 -2. Windows 就可以搜索使用 `Cmd` 或者 `Powershell` 等程序（WSL 的同学你坐下，你的 `Console` 当然也可以） +1. Linux desktop and macOS users are certainly familiar with this; just search for `Console` or `Terminal`. +2. Windows users can search for and use `Cmd` or `Powershell` programs (WSL users, sit down, your `Console` works too, of course). -其次，我们要做的事情是【让 `xray` 找到并读取配置文件 `config.json`，然后运行】，所以： +Secondly, what we need to do is [make `xray` find and read the configuration file `config.json`, and then run]. So: -1. 在 Windows 下，假设你的 `Xray` 程序位置是 `C:\Xray-windows-64\xray.exe`，配置文件位置是`C:\Xray-windows-64\config.json`，那么正确的启动命令就是： +1. On Windows, assuming your `Xray` program location is `C:\Xray-windows-64\xray.exe` and the configuration file location is `C:\Xray-windows-64\config.json`, the correct startup command is: - ```shell - C:\Xray-windows-64\xray.exe -c C:\Xray-windows-64\config.json - ``` + ```shell + C:\Xray-windows-64\xray.exe -c C:\Xray-windows-64\config.json + ``` - :::tip 说明 - 这里的 `-c` 就是指定配置文件路径的参数，告诉 `xray` 去后面的位置找配置文件 - ::: + :::tip Explanation + The `-c` here is the parameter to specify the configuration file path, telling `xray` to look for the configuration file at the location following it. + ::: -2. 相似的，在 Linux 和 macOS 下，假设你的 `Xray` 程序位置是 `/usr/local/bin/xray`，配置文件位置是`/usr/local/etc/xray/config.json`，那么正确的启动命令就是 +2. Similarly, on Linux and macOS, assuming your `Xray` program location is `/usr/local/bin/xray` and the configuration file location is `/usr/local/etc/xray/config.json`, the correct startup command is: - ```shell - /usr/local/bin/xray -c /usr/local/etc/xray/config.json - ``` + ```shell + /usr/local/bin/xray -c /usr/local/etc/xray/config.json + ``` - :::tip 说明 - 每个系统都有系统路径变量，所以写 `Xray` 程序时不一定要写绝对路径。但是写了肯定没错，所以我就如此演示了。 - ::: + :::tip Explanation + Every system has system path variables, so you don't necessarily have to write the absolute path when typing the `Xray` program. But writing it is definitely not wrong, so I demonstrated it that way. + ::: -## 8.5 附加题 3：在 PC 端开机自动运行 `xray-core` +## 8.5 Bonus Task 3: Auto-start `xray-core` on PC Boot -如果你真的尝试了手动运行 `xray-core`，你一定会发现这个方式还有点小问题： +If you really tried running `xray-core` manually, you must have found a small problem with this method: -1. 每次运行 `Xray` 都要出现一个黑乎乎的窗口，很丑 -2. 不能开机自动运行，每次都要手工输入，十分不方便 +1. Every time `Xray` runs, a dark window appears, which is ugly. +2. It cannot run automatically at startup; manually typing it every time is very inconvenient. -我可以肯定的告诉你：**完全可以解决**。但是具体的解决方式，就当作课外作业留给大家吧！（友情提示，文档站的问答区有线索哦） +I can tell you with certainty: **It is completely solvable**. But as for the specific solution, let's leave it as homework for everyone! (Friendly hint: there are clues in the Q&A section of the documentation site). -## 8.6 圆满完成！ +## 8.6 Mission Accomplished -我相信，有耐心看到这里的同学，都是兼具好奇心和行动力的学习派！我现在要郑重的恭喜你，因为到了这里，你已经完完整整的【**从第一条命令开始，完成了 VPS 服务器部署，并成功的在客户端配置使用 Xray**】了！这毫无疑问是一个巨大的胜利！ +I believe that students who have the patience to read this far are learners with both curiosity and the ability to take action! I want to solemnly congratulate you now, because by this point, you have completely **[started from the first command, completed the VPS server deployment, and successfully configured and used Xray on the client]**! This is undoubtedly a huge victory! -我相信，你现在一定对`Linux`不再恐惧，对`Xray`不再陌生了吧！ +I believe you are no longer afraid of `Linux` and no longer unfamiliar with `Xray`! -**至此，小小白白话文圆满结束！** +**Here, the Absolute Beginner's Plain Guide concludes successfully!** > ⬛⬛⬛⬛⬛⬛⬛⬛ 100% -## 8.7 TO INFINITY AND BEYOND! +## 8.7 TO INFINITY AND BEYOND -**但现在你看到的，远远不是 Xray 的全貌。** +**But what you see now is far from the full picture of Xray.** -`Xray`是一个强大而丰富的网络工具集合，平台化的提供了众多模块，可以像瑞士军刀一样，通过灵活的配置组合解决各种不同的问题。而本文，仅仅蜻蜓点水的用了**最简单**、**最直观**的配置来做**基础演示**。 +`Xray` is a powerful and rich collection of network tools. It provides numerous modules as a platform, which can solve various problems through flexible configuration combinations like a Swiss Army knife. This article only skimmed the surface using the **simplest** and **most intuitive** configuration for a **basic demonstration**. -如果你觉得现在已经完全够用了，那就好好的享受它给你带来的信息自由。但如果你的好奇心依然不能停歇，那就去继续挖掘它无限的可能性吧！ +If you feel that it is completely sufficient now, then enjoy the information freedom it brings you. But if your curiosity still cannot rest, then go ahead and continue to dig into its infinite possibilities! -需要更多信息，可以到这里寻找： +For more information, you can find it here: -1. [xtls.github.io](https://xtls.github.io/) - 官方文档站 -2. [官方 Telegram 群组](https://t.me/projectXray) - 活跃而友善的官方讨论社区 +1. [xtls.github.io](https://xtls.github.io/) - Official Documentation Site +2. [Official Telegram Group](https://t.me/projectXray) - Active and friendly official discussion community  -:::tip 不算后记的后记 +:::tip A Postscript that isn't really a Postscript -希望我陪你走过的这一段小小的旅程，可以成为你网络生活中的一份小小助力。 +I hope this small journey I accompanied you on can become a small boost in your online life. -这篇文章里的工具和信息难免会一点点的陈旧过时，但你一定会逐渐成长为大佬。未来的某个时间，若你能偶尔想起这篇教程、想起我写下本文的初衷，那我衷心希望你能够薪火相传、把最新的知识分享给后来人，让这一份小小的助力在社区里坚定的传递下去。 +The tools and information in this article will inevitably become slightly outdated, but you will surely grow into an expert. Sometime in the future, if you occasionally recall this tutorial and the original intention with which I wrote it, I sincerely hope you can pass on the torch, share the latest knowledge with newcomers, and let this small boost continue to be passed down firmly in the community. -这是个大雪封山乌云密布的世界，人们孤独的走在各自的路上试图寻找阳光，如果大家偶尔交汇时不能守望相助互相鼓励，那最终剩下的，恐怕只有【千山鸟飞绝 万径人踪灭】的凄凉了吧。 +This is a world where heavy snow seals the mountains and dark clouds loom. People walk lonely on their respective paths trying to find sunlight. If we cannot watch out for and encourage each other when we occasionally cross paths, then ultimately, I fear only the desolation of "a thousand mountains with no birds flying, ten thousand paths with no human footprints" will remain. ::: diff --git a/docs/en/document/level-0/ch09-appendix.md b/docs/en/document/level-0/ch09-appendix.md index 1967239a..1b50ea5f 100644 --- a/docs/en/document/level-0/ch09-appendix.md +++ b/docs/en/document/level-0/ch09-appendix.md @@ -1,46 +1,46 @@ -# 【第 9 章】附录 +# [Chapter 9] Appendix -## 1. 小小白白 Linux 基础命令索引 +## 1. Index of Basic Linux Commands for Beginners -| 编号 | 命令名称 | 命令说明 | 出现篇章 | -| :------: | :------------------ | :--------------------------- | :----------------------------------------: | -| `cmd-01` | `apt update` | 查询软件更新 | [《远程登录篇》](./ch03-ssh.md) | -| `cmd-02` | `apt upgrade` | 执行软件更新 | [《远程登录篇》](./ch03-ssh.md) | -| `cmd-03` | `nano` | 文本编辑器 | [《安全防护篇》](./ch04-security.md) | -| `cmd-04` | `systemctl restart` | 重启某个服务 | [《安全防护篇》](./ch04-security.md) | -| `cmd-05` | `adduser` | 给系统新增用户 | [《安全防护篇》](./ch04-security.md) | -| `cmd-06` | `apt install` | 安装某个软件 | [《安全防护篇》](./ch04-security.md) | -| `cmd-07` | `visudo` | 修改 sudo 权限设置专用编辑器 | [《安全防护篇》](./ch04-security.md) | -| `cmd-08` | `sudo` | 用`root`权限运行某个命令 | [《安全防护篇》](./ch04-security.md) | -| `cmd-09` | `chmod` | 修改目标文件/文件夹的权限 | [《安全防护篇》](./ch04-security.md) | -| `cmd-10` | `mkdir` | 新建文件夹 | [《网站建设篇》](./ch05-webpage.md) | -| `cmd-11` | `systemctl reload` | 重新加载某个服务 | [《网站建设篇》](./ch05-webpage.md) | -| `cmd-12` | `wget` | 访问（或下载）某个网页文件 | [《证书管理篇》](./ch06-certificates.md) | -| `cmd-13` | `acme.sh` | acme.sh 证书管理相关的命令 | [《证书管理篇》](./ch06-certificates.md) | -| `cmd-14` | `rm` | 删除命令 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `cmd-15` | `crontab -e` | 编辑当前用户的定时任务 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `cmd-16` | `touch` | 建立空白文件 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `cmd-17` | `systemctl` | `systemd`基本服务管理命令 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `cmd-18` | `reboot` | 重启 Linux 系统 | [《Xray 服务器篇》](./ch07-xray-server.md) | +| ID | Command Name | Description | Featured Chapter | +| :----: | :------------------ | :--------------------------- | :------------------------------------------: | +| `cmd-01` | `apt update` | Check for software updates | [[Chapter 3: Remote Login]](./ch03-ssh.md) | +| `cmd-02` | `apt upgrade` | Execute software updates | [[Chapter 3: Remote Login]](./ch03-ssh.md) | +| `cmd-03` | `nano` | Text editor | [[Chapter 4: Security Protection]](./ch04-security.md) | +| `cmd-04` | `systemctl restart` | Restart a service | [[Chapter 4: Security Protection]](./ch04-security.md) | +| `cmd-05` | `adduser` | Add a new user to the system | [[Chapter 4: Security Protection]](./ch04-security.md) | +| `cmd-06` | `apt install` | Install a software package | [[Chapter 4: Security Protection]](./ch04-security.md) | +| `cmd-07` | `visudo` | Dedicated editor for sudo privileges | [[Chapter 4: Security Protection]](./ch04-security.md) | +| `cmd-08` | `sudo` | Run a command with `root` privileges | [[Chapter 4: Security Protection]](./ch04-security.md) | +| `cmd-09` | `chmod` | Change permissions of a file/folder | [[Chapter 4: Security Protection]](./ch04-security.md) | +| `cmd-10` | `mkdir` | Create a new directory (folder) | [[Chapter 5: Website Building]](./ch05-webpage.md) | +| `cmd-11` | `systemctl reload` | Reload a service | [[Chapter 5: Website Building]](./ch05-webpage.md) | +| `cmd-12` | `wget` | Access (or download) a web file | [[Chapter 6: Certificate Management]](./ch06-certificates.md) | +| `cmd-13` | `acme.sh` | Commands related to acme.sh certificate management | [[Chapter 6: Certificate Management]](./ch06-certificates.md) | +| `cmd-14` | `rm` | Remove (delete) command | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `cmd-15` | `crontab -e` | Edit current user's scheduled tasks | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `cmd-16` | `touch` | Create an empty file | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `cmd-17` | `systemctl` | Basic `systemd` service management command | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `cmd-18` | `reboot` | Reboot the Linux system | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | -## 2. 小小白白 Linux 重要配置文件索引 +## 2. Index of Important Linux Configuration Files for Beginners -| 编号 | 配置文件位置 | 文件说明 | 出现篇章 | -| :-------: | :-------------------------------------- | :----------------------------- | :----------------------------------------: | -| `conf-01` | `/etc/ssh/sshd_config` | SSH 远程登录程序设置 | [《远程登录篇》](./ch03-ssh.md) | -| `conf-02` | `/etc/nginx/nginx.conf` | Nginx 程序设置 | [《网站建设篇》](./ch05-webpage.md) | -| `conf-03` | `/etc/apt/sources.list` | apt 软件源列表 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `conf-04` | `/etc/apt/sources.list.d/vpsadmin.list` | 用户自定义软件源列表列表 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `conf-05` | `crontab -e` | 当前用户的定时任务 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `conf-06` | `/etc/sysctl.conf` | 手动设置 kernel 参数 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `conf-07` | `/etc/sysctl.d/vpsadmin.conf` | 用户自定义 kernel 参数配置文件 | [《Xray 服务器篇》](./ch07-xray-server.md) | +| ID | Config File Location | File Description | Featured Chapter | +| :-------: | :-------------------------------------- | :----------------------------- | :------------------------------------------: | +| `conf-01` | `/etc/ssh/sshd_config` | SSH remote login program settings | [[Chapter 3: Remote Login]](./ch03-ssh.md) | +| `conf-02` | `/etc/nginx/nginx.conf` | Nginx program settings | [[Chapter 5: Website Building]](./ch05-webpage.md) | +| `conf-03` | `/etc/apt/sources.list` | apt software source list | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `conf-04` | `/etc/apt/sources.list.d/vpsadmin.list` | User-defined software source list | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `conf-05` | `crontab -e` | Current user's scheduled tasks | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `conf-06` | `/etc/sysctl.conf` | Manual kernel parameter settings | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `conf-07` | `/etc/sysctl.d/vpsadmin.conf` | User-defined kernel parameter config file | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | -## 3. 小小白白 Xray 重要文件索引 +## 3. Index of Important Xray Files for Beginners -| 编号 | 配置文件位置 | 文件说明 | 出现篇章 | -| :-------: | :----------------------------------- | :------------ | :----------------------------------------: | -| `xray-01` | `/usr/local/etc/xray/config.json` | Xray 程序设置 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `xray-02` | `/home/vpsadmin/xray_cert/xray.cert` | TLS 证书 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `xray-03` | `/home/vpsadmin/xray_cert/xray.key` | TLS 私钥 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `xray-04` | `/home/vpsadmin/xray_log/access.log` | Xray 访问日志 | [《Xray 服务器篇》](./ch07-xray-server.md) | -| `xray-05` | `/home/vpsadmin/xray_log/error.log` | Xray 错误日志 | [《Xray 服务器篇》](./ch07-xray-server.md) | +| ID | Config File Location | File Description | Featured Chapter | +| :-------: | :----------------------------------- | :--------------- | :------------------------------------------: | +| `xray-01` | `/usr/local/etc/xray/config.json` | Xray program settings | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `xray-02` | `/home/vpsadmin/xray_cert/xray.cert` | TLS Certificate | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `xray-03` | `/home/vpsadmin/xray_cert/xray.key` | TLS Private Key | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `xray-04` | `/home/vpsadmin/xray_log/access.log` | Xray Access Log | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | +| `xray-05` | `/home/vpsadmin/xray_log/error.log` | Xray Error Log | [[Chapter 7: Xray Server]](./ch07-xray-server.md) | diff --git a/docs/en/document/level-0/index.md b/docs/en/document/level-0/index.md index a18856c2..a5a6c2d0 100644 --- a/docs/en/document/level-0/index.md +++ b/docs/en/document/level-0/index.md @@ -1,25 +1,25 @@ -# Plain and Simple Language +# Absolute Beginner's Plain Guide -**This chapter is a basic lesson of [Starting from Scratch]. New students, please watch and learn carefully.** +**This section is a [From Scratch] foundation course. Newcomers, please read and study carefully!** ::: tip Made with ❤️ by [@ricuhkaen](https://github.com/ricuhkaen) ::: -[【Chapter 1】 Preface: Rambling](./ch01-preface.md) - Airport or Self-built? That is the question. +[[Chapter 1] Preface](./ch01-preface.md) - Commercial Provider or Self-Hosted? That Is the Question -[Chapter 2: Preparation of Raw Materials](./ch02-preparation.md) - Tools must be sharpened before they can be used proficiently. +[[Chapter 2] Preparation](./ch02-preparation.md) - To Do a Good Job, One Must First Sharpen One's Tools -[Chapter 3: Remote Login](./ch03-ssh.md) - A bridge connecting the north and south, turning a natural obstacle into a thoroughfare. +[[Chapter 3] Remote Login (SSH)](./ch03-ssh.md) - Bridging the Gap -[【Chapter 4】Security Protection](./ch04-security.md) - If you don't pay attention to security, you will shed tears for your loved ones. +[[Chapter 4] Security](./ch04-security.md) - Safety First, or Regret Later -[【Chapter 5】Website Construction] - Show Your Beauty (Link to webpage.md file) +[[Chapter 5] Website Setup](./ch05-webpage.md) - Show Your Style -[Chapter 6: Certificate Management](./ch06-certificates.md) - Only those who obtain certificates are considered legitimate. +[[Chapter 6] Certificates](./ch06-certificates.md) - It's Only Legal with a License -[Chapter 7: Xray Server](./ch07-xray-server.md) - Finally, waited for you. +[[Chapter 7] Xray Server](./ch07-xray-server.md) - The Moment You've Been Waiting For -[Chapter 8: Xray Client](./ch08-xray-clients.md) - A New Beginning. +[[Chapter 8] Xray Clients](./ch08-xray-clients.md) - A New Beginning -[Chapter 9] Appendix - All the exam points are here. +[[Chapter 9] Appendix](./ch09-appendix.md) - Key Takeaways Are Here diff --git a/docs/en/document/level-1/fallbacks-lv1.md b/docs/en/document/level-1/fallbacks-lv1.md index e71b6573..d7fd67ec 100644 --- a/docs/en/document/level-1/fallbacks-lv1.md +++ b/docs/en/document/level-1/fallbacks-lv1.md @@ -1,10 +1,10 @@ -# 回落 (fallbacks) 功能简析 +# A Brief Analysis of Fallbacks -在使用 Xray 的过程中，你一定无数次的听说了【回落】这个功能。本文就稍微说明一下这个功能的逻辑以及使用方式。 +In the process of using Xray, you must have heard about the **[Fallback]** function countless times. This article will briefly explain the logic and usage of this function. -## 1. 回顾《小小白白话文》中的回落 +## 1. Reviewing Fallbacks in the "Beginner's Guide" -如果你用了《小小白白话文》中的[Xray 配置](../level-0/ch07-xray-server.md#_7-4-配置xray)，并完成了[HTTP 自动跳转 HTTPS 优化](../level-0/ch07-xray-server.md#_7-8-服务器优化之二-开启http自动跳转https)，那么你已经有了基于 `VLESS` 协议的简易回落： +If you used the [Xray Configuration](../level-0/ch07-xray-server.md#_7-4-configuration-xray) from the *Beginner's Guide* and completed the [HTTP to HTTPS Redirection Optimization](../level-0/ch07-xray-server.md#_7-8-server-optimization-part-2-enable-http-automatic-jump-to-https), then you already have a simple fallback based on the `VLESS` protocol: ```json { @@ -19,7 +19,7 @@ "decryption": "none", "fallbacks": [ { - "dest": 8080 // 默认回落到防探测的代理 + "dest": 8080 // Default fallback to the probe-resistant proxy/service } ] }, @@ -31,109 +31,109 @@ } ``` -这一段配置用人话要怎么解释呢？ +How do we explain this configuration in plain language? -1. **`Xray` 的入站端口 `[inbound port]` 是 `443`** +1. **Xray's `[inbound port]` is `443`** - 即由 `Xray` 负责监听 `443` 端口的 `HTTPS` 流量 + This means `Xray` is responsible for listening to `HTTPS` traffic on port `443`. -2. **`Xray` 的入站协议 `[inbound protocol]` 是 `vless`** +2. **Xray's `[inbound protocol]` is `vless`** - 只有 `vless` 协议的流量才会流入 `Xray` 中做后续处理。 + Only traffic using the `vless` protocol will flow into `Xray` for further processing. - ::: warning - **注：** `VLESS` 这个轻量协议开发的初衷就是给 `xray` 及 `v2fly` 等核心引入回落功能、并同时减少冗余校验/加密。（当然，到目前为止，`xray` 中的 `trojan` 协议也已完整支持回落功能。） - ::: + ::: warning + **Note:** The `VLESS` lightweight protocol was originally developed to introduce the fallback function to cores like `xray` and `v2fly`, while reducing redundant verification/encryption. (Of course, as of now, the `trojan` protocol in `xray` also fully supports the fallback function.) + ::: -3. **回落目标端口 `[fallback dest]` 是 `8080`** +3. **The `[fallback dest]` is `8080`** - `Xray` 接受 `443` 端口的访问流量后，属于 `vless` 协议的流量、由 `Xray` 进行内部处理并转发至出站模块。而其他非 `vless` 协议的流量，则转发至 `8080` 端口。 + After `Xray` accepts traffic on port `443`, traffic belonging to the `vless` protocol is processed internally by `Xray` and forwarded to the outbound module. Traffic that is *not* `vless` protocol is forwarded to port `8080`. - ::: warning - **问：到底是单数还是复数？** + ::: warning + **Q: Is it singular or plural?** - 答：一定有聪明的同学发现，配置文件中，明明是复数 `inbounds`, `fallbacks`，为什么我解释的时候都是单数：`inbound`, `fallback` 呢？ + A: Some sharp students may have noticed that in the configuration file, the keys are plural (`inbounds`, `fallbacks`), but when I explain them, I use the singular (`inbound`, `fallback`). Why? - 因为，配置文件中用复数，说明 `xray` 支持 N 个同等级的元素（即 N 个入站，M 个回落等等），上面的示例解析中仅仅是其中一个，所以我用了单数。 - ::: + Because the plural form in the configuration file indicates that `xray` supports N elements of the same level (i.e., N inbounds, M fallbacks, etc.). In the example analysis above, we are referring to just one of them, so I used the singular. + ::: -4. **回落给 `8080` 端口的流量，由后续程序处理** +4. **Traffic falling back to port `8080` is handled by a subsequent program** - 小小白白话文中的示例，就是 `8080` 端口由 `Nginx` 处理，根据配置找到并展示小熊猫的网页。 + In the example from the *Beginner's Guide*, port `8080` is handled by `Nginx`, which finds and displays the Red Panda webpage based on its configuration. -5. **总结，小小白白话文示例中的最简单回落，完整数据路线如下：** +5. **Summary: The complete data route for the simplest fallback in the Beginner's Guide is as follows:** - ```mermaid - graph LR; + ```mermaid + graph LR; - W(外部 HTTP:80 请求) --> N80(HTTP:80) + W(External HTTP:80 Request) --> N80(HTTP:80) - subgraph Nginx 外部监听 - N80 -.- N301(301转写) -.- N443(HTTPS:443) - end + subgraph Nginx External Listener + N80 -.- N301(301 Redirect) -.- N443(HTTPS:443) + end - N443 --> X(Xray 监听 443) .- X1{入站判断} - X1 --> |接收 VLESS 流量| X2(Xray内部规则) - X2 --> O(Xray Outbounds 出站) - X1 ==> |回落 非VLESS 流量| N8080(Nginx:8080) - N8080:::nginxclass ==> H(index.html) + N443 --> X(Xray Listener 443) .- X1{Inbound Judgment} + X1 --> |Receive VLESS Traffic| X2(Xray Internal Rules) + X2 --> O(Xray Outbounds) + X1 ==> |Fallback Non-VLESS Traffic| N8080(Nginx:8080) + N8080:::nginxclass ==> H(index.html) - H:::nginxclass - classDef nginxclass fill:#FFFFDE + H:::nginxclass + classDef nginxclass fill:#FFFFDE - ``` + ``` -## 2. 重新认识回落 (WHAT, HOW `v1`) +## 2. Re-understanding Fallbacks (WHAT, HOW `v1`) -基于上面的示例，你应该就可以明白什么是回落（What）和怎么回落（How）了，简单地说就是下面这几个要素： +Based on the example above, you should understand what a fallback is (What) and how it works (How). Simply put, it involves these elements: -1. 回落的时间是流量进入 `Xray监听端口` 后 -2. 回落的依据是 `协议类型` 等流量特征 -3. 回落的目标是某个 `端口` -4. 被回落的流量由监听 `回落端口` 的后续程序接手 +1. The **Time** of fallback is after traffic enters the `Xray Listening Port`. +2. The **Basis** for fallback is traffic characteristics like `Protocol Type`. +3. The **Target** of fallback is a specific `Port`. +4. The traffic being fallen back is taken over by a subsequent program listening on the `Fallback Port`. -## 3. 为什么要回落 (WHY `v1`) +## 3. Why Use Fallbacks (WHY `v1`) -最初，是为了防御 **【主动探测】** (Active Probing) +Initially, it was to defend against **[Active Probing]**. -**主动探测：** 简单粗暴的理解，就是指外部通过发送特定的网络请求，并解读服务器的回应内容，来推测服务器端是否运行了 `xray`, `v2fly`, `shadowsocks` 等代理工具。一旦可以准确认定，则服务器可能受到干扰或阻断。 +**Active Probing:** To put it simply and crudely, this refers to external parties sending specific network requests and interpreting the server's response to guess whether the server is running proxy tools like `xray`, `v2fly`, or `shadowsocks`. Once accurately identified, the server may be interfered with or blocked. -之所以可以根据服务器回应内容进行解读，就是因为一次完整的数据请求，其实有很多数据交换的步骤，每一个步骤，都会产生一些软件特征。用大白话说就是： +The reason interpretation is possible based on server responses is that a complete data request involves many steps of data exchange, and each step produces certain software signatures. In plain English: -- 正常的网站的回应，一定【会有】类似 `Nginx`, `Apache`, `MySQL` 的 Web 服务、数据库等工具的特征 -- 正常的网站的回应，一定【不会有】类似 `xray`, `v2fly`, `shadowsocks` 等代理工具的特征 +- A normal website response will definitely **[HAVE]** signatures of Web services/databases like `Nginx`, `Apache`, `MySQL`, etc. +- A normal website response will definitely **[NOT HAVE]** signatures of proxy tools like `xray`, `v2fly`, `shadowsocks`, etc. -于是，当我们给 `Xray` 提供了【回落】功能后（如上例，回落给 `Nginx`），面对任何用来探测的请求，产生的结果是： +Therefore, when we provide the **[Fallback]** function to `Xray` (as in the example above, falling back to `Nginx`), the result when facing any probing request is: -- 探测流量无法掌握你的 `VLESS` 要素，故都会被回落至 `Nginx` -- 探测流量全都回落进入 `Nginx` ，故 VPS 服务器的回应一定【会有】 `Nginx` 的特征 -- 因为 `Xray` 本身不对探测流量做任何回应 ，所以 VPS 的回应一定【不会有】 `Xray` 的特征 +- Probing traffic cannot master your `VLESS` secrets/elements, so it will all fall back to `Nginx`. +- Since probing traffic falls back into `Nginx`, the VPS server's response will definitely **[HAVE]** `Nginx` signatures. +- Because `Xray` itself does not respond to probing traffic, the VPS response will definitely **[NOT HAVE]** `Xray` signatures. -至此，【回落】功能就从数据交互逻辑上解决了服务器被 **【主动探测】** 的安全隐患。 +Thus, the **[Fallback]** function solves the security risk of the server being **[Actively Probed]** from the logic of data interaction. -## 4. 重新认识【回落の完全体】 (WHAT, WHY, HOW `v2`) +## 4. Re-understanding the [Perfect Form of Fallback] (WHAT, WHY, HOW `v2`) -为什么又要再次认识回落呢？ 因为，上面仅仅说清楚了基于“协议”的、抵抗【主动探测】的初版回落。 +Why do we need to understand fallbacks again? Because the above only explains the initial version of fallbacks based on "protocols" for resisting [Active Probing]. -在 [RPRX](https://github.com/rprx) 不断开发迭代 `VLESS` 协议及 `fallback` 功能的过程中，逐渐发现，回落完全可以更加灵活强大，只要在保证抵抗【主动探测】的前提下，充分利用数据首包中的信息，其实可以做到多元素、多层次的回落。（如 `path`, `alpn` 等） +During the continuous development and iteration of the `VLESS` protocol and `fallback` function by [RPRX](https://github.com/rprx), it was discovered that fallbacks could be much more flexible and powerful. As long as the premise of resisting [Active Probing] is met, by fully utilizing the information in the first data packet, multi-element and multi-level fallbacks (such as `path`, `alpn`, etc.) can be achieved. -基于这个开发理念，【回落】功能才逐渐成长为现在的完全体，即完成了 `纯伪装 --> ws分流 --> 多协议多特征分流` 的进化。最终版甚至完全替代了以前要用 Web 服务器、其他工具才能完成的分流的功能。且由于上述的【回落/分流】处理都在首包判断阶段以毫秒级的速度完成、不涉及任何数据操作，所以几乎没有任何过程损耗。 +Based on this development philosophy, the **[Fallback]** function has gradually grown into its current "Perfect Form," completing the evolution from `Pure Camouflage --> WS Shunting --> Multi-protocol Multi-feature Shunting`. The final version has even completely replaced the shunting functions that previously required Web servers or other tools. Moreover, since the aforementioned [Fallback/Shunting] processing is completed at the first packet judgment stage with millisecond-level speed and does not involve any data manipulation, there is almost no process loss. -**因此，现在 `Xray` 中【完整体的回落功能】，同时具备下述属性：** +**Therefore, the [Complete Fallback Function] in `Xray` now possesses the following attributes:** -- **安全：** 充分抵御主动探测攻击 -- **高效：** 几乎毫无性能损失 -- **灵活：** 数据灵活分流、常用端口复用（如 443） +- **Secure:** Fully resists active probing attacks. +- **Efficient:** Almost zero performance loss. +- **Flexible:** Flexible data shunting, reuse of common ports (like 443). -::: tip 啰嗦君 -这样多轮介绍虽然略显繁琐，但只有这样层层深入展开，才能充分的说明【回落の完全体】独有的强大！ +::: tip Mr. Wordy +Although explaining it in multiple rounds seems tedious, only by peeling it back layer by layer can we fully demonstrate the unique power of the [Perfect Form of Fallback]! ::: -## 5. 多层回落示例及解读 +## 5. Multi-layer Fallback Example and Interpretation -理解了【回落の完全体】是什么，那就可以动手操作配置多层回落了。其实，项目已经提供了非常完整的示例，即官方模板中的 [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/)。 +Now that you understand what the [Perfect Form of Fallback] is, you can get your hands dirty configuring multi-layer fallbacks. -### 5.1 首先，我将服务器端配置的 443 监听段摘抄如下： +### 5.1 First, I will extract the server-side configuration for port 443 as follows ```json { @@ -142,7 +142,7 @@ "settings": { "clients": [ { - "id": "", // 填写你的 UUID + "id": "", // Fill in your UUID "flow": "xtls-rprx-vision", "level": 0, "email": "love@example.com" @@ -151,21 +151,21 @@ "decryption": "none", "fallbacks": [ { - "dest": 1310, // 默认回落到 Xray 的 Trojan 协议 + "dest": 1310, // Default fallback to Xray's Trojan protocol "xver": 1 }, { - "path": "/websocket", // 必须换成自定义的 PATH + "path": "/websocket", // Must be changed to your custom PATH "dest": 1234, "xver": 1 }, { - "path": "/vmesstcp", // 必须换成自定义的 PATH + "path": "/vmesstcp", // Must be changed to your custom PATH "dest": 2345, "xver": 1 }, { - "path": "/vmessws", // 必须换成自定义的 PATH + "path": "/vmessws", // Must be changed to your custom PATH "dest": 3456, "xver": 1 } @@ -178,8 +178,8 @@ "alpn": ["http/1.1"], "certificates": [ { - "certificateFile": "/path/to/fullchain.crt", // 换成你的证书，绝对路径 - "keyFile": "/path/to/private.key" // 换成你的私钥，绝对路径 + "certificateFile": "/path/to/fullchain.crt", // Absolute path to your certificate + "keyFile": "/path/to/private.key" // Absolute path to your private key } ] } @@ -187,194 +187,194 @@ } ``` -这一段配置用人话要怎么解释呢？ +How do we explain this configuration in plain language? -1. **`Xray` 的入站端口 (`inbound port`) 是 `443`** +1. **Xray's `[inbound port]` is `443`** - 即由 `Xray` 负责监听 `443` 端口的 `HTTPS` 流量，并使用 `certificates` 项下设定的 `TLS` 证书来进行验证 + This means `Xray` is responsible for listening to `HTTPS` traffic on port `443` and uses the `TLS` certificate set under `certificates` for verification. -2. **`Xray` 的入站协议 (`inbound protocol`) 是 `vless`** +2. **Xray's `[inbound protocol]` is `vless`** - `vless` 协议流量直接流入 `Xray` 中做后续处理 + `vless` protocol traffic flows directly into `Xray` for subsequent processing. -3. **非 `VLESS` 协议流量有 4 个不同的回落目标：** - 1. `path` 为 `websocket` 的流量，回落给端口 `1234` 后续处理 - 2. `path` 为 `vmesstcp` 的流量，回落给端口 `2345` 后续处理 - 3. `path` 为 `vmessws` 的流量，回落给端口 `3456` 后续处理 - 4. 其它所有流量，回落给端口 `1310` 后续处理 +3. **Non-`VLESS` protocol traffic has 4 different fallback targets:** + 1. Traffic with `path` as `/websocket` falls back to port `1234` for processing. + 2. Traffic with `path` as `/vmesstcp` falls back to port `2345` for processing. + 3. Traffic with `path` as `/vmessws` falls back to port `3456` for processing. + 4. All other traffic falls back to port `1310` for processing. -4. **`xver` 为 `1` 表示开启 `proxy protocol` 功能，向后传递来源真实 IP** +4. **`xver` set to `1` means enabling the `proxy protocol` function to pass the real source IP backwards.** -5. **上述回落结构如下图所示：** +5. **The fallback structure described above is shown in the diagram below:** - ```mermaid - graph LR; + ```mermaid + graph LR; - W443(外部 HTTP:443 请求) --> X443(Xray-inbound: 443) .- X1{入站判断} - X1 --> |协议 = VLESS 的流量| X2(Xray内部规则) - X2 --> O(Xray Outbounds 出站) + W443(External HTTP:443 Request) --> X443(Xray-inbound: 443) .- X1{Inbound Judgment} + X1 --> |Protocol = VLESS Traffic| X2(Xray Internal Rules) + X2 --> O(Xray Outbounds) - X1 --> |path = /websocket 的流量| X1234(Xray-inbound:1234) - X1 --> |path = /vmesstcp 的流量| X2345(Xray-inbound:2345) - X1 --> |path = /vmessws 的流量| X3456(Xray-inbound:3456) - X1 --> |其它所有流量| X1310(Xray-inbound:1310) + X1 --> |path = /websocket Traffic| X1234(Xray-inbound:1234) + X1 --> |path = /vmesstcp Traffic| X2345(Xray-inbound:2345) + X1 --> |path = /vmessws Traffic| X3456(Xray-inbound:3456) + X1 --> |All Other Traffic| X1310(Xray-inbound:1310) - ``` + ``` -6. **网页回落不见了！** +6. **The Web Page Fallback is missing!** - 没错，聪明的同学应该发现了，防御【主动探测】的 `nginx回落` 不见了！！！这是为什么呢？会不会不安全？别急，我们继续分析： + That's right, clever students must have noticed that the `nginx fallback` for defending against [Active Probing] is gone!!! Why is that? Is it insecure? Don't worry, let's continue analyzing: -### 5.2 后续监听处理的配置段摘抄如下： +### 5.2 The configuration segments for subsequent listening processing are as follows -1. 后续处理回落至 `1310` 端口的流量，按照下面的配置验证、处理： +1. Traffic falling back to port `1310` is verified and processed according to the configuration below: - ```json - { - "port": 1310, - "listen": "127.0.0.1", - "protocol": "trojan", - "settings": { - "clients": [ - { - "password": "", // 填写你的密码 - "level": 0, - "email": "love@example.com" - } - ], - "fallbacks": [ - { - "dest": 80 // 或者回落到其它也防探测的代理 - } - ] - }, - "streamSettings": { - "network": "tcp", - "security": "none", - "tcpSettings": { - "acceptProxyProtocol": true - } - } - } - ``` + ```json + { + "port": 1310, + "listen": "127.0.0.1", + "protocol": "trojan", + "settings": { + "clients": [ + { + "password": "", // Fill in your password + "level": 0, + "email": "love@example.com" + } + ], + "fallbacks": [ + { + "dest": 80 // Or fallback to another probe-resistant proxy + } + ] + }, + "streamSettings": { + "network": "tcp", + "security": "none", + "tcpSettings": { + "acceptProxyProtocol": true + } + } + } + ``` - 看，神奇的事情发生了， `trojan` 协议这里又出现了一个新的 `fallbacks`。前面已经说过，`xray` 中的 `trojan` 协议也具有完整的回落能力，所以，此时 `trojan` 协议可以再次做判断和回落（这也就是传说中的套娃回落了）： - - 所有 `trojan` 协议的流量，流入 `Xray` 中做后续处理 - - 所有非 `trojan` 协议的流量，转发至 `80` 端口，【主动探测】的防御，完成！ + Look, something magical happened. A new `fallbacks` section appeared here in the `trojan` protocol. As mentioned before, the `trojan` protocol in `xray` also has full fallback capabilities. So, at this point, the `trojan` protocol can perform judgment and fallback again (this is the legendary "Nested/Matryoshka" fallback): + - All `trojan` protocol traffic flows into `Xray` for subsequent processing. + - All non-`trojan` protocol traffic is forwarded to port `80`. The defense against [Active Probing] is complete! -2. 后续处理回落至 `1234` 端口的流量，仔细看！它其实是 `vless+ws`： +2. Traffic falling back to port `1234`. Look closely! It is actually `vless+ws`: - ```json - { - "port": 1234, - "listen": "127.0.0.1", - "protocol": "vless", - "settings": { - "clients": [ - { - "id": "", // 填写你的 UUID - "level": 0, - "email": "love@example.com" - } - ], - "decryption": "none" - }, - "streamSettings": { - "network": "ws", - "security": "none", - "wsSettings": { - "acceptProxyProtocol": true, // 提醒：若你用 Nginx/Caddy 等反代 WS，需要删掉这行 - "path": "/websocket" // 必须换成自定义的 PATH，需要和分流的一致 - } - } - } - ``` + ```json + { + "port": 1234, + "listen": "127.0.0.1", + "protocol": "vless", + "settings": { + "clients": [ + { + "id": "", // Fill in your UUID + "level": 0, + "email": "love@example.com" + } + ], + "decryption": "none" + }, + "streamSettings": { + "network": "ws", + "security": "none", + "wsSettings": { + "acceptProxyProtocol": true, // Reminder: Delete this line if using Nginx/Caddy to reverse proxy WS + "path": "/websocket" // Must be changed to custom PATH, matching the shunting path + } + } + } + ``` -3. 后续处理回落至 `2345` 端口的流量，仔细看！它其实是 `vmess直连`： +3. Traffic falling back to port `2345`. Look closely! It is actually `vmess direct connection`: - ```json - { - "port": 2345, - "listen": "127.0.0.1", - "protocol": "vmess", - "settings": { - "clients": [ - { - "id": "", // 填写你的 UUID - "level": 0, - "email": "love@example.com" - } - ] - }, - "streamSettings": { - "network": "tcp", - "security": "none", - "tcpSettings": { - "acceptProxyProtocol": true, - "header": { - "type": "http", - "request": { - "path": [ - "/vmesstcp" // 必须换成自定义的 PATH，需要和分流的一致 - ] - } - } - } - } - } - ``` + ```json + { + "port": 2345, + "listen": "127.0.0.1", + "protocol": "vmess", + "settings": { + "clients": [ + { + "id": "", // Fill in your UUID + "level": 0, + "email": "love@example.com" + } + ] + }, + "streamSettings": { + "network": "tcp", + "security": "none", + "tcpSettings": { + "acceptProxyProtocol": true, + "header": { + "type": "http", + "request": { + "path": [ + "/vmesstcp" // Must be changed to custom PATH, matching the shunting path + ] + } + } + } + } + } + ``` -4. 后续处理回落至 `3456` 端口的流量，再仔细看！它其实是是 `vmess+ws(+cdn)`。 +4. Traffic falling back to port `3456`. Look closely again! It is actually `vmess+ws(+cdn)`. - ::: warning 说明 - 你没看错，这就是 v2fly 曾经推荐的组合之一，并可完整支持 `CDN`。现已加入完美回落套餐哦！ - ::: + ::: warning Explanation + You read that right. This is one of the combinations previously recommended by v2fly, and it fully supports `CDN`. It is now included in the perfect fallback package! + ::: - ```json - { - "port": 3456, - "listen": "127.0.0.1", - "protocol": "vmess", - "settings": { - "clients": [ - { - "id": "", // 填写你的 UUID - "level": 0, - "email": "love@example.com" - } - ] - }, - "streamSettings": { - "network": "ws", - "security": "none", - "wsSettings": { - "acceptProxyProtocol": true, // 提醒：若你用 Nginx/Caddy 等反代 WS，需要删掉这行 - "path": "/vmessws" // 必须换成自定义的 PATH，需要和分流的一致 - } - } - } - ``` + ```json + { + "port": 3456, + "listen": "127.0.0.1", + "protocol": "vmess", + "settings": { + "clients": [ + { + "id": "", // Fill in your UUID + "level": 0, + "email": "love@example.com" + } + ] + }, + "streamSettings": { + "network": "ws", + "security": "none", + "wsSettings": { + "acceptProxyProtocol": true, // Reminder: Delete this line if using Nginx/Caddy to reverse proxy WS + "path": "/vmessws" // Must be changed to custom PATH, matching the shunting path + } + } + } + ``` -5. 至此，我们就能够完整的画出模板的回落路线了： +5. **With this, we can draw the complete fallback route for the template:** ```mermaid graph LR; - W443(外部 HTTP:443 请求) --> X443(Xray-inbound: 443) .- X1{入站判断} - X1 --> |协议 = VLESS 的流量| X2(Xray内部规则) - X2 --> XO(Xray Outbounds 出站) + W443(External HTTP:443 Request) --> X443(Xray-inbound: 443) .- X1{Inbound Judgment} + X1 --> |Protocol = VLESS Traffic| X2(Xray Internal Rules) + X2 --> XO(Xray Outbounds) - X1 --> |path = /websocket 的流量| X1234(Xray-inbound:1234) - X1 --> |path = /vmesstcp 的流量| X2345(Xray-inbound:2345) - X1 --> |path = /vmessws 的流量| X3456(Xray-inbound:3456) - X1 --> |其它所有流量| X1310(Xray-inbound:1310) + X1 --> |path = /websocket Traffic| X1234(Xray-inbound:1234) + X1 --> |path = /vmesstcp Traffic| X2345(Xray-inbound:2345) + X1 --> |path = /vmessws Traffic| X3456(Xray-inbound:3456) + X1 --> |All Other Traffic| X1310(Xray-inbound:1310) X1234 --> X2 X2345 --> X2 X3456 --> X2 - X1310 --> |协议 = trojan 的流量| X2 - X1310 --> |其他所有流量| N80(Nginx:80) + X1310 --> |Protocol = trojan Traffic| X2 + X1310 --> |All Other Traffic| N80(Nginx:80) N80:::nginxclass --> H(index.html) @@ -382,12 +382,12 @@ classDef nginxclass fill:#FFFFDE ``` -## 6. 结语 +## 6. Conclusion -至此，`Xray` 的【回落】功能就介绍完了。希望本文能够对你理解 `Xray` 的强大有所帮助。 +This concludes the introduction to `Xray`'s **[Fallback]** function. I hope this article helps you understand the power of `Xray`. -## 7. 附加题 +## 7. Bonus Question -我再无耻的留一个附加题：本文详解的 [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/) 模板？是否有可以优化的地方？ +I will shamelessly leave a bonus question: Is there any room for optimization in the [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/) template detailed in this article? -提示：HTTP 自动跳转 HTTPS +Hint: HTTP automatic redirection to HTTPS. diff --git a/docs/en/document/level-1/fallbacks-with-sni.md b/docs/en/document/level-1/fallbacks-with-sni.md index 6a4d3b6d..081ab5fb 100644 --- a/docs/en/document/level-1/fallbacks-with-sni.md +++ b/docs/en/document/level-1/fallbacks-with-sni.md @@ -1,77 +1,75 @@ --- -title: SNI fallback +title: SNI Fallback --- -# Implementing camouflage and domain-based routing through SNI fallback function +# Camouflage and Routing by Domain via SNI Fallback -VLESS is a lightweight protocol that, like Trojan, does not perform complex encryption and obfuscation on traffic. Instead, it is encrypted through the TLS protocol and mixed in with other HTTPS traffic, making it difficult to detect. In order to better disguise itself and respond to active probing, the fallback function appeared with VLESS at the same time. This tutorial will demonstrate how to use the fallback function of VLESS inbound protocol in Xray, combined with Nginx or Caddy, to achieve domain name-based traffic routing while ensuring complete disguise. +VLESS is a lightweight protocol. Like Trojan, it does not perform complex encryption and obfuscation on traffic. Instead, it "hides in plain sight" by using the TLS protocol for encryption, blending in with other HTTPS traffic to pass in and out of the firewall. To better camouflage against active probing, the **Fallbacks** feature was introduced alongside VLESS. This tutorial will demonstrate how to use the fallback function of the VLESS inbound protocol in Xray, combined with Nginx or Caddy, to achieve routing based on domain names while ensuring complete camouflage. -## Application Scenarios +## Scenarios -Due to XTLS, Xray needs to listen on port 443, which means that if there is a website running on the server, it cannot run or needs to run on another port, which is obviously unreasonable. There are three solutions to this problem: +Due to XTLS, Xray needs to listen on port 443. If a website was previously running on the server, it would no longer be able to run, or would have to run on a different port, which is obviously unreasonable. There are three solutions to this problem: -- Xray monitors other commonly used ports (such as 22, 3389, 8443). +- **Xray listens on other common ports (e.g., 22, 3389, 8443)** -This plan is the simplest, but not perfect enough. + This solution is the simplest, but not perfect. -- Nginx or HAProxy listens on port 443, uses SNI for L4 load balancing, and achieves port multiplexing through reverse proxy. +- **Nginx or HAProxy listens on port 443 and uses SNI routing for L4 reverse proxying to achieve port reuse** -This plan is relatively complicated and requires some understanding of using Nginx or HAProxy. We will not explain it in too much detail here. + This solution is relatively complex and requires a certain understanding of Nginx or HAProxy, so it will not be explained in detail here. -- Xray listens on port 443, and uses Fallbacks feature to split website traffic based on SNI and fallbacks it to Nginx or Caddy. +- **Xray listens on port 443 and uses the Fallbacks function for SNI routing to fallback website traffic to Nginx or Caddy** -This plan has a moderate level of difficulty and is the scheme that this tutorial will demonstrate next. + This solution is of moderate difficulty and is the method this tutorial intends to demonstrate. ## Introduction to SNI -Server Name Indication (SNI) is an extension protocol of TLS. Friends who are familiar with reverse proxies know that the following configuration is required if you want to proxy traffic to the correct content through a domain name: +Server Name Indication (**SNI**) is an extension of the TLS protocol. Friends familiar with reverse proxies know that to proxy traffic to the correct content based on the domain name, the following configuration is needed: ```nginx proxy_set_header Host hostname; ``` -(Note: "hostname" should be replaced with the actual hostname.) +This line sets the HTTP Header named "Host" to a specific hostname. Why do this? Generally, one server corresponds to one IP but runs multiple websites. Visitors query the IP via the domain name to access the server. The question arises: how does the server determine which website the visitor wants to access? This requires "Name-based Virtual Hosting." -This sentence sets the HTTP Header named "Host" to a certain hostname. Why do we need to do this? Generally, one server corresponds to one IP address, but it runs multiple websites. Visitors access the server by querying the IP address via domain name to visit the website. Then the question arises, how to determine which website the visitor wants to access? This requires "name-based virtual hosting". +When a Web server receives a request, it looks at the requested Host header to serve the correct website. However, when the HTTP protocol is encrypted by the TLS protocol, this simple method becomes impossible. Because the TLS handshake happens before the server sees any HTTP headers, the server cannot use the information in the HTTP Host header to decide which certificate to present, nor can it determine the visitor's target. -When a Web server receives a request, it looks at the host header to direct the visitor to the correct website. However, this simple method cannot be used when HTTP protocol is encrypted by TLS protocol. This is because the TLS handshake occurs before the server sees any HTTP headers, so the server cannot use the information in the HTTP host header to determine which certificate to present or which destination the visitor wants to access. +The principle of SNI is simple: it solves this problem by having the client send the hostname as part of the TLS negotiation. Therefore, when using Nginx for reverse proxying HTTPS, you need to add `proxy_ssl_server_name on;` to the configuration. At this point, Nginx will send SNI information to the proxied server, solving the issue of virtual hosts failing under HTTPS. Additionally, when using SNI, the website can be accessed correctly even without specifying the Host header. -The principle of SNI is also very simple. It solves the problem by allowing the client to send the hostname as part of the TLS negotiation. Therefore, when using Nginx to reverse proxy the HTTPS protocol, you need to add `proxy_ssl_server_name on;` to the configuration. At this time, Nginx will send SNI information to the proxied server, solving the problem of virtual host failure under the HTTPS protocol. In addition, when using SNI, even if the host header is not specified, the website can be accessed correctly. +## The Logic -## Idea + - +After receiving traffic on port 443, Xray decrypts the TLS. If the first packet length is < 18, the protocol version is invalid, or authentication fails, the traffic is forwarded to the address specified in `dest` by matching `name`, `path`, and `alpn`. -After receiving traffic from port 443, Xray will decrypt the TLS and forward the traffic that has a first packet length < 18, invalid protocol version, or failed authentication through matching name, path, and alpn to the address specified by dest. - -## Adding DNS Records +## Add DNS Records  -Please modify the domain name and IP according to the actual situation. +Please modify the domain name and IP according to your actual situation. -## Applying for TLS Certificate +## Apply for TLS Certificates -As it is necessary to route traffic to different domain name prefixes, but a wildcard certificate is only valid between two dots (for example, applying for `*.example.com`, the certificate cannot be used for `example.com` and `*.*.example.com`), it is necessary to apply for a [SAN](https://en.wikipedia.org/wiki/Subject_Alternative_Name) (Subject Alternative Name) wildcard certificate. According to the information on the Let's Encrypt official website, applying for a wildcard certificate requires DNS-01 verification. Here, we demonstrate how to apply for a free TLS certificate from Let's Encrypt using [acme.sh](https://acme.sh) for a domain with NS records hosted on Cloudflare. For the application method using other domain name hosting providers, please refer to [dnsapi · acmesh-official/acme.sh Wiki](https://github.com/acmesh-official/acme.sh/wiki/dnsapi). +Since we need to route traffic for domains with different prefixes, and a wildcard certificate is limited to the scope between two dots (e.g., applying for `*.example.com` covers `example.com` but not `*.*.example.com`), we need to apply for a [SAN](https://en.wikipedia.org/wiki/Subject_Alternative_Name) wildcard certificate. According to Let's Encrypt's official site[^1], applying for a wildcard certificate requires DNS-01 validation. Here, we demonstrate using [acme.sh](https://acme.sh) to apply for a free Let's Encrypt TLS certificate for a domain with NS records managed by Cloudflare. For methods using other domain registrars, please read [dnsapi · acmesh-official/acme.sh Wiki](https://github.com/acmesh-official/acme.sh/wiki/dnsapi). -First, you need to go to the [Cloudflare dashboard](https://dash.cloudflare.com/profile/api-tokens) to create an API token. The parameters are as follows: +First, go to the [Cloudflare Dashboard](https://dash.cloudflare.com/profile/api-tokens) to create an API Token. The parameters are as follows: - + -The permission part is crucial, while other parts are optional. +The permissions section is crucial; other sections can be arbitrary. -After creating, you will receive a mysterious string of characters. Please keep it safe in a secure and non-losing place, as it will not be displayed again. This string of characters is the `CF_Token` that will be used soon. +After creation, you will get a mysterious string. Please keep it safe in a secure place where it won't be lost, as it will not be shown again. This string is the `CF_Token` used below. ::: tip Note -The following operations need to be performed under the root user. Using sudo will result in errors. +The following operations need to be performed as the root user; using sudo may cause errors. ::: ```bash -curl https://get.acme.sh | sh # Install acme.sh +curl [https://get.acme.sh](https://get.acme.sh) | sh # Install acme.sh export CF_Token="sdfsdfsdfljlbjkljlkjsdfoiwje" # Set API Token variable -acme.sh --issue -d example.com -d *.example.com --dns dns_cf # Apply for a certificate using DNS-01 validation method -mkdir /etc/ssl/xray # Create a directory to store the certificate -acme.sh --install-cert -d example.com --fullchain-file /etc/ssl/xray/cert.pem --key-file /etc/ssl/xray/privkey.key --reloadcmd "chown nobody:nogroup -R /etc/ssl/xray && systemctl restart xray" # Install the certificate to the specified directory and set the effective command for automatic renewal +acme.sh --issue -d example.com -d *.example.com --dns dns_cf # Apply for certificate using DNS-01 validation +mkdir /etc/ssl/xray # Create directory for certificates +acme.sh --install-cert -d example.com --fullchain-file /etc/ssl/xray/cert.pem --key-file /etc/ssl/xray/privkey.key --reloadcmd "chown nobody:nogroup -R /etc/ssl/xray && systemctl restart xray" # Install certificate to the specified directory and set the command to run after auto-renewal ``` ## Xray Configuration @@ -164,79 +162,65 @@ acme.sh --install-cert -d example.com --fullchain-file /etc/ssl/xray/cert.pem -- } ``` -The above configuration is for Nginx. Here are some details that need to be noted. +The above configuration is for Nginx. Here are some details to note: -- About Proxy Protocol +- **About Proxy Protocol** -Proxy Protocol is a protocol developed by HaProxy to solve the problem of easily losing client information during proxying. It is often used for chain proxying and reverse proxying. The traditional approach to handling this problem is often complex and has many limitations, while Proxy Protocol simply attaches the original connection quadruple information packet to the transmitted data, solving this problem in a very simple way. + Proxy Protocol is a protocol developed by HAProxy designed to solve the problem of losing client information during proxying. It is often used in chained proxies and reverse proxies. Traditional handling methods are often complex and restrictive, while Proxy Protocol simply attaches the original connection 4-tuple information to the data packet during transmission, solving this problem. -Everything has its advantages and disadvantages, and the same goes for the Proxy Protocol. + Everything has its pros and cons, and Proxy Protocol is no exception. + - If sent, it must be received; and vice versa. + - The same port cannot be compatible with both connections carrying Proxy Protocol data and those without (e.g., Nginx virtual hosts (server) on the same port essentially violate this).[^2][^3] -- If there is sending, there must be receiving, and vice versa. -- The same port cannot be compatible with connections that have Proxy Protocol data and those that don't have data (e.g., different virtual hosts (servers) on the same port in Nginx, which is essentially the previous point). [^2][^3] + If you encounter exceptions, please consider whether the configuration meets the above conditions. -Please consider whether the configuration meets the above conditions when encountering exceptions. + Here, we use Proxy Protocol to let the fallback target acquire the client's real IP. -Here, we use the Proxy Protocol to allow the fallback target to obtain the real IP address of the client. + Additionally, when `"acceptProxyProtocol": true` exists in an Xray inbound configuration, ReadV will be disabled. -In addition, when the `"acceptProxyProtocol": true` exists in a certain inbound configuration of Xray, ReadV will be invalidated. +- **About HTTP/2** -- Regarding HTTP/2 + First, the order of `inbounds.streamSettings.tlsSettings.alpn` matters. `h2` should be placed before `http/1.1` to prioritize HTTP/2 while ensuring compatibility; reversing them will cause HTTP/2 to negotiate as HTTP/1.1, making it an ineffective configuration. -First, `inbounds.streamSettings.tlsSettings.alpn` has an order. `h2` should be placed before `http/1.1` to prioritize the use of HTTP/2 while ensuring compatibility. Placing them in reverse order will cause HTTP/2 to be negotiated as HTTP/1.1, resulting in an invalid configuration. + In the above configuration, each fallback rule to Nginx is split into two. This is because `h2` is an HTTP/2 connection with mandatory TLS encryption, which is beneficial for data security over the internet but unnecessary within the server; whereas `h2c` is an unencrypted HTTP/2 connection, suitable for this environment. However, Nginx cannot listen for HTTP/1.1 and h2c on the same port simultaneously. To solve this, the `alpn` item (inside `fallbacks`, not `tlsSettings`) must be specified in the fallback to attempt to match the TLS ALPN negotiation result. -In the above configuration, each `fallback` configuration that falls back to Nginx needs to be divided into two. This is because h2 is an HTTP/2 connection that requires TLS encryption, which is beneficial for the security of data transmission over the Internet, but is unnecessary within the server. On the other hand, h2c is a non-encrypted HTTP/2 connection that is suitable for this environment. However, Nginx cannot listen for HTTP/1.1 and h2c on the same port at the same time. To solve this problem, the `alpn` option (in `fallbacks` rather than `tlsSettings`) needs to be specified in the fallback to try to match the TLS ALPN negotiation result. + It is recommended to use only two types of values for the `alpn` item as needed:[^4] + - Omitted + - `"h2"` -Suggestion: Use only two types of fillings for the `alpn` item as needed: [^4] + If you use **Caddy**, you don't need to be this complicated because it **can** listen to HTTP/1.1 and h2c on the same port simultaneously. The configuration changes are as follows: -- Omitted -- `"h2"` - -If you use Caddy, you don't need to be so complicated, because **it can** listen to HTTP/1.1 and h2c on the same port at the same time. The configuration changes are as follows: - -```json -{ - "fallbacks": [ - { - "name": "example.com", - "path": "/vmessws", - "dest": 5000, - "xver": 1 - }, - { - "dest": 5001, - "xver": 1 - }, - { - "name": "blog.example.com", - "dest": 5002, - "xver": 1 - } - ] -} -``` - -(Note: This is a JSON code block. It describes fallback configurations for a service.) + ```json + { + "fallbacks": [ + { + "name": "example.com", + "path": "/vmessws", + "dest": 5000, + "xver": 1 + }, + { + "dest": 5001, + "xver": 1 + }, + { + "name": "blog.example.com", + "dest": 5002, + "xver": 1 + } + ] + } + ``` ## Nginx Configuration -Nginx will be installed through official sources. - -This is a set of Bash commands to install Nginx on Ubuntu. - -The first command installs the necessary packages for the installation process. - -The second command adds the Nginx repository to the list of sources that Ubuntu uses to find software packages. - -The third command downloads the Nginx signing key and adds it to the system's keyring, which verifies the authenticity of the package. - -The fourth command updates the package list with the newly added Nginx repository. +Nginx will be installed via the official repository. ```bash sudo apt install curl gnupg2 ca-certificates lsb-release -echo "deb [arch=amd64] http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" \ +echo "deb [arch=amd64] [http://nginx.org/packages/ubuntu](http://nginx.org/packages/ubuntu) `lsb_release -cs` nginx" \ | sudo tee /etc/apt/sources.list.d/nginx.list -curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - +curl -fsSL [https://nginx.org/keys/nginx_signing.key](https://nginx.org/keys/nginx_signing.key) | sudo apt-key add - sudo apt update sudo apt install nginx ``` @@ -275,37 +259,30 @@ server { ## Caddy Configuration -Please refer to [Install — Caddy Documentation](https://caddyserver.com/docs/install) for installing Caddy. +To install Caddy, please refer to [Install — Caddy Documentation](https://caddyserver.com/docs/install). -To enable Caddy to obtain the real IP address of visitors, it is necessary to compile Caddy with the Proxy Protocol module. It is recommended to compile it directly on the Caddy website. +To enable Caddy to obtain the visitor's real IP, you need to compile Caddy with the Proxy Protocol module. It is recommended to compile online directly on the Caddy website. ```bash -sudo curl -o /usr/bin/caddy "https://caddyserver.com/api/download?os=linux&arch=amd64&p=github.com%2Fmastercactapus%2Fcaddy2-proxyprotocol&idempotency=79074247675458" - +sudo curl -o /usr/bin/caddy "[https://caddyserver.com/api/download?os=linux&arch=amd64&p=github.com%2Fmastercactapus%2Fcaddy2-proxyprotocol&idempotency=79074247675458](https://caddyserver.com/api/download?os=linux&arch=amd64&p=github.com%2Fmastercactapus%2Fcaddy2-proxyprotocol&idempotency=79074247675458)" sudo chmod +x /usr/bin/caddy ``` -This is a bash script that downloads the Caddy web server and sets the necessary permissions to run it on a Linux system. - Just replace it directly. ::: tip -It is recommended to install Caddy through the official website documentation first, and then replace the binary file. This way, there is no need to manually set the process management. +It is recommended to install Caddy via the official documentation first, and then replace the binary file. This way, you don't need to manually configure the daemon process. ::: Edit `/etc/caddy/Caddyfile`: -This is a Caddyfile, which is a configuration file used by the Caddy web server. - -In this specific configuration, there are two servers defined: one listening on `127.0.0.1:5001` and another on `127.0.0.1:5002`. Both servers have a `listener_wrapper` defined for `proxy_protocol`, which is a protocol used for passing client connection information through a proxy or load balancer. Additionally, both servers have the `allow_h2c` option enabled, which allows clients to connect using HTTP/2 cleartext (h2c) protocol. - ```Caddyfile { servers 127.0.0.1:5001 { listener_wrappers { proxy_protocol } - protocol { + protocol { allow_h2c } } @@ -313,7 +290,7 @@ In this specific configuration, there are two servers defined: one listening on listener_wrappers { proxy_protocol } - protocol { + protocol { allow_h2c } } @@ -338,17 +315,17 @@ http://blog.example.com:5002 { } ``` -## Reference +## References -1. [Server Name Indication - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/Server_Name_Indication) +1. [Server Name Indication - Wikipedia](https://en.wikipedia.org/wiki/Server_Name_Indication) 2. [Home · acmesh-official/acme.sh Wiki](https://github.com/acmesh-official/acme.sh/wiki) -3. [HTTP/2 - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/HTTP/2) +3. [HTTP/2 - Wikipedia](https://en.wikipedia.org/wiki/HTTP/2) -## Quotation +## Citations -[^1]: [Frequently Asked Questions - Let's Encrypt - Free SSL/TLS Certificates](https://letsencrypt.org/docs/faq/) +[^1]: [FAQ - Let's Encrypt](https://letsencrypt.org/docs/faq/) [^2]: [Proxy Protocol - HAProxy Technologies](https://www.haproxy.com/blog/haproxy/proxy-protocol/) -[^3]: [Introduction to Proxy Protocol and Nginx Configuration - Jianshu](https://www.jianshu.com/p/cc8d592582c9) +[^3]: [Proxy protocol introduction and nginx configuration (Chinese)](https://www.jianshu.com/p/cc8d592582c9) [^4]: [v2fly-github-io/vless.md at master · rprx/v2fly-github-io](https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md) diff --git a/docs/en/document/level-1/index.md b/docs/en/document/level-1/index.md index ded12ebd..3d4b8bb5 100644 --- a/docs/en/document/level-1/index.md +++ b/docs/en/document/level-1/index.md @@ -1,13 +1,15 @@ -# Beginner's Tips +# Beginner Skills -**This chapter is an introductory level guide on using Xray, mainly sharing the principles of some commonly used functional modules in Xray.** +**This section shares beginner-level insights on using Xray, focusing primarily on explaining the principles behind some of Xray's commonly used functional modules.** -[Analysis of Fallbacks Function](./fallbacks-lv1.md) +[Analysis of the Fallbacks Feature](./fallbacks-lv1.md) -[Analysis of Routing Function (Part 1)](./routing-lv1-part1.md) +[Analysis of the Routing Feature (Part 1)](./routing-lv1-part1.md) -[Analysis of Routing Function (Part 2)](./routing-lv1-part2.md) +[Analysis of the Routing Feature (Part 2)](./routing-lv1-part2.md) -[Analysis of Xray's Working Mode](./work.md) +[Analysis of Xray's Working Modes](./work.md) -[Fallbacks with SNI for Disguising and Domain-based Routing](./fallbacks-with-sni.md) +[Camouflage and Routing by Domain via SNI Fallback](./fallbacks-with-sni.md) + +[Accurate Traffic Splitting (Domestic/Foreign) via DNS Module](./routing-with-dns.md) diff --git a/docs/en/document/level-1/routing-lv1-part1.md b/docs/en/document/level-1/routing-lv1-part1.md index a04edba6..97205766 100644 --- a/docs/en/document/level-1/routing-lv1-part1.md +++ b/docs/en/document/level-1/routing-lv1-part1.md @@ -1,34 +1,34 @@ -# 路由 (routing) 功能简析（上） +# A Brief Analysis of Routing Functionality (Part 1) -如果说 Xray 的【强大】主要体现在它极致的速度和广泛的兼容性。那么 Xray 的【灵活】，则主要应该归功于它巧妙的【路由】功能。本文就稍微说明一下这个功能的逻辑以及使用方式。 +If Xray's [Power] is mainly reflected in its extreme speed and broad compatibility, then Xray's [Flexibility] should be mainly attributed to its ingenious [Routing] feature. This article will briefly explain the logic and usage of this function. -## 1. 初识【路由】三兄弟 +## 1. Meeting the "Routing" Trio -要理解路由，就要理解完整的路由功能需要有三兄弟来合力完成：1. **入站**；2. **路由**；3. **出站**。 +To understand routing, one must understand that the complete routing function requires three "brothers" working together to complete: 1. **Inbound**; 2. **Routing**; 3. **Outbound**. - + -三兄弟桃园结义，不求同年同月同日生，但求同年同月同日死。 +The three brothers took the Oath of the Peach Garden: not asking to be born on the same year, month, and day, but asking to die on the same year, month, and day. -所以谨记：任何一个元素错误，就可能导致路由功能无法正常工作。 +So bear in mind: An error in any single element may cause the routing function to fail. -因为路由的灵活性非常高，只看技术文档很容易把自己绕晕，所以本文我们用几个具体的示例来逐层讲解。 +Because the flexibility of routing is very high, just reading the technical documentation can easily make you dizzy. Therefore, this article will use a few specific examples to explain it layer by layer. -::: warning 啰嗦君 -路由功能实在过于灵活，所以本文的示例，都是为了讲解对应的概念，实际使用时请根据自己的需求进行调整。 +::: warning Verbose Note +The routing function is indeed overly flexible, so the examples in this article are meant to explain the corresponding concepts. Please adjust them according to your own needs in actual use. ::: -## 2. 基本功： “兄弟一条心” +## 2. Basic Skills: "Brothers United" -下图的示例，就是在客户端的 `Xray` 入站接收 APP 数据、在路由 100%转发给出站，并从出站流向 VPS。 +The example in the chart below shows the client's `Xray` **Inbound** receiving APP data, the **Routing** forwarding it 100% to the **Outbound**, and the data flowing from the Outbound to the VPS. ```mermaid graph LR; - S(APP数据) .-> I[入站] + S(APP Data) .-> I[Inbound] subgraph Xray - I --> R[路由] --> O[出站] + I --> R[Routing] --> O[Outbound] end O .-> V(VPS) @@ -41,15 +41,15 @@ ``` -下面我们来逐个分析： +Let's analyze them one by one: -### 2.1 入站 +### 2.1 Inbound ::: tip -**入站：** 就是流量如何流入 `Xray` +**Inbound:** How traffic flows into `Xray`. ::: -下面的入站配置示例，用大白话说就是：数据按照 `socks` 协议，通过 `10808` 端口，从本机 `127.0.0.1` 流入`Xray`。同时，`Xray` 将这个入站用 `[tag]` 命名为 `inbound-10808`。 +The following inbound configuration example, in plain English, means: Data flows into `Xray` from the local machine `127.0.0.1` via port `10808` using the `socks` protocol. At the same time, `Xray` names this inbound using the `[tag]` `inbound-10808`. ```json { @@ -67,13 +67,13 @@ } ``` -**2.2 出站** +**2.2 Outbound** ::: tip -**出站：** 就是流量如何流出 `Xray` +**Outbound:** How traffic flows out of `Xray`. ::: -下面的出站配置示例，用大白话说就是：数据按照 `VLESS` 协议，以 `tcp + xtls` 的方式、及其他相关设置，把流量发送给对应的 VPS。同时，`Xray` 将这个出站用 `[tag]` 命名为 `proxy-out-vless`： +The following outbound configuration example, in plain English, means: Data is sent to the corresponding VPS using the `VLESS` protocol, via `tcp + xtls`, and other related settings. At the same time, `Xray` names this outbound using the `[tag]` `proxy-out-vless`: ```json { @@ -111,13 +111,13 @@ } ``` -### 2.3 路由 +### 2.3 Routing ::: tip -**路由：** 就是把【入站】和【出站】之间的通道，用某种【条件】串联起来 +**Routing:** Connecting the path between [Inbound] and [Outbound] using certain [Conditions]. ::: -下面的路由配置示例，用大白话说就是：把所有通过 `[tag]="inbound-10808"` 入站流入 `Xray` 的流量，`100%` 全部流转导入 `[tag]="proxy-out-vless"` 的出站，没有任何分流或其他操作。 +The following routing configuration example, in plain English, means: 100% of the traffic flowing into `Xray` through `[tag]="inbound-10808"` is forwarded to the outbound with `[tag]="proxy-out-vless"`, without any splitting or other operations. ```json { @@ -133,46 +133,46 @@ } ``` -至此，我们最开始设计的极简规则【客户端的 `Xray` 入站接收 APP 数据、在路由 100%转发给出站，并从出站流向 VPS】已经完成。 +At this point, our initially designed minimalist rule [Client `Xray` Inbound receives APP data, Routing forwards 100% to Outbound, and flows from Outbound to VPS] is complete. -### 2.4 路由配置项解析之一：流量筛选的依据 +### 2.4 Analysis of Routing Configuration Items Part 1: Basis for Traffic Filtering -注意观察路由配置，我们可以看到几个新名词： +Observing the routing configuration carefully, we can see several new terms: 1. "domainStrategy": "AsIs" 2. “rules” 3. "inboundTag": ["inbound-10808"] 4. "outboundTag": "proxy-out-vless" -其中 `domainStrategy` 我们暂且按下不表，先简单说明后面几个： +We will put aside `domainStrategy` for now and briefly explain the latter ones: -| 配置名称 | 配置值 | 配置说明 | -| :-------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------- | -| `“rules”` | | 它的内层就是【路由规则】的明细设置 | -| `"inboundTag"` | `["inbound-10808"]` | 筛选流量的 **【依据】** 是【入站 Tag】，具体 **【条件】** 现在只有一个：【入站来源是 `inbound-10808`】 | -| `"outboundTag"` | `"proxy-out-vless"` | 当上面的筛选条件成立时（即入站`[tag]="inbound-10808"`时 ），`Xray` 会将流量导入 `[tag]="proxy-out-vless"` 的出站 | +| Config Name | Config Value | Config Explanation | +| :---------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `“rules”` | | Its inner layer contains the detailed settings of [Routing Rules]. | +| `"inboundTag"` | `["inbound-10808"]` | The **[Basis]** for filtering traffic is the [Inbound Tag]. The specific **[Condition]** right now is only one: [Inbound source is `inbound-10808`]. | +| `"outboundTag"` | `"proxy-out-vless"` | When the above filtering condition is met (i.e., when inbound `[tag]="inbound-10808"`), `Xray` will import the traffic into the outbound with `[tag]="proxy-out-vless"`. | -本例中，我们只有一个入站，它的`"inboundTag" = "inbound-10808"` 。我们也只有一个出站，它的 `[tag]="proxy-out-vless"`。所以根据上面这个路由规则，从唯一入站端口 `10808` 流入`Xray`的流量，`100%` 符合筛选条件、会被路由模块选中，然后转发给唯一的出站。 +In this example, we have only one inbound, and its `"inboundTag" = "inbound-10808"`. We also have only one outbound, with `[tag]="proxy-out-vless"`. Therefore, according to this routing rule, traffic flowing into `Xray` from the sole inbound port `10808` matches the filtering condition `100%`, is selected by the routing module, and is then forwarded to the sole outbound. -至此，**入站**、**路由**、**出站** 三兄弟就已经可以携手工作了。当然，现在这个 100%转发的工作并没有什么特别的意义。那么接下来，我们就看看这种分工合作的机制可以带来什么好处。 +Thus, the trio of **Inbound**, **Routing**, and **Outbound** can now work hand in hand. Of course, this 100% forwarding task doesn't have any special significance yet. Next, let's see what benefits this cooperative mechanism can bring. -## 3. 小试牛刀： “三分天下” 之 “域名分流” +## 3. First Try: "Three Kingdoms" of "Domain Routing" > `[geosite.dat]` ```mermaid graph LR; - S(APP数据) .-> I[入站] + S(APP Data) .-> I[Inbound] subgraph Xray - I --> R[路由] -- "geosite:category-ads-all" --> O1[block] - R[路由] -- "geosite:cn" --> O2[direct] - R[路由] -- "geosite:geolocation-!cn" --> O3[proxy] + I --> R[Routing] -- "geosite:category-ads-all" --> O1[block] + R[Routing] -- "geosite:cn" --> O2[direct] + R[Routing] -- "geosite:geolocation-!cn" --> O3[proxy] end - O2 .-> D(国内服务器) + O2 .-> D(Domestic Server) O3 .-> V(VPS) O1:::redclass @@ -186,23 +186,23 @@ ``` -这个配置逻辑，其实就是最简单、最常用的（《小小白白话文》中也在用的）路由配置三件套： +This configuration logic is actually the simplest and most commonly used routing configuration set (also used in "Little White's Plain English Guide"): -1. 广告流量屏蔽 `[block]` -2. 国内流量直连 `[direct]` -3. 国外流量转发 VPS `[proxy]` +1. Block ad traffic `[block]` +2. Direct connection for domestic traffic `[direct]` +3. Forward foreign traffic to VPS `[proxy]` -::: warning 注意 -小小白白话文中的直连配置是包括【国内域名】、【国内 IP】、【本机内部 IP】的。这里先讲解【国内域名】。 +::: warning Note +The direct connection configuration in "Little White's Plain English Guide" includes [Domestic Domains], [Domestic IPs], and [Local Internal IPs]. Here we explain [Domestic Domains] first. ::: -### 3.1 入站 +### 3.1 Inbound -保持上例的 `inbound-10808` 不变。 +Keep `inbound-10808` from the previous example unchanged. -### 3.2 出站 +### 3.2 Outbound -在上例的基础上，我们已经有了 `[proxy]` 的出站 `"proxy-out-vless"`，所以它保持不变。显而易见，我们需要加入两个新的出站方式：`[block]` 和 `[direct]`，如下： +Based on the previous example, we already have the `[proxy]` outbound `"proxy-out-vless"`, so it remains unchanged. Obviously, we need to add two new outbound methods: `[block]` and `[direct]`, as follows: ```json { @@ -223,15 +223,15 @@ } ``` -上面的配置用大白话翻译如下： +The above configuration translated into plain English: -1. 上例中的 `[proxy-out-vless]` 出站配置保持不变 -2. 加入 **`blackhole` 黑洞协议**，通过这个协议出站的流量，其实都被发送到了 `Xray` 内部的黑洞里，再也无法逃脱，于是效果就是屏蔽 `[block]` -3. 加入 **`freedom` 自由协议**，通过这个协议出站的流量，是自由的离开`Xray`去寻找原定的服务器，就像从没有来过，于是效果就是直连 `[direct]` （我这里起名叫做 `[direct-out]` 是为了强调它是一个出站） +1. The `[proxy-out-vless]` outbound configuration from the previous example remains unchanged. +2. Add **`blackhole` protocol**. Traffic exiting through this protocol is actually sent into a black hole inside `Xray` and can never escape, thus achieving the effect of blocking `[block]`. +3. Add **`freedom` protocol**. Traffic exiting through this protocol leaves `Xray` freely to find the intended server as if it had never been here, thus achieving the effect of direct connection `[direct]` (I named it `[direct-out]` here to emphasize it is an outbound). -### 3.3 路由 +### 3.3 Routing -接下来就是见证奇迹的时刻了，我们可以用【路由】的配置把这些连接起来！ +Now is the moment to witness the miracle; we can use the [Routing] configuration to connect these! ```json { @@ -255,87 +255,86 @@ } ``` -为了理解这个配置文件，我们要稍微解释一下这里出现的几个新配置项： +To understand this configuration file, we need to slightly explain the new configuration items appearing here: - `"domain": ["geosite:category-ads-all"]` - `"domain": ["geosite:cn"]` - `"domain": ["geosite:geolocation-!cn"]` -### 3.4 简析域名文件： `geosite.dat` +### 3.4 Brief Analysis of Domain File: `geosite.dat` -其实，聪明的你大概可以通过这些配置项的名称猜出来个大概： +Actually, the clever you can probably guess the gist from the names of these configuration items: -- `"domain"`：就是这次筛选流量的 **【依据】** 是 **【域名】** （而不再是入站 tag） -- `"geosite"`：就是 `Xray` 会去 `geosite.dat` 文件中寻找 **【符合条件的域名】** -- `"category-ads-all"`：就是该文件中的 **【所有广告类域名】** -- `"cn"`：就是该文件中的 **【中国域名】** -- `"geolocation-!cn"`：就是该文件中的 **【非中国域名】** +- `"domain"`: This means the **[Basis]** for filtering traffic this time is **[Domain Name]** (no longer inbound tag). +- `"geosite"`: This means `Xray` will look for **[Domains matching the condition]** in the `geosite.dat` file. +- `"category-ads-all"`: This means **[All advertising domains]** in that file. +- `"cn"`: This means **[Chinese domains]** in that file. +- `"geolocation-!cn"`: This means **[Non-Chinese domains]** in that file. -结合这些说明，3.3 中的配置用大白话翻译就是： +Combining these explanations, the configuration in 3.3 translates to plain English as: -1. APP 试图访问国外域名 `"domain": "geolocation-!cn"` 的流量，通过 `[proxy-out-vless]` 出站，转发至 VPS -2. APP 试图访问国外域名广告域名 `"domain": "geosite:category-ads-all"` 的流量，通过 `[block]` 出站，转发至黑洞进行屏蔽 -3. APP 试图访问国内域名 `"domain": "geosite:cn"` 的流量，通过 `[direct-out]` 出站，自由离开完成直连 +1. Traffic where the APP attempts to access foreign domains `"domain": "geolocation-!cn"` goes through `[proxy-out-vless]` outbound and is forwarded to the VPS. +2. Traffic where the APP attempts to access foreign advertising domains `"domain": "geosite:category-ads-all"` goes through `[block]` outbound and is forwarded to the black hole for blocking. +3. Traffic where the APP attempts to access domestic domains `"domain": "geosite:cn"` goes through `[direct-out]` outbound and leaves freely to complete a direct connection. -这时，才让【路由功能】的好处稍微得到了一些展现。 +At this point, the benefits of the [Routing Function] are finally somewhat revealed. -### 3.5 所以 `geosite.dat` 到底是什么？不是有个 `GFWList` 吗？ +### 3.5 So what exactly is `geosite.dat`? Wasn't there a `GFWList`? -你想，这世界上的域名何止千万，如果我们每写一个基于【域名】匹配的路由规则，都要自己收集、手动输入域名，那效率将会何其低下！ +Think about it, there are tens of millions of domains in the world. If we had to collect and manually input domains every time we wrote a routing rule based on [Domain] matching, how inefficient that would be! -而如果所有的域名都只有一个种类，`[direct], [proxy], [block]` 只能三选其一，那又是多么的不方便！ +And if all domains were just one category, and we could only choose one out of `[direct], [proxy], [block]`, how inconvenient that would be! -就如关羽需要他的青龙偃月刀，`geosite.dat` 文件便作为【路由功能】驱使的神兵利器横空出世了，它致力于为用户提供成熟完善的【域名分类表】。让用户可以简单的通过 `geosite:xxx` 这种格式方便的调用任何子类，定制符合自身需求的路由规则。 +Just as Guan Yu needed his Green Dragon Crescent Blade, the `geosite.dat` file was born as a divine weapon driven by the [Routing Function]. It is dedicated to providing users with a mature and complete [Domain Classification Table]. It allows users to easily call any subclass via the `geosite:xxx` format to customize routing rules that meet their own needs. -这种模块化结构提供的灵活性，其实远超传统的一揽子防火墙域名列表 [`GFWList`](https://github.com/gfwlist/gfwlist)。为什么这么说呢？比如，你可以指定苹果的域名 `geosite:apple` 和 icloud 相关域名 `geosite:icloud` 通过代理 `[proxy]`，但是苹果的软件域名 `geosite:apple-update` 保持直连 `[direct]` 来保持最大下载速度。 +The flexibility provided by this modular structure actually far exceeds the traditional blanket firewall domain list [`GFWList`](https://github.com/gfwlist/gfwlist). Why do I say that? For example, you can specify Apple's domains `geosite:apple` and iCloud related domains `geosite:icloud` to go through the proxy `[proxy]`, but keep Apple's software update domains `geosite:apple-update` on direct connection `[direct]` to maintain maximum download speed. ::: warning -**注意：** 现在，`geosite.dat` 文件其实有多种选择： +**Note:** Nowadays, there are actually multiple choices for the `geosite.dat` file: -最初，从 `Victoria Raymond` 主力维护 `Project V` 项目时期，便提供了最初的配套项目：[`domain-list-community`](https://github.com/v2ray/domain-list-community)，用来收集、沉淀、分类各种常用的域名类型； +Initially, during the time when `Victoria Raymond` was the main maintainer of the `Project V` project, the original companion project was provided: [`domain-list-community`](https://github.com/v2ray/domain-list-community), used to collect, precipitate, and classify various commonly used domain types; -之后，随着 V 姐突然消失导致 `Project V` 的原项目开发陷入停滞，`v2fly` 社区维护并持续更新了社区版本的 [`domain-list-community`](https://github.com/v2fly/domain-list-community)； +Later, as V disappeared and the development of the original `Project V` stalled, the `v2fly` community maintained and continued to update the community version of [`domain-list-community`](https://github.com/v2fly/domain-list-community); -同时，Loyalsoldier 维护了其个人修改增强的路由规则文件 [v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat)，提供了诸多不同的选择和分类逻辑； +Meanwhile, Loyalsoldier maintains his personally modified and enhanced routing rule file [v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat), offering many different choices and classification logic; -另外，`Project X` 也计划于未来定制维护更适合 `Xray` 使用的路由规则文件 [Xray-rules-dat](https://github.com/XTLS/Xray-rules-dat)。~~(你们看，文件夹都建好了，所以快了快了)~~ +In addition, `Project X` also plans to customize and maintain a routing rule file better suited for `Xray` in the future: [Xray-rules-dat](https://github.com/XTLS/Xray-rules-dat). ~~(Look, the folder is already created, so it's coming soon, coming soon)~~ -甚至，你还可以定制自己的 `geosite` 文件，外挂给 `Xray` 使用，但是这个就跑题了，本文不展开。 - -如果你发现有些你遇到的域名没有被合理分类，请向上面的项目们提出 `issue` 甚至提交 `Pull Request` 吧！社区列表社区维护，人人为我我为人人！ +You can even customize your own `geosite` file and load it externally for `Xray` to use, but that's off-topic and won't be expanded upon in this article. +If you find that some domains you encounter are not properly classified, please raise an `issue` or even submit a `Pull Request` to the projects above! Community lists are maintained by the community; one for all, all for one! ::: -### 3.6 军师锦囊藏奇兵：一条隐藏的路由规则 +### 3.6 The Strategist's Hidden Card: A Hidden Routing Rule -事实上，当你认真思考上面的规则，不难发现一个问题，我们的所有规则都只规定了【当入站流量 **符合某种条件时** 应该被转发给哪个出站】，那么，如果 `geosite.dat` 文件不全面，我们的入站流量【**不符合任何条件时**】，`Xray` 会怎么处理呢？ +In fact, if you think carefully about the rules above, it's not hard to spot a problem. All our rules only stipulate [which outbound to forward to **when the inbound traffic meets certain conditions**]. So, if the `geosite.dat` file is not comprehensive, how will `Xray` handle our inbound traffic **when it does not meet any conditions**? -::: warning 注意 -如果你认为【不符合条件当然就无法连接啦！】的话，你可要重新思考一下哦。因为只有指定了 `[block]` 规则，才会被导入到 `blackhole` 黑洞协议从而阻断连接 +::: warning Note +If you think "If it doesn't meet conditions, of course it can't connect!", you need to rethink. Because only when a `[block]` rule is specified will it be imported into the `blackhole` protocol to block the connection. ::: -事实上，`Xray` 为了避免路由规则不完全导致的规则混乱，已经贴心的提供了一条隐藏的路由规则：【**当入站流量不符合任何条件时，转发给第一个出站** 】 +In fact, to avoid rule chaos caused by incomplete routing rules, `Xray` has thoughtfully provided a hidden routing rule: [**When inbound traffic does not meet any conditions, forward it to the first outbound**]. -这样，就不会有任何流量被漏掉了。所以，你一定要把你最信赖的心腹大将放在【第一条出站】，让它为你守城护池。 +This way, no traffic will be left out. Therefore, you must place your most trusted "general" at the [First Outbound] position to guard your city. -### 3.7 再看“三分天下”的大地图 +### 3.7 Looking at the "Three Kingdoms" Big Map Again -因为我们在前面的示例中把 `[proxy-out-vless]` 放在了出站的第一位，所以隐藏规则生效时，流量会通过 `VLESS` 协议被转发至远端的 VPS。因此，`Xray` 此时的完整工作逻辑如下： +Because we placed `[proxy-out-vless]` in the first position of the outbounds in the previous example, when the hidden rule takes effect, traffic will be forwarded to the remote VPS via the `VLESS` protocol. Therefore, `Xray`'s complete working logic at this time is as follows: ```mermaid graph LR; - S(APP数据) .-> I[入站] + S(APP Data) .-> I[Inbound] subgraph Xray - I --> R[路由] -- "geosite:category-ads-all" --> O1[block] - R[路由] -- "geosite:cn" --> O2[direct] - R[路由] -- "geosite:geolocation-!cn" --> O3[proxy] - R[路由] -. "没有命中规则的流量" .-> O4[第一条出站] + I --> R[Routing] -- "geosite:category-ads-all" --> O1[block] + R[Routing] -- "geosite:cn" --> O2[direct] + R[Routing] -- "geosite:geolocation-!cn" --> O3[proxy] + R[Routing] -. "Traffic hitting no rules" .-> O4[First Outbound] end - O2 .-> D(国内服务器) + O2 .-> D(Domestic Server) O3 .-> V(VPS) O4 .-> V(VPS) @@ -350,15 +349,15 @@ ``` -事实上，这就是传统所谓的 **【默认科学上网、国内网站白名单直连】** 的配置。 +In fact, this is the traditional configuration known as **[Default Proxy (Science Internet), Domestic Website Whitelist Direct]**. -## 4. “三分天下” 之 “蜀魏争雄” +## 4. "Three Kingdoms" - "Shu vs Wei": Changing Priorities -现在，你已经知道了隐藏的默认路由规则：【**当入站流量不符合任何条件时，转发给第一个出站** 】。这时候，你应该能看出来，究竟是【科学上网】为王，还是【直连】称霸，全看你的第一条出站是什么！ +Now, you already know the hidden default routing rule: [**When inbound traffic does not meet any conditions, forward to the first outbound**]. At this point, you should be able to see that whether [Proxy/Science Internet] rules supreme or [Direct Connection] dominates depends entirely on what your first outbound is! -上一步我们已经配置出了 **【默认科学上网、国内网站白名单直连】** 的规则。那么现在只要 **【把直连规则放在第一位】**，就立即变成了正好相反的 **【默认直连、国外网站白名单科学上网】** 规则。 +In the previous step, we configured the **[Default Proxy, Domestic Whitelist Direct]** rule. Now, as long as we **[place the direct rule in the first position]**, it immediately changes to the exact opposite **[Default Direct, Foreign Website Whitelist Proxy]** rule. -是不是，非常地简单？ +Isn't it very simple? ```json { @@ -379,22 +378,22 @@ } ``` -此时，路由规则其实变成了： +At this time, the routing rules actually become: ```mermaid graph LR; - S(APP数据) .-> I[入站] + S(APP Data) .-> I[Inbound] subgraph Xray - I --> R[路由] -- "geosite:category-ads-all" --> O1[block] - R[路由] -- "geosite:geolocation-!cn" --> O3[proxy] - R[路由] -- "geosite:cn" --> O2[direct] - R[路由] -. "没有命中规则的流量" .-> O4[第一条出站] + I --> R[Routing] -- "geosite:category-ads-all" --> O1[block] + R[Routing] -- "geosite:geolocation-!cn" --> O3[proxy] + R[Routing] -- "geosite:cn" --> O2[direct] + R[Routing] -. "Traffic hitting no rules" .-> O4[First Outbound] end - O2 .-> D(国内服务器) + O2 .-> D(Domestic Server) O3 .-> V(VPS) O4 .-> D @@ -408,12 +407,12 @@ ``` -这就是路由功能的灵活之处了，你可以自由的改变它的顺序来实现不同的设计。 +This is the flexibility of the routing function; you can freely change its order to achieve different designs. -至此，我们已经解释完了 **【如何利用 `geosite.dat` 文件，通过路由规则，根据【域名】来分流网络流量】。** +At this point, we have finished explaining **[How to use the `geosite.dat` file to route network traffic based on [Domain Name] through routing rules].** -## 5. 攻城略池 - 多种路由匹配条件 +## 5. Conquering Cities - Multiple Routing Match Conditions -请确保你已经读懂了上面的内容，因为这样，你就已经理解了【路由】功能的工作逻辑。有了这个基础，我们就可以继续分析【路由】功能更多更详细的配置方式和匹配条件了。 +Please ensure you have understood the content above, because this means you have understood the working logic of the [Routing] function. With this foundation, we can continue to analyze more detailed configuration methods and matching conditions of the [Routing] function. -等你看完后面的内容，就完全可以自由的定制属于自己的路由规则啦！还等什么，让我们一起进入 [《路由 (routing) 功能简析（下）》](./routing-lv1-part2.md) 吧！ +Once you finish reading the subsequent content, you will be completely able to freely customize your own routing rules! What are you waiting for? Let's enter [《A Brief Analysis of Routing Functionality (Part 2)》](./routing-lv1-part2.md) together! diff --git a/docs/en/document/level-1/routing-lv1-part2.md b/docs/en/document/level-1/routing-lv1-part2.md index a8137b6e..239732f1 100644 --- a/docs/en/document/level-1/routing-lv1-part2.md +++ b/docs/en/document/level-1/routing-lv1-part2.md @@ -1,71 +1,71 @@ -# 路由 (routing) 功能简析（下） +# Brief Analysis of Routing Functions (Part 2) -欢迎继续学习 `Xray` 的【路由】功能！ +Welcome back to the study of `Xray`'s **[Routing]** function! -在 [《路由 (routing) 功能简析（上）》](./routing-lv1-part1.md) 中，我们已经对【路由】功能的工作逻辑有了清晰的理解，也基于 `geosite.dat` 文件做了简单的域名分流配置。 +In [Brief Analysis of Routing Functions (Part 1)](./routing-lv1-part1.md), we gained a clear understanding of the working logic of the **[Routing]** function and set up simple domain-based shunting based on the `geosite.dat` file. -如前面所说，域名分流仅仅是【路由】功能的牛刀小试而已。下面就让我们来看看除了域名之外，还什么可以用做分流依据的东西吧！ +As mentioned earlier, domain-based shunting is just a small test of the **[Routing]** function's capabilities. Now, let's see what else, besides domains, can be used as a basis for shunting! -## 5. 攻城略池 - 多种路由匹配条件 +## 5. Expanding Horizons - Multiple Routing Matching Conditions -> `[域名], [IP], [协议], etc.` +> `[domain], [IP], [protocol], etc.` -基于域名的分流，已经可以让我们对网络流量进行基本合理的分流。为什么说【基本合理】呢？ +Shunting based on domains allows us to route network traffic in a basically reasonable way. Why do I say "basically reasonable"? -因为【三分天下】虽然是正确的战略方向，但如果只用【域名】来实现这个战略，其实漏洞百出，比如： +Because although "Dividing the world into three" (Block, Direct, Proxy) is the correct strategic direction, if you only use **[Domain]** to implement this strategy, it is actually full of loopholes. For example: -1. 我读了《小小白白话文》后，给 VPS 新申请了一个 `proxy.yourdomain.com` 的域名, 我希望它无论如何都代理，`geosite.dat` 里面有吗？ -2. 如果我还有个 `direct.yourdomain.com` 的域名，我希望它无论如何都直连， `geosite.dat` 里面有吗？ -3. 本机 `127.0.0.1` 的内部流量，是否正确直连了？（比如 `docker` 等） -4. 路由器、本地局域网 `192.168.*.*` 的流量，是否正确直连了？（比如路由器、群晖等） -5. 我的国内 DNS 查询（如 `223.5.5.5`）是否正确直连了？ -6. 我的国外 DNS 查询（如 `1.1.1.1`）是否正确代理了？ -7. 其他类似国内公共 DNS 一样没有域名、只有 IP 地址的国内网站，是否正确直连了？ -8. 其他类似国外公共 DNS 一样没有域名、只有 IP 地址的国外网站，是否正确代理了？ -9. BT 下载的流量，虽然来源是国外，但如果通过 VPS 下载很可能导致违规使用被封，这该如何强制直连？ +1. After reading the "Simple Guide for Beginners", I applied for a new domain `proxy.yourdomain.com` for my VPS. I want it to be proxied no matter what. Is it in `geosite.dat`? +2. If I have another domain `direct.yourdomain.com`, and I want it to be connected directly no matter what. Is it in `geosite.dat`? +3. Is the internal traffic of the local machine `127.0.0.1` (such as `docker`, etc.) correctly connected directly? +4. Is the traffic of the router and local LAN `192.168.*.*` correctly connected directly? (Such as routers, Synology NAS, etc.) +5. Are my domestic DNS queries (such as `223.5.5.5`) correctly connected directly? +6. Are my foreign DNS queries (such as `1.1.1.1`) correctly proxied? +7. Are other domestic websites that only have IP addresses and no domains (similar to domestic public DNS) correctly connected directly? +8. Are other foreign websites that only have IP addresses and no domains (similar to foreign public DNS) correctly proxied? +9. Although the source of BT download traffic is abroad, downloading via VPS may lead to a ban due to violation of usage terms. How can I force this to be direct? 10. ...... -我之所以说只用【域名分流】会漏洞百出，是因为 `geosite.dat` 文件内只包含了一部分常用的域名。换言之，仅仅依赖它，则会： +The reason I say using only **[Domain Shunting]** is full of loopholes is that the `geosite.dat` file only contains a portion of commonly used domains. In other words, relying solely on it will result in: -- 无法匹配文件里没有的新域名 -- 无法匹配基于 IP 地址的规则 -- 无法匹配基于网络协议的规则 +- Inability to match new domains not in the file. +- Inability to match rules based on IP addresses. +- Inability to match rules based on network protocols. -::: warning 啰嗦君 -那我们来复习一下，当上面这些情况无法匹配时，会发生什么？对了，会触发隐藏路由规则，即【**转发给第一个出站** 】。这其实就是说： +::: warning Mr. Wordy +Let's review: what happens when the situations above cannot be matched? That's right, the hidden routing rule will be triggered, which is **[Forward to the first outbound]**. This actually means: -- 当你的第一个出站是 `[direct-out]` 时：**需要直连的都正确了，但需要代理的则都错误** -- 当你的第一个出站是 `[proxy-out-vless]` 时：**需要代理的都正确了，但需要直连的则都错误** - ::: +- When your first outbound is `[direct-out]`: **Everything needing direct connection is correct, but everything needing proxy is wrong.** +- When your first outbound is `[proxy-out-vless]`: **Everything needing proxy is correct, but everything needing direct connection is wrong.** +::: -所以，我们需要一个办法，让我们鱼与熊掌兼得。这样的办法是否存在呢？**当然存在！** 我们需要的只是【域名】之外更多的【**分流判断依据**】而已。 +Therefore, we need a way to have our cake and eat it too. Does such a way exist? **Of course!** All we need are more **[Shunting Judgment Criteria]** beyond just **[Domain]**. -### 5.1 基于指定域名分流：`[domain], [full]` 等 +### 5.1 Shunting Based on Specific Domains: `[domain], [full]`, etc -1. 如果需要匹配某个子域名，如 `a-name.yourdomain.com`，我们使用 `full: "a-name.yourdomain.com"` -2. 前面的 `问题1` 和 `问题2`，就可以通过给 `proxy.yourdomain.com` 指定 `[proxy-out-vless]` 出站，给 `direct.yourdomain.com` 指定 `[direct-out]` 出站来解决 -3. 如果需要匹配 `yourdomain.com` 的所有子域名，我们使用 `domain: "yourdomain.com"` 实现 -4. 上述两个可以成为两个独立的路由规则，达到某些子域名直连，其他子域名代理的配置 -5. 另外，`[domain]` 还支持正则表达式等匹配方式。详情请参考 [《基础配置模块 - 路由》文档](../../config/routing.md) +1. If we need to match a specific subdomain, such as `a-name.yourdomain.com`, we use `full: "a-name.yourdomain.com"`. +2. The previous `Question 1` and `Question 2` can be solved by assigning the `[proxy-out-vless]` outbound to `proxy.yourdomain.com` and the `[direct-out]` outbound to `direct.yourdomain.com`. +3. If we need to match all subdomains of `yourdomain.com`, we use `domain: "yourdomain.com"` to implement it. +4. The above two can become two independent routing rules, achieving a configuration where some subdomains are direct and others are proxied. +5. Additionally, `[domain]` also supports matching methods like regular expressions. For details, please refer to the [[Basic Configuration Module - Routing] documentation](../../config/routing.md). -上述配置如下： +The configuration is as follows: ```json { "routing": { "domainStrategy": "AsIs", "rules": [ - // 指定子域名直连 + // Specify subdomain for direct connection { "domain": ["full:direct.yourdomain.com"], "outboundTag": "direct-out" }, - // 指定子域名转发VPS + // Specify subdomain for forwarding to VPS { "domain": ["full:proxy.yourdomain.com"], "outboundTag": "proxy-out-vless" }, - // 指定泛域名转发VPS + // Specify wildcard domain for forwarding to VPS { "domain": ["yourdomain.com"], "outboundTag": "proxy-out-vless" @@ -75,27 +75,27 @@ } ``` -### 5.2 基于 IP 文件分流：`geoip.dat` +### 5.2 Shunting Based on IP Files: `geoip.dat` -除了使用 `geosite.dat` 核心自然也支持直接使用IP进行路由以满足各种需求。 +Very similar to the `geosite.dat` rule file, we also have the `geoip.dat` rule file. It is dedicated to providing users with a mature and complete **[IP Classification Table]**. It allows users to simply call any subclass via the `geoip:xxx` format to customize routing rules that meet their needs. -1. 解决前面的 `[问题3], [问题4]`，我们使用 `geoip:private` 类别来指定 `[direct-out]` -2. 解决前面的 `[问题7]`，我们使用 `geoip:cn` 类别来指定 `[direct-out]` -3. 解决前面的 `[问题8]`，由于 `geoip` 中没有【非中国 IP】这个分类（因为这等于要收集全世界的 IP 段），所以我们用隐藏规则代替，也就是将 `[proxy-out-vless]` 放在第一个出站 +1. To solve the previous `[Question 3]` and `[Question 4]`, we use the `geoip:private` category to specify `[direct-out]`. +2. To solve the previous `[Question 7]`, we use the `geoip:cn` category to specify `[direct-out]`. +3. To solve the previous `[Question 8]`, since `geoip` does not have a category for "Non-Chinese IPs" (because this would mean collecting IP ranges from the entire world), we use the hidden rule instead, which is placing `[proxy-out-vless]` as the first outbound. -上述配置如下： +The configuration is as follows: ```json { "routing": { "domainStrategy": "AsIs", "rules": [ - // 本机内部地址、局域网地址直连 + // Local internal addresses and LAN addresses direct connection { "ip": ["geoip:private"], "outboundTag": "direct-out" }, - // 国内IP集直连 + // Domestic IP set direct connection { "ip": ["geoip:cn"], "outboundTag": "direct-out" @@ -105,26 +105,26 @@ } ``` -### 5.3 基于指定 IP 地址分流 +### 5.3 Shunting Based on Specific IP Addresses -与 `geosite.dat` 规则文件十分类似的，我们还有 `geoip.dat` 这个规则文件，它是供【路由功能】驱使的**第二个神兵利器**，它致力于为用户提供成熟完善的【IP 分类表】。让用户可以简单的通过 `geoip:xxx` 这种格式方便的调用任何子类，定制符合自身需求的路由规则 。 +In addition to using `geoip.dat`, the core naturally supports routing directly using IPs to meet various needs. -1. 解决前面的 `[问题5]`，我们使用 `ip: "223.5.5.5"` 来指定 `[direct-out]` -2. 解决前面的 `[问题6]`，我们使用 `ip: "1.1.1.1"` 来指定 `[proxy-out-vless]` +1. To solve the previous `[Question 5]`, we use `ip: "223.5.5.5"` to specify `[direct-out]`. +2. To solve the previous `[Question 6]`, we use `ip: "1.1.1.1"` to specify `[proxy-out-vless]`. -上述配置如下： +The configuration is as follows: ```json { "routing": { "domainStrategy": "AsIs", "rules": [ - // 指定IP地址直连 + // Specific IP address direct connection { "ip": ["223.5.5.5"], "outboundTag": "direct-out" }, - // 指定IP地址转发VPS + // Specific IP address forwarding to VPS { "ip": ["1.1.1.1"], "outboundTag": "proxy-out-vless" @@ -134,12 +134,12 @@ } ``` -### 5.4 基于协议类型分流：`[protocol]` 等 +### 5.4 Shunting Based on Protocol Types: `[protocol]`, etc -1. 解决前面的 `[问题9]`，我们使用 `"protocol": ["bittorrent"]` 类别来指定 `[direct-out]` +1. To solve the previous `[Question 9]`, we use the `"protocol": ["bittorrent"]` category to specify `[direct-out]`. ::: tip -你需要打开入站代理中的 `sniffing` 才能使用此种方式分流。 +You need to enable `sniffing` in the inbound proxy to use this method for shunting. ::: ```json @@ -147,7 +147,7 @@ "routing": { "domainStrategy": "AsIs", "rules": [ - // 指定 BT 协议直连 + // Specific BT protocol direct connection { "protocol": ["bittorrent"], "outboundTag": "direct-out" @@ -157,18 +157,18 @@ } ``` -### 5.5 基于更多条件的分流 +### 5.5 Shunting Based on More Conditions -到目前位置，我们仍然只讲了【路由功能】分流能力的冰山一角！因为它还支持很多其他的判断条件！我在此简单罗列如下： +Up to this point, we have only touched the tip of the iceberg of the **[Routing Function]**'s shunting capabilities! It supports many other judgment conditions! I will briefly list them below: -本文已经讲过的： +Covered in this article: - `inboundTag` - `domain` - `ip` - `protocol` -本文尚未讲到的： +Not yet covered in this article: - `port` - `sourcePort` @@ -177,14 +177,14 @@ - `user` - `attrs` -但这些内容实在是过多，全部展开就远远不是 `level-1` 的内容了，所以，需要这些复杂条件的朋友，请仔细阅读 [《基础配置模块 - 路由》文档](../../config/routing.md) 自学哦！有问题就去 TG 群里面问问吧！ +However, expanding on all these would be too much content, far beyond the scope of `level-1`. Therefore, friends who need these complex conditions, please carefully read the [[Basic Configuration Module - Routing] documentation](../../config/routing.md) to learn on your own! If you have questions, ask in the Telegram group! -## 6. “霸业初定”：路由规则整体回顾 +## 6. "The Empire is Set": A Comprehensive Review of Routing Rules -到现在为止，我们已经累积出了一套战略雄伟、战术精准的路由规则，为了避免混乱，现在就对它进行一次完整的整理和回顾。 +So far, we have accumulated a set of routing rules with grand strategy and precise tactics. To avoid confusion, let's now organize and review them completely. -::: warning 注意 -路由生效的顺序是：【从上往下，依次判断】，所以我一般推荐的规则顺序是： +::: warning Note +The order in which routing takes effect is: **[Top to bottom, judged sequentially]**. Therefore, the rule order I generally recommend is: `[1-block] --> [2-direct] --> [3-proxy] --> [4-first-outbound]` ::: @@ -194,30 +194,30 @@ "routing": { "domainStrategy": "AsIs", "rules": [ - // [1-block 广告流量屏蔽] - // 1.1 广告域名集屏蔽 + // [1-block Ad traffic blocking] + // 1.1 Ad domain set blocking { "domain": ["geosite:category-ads-all"], "outboundTag": "block" }, - // [2-direct 国内流量直连] - // 2.1 国内域名集、指定子域名直连 + // [2-direct Domestic traffic direct connection] + // 2.1 Domestic domain set, specific subdomain direct connection { "domain": ["geosite:cn", "full:direct.yourdomain.com"], "outboundTag": "direct-out" }, - // 2.2 本机内部地址+局域网、国内IP、指定IP直连 + // 2.2 Local internal address + LAN, Domestic IP, Specific IP direct connection { "ip": ["geoip:private", "geoip:cn", "223.5.5.5"], "outboundTag": "direct-out" }, - // 2.3 BT协议流量直连 + // 2.3 BT protocol traffic direct connection { "protocol": ["bittorrent"], "outboundTag": "direct-out" }, - // [3-proxy 国外流量转发VPS] - // 3.1 国外域名集、指定子域名、指定泛域名转发VPS + // [3-proxy Foreign traffic forwarding to VPS] + // 3.1 Foreign domain set, specific subdomain, specific wildcard domain forwarding to VPS { "domain": [ "geosite:geolocation-!cn", @@ -226,45 +226,45 @@ ], "outboundTag": "proxy-out-vless" }, - // 3.2 指定IP转发VPS + // 3.2 Specific IP forwarding to VPS { "ip": ["1.1.1.1"], "outboundTag": "proxy-out-vless" } - // [4-default-routing 第一条出站] - // 没有匹配到任何规则的流量，默认使用第一条出站处理 + // [4-default-routing First outbound] + // Traffic not matching any rules defaults to the first outbound handling ] } } ``` -此时，路由规则其实变成了： +At this point, the routing rules have effectively become: ```mermaid graph LR; - S(APP数据) .-> I[入站] + S(App Data) .-> I[Inbound] subgraph Xray - I --> R[路由] -- "geosite:category-ads-all" --> O1[block] + I --> R[Routing] -- "geosite:category-ads-all" --> O1[block] - R[路由] -- "geosite:cn" --> O2[direct] - R[路由] -- "direct.yourdomain.com" --> O2[direct] - R[路由] -- "geoip:private" --> O2[direct] - R[路由] -- "geoip:cn" --> O2[direct] - R[路由] -- "ip:223.5.5.5" --> O2[direct] - R[路由] -- "protocol:bittorrent" --> O2[direct] + R[Routing] -- "geosite:cn" --> O2[direct] + R[Routing] -- "direct.yourdomain.com" --> O2[direct] + R[Routing] -- "geoip:private" --> O2[direct] + R[Routing] -- "geoip:cn" --> O2[direct] + R[Routing] -- "ip:223.5.5.5" --> O2[direct] + R[Routing] -- "protocol:bittorrent" --> O2[direct] - R[路由] -- "geosite:geolocation-!cn" --> O3[proxy] - R[路由] -- "proxy.yourdomain.com" --> O3[proxy] - R[路由] -- "*.yourdomain.com" --> O3[proxy] - R[路由] -- "ip:1.1.1.1" --> O3[proxy] + R[Routing] -- "geosite:geolocation-!cn" --> O3[proxy] + R[Routing] -- "proxy.yourdomain.com" --> O3[proxy] + R[Routing] -- "*.yourdomain.com" --> O3[proxy] + R[Routing] -- "ip:1.1.1.1" --> O3[proxy] - R[路由] -. "没有命中规则的流量" .-> O4[第一条出站] + R[Routing] -. "Traffic not hitting any rules" .-> O4[First Outbound] end - O2 .-> D(国内服务器) + O2 .-> D(Domestic Server) O3 .-> V(VPS) O1:::redclass @@ -277,20 +277,20 @@ ``` -至于第一条出站是 `[direct-out]` 还是 `[proxy-out-vless]`，这就全看你的需求了。 +As for whether the first outbound is `[direct-out]` or `[proxy-out-vless]`, that depends entirely on your needs. -## 7. 路由配置常见错误 +## 7. Common Routing Configuration Errors -请大家注意看，我上面每一条路由规则，都是一个独立的匹配依据，只有这样才能确保生效。而新人在自定义路由规则时常犯的一个错误就是：**在一条规则内同时匹配了多种不同的匹配依据，造成匹配无效。** +Please pay attention: every routing rule I listed above is an independent matching basis. This is the only way to ensure they take effect. A common mistake newcomers make when customizing routing rules is: **Matching multiple different matching criteria within a single rule, causing the match to fail.** -比如，他希望实现的配置是： +For example, the configuration they hope to achieve is: -1. 自己的 `direct.yourdomain.com` 直连 -2. 国内 DNS 查询（如 `223.5.5.5`）直连 +1. Their own `direct.yourdomain.com` connects directly. +2. Domestic DNS queries (such as `223.5.5.5`) connect directly. -### 7.1 错误示范 +### 7.1 Incorrect Example -为了实现上面的目标，他写出了以下路由规则： +To achieve the above goals, they wrote the following routing rule: ```json { @@ -307,19 +307,19 @@ } ``` -你能看出这里面的错误吗？乍一看，似乎是对的？ +Can you spot the error here? At first glance, it seems correct? -::: warning 注意 -**同一个规则之内，各个依据需要同时成立，才会匹配成功**，逻辑关系是 `和`，而不是 `或`。 +::: warning Note +**Within the same rule, all criteria must be met simultaneously for the match to succeed.** The logical relationship is `AND`, not `OR`. ::: -换言之，这条规则的意思是：【当你访问的 `目标 = direct.yourdomain.com`, **并且** 同时还满足 `目标 = 223.5.5.5` 时，`Xray` 才会将流量转发给 `[direct-out]` 直连出站】 +In other words, this rule means: **[Xray will only forward traffic to `[direct-out]` when the target = `direct.yourdomain.com` **AND** at the same time the target = `223.5.5.5`]**. -很显然，一个目标不可能同时等于两个不同的值，所以这不但是一个永远不可能实现的无效规则，更与原本的目标风马牛不相及。 +Obviously, a target cannot equal two different values at the same time. So this is not only an invalid rule that can never be realized, but it also has nothing to do with the original goal. -### 7.2 正确示范 +### 7.2 Correct Example -正确示范，自然就是将不同的匹配依据独立出来： +The correct example is naturally to separate the different matching criteria: ```json { @@ -339,78 +339,78 @@ } ``` -其实，第 6 点已经是我整理过的规则了，原则就是【相同的匹配依据可以合并，不同的匹配依据保持独立】。 +In fact, point 6 was already my organized rules. The principle is **[Identical matching criteria can be merged, different matching criteria must remain independent]**. -## 8. 明修栈道、暗渡陈仓 +## 8. The Secret Passage -> `[domain]` 转化 `[ip]` 的密道：`domainStrategy` +> The secret path from `[domain]` to `[ip]`: `domainStrategy` -我们在 5.4 中提交了多种流量判断的【依据】，其中一种是域名 `[domain]`、一种是 `[IP]`。 +In section 5.4, we presented various **[criteria]** for traffic judgment. One is domain `[domain]`, and another is `[IP]`. -如果你初步了解过 DNS 的运作过程，就会知道，我们对一个域名 `[domain]` 发起访问请求时，其实需要先向 `DNS` 发起请求来解析域名 `[domain]` 对应的 `[IP]`，在得到 `[IP]` 后再向它发起实际请求。 +If you have a preliminary understanding of how DNS works, you know that when we initiate a request to a domain `[domain]`, we actually need to first initiate a request to `DNS` to resolve the `[IP]` corresponding to the domain `[domain]`, and then initiate the actual request to that `[IP]`. -所以，面对入站的一次域名请求，`Xray` 其实有两次机会去判断它的类型。那么，究竟是否要用这两次机会呢？这就是由 `domainStrategy` 这个配置来决定的。它有三个选项： +Therefore, facing an inbound domain request, `Xray` actually has two opportunities to judge its type. So, should we use these two opportunities? This is decided by the `domainStrategy` configuration. It has three options: - `AsIs` - `IPIfNonMatch` - `IPOnDemand` -按么我们逐个来解释一下： +Let's explain them one by one: -### 8.1 域名策略: `"AsIs"` +### 8.1 Domain Strategy: `"AsIs"` -就是 "As Domain Is"，也就是说 【域名什么样，就什么样，不多折腾】。 +This means "As Domain Is", which implies **[Just let the domain be, don't fuss with it]**. -简单粗暴理解就是说【仅用 `[domain]` 来匹配】。 +To understand it simply and crudely: **[Only use `[domain]` to match]**. ::: tip -`AsIs` 的实际意义为 【如原先所示，不加修改】，🍉 老师这里描述的不是很恰当。 +The actual meaning of `AsIs` is "As shown in the original, without modification". Teacher Watermelon didn't describe it very precisely here. ::: -这个方式的处理都在 `Xray` 内部完成，没有与外界的数据往来，所以速度最快。它的兜底策略也很清晰：即前面所说的、无法匹配的域名自动转入第一条出站处理。所以，对于常规使用路由功能这最推荐的策略。 +The processing of this method is completed within `Xray`, with no data exchange with the outside world, so it is the fastest. Its fallback strategy is also clear: that is, the unmatchable domains mentioned earlier are automatically transferred to the first outbound for processing. Therefore, this is the most recommended strategy for general routing usage. -### 8.2 域名策略: `"IPIfNonMatch"` +### 8.2 Domain Strategy: `"IPIfNonMatch"` -就是 "lookup IP if (there's) no matching rule"，也就是说【如果其他所有规则都匹配不上，那就转化成 `IP` 去匹配 `IP` 规则】。 +This means "lookup IP if (there's) no matching rule", which implies **[If no other rules match, then convert to `IP` to match `IP` rules]**. -简单粗暴理解就是说【先把访问目标和其他所有类型规则匹配，如果匹配不上，那就通过 `DNS` 查询转化成 `IP`，再从头和所有规则匹配一次】。 +To understand it simply and crudely: **[First match the access target with all other types of rules. If there is no match, then convert it to `IP` via `DNS` query, and match it against all rules again from the beginning]**. -该策略下没有命中任何规则的这一部分域名，会需要再经历 `DNS` 查询过程、以及第二轮规则匹配的过程，其耗时会多于 `AsIs` 策略，所以并不是首选推荐的策略。 +Under this strategy, domains that do not hit any rules need to go through the `DNS` query process and a second round of rule matching. It takes more time than the `AsIs` strategy, so it is not the preferred recommended strategy. -### 8.3 域名策略: `"IPOnDemand"` +### 8.3 Domain Strategy: `"IPOnDemand"` -这里其实说 `Demand IP` 更准确些，也就是说【当匹配时碰到任何基于 IP 的规则，将域名立即解析为 IP 进行匹配】。 +It is actually more accurate to say `Demand IP` here, which implies **[When matching, if any IP-based rule is encountered, immediately resolve the domain to IP for matching]**. -简单粗暴理解就是说【只要路由规则中有 `IP` 类规则，那么所有基于域名 `[domain]` 的请求都要解析成 `[IP]` 然后去匹配 `[IP]` 类规则】。 +To understand it simply and crudely: **[As long as there are `IP` type rules in the routing rules, then all requests based on domain `[domain]` must be resolved into `[IP]` and then matched against `[IP]` type rules]**. -它要对所有首次域名访问进行 `DNS` 解析，所以首次查询比较耗时。虽然由于 `Xray` 中 `DNS` 缓存机制的存在，后续对相同域名的访问速度会重回巅峰，但总体来说也不是首选推荐的策略。 +It requires `DNS` resolution for all initial domain accesses, so the first query is relatively time-consuming. Although due to the existence of the `DNS` caching mechanism in `Xray`, subsequent access speeds to the same domain will return to peak performance, generally speaking, it is not the preferred recommended strategy either. -::: warning 啰嗦君 -`domainStrategy` 仅对域名生效，不要搞混了哦~ +::: warning Mr. Wordy +`domainStrategy` only takes effect for domains, don't get mixed up~ ::: -## 9. 思考题 +## 9. Thought Exercises -迄今为止，我们都是在【单入站】和【单出站】的基础上，讲解【路由】内部的各种配置逻辑。 +So far, we have been explaining the various configuration logics within **[Routing]** based on **[Single Inbound]** and **[Single Outbound]**. -但是，如你所知，`Xray` 本身是支持多端口，多协议的。那么，如果我问你： +However, as you know, `Xray` itself supports multiple ports and multiple protocols. So, if I ask you: -1. 我希望 `VLESS` 协议将我日常的网页浏览和 APP 流量转发给美国的大流量服务器 -2. 我希望 `trojan` 协议将我的所有 Netflix 流量转发给日本的服务器解锁各种二次元 -3. 我希望 `shadowsocks` 协议将我所有的游戏流量转发给香港的服务器达到最低的延迟 -4. 我希望有一个独立的端口，能够把 `telegram` 的流量全都转发给 VPS -5. 我希望有一个独立的端口，能够把 `bittorrent` 下载流量全都转发给欧洲大盘鸡 -6. 我希望...... +1. I want the `VLESS` protocol to forward my daily web browsing and App traffic to a high-traffic server in the US. +2. I want the `trojan` protocol to forward all my Netflix traffic to a server in Japan to unlock various anime content. +3. I want the `shadowsocks` protocol to forward all my gaming traffic to a server in Hong Kong to achieve the lowest latency. +4. I want an independent port to forward all `telegram` traffic to the VPS. +5. I want an independent port to forward all `bittorrent` download traffic to a "Big Disk Chicken" (Server with large storage) in Europe. +6. I want...... -这些想法，是否能通过【路由】功能配置实现呢？ +Can these ideas be realized through **[Routing]** configuration? -答案当然是 **【完全可以】** 啦！ 但是这些对于 `level-1` 来说已经超纲了，就留给各位自由的探索吧！ +The answer is, of course, **[Absolutely!]** But these are already beyond the scope of `level-1`, so I'll leave them for you to explore freely! -## 10. 结语 +## 10. Conclusion -至此，`Xray` 的【路由】功能就介绍完了。希望本文能够对你理解 `Xray` 的灵活有所帮助。 +This concludes the introduction to `Xray`'s **[Routing]** function. I hope this article helps you understand the flexibility of `Xray`. -## 11. 尾注 +## 11. Endnotes -- 现在你可以重新阅读一遍 [路由](../../config/routing.md)，看看是否有更加深刻的理解。 +- Now you can read the [Routing](../../config/routing.md) documentation again to see if you have a deeper understanding. - 🍉🍉🍉🍉🍉 :D diff --git a/docs/en/document/level-1/routing-with-dns.md b/docs/en/document/level-1/routing-with-dns.md new file mode 100644 index 00000000..d1fadf7d --- /dev/null +++ b/docs/en/document/level-1/routing-with-dns.md @@ -0,0 +1,286 @@ +# Achieving Precise Domestic/Foreign Traffic Splitting via DNS + +## Conventional Splitting Methods and Their Flaws + +When you try to manually craft proxy rules, you inevitably ask yourself: Which traffic should go through the proxy, and which should go directly? + +The answer is usually a Blacklist or Whitelist. + +Over the past decade, the community has maintained massive rule lists, giving birth to many excellent projects: + +-Google Domains| C["Query via Proxy
Foreign DNS (1.1.1.1...)"]; + C --> C_OUT[Likely returns Foreign IP]; + C_OUT --> Z[End Query]; + + B -->|geosite:cn
Known/Suspected CN Domains| D["Query via Direct
Domestic DNS (114, AliDNS)"]; + D --> E{Result is CN IP?}; + E -->|"Yes (Expected)"| F_OUT[Return CN IP]; + F_OUT --> Z; + E -->|"No (Polluted/Wrong/Left CN)"| G["Fallback: Query via Proxy
Foreign DNS (1.1.1.1...)"]; + G --> G_OUT[Return correct Foreign IP]; + G_OUT --> Z; + + B -->|geosite:geolocation-!cn
Known/Suspected Foreign| I["Query via Proxy
Foreign DNS (1.1.1.1...)"]; + I --> J{Result is Foreign IP?}; + J -->|"Yes (Expected)"| K_OUT[Return Foreign IP]; + K_OUT --> Z; + J -->|"No (Unexpectedly CN IP / Wrong)"| L["Fallback: Query via Proxy+ECS
Foreign DNS (8.8.8.8...)"]; + L --> L_OUT[Return optimized CN IP]; + L_OUT --> Z; + + B -->|Unknown Domains| N["Query via Proxy+ECS
Foreign DNS (8.8.8.8...)
Expect CN IP"]; + N --> O{Result is CN IP?}; + O -->|"Yes (Has CN Server)"| P_OUT[Return CN IP]; + P_OUT --> Z; + O -->|"No (Pure Foreign Site)"| Q["Fallback: Query via Proxy
Foreign DNS (1.1.1.1...)"]; + Q --> Q_OUT[Return optimized Foreign IP]; + Q_OUT --> Z; +``` + +You can route traffic based on the IP resolved by this configuration combined with the domain name, or rely entirely on the IP. + +In a realIp transparent proxy environment, you can even ensure that after hijacking DNS from various channels, you set `domainStrategy=AsIs` and `routeOnly=true` to achieve a process with no secondary DNS resolution throughout. + +> Note: The "CDN-friendly" mentioned above regarding the foreign part is optimized for the location of your **proxy server**. If you are only proxying blacklisted sites rather than all foreign traffic, you need to adjust the ECS in the rules yourself. + +#### Example 2: This configuration resolves correct but not necessarily foreign-CDN-friendly addresses. It guarantees no DNS Leaks while prioritizing China servers if they exist. It is suitable for fakeIp transparent proxy, socks, and http inbound scenarios + +```json +{ + "dns": { + "servers": [ + // Prevent Google CAPTCHA issues, prevent Google China monitoring + { + "address": "1.1.1.1", + "skipFallback": true, + "domains": ["geosite:google", "geosite:google-cn"], + "finalQuery": true // Terminate query chain + }, + { + // We don't fully trust geosite:cn, but if a domain is in this list, + // we try resolving it first. If it returns a China IP, it means it's not blocked. + // Conversely, if not, it's highly likely blocked. Fallback to 8.8.8.8 to resolve again, solving potential DNS pollution. + // We prioritize this because the cost is minimal; direct connection takes only ~10ms. + "tag": "dns-direct", + "address": "223.5.5.5", + "skipFallback": true, + "domains": ["geosite:cn"], + "expectIPs": ["geoip:cn"] + }, + { + // If a domain is not in geosite:cn, or fell back from the rule above, use this server. + // Here we use ECS to try and get China A/AAAA records. + "address": "8.8.8.8", + "clientIp": "222.85.85.85", // Provide local ISP IP to get direct-connection optimized A/AAAA records + // e.g., if you are Henan Telecom, use a Henan Telecom DNS + // Cannot guarantee 100% China CDN friendliness as not all authoritative servers support ECS + "skipFallback": false + } + ], + "tag": "dns-proxy" + }, + "routing": { + "domainStrategy": "Must be NON-AsIs, depends on your needs", + "rules": [ + { + // Routing for DNS queries themselves + "inboundTag": ["dns-direct"], + "outboundTag": "direct" + }, + { + // Routing for DNS queries themselves + "inboundTag": ["dns-proxy"], + "outboundTag": "proxy" + } + // Your personalized routing rules + // For media unlocking, use domain routing. For domestic/foreign splitting, ALWAYS use IP routing. + ] + } + // Others ignored, configure as needed... +} +``` + +In this scenario, since all requests sent to the Xray Server are domain names, there is no need to use DNS to repeatedly probe for the optimal result. We only need to quickly identify if the domain is polluted and resolve a Chinese CDN-friendly IP as much as possible. + +The China IP resolved by the DNS module in this example is already 99% China CDN friendly. Therefore, you can set `domainStrategy` in the direct outbound to **non-AsIs** to utilize the cache if you wish. +
+If you pursue 100% China CDN friendliness, you can set it to `AsIs` to use the OS configured DNS to resolve it again. This adds about 1ms to hundreds of ms of latency; it is recommended to enable optimistic caching to further reduce latency. + +## Postscript + +It is known that many unscrupulous domestic Apps probe your overseas exit IP and correlate it with your sensitive information such as GPS location, phone number, and food delivery address, leaking it to social engineering databases. ~~Big brother is watching u!!!~~ + +Some people mistakenly believe this is caused by traffic splitting and that simply switching to Blacklist mode (only proxying blocked sites) will avoid it. +In reality, this is not the case. First, blacklists are very easy to poison; they can intentionally create bait websites and submit them to the list to probe your overseas IP. + +Secondly, as long as any website in the blacklist is hosted on Cloudflare, they don't even need bait. Just try accessing: `https://chatgpt.com/cdn-cgi/trace` + +Clever as you are, you might think: "Can't I just find another public proxy to layer on top?" The premise is that you must completely trust that this proxy keeps no logs and won't sell you out, and that it is heavily used by people in your country. If an overseas IP is correlated with thousands of people per unit of time, it is impossible to trace back to you via that IP. As for the annoying CAPTCHAs that come with such "dirty IPs," you just have to deal with them. + +Doesn't the cyber-philanthropist Cloudflare's Warp fit all these characteristics perfectly? Unfortunately, for websites hosted on CF, Warp cannot completely hide your IP; it is only effective for non-CF servers. + +Can Tor do it? It's not suitable for daily use. The IPs are too dirty, and the exit nodes jump frequently, causing many websites to ban your accounts. + +Therefore, unless the client you use can split traffic by App (which is only possible on mobile phones and computers), any other method of wall-crossing will lead to your overseas IP leaking. + +In short, for conventional wall-crossing methods, overseas IP leakage is almost inevitable. If you need high-level privacy protection, please use tools like Tor. Xray-core, as an anti-censorship tool, focuses on resisting blocking to help you cross the firewall, and its capabilities in privacy protection are very limited. diff --git a/docs/en/document/level-1/work.md b/docs/en/document/level-1/work.md index fce778e9..def7ee54 100644 --- a/docs/en/document/level-1/work.md +++ b/docs/en/document/level-1/work.md @@ -1,37 +1,37 @@ -# Xray 的工作模式 +# Xray Working Modes -## 单服务器模式 +## Single Server Mode -与其它的网络代理工具一样，你需要一台配置了 Xray 的服务器，然后在自己的设备上安装并配置 Xray 客户端，然后即可流畅地访问互联网。 +Like other network proxy tools, you need a server configured with Xray. Then, install and configure the Xray client on your device to access the Internet smoothly. ```mermaid graph LR; -A(PC) -.- B(防火墙); -B -.-> C(墙外网站); +A(PC) -.- B(Firewall); +B -.-> C(Foreign Websites); A --> D(Xray/VPS); D --> C; -A --> E(墙内网站); +A --> E(Domestic Websites); ``` -一个 Xray 服务器可同时支持多台设备使用不同的代理协议访问。同时，经过合理的配置，Xray 可以识别并区分需要代理以及不需要代理的流量，直连的流量不需要绕路。 +A single Xray server can support multiple devices accessing via different proxy protocols simultaneously. Meanwhile, with reasonable configuration, Xray can identify and distinguish traffic that needs proxying from traffic that doesn't; direct traffic does not need to take a detour. -## 桥接模式 +## Bridge Mode -如果你不想在每一台设备上都配置路由，你也可以设置一台中转服务器，用于接收客户端发来的所有流量，然后在服务器中进行转发判断。 +If you don't want to configure routing on every single device, you can set up a relay (transit) server. This server receives all traffic sent from clients and then makes forwarding decisions within the server itself. ```mermaid graph LR; -A(PC) -.-> B(防火墙); -B -.-> C(墙外网站); -A --> D(墙内 VPS); -D --> E(墙外 VPS); +A(PC) -.-> B(Firewall); +B -.-> C(Foreign Websites); +A --> D(Domestic VPS); +D --> E(Foreign VPS); E --> C; -D --> F(墙内网站); +D --> F(Domestic Websites); ``` -## 工作原理 +## Working Principle -在配置 Xray 之前，不妨先来看一下 Xray 的工作原理，以下是单个 Xray 进程的内部结构示意图。多个 Xray 之间相互独立，互不影响。 +Before configuring Xray, it is helpful to look at how Xray works. The following is a schematic diagram of the internal structure of a single Xray process. Multiple Xray instances are independent of each other and do not affect one another. ```mermaid graph LR; @@ -45,10 +45,10 @@ D --> B3(outbound); D --> B4(outbound); ``` -- 需要配置至少一个入站连接（Inbound）和一个出站连接（Outbound）才可以正常工作。 - - 入站连接负责与客户端（如浏览器）通信： - - 入站连接通常可以配置用户认证，如 ID 和密码等； - - 入站连接收到数据之后，会交给分发器（Dispatcher）进行分发； - - 出站连接负责将数据发给服务器，如另一台主机上的 Xray。 -- 当有多个出站连接时，可以配置路由（Routing）来指定某一类流量由某一个出站连接发出。 - - 路由会在必要时查询 DNS 以获取更多信息来进行判断。 +- You need to configure at least one **Inbound** and one **Outbound** connection for it to work properly. + - **Inbound** connections are responsible for communicating with clients (such as browsers): + - Inbound connections can usually be configured with user authentication, such as IDs and passwords. + - After receiving data, the inbound connection hands it over to the **Dispatcher** for distribution. + - **Outbound** connections are responsible for sending data to the destination, such as Xray on another host. +- When there are multiple outbound connections, you can configure **Routing** to specify that a certain category of traffic is sent via a specific outbound connection. + - The Router will query DNS when necessary to obtain more information for decision-making. diff --git a/docs/en/document/level-2/index.md b/docs/en/document/level-2/index.md index 5a364924..92a2b140 100644 --- a/docs/en/document/level-2/index.md +++ b/docs/en/document/level-2/index.md @@ -1,35 +1,35 @@ # Advanced Documentation -**This chapter contains experience sharing of using Xray at an advanced level. If you are already familiar with Xray, the experience shared here can help you unleash the full power of Xray.** +**This section contains advanced insights into using Xray. If you are already familiar with Xray, the experiences shared here will help you further unleash its full potential.** -[Beginner's Guide to Transparent Proxies](./transparent_proxy/transparent_proxy.md) by
[@kirin](https://github.com/kirin10000)
+[Introduction to Transparent Proxy](./transparent_proxy/transparent_proxy.md) by [@kirin](https://github.com/kirin10000)
-An Introduction to Transparent Proxies.
+An introductory chapter on Transparent Proxy.
-[TProxy Configuration Tutorial](./tproxy.md) by 
[@BioniCosmos](https://github.com/BioniCosmos)
+[Transparent Proxy (TProxy) Configuration Tutorial](./tproxy.md) by [@BioniCosmos](https://github.com/BioniCosmos)
-Complete tutorial on configuring transparent proxy (TProxy) based on Xray.
+A complete tutorial on configuring Transparent Proxy (TProxy) based on Xray.
[TProxy Transparent Proxy (IPv4 and IPv6) Configuration Tutorial](./tproxy_ipv4_and_ipv6.md) by 
[@SQLimit](https://github.com/SQLimit)
-Xray-based TProxy Transparent Proxy (IPv4 and IPv6) Configuration Tutorial
+Configuration tutorial for Xray-based TProxy Transparent Proxy (IPv4 and IPv6).
-[Nginx_TLS Tunnel Hidden Fingerprint](./nginx_or_haproxy_tls_tunnel.md) by [@SQLimit](https://github.com/SQLimit)
+[Using Nginx or HAProxy to Build TLS Tunnels to Hide Fingerprints](./nginx_or_haproxy_tls_tunnel.md) by [@SQLimit](https://github.com/SQLimit)
-Use Nginx_TLS tunnel on both ends to hide the fingerprint.
+Using Nginx or HAProxy on both ends to build a TLS tunnel for fingerprint hiding.
-[[Transparent Proxy] Avoiding Xray Traffic Through gid](./iptables_gid.md) by [@kirin](https://github.com/kirin10000)
+[[Transparent Proxy] Bypassing Xray Traffic via GID](./iptables_gid.md) by [@kirin](https://github.com/kirin10000)
-A new way of bypassing Xray traffic in transparent proxy implemented by iptables/nftables.
+A new method to bypass Xray traffic in transparent proxies implemented via iptables/nftables.
-[Redirect Specific Traffic to Specific Gateway using Xray to Achieve Global Routing "Load Balancing"](./redirect.md) by 
[@Zzz3m](https://github.com/Zzz3m)
+[Directing Specific Traffic to Specific Exits via Xray for Global Routing "Traffic Splitting"](./redirect.md) by [@Zzz3m](https://github.com/Zzz3m)
-Play Xray to the fullest: Implement "load balancing" based on fwmark or sendThrough.
+Getting creative with Xray: Achieving "traffic splitting" based on fwmark, sendThrough, or sockopt.interface.
-[Enhancing Proxy Security with Cloudflare Warp](./warp.md) by 
[@yuhan6665](https://github.com/yuhan6665)
+[Enhancing Proxy Security via Cloudflare Warp](./warp.md) by [@yuhan6665](https://github.com/yuhan6665)
-Introduction to using WireGuard for outbound traffic added in Xray v1.6.5.
+Introduction to the use of the WireGuard outbound added in Xray v1.6.5.
[Xray Traffic Statistics](./traffic_stats.md) by [@yuhan6665](https://github.com/yuhan6665)
-Adapt traffic statistics and scripts compatible with Xray.
+Traffic statistics and scripts adapted for Xray.
diff --git a/docs/en/document/level-2/iptables_gid.md b/docs/en/document/level-2/iptables_gid.md
index 0bc73d10..f8fdb2ca 100644
--- a/docs/en/document/level-2/iptables_gid.md
+++ b/docs/en/document/level-2/iptables_gid.md
@@ -1,98 +1,97 @@
---
-title: Transparent proxy via GID
+title: GID Transparent Proxy
---
-# Transparent proxy to circumvent Xray traffic via GID
+# Transparent Proxy: Bypassing Xray Traffic via GID
-In the existing transparent proxy configuration(**[New V2Ray vernacular tutorial on transparent proxy](https://guide.v2fly.org/app/transparent_proxy.html)** 、 **[New V2Ray vernacular tutorial on transparent proxy (TProxy)](https://guide.v2fly.org/app/tproxy.html)** 、 **[Transparent proxy（TProxy）configuration tutorial](./tproxy.md)**)tutorials, the circumvention of Xray traffic is achieved by using mark. That is, mark outbound traffics and set up iptables rules which directly connect traffics corresponding to the mark, to circumvent the Xray traffic and prevent loop back.
+In existing `iptables` transparent proxy guides (**[New V2Ray Plain English Guide - Transparent Proxy](https://guide.v2fly.org/app/transparent_proxy.html)**, **[New V2Ray Plain English Guide - Transparent Proxy (TPROXY)](https://guide.v2fly.org/app/tproxy.html)**, **[Transparent Proxy (TProxy) Configuration Tutorial](./tproxy)**), the method used to bypass Xray traffic (to prevent routing loops) involves marking packets (`mark`). Specifically, marks are applied to Xray's outbound traffic, and `iptables` rules are set to direct traffic with corresponding marks to go out directly, thus bypassing the Xray proxy process.
-There are several problems with this method:
+There are several issues with this approach:
-1. **[Inexplicable traffic into PREROUTING chain](https://github.com/v2ray/v2ray-core/issues/2621)**
+1. **[Unexplained traffic entering the PREROUTING chain](https://github.com/v2ray/v2ray-core/issues/2621)**.
+2. Android systems have their own marking mechanism, making this solution unusable on Android.
-2. Android has its own mark mechanism and this solution is not available on Android
+The solution in this tutorial does not require setting marks. Theoretically, it offers higher performance and avoids the issues mentioned above.
-The solution in this tutorial does not require a mark setting and has a higher theoretical performance, as well as not having the problems mentioned above.
+## Concept
-## Ideas
+TProxy traffic can only be received by the root user (`uid==0`) or other users with `CAP_NET_ADMIN` privileges.
-TProxy traffic can only be received by users with root privileges (uid==0) or other users with CAP_NET_ADMIN privileges.
+`iptables` rules can route traffic based on UID (User ID) and GID (Group ID).
-The iptables rules can separate network traffic by uid (user id) and gid (user group id).
-Let Xray run on a user with uid==0 but gid!=0. Set the iptables rule to not proxy traffic for that gid to circumvent Xray traffic.
+By running Xray as a user with `uid==0` but `gid!=0`, we can set `iptables` rules to exclude traffic from that specific GID, thereby bypassing Xray traffic.
-## Configuration Procedure
+## Configuration Process
-### 1. Preliminary preparation
+### 1. Prerequisites
-**Android**
+**Android System**
-1. System has root privilege.
+1. System must be rooted.
+2. Install **[busybox](https://play.google.com/store/apps/details?id=stericson.busybox)**.
+3. Have a terminal capable of executing commands, such as `adb shell`, `termux`, etc.
-2. Install **[busybox](https://play.google.com/store/apps/details?id=stericson.busybox)**
+**Other Linux Systems**
-3. There is a terminal that can execute commands, you can use adb shell, termux etc.
+Requires dependencies: `sudo`, `iptables-mod-tproxy`, and `iptables-mod-extra`.
-**Other Linux system**
-
-Need sudo, iptables-tproxy module and iptables-extra module。
-
-Usually the system comes with these functions. If you are using openwrt, you will need to run the following command:
+Most systems come with these built-in. For OpenWrt, run:
```bash
opkg install sudo iptables-mod-tproxy iptables-mod-extra
```
-Also attached are some common dependencies for openwrt, the lack of which may prevent Xray from running
+Here are some common dependencies for OpenWrt. Missing them might prevent Xray from running:
```bash
opkg install libopenssl ca-certificates
```
-### 2. Add user (Android users please ignore this section)
+### 2. Add User (Skip for Android users)
-Android does not support managing users by modifying the /etc/passwd file, please ignore it and go straight to the next step.
+Android systems do not support managing users via the `/etc/passwd` file, so please ignore this and proceed to the next step.
```bash
grep -qw xray_tproxy /etc/passwd || echo "xray_tproxy:x:0:23333:::" >> /etc/passwd
```
-where xray_tproxy is the username, 0 is the uid and 23333 is the gid, the username and gid can be set by yourself, the uid must be 0.
-To check if the user was added successfully, run
+Here, `xray_tproxy` is the username, `0` is the UID, and `23333` is the GID. The username and GID can be customized, but the UID must be 0.
+To check if the user was added successfully, run:
```bash
sudo -u xray_tproxy id
```
-The result displayed should be uid 0 and gid 23333.
+The displayed result should show UID as 0 and GID as 23333.
-### 3. Configure and run Xray, and configure iptables rules
+### 3. Configure/Run Xray and Set iptables Rules
-In the existing transparent proxy configuration(**[New V2Ray vernacular tutorial on transparent proxy](https://guide.v2fly.org/app/transparent_proxy.html)** 、 **[New V2Ray vernacular tutorial on transparent proxy (TProxy)](https://guide.v2fly.org/app/tproxy.html)** 、 **[Transparent proxy（TProxy）configuration tutorial](./tproxy.md)**)tutorials, modify:
+Modify based on the existing `iptables` transparent proxy guides (**[New V2Ray Plain English Guide - Transparent Proxy](https://guide.v2fly.org/app/transparent_proxy.html)**, **[New V2Ray Plain English Guide - Transparent Proxy (TPROXY)](https://guide.v2fly.org/app/tproxy.html)**, **[Transparent Proxy (TProxy) Configuration Tutorial](./tproxy)**):
-1. Modify the json configuration file: remove mark-related content
+1. Modify the JSON configuration file to delete content related to `mark`.
+2. Modify `iptables` rules to delete content related to `mark`, and add the option `-m owner ! --gid-owner 23333` to the rule applied in the OUTPUT chain.
-2. Modify the iptables rule to remove the mark-related content and add the option at the OUTPUT chain application rule: `-m owner ! --gid-owner 23333`
+For example:
-e.g.:
+```bash
+iptables -t mangle -A OUTPUT -j XRAY_SELF
+```
-`iptables -t mangle -A OUTPUT -j XRAY_SELF`
+Change to:
-Change to
+```bash
+iptables -t mangle -A OUTPUT -m owner ! --gid-owner 23333 -j XRAY_SELF
+```
-`iptables -t mangle -A OUTPUT -m owner ! --gid-owner 23333 -j XRAY_SELF`
+1. Modify the way Xray is run so that it runs as a user with `uid=0` and `gid=23333`. Refer to [this section](#_3-configure-max-open-files-run-xray-client).
-1. Modify the way you run Xray so that it runs on a user with uid 0 and gid 23333, refer to [here](#_3-configure-and-run-xray-and-configure-iptables-rules).
+## Below is a complete configuration process for implementing global TProxy
-## Steps
+### 1. Complete the Prerequisites and User Addition steps above
-The following provides a complete configuration process for implementing the tproxy global proxy
+### 2. Prepare Xray Configuration File
-### 1. Finish **[Preliminary preparation](#_1-preliminary-preparation)** and **[Add user](#_2-add-user-android-users-please-ignore-this-section)**
-
-### 2. Preparing Xray profiles
-
-Configure Xray to listen to 12345 at dokodemo-door, turn on followRedirect and tproxy, no sniffing required:
+Configure Xray `dokodemo-door` to listen on port 12345, enable `followRedirect` and `tproxy`. Setting `sniffing` is not required:
```json
{
@@ -113,60 +112,60 @@ Configure Xray to listen to 12345 at dokodemo-door, turn on followRedirect and t
],
"outbounds": [
{
- // Your server configuration
+ Your Server Configuration
}
]
}
```
-### 3. Configuring the maximum number of open files and run the Xray client
+### 3. Configure Max Open Files & Run Xray Client
-About the maximum number of open files, see: **[too many open files issues](https://guide.v2fly.org/app/tproxy.html#解决-too-many-open-files-问题)**
+For issues regarding the maximum number of open files, see: **[Too many open files issue](https://guide.v2fly.org/app/tproxy.html#解决-too-many-open-files-问题)**.
-The current Xray server installed with the official script has the maximum number of open files automatically configured, so no further changes are required.
+Currently, Xray servers installed using the official script automatically configure the maximum open file limit, so no further modification is needed.
-**Android**
+**Android System**
```bash
ulimit -SHn 1000000
setuidgid 0:23333 "Command to run Xray"&
```
-**Other Linux system**
+**Other Linux Systems**
```bash
ulimit -SHn 1000000
sudo -u xray_tproxy "Command to run Xray"&
```
-e.g.:
+For example:
```bash
ulimit -SHn 1000000
sudo -u xray_tproxy xray -c /etc/xray/config.json &
```
-_The first command:_
+*First command:*
-Change the maximum number of open files, valid only for the current terminal and to be run every time before starting Xray, this command is to set the maximum number of open files for the client.
+Changes the maximum number of open files. It is only effective for the current terminal and must be run every time before starting Xray. This command sets the maximum file limit for the client.
-_The second command:_
+*Second command:*
-Run the Xray client as a user with uid 0 and gid not 0, followed by & for running in the background.
+Runs the Xray client as a user with `uid=0` and a non-zero `gid`. The `&` at the end indicates running in the background.
-**Check if the maximum number of open files is set successfully**
+**Check if Max Open Files was set successfully**
```bash
-cat /proc/"Xray's pid"/limits
+cat /proc/PID_OF_XRAY/limits
```
-Find max open files, which should be the value you set. Xray's pid can be obtained by running `ps` or `ps -aux` or `ps -a`
+Find the `max open files` item; it should match the value you set. You can get the PID by running `ps`, `ps -aux`, `ps -a`, or `pidof xray`.
-Both the server and client side should be checked.
+Check both the server and the client.
-### 4. Setting up iptables rules
+### 4. Set iptables Rules
-**Proxy ipv4**
+**Proxy IPv4**
```bash
ip rule add fwmark 1 table 100
@@ -174,31 +173,40 @@ ip route add local 0.0.0.0/0 dev lo table 100
# Proxy LAN devices
iptables -t mangle -N XRAY
-# "ipv4 segment where the gateway is located" is obtained by running the command "ip address | grep -w inet | awk '{print $2}'", usually there are multiple
-iptables -t mangle -A XRAY -d "first ipv4 segment where the gateway is located" -j RETURN
-iptables -t mangle -A XRAY -d "second ipv4 segment where the gateway is located" -j RETURN
+# "Gateway IPv4 subnet" is obtained by running "ip address | grep -w inet | awk '{print $2}'". There are usually multiple.
+iptables -t mangle -A XRAY -d Gateway_IPv4_Subnet_1 -j RETURN
+iptables -t mangle -A XRAY -d Gateway_IPv4_Subnet_2 -j RETURN
+...
-# If the gateway is used as the primary router, add this line, see: [Other considerations for transparent proxy of iptables](https://xtls.github.io/en/documents/level-2/transparent_proxy/transparent_proxy/#proxy-ipv6)
-# The "gateway LAN_IPv4 address segment", obtained by running the command "ip address | grep -w "inet" | awk '{print $2}'", is one of the results
-iptables -t mangle -A XRAY ! -s "gateway LAN_IPv4 address segment" -j RETURN
+# Direct connection for Multicast/Class E/Broadcast addresses
+iptables -t mangle -A XRAY -d 224.0.0.0/3 -j RETURN
-# Mark 1 for TCP and forward to port 12345
-# mark can only be set to 1 for the traffic to be accepted by the Xray dokodemo-door
+
+# If the gateway serves as the main router, add this line.
+# See: [https://xtls.github.io/documents/level-2/transparent_proxy/transparent_proxy.md#iptables透明代理的其它注意事项](https://xtls.github.io/documents/level-2/transparent_proxy/transparent_proxy.md#iptables透明代理的其它注意事项)
+# Gateway_LAN_IPv4_Subnet is one of the results from "ip address | grep -w "inet" | awk '{print $2}'".
+iptables -t mangle -A XRAY ! -s Gateway_LAN_IPv4_Subnet -j RETURN
+
+# Mark TCP packets with 1, forward to port 12345
+# Traffic is accepted by Xray dokodemo-door only if mark is set to 1
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
# Apply rules
iptables -t mangle -A PREROUTING -j XRAY
-# Proxy gateway itself
+# Proxy the Gateway itself
iptables -t mangle -N XRAY_MASK
-iptables -t mangle -A XRAY_MASK -d "the first ipv4 segment where the gateway is located" -j RETURN
-iptables -t mangle -A XRAY_MASK -d "the second ipv4 segment where the gateway is located" -j RETURN
-
+iptables -t mangle -A XRAY_MASK -m owner --gid-owner 23333 -j RETURN
+iptables -t mangle -A XRAY_MASK -d Gateway_IPv4_Subnet_1 -j RETURN
+iptables -t mangle -A XRAY_MASK -d Gateway_IPv4_Subnet_2 -j RETURN
+...
+iptables -t mangle -A XRAY_MASK -d 224.0.0.0/3 -j RETURN
iptables -t mangle -A XRAY_MASK -j MARK --set-mark 1
-iptables -t mangle -A OUTPUT -m owner ! --gid-owner 23333 ! -p icmp -j XRAY_MASK
+iptables -t mangle -A OUTPUT -p tcp -j XRAY_MASK
+iptables -t mangle -A OUTPUT -p udp -j XRAY_MASK
```
-**Proxy ipv6 (optional)**
+**Proxy IPv6 (Optional)**
```bash
ip -6 rule add fwmark 1 table 106
@@ -206,23 +214,27 @@ ip -6 route add local ::/0 dev lo table 106
# Proxy LAN devices
ip6tables -t mangle -N XRAY6
-# The "ipv6 segment where the gateway is located" is obtained by running the command "ip address | grep -w inet6 | awk '{print $2}'".
-ip6tables -t mangle -A XRAY6 -d "the first ipv6 segment where the gateway is located" -j RETURN
-ip6tables -t mangle -A XRAY6 -d "the second ipv6 segment where the gateway is located" -j RETURN
+# "Gateway IPv6 subnet" is obtained by running "ip address | grep -w inet6 | awk '{print $2}'".
+ip6tables -t mangle -A XRAY6 -d Gateway_IPv6_Subnet_1 -j RETURN
+ip6tables -t mangle -A XRAY6 -d Gateway_IPv6_Subnet_2 -j RETURN
+...
-# If the gateway is used as the primary router, add this line, see: [Other considerations for transparent proxy of iptables](https://xtls.github.io/en/documents/level-2/transparent_proxy/transparent_proxy/#proxy-ipv6)
-# The "gateway LAN_IPv6 address segment", obtained by running the command "ip address | grep -w "inet6" | awk '{print $2}'", is one of the results
-ip6tables -t mangle -A XRAY6 ! -s "gateway LAN_IPv6 address segment" -j RETURN
+# If the gateway serves as the main router, add this line.
+# See: [https://xtls.github.io/documents/level-2/transparent_proxy/transparent_proxy.md#iptables透明代理的其它注意事项](https://xtls.github.io/documents/level-2/transparent_proxy/transparent_proxy.md#iptables透明代理的其它注意事项)
+# Gateway_LAN_IPv6_Subnet is one of the results from "ip address | grep -w "inet6" | awk '{print $2}'".
+ip6tables -t mangle -A XRAY6 ! -s Gateway_LAN_IPv6_Subnet -j RETURN
ip6tables -t mangle -A XRAY6 -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
ip6tables -t mangle -A XRAY6 -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
ip6tables -t mangle -A PREROUTING -j XRAY6
-# Proxy gateway itself
+# Proxy the Gateway itself
ip6tables -t mangle -N XRAY6_MASK
-ip6tables -t mangle -A XRAY6_MASK -d "the first ipv6 segment where the gateway is located" -j RETURN
-ip6tables -t mangle -A XRAY6_MASK -d "the second ipv6 segment where the gateway is located" -j RETURN
-
+ip6tables -t mangle -A XRAY6_MASK -m owner --gid-owner 23333 -j RETURN
+ip6tables -t mangle -A XRAY6_MASK -d Gateway_IPv6_Subnet_1 -j RETURN
+ip6tables -t mangle -A XRAY6_MASK -d Gateway_IPv6_Subnet_2 -j RETURN
+...
ip6tables -t mangle -A XRAY6_MASK -j MARK --set-mark 1
-ip6tables -t mangle -A OUTPUT -m owner ! --gid-owner 23333 ! -p icmp -j XRAY6_MASK
+ip6tables -t mangle -A OUTPUT -p tcp -j XRAY6_MASK
+ip6tables -t mangle -A OUTPUT -p udp -j XRAY6_MASK
```
diff --git a/docs/en/document/level-2/nginx_or_haproxy_tls_tunnel.md b/docs/en/document/level-2/nginx_or_haproxy_tls_tunnel.md
index e03174d0..1edbb7a3 100644
--- a/docs/en/document/level-2/nginx_or_haproxy_tls_tunnel.md
+++ b/docs/en/document/level-2/nginx_or_haproxy_tls_tunnel.md
@@ -1,18 +1,18 @@
---
-title: Nginx 或 Haproxy 搭建 TLS 隧道隐藏指纹
+title: Using Nginx or HAProxy to Build TLS Tunnels to Hide Fingerprints
---
-Nginx 或 Haproxy 实现的 HTTPS 隧道、HTTP/2 over HTTPS 隧道、WebSocket over HTTP/2 over HTTPS 隧道、gRPC over HTTP/2 over HTTPS 隧道以及自签证书双端认证的 gRPC over HTTP/2 over HTTPS 隧道
+HTTPS tunnels, HTTP/2 over HTTPS tunnels, WebSocket over HTTP/2 over HTTPS tunnels, gRPC over HTTP/2 over HTTPS tunnels implemented via Nginx or HAProxy, and gRPC over HTTP/2 over HTTPS tunnels with self-signed certificate mutual authentication.
-# 客户端服务端 Nginx 构建 HTTPS 隧道隐藏指纹
+# Building HTTPS Tunnels with Nginx on Client & Server to Hide Fingerprints
-网路结构：
+Network Structure:
xray_client ---tcp--- nginx_client ---HTTPS--- nginx_sever ---tcp--- xray_server
-## 编译 nginx --with-stream
+## Compile Nginx --with-stream
-在客户端及服务端均编译
+Compile on both the client and the server.
`curl -O -L http://nginx.org/download/nginx-1.22.1.tar.gz`
@@ -20,45 +20,44 @@ xray_client ---tcp--- nginx_client ---HTTPS--- nginx_sever ---tcp--- xray_server
`cd nginx-1.22.1`
-`apt install gcc make` //编译依赖 gcc 以及 make
+`apt install gcc make` // Install compilation dependencies: gcc and make
-`./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_v2_module --with-stream --with-stream_ssl_module` //此步需要依赖一些库，根据报错安装相应 lib
+`./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_v2_module --with-stream --with-stream_ssl_module` // This step requires some libraries; install the corresponding libs based on any errors reported.
`make && make install`
-编译之后 nginx 文件夹位于 `/usr/local/nginx`
+After compilation, the nginx folder is located at `/usr/local/nginx`.
-## 配置 nginx
+## Configure Nginx
-编辑 nginx 配置文件 nginx.conf
+Edit the nginx configuration file `nginx.conf`.
`vim /usr/local/nginx/conf/nginx.conf`
-服务端加入如下配置
+Add the following configuration to the **Server**:
-服务器申请证书不再赘述，参考[白话文](../level-0/ch06-certificates.md)
+(I won't go into detail about applying for server certificates; refer to the [Plain Language Guide](../level-0/ch06-certificates.md)).
-```
+```nginx
stream {
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl_protocols TLSv1.3;
- ssl_certificate /path/to/cert/domain.crt; # crt 文件位置
- ssl_certificate_key /path/to/cert/domain.key; # key 文件位置
- proxy_pass unix:/dev/shm/vless.sock; # 使用 domain socket
+ ssl_certificate /path/to/cert/domain.crt; # Location of crt file
+ ssl_certificate_key /path/to/cert/domain.key; # Location of key file
+ proxy_pass unix:/dev/shm/vless.sock; # Use domain socket
}
}
```
-::: warning 注意
-
-stream 部分与 http 模块并列，客户端可删除 http 部分，服务端可删除或搭建网页伪装回落
+::: warning Note
+The `stream` section is parallel to the `http` module. On the client side, you can delete the `http` section. On the server side, you can delete it or set up a web page fallback for camouflage.
:::
-客户端加入如下配置
+Add the following configuration to the **Client**:
-```
+```nginx
stream {
server {
listen 6666;
@@ -66,19 +65,19 @@ stream {
proxy_ssl on;
proxy_ssl_protocols TLSv1.3;
proxy_ssl_server_name on;
- proxy_ssl_name yourdomain.domain; # 服务器域名
- proxy_pass ip:443; # 服务器 ip 形如 proxy_pass 6.6.6.6:443; 或 proxy_pass [2401:0:0::1]:443;
+ proxy_ssl_name yourdomain.domain; # Server domain name
+ proxy_pass ip:443; # Server IP, e.g., proxy_pass 6.6.6.6:443; or proxy_pass [2401:0:0::1]:443;
}
}
```
-在 `/etc/systemd/system` 文件夹中创建 `nginx.service` 文件
+Create the `nginx.service` file in the `/etc/systemd/system` directory.
`vim /etc/systemd/system/nginx.service`
-写入如下
+Write the following:
-```
+```ini
[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network-online.target remote-fs.target nss-lookup.target
@@ -96,13 +95,13 @@ PrivateTmp=true
WantedBy=multi-user.target
```
-加入开机自启
+Enable auto-start on boot:
`systemctl enable nginx`
-## xray 配置
+## Xray Configuration
-服务端 xray 配置
+**Server-side** Xray Configuration:
```json
{
@@ -138,7 +137,7 @@ WantedBy=multi-user.target
}
```
-客户端 xray 配置，此处以旁路由透明代理为例
+**Client-side** Xray Configuration (Taking transparent proxy on a side-router/gateway as an example):
```json
{
@@ -270,49 +269,49 @@ WantedBy=multi-user.target
}
```
-如果使用透明代理需要在 iptables 或 ip6tables 配置中加入
+If using transparent proxy, you need to add the following to the `iptables` or `ip6tables` configuration:
-```
-# 设置策略路由 v4
+```bash
+# Set policy routing v4
ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
-# 设置策略路由 v6
+# Set policy routing v6
ip -6 rule add fwmark 1 table 106
ip -6 route add local ::/0 dev lo table 106
-# VPS IP 直连
+# VPS IP Direct Connection
iptables -t mangle -A XRAY_MASK -d VSP_IPv4/32 -j RETURN
ip6tables -t mangle -A XRAY6_MASK -d VPS_IPv6/128 -j RETURN
```
-## 客户端及服务端启动服务
+## Start Services on Client & Server
`systemctl restart xray`
`systemctl restart nginx`
-## 结束
+## Conclusion
-# 双端 Haproxy 构建 HTTPS 隧道隐藏指纹
+# Building HTTPS Tunnels with Dual-End HAProxy to Hide Fingerprints
-安装 Haproxy
+Install HAProxy:
-`pacman -Su haproxy` 或 `apt install haproxy`
+`pacman -Su haproxy` or `apt install haproxy`
-Haproxy 处理 ssl 需要 openssl 支持，检查 openssl 版本，必要时安装或更新
+HAProxy requires OpenSSL support to handle SSL. Check the OpenSSL version and install or update it if necessary.
-## HTTPS 隧道
+## HTTPS Tunnel
-前述 Nginx HTTPS 隧道 Hproxy 同样可以简单做到
+The Nginx HTTPS tunnel described above can also be easily achieved with HAProxy.
-网路结构：
+Network Structure:
xray_client ---tcp--- haproxy_client ---HTTPS--- haproxy_sever ---tcp--- xray_server
-### haproxy_client 配置 (运行前去掉注释)
+### haproxy_client Configuration (Uncomment before running)
-```
+```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -322,7 +321,7 @@ global
group root
daemon
- # 隧道强制使用 TLS 1.3
+ # Force tunnel to use TLS 1.3
ssl-default-server-options ssl-min-ver TLSv1.3
defaults
@@ -333,17 +332,20 @@ defaults
timeout server 300s
frontend xray
- bind 127.0.0.1:6666 # 监听本机 6666 端口
+ bind 127.0.0.1:6666 # Listen on local port 6666
default_backend tunnel
backend tunnel
- server tunnel www.example.com:443 ssl verify none sni req.hdr(host) alpn h2,http/1.1
- # 域名或 IP 均可以，若填域名建议在 hosts 中指定 IP 降低解析时间；alpn 与服务器协商，服务器端为 alpn h2,http1.1 时，客户端指定为 h2 则隧道为 HTTP2 方式连接，指定为 http1.1 为 HTTP 方式，双端均写优先 h2
+ server tunnel [www.example.com:443](https://www.example.com:443) ssl verify none sni req.hdr(host) alpn h2,http/1.1
+ # Domain or IP are both fine. If using a domain, it's recommended to specify the IP in hosts to reduce resolution time.
+ # alpn negotiates with the server. If the server side is alpn h2,http1.1:
+ # Specifying h2 on the client means the tunnel connects via HTTP2.
+ # Specifying http1.1 means HTTP. It is recommended to prioritize h2 on both ends.
```
-### haproxy_server 配置 (运行前去掉注释)
+### haproxy_server Configuration (Uncomment before running)
-```
+```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -353,7 +355,7 @@ global
group root
daemon
- # 指定安全套件并指定 ssl 版本最低 1.2 增加真实性
+ # Specify cipher suites and set minimum SSL version to 1.2 to increase authenticity
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2
@@ -366,40 +368,40 @@ defaults
timeout server 300s
frontend tls-in
- bind :::443 ssl crt /path/to/pem alpn h2,http/1.1 # haproxy 使用 pem 进行 ssl 解密，pem 由 cat www.example.com.crt www.example.com.key > www.example.com.pem 获得
+ bind :::443 ssl crt /path/to/pem alpn h2,http/1.1 # haproxy uses pem for ssl decryption. pem is obtained by: cat [www.example.com](https://www.example.com).crt [www.example.com](https://www.example.com).key > [www.example.com](https://www.example.com).pem
default_backend xray
tcp-request inspect-delay 5s
tcp-request content accept if HTTP
use_backend web if HTTP
backend xray
- server xray /dev/shm/vless.sock # 支持 abstract 格式： "abns@vless.sock" ；loopback 方式：127.0.0.1:6666
+ server xray /dev/shm/vless.sock # Supports abstract format: "abns@vless.sock"; loopback method: 127.0.0.1:6666
backend web
- server web /dev/shm/h1h2c.sock # 回落到网页
+ server web /dev/shm/h1h2c.sock # Fallback to web page
```
-### xray 配置
+### Xray Configuration
-同上 nginx 部分：最简单的 TCP 配置，可搭配任意协议，建议使用 VLESS+TCP 无需多余加密，参考文档或其他示例
+Same as the Nginx section above: Simplest TCP configuration. It works with any protocol. It is recommended to use VLESS+TCP without extra encryption. Refer to the documentation or other examples.
## WebSocket over HTTP/2
-Haproxy 支持 HTTP/2 的 h2c 进站及出站
+HAProxy supports inbound and outbound HTTP/2 h2c.
-然而援引 xray 文档 HTTP/2 的说明
+However, quoting the Xray documentation on HTTP/2:
-“由 HTTP/2 的建议，客户端和服务器必须同时开启 TLS 才可以正常使用这个传输方式。...... 当前版本的 HTTP/2 的传输方式并不强制要求入站（服务端）有 TLS 配置。”
+"According to HTTP/2 recommendations, both the client and server must enable TLS to use this transport method normally... The current version of HTTP/2 transport does not enforce TLS configuration for inbound (server side)."
-即入站可以使用 h2c，出站并不支持 h2c。因此无法使用 xray_client ---h2c--- haproxy_client ---HTTP/2+TLS--- haproxy_sever ---h2c--- xray_server
+This means inbound can use h2c, but outbound does not support h2c. Therefore, you cannot use: `xray_client ---h2c--- haproxy_client ---HTTP/2+TLS--- haproxy_sever ---h2c--- xray_server`.
-但是可以通过 ws 偷个鸡，Haproxy 支持 ws over HTTP/2
+However, we can use a trick with WS (WebSocket). HAProxy supports WS over HTTP/2.
-则网络结构：xray_client ---ws--- haproxy_client ---ws over HTTP/2 over HTTPS--- haproxy_sever ---ws--- xray_server
+So the network structure is: `xray_client ---ws--- haproxy_client ---ws over HTTP/2 over HTTPS--- haproxy_sever ---ws--- xray_server`.
-### haproxy_client 配置
+### haproxy_client Configuration
-```
+```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -409,9 +411,9 @@ global
group root
daemon
- # 调整 HTTP/2 的性能，当遇到 HTTP/2 性能问题时都可以设置相关项，更多设置见 Haproxy 文档 tune.h2 部分 https://docs.haproxy.org/2.7/configuration.html
- tune.h2.initial-window-size 536870912 # 初始窗口大小，建议设置，默认值 65536 单位 byte，此值在突发大流量情况下需要一定加载时间，建议根据网速调整
- tune.h2.max-concurrent-streams 512 # 复用线路数，可根据情况设置，默认值 100，一般不用设置(官方不建议改动)
+ # Adjust HTTP/2 performance. Set relevant items when encountering HTTP/2 performance issues. For more settings, see the tune.h2 section of the Haproxy documentation [https://docs.haproxy.org/2.7/configuration.html](https://docs.haproxy.org/2.7/configuration.html)
+ tune.h2.initial-window-size 536870912 # Initial window size. Recommended to set. Default is 65536 bytes. Larger values may require some load time during traffic bursts. Adjust based on network speed.
+ tune.h2.max-concurrent-streams 512 # Number of multiplexed streams. Set as needed. Default is 100. Generally no need to set (official recommendation is not to change).
ssl-default-server-options ssl-min-ver TLSv1.3
@@ -427,13 +429,13 @@ frontend xray
default_backend tunnel
backend tunnel
- server tunnel www.example.com:443 ssl verify none sni req.hdr(host) ws h2 alpn h2
+ server tunnel [www.example.com:443](https://www.example.com:443) ssl verify none sni req.hdr(host) ws h2 alpn h2
# ws over HTTP/2
```
-### haproxy_server 配置
+### haproxy_server Configuration
-```
+```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -443,7 +445,7 @@ global
group root
daemon
- # 客户端配置即可，服务端配置也无妨
+ # Configured on client is enough, configuring on server is also fine
tune.h2.initial-window-size 536870912
tune.h2.max-concurrent-streams 512
@@ -465,7 +467,7 @@ frontend tls-in
use_backend server2 if { ssl_fc_alpn -i h2 } { path_beg /path2 }
use_backend server3 if { ssl_fc_alpn -i h2 } { path_beg /path3 }
default_backend web
- # haproxy 使用 http 模式可以根据 path 分流
+ # haproxy using http mode can route based on path
backend xray
server xray abns@vless.sock ws h1
@@ -483,19 +485,19 @@ backend web
server web /dev/shm/h1h2c.sock
```
-### xray 配置
+### Xray Configuration
-简单的 websocket 配置即可，无需 TLS， 配置见 xray 文档示例，配置 "path" 可以用于服务端 haproxy 分流（客户端有分流需求同样可以通过客户端 haproxy 进行，原理类似，参考服务端的 path 分流配置）
+A simple WebSocket configuration is sufficient. No TLS required. See Xray documentation examples. Configuration of "path" can be used for server-side HAProxy routing (if the client has routing needs, it can also be done via client-side HAProxy; the principle is similar, refer to the server-side path routing configuration).
## gRPC over HTTP/2
-虽然双端的 h2c 不行，但是 gRPC 不要求必须 TLS，直接冲
+Although dual-end h2c doesn't work, gRPC does not mandate TLS, so we can go straight ahead.
-网络结构：xray_client ---gRPC h2c--- haproxy_client ---gRPC over HTTP/2 over HTTPS--- haproxy_sever ---gRPC h2c--- xray_server
+Network Structure: `xray_client ---gRPC h2c--- haproxy_client ---gRPC over HTTP/2 over HTTPS--- haproxy_sever ---gRPC h2c--- xray_server`
-### haproxy_client 配置
+### haproxy_client Configuration
-```
+```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -518,16 +520,16 @@ defaults
timeout server 300s
frontend xray
- bind 127.0.0.1:6666 proto h2 # 指定 proto h2 使用 h2c
+ bind 127.0.0.1:6666 proto h2 # Specify proto h2 to use h2c
default_backend tunnel
backend tunnel
- server tunnel www.example.com:443 ssl verify none sni req.hdr(host) alpn h2
+ server tunnel [www.example.com:443](https://www.example.com:443) ssl verify none sni req.hdr(host) alpn h2
```
-### haproxy_server 配置
+### haproxy_server Configuration
-```
+```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -553,7 +555,7 @@ defaults
frontend tls-in
bind :::443 ssl crt /path/to/pem alpn h2,http/1.1
- use_backend xray if { ssl_fc_alpn -i h2 } { path_beg /tunnel } # xray gRPC 中配置的 "serviceName" 在 harpoxy 中可以使用 path 进行分流，为方便使用 "multiMode"，使用 path_beg 参数匹配路径
+ use_backend xray if { ssl_fc_alpn -i h2 } { path_beg /tunnel } # The "serviceName" configured in xray gRPC can be used for routing in haproxy via path. For convenience when using "multiMode", use the path_beg parameter to match the path.
use_backend server1 if { ssl_fc_alpn -i h2 } { path_beg /path1 }
use_backend server2 if { ssl_fc_alpn -i h2 } { path_beg /path2 }
use_backend server3 if { ssl_fc_alpn -i h2 } { path_beg /path3 }
@@ -575,27 +577,27 @@ backend web
server web /dev/shm/h1h2c.sock
```
-### xray 配置
+### Xray Configuration
-简单的 gRPC 配置，无需 TLS，配置见文档，配置的 serviceName 可用于分流。
+Simple gRPC configuration, no TLS needed. See documentation for configuration. The configured `serviceName` can be used for routing.
-# Haproxy 使用自签证书进行双端认证（gRPC 示例）
+# HAProxy Using Self-Signed Certificates for Mutual Authentication (gRPC Example)
-这里使用自签证书双端认证加强隧道安全性（但会牺牲一点延迟，不过使用 gRPC 后感知不强），而服务端同时处理信任的证书和自签名证书，并据此分流伪装网站和隧道流量
+Here, we use self-signed certificates with mutual authentication (mTLS) to strengthen tunnel security (at the cost of a little latency, though not very noticeable with gRPC). The server handles both trusted certificates and self-signed certificates simultaneously, and routes traffic for the camouflage site and tunnel traffic accordingly.
-其中 www.example.com 为伪装站信任证书（如白话文中申请的证书）
+Where `www.example.com` is the trusted certificate for the camouflage site (like certificates applied for in the Plain Language Guide).
-tunnel.example.com 为自签证书网址，自签证书可以参考 https://learn.microsoft.com/zh-cn/azure/application-gateway/self-signed-certificates
+`tunnel.example.com` is the URL for the self-signed certificate. For self-signed certificates, refer to: 
-### 方法二
+### Method 2
-局域网设备上网的第二种方式，是在路由器上进行网关设置，这种方法对于连接到此路由器的设备无需做任何设置即可科学上网，但注意有些路由器不支持 ipv6 的网关设置，有 ipv6 需求的设备仍需在所需设备上单独手动配置 ipv6 相关设置参考方法一。
+The second way for LAN devices to access the Internet is to configure the gateway on the router. With this method, devices connected to this router can access the scientific internet (bypass firewall) without any configuration. However, note that some routers do not support IPv6 gateway configuration. Devices requiring IPv6 still need to manually configure IPv6-related settings on the specific device (refer to Method 1).
## Finally
-按照以上方法设置后设备即可双栈访问，进入测试网站比如 https://ipv6-test.com/ 可以看到如下结果 (需要代理此网站才能看到如下结果)
+After setting up according to the above methods, the device can access via dual-stack. Entering a test website like 
-## 写在最后
+## Closing Thoughts
-如今 ipv6 并未完全普及，我们日常访问的流量 99%仍为 ipv4 流量；很多 VPS 商家虽然提供 ipv6 地址，但线路优化非常垃圾，甚至处于不可用状态，为何要加入 ipV6 的设置？
+Nowadays, IPv6 is not yet fully popularized. 99% of our daily access traffic is still IPv4 traffic. Although many VPS providers offer IPv6 addresses, the route optimization is often garbage, or even in an unusable state. So why add IPv6 settings?
-可以看到目前 ipv6 处于很尴尬的境地，各种设备对于 ipv6 的支持很烂，但是都在逐步完善，同时 Windows 系统对于 ipv6 的优先级也在提高，很多浏览器也会优先进行 ipv6 的解析以及访问，很多网站也开始默认使用 ipv6 进行访问（比如 Netflix, 如果没有配置 ipv6, 浏览器打开 Netflix 会显示 Not Available 是因为没有代理 Netflix 的 ipv6 请求，当然可以选择禁用 Windows 的 ipv6，但支持 ipv6 的 pt 站就无法使用）
+It can be seen that IPv6 is currently in an awkward position. Support for IPv6 on various devices is poor, but it is gradually improving. At the same time, the priority of IPv6 in Windows systems is also increasing. Many browsers will also prioritize IPv6 resolution and access. Many websites have also started to use IPv6 for access by default (such as Netflix; if IPv6 is not configured, opening Netflix in the browser will show "Not Available" because the IPv6 request for Netflix is not proxied. Of course, you can choose to disable IPv6 in Windows, but PT sites that support IPv6 will not be usable).
-这种情况下 ipv4 无法完全胜任网络冲浪的需求，即使是那 1%的流量，遇到了也会让人头疼不已。
+In this case, IPv4 cannot fully meet the needs of web surfing. Even if it is only that 1% of traffic, encountering it can be a headache.
-而可以预见 ipv6 也会逐步与 ipv4 分庭抗礼，所以有必要加入 ipv6 的设置。
+And it is foreseeable that IPv6 will gradually stand up to IPv4, so it is necessary to add IPv6 settings.
diff --git a/docs/en/document/level-2/traffic_stats.md b/docs/en/document/level-2/traffic_stats.md
index 9a22bde0..6b112572 100644
--- a/docs/en/document/level-2/traffic_stats.md
+++ b/docs/en/document/level-2/traffic_stats.md
@@ -1,23 +1,23 @@
---
-title: 流量统计
+title: Traffic Statistics
---
-# 流量统计配置教程
+# Traffic Statistics Configuration Tutorial
-请熟悉[流量统计 白话文教程](https://guide.v2fly.org/advanced/traffic.html)，本文在其基础上适配了 Xray（1.5.9+）。
+Please familiarize yourself with the [Traffic Statistics Plain Language Guide](https://guide.v2fly.org/advanced/traffic.html). This article adapts those concepts for Xray (1.5.9+).
-## 查看流量信息
+## Viewing Traffic Information
-配置方法与 v2fly 一致。
-查看流量信息是 xray 命令行的其中一个功能。配置内设置的 api dokodemo-door 端口，即为 `--server` 参数的端口。
+The configuration method is consistent with v2fly.
+Viewing traffic information is one of the features of the xray command line. The `api dokodemo-door` port set in the configuration corresponds to the port for the `--server` parameter.
```bash
-xray api statsquery --server=127.0.0.1:10085 #查看所有流量
-xray help api statsquery #statsquery 查询匹配的记录
-xray help api stats #stats 查询一个记录
+xray api statsquery --server=127.0.0.1:10085 # View all traffic statistics
+xray help api statsquery # statsquery queries matching records
+xray help api stats # stats queries a single record
```
-输出例子：
+Output example:
```json
{
@@ -58,9 +58,9 @@ xray help api stats #stats 查询一个记录
}
```
-## 流量信息的处理
+## Processing Traffic Information
-把以下脚本保存到 `traffic.sh`，注意使用 `chmod 755 traffic.sh` 授予执行权限。注意调整修改 `_APISERVER` 一行的连接具体的端口参数。
+Save the following script to `traffic.sh`, and remember to use `chmod 755 traffic.sh` to grant execution permissions. Pay attention to adjusting the specific port parameter in the `_APISERVER` line.
```bash
#!/bin/bash
diff --git a/docs/en/document/level-2/transparent_proxy/transparent_proxy.md b/docs/en/document/level-2/transparent_proxy/transparent_proxy.md
index 2d5d0624..d2997cdd 100644
--- a/docs/en/document/level-2/transparent_proxy/transparent_proxy.md
+++ b/docs/en/document/level-2/transparent_proxy/transparent_proxy.md
@@ -1,104 +1,107 @@
-# 透明代理入门
+# Introduction to Transparent Proxy
-## 什么是透明代理
+## What is a Transparent Proxy?
-透明代理简单地说就是不让被代理的设备感觉到自己被代理了。简单地说就是，被代理的设备上不需要运行任何代理软件(比如 Xray、V2RayNG 等)，当你连接上网络时，你的设备已经被代理了。
+Simply put, a transparent proxy means that the proxied device does not realize it is being proxied. In other words, no proxy software (such as Xray, V2RayNG, etc.) needs to be run on the proxied device itself. When you connect to the network, your device is automatically proxied.
-这也意味着，代理的软件运行在别的地方，比如运行在路由器中，通过路由器上网的设备就自动被代理了。
+This also implies that the proxy software is running elsewhere, for example, on a router. Devices accessing the Internet through this router are automatically proxied.
-## 透明代理的实现
+## Implementation of Transparent Proxy
-透明代理的实现目前主要有两种方式：
+There are two main ways to implement a transparent proxy:
### tun2socks
-可用 Windows/Linux(包括安卓)实现。因为实现过程比较简单，很少有教程，我这里简单描述一下。
+This can be implemented on Windows/Linux (including Android). Since the implementation process is relatively simple, there are few tutorials available. I will briefly describe it here.
**Windows**
-1. 安装 **[Netch](https://github.com/NetchX/Netch/releases)** ，使用模式`[3] [TUN/TAP] 绕过局域网`启动。
+1. Install **[Netch](https://github.com/NetchX/Netch/releases)** and start it using the mode `[3] [TUN/TAP] Bypass LAN`.
-2. 开启热点
+2. Enable the Mobile Hotspot.
-3. 打开`控制面板`->`网络和 Internet`->`网络和共享中心`->`更改适配器设置`，找到`TAP-Windows Adapter`和`Microsoft Wi-Fi Direct Virtual Adapter`。
+3. Open `Control Panel` -> `Network and Internet` -> `Network and Sharing Center` -> `Change adapter settings`. Find `TAP-Windows Adapter` and `Microsoft Wi-Fi Direct Virtual Adapter`.
-4. 鼠标右键点击`TAP-Windows Adapter`，`属性`->`共享`，勾选`允许其他网络用户通过此计算机的 Internet 连接来连接`，在`家庭网络连接`中选择`Microsoft Wi-Fi Direct Virtual Adapter`的那个网络连接，点击确定。
+4. Right-click on `TAP-Windows Adapter`, select `Properties` -> `Sharing`. Check `Allow other network users to connect through this computer's Internet connection`. Under `Home networking connection`, select the network connection corresponding to the `Microsoft Wi-Fi Direct Virtual Adapter`, and click OK.
**Android**
-1. 配置连接 V2RayNG
+1. Configure and connect V2RayNG.
-2. 开启热点
+2. Enable Hotspot.
-3. 热点设置 -> 允许热点使用 VPN(部分安卓系统可能没有这个选项)
+3. Hotspot Settings -> Allow hotspot to use VPN (some Android systems may not have this option).
### iptables/nftables
-iptables 与 nftables 实现透明代理的原理相同，下文统一使用 iptables。
+The principle of implementing a transparent proxy with iptables and nftables is the same. The text below will unify the description using iptables.
-基于 iptables 的透明代理实现只能用于 Linux 系统(包括 openwrt/安卓)。由于其比 tun2socks 更高效率以及适合在路由器中配置而广泛使用。
+Transparent proxy implementation based on iptables can only be used on Linux systems (including OpenWrt/Android). It is widely used because it is more efficient than tun2socks and is suitable for configuration in routers.
-现存的三篇白话文透明代理教程其实讲的都是基于这种方案的透明代理实现，它们是： **[新 V2Ray 白话文指南-透明代理](https://guide.v2fly.org/app/transparent_proxy.html)** 、 **[新 V2Ray 白话文指南-透明代理(TPROXY)](https://guide.v2fly.org/app/tproxy.html)** 、 **[透明代理（TProxy）配置教程](../tproxy.md)** 。其中第一篇是基于 iptables-redirect 模式，已经过时了，不建议使用，仅供参考。第二篇和第三篇讲的都是基于 iptables-tproxy 模式的透明代理实现。
+The three existing "Plain Language" transparent proxy tutorials are actually all based on this scheme. They are: **[New V2Ray Plain Guide - Transparent Proxy](https://guide.v2fly.org/app/transparent_proxy.html)**, **[New V2Ray Plain Guide - Transparent Proxy (TPROXY)](https://guide.v2fly.org/app/tproxy.html)**, and **[Transparent Proxy (TProxy) Configuration Tutorial](../tproxy.md)**. The first one is based on the iptables-redirect mode, which is obsolete and not recommended (for reference only). The second and third ones discuss transparent proxy implementation based on the iptables-tproxy mode.
-## iptables 实现透明代理原理
+## Principle of iptables-based Transparent Proxy
-Linux 使用`Netfilter`来管理网络，`Netfilter`模型如下：
+Linux uses `Netfilter` to manage the network. The `Netfilter` model is as follows:
-**假设使用路由器作为网关(即我们平时的上网方式)，那么：**
+**Assuming a router is used as the gateway (which is our usual way of accessing the Internet):**
-局域网设备通过路由器访问互联网的流量方向：
+Traffic direction for LAN devices accessing the Internet via the router:
-`PREROUTING链->FORWARD链->POSTINGROUTING链`
+`PREROUTING Chain -> FORWARD Chain -> POSTROUTING Chain`
-局域网设备访问路由器的流量(如登陆路由器 web 管理界面/ssh 连接路由器/访问路由器的 dns 服务器等)方向：
+Traffic direction for LAN devices accessing the router itself (e.g., logging into the router web UI / SSH connection to router / accessing the router's DNS server):
-`PREROUTING链->INPUT链->网关本机`
+`PREROUTING Chain -> INPUT Chain -> Gateway Local Process`
-路由器访问互联网的流量方向：
+Traffic direction for the router accessing the Internet:
-`网关本机->OUTPUT链->POSTINGROUTING链`
+`Gateway Local Process -> OUTPUT Chain -> POSTROUTING Chain`
-**通过使用 iptables 操控`PREROUTING链`和`OUTPUT链`的流量走向，转发到 Xray，就可以代理局域网设备和网关本机。**
+**By using iptables to manipulate the traffic flow in the `PREROUTING Chain` and `OUTPUT Chain` and forwarding it to Xray, we can proxy both LAN devices and the gateway itself.**
-## 透明代理难在哪里
+## Where is the Difficulty?
-透明代理的难点就在于路由，所谓路由，就是区分哪些流量是直连的，哪些该被代理，所以我个人认为叫做**分流**更加合适。
+The difficulty of transparent proxy lies in routing. Routing essentially means distinguishing which traffic should be direct and which should be proxied. Therefore, I personally think calling it **Traffic Splitting** is more appropriate.
-我们可以把路由由易到难分为以下几个阶段：
+We can divide routing into the following stages, from easy to difficult:
-1. 代理全部请求
+1. Proxy all requests.
-2. 本地局域网 IP/组播 IP 请求直连，其它请求代理
+2. Direct connection for local LAN IPs/Multicast IPs; proxy other requests.
-3. 在 2 的基础上直连 Xray 发起的连接请求
+3. Based on 2, direct connection for connection requests initiated by Xray itself.
-4. 在 3 的基础上直连指向中国大陆 IP 的连接请求，并对国内外域名选择国内外 DNS 服务器解析。
+4. Based on 3, direct connection for requests pointing to Mainland China IPs, and selecting domestic/foreign DNS servers for parsing domestic/foreign domains respectively.
-上面说的三篇教程，都是在第四阶段。所以新手直接阅读可能显得有点难懂。
+The three tutorials mentioned above are all at the fourth stage. Therefore, it might seem a bit difficult for beginners to read directly.
-## 从零开始一步步实现基于 iptables-tproxy 的透明代理
+## Implementing iptables-tproxy Transparent Proxy Step by Step from Scratch
-### 在开始之前，你需要有一定的基础知识：
+### Before you start, you need some basic knowledge
-1. 大概知道什么是 TCP/IP 协议、域名和 DNS 服务器
+1. Roughly know what TCP/IP protocol, domain names, and DNS servers are.
-2. 知道什么是 WAN 口，LAN 口，LAN_IP，WAN_IP 以及 DHCP 服务器。对于旁路由，只有一个网口，这里称其为 LAN 口
+2. Know what WAN port, LAN port, LAN_IP, WAN_IP, and DHCP server are. For a "Side Router" (single-arm router), there is only one network port, which we call the LAN port here.
-3. 对 Linux 系统有最基础的了解(知道怎么运行命令)
+3. Have a basic understanding of the Linux system (know how to run commands).
-4. 能够手写客户端 json 文件配置，至少要能看懂
+4. Be able to hand-write client JSON configuration files, or at least understand them.
-### 前期准备工作
+### Preparation Work
-**1. 准备一个运行 Linux 系统的网关**
+::: warning
+Before starting operations, remember to use `sysctl -w net.ipv4.ip_forward=1` to enable Linux IPv4 packet forwarding.
+:::
+**1. Prepare a gateway running a Linux system**
-比如，刷了 OpenWRT 的路由器
+For example, a router flashed with OpenWrt.
-**2. 在网关(路由器)准备好 Xray 可执行文件以及配置文件**
+**2. Prepare the Xray executable and configuration file on the gateway (router)**
-配置文件监听 12345 端口，开启 tproxy：
+The configuration file should listen on port 12345 and enable tproxy:
```json
{
@@ -122,19 +125,23 @@ Linux 使用`Netfilter`来管理网络，`Netfilter`模型如下：
],
"outbounds": [
{
- 你的服务器配置
+ Your_Server_Configuration
}
]
}
```
-我们由易到难，不写 routing，只写一个 inbound 一个 outbound。
+Moving from easy to difficult, we won't write `routing` for now, just one `inbound` and one `outbound`.
-### 首先，我们先试试做到第一阶段
+### First, let's try to achieve Stage 1
-将所有`PREROUTING链`的流量，都转发到 Xray 中。
+::: warning
+If you cannot accept that your machine needs to be rebooted, it is best to start a virtual machine for practice first.
+:::
-运行 Xray，执行以下指令：
+Forward all traffic from the `PREROUTING Chain` to Xray.
+
+Run Xray, and execute the following commands:
```bash
ip rule add fwmark 1 table 100
@@ -145,43 +152,43 @@ iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A PREROUTING -j XRAY
```
-当你输入完之后，如果你是使用 ssh 连接到网关上的，你会发现 ssh 的连接断开了(不用紧张，断电重启即可恢复)，并且透明代理无法上网；如果你是的网关是虚拟机，你会发现网关本身也无法上网，并且 Xray 日志 access_log 中出现许多源地址为目标地址，目标地址为 WAN_IP 的请求。
+After entering these commands, if you are connected to the gateway via SSH, you will find that the SSH connection is disconnected (don't panic, a power cycle will restore it), and the transparent proxy cannot access the Internet. If your gateway is a virtual machine, you will find that the gateway itself cannot access the Internet, and many requests with the source address as the destination address and the destination address as the WAN_IP appear in the Xray `access_log`.
-理论上网关本机访问公网只会经过`OUTPUT链`和`POSTROUTING链`，为什么操控`PREROUTING链`会导致网关无法上网呢？这是因为网络通讯往往是双向的，虽然网关访问公网 IP 不需要经过`PREROUTING链`，但被访问的服务器向网关返回信息时要经过`PREROUTING链`，且这部分被转发到 Xray 了，因此出现了日志中的反向请求。
+Theoretically, the gateway's local access to the public network should only pass through the `OUTPUT Chain` and `POSTROUTING Chain`. Why does manipulating the `PREROUTING Chain` cause the gateway to lose Internet access? This is because network communication is often bidirectional. Although the gateway does not need to pass through the `PREROUTING Chain` to access a public IP, the information returned by the accessed server to the gateway must pass through the `PREROUTING Chain`. Since this part is forwarded to Xray, the reverse requests appear in the log.
-我们修改一下规则，源 IP 不是来自局域网的则返回。重启网关，运行 Xray，执行以下指令：
+Let's modify the rules to return (skip Xray) if the source IP is not from the LAN. Reboot the gateway, run Xray, and execute the following commands:
```bash
ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N XRAY
-# "网关LAN_IP地址段" 通过运行命令"ip address | grep -w "inet" | awk '{print $2}'"获得，是其中的一个
-iptables -t mangle -A XRAY ! -s 网关LAN_IP地址段 -j RETURN
+# "Gateway_LAN_IP_Range" can be obtained by running "ip address | grep -w "inet" | awk '{print $2}'". Pick the correct one.
+iptables -t mangle -A XRAY ! -s Gateway_LAN_IP_Range -j RETURN
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A PREROUTING -j XRAY
```
-然后你会发现，虽然 ssh 连接断开了，但是透明代理已经可用了。只要我们修改系统 dns 为公共 dns，就能正常上网了(因为现在网关访问不了，所以 dns 设置为网关是不行的)。
+Then you will find that although the SSH connection is disconnected, the transparent proxy is now available. As long as we change the system DNS to a public DNS, we can surf the Internet normally (because the gateway itself cannot be accessed now, setting the DNS to the gateway won't work).
-至此，第一阶段就完成了。之所以无法访问网关，是因为代理规则代理了全部流量，包括访问网关的流量。试想在 VPS 上访问你本地的网关，肯定是访问不了的，所以我们要对这部分流量直连，请看第二阶段：
+At this point, Stage 1 is complete. The reason the gateway cannot be accessed is that the proxy rules cover *all* traffic, including traffic accessing the gateway. Imagine trying to access your local gateway on a VPS; it certainly won't work. So, we need to make this part of the traffic direct. Please see Stage 2.
-### 第二阶段
+### Stage 2
-重启网关，运行 Xray，执行以下指令：
+Reboot the gateway, run Xray, and execute the following commands:
```bash
ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N XRAY
-# 所有目标地址在网关所在网段的请求直连
-# 通过运行命令"ip address | grep -w "inet" | awk '{print $2}'"获得，一般来说有多个
-iptables -t mangle -A XRAY -d 网关所在网段1 -j RETURN
-iptables -t mangle -A XRAY -d 网关所在网段2 -j RETURN
+# Direct connection for all requests where the destination address is in the gateway's subnet
+# Obtained via "ip address | grep -w "inet" | awk '{print $2}'". Generally, there are multiple.
+iptables -t mangle -A XRAY -d Gateway_Subnet_1 -j RETURN
+iptables -t mangle -A XRAY -d Gateway_Subnet_2 -j RETURN
...
-# 目标地址为组播IP/E类地址/广播IP的请求直连
+# Direct connection for Multicast IPs / Class E addresses / Broadcast IPs
iptables -t mangle -A XRAY -d 224.0.0.0/3 -j RETURN
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
@@ -189,86 +196,93 @@ iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A PREROUTING -j XRAY
```
-使用这条规则后，上一条规则`iptables -t mangle -A XRAY ! -s 网关LAN_IP地址段 -j RETURN`便成为了多余规则，可以删去。
+After using this rule, the previous rule `iptables -t mangle -A XRAY ! -s Gateway_LAN_IP_Range -j RETURN` becomes redundant and can be removed.
-至此，第二阶段完成。网关已经可以访问，ssh 不会断开。
+At this point, Stage 2 is complete. The gateway is accessible, and SSH will not disconnect.
-### 第三阶段
+### Stage 3
-我们平时用的 DNS 一般来自路由器，但这个 iptables 规则只代理了局域网中的设备，却没有代理网关本机，这样返回的 DNS 查询结果可能是错误的或者污染的。
+The DNS we usually use generally comes from the router, but these iptables rules only proxy devices in the LAN and do not proxy the gateway itself. Thus, the returned DNS query results might be incorrect or polluted.
-iptables-tproxy 不支持对`OUTPUT链`操作，但是`Netfilter`有个特性，在`OUTPUT链`给包打标记为`1`后相应的包会重路由到`PREROUTING链`上。所以我们就给网关本机需要代理的请求在`OUTPUT链`上标记`1`即可。
-
-如果要代理网关本机发出的的全部请求，就会引入一个问题，Xray 运行在网关，Xray 向代理服务端发送请求，这个请求又被代理了，就形成了回环。
-
-因此要代理网关本机，就要避免回环发生，即代理规则中规避 Xray 请求的流量。
-
-**常见的方法有三种：**
-
-1. 直连目标地址为 VPS 的流量
-
-重启网关，运行 Xray，执行以下指令：
+`iptables-tproxy` does not support operations on the `OUTPUT Chain`, but we can reroute packets from the `OUTPUT Chain` to the `PREROUTING Chain` by configuring `Policy Routing`.
```bash
-#代理局域网设备
-#继承上一个阶段的成果
+# Add policy routing: Packets marked as 1 go to routing table 100
+ip rule add fwmark 1 table 100
+# Add route entry to table 100: All packets route to local
+ip route add local 0.0.0.0/0 dev lo table 100
+```
+
+By configuring the above `Policy Routing`, we only need to mark packets with `1` in the `OUTPUT Chain`, and the corresponding packets will be routed to the local gateway, i.e., the `PREROUTING Chain`. So, we just need to mark requests from the gateway itself that need proxying with `1` on the `OUTPUT Chain`.
+
+If we proxy all requests originating from the gateway, a problem arises: Xray runs on the gateway and sends requests to the proxy server. If this request is also proxied, a loop is formed.
+
+Therefore, to proxy the gateway itself, we must avoid loops, which means avoiding Xray's own traffic in the proxy rules.
+
+**There are three common methods:**
+
+1. Direct connection for traffic destined for the VPS address
+
+Reboot the gateway, run Xray, and execute the following commands:
+
+```bash
+# Proxy LAN devices
+# Inherit results from the previous stage
ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N XRAY
-iptables -t mangle -A XRAY -d 网关所在网段1 -j RETURN
-iptables -t mangle -A XRAY -d 网关所在网段2 -j RETURN
+iptables -t mangle -A XRAY -d Gateway_Subnet_1 -j RETURN
+iptables -t mangle -A XRAY -d Gateway_Subnet_2 -j RETURN
...
iptables -t mangle -A XRAY -d 224.0.0.0/3 -j RETURN
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A PREROUTING -j XRAY
-#代理网关本机
+# Proxy the gateway itself
iptables -t mangle -N XRAY_MASK
-iptables -t mangle -A XRAY_MASK -d 网关所在网段1 -j RETURN
-iptables -t mangle -A XRAY_MASK -d 网关所在网段2 -j RETURN
+iptables -t mangle -A XRAY_MASK -d Gateway_Subnet_1 -j RETURN
+iptables -t mangle -A XRAY_MASK -d Gateway_Subnet_2 -j RETURN
...
iptables -t mangle -A XRAY_MASK -d 224.0.0.0/3 -j RETURN
-iptables -t mangle -A XRAY_MASK -d VPS公网ip/32 -j RETURN
+iptables -t mangle -A XRAY_MASK -d VPS_Public_IP/32 -j RETURN
iptables -t mangle -A XRAY_MASK -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -p tcp -j XRAY_MASK
iptables -t mangle -A OUTPUT -p udp -j XRAY_MASK
```
-但是这么配置有个缺点，如果使用 CDN 或者 VPS 很多的话，就不好写规则了。
+However, this configuration has a downside: if you use CDNs or many VPSs, writing rules becomes difficult.
-2. 通过 mark 规避
+1. Bypass via fwmark
-三个白话文教程都是使用这种方法规避，自行参考，这里不再赘述。
+The three "Plain Language" tutorials all use this method to avoid loops. Please refer to them; I won't repeat it here.
-3. 通过 gid 规避(推荐)
+1. Bypass via GID (Recommended)
-参考 **[[透明代理]通过 gid 规避 Xray 流量](../iptables_gid.md)**
+Refer to **[[Transparent Proxy] Bypassing Xray Traffic via GID](../iptables_gid.md)**.
-这样就完成了第三阶段的代理，也就是平时说的全局代理。但是记得把网关的 DNS 服务器设置为国外的 DNS 服务器，否则可能依然返回被污染的结果。
+This completes Stage 3 proxying, which is what we call Global Proxy. However, remember to set the gateway's DNS server to a foreign DNS server; otherwise, it may still return polluted results.
-### 第四阶段
+### Stage 4
-其实，并不是所有人都需要实现第四阶段。全局代理对于大部分情况已经适用。
+In fact, not everyone needs to implement Stage 4. Global proxy is suitable for most situations.
-特别是对于旁路由而言。需要代理时，将网关调成旁路由的 IP，不需要代理时，将网关换回主路由 IP。
+Especially for "Side Routers" (Gateway Servers). When proxying is needed, set the device gateway to the Side Router's IP; when not needed, set the gateway back to the Main Router's IP.
-至于第四阶段的具体实现，那三篇白话文教程讲的都是。在理解了上面的内容后，再去看那三篇白话文教程，就比较容易理解了。
+As for the specific implementation of Stage 4, those three "Plain Language" tutorials cover it. After understanding the content above, reading those tutorials should be much easier.
-### 代理 ipv6
+### Proxying IPv6
-上面的规则只对 ipv4 生效，如果还想要代理 ipv6 请求，则使用 ip6tables 命令，用法与 iptables 基本相同。参考 **[[透明代理]通过 gid 规避 Xray 流量#4-设置 iptables 规则](../iptables_gid#4-设置iptables规则.md)**
+The rules above only apply to IPv4. If you also want to proxy IPv6 requests, use the `ip6tables` command. The usage is basically the same as `iptables`. Refer to **[[Transparent Proxy] Bypassing Xray Traffic via GID#4-Set iptables rules](../iptables_gid#4-设置iptables规则.md)**.
-# iptables 透明代理的其它注意事项
+# Other Notes on iptables Transparent Proxy
-1. 如果作为代理的网关作为主路由，要在`PREROUTING链`规则中加一条`iptables -t mangle -A XRAY ! -s 网关LAN_IP地址段 -j RETURN`，即在第一阶段使用、第二阶段被删除的指令。如果不写，WAN 口中同网段的其它人可以将网关填写成你的 WAN_IP，从而蹭你的透明代理用，还可能带来一定的危险性。
+1. If the gateway acting as the proxy is the **Main Router**, you must add `iptables -t mangle -A XRAY ! -s Gateway_LAN_IP_Range -j RETURN` to the `PREROUTING Chain` rules. This is the command used in Stage 1 but removed in Stage 2. If you don't write this, other people in the same subnet on the WAN port can set their gateway to your WAN_IP, thereby leeching off your transparent proxy, which may also pose certain dangers.
-2. **[新 V2Ray 白话文指南-透明代理(TPROXY)#设置网关](https://guide.v2fly.org/app/tproxy.html#设置网关)** 中的第三条说：`手动配置 PC 的网络，将默认网关指向树莓派的地址即 192.168.1.22。此时 PC 应当能正常上网（由于还没设置代理，“正常”是指可以上国内的网站）`。实际上，Ubuntu、CentOS、debian 等系统就算开启了 IP 转发，PC 也不能正常上网，这是正常的。事实上只有 OpenWRT 能做到文中所描述的那样，据 **[@BioniCosmos](https://github.com/BioniCosmos)** 点拨，这是由于一般的 Linux 系统没有 Masquery 规则。
+2. **[New V2Ray Plain Guide - Transparent Proxy (TPROXY) #Set Gateway](https://guide.v2fly.org/app/tproxy.html#设置网关)**, item 3 states: `Manually configure the PC's network, pointing the default gateway to the Raspberry Pi's address, i.e., 192.168.1.22. At this time, the PC should be able to access the Internet normally (since no proxy is set yet, "normal" means accessing domestic websites).` In reality, on systems like Ubuntu, CentOS, Debian, etc., even if IP Forwarding is enabled, the PC cannot access the Internet normally. This is expected. Only OpenWrt can achieve what is described in the article. As pointed out by **[@BioniCosmos](https://github.com/BioniCosmos)**, this is because general Linux systems do not have Masquerade rules.
-3. **[too many open files 问题](https://guide.v2fly.org/app/tproxy.html#解决-too-many-open-files-问题)** ，解决方法见 **[[透明代理]通过 gid 规避 Xray 流量-配置最大文件大开数&运行 Xray 客户端](../iptables_gid#3-配置最大文件大开数运行xray客户端)**
+3. **[too many open files issue](https://guide.v2fly.org/app/tproxy.html#解决-too-many-open-files-问题)**. For the solution, see **[[Transparent Proxy] Bypassing Xray Traffic via GID - Config Max Open Files & Run Xray Client](../iptables_gid#3-配置最大文件大开数运行xray客户端)**.
-4. 关于开启 ip_forward，待补充...
+4. Avoid double TPROXY for existing connections. To be added...
-5. 避免已有连接的包二次通过 TPROXY ,待补充...
-
-6. 主路由、单臂路由与旁路由，待补充...
+5. Main Router vs. Single-Arm Router vs. Side Router. To be added...
diff --git a/docs/en/document/level-2/warp.md b/docs/en/document/level-2/warp.md
index 50bd6349..6875d581 100644
--- a/docs/en/document/level-2/warp.md
+++ b/docs/en/document/level-2/warp.md
@@ -1,60 +1,153 @@
---
-title: Enhancing Proxy Security with Cloudflare Warp
+title: Enhancing Proxy Security via Cloudflare Warp
---
-# Enhancing Proxy Security with Cloudflare Warp
+# Enhancing Proxy Security via Cloudflare Warp
-Xray (1.6.5+) has added outbound WireGuard support. Although the added code and dependencies will increase the core size, we believe that this is a necessary new feature for three reasons:
+Xray (1.6.5+) has added a WireGuard outbound. Although the additional code and dependencies increase the core size, we believe this is a highly necessary new feature for three reasons:
-1. Through recent discussions and [experiments](https://github.com/net4people/bbs/issues/129#issuecomment-1308102504), we know that proxying the traffic back to China is not safe. One way to deal with this is to route the back-to-China traffic to a black hole, but the downside is that due to the delay in geosite and geoip updates or the lack of knowledge on how to properly split the traffic on the client side, the traffic ends up going to the black hole, affecting the user experience. In this case, we only need to import the back-to-China traffic into Cloudflare Warp, which can achieve the same level of security without affecting the user experience.
-2. As we all know, most airports will log the domain names visited by users, and some airports will even audit and block some user traffic. One way to protect user privacy is to use chain proxies on the client side. The WireGuard lightweight VPN protocol used by Warp adds an extra layer of encryption within the proxy layer. For airports, the target of all user traffic is Warp, thereby maximizing privacy protection.
-3. It is easy to use, and only one core is needed to complete the split, Wireguard Tun, and chain proxy settings.
+1. Through recent discussions and [experiments](https://github.com/net4people/bbs/issues/129#issuecomment-1308102504), we know that routing traffic back to China via a proxy is insecure. One countermeasure is to route return traffic to a blackhole. The downside is that if `geosite` and `geoip` rules are not updated in time, or if beginners don't know how to configure routing properly on the client side, legitimate traffic enters the blackhole, affecting the user experience.
+ By routing return traffic (traffic destined for China) to Cloudflare Warp instead, we can achieve the same level of security without impacting the user experience.
+2. It is well known that most proxy providers ("Airports") log user domain access history, and some even audit and block certain user traffic. One way to protect user privacy is to use a chain proxy on the client side.
+ The WireGuard lightweight VPN protocol used by Warp adds a layer of encryption within the proxy layer. For the proxy provider, the destination of all user traffic appears to be Warp, thereby maximizing privacy protection.
+3. Ease of use. A single core can handle routing, WireGuard Tun, and chain proxy settings.
## Applying for a Warp Account
-1. Thank you Cloudflare for promoting a free internet. Now you can use the Warp service for free, and the nearest server will be automatically selected based on the exit.
-2. Use a VPS and download [wgcf](https://github.com/ViRb3/wgcf/releases).
-3. Run `wgcf register` to generate `wgcf-account.toml`.
-4. Run `wgcf generate` to generate `wgcf-profile.conf`. Copy the following content:
+### Thanks to Cloudflare for promoting a free internet. You can now use the Warp service for free, and it will automatically select the nearest server when connecting
-```
+#### Method 1
+
+1. Use a VPS to download [wgcf](https://github.com/ViRb3/wgcf/releases).
+2. Run `wgcf register` to generate `wgcf-account.toml`.
+3. Run `wgcf generate` to generate `wgcf-profile.conf`. Copy the content as follows:
+
+```ini
[Interface]
-PrivateKey = my private key
+PrivateKey = My_Private_Key
Address = 172.16.0.2/32
Address = 2606:4700:110:8949:fed8:2642:a640:c8e1/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
-PublicKey = Warp public key
+PublicKey = Warp_Public_Key
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:2408
```
-## Diverting inbound traffic to warp on the server side
+#### Method 2
-Add a new WireGuard outbound in the existing ones.
+1. Use [warp-reg.sh](https://github.com/chise0713/warp-reg.sh), run:
+
+```
+bash -c "$(curl -L warp-reg.vercel.app)"
+```
+
+- Output:
+
+```json
+{
+ "endpoint": {
+ "v4": "162.159.192.7",
+ "v6": "[2606:4700:d0::a29f:c007]"
+ },
+ "reserved_dec": [35, 74, 190],
+ "reserved_hex": "0x234abe",
+ "reserved_str": "I0q+",
+ "private_key": "yL0kApRiZW4VFfNkKAQ/nYxnMFT3AH0dfVkj1GAlr1k=",
+ "public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
+ "v4": "172.16.0.2",
+ "v6": "2606:4700:110:81f3:2a5b:3cad:9d4:9ea6"
+}
+```
+
+1. Copy the output content.
+
+#### Method 3
+
+1. Use [wgcf-cli](https://github.com/ArchiveNetwork/wgcf-cli). Run the following to install:
+
+```
+bash -c "$(curl -L wgcf-cli.vercel.app)"
+```
+
+1. Run `wgcf-cli register` to register. Output:
+
+```json
+❯ wgcf-cli register
+{
+ "endpoint": {
+ "v4": "162.159.192.7:0",
+ "v6": "[2606:4700:d0::a29f:c007]:0"
+ },
+ "reserved_str": "6nT5",
+ "reserved_hex": "0xea74f9",
+ "reserved_dec": [
+ 234,
+ 116,
+ 249
+ ],
+ "private_key": "WIAKvgUlq5fBazhttCvjhEGpu8MmGHcb1H0iHSGlU0Q=",
+ "public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
+ "addresses": {
+ "v4": "172.16.0.2",
+ "v6": "2606:4700:110:8d9c:3c4e:2190:59d1:2d3c"
+ }
+}
+```
+
+- The complete file will be saved to `wgcf.json` in the working directory.
+
+1. Run `wgcf-cli generate --xray` to generate a WireGuard outbound config. It will save the content to `wgcf.xray.json`.
+
+- Example file:
```json
{
"protocol": "wireguard",
"settings": {
- "secretKey": "My private key",
+ "secretKey": "6CRVRLgFwGajnikoVOPTDNZnDhx3EydhPsMgpxHfBCY=",
+ "address": ["172.16.0.2/32", "2606:4700:110:857a:6a95:fe27:1870:2a9d/128"],
+ "peers": [
+ {
+ "publicKey": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
+ "allowedIPs": ["0.0.0.0/0", "::/0"],
+ "endpoint": "162.159.192.1:2408"
+ }
+ ],
+ "reserved": [240, 25, 146],
+ "mtu": 1280
+ },
+ "tag": "wireguard"
+}
+```
+
+## Routing Traffic Back to China via Warp on the Server Side
+
+Add a new WireGuard outbound to your existing outbounds:
+
+```json
+{
+ "protocol": "wireguard",
+ "settings": {
+ "secretKey": "My_Private_Key",
"address": ["172.16.0.2/32", "2606:4700:110:8949:fed8:2642:a640:c8e1/128"],
"peers": [
{
- "publicKey": "Warp public key",
+ "publicKey": "Warp_Public_Key",
"endpoint": "engage.cloudflareclient.com:2408"
}
- ]
+ ],
+ "reserved": [0, 0, 0] // If you have it, paste 'reserved' here
},
"tag": "wireguard-1"
}
```
-Recommended routing strategy is `IPIfNonMatch`.
+Recommended routing strategy: `IPIfNonMatch`.
-Add the following to the existing router:
+Add the following to your existing routing rules:
```json
{
@@ -79,13 +172,14 @@ Add the following to the existing router:
{
"protocol":"wireguard",
"settings":{
- "secretKey":"My private key",
+ "secretKey":"My_Private_Key",
"peers":[
{
- "publicKey":"Warp public key",
+ "publicKey":"Warp_Public_Key",
"endpoint":"engage.cloudflareclient.com:2408"
}
- ]
+ ],
+ "reserved":[0, 0, 0] // If you have it, paste 'reserved' here
},
"streamSettings":{
"sockopt":{
@@ -100,11 +194,11 @@ Add the following to the existing router:
"settings":{
"vnext":[
{
- "address":"My IP",
- "port":My port,
+ "address":"My_Server_IP",
+ "port":My_Port,
"users":[
{
- "id":"My UUID",
+ "id":"My_UUID",
"security":"auto"
}
]