Max/XTLS_Xray-docs-next
1
0
Fork 0
mirror of https://github.com/XTLS/Xray-docs-next.git synced 2026-09-22 22:38:05 +03:00
Code Issues Packages Projects Releases Wiki Activity

EN: Retranslate all documents via Gemini Pro 3, Human proofreading

Browse Source
This commit is contained in:
Meow
2026-01-24 06:07:31 +08:00
parent a07654a1d1
commit b7ee2196c6
91 changed files with 6053 additions and 5509 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.vitepress/menus/nav.en.mts
+4 -4
View File
@@ -9,7 +9,7 @@ export const nav: DefaultTheme.Config["nav"] = [
{ text: "Basic Configuration", link: "/en/config/" },
{ text: "Inbound Protocols", link: "/en/config/inbounds/" },
{ text: "Outbound Protocols", link: "/en/config/outbounds/" },
{ text: "Underlying Transports", link: "/en/config/transports/" },
{ text: "Transports", link: "/en/config/transports/" },
],
},
{
@@ -17,11 +17,11 @@ export const nav: DefaultTheme.Config["nav"] = [
items: [
{ text: "Quick Start", link: "/en/document/" },
{
text: "Beginner's Plain Language Guide",
text: "Absolute Beginner's Plain Guide",
link: "/en/document/level-0/",
},
{ text: "Beginner Tips", link: "/en/document/level-1/" },
{ text: "Advanced Tips", link: "/en/document/level-2/" },
{ text: "Beginner Skills", link: "/en/document/level-1/" },
{ text: "Advanced Skills", link: "/en/document/level-2/" },
],
},
{ text: "Developer Guide", link: "/en/development/" },
.vitepress/menus/sidebar.en.mts
+45 -102
View File
@@ -7,24 +7,15 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/config/features/",
collapsed: true,
items: [
{
text: "In-depth Analysis of XTLS",
link: "/en/config/features/xtls.md",
},
{
text: "Fallback",
link: "/en/config/features/fallback.md",
},
{ text: "XTLS Deep Dive", link: "/en/config/features/xtls.md" },
{ text: "Fallback", link: "/en/config/features/fallback.md" },
{
text: "Browser Dialer",
link: "/en/config/features/browser_dialer.md",
},
{ text: "Environment Variables", link: "/en/config/features/env.md" },
{
text: "Environment Variables",
link: "/en/config/features/env.md",
},
{
text: "Multi-file Configuration",
text: "Multiple Configurations",
link: "/en/config/features/multiple.md",
},
],
@@ -38,24 +29,15 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
{ text: "API Interface", link: "/en/config/api.md" },
{ text: "Built-in DNS Server", link: "/en/config/dns.md" },
{ text: "FakeDNS", link: "/en/config/fakedns.md" },
{ text: "Inbound Proxy", link: "/en/config/inbound.md" },
{
text: "Outbound Proxy (Mux, XUDP)",
link: "/en/config/outbound.md",
},
{ text: "Inbounds", link: "/en/config/inbound.md" },
{ text: "Outbounds (Mux, XUDP)", link: "/en/config/outbound.md" },
{ text: "Local Policy", link: "/en/config/policy.md" },
{ text: "Reverse Proxy", link: "/en/config/reverse.md" },
{ text: "Routing", link: "/en/config/routing.md" },
{ text: "Statistics", link: "/en/config/stats.md" },
{
text: "Transport (uTLS, REALITY)",
link: "/en/config/transport.md",
},
{ text: "Transport (uTLS, REALITY)", link: "/en/config/transport.md" },
{ text: "Metrics", link: "/en/config/metrics.md" },
{
text: "Connection Observatory",
link: "/en/config/observatory.md",
},
{ text: "Observatory", link: "/en/config/observatory.md" },
],
},
{
@@ -68,10 +50,7 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/config/inbounds/tunnel.md",
},
{ text: "HTTP", link: "/en/config/inbounds/http.md" },
{
text: "Shadowsocks",
link: "/en/config/inbounds/shadowsocks.md",
},
{ text: "Shadowsocks", link: "/en/config/inbounds/shadowsocks.md" },
{ text: "Socks", link: "/en/config/inbounds/socks.md" },
{ text: "Trojan", link: "/en/config/inbounds/trojan.md" },
{
@@ -80,6 +59,7 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
},
{ text: "VMess", link: "/en/config/inbounds/vmess.md" },
{ text: "Wireguard", link: "/en/config/inbounds/wireguard.md" },
{ text: "TUN", link: "/en/config/inbounds/tun.md" },
],
},
{
@@ -87,10 +67,7 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/config/outbounds/",
collapsed: true,
items: [
{
text: "Blackhole",
link: "/en/config/outbounds/blackhole.md",
},
{ text: "Blackhole", link: "/en/config/outbounds/blackhole.md" },
{ text: "DNS", link: "/en/config/outbounds/dns.md" },
{
text: "Freedom (fragment, noises)",
@@ -98,10 +75,7 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
},
{ text: "HTTP", link: "/en/config/outbounds/http.md" },
{ text: "Loopback", link: "/en/config/outbounds/loopback.md" },
{
text: "Shadowsocks",
link: "/en/config/outbounds/shadowsocks.md",
},
{ text: "Shadowsocks", link: "/en/config/outbounds/shadowsocks.md" },
{ text: "Socks", link: "/en/config/outbounds/socks.md" },
{ text: "Trojan", link: "/en/config/outbounds/trojan.md" },
{
@@ -109,14 +83,12 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/config/outbounds/vless.md",
},
{ text: "VMess", link: "/en/config/outbounds/vmess.md" },
{
text: "Wireguard",
link: "/en/config/outbounds/wireguard.md",
},
{ text: "Wireguard", link: "/en/config/outbounds/wireguard.md" },
{ text: "Hysteria", link: "/en/config/outbounds/hysteria.md" },
],
},
{
text: "Underlying Transports",
text: "Transports",
link: "/en/config/transports/",
collapsed: true,
items: [
@@ -127,42 +99,31 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
},
{ text: "mKCP", link: "/en/config/transports/mkcp.md" },
{ text: "gRPC", link: "/en/config/transports/grpc.md" },
{
text: "WebSocket",
link: "/en/config/transports/websocket.md",
},
{
text: "HTTPUpgrade",
link: "/en/config/transports/httpupgrade.md",
},
{ text: "WebSocket", link: "/en/config/transports/websocket.md" },
{ text: "HTTPUpgrade", link: "/en/config/transports/httpupgrade.md" },
{ text: "Hysteria", link: "/en/config/transports/hysteria.md" },
],
},
],
"/en/document/": [
{
text: "Quick Start Guide",
text: "Quick Start",
link: "/en/document/",
collapsed: true,
items: [
{
text: "Download and Install",
link: "/en/document/install.md",
},
{ text: "Configure and Run", link: "/en/document/config.md" },
{ text: "Command Parameters", link: "/en/document/command.md" },
{
text: "Contribute to Project X's Documentation",
link: "/en/document/document.md",
},
{ text: "Installation", link: "/en/document/install.md" },
{ text: "Configuration & Run", link: "/en/document/config.md" },
{ text: "Command Arguments", link: "/en/document/command.md" },
{ text: "Contribute to Project X", link: "/en/document/document.md" },
],
},
{
text: "Beginner's Plain Language Guide",
text: "Absolute Beginner's Guide",
link: "/en/document/level-0/",
collapsed: true,
items: [
{
text: "[Chapter 1] Beginner's Plain Language Guide",
text: "[Chapter 1] Preface",
link: "/en/document/level-0/ch01-preface.md",
},
{
@@ -170,15 +131,15 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/document/level-0/ch02-preparation.md",
},
{
text: "[Chapter 3] Remote Login",
text: "[Chapter 3] Remote Login (SSH)",
link: "/en/document/level-0/ch03-ssh.md",
},
{
text: "[Chapter 4] Security Protection",
text: "[Chapter 4] Security",
link: "/en/document/level-0/ch04-security.md",
},
{
text: "[Chapter 5] Website Construction",
text: "[Chapter 5] Website Building",
link: "/en/document/level-0/ch05-webpage.md",
},
{
@@ -190,7 +151,7 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/document/level-0/ch07-xray-server.md",
},
{
text: "[Chapter 8] Xray Client",
text: "[Chapter 8] Xray Clients",
link: "/en/document/level-0/ch08-xray-clients.md",
},
{
@@ -200,43 +161,40 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
],
},
{
text: "Beginner Tips",
text: "Beginner Skills",
link: "/en/document/level-1/",
collapsed: true,
items: [
{
text: "Brief Analysis of Fallbacks",
text: "Analysis of Fallbacks",
link: "/en/document/level-1/fallbacks-lv1.md",
},
{
text: "Brief Analysis of Routing (Part 1)",
text: "Analysis of Routing (Part 1)",
link: "/en/document/level-1/routing-lv1-part1.md",
},
{
text: "Brief Analysis of Routing (Part 2)",
text: "Analysis of Routing (Part 2)",
link: "/en/document/level-1/routing-lv1-part2.md",
},
{
text: "Xray's Working Modes",
link: "/en/document/level-1/work.md",
},
{ text: "Working Modes of Xray", link: "/en/document/level-1/work.md" },
{
text: "SNI Fallback",
link: "/en/document/level-1/fallbacks-with-sni.md",
},
{
text: "Achieving Precise Domestic/International Traffic Splitting with DNS",
text: "Traffic Splitting via DNS",
link: "/en/document/level-1/routing-with-dns.md",
},
],
},
{
text: "Advanced Tips",
text: "Advanced Skills",
link: "/en/document/level-2/",
collapsed: true,
items: [
{
text: "Introduction to Transparent Proxy",
text: "Transparent Proxy Basics",
link: "/en/document/level-2/transparent_proxy/transparent_proxy.md",
},
{
@@ -244,11 +202,11 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/document/level-2/tproxy.md",
},
{
text: "TProxy Transparent Proxy (IPv4 and IPv6)",
text: "TProxy (IPv4 and IPv6)",
link: "/en/document/level-2/tproxy_ipv4_and_ipv6.md",
},
{
text: "Building TLS Tunnel with Nginx or Haproxy to Hide Fingerprints",
text: "Hide Fingerprint with Nginx/Haproxy TLS Tunnel",
link: "/en/document/level-2/nginx_or_haproxy_tls_tunnel.md",
},
{
@@ -260,7 +218,7 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/document/level-2/redirect.md",
},
{
text: "Enhancing Proxy Security with Cloudflare Warp",
text: "Enhance Security with Cloudflare Warp",
link: "/en/document/level-2/warp.md",
},
{
@@ -276,14 +234,8 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
link: "/en/development/",
collapsed: true,
items: [
{
text: "Compilation",
link: "/en/development/intro/compile.md",
},
{
text: "Design Goals",
link: "/en/development/intro/design.md",
},
{ text: "Compilation", link: "/en/development/intro/compile.md" },
{ text: "Design Goals", link: "/en/development/intro/design.md" },
{
text: "Development Guidelines",
link: "/en/development/intro/guide.md",
@@ -294,22 +246,13 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
text: "Protocol Details",
collapsed: false,
items: [
{
text: "VLESS Protocol",
link: "/en/development/protocols/vless.md",
},
{
text: "VMess Protocol",
link: "/en/development/protocols/vmess.md",
},
{ text: "VLESS Protocol", link: "/en/development/protocols/vless.md" },
{ text: "VMess Protocol", link: "/en/development/protocols/vmess.md" },
{
text: "Mux.Cool Protocol",
link: "/en/development/protocols/muxcool.md",
},
{
text: "mKCP Protocol",
link: "/en/development/protocols/mkcp.md",
},
{ text: "mKCP Protocol", link: "/en/development/protocols/mkcp.md" },
],
},
],
docs/en/about/news.md
+259 -255
View File
@@ -2,153 +2,155 @@
sidebar: auto
---
# The Great Chronicles
# Grand Chronicle
## 2024.10.31 <badge>[24.10.31](https://github.com/XTLS/Xray-core/releases/tag/v24.10.31)</badge>
Happy Halloween! 🎃
We have a gift with candies for you, come get and open~ 🎁
There are gifts and candies for this Halloween~ Welcome to unwrap and taste~ 🎁
~~SplitHTTP now evolved into XHTTP, with ability of splitting upstream and downstream to different pathway! It is concrete that XHTTP opens a new era again.~~
~~SplitHTTP evolved into XHTTP, and now it has the capability of separating uplink and downlink! Undoubtedly, XHTTP has opened a brand new era.~~
## 2024.10.24
Only panels that secure in default are listed here. The plain HTTP issue shouldn’t be taken lightly.
Only panels that can be configured safely are listed now. The issue of plaintext HTTP cannot be taken lightly.
## 2024.10.18
The first Projext X NFT pricing 0.15 ETH has been sold. Thank you for your support! And don't forget that the earlier you purchase the lower the price.
The first Project X NFT priced at 0.15 ETH was sold yesterday. Thanks for the support! Don't forget, the earlier you buy, the cheaper it is.
We may have 10,000 REALITY NFT (two of them as a gift) with each pricing 0.01 ETH as a way of normal donation.
There are expected to be 10,000 REALITY NFTs (with two being given away), priced at 0.01 ETH each, to serve as a channel for daily donations.
## 2024.10.4
Why there is someone use panels with http://ip over Internet? Oh no, oh no, oh no no no no no...
Why are there people managing panels using <http://ip> on the public web? No, this shouldn't be happening...
For [data security](https://t.me/projectXtls/358), these tools should use HTTPS or SSH tunneling.
For safety, tools used for such configurations should use HTTPS or SSH forwarding to [ensure security](https://t.me/projectXtls/358).
## 2024.10.3
It is almost one day after marking v24.9.30 as the latest version and no one complaints, ~~oh so nobody use the removed obsolote parts~~.
It's been almost a day since v24.9.30 was set to `latest`, and I haven't seen anyone complaining about issues ~~, which implies that the deleted features were truly not being used by anyone~~. 🤡
## 2024.9.30 <badge>[24.9.30](https://github.com/XTLS/Xray-core/releases/tag/v24.9.30)</badge>
The first stable release after changing the versioning rule!
First stable release after changing the versioning rules!
As the first stable version of versioning change:
As the first release after the version number change:
- We have XMUX for SplitHTTP
- HTTP/3 now in HTTP transport
- TCP transport renamed to RAW (more sensible)
- UDP Noises in Freedom outbound
- **WARNING**: This version has removed lots of obsolote config fields, check the config file carefully before upgrade to prevent unexpected situations.
- SplitHTTP added XMUX control.
- HTTP transport added HTTP/3.
- TCP in transport layer renamed to RAW (it makes more sense now).
- UDP Noises for Freedom outbound.
- **Note**: This version removed a large amount of obsolete configuration code. Please strictly check your configuration file against the documentation before upgrading to avoid accidents.
## 2024.9.28
We all know the entrance question of the group is hell difficult.
It is generally acknowledged that joining the group is difficult.
But it’s not about the number of people — it’s about quality. The goal is to test one's ability to find answers independently and ~~a bit of luck~~. This way, we can maintain high-quality discussions.
However, quality matters more than quantity. It tests the ability to find answers independently ~~and a little bit of luck~~, so as to maintain high-quality communication in the group.
Cherish your place in the group and be sure not to break the rules!
Cherish your qualification to stay in the group and do not violate the rules.
## 2024.9.24
NOTICE: There is ONLY one Project X NFT left with the price 0.1 ETH. The subsequent price starts from 0.15 ETH.
Reminder: Only one Project X NFT priced at 0.1 ETH remains. Afterward, the price will start at 0.15 ETH.
## 2024.9.17
The sister group, Project X, reached 1000 members.
The sister group, Project X, has reached 1000 members.
Thank you for the support from non-Chinese world!
Thanks for the support from the non-Chinese speaking world!
- What are XHTTP and XgRPC?
## 2024.9.12
The Great Chronicles Return to the Scene?!
The return of the Grand Chronicle?!
## 2024.9.7 <Badge>[v24.9.7](https://github.com/XTLS/Xray-core/releases/tag/v24.9.7)</Badge>
First release after abandoning semantic versioning.
First release after changing the version numbering.
- This time, QUIC and DomainSocket transports were removed, along with two pieces of legacy code.
- The binary size is 1MB smaller than v1.8.24.
- As always, there are essential bug fixes.
- Removed QUIC and DomainSocket transport, and removed two pieces of legacy configuration code from ancient times.
- Binary size reduced by 1MB compared to v1.8.24.
- As always, includes necessary bug fixes.
## 2024.9.6
Can Xray-core use Xray-JSON subscription? The proposal is [over here](https://github.com/XTLS/Xray-core/discussions/3765).
Can Xray-core use JSON format subscriptions? The proposal is [here](https://github.com/XTLS/Xray-core/discussions/3765).
## 2024.8.30 <Badge>[v1.8.24](https://github.com/XTLS/Xray-core/releases/tag/v1.8.24)</Badge>
While waiting for the SplitHTTP multiplex controller, the main branch had accumulated many important updates, so we decided to release a version first.
While waiting for the SplitHTTP multiplex controller, the main branch has accumulated a large number of important updates, so we decided to release a version first.
- The Socks inbound now supports HTTP proxy requests by default.
- UDP noise (preview)
- Socks inbound now defaults to being compatible with HTTP proxy requests.
- UDP noise (preview).
- And some other improvements.
Due to the existence of semantic versioning, planning features and scheduling for each release have severely hindered the development, merging, and release of new features. Therefore, we decided to abandon semantic versioning starting with the next release and use the release date as the version number, such as v24.8.30, and cancel version planning, fully adopting continuous updates. Features will be merged and released as soon as they are ready, with a version released at the end of each month.
Due to the existence of traditional version numbers, planning features and scheduling for each version has seriously hindered the development, merging, and release of new features. Therefore, we decided to deprecate traditional version numbers starting from the next version, use the release date as the version number (e.g., v24.8.30), cancel version planning, and fully adopt rolling updates. Completed features will be merged directly without waiting. We expect to release a version at the end of each month.
After all, as a software aiming to help people bypass censorship, instead of maintaining a long-term stable version, it's more important to adapt new features and keep updating monthly.
After all, for anti-censorship software, compared to traditional version numbers, the timeliness of new features and monthly updates are more important than releasing a version with fixed features and maintaining it for a long time.
The next version will remove some legacy code no longer in used, add warning log for using deprecated features/configs, and for sure, some breaking changes. Be aware that future versions will be released once we consider something new is ready for a release.
The next version will remove some ancient code. In the future, we will accumulate new code daily, remind users to migrate, and delete code/introduce breaking changes in the new year's version.
We believe that with your donations and the reform of the release format, the Xray-core project will develop even better.
We believe that with your donations and the innovation in the release format, the Xray-core project will develop even better.
## 2024.8.26
The Project VLESS group was established.
Project VLESS group founded.
We have created [Project VLESS](https://t.me/projectVless) for non-Chinese users (mainly Russian).
## 2024.8.3
The first [Project X NFT](https://github.com/XTLS/Xray-core/discussions/3633#discussioncomment-10240940) is officially released! Just as Xray has made history, releasing an NFT is also an unprecedented move in this field. These NFTs are highly commemorative and even historically significant, far beyond their current initial price. In time, they will undoubtedly become priceless. Once again, thank you for your support of Project X.
The first [Project X NFT](https://github.com/XTLS/Xray-core/discussions/3633) is officially issued!
Just as Xray has created a lot of history, issuing an NFT is also an unprecedented operation in this field. These NFTs are very commemorative, arguably historically significant, and their value far exceeds the current initial price. Given time, they will surely be invaluable. Finally, thank you again for your support of Project X.
## 2024.7.29 <Badge>[v1.8.23](https://github.com/XTLS/Xray-core/releases/tag/v1.8.23)</Badge>
- Congratulations to [@mmmray](https://github.com/mmmray) for contributing the 1000th commit to Xray-core!
- Optimized the stability of SplitHTTP upstream, and the server must be upgraded to this version to support the new client.
- Optimized the stability of SplitHTTP uplink. The server must be upgraded to this version to support the new client.
- More changes on SplitHTTP.
## 2024.7.22 <Badge>[v1.8.21](https://github.com/XTLS/Xray-core/releases/tag/v1.8.21)</Badge>
It seems to have returned to the original state of rapid-fire releases...
It seems we have returned to the initial state of "diarrhea-style" frequent releases...
As foreshadowed in v1.8.16, SplitHTTP now preliminarily supports HTTP/3 (QUIC). Undoubtedly, SplitHTTP H3 has ushered in a new era.
As predicted in v1.8.16, SplitHTTP now initially supports HTTP/3 (QUIC). Undoubtedly, SplitHTTP H3 has opened a brand new era.
- SplitHTTP H3 is the first QUIC-based proxy fully compliant with standard H3, supporting CDN passthrough, and can be concealed using reverse proxy or Browser Dialer.
- SplitHTTP H3 is the first QUIC-based proxy completely based on standard H3 and supporting CDN. It can also be hidden using reverse proxy or Browser Dialer.
## 2024.7.16
Project X documentation now has a Russian version! Thanks to [@iambabyninja](https://github.com/iambabyninja) for the translation!
The Project X documentation now has a Russian version! Thanks to [@iambabyninja](https://github.com/iambabyninja) for the translation!
> Привет, друзья из России!
## 2024.7.15
Through known information and efforts, Xray-core now supports Windows 7 again! In subsequent releases, Windows 7 users can enjoy it by downloading and extracting the Xray-win7-32.zip or Xray-win7-64.zip packages. Thank you for your support! For specific usage, please click [here](../document/install.md)
Through known information and efforts, Xray-core now supports Windows 7 again! In subsequent releases, Windows 7 users can download the archive named Xray-win7-32.zip or Xray-win7-64.zip, unzip it, and enjoy. Thanks for everyone's support! For specific usage, please click [here](../document/install.md).
Although Windows 7 will eventually be phased out with future upgrades, we can now delay that time a little.
Although Windows 7 will eventually leave us as everything upgrades, we can delay that moment for a little while longer.
## 2024.6.18 <Badge>[v1.8.16](https://github.com/XTLS/Xray-core/releases/tag/v1.8.16)</Badge>
A new transport has arrived, currently called SplitHTTP.
A new transport is here, currently named SplitHTTP.
- There are two completely opposite ways to achieve further traffic obfuscation: multiplexing and splitting connections.
- It can achieve the same goals as Meek through CDNs that do not support WebSocket or gRPC, and SplitHTTP is simpler and more efficient than Meek.
- SplitHTTP does not have WebSocket's ALPN issues, which is a major advantage, and it will support HTTP/3 (QUIC) in the future.
- SplitHTTP has also been added to the sharing link package.
- There are two diametrically opposed ways to achieve further traffic obfuscation: Multiplexing and Split Connection.
- It allows passing through CDNs that do not support WebSocket or gRPC, achieving the same goal as Meek, but SplitHTTP is simpler and more efficient than Meek.
- SplitHTTP does not have the ALPN issue of WebSocket, which is a major advantage. It will support HTTP/3 (QUIC) in the future.
- Additionally, SplitHTTP has also been added to the share link combo~
## 2024.6.2
A new transport method is being developed...
A new transport mode is being forged...
## 2024.4.26 <Badge>[v1.8.11](https://github.com/XTLS/Xray-core/releases/tag/v1.8.11)</Badge>
- Now there is a tool to generate ECH keys.
- Enhancements, fixes, and some obsolete code removal.
- There is now a tool for generating ECH keys.
- Enhancements, fixes, and removed a bit of unused code.
## 2024.4.20
@@ -164,82 +166,85 @@ Like WebSocket, HTTPUpgrade now also has 0-RTT.
## 2024.3.11 <Badge>[v1.8.9](https://github.com/XTLS/Xray-core/releases/tag/v1.8.9)</Badge>
Added HTTPUpgrade transport, said to be lighter than WebSocket.
Added HTTPUpgrade transport, rumored to be lighter than WebSocket.
- Already added to the sharing link package.
- Added to the share link combo~
## 2024.2.29
gRPC transport now also has a Host-like configuration field! It's called `authority`. Now gRPC can also "domain front," without ALPN issues.
gRPC transport now also has a configuration field similar to Host! It's called `authority`. Now gRPC can also do "domain fronting" without ALPN issues.
## 2024.2.25 <Badge>[v1.8.8](https://github.com/XTLS/Xray-core/releases/tag/v1.8.8)</Badge>
- Now XUDP traffic is uniformly padded with Vision, come and experience it.
- XUDP traffic now uniformly uses Vision padding. Come and experience it.
- Added leastLoad balancer.
- Fixed errors, optimized performance...
- Bug fixes, performance optimizations...
## 2024.1.9
Shocked to hear that Win7 cannot run the new version of Xray-core? Upon exploration, it was discovered that Go has dropped support for Win7. Is there a way to continue supporting this somewhat ancient but still elegant operating system?
Shocked to hear Win7 cannot run the new Xray-core? Exploration revealed that Go dropped support for Win7. Is there any way to continue supporting this somewhat ancient but still elegant operating system?
## 2023.11.21
The [paper](https://t.me/projectXtls/212) published at the USENIX top conference confirms that XTLS Vision has achieved its design goals. And XTLS will not stop there, breaking through towering walls like X-rays.
The [paper](https://t.me/projectXtls/212) published at the USENIX top conference confirms that XTLS Vision has achieved its design goals.
And XTLS will not stop there; it will pierce through towering walls like an X-ray.
## 2023.11.18 <Badge>[v1.8.6](https://github.com/XTLS/Xray-core/releases/tag/v1.8.6)</Badge>
- WireGuard now also has a corresponding inbound. Freedom outbound finally has splice.
- The domainStrategy for outbound has also been unified.
- More delicious little treats.
- Due to ~~force majeure~~ feature changes, Dragonfly BSD support has quietly left the stage.
- ~~Are we really saying goodbye to the classic Windows 7?~~
- WireGuard now also has a corresponding inbound. Freedom outbound finally got `splice`.
- Outbound `domainStrategy` has also been unified.
- More delicious little snacks.
- Due to ~~force majeure~~ feature changes, Dragonfly BSD support has sadly left the stage.
- ~~Are we really going to say goodbye to the classic Windows 7?~~
## 2023.9.30
Designed a brand new color scheme for v2rayNG, install the latest Pre-release version to experience it.
Designed a brand new color scheme for v2rayNG. Install the latest Pre-release version to experience it.
## 2023.8.29 <Badge>[v1.8.4](https://github.com/XTLS/Xray-core/releases/tag/v1.8.4)</Badge>
After half a year of polishing, 1.8.x has finally reached its first recognized official version.
Likewise, there are many integrated improvements this time, come and taste it!
After half a year of polishing, 1.8.x has finally reached its first recognized stable version.
Likewise, this release integrates many improvements. Come and taste it!
## 2023.7.22
Another historical HTTP/2 transport issue has been fixed.
Fixed another legacy connection drop issue in HTTP/2 transport.
## 2023.7.7
Vision will soon have Seed support.
About to add Seed support to Vision.
## 2023.6.30
The next XTLS flow control: xtls-rprx-switch 🍪
- XTLS's 0-RTT has been teased for months, originally to maintain some mystery.
- XTLS 0-RTT has been teased for a few months; intended to keep a sense of mystery.
- Compared to the existing XTLS Vision and Mux, it has even better advantages.
## 2023.6.27
[How to choose a REALITY target domain? Check here to help you achieve twice the result with half the effort!](https://github.com/XTLS/Xray-core/discussions/2256#discussioncomment-6295296)
[How to choose a REALITY target domain? Check here to double the result with half the effort!](https://github.com/XTLS/Xray-core/discussions/2256#discussioncomment-6295296)
## 2023.6.19 <Badge>[v1.8.3](https://github.com/XTLS/Xray-core/releases/tag/v1.8.3)</Badge>
- The first version after the code streamlining plan, VMess (MD5), MTProto, and Starlark-related code have been removed. Going light.
- Code refactoring is also part of going light.
- We have also not forgotten to add some enhancements and fix vulnerabilities.
- ~~v2rayNG has not yet supported Xray, and the new sharing link format cannot be used yet.~~
- The first version after the Code Slimming Plan. VMess (MD5), MTProto, and Starlark related codes have been unloaded. Traveling light.
- Code refactoring is also part of traveling light.
- At the same time, we haven't forgotten to add some enhancements and fix vulnerabilities.
- ~~v1.8.3 is the last version for this year.~~
## 2023.6.6
Good News: The next XTLS flow control will not be called Vision. 🍪
Good news: The next XTLS flow control is not called Vision. 🍪
## 2023.4.21
Maybe we can leverage [RealiTLScanner](https://github.com/XTLS/RealiTLScanner)……
Perhaps we can borrow a bit from [RealiTLScanner](https://github.com/XTLS/RealiTLScanner)...
## 2023.4.20
After years of development and countless lines of code... [The code simplification plan](https://github.com/XTLS/Xray-core/discussions/1967) has been proposed!
After years of development, accumulating countless lines of code... The [Code Slimming Plan](https://github.com/XTLS/Xray-core/discussions/1967) has been proposed!
## 2023.4.19
@@ -247,12 +252,12 @@ After years of development and countless lines of code... [The code simplificati
## 2023.4.18 <Badge>[v1.8.1](https://github.com/XTLS/Xray-core/releases/tag/v1.8.1)</Badge>
The upgraded XUDP is here!
The upgraded XUDP is here too!
- Now XUDP features connection migration and port reuse, with a global Session ID ~~, so mom doesn't have to worry about what to do when there is an unexpected disconnection anymore~~.
- We’ve also added control settings for XUDP, giving you better control~
- The new XUDP paired with XTLS Vision offers an even better experience~
- As usual, there’s a little treat, enjoy~
- Now XUDP also comes with connection migration and port reuse features, and has a global Session ID ~~, so mom doesn't have to worry about accidental disconnections anymore~~.
- We also added XUDP control configurations, allowing you to master it better~
- The new XUDP tastes better when paired with XTLS Vision~
- As customary, there are little desserts. Welcome to taste~
## 2023.4.6
@@ -264,18 +269,18 @@ XUDP is also quietly upgrading...
## 2023.3.19
The sharing link standard for REALITY has also emerged.
The share link standard for REALITY has also emerged.
## 2023.3.9 <Badge>[v1.8.0](https://github.com/XTLS/Xray-core/releases/tag/v1.8.0)</Badge>
> THE NEXT FUTURE, REALITY is NOW release on Xray-core
REALITY has been implemented and released! Welcome to try it out!
XTLS Vision has also been improved, please upgrade both ends to the latest version for the best experience.
REALITY has been implemented and released! Welcome to experience it!
XTLS Vision has also been perfected. Please upgrade both ends to the latest version to enjoy.
- Due to changes in the Vision padding algorithm, there may be compatibility issues between old and new versions of XTLS Vision.
- HTTP/2 transport has also been improved, enjoy the smooth experience with the new version~
- There are many other small improvements, feel free to explore~
- Due to changes in the Vision padding algorithm this time, there will be compatibility issues between the old and new versions of XTLS Vision.
- HTTP/2 transport has also been improved. Use the new version now for silky smoothness~
- There are also a large number of small improvements welcome for you to experience~
## 2023.3.4
@@ -285,7 +290,7 @@ XTLS Vision has also been improved, please upgrade both ends to the latest versi
## 2023.3.2
Some lingering issues with HTTP/2 transport have been improved. Enjoy the smooth experience when testing with REALITY~
Some legacy issues with HTTP/2 transport have been improved. Welcome to test it with REALITY for silky smoothness~
## 2023.2.16
@@ -300,11 +305,11 @@ REALITY is reality now!
Keep riding and never look back.
- Congratulations to [@yuhan6665](https://github.com/yuhan6665) for contributing the 500th commit to Xray-core!
- XTLS Vision flow control is nearly complete and will soon be practical.
- Now there are more options for uTLS fingerprint simulation, which one suits you?
- Sharing links now also support sharing uTLS fingerprint configurations.
- There are more feature enhancements and fixes.
- This version will also be the last time to see XTLS Origin, Direct, and Splice flow control. ~~A bit nostalgic, isn’t it?~~
- XTLS Vision flow control is nearing perfection and will be practical soon.
- Added more options for uTLS fingerprint simulation. Which one suits you?
- Share links now also support sharing uTLS fingerprint configurations simultaneously.
- Even more feature enhancements and fixes.
- This version is also the last one where you can see XTLS Origin, Direct, and Splice flow controls. ~~A bit sad, isn't it?~~
## 2023.1.29
@@ -312,150 +317,150 @@ Winter cannot cover the NEXT FUTURE...
## 2022.12.26 <Badge>[v1.7.0](https://github.com/XTLS/Xray-core/releases/tag/v1.7.0)</Badge>
Due to a slip of the hand, this version number jumped directly up, thanks for everyone's support!
Due to a slip of the hand, the version number jumped significantly this time. Thanks for everyone's support!
- From now on, Semantic Versioning will be strictly followed.
- Semantic Versioning will be strictly followed from now on.
## 2022.11.28 <Badge>[v1.6.5](https://github.com/XTLS/Xray-core/releases/tag/v1.6.5)</Badge>
This time we have WireGuard outbound.
- Using WireGuard with CF WARP can unlock some fun new ways to play.
- Of course, there are also security updates and fixes.
- Using WireGuard with CF WARP can unlock interesting new ways to play.
- As always, security updates and fixes are included.
## 2022.11.7 <Badge>[v1.6.3](https://github.com/XTLS/Xray-core/releases/tag/v1.6.3)</Badge>
Now Vision flow control can also use uTLS fingerprint simulation, is this the benefit brought by `tlsSettings`!
Now Vision flow control can also use uTLS fingerprint simulation. Is this the benefit of using `tlsSettings`!
## 2022.10.29 <Badge>[v1.6.2](https://github.com/XTLS/Xray-core/releases/tag/v1.6.2)</Badge>
The first release with Vision flow control is out! Welcome to try it and give feedback!
The first release containing Vision flow control is out! Welcome to try it out and submit feedback!
## 2022.10.22 <Badge>[v1.6.1](https://github.com/XTLS/Xray-core/releases/tag/v1.6.1)</Badge>
- Brought uTLS fingerprint support for WebSocket, HTTP/2, and gRPC transport!
- The option that was previously only available under regular TLS for TCP transport is now better.
- On Linux, TCP congestion control can be set independently for ingress and egress.
- Brought uTLS fingerprint support to WebSocket, HTTP/2, and gRPC transports!
- Options that were previously only available for TCP transport under standard TLS are now even easier to use.
- TCP congestion control can now be set separately for inbound and outbound on Linux.
## 2022.10.3
The weather is getting cooler, but the pace of development hasn’t slowed down. Blocks fall from the sky, but progress can’t be stopped...
The weather is getting cooler, but the pace of development has not cooled down. The blockade descends, but it cannot stop the progress...
- A new XTLS flow control is brewing...
- Addressing existing flow control issues;
- Direct splice activation for TLS 1.3;
- Added TLS handshake length obfuscation;
- Simplified code, using `tlsSettings` instead of `xtlsSettings`...
- Solves existing issues with previous flow controls;
- Enables `splice` directly for TLS 1.3;
- Adds TLS handshake length obfuscation;
- Simplifies code, using `tlsSettings` instead of `xtlsSettings`...
## 2022.8.28 <Badge>[v1.5.10](https://github.com/XTLS/Xray-core/releases/tag/v1.5.10)</Badge>
Underlying transport now supports more reasonable TCP Keepalive settings.
The underlying transport now supports more reasonable TCP Keepalive configurations.
## 2022.6.20 <Badge>[v1.5.8](https://github.com/XTLS/Xray-core/releases/tag/v1.5.8)</Badge>
Now Shadowsocks-2022 relay is also supported.
Shadowsocks-2022 relay is now supported.
## 2022.5.29 <Badge>[v1.5.6](https://github.com/XTLS/Xray-core/releases/tag/v1.5.6)</Badge>
Shadowsocks-2022 protocol has come to Xray-core!
The Shadowsocks-2022 protocol comes to Xray-core!
- Thanks to [@nekohasekai](https://github.com/nekohasekai) for developing the brand new go implementation https://github.com/SagerNet/sing-shadowsocks and bringing it to Xray.
- Thanks to [@database64128](https://github.com/database64128) for driving the Shadowsocks community to propose a complete design.
- Thanks to [@nekohasekai](https://github.com/nekohasekai) for developing the brand new Go implementation <https://github.com/SagerNet/sing-shadowsocks> and introducing it to Xray.
- Thanks to [@database64128](https://github.com/database64128) for promoting the Shadowsocks community to propose a complete design scheme.
- Thanks to [@RPRX](https://github.com/RPRX) for submitting the original vulnerability.
Shadowsocks-2022 is a newly designed protocol:
Shadowsocks-2022 is a redesigned, brand-new protocol:
- It addresses security issues like replay attacks while retaining native udp support from Shadowsocks (using timestamps similar to vmess, so client and server need synchronized time).
- Supports multi-user on a single port, and implements session mechanisms similar to quic and wireguard to reduce encryption overhead and ensure seamless migration during network changes.
- Based on retaining Shadowsocks native UDP, it solves security issues like replay attacks (using timestamps like VMess, so clients and servers need consistent time).
- Supports single-port multi-user, and references the design and implementation of QUIC, WireGuard, etc., using a session mechanism to reduce encryption burden and ensure seamless migration during network changes.
## 2022.4.24 <Badge>[v1.5.5](https://github.com/XTLS/Xray-core/releases/tag/v1.5.5)</Badge>
This time we brought a convenient visual data detection interface! Come and experience it!
This time brings a detection data interface convenient for visualization! Come and experience it!
- We also fixed some issues affecting user experience.
- Also fixed some issues affecting user experience.
## 2022.3.13 <Badge>[v1.5.4](https://github.com/XTLS/Xray-core/releases/tag/v1.5.4)</Badge>
Added a wxray.exe file for Windows platform with no black windows popping up, and brought enhancements for UDS listening.
Added a `wxray.exe` file for the Windows platform that doesn't pop up a black window, and brought enhancements to UDS listening.
## 2022.1.29 <Badge>[v1.5.3](https://github.com/XTLS/Xray-core/releases/tag/v1.5.3)</Badge>
Farewell to the year of the Ox, and leap into the new year of the Tiger. 🧨
Farewell to the Ox, Leaping into the Year of the Tiger. 🧨
- This time we brought improvements to stream allocation for QUIC transport, making QUIC transport smoother.
- This time brings stream allocation improvements for QUIC transport. Using QUIC transport is now smoother.
## 2021.12.24 <Badge>[v1.5.2](https://github.com/XTLS/Xray-core/releases/tag/v1.5.2)</Badge>
Added a new option for gRPC, making it even better when used through a CDN.
Added a new option for gRPC, making it easier to use when passing through CDNs.
## 2021.12.15 <Badge>[v1.5.1](https://github.com/XTLS/Xray-core/releases/tag/v1.5.1)</Badge>
> “A transitional, phased maintenance version”
> "Transitional phase maintenance release"
- New features, enhancements, and a lot of fixes are coming in.
- Remember to remove `alterID` from your VMess configuration!
- New features, enhancements, and a large number of fixes are coming one after another.
- Remember to remove `alterID` from VMess configuration!
## 2021.10.20 <Badge>[v1.5.0](https://github.com/XTLS/Xray-core/releases/tag/v1.5.0)</Badge>
A really big change!
Truly massive changes!
- Refactored the DNS component, with more supported protocols and detailed configurations.
- Refactored DNS components; more protocols and detailed configurations are supported.
- Enhanced gRPC transport and FakeDNS.
- Finally supports Windows ARM64.
- More new features and improvements await you.
- More new features and improvements await your experience.
## 2021.9.23 <Badge>[v1.4.5](https://github.com/XTLS/Xray-core/releases/tag/v1.4.5)</Badge>
Happy Mid-Autumn Festival, wishing you a joyful reunion.
Happy Mid-Autumn Festival, wishing you a happy family reunion.
- ~~Fixed a bug where the version number was too low and unlucky.~~
- This update removed the insecure encryption methods from Shadowsocks. Please migrate to AEAD encryption as soon as possible.
- This update fixed a longstanding issue from ancient times: enabling traffic statistics could cause a performance drop. Simply put, enabling statistics now will not impact performance regardless of the configuration.
- Also included are security updates for XTLS and numerous other fixes.
- By the way, due to the TLS library update, `cipherSuites` can no longer specify the order of cipher suites, and `preferServerCipherSuites` has been completely deprecated. In fact, these changes were already present in Xray-core v1.4.3.
- ~~Fixed the bug where the version number was too low and unlucky.~~
- This time removed insecure encryption methods in Shadowsocks. Migrate to AEAD encryption as soon as possible.
- Fixed a historical issue existing since ancient times: enabling traffic statistics might degrade performance. Simply put, turning on statistics now regardless of configuration will not have any impact on performance.
- Also includes security updates for XTLS and numerous fixes.
- By the way, due to the update of the TLS library, `cipherSuites` can no longer specify the order of cipher suites, and `preferServerCipherSuites` has been completely deprecated. In fact, these changes already occurred in Xray-core v1.4.3.
## 2021.9.16
- The documentation site has fully transitioned to docs-next, providing a smoother and better experience! The address remains [https://xtls.github.io/](https://xtls.github.io/).
- The documentation site has fully switched to docs-next, silky smooth, better experience! The address remains [https://xtls.github.io/](https://xtls.github.io/)
## 2021.9.8 <Badge>[v1.4.3](https://github.com/XTLS/Xray-core/releases/tag/v1.4.3)</Badge>
This is a maintenance release. Development continues…
This is a periodic maintenance release. Development continues...
- A large number of improvements and new features have accumulated during this period.
- Added a new DomainMatcher, improving domain rule matching performance.
- Added health checks for HTTP/2 and gRPC transports, improved handling of unknown SNI, and fixed a bunch of bugs.
- Accumulated a large number of improvements and new features during this period.
- Added new DomainMatcher; domain rule matching performance is now better.
- Added health checks for HTTP/2 and gRPC transport, improved handling of unknown SNI, and fixed a bunch of bugs.
> ~~Helden sterben nicht!~~
## 2021.7.14
- AnXray's ~~expensively designed~~ new icon is now live!
- The new icon is now more recognizable.
- Over the past three weeks, AnXray has accumulated 600 stars, 2K+ channel subscriptions, and 11K+ GitHub downloads. Thank you for your support.
- AX is short for AnXray. We recommend using AX to refer to AnXray—it's short and convenient.
- AnXray's new icon, ~~designed at heavy cost~~, is now online!
- The icon is now more recognizable.
- In the past three weeks, AnXray has accumulated 600 stars, 2K+ channel subscribers, and 11K+ GitHub downloads. Thanks for everyone's support.
- AX is the abbreviation for AnXray. It is recommended to use AX to refer to AnXray for brevity.
## 2021.6.21
Now, an open-source, free Android client based on Xray-core is available—[AnXray](https://github.com/XTLS/AnXray)! Maintained by [@nekohasekai](https://github.com/nekohasekai).
Now an open-source, free Android client with Xray-core at its core has appeared—[AnXray](https://github.com/XTLS/AnXray)! Maintained by [@nekohasekai](https://github.com/nekohasekai).
- Supports numerous protocols and plugins.
- Chief visual designer [@RPRX](https://github.com/RPRX) designed an X-style logo, slogan, and a unique black-and-white material theme.
- There's also a small Easter egg waiting to be discovered in the app.
- Chief Visual Designer [@RPRX](https://github.com/RPRX) designed the X-style logo, slogan, and a unique material black and white theme.
- There is also a little easter egg inside the APP waiting for you to discover.
Spent the last few days refining details from morning till night. We hope you'll star and follow the project.
Polished details repeatedly from morning till night over the last two days. Hope everyone gives it a Star and follows.
## 2021.5.1
Improvements to tun2socks have appeared in v2rayNG.
Improvements to tun2socks have appeared on v2rayNG.
## 2021.4.26
Brought an improvement to tun2socks. You might get to enjoy it in the future~
Brought an improvement to tun2socks. Might be able to taste it later~
## 2021.4.12
Let's foresee X-flutter; looking forward to what it might be like~ ~~🍪~~
Now bringing a sneak peek of X-flutter, look forward to what it will look like~ ~~🍪~~
## 2021.4.6
@@ -464,209 +469,208 @@ Let's foresee X-flutter; looking forward to what it might be like~ ~~🍪~~
## 2021.4.4
- This document has a new homepage.
- This document now has a dark mode.
- ~~Of course, dark mode still has various issues. Specific content will need to be gradually adjusted.~~
- Additionally, the Telegram group chat has surpassed 5,000 members! An Anti-Spam bot has also been added!
- This documentation welcomes a new homepage.
- This documentation welcomes Dark Mode.
- ~~Of course, Dark Mode still has various issues. Specific content needs to be adjusted slowly.~~
- Also: Telegram group chat exceeded 5000 people! Also added Anti-Spam bot!
- 🎉🎉🎉
## 2021.4.1 <Badge>[v1.4.2](https://github.com/XTLS/Xray-core/releases/tag/v1.4.2)</Badge>
- Not an April Fool's joke, updated today.
- Added Browser Dialer to modify TLS fingerprints and behavior.
- Added uTLS to modify the TLS Client Hello fingerprint.
- Also fixed a bunch of strange issues; see the changelog for details.
- Added Browser Dialer, used to change TLS fingerprints and behavior.
- Added uTLS, used to change TLS Client Hello fingerprints.
- By the way, fixed a bunch of wondrous issues. See the changelog for details.
## 2021.3.25
<!-- prettier-ignore -->
Yes, it’s still changing. -_-
Yes, still changing. -_-
## 2021.3.15
The documentation site is quietly undergoing some mysterious changes..., 🙊🙊🙊
The documentation site is quietly undergoing some mysterious changes... 🙊🙊🙊
## 2021.3.14 <Badge>[v1.4.0](https://github.com/XTLS/Xray-core/releases/tag/v1.4.0)</Badge>
- Happy Pi-Day!
- This is a major update:
- Introduced transport layer support for chained proxies.
- Introduced Domain Strategy for the Dialer, solving strange DNS issues.
- Added gRPC transport method and a slightly faster Multi Mode.
- Introduced transport layer support for proxy chaining.
- Introduced Domain Strategy for Dialer, solving wondrous DNS issues.
- Added gRPC transport mode, and a slightly faster Multi Mode.
- Added WebSocket Early-Data feature, reducing WebSocket latency.
- Added FakeDNS.
- Also fixed a series of issues and added various features. For details, see the changelog.
- VuePress is still more enjoyable~
- Also fixed a series of issues and added various features. See changelog for details.
- VuePress is still nicer (
## 2021.3.3 <Badge>[1.3.1](https://github.com/XTLS/Xray-core/releases/tag/v1.3.1)</Badge>
- This version uses Golang 1.16, officially supporting Apple Silicon natively.
- Also fixed a bug that could cause a panic. ~~Holmium\_ thinks this is deceit, a sneak attack.~~
- At the same time fixed a bug that would cause Panic. ~~Holmium\_ thinks this is deception, a sneak attack.~~
- Fixed several legacy issues.
## 2021.2.14 <Badge>[1.3.0](https://github.com/XTLS/Xray-core/releases/tag/v1.3.0)</Badge>
- Happy 🐮 Year 🎉!
- v1.3.0 implemented FullCone for all V protocols using a very clever mechanism, while ensuring some compatibility.
- v1.3.0 implemented FullCone for all V-series protocols through a very ingenious mechanism, while ensuring certain compatibility.
- OHHHHHHHHHHHH!
## 2021.01.31 <Badge>[1.2.4](https://github.com/XTLS/Xray-core/releases/tag/v1.2.4)</Badge>
- Resolved two longstanding issues where “connecting to a standard Socks server might result in errors.”
- It seems there’s not much change in this version, but it’s just the calm before the storm.
- (Yes, I’m a prophet)
> You fool, you’re holding a UNO card.
- Solved two legacy issues where "errors might occur when connecting to standard Socks servers".
- It seems there are no changes in this version, but this is just the calm before the storm.
- (Yes, I am a prophet)
> You fool, you are holding a UNO card.
## 2021.01.25
- Have you mastered the most detailed beginner's guide on the entire internet? 🍉 The teacher has started serializing [Level One of the Guide](../document/level-1/)...
- The [English version of the documentation site](/en/) is gradually being updated, thanks to the hard work of everyone involved!
- Have students mastered the best and most detailed beginner's guide on the whole internet? Teacher 🍉 starts serializing the [First Level of the Guide](../document/level-1/)...
- The [English version documentation site](/en/) is gradually adding content. Thanks to all the big shots for their hard work~!
## 2021.01.22 <Badge>[1.2.3](https://github.com/XTLS/Xray-core/releases/tag/v1.2.3)</Badge>
- **Yet again**, support for the SS protocol has been strengthened, now supporting multi-user on a single port!
- **Yet again**, support for the trojan protocol has been strengthened, with new SNI-based routing for trojan fallback!
- _(VLESS: sobbing)_
- The weird UDP bugs have been fixed, making it “stable” in one word.
- Sniffing can now exclude domains you don't want to sniff, opening up some new possibilities.
- Salute to the big shot [@Bohan Yang](https://github.com/bohanyang) who discovers issues -> opens an issue -> tests on their own -> analyzes on their own -> finds the issue on their own -> fixes it on their own -> and then submits a PR upstream and downstream!
- Other tasty cherries—just update and taste them.
- Support for SS protocol has become stronger **again**, supporting single-port multi-user!
- Support for Trojan protocol has also become stronger **again**; Trojan fallback also unlocked a new posture for SNI routing~!
- _(VLESS: _cries_)_
- Weird UDP BUGs have been eliminated. One word: "Stable".
- Sniffing can exclude domains you don't want to sniff, enabling some new ways to play.
- Salute to [@Bohan Yang](https://github.com/bohanyang) who discovers issues -> opens issues -> self-tests -> self-analyzes -> finds the problem -> solves it -> and then submits PRs to upstream and downstream!
- Other delicious little cherries, strictly update and taste as usual.
## 2021.01.19
- Some numbers:
- 10 tags released
- 100 issues resolved
- 300 forks created
- 2000 stars given
- 3000 members in the group
- Some numbers
- Version released 10 tags
- Resolved 100 issues
- Forked 300 times
- Starred 2000 times
- Group has 3000 people
## 2021.01.17
- The hard work of translation has begun, thanks to [@玖柒 Max](https://github.com/jiuqi9997) and all the other translation contributors.
- Hard translation work has begun. Thanks to [@玖柒 Max](https://github.com/jiuqi9997) and all other translation gurus.
- [English version](/en/)
## 2021.01.15 <Badge>[1.2.2](https://github.com/XTLS/Xray-core/releases/tag/v1.2.2)</Badge>
- Fallback routing has unlocked a new strange trick! You can now route based on SNI in the fallback!
- The previously announced UUID modification is officially live. ([Scroll down, scroll down](#_2021-01-12))
- The logs now look a bit more pleasing to the eye than last time.
- Fallback routing unlocked a strange new posture! Fallback can now route based on SNI~!
- The previously announced UUID modification is officially online. ([Look down, look down](#_2021-01-12))
- Logs now look a bit more pleasing to the eye than last time.
- Remote DOH has learned to use routing just like other DNS modes.
- And of course, various other little candies. (Just update and taste them)
- Oh, and, the first person to run Xray on an M1 Mac is Anthony TSE.
- Of course, there are other various small candies. (Update and taste is the way)
- Ah, also, the first man in the world to run Xray on M1 is Anthony TSE.
## 2021.01.12
- Upcoming UUID modification supports mapping between custom strings and UUIDs. This means you can write the id like this in the configuration file to correspond to users.
- Client writes `"id": "I love 🍉 teacher 1314"`,
- Server writes `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the UUID mapping of `I love 🍉 teacher 1314`)
- The [Simple White Language](../document/level-0/) by 🍉 teacher concludes with a grand finale, throwing flowers.
- The upcoming UUID modification supports mapping between custom strings and UUIDs. This means you can write an ID in the configuration file to correspond to a user like this:
- Client writes "id": "I love Teacher 🍉 1314",
- Server writes "id": "5783a3e7-e373-51cd-8642-c83782b807c5" (This UUID is the UUID mapping for `I love Teacher 🍉 1314`)
- Teacher 🍉's [Absolute Beginner's Guide](../document/level-0/) finale. Confetti.
## 2021.01.10 <Badge>[1.2.1](https://github.com/XTLS/Xray-core/releases/tag/v1.2.1)</Badge>
- The [Simple White Language](../document/level-0/) series has been launched! 🍉 Teacher's painstaking work teaches you how to configure Xray from scratch!
- (Possibly the most detailed and patient guide on the entire internet for configuring from zero)
- [Transparent Proxy](../document/level-2/) has also been updated with more articles.
- Many other details have been modified, and the documentation will become more standardized!
- Thanks to [@ricuhkaen](https://github.com/ricuhkaen), [@BioniCosmos](https://github.com/BioniCosmos), [@kirin](https://github.com/kirin10000).
- [Absolute Beginner's Guide](../document/level-0/) serialization is online! Teacher 🍉's painstaking work teaches you how to configure Xray proficiently from scratch!
- (Possibly the most detailed and patient tutorial on the whole internet teaching you to configure from 0)
- [Transparent Proxy](../document/level-2/) has also added more articles.
- There are many detail modifications, and the documentation will become more and more standardized!
- Thanks to [@ricuhkaen](https://github.com/ricuhkaen) , [@BioniCosmos](https://github.com/BioniCosmos), [@kirin](https://github.com/kirin10000)
* A lot of UDP-related fixes, now you can even play Rainbow Six Siege on Ubisoft's potato servers!
* Google Voice should now work properly when making calls with v2rayNG.
* Logs now look more pleasing to the eye.
- Extensive UDP-related fixes, you can even play Rainbow Six on Ubisoft's potato servers!
- Google Voice should also be able to make calls normally using v2rayNG.
- Logs now look more pleasing to the eye.
## 2021.01.07
- Courtesy and respect should be fundamental principles that don’t need to be explicitly stated in the community.
- Politeness and respect should be one of the unspoken rules of the community.
## 2021.01.05
- The documentation website is quietly undergoing some mysterious changes..., 🙊🙊🙊
- The documentation site is quietly undergoing some mysterious changes... 🙊🙊🙊
## 2021.01.03
- The first PR in the documentation repository. 🎉
[Transparent Proxy (TProxy) Configuration Tutorial](../document/level-2/tproxy.md), thanks to [@BioniCosmos](https://github.com/BioniCosmos).
- The TG group has surpassed 2500 members.
- First PR for the documentation repository. 🎉
[Transparent Proxy (TProxy) Configuration Tutorial](../document/level-2/tproxy.md), thanks to [@BioniCosmos](https://github.com/BioniCosmos)
- TG group exceeded 2500 members.
## 2021.01.01
[Happy New Year, Happy “Cow” Year!] 🎆🎇🎆 <Badge>[1.2.0](https://github.com/XTLS/Xray-core/releases/tag/v1.2.0)</Badge>
[Happy New Year everyone, Happy Niu (Ox) Year!] 🎆🎇🎆 <Badge>[1.2.0](https://github.com/XTLS/Xray-core/releases/tag/v1.2.0)</Badge>
🎁 In the last few minutes of New Year's Day, v1.2.0 arrived, continuing the tradition of Friday updates, bringing the hard work of all contributors and the dark circles of @rprxx—living up to expectations!
🎁 In the last few minutes of New Year's Day, v1.2.0 is here, carrying the custom of obligatory Friday updates, carrying the hard work of all contributing gurus and @rprxx's dark circles, living up to expectations!
- The New Year's gift 🎁 following the Christmas gift [v1.1.5](#_2020-12-25-1-1-5), a great benefit for gamers, full FullCone support.
- New Year's gift 🎁 following the Christmas gift [v1.1.5](#_2020-12-25-1-1-5), a big welfare for gamers, comprehensive FullCone.
- (UDP will continue to be enhanced!)
- If you’ve already opened your Christmas gift, this time there’s an even more beautifully wrapped package and little candies. (As always, no need to ask, just update and taste it)
- (No, what's below is not an ad, but a milestone.)
- Xray is the first unrestricted multi-protocol platform: Xray alone solves the problem, without relying on other implementations.
- One person handles everything! Supports all major mainstream protocols!
- Unparalleled performance!
- Continuously improving features!
- Incredible vitality and community affinity!
- Xray will continue to move forward! Therefore, [Xray needs more heroes!!](https://github.com/XTLS/Xray-core/discussions/56)!
- PS: Please taste, taste every line of the [release notes](https://github.com/XTLS/Xray-core/releases/tag/v1.2.0) carefully. It seems there's a small secret Easter egg. ~~(Ah, someone’s knocking at the door... I’ll tell you later)~~
- If you have already unwrapped the Christmas gift, this time there are even more exquisite packaging and small candies than the Christmas gift. (Again, no need to ask, just update and taste)
- (No, the following is not an advertisement, it is a milestone.)
- Xray is the first unrestricted multi-protocol platform in history: Xray alone solves the problem without relying on other implementations.
- Shouldering everything alone! Supports all major mainstream protocols!
- Performance leaving others in the dust!
- Increasingly perfect functions!
- Terrifying vitality and community affinity!
- Xray will keep moving forward! Therefore [Xray needs more heroes!!](https://github.com/XTLS/Xray-core/discussions/56)!!
- PS: Please savor, carefully savor every sentence of the [release notes](https://github.com/XTLS/Xray-core/releases/tag/v1.2.0). There seems to be a little secret easter egg ~~ (Ah, someone is knocking... I'll tell you later)~~
## 2020.12.29
Good news for gamers using transparent proxy! Xray-core TProxy inbound, SOCKS outbound UDP FullCone beta, [TG group](https://t.me/projectXray) is hotly testing.
Good news for gamers using Transparent Proxy! Xray-core tproxy inbound, socks outbound UDP FullCone beta version, currently in hot testing in [TG Group](https://t.me/projectXray).
## 2020.12.25 <Badge>[1.1.5](https://github.com/XTLS/Xray-core/releases/tag/v1.1.5)</Badge>
Merry Christmas!
- A Christmas gift for gamers! You can now enjoy gaming with Xray! Thanks to SS/trojan UDP FullCone.
- You can now write configuration files in your preferred format, such as YAML or TOML...
- (VLESS’s UDP FullCone and more enhancements are coming soon!)
- No need to worry about certificate validation being blocked anymore, OCSP stapling is now online!
- Kirin brought a wave of script updates. [Scripts here](https://github.com/XTLS/Xray-install).
- And more delicious little cherries! (No need to ask, just update and taste it)
- Christmas gift for gamers! You can play games refreshingly with xray! Because of SS/trojan UDP fullcone.
- You can write configuration files in your favorite format, such as yaml, toml...
- (VLESS UDP fullcone and more enhancements are coming soon!)
- No need to worry about certificate verification being blocked anymore, OCSP stapling is online!
- kirin brought a big wave of script updates. [Script here](https://github.com/XTLS/Xray-install)
- And more delicious little cherries! (No need to ask, just update and taste)
## 2020.12.24
For some unspeakable reasons, Xray’s documentation website was sneakily launched before the release date.
The URL is: [Yes, what you’re looking at](https://xtls.github.io).
For some indescribable reasons, the Xray documentation site has sneakily gone online before the release date.
The URL is: [Yes, what you are looking at is](https://xtls.github.io)
Everyone is welcome to check various contents and correct any errors/suggestions (can be submitted to the issue area of the documentation GitHub repository).
Everyone is welcome to check various content and correct errors/make suggestions (can be sent to the issue area of the documentation github repository).
The documentation website needs continuous improvement and content addition, as well as design refinement.
Therefore, everyone is welcome to contribute to the construction of the documentation together.
[Documentation Repository](https://github.com/XTLS/XTLS.github.io).
The documentation site needs continuous improvement and added content, as well as design refinement.
Therefore, everyone is welcome to contribute to the documentation construction.
[Documentation Repository](https://github.com/XTLS/XTLS.github.io)
There’s a brief tutorial in the repository's README explaining how to help Xray improve the documentation website.
Everyone is welcome to check it out, correct errors, modify, and add experiences.
There is a brief tutorial in the repository's readme explaining how to help xray improve the documentation site.
Welcome everyone to view, correct, modify, and add insights.
## 2020.12.23
Xray-core Shadowsocks UDP FullCone beta, [TG group](https://t.me/projectXray) is hotly testing.
Xray-core Shadowsocks UDP FullCone beta version, currently in hot testing in [TG Group](https://t.me/projectXray).
## 2020.12.21
- Project X group member count exceeds 2000.
- The group messages (including game groups) surpass 10,000 daily.
- Project X group members 2000+
- Group messages (including game group) exceed 10,000 daily
## 2020.12.18 <Badge>[1.1.4](https://github.com/XTLS/Xray-core/releases/tag/v1.1.4)</Badge>
- Lower startup memory usage and memory usage optimization.
- Customize TLS at will to improve your SSL rating.
- Added Splice support for XTLS inbound and support for trojan XTLS.
- Also, best usage mode suggestions for Splice on your router.
- Lower startup memory footprint and memory usage optimization.
- Custom TLS to improve your SSL rating.
- Support for Splice in XTLS inbound and XTLS support for Trojan.
- And suggestions for the best usage mode of Splice on your router.
## 2020.12.17
Given the growing number of group members and gaming needs, the [TG game group](https://t.me/joinchat/UO4NixbB_XDQJOUjS6mHEQ) has been launched.
Given the growing number of group members and gaming needs, a [TG Game Group](https://t.me/joinchat/UO4NixbB_XDQJOUjS6mHEQ) has been opened.
## 2020.12.15
[Installation script dev branch](https://github.com/XTLS/Xray-install/tree/dev) is now open and features are being continuously updated.
[Install script dev branch](https://github.com/XTLS/Xray-install/tree/dev) opened, features are being continuously updated.
## 2020.12.11 <Badge>[1.1.3](https://github.com/XTLS/Xray-core/releases/tag/v1.1.3)</Badge>
- Full version of REDIRECT transparent proxy mode.
- Optimization suggestions for Splice flow control mode on soft routers.
- Optimization suggestions for splice flow control mode on soft routers.
## 2020.12.06 <Badge>[1.1.2](https://github.com/XTLS/Xray-core/releases/tag/v1.1.2)</Badge>
- Added splice mode for flow control, Linux exclusive, with unparalleled performance.
- Added splice mode to flow control, Linux exclusive, performance leaves others in the dust.
- Enhanced API compatibility.
## 2020.12.04
@@ -675,19 +679,19 @@ Added splice mode.
## 2020.11.27
- Project X's GitHub main repository Xray-core has now received 500+ stars.
- Featured on GitHub Trending.
- Project X group members exceeded 1000, and channel subscribers reached 500+.
- Project X's main GitHub repository Xray-core has gained 500+ stars.
- Made it to GitHub Trending.
- Project X group members exceeded 1000, channel subscribers 500+.
## 2020.11.25 <Badge>[1.0.0](https://github.com/XTLS/Xray-core/releases/tag/v1.0.0)</Badge>
Xray’s first version.
The first version of Xray.
- Based on v2ray-core with significant modifications.
- Comprehensive enhancements, excellent performance, fully compatible.
- Modified based on v2ray-core, with significant changes.
- Comprehensive enhancement, excellent performance, fully compatible.
## 2020.11.23
project X start
> ~~When the dream begins~~
> ~~When the dream began~~
docs/en/config/api.md
+41 -36
View File
@@ -1,46 +1,51 @@
# API Interface
API interface configuration provides a set of APIs based on [gRPC](https://grpc.io/) for remote invocation.
The API interface configuration provides [gRPC](https://grpc.io/)-based API interfaces for remote procedure calls.
The interface can be enabled through the api configuration module. When the api configuration is enabled, Xray will create an outbound proxy automatically. All incoming API connections need to be manually routed to this outbound proxy through [routing rule configuration](./routing.md).
You can enable the interface through the `api` configuration module. When the `api` configuration is enabled, Xray will automatically build an outbound proxy with the same name as the `tag`. You must manually route all API inbound connections to this outbound proxy via [Routing Configuration](./routing.md). Please refer to [Relevant Configuration](#relevant-configuration) in this section.
Please refer to the [related configuration](#related-configuration) in this section.
Since [v1.8.12](https://github.com/XTLS/Xray-core/releases/tag/v1.8.12), a simplified configuration mode is supported. You only need to configure the `ApiObject`, without needing to configure `inbounds` and `routing`. However, when using the simplified configuration, the traffic statistics feature does not count the traffic of API inbound connections.
::: warning
Most users do not need to use this API. Novices can ignore this page entirely.
Most users will not need this API; beginners can skip this section.
:::
## ApiObject
`ApiObject` corresponds to the `api` item in the configuration file.
`ApiObject` corresponds to the `api` field in the configuration file.
```json
{
"api": {
"tag": "api",
"listen": "127.0.0.1:8080",
"services": ["HandlerService", "LoggerService", "StatsService"]
"services": [
"HandlerService",
"LoggerService",
"StatsService",
"RoutingService"
]
}
}
```
> `tag`: string
Outbound proxy identifier.
The identifier of the outbound proxy.
> `listen`: string
The IP and port that the API service listens on. This is an optional configuration item.
The IP and port for the API service to listen on. This is an optional configuration item.
When you omit this item, you need to add inbounds and routing configurations according to the examples in the [relevant configurations below](#related-configuration).
If this item is omitted, you need to add `inbounds` and `routing` configurations according to the example in [Relevant Configuration](#relevant-configuration) below.
> `services`: [string]
> `services`: \[string\]
List of enabled APIs, optional values can be found in [Supported API List](#supported-api-list).
The list of enabled APIs. See [API List](#supported-api-list) for available values.
## Related Configuration
## Relevant Configuration
An api inbound can be added to the inbounds configuration.
You can add an `api` inbound in the `inbounds` configuration:
```json
"inbounds": [
@@ -56,7 +61,7 @@ An api inbound can be added to the inbounds configuration.
]
```
Add routing rules for the api inbound in the routing configuration.
Add a routing rule for the `api` inbound in the `routing` configuration:
```json
"routing": {
@@ -71,7 +76,7 @@ Add routing rules for the api inbound in the routing configuration.
}
```
Add api to basic configuration
Add `api` in the basic configuration:
```json
"api": {
@@ -86,40 +91,40 @@ Add api to basic configuration
### HandlerService
APIs that modify the inbound and outbound proxies, with the following available functions:
APIs for modifying inbound and outbound proxies. Available functions are as follows:
- Add a new inbound proxy;
- Add a new outbound proxy;
- Delete an existing inbound proxy;
- Delete an existing outbound proxy;
- List inbound proxies;
- List outbound proxies;
- Add a user to an inbound proxy (VMess, VLESS, Trojan, and Shadowsocks(v1.3.0+) only);
- Delete a user from an inbound proxy (VMess, VLESS, Trojan, and Shadowsocks(v1.3.0+) only);
- Add a new inbound;
- Add a new outbound;
- Remove an existing inbound;
- Remove an existing outbound;
- List outbounds;
- List inbounds;
- Add a user to an inbound (supports VMess, VLESS, Trojan, Shadowsocks only);
- Remove a user from an inbound (supports VMess, VLESS, Trojan, Shadowsocks only);
## RoutingService
### RoutingService
API for adding, deleting, and replacing routing rules and querying equalizer statistics. The available functions are as follows:
APIs for adding, removing, replacing routing rules, and querying balancer statistics. Available functions are as follows:
- `adrules` adds and replaces routing configuration
- `rmrules` delete routing rules
- `sib` Disconnect source IP
- `bi` Query equalizer statistics
- `bo` Forces the equalizer to select the specified outboundTag
- `adrules`: Add or replace routing configuration
- `rmrules`: Remove routing rules
- `sib`: Disconnect connections from a source IP
- `bi`: Query balancer statistics
- `bo`: Force balancer to select a specific `outboundTag`
You can use something like `./xray help api bi` to query the specific usage.
You can use commands like `./xray help api bi` to query specific usage.
### LoggerService
Supports restarting the built-in logger, which can be used in conjunction with logrotate to perform operations on log files.
Supports restarting the built-in Logger, which can be used with `logrotate` to perform operations on log files.
### StatsService
Built-in data statistics service, see [Statistics Information](./stats.md) for details.
Built-in data statistics service. See [Statistics](./stats.md) for details.
### ReflectionService
Supports gRPC clients to obtain the list of APIs from the server.
Allows gRPC clients to retrieve the list of APIs on the server.
```bash
$ grpcurl -plaintext localhost:10085 list
@@ -130,6 +135,6 @@ xray.app.proxyman.command.HandlerService
xray.app.stats.command.StatsService
```
## API Calling Example
## API Call Examples
[Xray-API-documents](https://github.com/XTLS/Xray-API-documents) @crossfw
docs/en/config/dns.md
+163 -119
View File
@@ -2,42 +2,46 @@
## DNS Server
The DNS module built into Xray has two main purposes:
The built-in DNS module in Xray has three main purposes:
- During the routing phase, it resolves domain names to IP addresses and performs traffic splitting based on the results of domain name resolution and the value of `domainStrategy` in the routing configuration module. The built-in DNS server is only used for DNS queries when either of the following values is set:
- "IPIfNonMatch": When a domain name is requested, it first tries to match it against the `domain` entries in the routing configuration. If no match is found, the built-in DNS server is used to perform a DNS query for the domain name, and the returned IP address is used to perform IP routing matching again.
- "IPOnDemand": When a domain name is matched against any IP-based rule, it is immediately resolved to an IP address for matching.
- It resolves the target address for connection.
- In the `freedom` outbound setting, if `domainStrategy` is set to `UseIP`, requests made through the outbound proxy will first resolve the domain name to an IP address using the built-in server before making the connection.
- In the `sockopt` setting, if `domainStrategy` is set to `UseIP`, system connections initiated through the outbound proxy will first be resolved to an IP address using the built-in server before making the connection.
- **Routing Phase:** Resolves domain names to IPs and matches rules based on the resolved IPs for traffic splitting. Whether to resolve the domain and split traffic depends on the `domainStrategy` setting in the routing configuration module. The built-in DNS server is used for DNS queries only when the following two values are set:
- `"IPIfNonMatch"`: When a domain is requested, Xray attempts to match it against the `domain` rules in the routing configuration. If no match is found, the built-in DNS server is used to resolve the domain, and the returned IP address is used to match against IP routing rules.
- `"IPOnDemand"`: When any IP-based rule is encountered during matching, the domain is immediately resolved to an IP for matching.
- **Resolving Target Addresses for Connections:**
- For example, in a `freedom` outbound, if `domainStrategy` is set to `UseIP`, requests sent from this outbound will first resolve the domain to an IP using the built-in server before connecting.
- For example, in `sockopt`, if `domainStrategy` is set to `UseIP`, system connections initiated by this outbound will first resolve to an IP using the built-in server before connecting.
- **DNS Traffic Hijacking (Transparent Proxy) or Acting as a Recursive DNS Server:** Directly exposing port 53 to serve as a DNS server.
::: tip TIP 1
DNS queries sent by the built-in DNS server are automatically forwarded based on the routing configuration.
DNS query requests sent by the built-in DNS server will be automatically forwarded according to the routing configuration.
:::
::: tip TIP 2
Only basic IP queries (A and AAAA records) are supported. CNAME records will be queried repeatedly until an A/AAAA record is returned. Other queries will not enter the built-in DNS server.
Only basic IP queries (A and AAAA records) are supported. CNAME records will be queried repeatedly until an A/AAAA record is returned. Other queries will not enter the built-in DNS server; instead, they may be discarded or transparently forwarded to other servers depending on your outbound configuration.
:::
## DNS Processing Flow
If the domain name to be queried:
If the domain currently being queried:
- Matches the mapping of "domain name - IP" or "domain name - IP array" in the `hosts`, then the IP or IP array will be returned as the DNS resolution result.
- Matches the mapping of "domain name - domain name" in the `hosts`, then the value of this mapping (another domain name) will be used as the domain name to be queried, and enter the DNS processing flow until an IP is resolved and returned, or an empty resolution is returned.
- Does not match `hosts`, but matches the `domains` list in one or more DNS servers, then according to the priority of the matching rule, use the DNS server corresponding to the rule to perform the query in sequence. If the DNS server that is hit fails to query or `expectedIPs` does not match, then use the next hit DNS server to perform the query. Otherwise, return the resolved IP. If all hit DNS servers fail to query or `expectedIPs` does not match, then the DNS component:
- By default, it will perform "DNS fallback query": use the "DNS server that has not been used in the last failed query and has a default value of `false` for `skipFallback`" to perform the query in sequence. If the query fails or `expectedIPs` does not match, return an empty resolution; otherwise, return the resolved IP.
- If `disableFallback` is set to `true`, "DNS fallback query" will not be performed.
- If neither `hosts` nor the `domains` list in DNS servers matches, then:
- By default, use the "DNS server that has a default value of `false` for `skipFallback`" to perform the query in sequence. If the first selected DNS server fails to query or `expectedIPs` does not match, then use the next selected DNS server to perform the query. Otherwise, return the resolved IP. If all selected DNS servers fail to query or `expectedIPs` does not match, return an empty resolution.
- If the number of "DNS servers that have a default value of `false` for `skipFallback`" is 0 or `disableFallback` is set to `true`, use the first DNS server in the DNS configuration to perform the query. If the query fails or `expectedIPs` does not match, return an empty resolution; otherwise, return the resolved IP.
- Matches a "Domain - IP" or "Domain - IP Array" mapping in `hosts`, that IP or IP array is returned as the DNS resolution result.
- Matches a "Domain - Domain" mapping in `hosts`, the mapped value (another domain) becomes the domain to be queried, re-entering the DNS processing flow until an IP is resolved or an empty response is returned.
- Does **not** match `hosts`, but matches the `domains` list of one or more DNS servers:
- It will query the corresponding DNS servers in the order of the matching rules' priority.
- If a matched DNS server fails to query or the `expectedIPs` do not match, the next matched DNS server is used.
- If successful, the resolved IP is returned.
- If all matched DNS servers fail or `expectedIPs` do not match, the DNS component will:
- By default, perform a "DNS Fallback Query": Sequentially query "DNS servers that were not used in the previous failed round and have `skipFallback` set to the default `false`". If these queries fail or `expectedIPs` do not match, an empty response is returned; otherwise, the resolved IP is returned.
- If `disableFallback` is set to `true`, the "DNS Fallback Query" will not be performed.
- Matches **neither** `hosts` **nor** the `domains` list of any DNS server:
- By default, it sequentially queries "DNS servers where `skipFallback` is default `false`". If the first selected DNS server fails or `expectedIPs` do not match, the next selected server is used; otherwise, the resolved IP is returned. If all selected servers fail, an empty response is returned.
- If the count of "DNS servers where `skipFallback` is `false`" is 0, or if `disableFallback` is set to `true`, the first DNS server in the DNS configuration is used. If it fails or `expectedIPs` do not match, an empty response is returned; otherwise, the resolved IP is returned.
## DnsObject
`DnsObject` corresponds to the `dns` section in the configuration file.
`DnsObject` corresponds to the `dns` field in the configuration file.
```json
{
@@ -58,13 +62,13 @@ If the domain name to be queried:
"clientIP": "1.2.3.4"
},
{
"address": "https://1.1.1.1/dns-query",
"address": "[https://8.8.8.8/dns-query](https://8.8.8.8/dns-query)",
"domains": ["geosite:netflix"],
"skipFallback": true,
"queryStrategy": "UseIPv4"
},
{
"address": "https://1.1.1.1/dns-query",
"address": "[https://1.1.1.1/dns-query](https://1.1.1.1/dns-query)",
"domains": ["geosite:openai"],
"skipFallback": true,
"queryStrategy": "UseIPv6"
@@ -74,8 +78,11 @@ If the domain name to be queried:
"clientIp": "1.2.3.4",
"queryStrategy": "UseIP",
"disableCache": false,
"serveStale": false,
"serveExpiredTTL": 0,
"disableFallback": false,
"disableFallbackIfMatch": false,
"enableParallelQuery": false,
"useSystemHosts": false,
"tag": "dns_inbound"
}
@@ -84,140 +91,169 @@ If the domain name to be queried:
> `hosts`: map{string: address} | map{string: [address]}
A list of static IP addresses, with values consisting of a series of "domain": "address" or "domain": ["address 1","address 2"]. The address can be an IP or a domain name. When resolving a domain name, if the domain name matches an item in this list:
A list of static IPs. The value is a series of `"domain": "address"` or `"domain": ["address 1", "address 2"]`. The address can be an IP or a domain. When resolving a domain, if the domain matches an item in this list:
- If the address of the item is an IP, the resolution result will be that IP.
- If the address of the item is a domain name, this domain name will be used for IP resolution instead of the original domain name.
- If multiple IPs and domain names are set in the address, only the first domain name will be returned, and the rest of the IPs and domain names will be ignored.
- If the address of the item is an IP, the resolution result is that IP.
- If the address of the item is a domain, this domain will be used for IP resolution instead of the original domain.
- If multiple IPs and domains are set in the address list simultaneously, only the first domain is returned, and the remaining IPs and domains are ignored.
- If the first value in the address starts with a hash followed by a number (e.g., `#3`), and it is used in a DNS outbound, the core will return an empty response with the corresponding rcode number to reject the request. If the request comes from an internal query, it will simply be treated as a failure.
- When the resolved domain matches multiple domains in the list, all associated IPs are returned.
The domain name can take several forms:
The matching format (`domain:`, `full:`, etc.) is the same as the domain in the commonly used [Routing System](./routing.md#ruleobject). The difference is that without a prefix, it defaults to using the `full:` prefix (similar to the common hosts file syntax).
- Plain string: When this string matches the target domain name exactly, the rule takes effect. For example, "xray.com" matches "xray.com" but not "www.xray.com".
- Regular expression: Starting with `"regexp:"`, the rest is a regular expression. When this regular expression matches the target domain name, the rule takes effect. For example, "regexp:\\\\.goo.\*\\\\.com$" matches "www.google.com" and "fonts.googleapis.com", but not "google.com".
- Subdomain (recommended): Starting with `"domain:"`, the rest is a domain name. When this domain name is the target domain name or its subdomain, the rule takes effect. For example, "domain:xray.com" matches "www.xray.com" and "xray.com", but not "wxray.com".
- Substring: Starting with `"keyword:"`, the rest is a string. When this string matches any part of the target domain name, the rule takes effect. For example, "keyword:sina.com" can match "sina.com", "sina.com.cn", and "www.sina.com", but not "sina.cn".
- Predefined domain name list: Starting with `"geosite:"`, the rest is a name, such as `geosite:google` or `geosite:cn`. The names and domain name lists are listed in [Predefined Domain Name Lists](./routing.md#predefined-domain-lists).
> `servers`: \[string | [DnsServerObject](#dnsserverobject) \]
> `servers`: [string | [DnsServerObject](#dnsserverobject) ]
A list of DNS servers. Two types are supported: DNS address (string format) and [DnsServerObject](#dnsserverobject).
A list of DNS servers that supports two types: DNS addresses (in string format) and [DnsServerObject](#dnsserverobject).
When the value is `"localhost"`, it indicates using the local machine's preset DNS configuration.
When the value is `"localhost"`, it means to use the default DNS configuration on the local machine.
When the value is a DNS `"IP:Port"` address, such as `"8.8.8.8:53"`, Xray will use the specified UDP port of this address for DNS queries. The query follows routing rules. If no port is specified, port 53 is used by default.
When the value is a DNS `"IP:Port"` address, such as `"8.8.8.8:53"`, Xray will use the specified UDP port of this address for DNS queries. The query follows the routing rules. When the port is not specified, the default port 53 is used.
When the value is in the form of `"tcp://host:port"`, such as `"tcp://8.8.8.8:53"`, Xray will use `DNS over TCP` for queries. The query follows routing rules. If no port is specified, port 53 is used by default.
When the value is in the form of `"tcp://host:port"`, such as `"tcp://8.8.8.8:53"`, Xray will use `DNS over TCP` for queries. The query follows the routing rules. When the port is not specified, the default port 53 is used.
When the value is in the form of `"tcp+local://host:port"`, such as `"tcp+local://8.8.8.8:53"`, 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 `"tcp+local://host:port"`, such as `"tcp+local://8.8.8.8:53"`, Xray will use `TCP local mode (TCPL)` for queries. That is, DNS requests will not pass through the routing component and will directly request outbound through Freedom, to reduce latency. When the port is not specified, the default port 53 is used.
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://host:port/dns-query"`, such as `"https://dns.google/dns-query"`, Xray will use `DNS over HTTPS` (RFC8484, abbreviated as DOH) for queries. Some service providers have certificates with IP aliases, 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 `"h2c://host:port/dns-query"`, such as `"h2c://dns.google/dns-query"`, Xray will use the `DNS over HTTPS` request format but will send the request in cleartext h2c. This cannot be used directly; in this case, you need to configure a Freedom outbound + streamSettings with TLS to wrap it into a normal DOH request. This is used for special purposes, such as customizing the SNI of DOH requests or using utls fingerprints.
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. That is, DOH requests will not pass through the routing component and will directly request outbound through Freedom, to reduce latency. This is generally suitable for use on the server side. 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"`, such as `"quic+local://dns.adguard.com"`, Xray will use `DNS over QUIC local mode (DOQL)` for queries. That is, DNS requests will not pass through the routing component and will directly request outbound through Freedom. This method requires DNS server support for DNS over QUIC. The default port 853 is used for queries, and non-standard ports can also be used.
When the value is in the form of `"quic+local://host"`, such as `"quic+local://dns.adguard.com"`, Xray will use `DNS over QUIC 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`, the FakeDNS function will be used for queries.
When the value is `fakedns`, the FakeDNS feature will be used for queries.
::: tip TIP 1
When using `localhost`, DNS requests on the local machine are not controlled by Xray and additional configuration is required to make DNS requests forwarded by Xray.
When using `localhost`, the local machine's DNS requests are not controlled by Xray. Additional configuration is required to forward DNS requests through Xray.
:::
::: tip TIP 2
DNS clients initialized with different rules will be reflected in the Xray startup log at the `info` level, such as `local DOH`, `remote DOH`, and `udp` modes.
The DNS clients initialized by different rules will be shown in the Xray startup logs at the `info` level, such as `local DOH`, `remote DOH`, and `udp` modes.
:::
::: tip TIP 3
(v1.4.0+) DNS query logging can be enabled in the [log](./log.md).
(v1.4.0+) You can enable DNS query logging in [Log](./log.md).
:::
> `clientIp`: string
Used to notify the server of the specified IP location during DNS queries. Cannot be a private address.
The IP address used in the EDNS Client Subnet extension.
::: tip TIP 1
EDNS Client Subnet support is required for the DNS server.
:::
::: tip TIP 2
You can specify `clientIp` for all DNS servers in [DnsObject](#dnsobject), or specify it for each DNS server in the configuration of [DnsServerObject](#dnsserverobject) (which has higher priority than the configuration in [DnsObject](#dnsobject)).
:::
Must be a valid IPv4 or IPv6 address. When actually sent, the last few bits will be automatically masked; IPv4 and IPv6 are sent with /24 and /96 subnets respectively.
> `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.
Limits the capabilities of all servers in the DNS module and sets 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.
The default value `UseIP` allows querying both A + AAAA records. When a query initiated by Xray itself does not specify an IP type, both A and AAAA records are queried from the upstream DNS server. `UseIPv4` only queries and allows querying A records; `UseIPv6` only queries and allows querying AAAA records.
Xray-core v1.8.6 New feature: `queryStrategy` can be set separately for each `DNS` server.
`UseSystem` adapts to the operating system's network environment. Before querying, it checks whether there are IPv4 and IPv6 default gateways, thereby limiting the capabilities of all servers and setting the default query type. It checks in real-time on graphical OS environments and only once on command-line environments.
```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://1.1.1.1/dns-query",
"address": "[https://8.8.8.8/dns-query](https://8.8.8.8/dns-query)",
"domains": [
"geosite:netflix"
],
"skipFallback": true,
"queryStrategy": "UseIPv4" // geosite:netflix's domain name uses "UseIPv4"
"queryStrategy": "UseIPv4" // netflix domain queries A record
},
{
"address": "https://1.1.1.1/dns-query",
"address": "[https://1.1.1.1/dns-query](https://1.1.1.1/dns-query)",
"domains": [
"geosite:openai"
],
"skipFallback": true,
"queryStrategy": "UseIPv6" // The domain name geosite:openai uses "UseIPv6".
"queryStrategy": "UseIPv6" // openai domain queries AAAA record
}
],
"queryStrategy": "UseIP" // Global use of "UseIP"
"queryStrategy": "UseIP" // Globally query both A and AAAA records
}
```
**NOTE：**<br>
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:<br>
Global `"queryStrategy": "UseIPv6"` conflicts with sub-item `"queryStrategy": "UseIPv4"`.<br>
Global `"queryStrategy": "UseIPv4"` conflicts with sub-item `"queryStrategy": "UseIPv6"`.<br>
Global `"queryStrategy": "UseIP"` does not conflict with sub-item `"queryStrategy": "UseIPv6"`.<br>
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
docs/en/config/fakedns.md
+26 -26
View File
@@ -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
{
docs/en/config/features/browser_dialer.md
+29 -29
View File
@@ -1,53 +1,53 @@
# Browser Dialer
<Badge text="BETA" type="warning"/> <Badge text="v1.4.1+" type="warning"/>
## Background
Xray generally uses uTLS to mimic the behavior of popular browsers, and it can be controlled through the `fingerprint` setting. However, the fingerprints produced by uTLS are an imperfect replica of the real thing, and because uTLS is a popular library, they may be targeted themselves.
Through uTLS, Xray can simulate the TLS handshake fingerprints of mainstream browsers (see the `fingerprint` option in TLS for details). However, it still cannot guarantee that the simulated browser behavior is perfectly consistent with a real browser at all times.
So [the idea of browser dialer](https://github.com/v2ray/discussion/issues/754#issuecomment-647934994) is that Xray uses a real browser to establish TLS connections. The way this works is that Xray hosts a small website on `localhost:8080`, the user opens this website in a browser of their choice, and JavaScript on that page will act as Xray's networking stack (HTTP client, TLS client).
In response to this, the [Browser Dialer](https://github.com/v2ray/discussion/issues/754#issuecomment-647934994) was created. Users open a page at `localhost:8080` in their own browser. This page uses native JS to act as Xray's network stack, establishing TLS and HTTP connections with the proxy server.
The TLS fingerprinting behavior is perfect this way, and so it may be possible to revive servers that open fine as websites in the browser, but do not connect using any proxying software.
This method concisely implements real browser TLS fingerprints and behavioral characteristics, providing maximum anti-detection and anti-blocking capabilities.
However, there are many drawbacks:
However, the current Browser Dialer has the following drawbacks:
- The user has to launch a browser next to the Xray client just for opening the proxy connection.
- The browser dialer must not be tunneled through the proxy itself, otherwise there is a loop. TUN users should be cautious.
- The browser can only speak standard HTTP, which means that only [WebSocket](../transports/websocket.md) and [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) are supported
- [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) needs to be considered when making requests from one website (`localhost:8080`) to another (`proxy.example.com:443`)
- The browser tunnels your traffic using JavaScript, so there is a significant performance penalty (or, battery drain)
- The configuration to be used with browser dialer cannot use custom SNI or host headers. `SNI == host == address`. Custom HTTP headers and `tlsSettings` are ignored entirely.
- Users need to manually open the browser.
- Connections initiated by the browser must be direct. Users using `tun` need to pay special attention to avoid creating infinite routing loops.
- The browser can only initiate HTTP connections, so currently, only [WebSocket](../transports/websocket.md) and [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) transport methods are supported.
- When the browser connects from the `localhost:8080` page to the proxy server, [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) needs to be considered.
- Since data is processed via JS, there will be some performance overhead.
- Custom SNI or Host cannot be used; that is, `SNI == host == address`. Custom HTTP headers and other `tlsSettings` items will be ignored.
## Configuration
## Configuration Method
1. Prepare a usable WebSocket or XHTTP configuration. Be aware of the above restrictions.
2. Launch Xray with `XRAY_BROWSER_DIALER=127.0.0.1:8080`. On Windows, this can be done as `set XRAY_BROWSER_DIALER=...` and then launching the core from the console, on Linux the core can be launched as `XRAY_BROWSER_DIALER=127.0.0.1:8080 ./xray -c config.json`.
3. Open a browser that is not tunneled through the proxy, or modify the config's routing such that the Xray server's domain goes to `freedom` directly from the client. Browse to `localhost:8080`, and open the developer console with `F12` to monitor for errors.
4. For better performance and to bypass arbitrary connection limits enforced by the browser, it is recommended to enable `Mux.Cool`.
1. Prepare a WebSocket or XHTTP configuration. Note that the `address` must be a domain name. If you need to specify an IP, please configure DNS or the system `hosts` file.
2. Start Xray using the environment variable `XRAY_BROWSER_DIALER=127.0.0.1:8080`.
- On Windows: `set XRAY_BROWSER_DIALER=127.0.0.1:8080`
- On Linux: `XRAY_BROWSER_DIALER=127.0.0.1:8080 ./xray -c config.json`
3. Ensure the browser connects directly (or configure the routing so that the server address is sent directly via `freedom`). Open the page `localhost:8080`. You can also use `F12` to check `Console` and `Network`.
4. Browsers limit the number of outbound connections, so it is recommended to enable `Mux.Cool`.
## Inner workings
## Internal Communication Mechanism
- Xray listens on `http://127.0.0.1:8080`, and the browser accesses `http://127.0.0.1:8080` to load the `JS` in the webpage.
- The `JS` actively establishes a WebSocket connection to `http://127.0.0.1:8080`. Xray will use this connection to send instructions, but for now it goes into a connection pool (implemented as Go channel).
- When a connection needs to be established, Xray receives an available connection from the pool and sends the protocol name, target URL and optional early data.
- Once the `JS` successfully connects to the target, it informs Xray and continues to use this conn to bi-directionally forward data.
- After the connection to the server is closed, the connection to localhost is also closed, but the JS ensures that there is always at least one idle connection available.
- Xray listens on the address/port `http://127.0.0.1:8080` as an HTTP server. The browser visits this address and loads the JS in the webpage.
- The JS actively establishes a WebSocket connection to `http://127.0.0.1:8080`. Upon success, Xray sends the connection to a channel.
- When a connection needs to be established, Xray retrieves an available connection from the channel and sends the target URL and optional early data.
- After the JS successfully connects to the target, it notifies Xray and continues to use this connection to forward data in full-duplex mode. Connection closure is synchronized.
- The connection is closed after use, but the JS ensures that new idle connections are always available.
## WebSocket
<Badge text="v1.4.1+" type="warning"/>
According to the browser's needs, the early data mechanism has been adjusted as follows:
Based on browser requirements, the following adjustments were made to the early data mechanism:
- The server response header will contain the requested `Sec-WebSocket-Protocol`, which also initially obfuscates the length characteristic of the WSS handshake response.
- The encoding used for early data for browsers is `base64.RawURLEncoding` instead of `StdEncoding`, and the server has made it compatible.
- In addition, due to [Xray-core#375](https://github.com/XTLS/Xray-core/pull/375) recommendations for `?ed=2048`, this PR also increased server `MaxHeaderBytes` by 4096. ~~(Although it seems like it would work without modification.)~~
- The server response header will carry the requested `Sec-WebSocket-Protocol`, which preliminarily obfuscates the length characteristics of the WSS handshake response.
- The early data encoding used for browsers is `base64.RawURLEncoding` instead of `StdEncoding`. The server has made compatibility adjustments.
- Additionally, due to [Xray-core#375](https://github.com/XTLS/Xray-core/pull/375) recommending `?ed=2048`, this PR also expanded a `MaxHeaderBytes` limit on the server side to 4096. ~~ (Although it seems fine without changing it) ~~
## XHTTP
<Badge text="v1.8.19+" type="warning"/>
[XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) supports QUIC, but the browser's own QUIC stack may be used as well. In Chrome this can be done through `chrome://flags`, in other browsers it may already be enabled or need a different flag.
[XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) itself supports QUIC. If you want to use the browser's own QUIC network stack, Chrome users can configure it in `chrome://flags`. Other browsers also have relevant options.
In general, `tlsSettings` are completely ignored when Browser Dialer is used. Xray does not have any control over which HTTP version the browser selects.
In principle, `tlsSettings` items will be ignored, and the HTTP version used will be determined entirely by the browser.
docs/en/config/features/env.md
+32 -11
View File
@@ -1,13 +1,14 @@
# Environment Variables
Xray provides the following environment variables for modifying some of its underlying configurations.
Xray provides the following environment variables to modify some underlying configurations of Xray.
## Xray Asset Location
## Resource File Path
- Name：`xray.location.asset` or `XRAY_LOCATION_ASSET`。
- Default value：specified [FHS](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) directory or the same path as the Xray file.
- Name: `xray.location.asset` or `XRAY_LOCATION_ASSET`.
- Default value: Specific [FHS](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) directories or the same path as the Xray executable.
This environment variable specifies a folder location that should contain the `geoip.dat` and `geosite.dat` files. If no variable value is specified, the program will search for resource files in the following order:
This environment variable specifies a folder location that should contain the `geoip.dat` and `geosite.dat` files.
If no variable value is specified, the program will look for resource files in the following order:
```
./
@@ -17,14 +18,34 @@ This environment variable specifies a folder location that should contain the `g
## Configuration File Location
- Name：`xray.location.config` or `XRAY_LOCATION_CONFIG`。
- Default value: Same path as the Xray file.
- Name: `xray.location.config` or `XRAY_LOCATION_CONFIG`.
- Default value: The same path as the Xray executable.
This environment variable specifies a folder location that should contain the `config.json` file.
## Multiple Configuration Directories
## Multiple Configuration Directory
- Name：`xray.location.confdir` or `XRAY_LOCATION_CONFDIR`。
- Default value：`""`。
- Name: `xray.location.confdir` or `XRAY_LOCATION_CONFDIR`.
- Default value: `""`.
The `.json` files in this directory will be read in alphabetical order by filename and used as options for multiple configurations.
The `.json` files in this directory will be read in alphabetical order of their filenames as multiple configuration options.
This item has lower priority than the startup argument `confdir`.
## Other Available Configurations
- xray.location.plugin
- xray.location.tool
- xray.location.cert
- xray.buf.readv
- xray.buf.splice
- xray.vmess.padding
- xray.cone.disabled
- xray.ray.buffer.size
- xray.browser.dialer
- xray.xudp.show
- xray.xudp.basekey
These options are open to users with special needs; you can read the source code to discover their usage. ~PR Welcome~
docs/en/config/features/fallback.md
+38 -34
View File
@@ -1,14 +1,14 @@
# Fallback
> **Fallback is one of the most powerful features of Xray, which can effectively prevent active probing and allows you to use one port for multiple services**
> **Fallback is one of Xray's most powerful features, effectively preventing active probing and allowing multiple services to share common ports.**
Fallback provides Xray with high-strength anti-active probing capabilities and has a unique first-packet fallback mechanism.
Fallback provides Xray with high-strength resistance against active probing and features a unique first-packet fallback mechanism.
Fallback can also divide traffic of different types based on path for multi-service sharing on a single port.
Fallback can also split different types of traffic based on `path`, allowing a single port to be shared by multiple services.
Currently, you can use the fallback feature by configuring fallbacks when using VLESS or Trojan protocols, thus creating an unimaginable combo of services becomes REALITY.
Currently, you can use the fallback feature by configuring `fallbacks` when using VLESS or Trojan protocols, allowing for very rich configuration combinations.
## fallbacks configuration
## Fallbacks Configuration
```json
"fallbacks": [
@@ -20,7 +20,7 @@ Currently, you can use the fallback feature by configuring fallbacks when using
> `fallbacks`: \[ [FallbackObject](#fallbackobject) \]
**`fallbacks` is an array, and here is an example configuration of one of its child elements.**
An array containing a series of powerful fallback distribution configurations.
### FallbackObject
@@ -34,65 +34,69 @@ Currently, you can use the fallback feature by configuring fallbacks when using
}
```
The `fallbacks` object is optional and can only be used for the `TCP+TLS` transport combination.
**`fallbacks` is an array; this is the configuration description for one of its child elements.**
- When `fallbacks` configure with any child elements，`"alpn":["http/1.1"]` needs to be configured in [Inbound TLS](../transport.md#tlsobject).
The `fallbacks` item is optional and can only be used with the TCP+TLS transport combination.
Usually, you need to set up a default fallback with both `alpn` and `path` omitted or empty, and then configure other routing rules as needed.
- When this item has child elements, [Inbound TLS](../transport.md#tlsobject) must set `"alpn":["http/1.1"]`.
VLESS will forward traffic with TLS decrypted first packet length <18, invalid protocol version, or failed authentication to the address specified by `dest`.
Usually, you need to first set a default fallback with both `alpn` and `path` omitted or empty, and then configure other traffic splitting as needed.
For other transport combinations, you must remove the `fallbacks` object or all its child elements. At this point, no `fallbacks` will be enabled, and VLESS will wait until it reads enough data. If the protocol version is invalid or authentication fails, the connection will be terminated directly.
VLESS will forward traffic to the address specified by `dest` if, after TLS decryption, the first packet length is < 18, the protocol version is invalid, or authentication fails.
For other transport combinations, the `fallbacks` item or all child elements must be deleted. In this case, Fallback will not be enabled. VLESS will wait to read the required length, and if the protocol version is invalid or authentication fails, it will directly disconnect.
> `name`: string
Attempt to match the TLS SNI (Server Name Indication), where an empty value matches any SNI. The default value is `""`, which means empty value.
Attempts to match TLS SNI (Server Name Indication). Empty means any. Default is `""`.
> `alpn`: string
Attempt to match the result of TLS ALPN negotiation, where an empty value matches any ALPN result. The default value is `""` , which means empty value.
Attempts to match the TLS ALPN negotiation result. Empty means any. Default is `""`.
VLESS will read the TLS ALPN negotiation result only when necessary. If successful, it will output `realAlpn =` info to the log.
Purpose: To solve the problem of Nginx's inability to simultaneously support http/1.1 and h2c services. Nginx needs to write two lines of listen, one for 1.1 and one for h2c.
Note: When `"h2"` is included in fallbacks alpn, the Inbound TLS needs to be set as `"alpn":["h2","http/1.1"]` to support `h2` access.
Xray will only attempt to read the TLS ALPN negotiation result when necessary. If successful, it outputs `realAlpn =` to the info log.
Usage: Solves the issue where Nginx's h2c service cannot be compatible with http/1.1 simultaneously. Nginx would require two `listen` lines, for 1.1 and h2c respectively.
Note: When `fallbacks` `alpn` contains `"h2"`, [Inbound TLS](../transport.md#tlsobject) needs to set `"alpn":["h2","http/1.1"]` to support h2 access.
::: tip
The `alpn` set in the Fallback is used to match the actual negotiated ALPN, while the `alpn` set in the Inbound TLS represents the list of optional ALPNs during the handshake. These two have different meanings.
The `alpn` set in Fallback matches the *actually negotiated* ALPN, whereas the `alpn` set in Inbound TLS is the list of *optional* ALPNs during the handshake. The meanings are different.
:::
> `path`: string
Attempt to match the first packet HTTP PATH, where an empty value matches any PATH and a default value is empty. If non-empty, it must start with `/`, and h2c is not supported.
Attempts to match the HTTP PATH of the first packet. Empty means any. Default is empty. If non-empty, it must start with `/`. h2c is not supported.
Smart: VLESS will only attempt to check the PATH (no more than 55 bytes; the fastest algorithm that does not fully parse HTTP) when necessary. If successful, it will output `realPath =` in the INFO log.
Purpose: To route other inbound WebSocket traffic or HTTP disguised traffic, without additional processing, purely forwarding traffic, and theoretically better performance than Nginx.
Smart: Xray will only attempt to peek at the PATH when necessary (not exceeding 55 bytes; uses the fastest algorithm, does not fully parse HTTP). If successful, it outputs the INFO log `realPath =`.
Usage: Offloading WebSocket traffic or HTTP camouflage traffic from other inbounds. It performs pure traffic forwarding without extra processing. Theoretical performance is stronger than Nginx.
Note: **The inbound where fallbacks is located must be TCP+TLS**. This is for routing to other WebSocket inbound, while the inbound being routed doesn't need to configure TLS.
Note: **The inbound where fallbacks is located must itself be TCP+TLS**. This is used for offloading to other WS inbounds; the offloaded inbound does not need to configure TLS.
> `dest`: string | number
Determines the destination of decrypted TLS TCP traffic, which currently supports two types of addresses: (this field is required, otherwise it cannot be started)
Decides the destination of the TCP traffic after TLS decryption. Currently supports two types of addresses: (This item is mandatory, otherwise it will not start)
1. TCP, in the format of `"addr:port"`, where addr supports IPv4, domain names, and IPv6. If a domain name is entered, a direct TCP connection will be made (rather than using the built-in DNS resolver).
2. Unix domain socket, in the format of an absolute path, such as `"/dev/shm/domain.socket"`, which can be prefixed with `@` to represent [abstract](https://www.man7.org/linux/man-pages/man7/unix.7.html), and `@@` to represent padded abstract.
1. TCP, formatted as `"addr:port"`, where `addr` supports IPv4, domain name, and IPv6. If a domain name is filled, a TCP connection will be initiated directly (without going through the built-in DNS).
2. Unix domain socket, formatted as an absolute path, like `"/dev/shm/domain.socket"`. Can handle [abstract](https://www.man7.org/linux/man-pages/man7/unix.7.html) by adding `@` at the beginning, or `@@` for abstract with padding.
If only the port is specified, both numbers and strings are accepted, such as `80` or `"80"`. This usually points to a plaintext HTTP service (and the addr will be filled in as `"127.0.0.1"`).
If only `port` is filled, it can be a number or a string, like `80` or `"80"`. It usually points to a cleartext http service (`addr` will be filled as `"localhost"`).
Note: Only after v25.7.26 does a `dest` containing only a port point to `localhost`. Before this, it was `127.0.0.1`. After the change, the actual target is likely `::1`. Some webserver templates copied online might listen on `::1` but only allow `127` to enter or apply the proxy protocol, which may lead to different behaviors.
> `xver`: number
Sends the [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) protocol, which is used to transmit the real source IP and port of the request. The version can be set to `1` or `2`, with a default value of `0`, which means no PROXY protocol is sent. Version `1` is recommended if needed.
Sends [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt), specifically used to pass the real source IP and port. Fill 1 or 2. Default is 0, meaning it is not sent. It is recommended to fill 1 if needed.
Currently, versions `1` and `2` have the same functionality but different structures, where version `1` is printable while version 2 is `binary`. Xray's `TCP` and `WebSocket` inbound already support receiving the PROXY protocol.
Currently, filling 1 or 2 functions identically, only the structure differs (the former is printable, the latter is binary). Both TCP and WS inbounds in Xray support receiving PROXY protocol.
::: warning
If you are [configuring Nginx to receive the PROXY protocol](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#configuring-nginx-to-accept-the-proxy-protocol), you need to not only set `proxy_protocol`, but also `set_real_ip_from` to avoid potential issues.
If you are [configuring Nginx to accept PROXY protocol](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#configuring-nginx-to-accept-the-proxy-protocol), besides setting `proxy_protocol`, you also need to set `set_real_ip_from`, otherwise issues may occur.
:::
### Additional Information
### Supplementary Explanation
- Matches the most precise sub-element, regardless of the order of arrangement of the sub-elements. If several sub-elements have the same `alpn` and `path` configurations, the last one specified will be used.
- Fallback routing is performed at the decrypted TCP layer rather than the HTTP layer, and the first packet PATH is only checked when necessary.
- You can learn more about tips and experiences in using Fallbacks by visiting
- [An Analysis of Fallback Functionality.](../../document/level-1/fallbacks-lv1)
- It will match the most precise child element, regardless of the order of child elements. If several child elements with identical `alpn` and `path` are configured, the last one will prevail.
- Fallback offloading is forwarding at the decrypted TCP layer, not the HTTP layer. It only checks the first packet's PATH when necessary.
- You can view more tips and insights on using Fallbacks here:
- [Analysis of Fallbacks Features](../../document/level-1/fallbacks-lv1)
## Fallbacks design theory <Badge text="WIP" type="warning"/>
## Fallbacks Design Theory <Badge text="WIP" type="warning"/>
docs/en/config/features/index.md
+4 -4
View File
@@ -1,9 +1,9 @@
# Xray Feature Details
# Xray Features in Detail
Xray offers the following features:
Xray has the following features:
- [Deep Dive into XTLS](xtls.md)
- [XTLS Deep Dive](xtls.md)
- [Fallback](fallback.md)
- [Browser Dialer](browser_dialer.md)
- [Environment Variables](env.md)
- [Multi-file Configuration](multiple.md)
- [Multiple File Configuration](multiple.md)
docs/en/config/features/multiple.md
+75 -115
View File
@@ -1,176 +1,136 @@
# Multi-file configuration
# Multiple Configuration Files
The Xray program supports the use of multiple configuration files.
Xray supports the use of multiple configuration files.
The main purpose of using multiple configuration files is to distribute different module configurations, making it easier to manage and maintain.
The main purpose of multiple configuration files is to disperse the configuration of different functional modules, facilitating management and maintenance.
This feature is mainly designed to enrich the Xray ecosystem. For example, for GUI-based clients, only fixed functions such as node selection are usually implemented, and complex configurations are difficult to implement graphically. By leaving a custom `confdir` configuration directory for complex functions, server deployment scripts can simply add files to `confdir` to implement multiple protocol configurations.
This feature is designed mainly to enrich Xray's ecosystem. For example, GUI clients usually only implement fixed functions like node selection, making it difficult to graphically implement complex configurations. By leaving a custom configuration directory `confdir`, complex functions can be configured there. For server deployment scripts, simply adding files to `confdir` can achieve multi-protocol configuration.
## Multi-file startup
## Multi-file Startup
::: tip
The startup information will indicate each configuration file being read in sequence. Please pay attention to whether the startup information matches the order you have set.
The startup log will indicate each configuration file read in sequence. Pay attention to whether the startup information matches your expected order. You can control the order by adding numeric prefixes to file names, such as `01_filename`, `02_filename`. The larger the number, the later it is sorted.
:::
```shell
$ xray run -confdir /etc/xray/confs
```
You can also use `Xray.location.confdir` or `Xray_LOCATION_CONFDIR` to specify the `confdir`.
You can also use `Xray.location.confdir` or `Xray_LOCATION_CONFDIR` to specify `confdir`.
The `-confdir` parameter takes precedence over the environment variable. If a valid directory is specified by the parameter, the path in the environment variable will not be read.
The `-confdir` parameter takes precedence over environment variables. If the parameter specifies a valid directory, the path in the environment variable will not be read.
## Rule Explanation
## Rules Explanation
### Normal Objects（`{}`）
### Ordinary Objects (`{}`)
**In the top-level object of `JSON`, the latter overrides or supplements the former.**
Top-level objects in later files overwrite or supplement those in earlier files.
For example：
### Arrays (`[]`)
- base.json
`inbounds` and `outbounds` in JSON configuration are array structures, and they have special rules:
- Look for existing elements with the same `tag` and overwrite them; if not found:
- For `inbounds`, append to the end (order within inbounds doesn't matter).
- For `outbounds`, prepend to the beginning (the first outbound is the default); however, if the filename contains "tail" (case-insensitive), append to the end.
## Configuration Example
Assume there are the following three configuration files in the `confs` folder.
- 01.json
```json
{
"log": {},
"api": {},
"dns": {},
"stats": {},
"policy": {},
"transport": {},
"routing": {},
"inbounds": []
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "socks",
"protocol": "socks",
"listen": "0.0.0.0",
"port": 8888
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom"
}
]
}
```
- outbounds.json
```json
{
"outbounds": []
}
```
When starting Xray with multiple configurations, use the following command:
```bash
$ xray run -confdir /etc/xray/confs
```
These two configuration files are equivalent to a single combined configuration. If you need to modify the outbound nodes, simply modify the content of `outbounds.json`.
If you need to change the log level for debugging purposes, there is no need to modify `base.json`. You can add an additional configuration file:
- debuglog.json
- 02.json
```json
{
"log": {
"loglevel": "debug"
}
}
```
Start the program in sequence after `base.json` to output logs at the debug level.
### Arrays（`[]`）
In the JSON configuration, `inbounds` and `outbounds` are array structures with special rules:
- When there are two or more elements in the array, the latter overrides the former for `inbounds`/`outbounds`.
- When there is only one element in the array, it searches for an existing element with the same `tag` to override. If it cannot be found:
- For `inbounds`, add it to the end (the order of elements in `inbounds` is irrelevant).
- For `outbounds`, add it to the beginning (the default first-choice outbound). However, if the filename contains "tail" (case-insensitive), add it to the end.
With multiple configurations, it is easy to add inbound for different protocols to the original configuration without modifying the original configuration.
The following example is not a valid configuration but is provided to demonstrate the above rules.
- 000.json
```json
{
},
"inbounds": [
{
"protocol": "socks",
"tag": "socks",
"port": 1234
"protocol": "socks",
"listen": "127.0.0.1",
"port": 1080
}
],
"outbounds": [
{
"tag": "block",
"protocol": "blackhole"
}
]
}
```
- 001.json
- 03_tail.json
```json
{
"inbounds": [
"outbounds": [
{
"protocol": "http",
"tag": "http"
"tag": "direct2",
"protocol": "freedom"
}
]
}
```
- 002.json
The three configurations will be merged as follows:
```json
{
"log": {
"loglevel": "debug" // Top-level object overwrites the former
},
"inbounds": [
{
"tag": "socks", // Overwrites the former when tag is the same
"protocol": "socks",
"tag": "socks",
"port": 4321
"listen": "127.0.0.1",
"port": 1080
}
]
}
```
The three configurations will be combined into:
```json
{
"inbounds": [
],
"outbounds": [
{
"protocol": "socks",
"tag": "socks",
"port": 4321 // < 002顺序在000后，因此覆盖tag为socks的inbound端口为4321
"tag": "block", // outbounds added to the front
"protocol": "blackhole"
},
{
"protocol": "http",
"tag": "http"
"tag": "direct",
"protocol": "freedom"
},
{
"tag": "direct2", // Filename of 03_tail.json contains 'tail' keyword, added to the end
"protocol": "freedom"
}
]
}
```
## Recommended Multi-file List
Execute：
```bash
for BASE in 00_log 01_api 02_dns 03_routing 04_policy 05_inbounds 06_outbounds 07_transport 08_stats 09_reverse; do echo '{}' > "/etc/Xray/$BASE.json"; done
```
or
```bash
for BASE in 00_log 01_api 02_dns 03_routing 04_policy 05_inbounds 06_outbounds 07_transport 08_stats 09_reverse; do echo '{}' > "/usr/local/etc/Xray/$BASE.json"; done
```
```bash
.
├── 00_log.json
├── 01_api.json
├── 02_dns.json
├── 03_routing.json
├── 04_policy.json
├── 05_inbounds.json
├── 06_outbounds.json
├── 07_transport.json
├── 08_stats.json
└── 09_reverse.json
0 directories, 10 files
```
::: tip
You can use the `xray run -confdir=./confs -dump` command to view the merged configuration. However, since the core uses the Protobuf data format internally, the configuration format output by the `-dump` option will look different.
:::
docs/en/config/features/xtls.md
+2 -2
View File
@@ -1,5 +1,5 @@
# Deep analysis of XTLS
# XTLS Deep Dive
> **"XTLS is the original black technology of Xray, and also the core driving force that makes Xray's performance far superior."**
> **XTLS is Xray's original cutting-edge technology and the core driving force behind its unmatched performance.**
<Badge text="WIP" type="warning"/>
docs/en/config/inbound.md
+59 -66
View File
@@ -1,10 +1,10 @@
# Inbound Proxy
Inbound connections are used to receive incoming data and the available protocols are listed in [inbound protocols](./inbounds/).
Inbound connections are used to receive incoming data. For available protocols, please refer to [Inbound Protocols](./inbounds/).
## InboundObject
The `InboundObject` corresponds to a subelement of the `inbounds` item in the configuration file.
`InboundObject` corresponds to a child element of the `inbounds` item in the configuration file.
```json
{
@@ -19,11 +19,6 @@ The `InboundObject` corresponds to a subelement of the `inbounds` item in the co
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
},
"allocate": {
"strategy": "always",
"refresh": 5,
"concurrency": 3
}
}
]
@@ -32,40 +27,46 @@ The `InboundObject` corresponds to a subelement of the `inbounds` item in the co
> `listen`: address
The listening address, either an IP address or a Unix domain socket. The default value is `"0.0.0.0"`, which means accepting connections on all network interfaces.
The listening address, which can be an IP address or a Unix domain socket. The default value is `"0.0.0.0"`, which means listening on all network interfaces.
An available system IP address can be specified.
You can specify an IP address available on the system.
Unix domain socket can also be specified by providing the absolute path in the form of `"/dev/shm/domain.socket"`. The `@` symbol can be added at the beginning to represent [abstract](https://www.man7.org/linux/man-pages/man7/unix.7.html), and `@@` represents padded abstract.
`"::"` is equivalent to `"0.0.0.0"`; both will listen on IPv6 and IPv4 simultaneously. However, if you only want to listen on IPv6, you can set `v6only` in `sockopt` to true. If you only want to listen on IPv4, you can use commands like `ip a` to view the specific IP on the network card (usually the machine's public IP address or a private network address like 10.x.x.x) and listen on that. Of course, you can do the same for IPv6.
When Unix domain socket is specified, `port` and `allocate` will be ignored. The protocol currently supports VLESS, VMess, and Trojan. The transport methods available are TCP, WebSocket, HTTP/2, and gRPC.
Note that because UDP is not connection-oriented, if the inbound is based on UDP and there are multiple IP addresses on the network card, and the external connection is to a non-preferred address on the card, Xray might incorrectly use the preferred address as the source address for the reply instead of the target of the external connection, causing the connection to fail.
The solution is not to listen on `0.0.0.0` but to listen on the specific IP address on the network card.
When specifying a Unix domain socket, you can add a comma and an access permission indicator after the socket, such as `"/dev/shm/domain.socket,0666"`, to specify the access permission of the socket. This can be used to solve the socket access permission issue that occurs by default.
Supports Unix domain sockets in absolute path format, such as `"/dev/shm/domain.socket"`. You can add `@` at the beginning to represent [abstract](https://www.man7.org/linux/man-pages/man7/unix.7.html), and `@@` for abstract with padding.
When filling in a Unix domain socket, `port` and `allocate` will be ignored. The protocol can currently be VLESS, VMess, or Trojan, and applies only to TCP-based underlying transports, such as `tcp`, `websocket`, `grpc`. UDP-based transports like `mkcp` are not supported.
When filling in a Unix domain socket, you can use the format `"/dev/shm/domain.socket,0666"`, i.e., adding a comma and access permission indicators after the socket, to specify the access permissions of the socket. This can be used to solve socket permission issues that occur by default.
> `port`: number | "env:variable" | string
Port. The accepted formats are:
Port. Accepted formats are as follows:
- Integer: the actual port number.
- Environment variable: starts with `"env:"`, followed by the name of an environment variable, such as `"env:PORT"`. Xray will parse this environment variable as a string.
- String: can be a numeric string, such as `"1234"`, or a range of port numbers, such as `"5-10"` which represents ports 5 through 10, a total of 6 ports. You can use commas to separate multiple ranges, such as `11,13,15-17`, which represents ports 11, 13, and 15 through 17, a total of 5 ports.
- Integer value: The actual port number.
- Environment variable: Starts with `"env:"`, followed by the name of an environment variable, such as `"env:PORT"`. Xray will parse this environment variable as a string.
- String: Can be a numeric string, such as `"1234"`; or a numerical range, such as `"5-10"` indicating ports 5 to 10 (6 ports in total). Commas can be used for segmentation, such as `11,13,15-17` indicating port 11, port 13, and ports 15 to 17 (5 ports in total).
When only one port is specified, Xray listens for inbound connections on that port. When a range of ports is specified, it depends on the `allocate` setting.
When only one port is specified, Xray will listen for inbound connections on this port. When a port range is specified, Xray will listen on all ports within the range.
Note that listening on a port is a relatively expensive operation. Listening on a port range that is too large may cause a significant increase in resource usage or even cause Xray to fail to work properly. Generally speaking, problems may begin to appear when the number of listening ports approaches four digits. If you need to use a very large range, please consider using iptables for redirection instead of setting it here.
> `protocol`: "dokodemo-door" | "http" | "shadowsocks" | "socks" | "vless" | "vmess" | "trojan" | "wireguard"
The connection protocol name. The optional protocol types are listed in [inbound protocols](./inbounds/).
Connection protocol name. See the list of available [Inbound Protocols](./inbounds/) on the left.
> `settings`: InboundConfigurationObject
The specific configuration content depends on the protocol. See `InboundConfigurationObject` in each protocol for details.
Specific configuration content, which varies by protocol. See `InboundConfigurationObject` in each protocol section for details.
> `streamSettings`: [StreamSettingsObject](./transport.md#streamsettingsobject)
The underlying transport method is how the current Xray node interfaces with other nodes.
Underlying transport method (transport) is the way the current Xray node connects with other nodes.
> `tag`: string
>
> The identifier of this inbound connection, used to locate this connection in other configurations.
::: danger
@@ -74,27 +75,25 @@ When it is not empty, its value must be **unique** among all `tag`s.
> `sniffing`: [SniffingObject](#sniffingobject)
Traffic sniffing is mainly used in transparent proxies, for example:
Traffic sniffing is mainly used for transparent proxies and similar purposes. A typical flow is as follows:
1. If a device wants to access `abc.com` while connected to the internet, it will first query the IP address of `abc.com` via DNS and get `1.2.3.4`. Then the device will initiate a connection to `1.2.3.4`.
2. If sniffing is not set up, Xray will receive a connection request for `1.2.3.4`, which cannot be used for routing based on domain rules.
3. When `enable` in `sniffing` is set to `true`, Xray will sniff the domain name, `abc.com`, from the traffic data when processing the traffic of this connection.
4. Xray will reset `1.2.3.4` to `abc.com`. Routing can then be based on domain rules.
1. If a device accesses the internet and visits abc.com, the device first queries DNS to get the IP of abc.com as 1.2.3.4, and then the device initiates a connection to 1.2.3.4.
2. If sniffing is not configured, the connection request received by Xray is for 1.2.3.4, which cannot be used for routing traffic based on domain rules.
3. When `enabled` in sniffing is set to `true`, Xray will sniff the domain name, i.e., abc.com, from the traffic data when processing this connection.
4. Xray will reset 1.2.3.4 to abc.com. The routing can then divert traffic according to the domain rules.
Since the connection is now to `abc.com`, more can be done, such as routing based on domain rules, and even re-resolving the DNS.
Because it becomes a connection requesting abc.com, more things can be done. Besides routing domain rule diversion, it can also re-perform DNS resolution and other tasks.
When `enable` in `sniffing` is set to `true`, it can also sniff out bittorrent traffic and then configure the "protocol" item in routing rules to handle bittorrent traffic, such as intercepting bittorrent traffic on the server or forwarding bittorrent traffic to a VPS on the client side.
When `enabled` in sniffing is set to `true`, it can also sniff Bittorrent type traffic. Then you can configure the "protocol" item in routing to set rules for handling unencrypted BT traffic. For example, the server side can be used to intercept unencrypted BT traffic, or the client side can fixedly forward BT traffic to a certain VPS, etc.
> `allocate`: [AllocateObject](#allocateobject)
Specifies the specific settings for port allocation when multiple ports are set up.
Note: Newer browsers may use ECH to encrypt the Client Hello. In this case, Xray can only see the domain in the Outer Hello. You may need to consider hijacking DNS or manually disabling ECH in the browser configuration.
### SniffingObject
```json
{
"enabled": true,
"destOverride": ["http", "tls", "quic", "fakedns"],
"destOverride": ["http", "tls", "fakedns"],
"metadataOnly": false,
"domainsExcluded": [],
"routeOnly": false
@@ -105,55 +104,49 @@ Specifies the specific settings for port allocation when multiple ports are set
Whether to enable traffic sniffing.
> `destOverride`: ["http" | "tls" | "quic" | "fakedns" ]
> `destOverride`: \["http" | "tls" | "quic" | "fakedns"\]
When the traffic is of a specified type, reset the destination of the current connection to the target address included in the list.
When the traffic is of the specified type, reset the destination of the current connection based on the destination address contained within it.
::: tip
Xray will only sniff the domains of protocols in `destOverride` for routing purposes. If you only want to sniff for routing but do not want to reset the destination address (e.g., resetting the destination address when using the Tor browser will cause connection failure), please add the corresponding protocol here and enable `routeOnly`.
:::
> `metadataOnly`: true | false
When enabled, only use the connection's metadata to sniff the target address. In this case, sniffer other than `fakedns` cannot be activated.
When enabled, only the connection metadata will be used to sniff the destination address. At this time, sniffers other than `fakedns` will not be activated.
If metadata-only is disabled, the client must send data before the proxy server actually establishes the connection. This behavior is incompatible with protocols that require the server to initiate the first message, such as the SMTP protocol.
If disabled (using more than just metadata to infer the destination address), the client must send data first before the proxy server actually establishes a connection. This behavior is incompatible with protocols where the server must initiate the first message, such as the SMTP protocol.
> `domainsExcluded`: [string] <Badge text="WIP" type="warning"/>
A list of domain names. If the traffic sniffing result matches a domain name in this list, the target address will **not** be reset.
A list of domains. If the result of traffic sniffing is in this list, the destination address will **not** be reset.
Supports direct domains (exact match), or strings starting with `regexp:` followed by a regular expression.
::: tip
Filling in some domains may solve issues with iOS push notifications, Mijia smart devices, and voice chat in certain games (Rainbow Six).<br>
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`.
docs/en/config/inbounds/http.md
+15 -15
View File
@@ -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.
docs/en/config/inbounds/index.md
+1 -1
View File
@@ -1,4 +1,4 @@
# Xray Inbound Protocols List
# Xray Inbound Protocols
Xray supports the following inbound protocols:
docs/en/config/inbounds/shadowsocks.md
+69 -60
View File
@@ -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 <length>` to generate a key compatible with shadowsocks-rust. The length depends on the encryption method used.
| Encryption Method | Key Length |
| ----------------------------- | ---------: |
| 2022-blake3-aes-128-gcm | 16 |
| 2022-blake3-aes-256-gcm | 32 |
| 2022-blake3-chacha20-poly1305 | 32 |
In the Go implementation, 32-byte keys always work.
- Other encryption methods
Any string. There is no limit on password length, but short passwords are more likely to be cracked. It is recommended to use passwords of 16 characters or longer.
> `level`: number
User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
The value of `level` corresponds to the `level` value in [policy](../policy.md#levelpolicyobject). If not specified, the default is 0.
> `email`: string
User email, used to distinguish traffic from different users (logs, statistics).
## ClientObject
```json
{
"password": "密码",
"password": "1919810",
"method": "aes-256-gcm",
"level": 0,
"email": "love@xray.com"
}
```
> `method`: string
When this option exists, it indicates that multi-user mode is enabled.
Required, any of the [supported methods](#supported-encryption-methods)
When the `method` in `InboundConfigurationObject` is not an SS2022 option, you can specify `"method"` for each user here (only non-SS2022 options are supported in `"method"`) along with `"password"` (at the same time, the `"password"` set in `InboundConfigurationObject` will be ignored).
> `password`: string
When the `method` in `InboundConfigurationObject` is an SS2022 option, for security reasons, setting `"method"` for individual users is no longer supported. It is unified to the `"method"` specified in `InboundConfigurationObject`.
Required. For **Shadowsocks 2022** a pre-shared `base64` random key similar to WireGuard's keys should be used as the password. The command
Note that SS2022 does not ignore the upper-level `"password"` like the old SS did. The correct password format for the client should be `ServerPassword:UserPassword`. For example: `"password": "114514:1919810"`.
```sh
openssl rand -base64 <length>
```
could used to generate a key. The length of the required key for `shadowsocks-rust` implementation depends on the encryption method:
| Encryption Method | Key Length |
| ------------------------------- | ---------: |
| `2022-blake3-aes-128-gcm` | 16 |
| `2022-blake3-aes-256-gcm` | 32 |
| `2022-blake3-chacha20-poly1305` | 32 |
In the `go-shadowsocks` implementation written in Golang, a 32-byte key always works.
For **any other encryption method** _any string_ could be used. There is no limitation on the password length, but shorter passwords are more susceptible to cracking. It is recommended to use a random-generated password of 16 characters or longer. The following example generates 40-characters length password:
```sh
sudo strings /dev/urandom | grep -o '[[:alnum:]]' | head -n 40 | tr -d '\n'; echo
```
> `level`: number
The user level that the connection will use to determine the corresponding [Local Policy](../policy.md#levelpolicyobject).
The value of `level` corresponds to the value of `level` in the [policy](../policy.md#policyobject). If not specified, the default value is 0.
> `email`: string
The user's email, used to differentiate traffic from different users for logs or statistics.
The remaining options have the same meaning as in `InboundConfigurationObject`.
docs/en/config/inbounds/socks.md
+20 -16
View File
@@ -1,12 +1,12 @@
# SOCKS
# Socks
The standard SOCKS protocol implementation is compatible with [SOCKS 4](http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol), SOCKS 4a, and [SOCKS 5](http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol).
Standard Socks protocol implementation, compatible with [Socks 4](http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol), [Socks 4a](https://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4A.protocol), Socks 5, and **HTTP**.
::: danger
The SOCKS protocol does not provide encryption for transport and is not suitable for transmitting data over public networks.
**The Socks protocol does not encrypt transmission and is not suitable for transmission over the public internet.**
:::
The use of `SOCKS` inbound is more meaningful in a local area network or local environment, where it can be used to listen for incoming connections and provide local services to other programs.
A more meaningful usage of `Socks` inbound is to listen within a LAN or on the local machine to provide local services for other programs.
## InboundConfigurationObject
@@ -27,35 +27,39 @@ The use of `SOCKS` inbound is more meaningful in a local area network or local e
> `auth`: "noauth" | "password"
The authentication method for the SOCKS protocol, supporting `"noauth"` for anonymous mode and `"password"` for username/password authentication.
Authentication method for the Socks protocol. Supports `"noauth"` (anonymous) and `"password"` (user/password).
The default value is `"noauth"`.
When using password, HTTP requests sent to this inbound will also require the same account and password.
Default value is `"noauth"`.
> `accounts`: \[ [AccountObject](#accountobject) \]
An array where each element represents a user account.
An array where each element is a user account.
This option is only valid when `auth` is set to `"password"`.
This option is only valid when `auth` is set to `password`.
The default value is an empty array.
Default value is empty.
> `udp`: true | false
Whether to enable UDP protocol support.
The default value is `false`.
Default value is `false`.
> `ip`: address
When UDP is enabled, Xray needs to know the local IP address.
When UDP is enabled, Xray needs to know the IP address of the local machine.
The default value is `"127.0.0.1"`.
"The IP address of the local machine" means the IP that the client can use to find the server when initiating a UDP connection. By default, it is the local IP address when the server accepts the TCP connection. It should work normally in most cases, but when passing through systems behind NAT, it may cause malfunctions, requiring this parameter to be modified to the correct public IP.
Warning: If your machine has multiple IP addresses, you will be affected by the issue regarding UDP listening on 0.0.0.0 mentioned in [Inbound Listening](../inbound.md#inboundobject).
> `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
@@ -68,8 +72,8 @@ The value of `userLevel` corresponds to the value of `level` in the [policy](../
> `user`: string
The username as a string. Required.
Username, string type. Required.
> `pass`: string
The password as a string. Required.
Password, string type. Required.
docs/en/config/inbounds/trojan.md
+13 -11
View File
@@ -1,9 +1,9 @@
# Trojan
The [Trojan](https://trojan-gfw.github.io/trojan/protocol) protocol.
[Trojan](https://trojan-gfw.github.io/trojan/protocol) protocol.
::: danger
Trojan is designed to work with correctly configured encrypted TLS tunnels.
Trojan is designed to work over correctly configured encrypted TLS tunnels.
:::
## InboundConfigurationObject
@@ -27,16 +27,18 @@ Trojan is designed to work with correctly configured encrypted TLS tunnels.
> `clients`: \[ [ClientObject](#clientobject) \]
An array representing a group of users approved by the server.
An array representing a group of users accepted by the server.
Each item in the array is a user [ClientObject](#clientobject).
Each item is a [ClientObject](#clientobject).
> `fallbacks`: \[ [FallbackObject](../features/fallback.md) \]
An array that contains a series of powerful fallback configurations (optional). The specific configuration for `fallbacks` can be found in the [FallbackObject](../features/fallback.md#fallbacks-configuration) documentation.
An array containing a series of powerful fallback configurations (optional).
For specific configuration of fallbacks, please click [FallbackObject](../features/fallback.md#fallbackobject).
::: tip
Xray's Trojan has full support for fallbacks, and the configuration is identical. The conditions triggering fallback are similar to VLESS: first packet length < 58 or the 57th byte is not `\r` (because Trojan does not have a protocol version) or authentication failure.
Xray's Trojan has complete support for fallbacks, and the configuration method is exactly the same as VLESS.
The conditions for triggering fallback are also similar to VLESS: the length of the first packet < 58, OR the 57th byte is not `\r` (because Trojan has no protocol version), OR authentication fails.
:::
### ClientObject
@@ -51,18 +53,18 @@ Xray's Trojan has full support for fallbacks, and the configuration is identical
> `password`: string
Required. Any string.
Required, any string.
> `email`: string
Email address. Optional. Used to identify the user.
Email address, optional, used to identify the user.
::: danger
If there are multiple `ClientObject`s, please make sure that the email addresses are not duplicated.
If there are multiple ClientObjects, please note that emails must not be duplicated.
:::
> `level`: 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 `level` 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.
docs/en/config/inbounds/tun.md
+39
View File
@@ -0,0 +1,39 @@
# TUN
Creates a TUN interface; traffic sent to this interface will be processed by Xray. Currently, only Windows and Linux are supported.
## InboundConfigurationObject
```json
{
"name": "xray0",
"MTU": 1500,
"UserLevel": 0
}
```
> `name`: string
The name of the created TUN interface. Default is `"xray0"`.
> `MTU`: number
The MTU of the interface. Default is `1500`.
> `userLevel`: number
User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
The value of `userLevel` corresponds to the `level` value in [policy](../policy.md#policyobject). If not specified, the default is 0.
## Usage Tips
Currently, Xray does not automatically modify the system routing table. You need to manually configure routes to direct data to the created TUN interface; otherwise, it remains just an interface.
If you only want to proxy specific process(es), the process name routing in the Xray routing system will be very useful.
::: warning
Be aware of potential traffic loop issues. After setting routes, requests initiated by Xray might be sent back to Xray, causing a loop!
Use `interface` in `sockopt` to bind to the actual physical network interface to avoid this problem. `ipconfig` (Windows) or `ip a` (Linux) will help you find the interface name you need.
Alternatively, use the outbound `sendThrough` setting. It is available directly in `OutboundObject` without the deep nesting level of `sockOpt.interface`. Here you need to use the IP address on the network card, such as 192.168.1.2 (As you can see, its disadvantage is that it cannot automatically support dual-stack; please choose according to the IP actually used for your outbound connection).
:::
docs/en/config/inbounds/tunnel.md
+17 -17
View File
@@ -1,6 +1,8 @@
# Tunnel(Dokodemo-Door)
# Tunnel (dokodemo-door)
Tunnel, formerly known as dokodemo-door, listens on multiple local ports and forwards all incoming data through an outbound to a specified server port, achieving the effect of port mapping.
Tunnel, formerly known as dokodemo-door (Arbitrary Door), can listen on multiple local ports and send all received data to a specific port on a specified server via an outbound, thereby achieving the effect of port mapping.
[Image of port forwarding diagram]
## InboundConfigurationObject
@@ -21,41 +23,39 @@ Tunnel, formerly known as dokodemo-door, listens on multiple local ports and for
> `address`: address
The address to forward the traffic to. It can be an IP address like `"1.2.3.4"` or a domain name like `"xray.com"`. It is a string type, default `"localhost"`.
When `followRedirect` (see below) is set to `true`, `address` can be empty.
Forward traffic to this address. It can be an IP address, like `"1.2.3.4"`, or a domain name, like `"xray.com"`. String type, defaults to `"localhost"`.
> `port`: number
The specified port on the destination address to forward the traffic to, range \[0, 65535\], numeric type. If not filled or set to 0, it defaults to the listening port.
Forward traffic to the specified port of the target address. Range \[0, 65535\], numeric type. If omitted or 0, it defaults to the listening port.
> `portMap`: map[string]string
A map maps local ports and required remote addresses/ports (if the inbound listens on several ports). If a local port is not included, handles according to `address`/`port` setting.
A map mapping local ports to required remote addresses/ports (if the inbound listens on multiple ports). If the local port is not included in this map, it is handled according to the `address`/`port` settings.
> `network`: "tcp" | "udp" | "tcp,udp"
The supported network protocol type. For example, when specified as `"tcp"`, it will only receive TCP traffic. The default value is `"tcp"`.
Accepted network protocol types. For example, when specified as `"tcp"`, only TCP traffic will be received. Default value is `"tcp"`.
> `followRedirect`: true | false
When set to `true`, dokodemo-door will recognize data forwarded by iptables and forward it to the corresponding destination address.
When set to `true`, dokodemo-door will recognize data forwarded by iptables and forward it to the corresponding target address.
Refer to the `tproxy` setting in the [Transport Configuration](../transport.md#sockoptobject) for more information.
Please refer to the `tproxy` setting in [Transport Configuration](../transport.md#sockoptobject).
> `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, it defaults to 0.
## Usage
Dokodemo-door can be used as Transparent proxy (in the next section) and can be used to map a port.
The "Arbitrary Door" has two main uses: one is for transparent proxy (see below), and the other is for mapping a port.
Some services do not support proxy likes Socks5, but using Tun or Tproxy could be too complicated. If these services only communicate with a single IP address and port (example: iperf, Minecraft server, Wireguard endpoint), dokodemo-door can be used.
Sometimes some services do not support forward proxies like Socks5, and using Tun or Tproxy is overkill. If these services only communicate with a single IP and port (e.g., iperf, Minecraft server, Wireguard endpoint), you can use dokodemo-door.
Below is an example config (if the default outbound is an effective proxy):
For example, the following Config (assuming the default outbound is a valid proxy):
```json
{
@@ -73,8 +73,8 @@ Below is an example config (if the default outbound is an effective proxy):
}
```
The core will listen at `127.0.0.1:25565`, and the traffic coming in through this inbound will be send to `mc.hypixel.net:25565` (a Minecraft server) through the default outbound. Then you can connect the Minecraft client to the Hypixel server through the proxy by set the game server to `127.0.0.1:25565` in the Minecraft client.
In this case, the core will listen on 127.0.0.1:25565 and forward it to mc.hypixel.net:25565 (a MC server) via the default outbound. Connecting the Minecraft client to 127.0.0.1:25565 is equivalent to connecting to the Hypixel server via a proxy.
## Transparent Proxy Configuration Example
Please refer to the [Transparent Proxy (TProxy) Configuration Tutorial](../../document/level-2/tproxy) for this section.
For this section, please refer to [Transparent Proxy (TProxy) Configuration Tutorial](../../document/level-2/tproxy).
docs/en/config/inbounds/vless.md
+62 -26
View File
@@ -1,12 +1,8 @@
# VLESS
# VLESS (XTLS Vision Seed)
::: danger
Currently, VLESS does not provide built-in encryption. Please use it with a reliable channel, such as TLS.
:::
VLESS is a stateless, lightweight transport protocol. It is divided into inbound and outbound parts and can serve as a bridge between Xray clients and servers.
VLESS is a stateless lightweight transport protocol that consists of inbound and outbound parts. It can serve as a bridge between Xray clients and servers.
Unlike [VMess](./vmess.md), VLESS does not rely on system time. The authentication method is still UUID-based.
Unlike [VMess](./vmess.md), VLESS does not depend on system time. The authentication method is also UUID.
## InboundConfigurationObject
@@ -17,7 +13,8 @@ Unlike [VMess](./vmess.md), VLESS does not rely on system time. The authenticati
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"level": 0,
"email": "love@xray.com",
"flow": "xtls-rprx-vision"
"flow": "xtls-rprx-vision",
"reverse": {}
}
],
"decryption": "none",
@@ -33,17 +30,33 @@ Unlike [VMess](./vmess.md), VLESS does not rely on system time. The authenticati
An array representing a group of users approved by the server.
Each item in the array is a user [ClientObject](#clientobject).
Each item is a user [ClientObject](#clientobject).
> `decryption`: "none"
Currently, you need to specify `"none"`. It cannot be left empty. If the `decryption` value is not set correctly, you will receive an error message when using Xray or `-test`.
[VLESS Encryption](https://github.com/XTLS/Xray-core/pull/5067) settings. Cannot be left empty; to disable, explicitly set it to `"none"`.
Note that `decryption` is at the same level as `clients`. The placement of `decryption` is different from the `encryption` in the vmess protocol because if there is a layer of agreed encryption, the server needs to decrypt it first to know which user it belongs to.
It is recommended for most users to use `./xray vlessenc` to automatically generate this field to ensure no errors in writing. The detailed configuration below is recommended for advanced users only.
Its format is a string of detailed configuration fields connected by `.`. For example: `mlkem768x25519plus.native.0rtt.100-111-1111.75-0-111.50-0-3333.ptjHQxBQxTJ9MWr2cd5qWIflBSACHOevTauCQwa_71U`. This document refers to the individual parts separated by dots as blocks.
- The 1st block is the handshake method. Currently, there is only `mlkem768x25519plus`. Requires the server and client to match.
- The 2nd block is the encryption method. Options are `native`/`xorpub`/`random`, corresponding to: raw format packets / raw format + obfuscated public key part / full random numbers (similar to VMess/Shadowsocks). Requires the server and client to match.
- The 3rd block is the session resumption ticket validity time. Format is `600s` or `100-500s`. The former will pick a random time between that duration and half of that duration (e.g., `600s` = `300-600s`); the latter manually specifies a random range.
Following this is padding. After the connection is established, the server sends some garbage data to obfuscate length characteristics. This does not need to be the same as the client (the same part in the outbound is the padding sent from the client to the server). It is a variable-length part, formatted as `padding.delay.padding`+`(.delay.padding)`\*n (multiple paddings can be inserted, requiring a delay block between two padding blocks). For example, you can write an ultra-long `padding.delay.padding.delay.padding.delay.padding.delay.padding.delay.padding`.
- The `padding` format is `probability-min-max`, e.g., `100-111-1111` means 100% probability of sending a padding with a length of 111~1111.
- The `delay` format is also `probability-min-max`, e.g., `75-0-111` means 75% probability of waiting for 0~111 milliseconds.
The first padding block has special requirements: it requires 100% probability and a minimum length greater than 0. If no padding exists, the core automatically uses `100-111-1111.75-0-111.50-0-3333` as the padding setting.
The last block is identified by the core as the parameter used to authenticate the client. It can be generated using `./xray x25519` (using the PrivateKey part) or `./xray mlkem768` (using the Seed part). It must correspond to the client. `mlkem768` is a post-quantum algorithm that prevents the private key from being cracked by quantum computers (in the future) to impersonate the server if client parameters are leaked. This parameter is only used for verification; the handshake process is post-quantum secure regardless, and existing encrypted data cannot be cracked by future quantum computers.
> `fallbacks`: \[ [FallbackObject](../features/fallback.md) \]
An array that contains a series of powerful fallback configurations (optional). The specific configuration for `fallbacks` can be found in the [FallbackObject](../features/fallback.md#fallbacks-configuration) documentation.
An array containing a series of powerful fallback distribution configurations (optional).
For specific fallback configurations, please click [FallbackObject](../features/fallback.md#fallbacks-configuration).
### ClientObject
@@ -52,40 +65,63 @@ An array that contains a series of powerful fallback configurations (optional).
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"level": 0,
"email": "love@xray.com",
"flow": "xtls-rprx-vision"
"flow": "xtls-rprx-vision",
"reverse" {}
}
```
> `id`: string
The user ID for VLESS. It can be any string less than 30 bytes or a valid UUID. Custom strings and their corresponding UUIDs are equivalent, which means you can use either of the following in the configuration file to identify the same user:
The user ID for VLESS. It can be any string less than 30 bytes or a valid UUID.
A custom string and its mapped UUID are equivalent, which means you can write the id in the configuration file to identify the same user like this:
- `"id": "我爱🍉老师1314"`
- `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the mapping of the string "我爱 🍉 老师 1314")
- Write `"id": "我爱🍉老师1314"`,
- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the UUID mapping of `我爱🍉老师1314`).
The mapping standard is described in the [VLESS UUID Mapping Standard: Mapping a Custom String to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
The mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
You can use the command `xray uuid -i "custom string"` to generate the UUID corresponding to a custom string.
You can use the command `xray uuid -i "custom string"` to generate the UUID mapped from the custom string.
> You can also use the command `xray uuid` to generate a random UUID.
> `level`: number
The user level that the connection will use to determine the corresponding [Local Policy](../policy.md#levelpolicyobject).
User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
The value of `level` corresponds to the value of `level` in the [policy](../policy.md#policyobject). If not specified, the default value is 0.
The value of `level` corresponds to the `level` value in [policy](../policy.md#policyobject). If not specified, the default is 0.
> `email`: string
User email address used to differentiate traffic from different users (reflected in logs and statistics).
User email, used to distinguish traffic from different users (reflected in logs and statistics).
> `flow`: string
Flow control mode used to select the XTLS algorithm.
Flow control mode, used to select the XTLS algorithm.
Currently, the following flow control modes are available for inbound protocols:
Currently, the following flow control modes are available in the inbound protocol:
- No `flow` or empty string: Use regular TLS proxy.
- `xtls-rprx-vision`: Use the new XTLS mode, including inner-handshake random padding.
- No `flow` or empty string: Use standard TLS proxy.
- `xtls-rprx-vision`: Use the new XTLS mode, including inner handshake random padding.
Additionally, XTLS currently only supports TCP+TLS/Reality.
XTLS is only available under the following combinations:
- TCP+TLS/Reality: In this case, encrypted data is directly copied at the underlying layer (if transmitting TLS 1.3).
- VLESS Encryption: No underlying transport restrictions. If the underlying layer does not support direct copying (see above), it only penetrates Encryption.
> `reverse`: struct
VLESS simplified reverse proxy configuration. It functions the same as the core's internal general reverse proxy but with simpler configuration.
The presence of this item indicates that connections from this user can be used to establish a reverse proxy tunnel.
Current syntax:
```json
"reverse": {
"tag": "r-outbound"
}
```
`tag` is the outbound proxy tag for this reverse proxy. Routing traffic to this outbound using routing rules will forward it through the reverse proxy to the connected client's routing system (see VLESS Outbound for client configuration details).
When multiple different connections (potentially from different devices) are connected, the core will randomly select one to dispatch reverse proxy data for each request.
docs/en/config/inbounds/vmess.md
+18 -36
View File
@@ -1,9 +1,9 @@
# VMess
[VMess](../../development/protocols/vmess.md) is an encrypted transport protocol that is commonly used as a bridge between Xray clients and servers.
[VMess](../../development/protocols/vmess.md) is an encrypted transport protocol, commonly acting as a bridge between the Xray client and server.
::: danger
VMess relies on system time. Please ensure that the system UTC time used by Xray is within 120 seconds of the actual time, regardless of time zone. On Linux systems, you can install the `ntp` service to automatically synchronize the system time.
VMess depends on system time. Please ensure that the system UTC time of the device running Xray is within 120 seconds of the actual time, regardless of the time zone. On Linux systems, you can install the `ntp` service to automatically synchronize system time.
:::
## InboundConfigurationObject
@@ -19,28 +19,21 @@ VMess relies on system time. Please ensure that the system UTC time used by Xray
],
"default": {
"level": 0
},
"detour": {
"to": "tag_to_detour"
}
}
```
> `clients`: \[ [ClientObject](#clientobject) \]
An array representing a group of users approved by the server.
An array representing a group of users accepted by the server.
Each item in the array is a user [ClientObject](#clientobject).
Each item is a [ClientObject](#clientobject).
When this configuration is used for dynamic ports, Xray will automatically create users.
> `detour`: [DetourObject](#detourobject)
Indicates that another server should be used for the corresponding outbound protocol.
> `default`: [DefaultObject](#defaultobject)
Optional. The default configuration for clients. Only effective when used with `detour`.
Optional. Default configuration for clients. Only valid when used in conjunction with `detour`.
### ClientObject
@@ -54,41 +47,30 @@ Optional. The default configuration for clients. Only effective when used with `
> `id`: string
The user ID for VMess. It can be any string less than 30 bytes or a valid UUID.
User ID for VMess. It can be any string less than 30 bytes, or a valid UUID.
::: tip
Custom strings and their corresponding UUIDs are equivalent, which means you can use either of the following in the configuration file to identify the same user:
A custom string and its mapped UUID are equivalent. This means you can identify the same user in the configuration file by writing the ID in either way:
- `"id": "我爱🍉老师1314"`
- `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the mapping of the string "我爱 🍉 老师 1314")
- Write `"id": "我爱🍉老师1314"`,
- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the UUID mapping of `我爱🍉老师1314`)
:::
The mapping standard is described in the [VLESS UUID Mapping Standard: Mapping a Custom String to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
The mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
You can use the command `xray uuid -i "custom string"` to generate the UUID corresponding to a custom string.
You can use the command `xray uuid -i "custom string"` to generate the UUID mapped from a custom string.
You can also use the command `xray uuid` to generate a random UUID. :::
> You can also use the command `xray uuid` to generate a random UUID.
> `level`: number
The user level that the connection will use to determine the corresponding [Local Policy](../policy.md#levelpolicyobject).
User level. The connection will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
The value of `level` corresponds to the value of `level` in the [policy](../policy.md#policyobject). If not specified, the default value is 0.
The value of `level` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.
> `email`: string
The user's email address, used to differentiate traffic from different users.
### DetourObject
```json
{
"to": "tag_to_detour"
}
```
> `to`: string
The `tag` of an inbound that specifies the inbound using the VMess protocol.
User email address, used to distinguish traffic from different users.
### DefaultObject
@@ -100,6 +82,6 @@ The `tag` of an inbound that specifies the inbound using the VMess protocol.
> `level`: number
The user level that the connection will use to determine the corresponding [Local Policy](../policy.md#levelpolicyobject).
User level. The connection will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
The value of `level` corresponds to the value of `level` in the [policy](../policy.md#policyobject). If not specified, the default value is 0.
The value of `level` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.
docs/en/config/inbounds/wireguard.md
+8 -9
View File
@@ -1,9 +1,9 @@
# Wireguard
# WireGuard
User-space implementation of the Wireguard protocol.
User-space WireGuard protocol implementation.
::: danger
**The Wireguard protocol is not specifically designed for circumvention purposes. If used as the outer layer for circumvention, its characteristics may lead to server blocking.**
**The WireGuard protocol is not designed specifically for bypassing firewalls. If used as the outer layer to cross the firewall, its distinct characteristics may lead to the server being blocked.**
:::
## InboundConfigurationObject
@@ -17,7 +17,6 @@ User-space implementation of the Wireguard protocol.
"allowedIPs": [""]
}
],
"kernelMode": true, // optional, default true if it's supported and permission is sufficient
"mtu": 1420 // optional, default 1420
}
```
@@ -28,12 +27,12 @@ Private key. Required.
> `mtu`: int
Fragmentation size of the underlying Wireguard tun.
The MTU size of the underlying WireGuard TUN.
<details>
<summary>MTU Calculation Method</summary>
<summary>Method to Calculate MTU</summary>
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).
</details>
> `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
docs/en/config/index.md
+46 -33
View File
@@ -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.
docs/en/config/log.md
+16 -28
View File
@@ -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]`
docs/en/config/metrics.md
+30 -54
View File
@@ -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):
<details><summary>Click to expand</summary><br>
<details><summary>Click to view</summary><br>
```json
{
@@ -152,14 +134,14 @@ for example with [luci-app-xray](https://github.com/yichya/luci-app-xray) you ar
</details>
To get a better view of these numbers, [Netdata](https://github.com/netdata/netdata) (with python.d plugin) is a great option:
To get better visualization output, you can use [Netdata](https://github.com/netdata/netdata) (with python.d plugin):
1. Edit related configuration file (`sudo /etc/netdata/edit-config python.d/go_expvar.conf`)
2. Take the following configuration file as an example:
1. Edit the relevant configuration file (`sudo /etc/netdata/edit-config python.d/go_expvar.conf`).
2. Use the example configuration below:
<details><summary>Click to expand</summary><br>
<details><summary>Click to view</summary><br>
```
```yaml
xray:
name: 'xray'
update_every: 2
@@ -267,12 +249,6 @@ xray:
</details>
And you will get a nice plot like this:
You can get results similar to this:
![160428235-2988bf69-5d6c-41ec-8267-1bd512508aa8](https://github.com/chika0801/Xray-docs-next/assets/88967758/455e88ce-ced2-4593-a9fa-425bb293215b)
### Additional
Maybe reusing the empty object `stats` in config file is better than adding `metrics` here?
**Edit:** removed prometheus related things and added usage about expvars
docs/en/config/observatory.md
+34 -20
View File
@@ -1,11 +1,6 @@
# Connection Monitoring
# Observatory
The connection monitoring component uses HTTPing to detect the connection
status of outbound proxies. The monitoring results can be used by other
components, such as load balancers. There are currently two options:
[observatory](#observatoryobject) (background connection monitoring) and
[burstObservatory](#burstobservatoryobject) (concurrent connection monitoring).
You can choose one of them as needed.
The Observatory component uses HTTPing to probe the connection status of outbound proxies. The observation results can be used by other components, such as the Load Balancer. Currently, there are two types: [observatory](#observatoryobject) (Background Connection Observatory) and [burstObservatory](#burstobservatoryobject) (Burst Connection Observatory). Choose one according to your needs.
## ObservatoryObject
@@ -20,20 +15,22 @@ You can choose one of them as needed.
> `subjectSelector`: \[ string \]
An array of strings, where each string is used to match the prefix of outbound proxy identifiers. Among the following outbound proxy identifiers: `["a", "ab", "c", "ba"]`, `"subjectSelector": ["a"]` will match `["a", "ab"]`.
An array of strings, where each string is used for prefix matching against outbound proxy tags. Given the following outbound proxy tags: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` will match `[ "a", "ab" ]`.
> `probeUrl`: string
The URL used to detect the connection status of the outbound proxy.
The URL used to probe the connection status of the outbound proxy.
> `probeInterval`: string
The interval at which probes are initiated. The time format is a number followed by a unit, such as `"10s"`, `"2h45m"`. Supported time units include `ns`, `us`, `ms`, `s`, `m`, `h`, corresponding to nanoseconds, microseconds, milliseconds, seconds, minutes, and hours, respectively.
The interval for initiating probes. The time format is number + unit, such as `"10s"`, `"2h45m"`. Supported time units are `ns`, `us`, `ms`, `s`, `m`, `h`, corresponding to nanoseconds, microseconds, milliseconds, seconds, minutes, and hours respectively.
Note that since the request interval is fixed, periodic fixed requests might lead to behavioral fingerprinting. Using protocols with multiplexing or enabling `mux` can alleviate this issue.
> `enableConcurrency`: true | false
- `true`: Concurrently probe all matching outbound proxies, then pause for the time set by `probeInterval`.
- `false`: Probe each matching outbound proxy one by one, pausing for the time set by `probeInterval` after probing each one.
- `true`: Probe all matched outbound proxies concurrently. Pauses for the time set in `probeInterval` after all are completed.
- `false`: Probe matched outbound proxies one by one. Pauses for the time set in `probeInterval` after each outbound proxy is probed.
## BurstObservatoryObject
@@ -46,7 +43,7 @@ The interval at which probes are initiated. The time format is a number followed
> `subjectSelector`: \[ string \]
An array of strings, where each string is used to match the prefix of outbound proxy identifiers. Among the following outbound proxy identifiers: `["a", "ab", "c", "ba"]`, `"subjectSelector": ["a"]` will match `["a", "ab"]`.
An array of strings, where each string is used for prefix matching against outbound proxy tags. Given the following outbound proxy tags: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` will match `[ "a", "ab" ]`.
> `pingConfig`: [PingConfigObject](#pingconfigobject)
@@ -54,30 +51,47 @@ An array of strings, where each string is used to match the prefix of outbound p
```json
{
// For each outbound, probe 2 times within 10 minutes; specific probe times are random.
// If they all fail, it will be marked as a faulty node within 10 ~ 20 minutes.
// After failure, a single successful probe will mark it as a healthy node; at slowest, it takes 10 minutes.
"destination": "https://connectivitycheck.gstatic.com/generate_204",
"connectivity": "",
"interval": "1h",
"sampling": 3,
"interval": "5m",
"sampling": 2,
"timeout": "30s"
}
```
> `destination`: string
The URL used to detect the connection status of the outbound proxy. This URL should return an HTTP 204 success status code.
The URL used to probe the connection status of the outbound proxy. This URL should return an HTTP 204 success status code.
> `connectivity`: string
The URL used to check local network connectivity. An empty string means that local network connectivity is not checked.
The URL used to check local network connectivity. This URL should return an HTTP 204 success status code.
An empty string indicates no local network connectivity check.
This probe is executed only when the `destination` probe fails. This makes the cause of network failure clearer in the logs.
Note: In transparent proxy mode, this request might be captured by the transparent proxy and re-enter Xray for routing (depending on your configuration). You need to use extra means to ensure it is not captured by the transparent proxy, such as bypassing based on the URL IP, or using cgroup/pid routing to completely prevent Xray's requests from being captured. Alternatively, you can choose a URL that matches a direct connection rule and allow this request to be captured by the transparent proxy.
> `interval`: string
Within the specified time, probe all matching outbound proxies, probing each proxy `sampling + 1` times. The time format is a number followed by a unit, such as `"10s"`, `"2h45m"`. Supported time units include `ns`, `us`, `ms`, `s`, `m`, `h`, corresponding to nanoseconds, microseconds, milliseconds, seconds, minutes, and hours, respectively.
The expected **average** probe interval for each outbound proxy.
The time format is number + unit, such as `"10s"`, `"2h45m"`. Supported time units are `ns`, `us`, `ms`, `s`, `m`, `h`, corresponding to nanoseconds, microseconds, milliseconds, seconds, minutes, and hours respectively.
> `sampling`: number
The number of recent probe results to retain.
The number of recent probe results to keep.
> `timeout`: string
The probe timeout period. The format is the same as the `interval` above.
Probe timeout. Format is the same as `interval` above.
::: tip
The working principle of Burst Observatory is to immediately schedule probe tasks for each matched outbound at every `interval` * `sampling` (hereinafter referred to as the probe cycle). However, within each task's cycle, the probe is executed at a random time. This means compared to `observatory` (Background Connection Observatory), the fingerprint of this detector is less obvious. But if `interval` is set too small, or `sampling` is too large causing frequent probing, the fingerprint will be more obvious.
`interval` and `sampling` jointly affect the sensitivity of failover and recovery. When a node fails probes continuously, it takes at fastest 1 probe cycle to mark the node as faulty, and at slowest 2 probe cycles. Recovering from failure requires one successful probe, which depends on the probe density; at slowest, it takes 1 probe cycle.
:::
docs/en/config/outbound.md
+57 -60
View File
@@ -1,13 +1,13 @@
# Outbound Proxies
# Outbound Proxy (Mux, XUDP)
Outbound connections are used for sending data and can use any of the available protocols listed in [outbound protocols](./outbounds/).
Outbound connections are used to send data. For available protocols, please see [Outbound Protocols](./outbounds/).
## OutboundObject
The `OutboundObject` corresponds to a sub-element of the `outbounds` item in the configuration file.
`OutboundObject` corresponds to a sub-element of the `outbounds` item in the configuration file.
::: tip
The first element in the list serves as the main outbound. When there is no match or no successful match for the routing, the traffic is sent out by the main outbound.
The first element in the list serves as the primary outbound. When a routing match does not exist or fails, traffic is sent via the primary outbound.
:::
```json
@@ -15,12 +15,13 @@ The first element in the list serves as the main outbound. When there is no matc
"outbounds": [
{
"sendThrough": "0.0.0.0",
"protocol": "protocol name",
"protocol": "protocol_name",
"settings": {},
"tag": "identifier",
"streamSettings": {},
"proxySettings": {
"tag": "another-outbound-tag"
"tag": "another-outbound-tag",
"transportLayer": false
},
"mux": {},
"targetStrategy": "AsIs"
@@ -31,129 +32,125 @@ The first element in the list serves as the main outbound. When there is no matc
> `sendThrough`: address
The IP address used to send data. It is effective when the host has multiple IP addresses, and the default value is `"0.0.0.0"`.
The IP address used to send data. This is effective when the host has multiple IP addresses. The default value is `"0.0.0.0"`.
It is allowed to fill in the IPv6 CIDR block (such as `114:514:1919:810::/64`),
and Xray will use the random IP address in the address block to initiate
external connections. Network access, routing tables, and kernel parameters
need to be configured correctly to allow Xray to bind to any IP within the
address block.
You can enter an IPv6 CIDR block (e.g., `114:514:1919:810::/64`), and Xray will use a random IP address from the address block to initiate external connections.
You need to correctly configure the network access method, routing table, and kernel parameters to allow Xray to bind to any IP within the address block.
For networks that use ndp to access, it is not recommended to set a subnet
smaller than `/120`, otherwise it may cause NDP flood and a series of problems
such as the router neighbor cache being filled up.
For networks using NDP access, it is not recommended to set a subnet smaller than `/120`. Otherwise, it may cause issues such as NDP flooding, leading to the router's neighbor cache becoming full.
> `protocol`: string
Special value `origin`: If this value is used, the request will be sent using the IP address of the local machine that received the connection.
The name of the connection protocol. For a list of optional protocols, see
Outbound Proxy in the left sidebar.
For example, if the machine has a full IPv4 range `11.4.5.0/24` and listens on `0.0.0.0` (all IPv4 and IPv6 on the network interface), if a client connects to the local machine via `11.4.5.14`, the outbound request will also be sent via `11.4.5.14`. If the client connects via `11.4.5.10`, the outbound request will be sent via `11.4.5.10`. This also applies to cases where the machine has a full range/multiple IPv6 addresses.
As mentioned in the inbound introduction, because of the connectionless nature of UDP, Xray cannot know the original destination IP where the request entered the core (for example, in the same QUIC connection, it might even change), so this feature cannot take effect for UDP.
> `protocol`: "blackhole" | "dns" | "freedom" | "http" | "loopback" | "shadowsocks" | "socks" | "trojan" | "vless" | "vmess" | "wireguard"
The connection protocol name. For the list of optional protocols, see [Outbound Protocols](./outbounds/) on the left.
> `settings`: OutboundConfigurationObject
The specific configuration content varies depending on the protocol. See `OutboundConfigurationObject` in each protocol for details.
Specific configuration content, which varies by protocol. See `OutboundConfigurationObject` in each protocol for details.
> `tag`: string
The identifier of this outbound connection, used to locate this connection in other configurations.
The identifier for this outbound connection, used to locate this connection in other configurations.
::: danger
When it is not empty, its value must be **unique** among all `tag`s.
When not empty, its value must be **unique** among all `tag`s.
:::
> `streamSettings`: [StreamSettingsObject](./transport.md#streamsettingsobject)
The underlying transport method is the way the current Xray connects with other nodes.
The underlying transport method is the way the current Xray node connects with other nodes.
> `proxySettings`: [ProxySettingsObject](#proxysettingsobject)
The outbound proxy configuration. When the outbound proxy takes effect, the
`streamSettings` of this outbound will not work.
Outbound proxy configuration.
> `mux`: [MuxObject](#muxobject)
Specific configuration related to Mux.
> `targetStrategy`: "AsIs" |
> "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4"
> "ForceIP" | "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4"
> `targetStrategy`: "AsIs" | "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4" | "ForceIP" | "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4"
This strategy is for the final-target, which is transported by the proxy, to select the strategy for proxy-address itself you should use sockopt-domainStrategy.
If this outbound attempts to send a domain request, this controls whether it is resolved/how it is resolved to an IP before sending.
default is "AsIs", it is not recommended to change it unless you need to use your own trusted dns.
The default value is `AsIs`, meaning it is sent to the remote server as is. All parameter meanings are roughly equivalent to `domainStrategy` in [sockopt](./transport.md#sockoptobject).
The difference between "Use"/"Force" or "v4"/"v6"/"v4v6"/"v6v4" is also explained in sockopt-domainStrategy/freedom-targetStrategy.
::: tip
This controls **proxied requests**. If the address of the outbound proxy server is a domain name, and you need to select a resolution strategy for the domain name itself, you should configure `domainStrategy` in [sockopt](./transport.md#sockoptobject).
:::
### ProxySettingsObject
```json
{
"tag": "another-outbound-tag"
"tag": "another-outbound-tag",
"transportLayer": false
}
```
> `tag`: string
When specifying the identifier of another outbound, data emitted by this outbound will be forwarded to the specified outbound.
When the identifier of another outbound is specified, data sent by this outbound will be forwarded to the specified outbound for transmission.
::: danger
This forwarding method does **not go through** the underlying transport. If you need to use forwarding that supports the underlying transport, please use [SockOpt.dialerProxy](./transport.md#sockoptobject).
This option conflicts with [SockOpt.dialerProxy](./transport.md#sockoptobject). Choose one as needed.
By default, this forwarding method **does not go through** the underlying transport method (REALITY/XHTTP/gRPC...), meaning the `streamSettings` of this outbound will not take effect.<br>
If you need forwarding that supports underlying transport methods, please use `SockOpt.dialerProxy` instead or set `transportLayer` to `true`.
:::
::: 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.
docs/en/config/outbounds/blackhole.md
+6 -5
View File
@@ -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.
docs/en/config/outbounds/dns.md
+20 -9
View File
@@ -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 <Badge text="WIP" type="warning"/>
The default value is `"reject"`.
> `blockTypes`: array
An integer array used to block query types listed in the array. For example, `"blockTypes": [65,28]` means blocking type 65 (HTTPS) and 28 (AAAA). Common uses include blocking type 65 to prevent browsers from initiating ECH.
Since `nonIPQuery` drops all non-A and non-AAAA queries by default, this option requires `nonIPQuery` to be set to `skip` to take further effect on other types. Of course, you can also use it solely to block A or AAAA (IPv4/IPv6 queries), but this is highly discouraged. It is recommended to configure `queryStrategy` in the built-in DNS settings for relevant content instead.
Note: When using `blockTypes` to block only A or AAAA, if `nonIPQuery` is set to `reject`, the blocking method will also be to return a DNS reject response instead of dropping.
## DNS Configuration Examples <Badge text="WIP" type="warning"/>
docs/en/config/outbounds/freedom.md
+36 -73
View File
@@ -1,127 +1,90 @@
# Freedom
# Freedom (fragment, noises)
Freedom is an outbound protocol that can be used to send (normal) TCP or UDP data to any network.
Freedom is an outbound protocol used to send (normal) TCP or UDP data to any network.
## OutboundConfigurationObject
```json
{
"targetStrategy": "AsIs",
"domainStrategy": "AsIs",
"redirect": "127.0.0.1:3366",
"userLevel": 0,
"fragment": {
"packets": "tlshello",
"length": "100-200",
"interval": "10-20", // ms
"maxSplit": "300-400"
"interval": "10-20" // Unit: ms
},
"noises": [
{
"type": "base64",
"packet": "7nQBAAABAAAAAAAABnQtcmluZwZtc2VkZ2UDbmV0AAABAAE=",
"delay": "10-16",
"applyTo": "ip"
},
{
"type": "rand",
"packet": "10-20",
"delay": "10-16",
"applyTo": "ipv4"
},
{
"type": "str",
"packet": "hiGFW",
"delay": "10-16",
"applyTo": "ipv6"
"delay": "10-16"
}
],
"proxyProtocol": 0
}
```
> `targetStrategy`: "AsIs"
> "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4"
> `domainStrategy`: "AsIs"<br>
> "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4"<br>
> "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).
docs/en/config/outbounds/http.md
+32 -52
View File
@@ -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.
docs/en/config/outbounds/hysteria.md
+27
View File
@@ -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.
docs/en/config/outbounds/index.md
+2 -1
View File
@@ -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)
docs/en/config/outbounds/loopback.md
+9 -9
View File
@@ -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"
}
docs/en/config/outbounds/shadowsocks.md
+33 -47
View File
@@ -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 <length>`, where the length depends on the encryption method used.
Use `openssl rand -base64 <length>` to generate a key compatible with shadowsocks-rust. The length depends on the encryption method used.
| Encryption Method | Key Length |
| ----------------------------- | ---------: |
@@ -98,14 +84,14 @@ To generate a compatible key with shadowsocks-rust, use `openssl rand -base64 <l
| 2022-blake3-aes-256-gcm | 32 |
| 2022-blake3-chacha20-poly1305 | 32 |
In the Go implementation, a 32-byte key always works.
In the Go implementation, 32-byte keys always work.
- Other encryption methods
Any string can be used as a password. There is no limit on the password length, but shorter passwords are more susceptible to cracking. It is recommended to use a password of 16 characters or longer.
Any string. There is no limit on password length, but short passwords are more likely to be cracked. It is recommended to use passwords of 16 characters or longer.
> `level`: number
User level. Connections will use the corresponding [local policy](../policy.md#levelpolicyobject) associated with this user level.
User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
The `level` value corresponds to the `level` value in the [policy](../policy.md#policyobject). If not specified, the default value is 0.
The value of `level` corresponds to the `level` value in [policy](../policy.md#policyobject). If not specified, the default is 0.
docs/en/config/outbounds/socks.md
+16 -57
View File
@@ -1,54 +1,27 @@
# Socks
The Socks protocol is a standard protocol implementation that is compatible with [Socks 5](http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol).
Standard Socks protocol implementation, compatible with Socks 5.
::: danger
The Socks protocol does not provide encryption for transmission and is not suitable for transmitting data over public networks.
**The Socks protocol does not encrypt transmission and is not suitable for transmission over the public internet.**
:::
## OutboundConfigurationObject
```json
{
"servers": [
{
"address": "127.0.0.1",
"port": 1234,
"users": [
{
"user": "test user",
"pass": "test pass",
"level": 0
}
]
}
]
}
```
> `servers`: \[ [ServerObject](#serverobject) \]
An array representing a list of Socks servers, where each item is a server configuration.
### ServerObject
```json
{
"address": "127.0.0.1",
"port": 1234,
"users": [
{
"user": "test user",
"pass": "test pass",
"level": 0
}
]
"user": "test user",
"pass": "test pass",
"level": 0,
"email": "love@xray.com"
}
```
> `address`: address
The server address. Required.
Server address. Required.
::: tip
Only connections to Socks 5 servers are supported.
@@ -56,36 +29,22 @@ Only connections to Socks 5 servers are supported.
> `port`: number
The server port. Required.
> `users`: \[ [UserObject](#userobject) \]
An array representing a list of users. Each item in the array is a user configuration.
When the list is not empty, the Socks client will authenticate using the user information. If not specified, no authentication is performed.
The default value is an empty array.
#### UserObject
```json
{
"user": "test user",
"pass": "test pass",
"level": 0
}
```
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
The user level. Connections will use the corresponding [local policy](../policy.md#levelpolicyobject) associated with this user level.
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 `level` value corresponds to the `level` value 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.
> `email`: string
Email address, used to identify the user. Optional if the remote server requires authentication; otherwise, do not include this item.
docs/en/config/outbounds/trojan.md
+8 -28
View File
@@ -1,33 +1,13 @@
# Trojan
[Trojan](https://trojan-gfw.github.io/trojan/protocol) protocol
[Trojan](https://trojan-gfw.github.io/trojan/protocol) protocol.
::: danger
Trojan is designed to work with correctly configured encrypted TLS tunnels.
Trojan is designed to work over a correctly configured encrypted TLS tunnel.
:::
## OutboundConfigurationObject
```json
{
"servers": [
{
"address": "127.0.0.1",
"port": 1234,
"password": "password",
"email": "love@xray.com",
"level": 0
}
]
}
```
> `servers`: \[ [ServerObject](#serverobject) \]
An array representing a list of servers, where each item is a [ServerObject](#serverobject).
### ServerObject
```json
{
"address": "127.0.0.1",
@@ -40,22 +20,22 @@ An array representing a list of servers, where each item is a [ServerObject](#se
> `address`: address
The server address, which can be an IPv4, IPv6, or domain name. Required.
Server address. Supports IPv4, IPv6, and domain names. Required.
> `port`: number
The server port, usually the same port that the server is listening on.
Server port. Usually the same as the port the server is listening on.
> `password`: string
The password for authentication. Required. It can be any string.
Password. Required, any string.
> `email`: string
The email address, optional, used to identify the user.
Email address. Optional, used to identify the user.
> `level`: number
The user level. Connections will use the corresponding [local policy](../policy.md#levelpolicyobject) associated with this user level.
User level. Connections will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
The `level` value corresponds to the `level` value in the [policy](../policy.md#policyobject). If not specified, the default value is 0.
The value of `level` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.
docs/en/config/outbounds/vless.md
+66 -90
View File
@@ -1,135 +1,111 @@
# VLESS
# VLESS (XTLS Vision Seed)
::: danger
Currently, VLESS does not have built-in encryption, please use it on a reliable channel, such as TLS.
:::
VLESS is a stateless lightweight transport protocol. It consists of inbound and outbound parts and can serve as a bridge between the Xray client and server.
VLESS is a stateless lightweight transport protocol, which is divided into inbound and outbound parts, and can be used as a bridge between Xray clients and servers.
Unlike [VMess](./vmess.md), VLESS does not rely on system time, and the authentication method is also UUID.
Unlike [VMess](./vmess.md), VLESS does not depend on system time. The authentication method is also UUID.
## OutboundConfigurationObject
```json
{
"vnext": [
{
"address": "example.com",
"port": 443,
"users": [
{
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"encryption": "none",
"flow": "xtls-rprx-vision",
"level": 0
}
]
}
]
}
```
> `vnext`: \[ [ServerObject](#serverobject) \]
An array, representing the VLESS server list, containing a set of configurations pointing to the server, each of which is a server configuration.
### ServerObject
```json
{
"address": "example.com",
"port": 443,
"users": [
{
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"encryption": "none",
"flow": "xtls-rprx-vision",
"level": 0
}
]
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"encryption": "none",
"flow": "xtls-rprx-vision",
"level": 0,
"reverse": {}
}
```
> `address`: address
Server address, pointing to the server, supporting domain names, IPv4, and IPv6.
Server address, points to the server. Supports domain names, IPv4, and IPv6.
> `port`: number
Server port, usually the same as the port listened by the server.
> `users`: \[ [UserObject](#userobject) \]
Array, a list of users recognized by the server, each of which is a user configuration.
### UserObject
```json
{
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"encryption": "none",
"flow": "xtls-rprx-vision",
"level": 0
}
```
Server port, usually the same as the port the server is listening on.
> `id`: string
The user ID of VLESS, which can be any string less than 30 bytes, or a valid UUID.
Custom strings and their mapped UUIDs are equivalent, which means you can write an id in the configuration file to identify the same user, i.e.
User ID for VLESS. It can be any string less than 30 bytes, or a valid UUID.
A custom string and its mapped UUID are equivalent. This means you can identify the same user in the configuration file by writing the ID in either way:
- Write `"id": "I love 🍉 teacher 1314"`,
- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (this UUID is the UUID mapping of `I love 🍉 teacher 1314`)
- Write `"id": "我爱🍉老师1314"`,
- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the UUID mapping of `我爱🍉老师1314`)
The mapping standard is in [VLESS UUID mapping standard: mapping custom strings to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158)
The mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
You can use the command `xray uuid -i "custom string"` to generate the UUID mapped by the custom string, or use the command `xray uuid` to generate a random UUID.
You can use the command `xray uuid -i "custom string"` to generate the UUID mapped from a custom string, or use the command `xray uuid` to generate a random UUID.
> `encryption`: "none"
Need to fill in `"none"`, cannot be left empty.
[VLESS Encryption](https://github.com/XTLS/Xray-core/pull/5067) settings. Cannot be left empty; to disable, explicitly set to `"none"`.
This requirement is to remind users that there is no encryption and to prevent users from filling in the wrong attribute name or location, causing exposure when encryption methods come out in the future.
It is recommended for most users to use `./xray vlessenc` to automatically generate this field to ensure no errors in writing. The detailed configuration below is recommended only for advanced users.
If the value of encryption is not set correctly, an error message will be received when using Xray or -test.
Its format is a detailed configuration string of fields connected by `.`. For example: `mlkem768x25519plus.native.0rtt.100-111-1111.75-0-111.50-0-3333.ptjHQxBQxTJ9MWr2cd5qWIflBSACHOevTauCQwa_71U`. This document will refer to the separate parts separated by dots as "blocks".
- **The 1st block** is the handshake method. Currently, there is only `mlkem768x25519plus`. Requires consistency between server and client.
- **The 2nd block** is the encryption method. Options are `native`/`xorpub`/`random`, corresponding to: raw format packet / raw format + obfuscated public key part / fully random numbers (similar to VMESS/Shadowsocks). Requires consistency between server and client.
- **The 3rd block** is session resumption. Choosing `0rtt` will follow the server settings to attempt to use previously generated tickets to skip the handshake for fast connection (can be manually disabled by the server). Choosing `1rtt` will force a 1-RTT handshake process. The meaning here differs from the server setting; see VLESS Inbound `decryption` settings for details.
Following blocks are **padding**. After the connection is established, the client sends some garbage data to obfuscate length characteristics. It does not need to be the same as the server (the corresponding part in the inbound is the padding sent from the server to the client). It is a variable-length part with the format `padding.delay.padding` + `(.delay.padding)` × n (multiple padding blocks can be inserted, requiring a delay block between two padding blocks). For example, you can write a very long `padding.delay.padding.delay.padding.delay.padding.delay.padding.delay.padding`.
- `padding` format is `probability-min-max`. E.g., `100-111-1111` means 100% probability to send a padding of length 111~1111.
- `delay` format is also `probability-min-max`. E.g., `75-0-111` means 75% probability to wait 0~111 milliseconds.
The first padding block has special requirements: probability must be 100% and minimum length greater than 0. If no padding exists, the core automatically uses `100-111-1111.75-0-111.50-0-3333` as the padding setting.
**The last block** will be recognized by the core as the parameter used to authenticate the server. It can be generated by `./xray x25519` (using the Password part) or `./xray mlkem768` (using the Client part). It must correspond to the server. `mlkem768` belongs to post-quantum algorithms, preventing (future) client parameter leaks from allowing quantum computers to crack the private key and impersonate the server. This parameter is only used for verification; the handshake process is post-quantum secure regardless, and existing encrypted data cannot be decrypted by future quantum computers.
> `flow`: string
Flow control mode, used to select the XTLS algorithm.
Currently, there are the following flow control modes available in the outbound protocol:
Currently, the following flow control modes are available in the outbound protocol:
- No `flow` or empty string: Use regular TLS proxy.
- `xtls-rprx-vision`: using the new XTLS mode includes inner handshake random padding supports uTLS client fingerprint simulation
- `xtls-rprx-vision-udp443`: same as `xtls-rprx-vision`, but allows UDP traffic with a destination of port 443
- **No `flow` or empty string**: Use standard TLS proxy.
- **`xtls-rprx-vision`**: Use XTLS, including inner handshake random padding. Will intercept UDP traffic targeting port 443 (QUIC) to force browsers to use standard HTTPS, increasing traffic that can be Spliced.
- **`xtls-rprx-vision-udp443`**: Same as `xtls-rprx-vision`, but does not intercept UDP 443. Used when a program forces the use of QUIC and would fail to work if intercepted.
Additionally, XTLS currently only supports TCP+TLS/Reality.
XTLS is available only in the following combinations:
<!-- prettier-ignore -->
::: tip About xtls-rprx-*-udp443 flow control mode
- **TCP+TLS/Reality**: In this case, if transmitting TLS 1.3, the core will attempt to Splice encrypted data at the bottom layer. If successful, it saves all core IO overhead.
- **VLESS Encryption**: No underlying transport restrictions. If the underlying transport is not TCP, it only attempts to penetrate Encryption, saving Encryption overhead. If it is TCP, it will still attempt to perform Splice.
When using Xray-core's XTLS, traffic to UDP port 443 is blocked by default (generally for QUIC), so the application will use TLS instead of QUIC, and XTLS will take effect. In fact, QUIC itself is not suitable for proxying because it has its own TCP functionality. When it is transmitted as UDP traffic through the VLESS protocol, the underlying protocol is TCP, which is equivalent to two layers of TCP.
::: tip About Splice
Splice is a function provided by the Linux Kernel. The system kernel forwards TCP directly, no longer passing through Xray's memory, greatly reducing data copying and CPU context switching.
If you do not need to block it, please fill in `xtls-rprx-*-udp443` on the client side and do not change the server side.
:::
When using Vision mode, Splice is automatically enabled if the following conditions are met:
::: tip About Splice mode
Splice is a function provided by the Linux Kernel. The system kernel directly forwards TCP without going through Xray's memory, greatly reducing the number of data copies and CPU context switches.
- Linux environment.
- Inbound protocol is a pure TCP connection like `Dokodemo door`, `Socks`, `HTTP`, or other inbound protocols using XTLS.
- Outbound protocol is VLESS + XTLS.
The usage restrictions of Splice mode are:
- Linux environment
- Inbound protocols are `Dokodemo door`, `Socks`, `HTTP`, etc., pure TCP connections, or other inbound protocols that use XTLS
- Outbound protocol is VLESS + XTLS
- It is worth noting that when using the mKCP protocol, Splice will not be used (yes, although there is no error, it is not used at all)
In addition, when using Splice, the speed display will lag behind, which is a feature, not a bug.
Using Vision mode will automatically enable Splice if the above conditions are met.
When using Splice, the network speed display will lag and will only be counted after the connection is disconnected because the core cannot know the traffic situation while the kernel takes over the connection.
:::
> `level`: number
User level, the connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
User level. The connection will use the [Local Policy](../policy.md#levelpolicyobject) corresponding to this user level.
The value of level corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, the default is 0.
The value of `level` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, it defaults to 0.
> `reverse`: struct
VLESS minimalist reverse proxy configuration. It functions the same as the core's built-in generic reverse proxy but is simpler to configure.
The existence of this item indicates that this outbound can be used as a VLESS reverse proxy outbound, and it will automatically establish a connection to the server to register the reverse proxy tunnel.
Current syntax:
```json
"reverse": {
"tag": "r-inbound"
}
```
`tag` is the inbound proxy tag for this reverse proxy. When the server dispatches a reverse proxy request, it enters the routing system from the inbound using this tag, and the routing system routes it to the outbound you need.
The UUID used needs to be a UUID that is also configured with reverse on the server side (see VLESS Inbound for details).
docs/en/config/outbounds/vmess.md
+27 -67
View File
@@ -1,108 +1,68 @@
# VMess
[VMess](../../development/protocols/vmess.md) is an encrypted transport protocol commonly used as a bridge between Xray clients and servers.
[VMess](../../development/protocols/vmess.md) is an encrypted transport protocol, usually serving as a bridge between the Xray client and server.
::: danger
VMess relies on system time. Please ensure that the UTC time of your system, when using Xray, has an error within 120 seconds, regardless of the time zone. On Linux systems, you can install the `ntp` service to automatically synchronize the system time.
VMess depends on system time. Please ensure that the UTC time of the system running Xray is within 120 seconds of the actual time, independent of the time zone. On Linux systems, you can install the `ntp` service to automatically synchronize the system time.
:::
## OutboundConfigurationObject
```json
{
"vnext": [
{
"address": "127.0.0.1",
"port": 37192,
"users": [
{
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"security": "auto",
"level": 0
}
]
}
]
}
```
> `vnext`：\[ [ServerObject](#serverobject) \]
An array containing a set of server configurations.
Each item in the array is a server configuration [ServerObject](#serverobject).
### ServerObject
```json
{
"address": "127.0.0.1",
"port": 37192,
"users": []
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"security": "auto",
"level": 0,
"experiments": ""
}
```
> `address`: address
The server address, which can be an IP address or domain name.
Server address, supports IP address or domain name.
> `port`: number
The port number that the server is listening on. Required.
> `users`: \[ [UserObject](#userobject) \]
An array representing a group of users authorized by the server.
Each item is a user configuration [UserObject](#userobject).
#### UserObject
```json
{
"id": "5783a3e7-e373-51cd-8642-c83782b807c5",
"security": "auto",
"level": 0
}
```
The port number the server is listening on. Required.
> `id`: string
The user ID for VMess, which can be any string less than 30 bytes or a valid UUID.
VMess User ID. It can be any string less than 30 bytes or a valid UUID.
Custom strings and their corresponding UUIDs are equivalent. This means that you can use either a custom string or its corresponding UUID to identify the same user in the configuration file. For example:
A custom string and its mapped UUID are equivalent. This means you can identify the same user in the configuration file like this:
- Write `"id": "我爱🍉老师1314"`,
- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (this UUID is the mapping of the custom string "我爱 🍉 老师 1314")
- Or write `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (This UUID is the UUID mapping of `我爱🍉老师1314`)
The mapping standard is described in the [VLESS UUID Mapping Standard: Mapping a Custom String to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
The mapping standard is described in [VLESS UUID Mapping Standard: Mapping Custom Strings to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158).
You can use the command `xray uuid -i "custom string"` to generate the UUID corresponding to a custom string, or use the command `xray uuid` to generate a random UUID.
You can use the command `xray uuid -i "custom string"` to generate the UUID mapped from the custom string. You can also use the command `xray uuid` to generate a random UUID.
> `level`: number
The user level. Connections will use the corresponding [local policy](../policy.md#levelpolicyobject) associated with this user level.
User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
The `level` value corresponds to the `level` value in the [policy](../policy.md#policyobject). If not specified, the default value is 0.
The value of `level` corresponds to the value of `level` in [policy](../policy.md#policyobject). If not specified, the default is 0.
> `security`: "aes-128-gcm" | "chacha20-poly1305" | "auto" | "none" | "zero"
The encryption method. The client will use the configured encryption method to send data, and the server will automatically recognize it without the need for configuration.
Encryption method. The client will use the configured encryption method to send data, and the server will automatically identify it without configuration.
- `"aes-128-gcm"`: Recommended for use on PCs.
- `"chacha20-poly1305"`: Recommended for use on mobile devices.
- `"auto"`: Default value. Automatically selects the encryption method (uses aes-128-gcm when running on AMD64, ARM64, or s390x architecture, and Chacha20-Poly1305 in other cases).
- `"none"`: No encryption.
- `"zero"`: No encryption and no message authentication (v1.4.0+).
- `"aes-128-gcm"`: Use AES-128-GCM algorithm.
- `"chacha20-poly1305"`: Use Chacha20-Poly1305 algorithm.
- `"auto"`: Default value. Automatically selected (uses aes-128-gcm encryption when the running framework is AMD64, ARM64, or s390x; uses Chacha20-Poly1305 encryption in other cases).
- `"none"`: No encryption, maintains the VMess message structure.
- `"zero"`: No encryption, direct stream copy (similar to VLESS).
::: tip
It is recommended to use the `"auto"` encryption method as it ensures long-term security and compatibility.
It is not recommended to use `"none"` or `"zero"` pseudo-encryption methods without enabling TLS encryption and enforcing certificate verification. Regardless of the encryption method used, the VMess packet header is protected by encryption and authentication.
The `"none"` pseudo-encryption method calculates and verifies the packet's checksum. However, due to the lack of hardware support for the authentication algorithm, it may be slower than the hardware-accelerated `"aes-128-gcm"` on some platforms.
Note: `"auto"` only determines the AES hardware acceleration support status of the *client*. If the *server* does not support AES hardware acceleration, you still need to manually set it to `chacha20-poly1305`. This is very important because Chacha20-Poly1305 takes about 48% more time than AES-128-GCM on platforms supporting AES acceleration, but on platforms *without* AES acceleration, AES-128-GCM takes over 2000% more time than Chacha20-Poly1305.
The `"zero"` pseudo-encryption method neither encrypts the message nor calculates the checksum, theoretically providing higher speed than any other encryption method. The actual speed may be influenced by other factors.
> `experiments`: string
It is not recommended to use the `"none"` or `"zero"` pseudo-encryption methods without enabling TLS encryption and forcibly verifying certificates. If you use a CDN or other intermediate platforms or network environments that decrypt TLS connections, it is not recommended to use the `"none"` or `"zero"` pseudo-encryption methods.
Enabled VMess protocol experimental features. (Features here are unstable and may be removed at any time). Multiple enabled experiments can be separated by the `|` character, such as `"AuthenticatedLength|NoTerminationSignal"`.
Regardless of the encryption method used, the VMess packet header is protected by encryption and authentication.
:::
- `"AuthenticatedLength"`: Enable authenticated packet length experiment. This experiment requires both the client and server to enable it simultaneously and run the same version of the program.
- `"NoTerminationSignal"`: Enable not sending the disconnection signal. This feature is now enabled by default.
docs/en/config/outbounds/wireguard.md
+50 -60
View File
@@ -1,9 +1,9 @@
# Wireguard
Wireguard is a standard implementation of the Wireguard protocol.
Standard Wireguard protocol implementation.
::: danger
**The Wireguard protocol is not specifically designed for circumvention purposes. If used as the outer layer for circumvention, its characteristics may lead to server blocking.**
**The Wireguard protocol is not designed specifically for bypassing firewalls. If used at the outermost layer to cross the Great Firewall, distinctive characteristics may lead to the server being blocked.**
:::
## OutboundConfigurationObject
@@ -23,6 +23,7 @@ Wireguard is a standard implementation of the Wireguard protocol.
"publicKey": "PUBLIC_KEY"
}
],
"noKernelTun": false,
"mtu": 1420, // optional, default 1420
"reserved": [1, 2, 3],
"workers": 2, // optional, default runtime.NumCPU()
@@ -31,81 +32,70 @@ Wireguard is a standard implementation of the Wireguard protocol.
```
::: tip
Currently, the Wireguard protocol outbound does not support setting `streamSettings`.
Currently, configuring `streamSettings` is not supported in the Wireguard protocol outbound.
:::
> `secretKey`: string
The user's private key. Required.
User private key. Required.
> `address`: string array
Wireguard will create a virtual network interface `tun` locally. Use one or more IP addresses, including IPv6.
Wireguard will start a virtual network interface (tun) locally. Use one or more IP addresses; IPv6 is supported.
> `noKernelTun`: true | false
By default, the core detects if it is running on Linux and if the current user has `CAP_NET_ADMIN` permissions to decide whether to enable the system virtual network interface; otherwise, it uses gVisor. Using the system virtual interface offers relatively higher performance. Note that this is only for processing IP packets and has nothing to do with the wireguard kernel module.
This detection may not always be accurate. For example, some LXC virtualization environments may not have TUN permissions at all, causing the outbound to fail. Therefore, you can set this option to manually disable it.
When using the system virtual interface, it occupies IPv6 routing table number `10230`. Each additional Wireguard outbound will use subsequent routing tables sequentially; for example, the second one will use routing table `10231`, and so on.
Note that if a second Xray instance is started on the same machine, it will not assign the next routing table number but will continue trying to use routing table `10230`. Since it is already occupied by the first Xray instance, it will fail to connect. If absolutely needed, you must set this option to disable the system virtual interface.
> `mtu`: int
The fragment size of the underlying `tun` device in Wireguard.
MTU size of the underlying Wireguard tun.
<details>
<summary>MTU Calculation Method</summary>
The structure of a Wireguard packet is as follows:
```
- 20-byte IPv4 header or 40 byte IPv6 header
- 8-byte UDP header
- 4-byte type
- 4-byte key index
- 8-byte nonce
- N-byte encrypted data
- 16-byte authentication tag
```
`N-byte encrypted data` is the MTU value we need. Depending on whether the endpoint is IPv4 or IPv6, the specific value can be 1440 (IPv4) or 1420 (IPv6). If in a special environment, subtract further (e.g., home broadband PPPoE requires an extra -8).
</details>
> `reserved` \[ number \]
Wireguard Reserved Bytes.
Xray-core v1.8.0 New parameter.<br>
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.<br>
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.<br>
If you do not write this parameter, or leave it blank, the default value is `"ForceIP"`.<br>
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.<br>
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. `<br>
**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.<br>
Note: When applied to proxied traffic, this option is also constrained by the `address` option. For example, if you set `ForceIPv6v4` but no IPv6 address is set in `address`, even if the target domain has AAAA records, they will not be resolved/used.
### Peers
@@ -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`.<br>
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`<br>
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.
docs/en/config/policy.md
+26 -21
View File
@@ -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.
docs/en/config/reverse.md
+71 -40
View File
@@ -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"
}
docs/en/config/routing.md
+180 -162
View File
@@ -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).
docs/en/config/stats.md
+15 -15
View File
@@ -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.
docs/en/config/transport.md
+457 -267
View File
File diff suppressed because it is too large Load Diff
docs/en/config/transports/grpc.md
+50 -34
View File
@@ -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.<br>
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 <Badge text="BETA" type="warning"/>
`true` enables `multiMode`, with a default value of `false`.
`true` enables `multiMode`. Default value: `false`.
This is an **experimental** option that may not be retained for the long term, and cross-version compatibility is not guaranteed. This mode can bring about a performance improvement of around 20% in **test environments**, but actual effects may vary depending on the transmission rate.
This is an **experimental** option. It may not be kept long-term and cross-version compatibility is not guaranteed. This mode can bring about a 20% performance improvement in **test environments**, but actual results vary depending on transfer rates.
::: tip
**Only need to be configured** in `outbound` **(client)**.
**Only** needs to be configured on **outbound** (**client**).
:::
> `idle_timeout`: number
The health check is performed when no data transmission occurs for a certain period of time, measured in seconds. If this value is set to less than `10`, `10` will be used as the minimum value.
Unit: seconds. When there is no data transmission during this period, a health check will be performed. If this value is set below `10`, `10` will be used (the minimum value).
::: tip
If you are not using reverse proxy tools such as Caddy or Nginx (**which is usually the case**), if this value is set to less than `60`, the server may send "unexpected h2 GOAWAY" frames to close existing connections.
If you are not using reverse proxy tools like Caddy or Nginx (**usually not**), and set this below `60`, the server might send unexpected h2 GOAWAY frames to close existing connections.
:::
By default, the health check is **not enabled**.
Health checks are **disabled** by default.
::: tip
**Only need to be configured** in `outbound` **(client)**.
**Only** needs to be configured on **outbound** (**client**).
:::
::: tip
Enabling health checks may help solve some "connection drop" issues.
May resolve some "disconnection" issues.
:::
> `health_check_timeout`: number
The timeout for the health check, measured in seconds. If the health check is not completed within this time period, it is considered to have failed.
The default value is `20`
Unit: seconds. The timeout for health checks. If the health check is not completed within this time, and there is still no data transmission, the health check is considered failed. Default value is `20`.
::: tip
**Only need to be configured** in `outbound` **(client)**.
**Only** needs to be configured on **outbound** (**client**).
:::
> `permit_without_stream`: true | false
`true` allows health checks to be performed when there are no sub-connections. The default value is `false`.
`true` allows health checks when there are no sub-connections (streams). Default value is `false`.
::: tip
**Only need to be configured** in `outbound` **(client)**.
**Only** needs to be configured on **outbound** (**client**).
:::
> `initial_windows_size`: number
The initial window size of the h2 stream. When the value is less than or equal to `0`, this feature does not take effect. When the value is greater than `65535`, the Dynamic Window mechanism will be disabled. The default value is `0`, which means it is not effective.
Initial window size for h2 Stream. When the value is less than or equal to `0`, this feature does not take effect. When the value is greater than `65535`, the Dynamic Window mechanism will be disabled. Default value is `0` (disabled).
::: tip
**Only need to be configured** in `outbound` **(client)**.
**Only** needs to be configured on **outbound** (**client**).
:::
::: tip
When using Cloudflare CDN, set the value to `35536` or higher to disable the Dynamic Window mechanism and prevent Cloudflare CDN from sending "unexpected h2 GOAWAY" frames to close existing connections.
When going through Cloudflare CDN, you can set the value to `65536` or higher (disabling Dynamic Window) to prevent Cloudflare CDN from sending unexpected h2 GOAWAY frames to close existing connections.
:::
docs/en/config/transports/httpupgrade.md
+16 -15
View File
@@ -1,16 +1,15 @@
# HTTPUpgrade
A WebSocket-like transport protocol implementing the HTTP/1.1 upgrade and response, allowing it to be reverse proxied by web servers or CDNs just like WebSocket, but without the need to implement the remaining portions of the WebSocket protocol, yielding better performance.
Standalone usage is not recommended, but rather in conjunction with other security protocols like TLS.
A protocol that implements HTTP 1.1 upgrade requests and responses similar to WebSocket. This allows it to be reverse-proxied by CDNs or Nginx just like WebSocket, but without the need to implement other parts of the WebSocket protocol, resulting in higher efficiency.
Its design is not recommended for standalone use; instead, it is intended to work with security protocols like TLS.
::: danger
**It is recommended to switch to [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) to avoid significant traffic characteristics such as HTTPUpgrade "ALPN is http/1.1".**
**It is recommended to switch to [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) to avoid significant traffic fingerprints such as HTTPUpgrade's "ALPN is http/1.1".**
:::
## HttpUpgradeObject
The `HttpUpgradeObject` corresponds to the `httpupgradeSettings` section under transport configurations.
`HttpUpgradeObject` corresponds to the `httpupgradeSettings` item in transport configuration.
```json
{
@@ -25,28 +24,30 @@ The `HttpUpgradeObject` corresponds to the `httpupgradeSettings` section under t
> `acceptProxyProtocol`: true | false
For inbounds only. Specifies whether to accept the PROXY protocol.
Only used for inbound; indicates whether to accept PROXY protocol.
The [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is used to pass the real IP address and port of a connection along. **Ignore it if you have no knowledge regarding this**.
[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is dedicated to passing the real source IP and port of the request. **If you don't know what it is, please ignore this item for now.**
Common reverse proxies (e.g. HAProxy, NGINX) and VLESS fallbacks xver can be configured for its inclusion.
Common reverse proxy software (such as HAProxy, Nginx) can be configured to send it. VLESS fallbacks xver can also send it.
When `true`, the downstream must first send PROXY protocol version 1 or 2 after establishing the underlying TCP connection, or the connection will be closed.
When set to `true`, after the underlying TCP connection is established, the requester must send PROXY protocol v1 or v2 first; otherwise, the connection will be closed.
> `path`: string
HTTP path used by the HTTPUpgrade connection. Defaults to `"/"`.
The HTTP path used by HTTPUpgrade. Default value is `"/"`.
If the `path` property include an `ed` query field (e.g. `/mypath?ed=2560`), "early data" will be used to decrease latency, with the value defining the threshold of the first packet's size. If the size of the first packet exceeds the defined value, "early data" will not be applied. The recommended value is `2560`.
If the client path contains the `ed` parameter (e.g., `/mypath?ed=2560`), `Early Data` will be enabled to reduce latency. The value represents the threshold for the first packet length. If the first packet length exceeds this value, `Early Data` will not be enabled. The recommended value is 2560.
> `host`: string
HTTP Host sent by the HTTPUpgrade connection. Empty by default. If this value is empty on the server, the host header sent by clients will not be validated.
The host sent in the HTTP request of HTTPUpgrade. Default value is empty. If the server-side value is empty, the host value sent by the client is not verified.
If the `Host` header has been defined on the server in any way, the server will validate if the `Host` header matches.
When this value is specified on the server, or specified in `headers`, it will verify whether it is consistent with the host requested by the client.
The current priority of the `Host` header sent by clients: `host` > `headers` > `address`
Priority of the host sent by the client: `host` > `headers` > `address`
> `headers`: map \{string: string\}
Customized HTTP headers defined in key-value pairs. Defaults to empty.
Client-only. Custom HTTP headers. A key-value pair, where each key represents the name of an HTTP header, and the corresponding value is a string.
Default value is empty.
docs/en/config/transports/hysteria.md
+81
View File
@@ -0,0 +1,81 @@
# Hysteria
The Xray implementation of Hysteria2's underlying QUIC transport. It is usually used in conjunction with [hysteria2 outbound](../outbounds/hysteria.md).
## HysteriaObject
`HysteriaObject` corresponds to the `hysteriaSettings` item in the transport configuration.
```json
{
"version": 2,
"auth": "password",
"up": "0",
"down": "0",
"udphop": {
"port": "1145-1919",
"interval": 30
},
"initStreamReceiveWindow": 8388608,
"maxStreamReceiveWindow": 8388608,
"initConnectionReceiveWindow": 20971520,
"maxConnectionReceiveWindow": 20971520,
"maxIdleTimeout": 30,
"keepAlivePeriod": 0,
"disablePathMTUDiscovery": false
}
```
> `version`: number
Hysteria version, must be 2.
> `auth`: string
Hysteria authentication password. Must be consistent between the server and the client.
> `up`: string
> `down`: string
Upload/Download rate limits. Default is 0.
The format is user-friendly and supports various common bit-per-second notations, including `1000000`, `100kb`, `20 mb`, `100 mbps`, `1g`, `1 tbps`, etc. It is case-insensitive, and spaces between the number and unit are optional. If no unit is specified, it defaults to bps (bits per second). It cannot be lower than 65535 bps.
The negotiation behavior is consistent with the original Hysteria:
The server's value limits the maximum Brutal mode rate that the client can choose. 0 means no limit on the client.
If the client sets this to 0, it uses BBR mode. If not 0, it uses Brutal mode, subject to the server's limit.
Note relativity: Server upload is client download, and server download is client upload.
> `udphop`: {"port": string, "interval": number}
UDP port hopping configuration.
`port` is the port range for hopping. It can be a numeric string, such as `"1234"`; or a numeric range, such as `"1145-1919"` (indicating ports 1145 to 1919, totaling 775 ports). Commas can be used for segmentation, such as `11,13,15-17` (indicating port 11, port 13, and ports 15 to 17, totaling 5 ports).
`interval` is the port hopping interval in seconds. Minimum is 5, default is 30 seconds.
> `initStreamReceiveWindow`: number
> `maxStreamReceiveWindow`: number
> `initConnectionReceiveWindow`: number
> `maxConnectionReceiveWindow`: number
These four are specific QUIC window parameters. **Unless you fully understand what you are doing, it is not recommended to modify these values.** If you must modify them, it is recommended to keep the ratio of the stream receive window to the connection receive window at 2:5.
> `maxIdleTimeout`: number
Maximum idle timeout (seconds). The server will close the connection if no data is received from the client for this duration. Range: 4~120 seconds. Default: 30 seconds.
> `keepAlivePeriod`: number
QUIC KeepAlive interval (seconds). Range: 2~60 seconds. Disabled by default.
> `disablePathMTUDiscovery`: bool
Whether to disable Path MTU Discovery.
docs/en/config/transports/index.md
+2 -1
View File
@@ -1,4 +1,4 @@
# Xray Transport Layer List
# Xray Transport Layer
Xray supports the following transport layers:
@@ -8,3 +8,4 @@ Xray supports the following transport layers:
- [gRPC](grpc.md)
- [WebSocket](websocket.md)
- [HTTPUpgrade](httpupgrade.md)
- [Hysteria](hysteria.md)
docs/en/config/transports/mkcp.md
+63 -51
View File
@@ -1,16 +1,16 @@
# mKCP
mKCP uses UDP to emulate TCP connections.
mKCP uses UDP to simulate TCP connections.
mKCP sacrifices bandwidth to reduce latency. To transmit the same content, mKCP generally consumes more data than TCP.
mKCP sacrifices bandwidth to reduce latency. To transmit the same amount of content, mKCP generally consumes more traffic than TCP.
::: tip
Make sure the firewall on the host is configured correctly.
Please ensure that the firewall configuration on the host is correct.
:::
## KcpObject
`KcpObject` corresponds to the `kcpSettings` in the [Transport Protocol](../transport.md)
`KcpObject` corresponds to the `kcpSettings` item in the transport configuration.
```json
{
@@ -22,7 +22,8 @@ Make sure the firewall on the host is configured correctly.
"readBufferSize": 1,
"writeBufferSize": 1,
"header": {
"type": "none"
"type": "none",
"domain": "example.com"
},
"seed": "Password"
}
@@ -30,112 +31,123 @@ Make sure the firewall on the host is configured correctly.
> `mtu`: number
Maximum transmission unit. It indicates the maxium bytes that an UDP packet can carry. Recommended value is between `576` and `1460`
Maximum Transmission Unit.
Please select a value between 576 and 1460.
The default value is `1350`
The default value is `1350`.
> `tti`: number
Transmission time interval, measured in milliseconds (ms), determines how often mKCP sends data. Please choose a value between `10` and `100`
Transmission Time Interval, in milliseconds (ms). mKCP will send data at this frequency.
Please select a value between 10 and 100.
The default value is `50`
The default value is `50`.
> `uplinkCapacity`: number
Uplink capacity refers to the maximum bandwidth used by the host to send data, measured in MB/s (note: Byte, not bit). It can be set to 0, indicating a very small bandwidth.
Uplink capacity, i.e., the maximum bandwidth used by the host to send data. The unit is MB/s. Note that it is Byte, not bit.
Can be set to 0, representing a very small bandwidth.
The default value is `5`
The default value is `5`.
> `downlinkCapacity`: number
Downlink capacity refers to the maximum bandwidth used by the host to receive data, measured in MB/s (note: Byte, not bit). It can be set to 0, indicating a very small bandwidth.
Downlink capacity, i.e., the maximum bandwidth used by the host to receive data. The unit is MB/s. Note that it is Byte, not bit.
Can be set to 0, representing a very small bandwidth.
The default value is `20`
The default value is `20`.
::: tip
`uplinkCapacity` and `downlinkCapacity` determine the transmission speed of mKCP. For example, when a client sends data, the client's `uplinkCapacity` specifies the speed of sending data, while the server's `downlinkCapacity` specifies the speed of receiving data. The value used is the smaller of the two.
`uplinkCapacity` and `downlinkCapacity` determine the transmission speed of mKCP.
Taking a client sending data as an example, the client's `uplinkCapacity` specifies the speed of sending data, while the server's `downlinkCapacity` specifies the speed of receiving data. The actual speed will be the smaller of the two values.
It is recommended to set `downlinkCapacity` to a larger value, such as `100`, and set `uplinkCapacity` to the actual network speed. If the speed is insufficient, gradually increase the value of `uplinkCapacity` until it is about twice the bandwidth.
It is recommended to set `downlinkCapacity` to a larger value, such as 100, and set `uplinkCapacity` to the actual network speed. When the speed is insufficient, you can gradually increase the value of `uplinkCapacity` until it is about twice the bandwidth.
:::
> `congestion`: true | false
Whether or not to enable congestion control.
When congestion control is enabled, Xray will detect network quality. It will send less packets when packet loss is severe, or more packets when network is not fully filled.
Whether to enable congestion control.
The default value is `false`
When congestion control is enabled, Xray automatically monitors network quality. When packet loss is severe, it automatically reduces throughput; when the network is smooth, it appropriately increases throughput.
The default value is `false`.
> `readBufferSize`: number
The read buffer size for a single connection, measured in `MB`
The read buffer size for a single connection, in MB.
The default value is `2`
The default value is `2`.
> `writeBufferSize`: number
The write buffer size for a single connection, measured in `MB`
The write buffer size for a single connection, in MB.
The default value is `2`
The default value is `2`.
::: tip
`readBufferSize` and `writeBufferSize` specify the memory size used by a single connection. When high-speed transmissions are required, specifying larger values for `readBufferSize` and `writeBufferSize` can improve speed to some extent, but it will also consume more memory.
`readBufferSize` and `writeBufferSize` specify the memory size used by a single connection.
When high-speed transmission is required, specifying larger `readBufferSize` and `writeBufferSize` will improve speed to a certain extent, but it will also use more memory.
When the network speed is no more than `20 MB/s`, the default value of `1MB` is sufficient; after exceeding this limit, you can increase the values of `readBufferSize` and `writeBufferSize` appropriately and then manually balance the relationship between speed and memory.
When the network speed does not exceed 20MB/s, the default value of 1MB can meet the demand; beyond that, you can appropriately increase the values of `readBufferSize` and `writeBufferSize`, and then manually balance the relationship between speed and memory.
:::
> `header`: [HeaderObject](#headerobject)
Configuration for packet header obfuscation.
Packet header camouflage settings.
> `seed`: string
An optional obfuscation seed is used to obfuscate traffic data using the `AES-128-GCM` algorithm. The client and server need to use the same seed.
Optional obfuscation password. Uses the AES-128-GCM algorithm to obfuscate traffic data. Must be consistent between the client and the server.
This obfuscation mechanism cannot ensure the security of the content, but it may be able to resist some blocking.
This obfuscation mechanism cannot be used to guarantee the security of communication content, but it may help mitigate some forms of blocking.
::: tip NOTE
Currently, in the testing environment, enabling this setting has not resulted in the original unobfuscated version being blocked by ports.
:::
> Currently, in test environments, no port blocking phenomena have been observed after enabling this setting compared to the original unobfuscated version.
### HeaderObject
```json
{
"type": "none"
"type": "none",
"domain": "example.com"
}
```
> `type`: string
Type of obfuscation. Corresponding inbound and outbound must have the same value. Choices are:
Camouflage type. Optional values are:
- `"none"`：Default value. No obfuscation is used.
- `"srtp"`：Obfuscated as SRTP traffic. It may be recognized as video calls such as Facetime.
- `"utp"`：Obfuscated as uTP traffic. It may be recognized as Bittorrent traffic.
- `"wechat-video"`：Obfuscated to WeChat traffic.
- `"dtls"`：Obfuscated as DTLS 1.2 packets.
- `"wireguard"`：Obfuscated as WireGuard packets. (NOT true WireGuard protocol)
- `"none"`: Default value. No camouflage is performed; sent data is a packet without characteristics.
- `"srtp"`: Disguised as SRTP packets, recognized as video call data (e.g., FaceTime).
- `"utp"`: Disguised as uTP packets, recognized as BT download data.
- `"wechat-video"`: Disguised as WeChat video call packets.
- `"dtls"`: Disguised as DTLS 1.2 packets.
- `"wireguard"`: Disguised as WireGuard packets. (Not the real WireGuard protocol).
- `"dns"`: Some campus networks allow DNS queries without logging in. Adding a DNS header to KCP allows traffic to be disguised as DNS requests, potentially bypassing login requirements on some campus networks.
## Special Thanks
> `domain`: string
- [@skywind3000](https://github.com/skywind3000) Credit for inventing and implementing the original KCP protocol in C.
- [@xtaci](https://github.com/xtaci) Credit for re-implementing KCP protocol in Go.
- [@xiaokangwang](https://github.com/xiaokangwang) Credit for testing the integration of KCP with Xray and submitting the initial PR.
Used with the camouflage type `"dns"`. You can fill in any domain name.
## Improvements to the KCP protocol
## Credits
### smaller protocol header
- [@skywind3000](https://github.com/skywind3000) Invented and implemented the KCP protocol.
- [@xtaci](https://github.com/xtaci) Ported KCP from C implementation to Go.
- [@xiaokangwang](https://github.com/xiaokangwang) Tested the integration of KCP with Xray and submitted the initial PR.
The original KCP protocol uses a fixed header of 24 bytes, while mKCP modifies it to 18 bytes for data packets and 16 bytes for acknowledgement (ACK) packets. A smaller header helps evade feature detection and speeds up transmission.
## Improvements to the KCP Protocol
In addition, the original KCP can only confirm that one packet has been received with a single ACK packet. This means that when KCP needs to confirm that 100 packets have been received, it will send out 2400 bytes of data (24 x 100), including a large amount of repeated header information that wastes bandwidth. mKCP compresses multiple ACK packets, so 100 ACK packets only require 418 bytes (16 + 2 + 100 x 4), which is equivalent to one-sixth of the original KCP.
### Smaller Protocol Header
### ACK packet retransmission
The native KCP protocol uses a fixed header of 24 bytes, while mKCP modifies this to 18 bytes for data packets and 16 bytes for acknowledgement (ACK) packets. Smaller headers help evade characteristic detection and increase transmission speed.
In the original KCP protocol, an ACK packet is only sent once. If an ACK packet is lost, it will cause unnecessary bandwidth waste due to data retransmission. In contrast, mKCP retransmits ACK packets at a certain frequency until they are confirmed by the sender. The size of a single ACK packet is 22 bytes, much smaller than the data packets which are over 1000 bytes. Therefore, the cost of retransmitting ACK packets is much lower.
Additionally, native KCP's single ACK packet can only acknowledge the receipt of one data packet. This means that when KCP needs to acknowledge the receipt of 100 data packets, it sends 24 *100 = 2400 bytes of data. This includes a large amount of repetitive header data, causing bandwidth waste. mKCP compresses multiple ACK packets; 100 ACK packets require only 16 + 2 + 100* 4 = 418 bytes, which is equivalent to one-sixth of the native size.
### Connection state control
### ACK Packet Retransmission
mKCP can effectively initiate and close connections. When the remote host initiates disconnection, the connection will be released within two seconds. When the remote host lost connection, the connection will be released within a maximum of 30 seconds.
The native KCP protocol sends acknowledgement (ACK) packets only once. If an ACK packet is lost, it inevitably leads to data retransmission, causing unnecessary bandwidth waste. mKCP retransmits ACK packets at a certain frequency until the sender confirms receipt. The size of a single ACK packet is 22 bytes, which is much smaller than the cost of retransmitting a data packet of over 1000 bytes.
The original KCP does not support this scenario.
### Connection State Control
mKCP can effectively open and close connections. When the remote host actively closes the connection, the connection is released within two seconds; when the remote host disconnects, the connection is released within a maximum of 30 seconds.
Native KCP does not support this scenario.
docs/en/config/transports/raw.md
+26 -26
View File
@@ -1,12 +1,12 @@
# RAW
Renamed from what was once the TCP transport layer (the original name was ambiguous), the outbound RAW transport layer sends TCP and UDP data generated by proxy protocol wrappers directly, and the core doesn't use other transport layers (e.g., [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113)) to carry its traffic.
Renamed from the former TCP transport layer (as the original name was ambiguous), the outbound RAW transport layer directly sends TCP or UDP data wrapped by the proxy protocol. The core does not use other transport layers (such as [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113)) to carry its traffic.
It can be combined with various protocols in multiple ways.
It can be combined with various protocols in multiple modes.
## RawObject
`RawObject` corresponds to the `rawSettings` item in the Transport Protocol.
`RawObject` corresponds to the `rawSettings` item in transport configuration.
```json
{
@@ -19,27 +19,27 @@ It can be combined with various protocols in multiple ways.
> `acceptProxyProtocol`: true | false
Only used for inbound, indicating whether to accept the PROXY protocol.
Only used for inbound; indicates whether to accept PROXY protocol.
The [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is used to transmit the real source IP and port of the request. **If you are not familiar with it, please ignore this item.**
[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is dedicated to passing the real source IP and port of the request. **If you don't know what it is, please ignore this item for now.**
Common reverse proxy software (such as HAProxy and Nginx) can be configured to send it, and VLESS fallbacks xver can also send it.
Common reverse proxy software (such as HAProxy, Nginx) can be configured to send it. VLESS fallbacks xver can also send it.
When filled in as `true`, after the underlying TCP connection is established, the requesting party must first send PROXY protocol v1 or v2, otherwise the connection will be closed.
When set to `true`, after the underlying TCP connection is established, the requester must send PROXY protocol v1 or v2 first; otherwise, the connection will be closed.
The default value is `false`
Default value is `false`.
> `header`: [NoneHeaderObject](#noneheaderobject) | [HttpHeaderobject](#httpheaderobject)
Packet header obfuscation settings, the default value is `NoneHeaderObject`
Packet header obfuscation settings. Default value is `NoneHeaderObject`.
::: tip
HTTP obfuscation cannot be proxied by other HTTP servers (such as Nginx), but it can be proxied by VLESS fallbacks path.
HTTP obfuscation cannot be traffic-split by other HTTP servers (like Nginx), but can be split by VLESS fallbacks path.
:::
### NoneHeaderObject
No header obfuscation
No obfuscation.
```json
{
@@ -49,11 +49,11 @@ No header obfuscation
> `type`: "none"
Disable header obfuscation.
Specifies no obfuscation.
### HttpHeaderObject
HTTP header obfuscation. The configuration must be the same between connecting inbound and outbound.
HTTP obfuscation configuration must be configured on the corresponding inbound and outbound connections simultaneously, and the content must be consistent.
```json
{
@@ -65,15 +65,15 @@ HTTP header obfuscation. The configuration must be the same between connecting i
> `type`: "http"
Enable HTTP header obfuscation.
Specifies HTTP obfuscation.
> `request`: [HTTPRequestObject](#httprequestobject)
HTTP request template.
HTTP Request.
> `response`: [HTTPResponseObject](#httpresponseobject)
HTTP response template.
HTTP Response.
#### HTTPRequestObject
@@ -97,21 +97,21 @@ HTTP response template.
> `version`: string
HTTP version, the default value is `"1.1"`
HTTP version. Default value is `"1.1"`.
> `method`: string
The HTTP method, the default value is `"GET"`
HTTP method. Default value is `"GET"`.
> `path`: \[ string \]
paths, an array of strings. The default value is `["/"]`. When there are multiple values, a value is chosen randomly for each request.
Path, an array of strings. Default value is `["/"]`. When there are multiple values, one is randomly selected for each request.
> `headers`: map{ string, \[ string \]}
HTTP header, a key-value pair, each key represents the name of an HTTP header, and the corresponding value is an array.
HTTP headers. A key-value pair, where each key represents the name of an HTTP header, and the corresponding value is an array.
Each request will include all the keys and randomly select a corresponding value. Please refer to the **default values** shown in the example above.
All keys will be attached to every request, and one corresponding value will be randomly selected. See the example above for default values.
#### HTTPResponseObject
@@ -131,18 +131,18 @@ Each request will include all the keys and randomly select a corresponding value
> `version`: string
HTTP version, default is `"1.1"`
HTTP version. Default value is `"1.1"`.
> `status`: string
HTTP status, default is `"200"`
HTTP status code. Default value is `"200"`.
> `reason`: string
HTTP status description, default value is `"OK"`
HTTP status reason phrase. Default value is `"OK"`.
> `headers`: map {string, \[ string \]}
HTTP header, a key-value pair, each key represents the name of an HTTP header, and the corresponding value is an array.
HTTP headers. A key-value pair, where each key represents the name of an HTTP header, and the corresponding value is an array.
Each request will include all the keys and randomly select a corresponding value. Please refer to the **default values** shown in the example above.
All keys will be attached to every request, and one corresponding value will be randomly selected. See the example above for default values.
docs/en/config/transports/websocket.md
+24 -17
View File
@@ -1,20 +1,20 @@
# WebSocket
Uses standard WebSocket for data transmission.
Uses standard WebSocket to transport data.
WebSocket connections can be proxied by other web servers (like NGINX) or by VLESS fallback paths.
WebSocket connections can be routed by other HTTP servers (such as Nginx) or by VLESS fallbacks path.
::: danger
**It is recommended to switch to [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) to avoid significant traffic characteristics such as WebSocket "ALPN is http/1.1".**
**It is recommended to switch to [XHTTP](https://github.com/XTLS/Xray-core/discussions/4113) to avoid significant traffic characteristics like WebSocket "ALPN is http/1.1".**
:::
::: tip
WebSocket inbounds will parse the `X-Forwarded-For` header received, overriding the source address with a higher priority than the source address got from PROXY protocol.
WebSocket will recognize the `X-Forwarded-For` header in HTTP requests to overwrite the source address of the traffic, which has higher priority than the PROXY protocol.
:::
## WebSocketObject
`WebSocketObject` corresponds to the `wsSettings` property of the transport configs.
`WebSocketObject` corresponds to the `wsSettings` item in the transport configuration.
```json
{
@@ -23,38 +23,45 @@ WebSocket inbounds will parse the `X-Forwarded-For` header received, overriding
"host": "xray.com",
"headers": {
"key": "value"
}
},
"heartbeatPeriod": 10
}
```
> `acceptProxyProtocol`: true | false
Only used by inbounds. Indicates whether to accept the PROXY protocol.
Only used for inbound, indicating whether to receive PROXY protocol.
The [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is used to transmit the real source IP and port of connections. **If you are not familiar with this, leave it alone.**
[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is specifically used to pass the real source IP and port of the request. **If you don't understand it, please ignore this item.**
Commonplace reverse proxy software solutions (like HAProxy and NGINX) can be configured to have source IPs and ports sent with PROXY protocol. Same goes to VLESS fallbacks `xver`.
Common reverse proxy software (such as HAProxy, Nginx) can be configured to send it, and VLESS fallbacks xver can also send it.
When `true`, after the underlying TCP connection is established, the downstream must first send the source IPs and ports in PROXY protocol v1 or v2, or the connection will be terminated.
When set to `true`, after the underlying TCP connection is established, the requester must send PROXY protocol v1 or v2 first; otherwise, the connection will be closed.
> `path`: string
The HTTP path used by the WebSocket connection. Defaults to `"/"`.
The HTTP protocol path used by WebSocket. The default value is `"/"`.
If `path` contains the `ed` query parameter, `early data` will be activated for latency reduction, and its value will be the length threshold of the first packet. If the length of the first packet exceeds this value, `early data` won't be activated. The recommended value is 2560, with a maximum of 8192. Compatibility problems can occur when the value is set too high. Try lowering the threshold when encountering such problems.
If the client path contains the `ed` parameter (e.g., `/mypath?ed=2560`), `Early Data` will be enabled to reduce latency. It uses the `Sec-WebSocket-Protocol` header to carry the first packet data during the upgrade, where the value represents the first packet length threshold. If the length of the first packet exceeds this value, `Early Data` will not be enabled. The recommended value is 2560, and the maximum value is 8192. Excessively large values may cause some compatibility issues. If you encounter compatibility issues, try lowering the threshold.
> `host`: string
The `Host` header sent in HTTP requests. Defaults to an empty string. Servers will not validate the `Host` header sent by clients when left blank.
The host sent in the WebSocket HTTP request. Default value is empty. If the server-side value is empty, the host value sent by the client is not verified.
If the `Host` header has been defined on the server in any way, the server will validate if the `Host` header matches.
When this value is specified on the server side, or `host` is specified in `headers`, it will verify whether it matches the client request host.
The current priority of the `Host` header sent by clients: `host` > `headers` > `address`
Client priority for sending host: `host` > `headers` > `address`.
> `headers`: map \{string: string\}
Customized HTTP headers defined in key-value pairs. Defaults to empty.
Client only. Custom HTTP headers, key-value pairs. Each key represents the name of an HTTP header, and the corresponding value is a string.
Default is empty.
> `heartbeatPeriod`: int
Specifies a fixed time interval to send a Ping message to keep the connection alive. If not specified or set to 0, no Ping message is sent, which is the current default behavior.
## Browser Dialer
Use the browser to handle TLS, see [Browser Dialer](../features/browser_dialer.md)
Use a browser to handle TLS. See [Browser Dialer](../features/browser_dialer.md) for details.
docs/en/development/index.md
+14 -14
View File
@@ -1,28 +1,28 @@
# Development Guide
## Compile Documentation
## Compilation Documentation
Xray supports multiple platforms, and you can perform cross-compilation on various platforms by yourself.
Xray supports a wide range of platforms, allowing you to perform cross-compilation on various systems yourself.
Please click [Compile Documentation](./intro/compile.md) to view specific compile-related content.
Please click [Compilation Documentation](./intro/compile.md) to view specific compilation-related content.
## Design Concept
## Design Philosophy
Xray kernel provides a platform for secondary development.
The Xray kernel provides a platform upon which secondary development can be conducted.
This section explains the design goals and architecture of Xray.
This chapter expounds on Xray's design goals and architecture.
Please click [Design Principles](./intro/design.md) to learn about the design goals and architecture of Xray.
Please click [Design Philosophy](./intro/design.md) to understand Xray's design goals and architecture.
## Development Standards
## Development Guidelines
This section outlines the guidelines to follow when obtaining code, developing, submitting PRs, as well as the relevant coding standards.
This chapter explains the guidelines to follow during the process of obtaining code, conducting development, and submitting PRs, as well as relevant coding conventions.
Please click [Development Specification](./intro/guide.md) to view the guidelines that should be followed during Xray development.
Please click [Development Guidelines](./intro/guide.md) to view the criteria to be followed in Xray development.
## Protocol Details
Xray uses many protocols, and you can obtain a detailed description of each protocol through various means.
Xray utilizes many types of protocols. You can obtain detailed descriptions of these protocols through various channels.
### [VLESS Protocol](./protocols/vless.md)
@@ -30,12 +30,12 @@ VLESS is a stateless lightweight transport protocol that can serve as a bridge b
### [VMess Protocol](./protocols/vmess.md)
VMess is an encrypted transport protocol that can act as a bridge between Xray clients and servers.
VMess is an encrypted transport protocol that can serve as a bridge between Xray clients and servers.
### [Mux.Cool Protocol](./protocols/muxcool.md)
Mux.Cool protocol is a multiplexing transport protocol used to transmit multiple independent data streams within an established data stream.
The Mux.Cool protocol is a multiplexing transport protocol used to transmit multiple independent data streams within a single established data stream.
### [mKCP Protocol](./protocols/mkcp.md)
mKCP is a stream transmission protocol modified from the [KCP protocol](https://github.com/skywind3000/kcp) that can transmit arbitrary data streams in order.
mKCP is a stream transport protocol, modified from the [KCP Protocol](https://github.com/skywind3000/kcp), capable of transmitting arbitrary data streams in order.
docs/en/development/intro/compile.md
+43 -27
View File
@@ -1,80 +1,96 @@
# Compile the document
# Compilation Documentation
## Preparatory Work
## Prerequisites
Xray uses [Golang](https://golang.org/) as its programming language, so you need to install the latest version of Golang first in order to compile.
Xray uses [Golang](https://golang.org/) as its programming language. You need to install the latest version of Golang to compile it.
::: tip TIP
Install Golang: [golang.org/doc/install](https://golang.org/doc/install)
:::
If you happen to use Windows, please **make sure** to use Powershell.
> If you are unfortunately using Windows, please **be sure** to use PowerShell.
## Pull Xray source code
## Pull Xray Source Code
```bash
git clone https://github.com/XTLS/Xray-core.git
git clone [https://github.com/XTLS/Xray-core.git](https://github.com/XTLS/Xray-core.git)
cd Xray-core && go mod download
```
If you have free time, you can try GitHub's official tool: `gh repo clone XTLS/Xray-core`
> If you have nothing better to do, you can try the GitHub official tool: `gh repo clone XTLS/Xray-core`
Note: In a network environment where Google cannot be accessed normally, dependencies cannot be pulled normally, and `GOPROXY` needs to be set first:
Note: In network environments where Google cannot be accessed normally, dependencies cannot be pulled correctly. You need to set `GOPROXY` first:
```bash
go env -w GOPROXY=https://goproxy.io,direct
go env -w GOPROXY=[https://goproxy.io](https://goproxy.io),direct
```
## Build Binary
:::warning
This command needs to be executed within Xray root directory.
The commands in this section need to be run inside the Xray root directory.
:::
### Windows(Powershell):
### Windows (Powershell)
```powershell
$env:CGO_ENABLED=0
go build -o xray.exe -trimpath -ldflags "-s -w -buildid=" ./main
go build -o xray.exe -trimpath -buildvcs=false -ldflags "-s -w -buildid=" ./main
```
### macOS, Linux:
### macOS, Linux
```bash
CGO_ENABLED=0 go build -o xray -trimpath -ldflags "-s -w -buildid=" ./main
CGO_ENABLED=0 go build -o xray -trimpath -buildvcs=false -ldflags "-s -w -buildid=" ./main
```
Running the above command will generate an xray executable file in the directory.
Running the above commands will generate the `xray` executable file in the directory.
::: tip
If you need to compile a program that can be debugged, i.e., you can use dlv to attach to the running program for debugging, please remove the '-w -s' options from the ldflags.
If you need to compile a debuggable program (i.e., you can attach `dlv` to the running program for debugging), please remove the `-w -s` options from `ldflags`.
- w option disables the generation of debug information. After using this option, gdb cannot be used for debugging.
- s option disables the symbol table.
PS: Actually, debugging with vscode or other IDEs seems to be more convenient.
- `-w`: Disable DWARF generation (debug info). After using this option, you cannot use gdb for debugging.
- `-s`: Disable the symbol table.
## Cross compilation:
PS: Actually, debugging with VSCode or other IDEs seems more convenient.
:::
Here, we take the example of compiling to a Linux server in a Windows (Powershell) environment:
## Cross Compilation
Here is an example of compiling for a Linux server in a Windows (Powershell) environment:
```powershell
$env:CGO_ENABLED=0
$env:GOOS="linux"
$env:GOARCH="amd64"
```
go build -o xray -trimpath -ldflags "-s -w -buildid=" ./main```
go build -o xray -trimpath -buildvcs=false -ldflags "-s -w -buildid=" ./main
```
After uploading to the server, remember to execute `chmod +x xray` in the server terminal.
::: tip
Execute `go tool dist list` to view all supported systems and architectures.
Run `go tool dist list` to view all supported systems and architectures.
:::
## Reproducible Build:
## Reproducible Build
Following the above steps, it is possible to compile and release an identical binary file as the one in Release.
Use the following command to build (`<short commit ID>` should be replaced with the first seven characters of the corresponding commit SHA-256):
```bash
CGO_ENABLED=0 go build -o xray -trimpath -buildvcs=false -gcflags="all=-l=4" -ldflags="-X [github.com/xtls/xray-core/core.build=](https://github.com/xtls/xray-core/core.build=)<short commit ID> -s -w -buildid=" -v ./main
```
For MIPS/MIPSLE architectures, you should use:
```bash
CGO_ENABLED=0 go build -o xray -trimpath -buildvcs=false -gcflags="-l=4" -ldflags="-X [github.com/xtls/xray-core/core.build=](https://github.com/xtls/xray-core/core.build=)<short commit ID> -s -w -buildid=" -v ./main
```
::: warning
Please confirm that you are using the same Golang version as the one used to compile the release.
Please ensure that the Golang version you are using is consistent with the one used to compile the Release.
:::
## Compiling for Windows 7
Replace the Golang tools with the version provided in [go-win7](https://github.com/XTLS/go-win7), and then proceed with the compilation steps above.
docs/en/development/intro/design.md
+17 -17
View File
@@ -1,43 +1,43 @@
# Design Objectives
# Design Goals
- Xray Kernel provides a platform that supports essential network proxy functions and can be developed upon to provide a better user experience.
- Cross-platform is the primary principle to reduce the cost of secondary development.
- The Xray core provides a platform that supports necessary network proxy functions, upon which secondary development can be conducted to provide a better user experience.
- Cross-platform support is the primary principle to reduce the cost of secondary development.
## Architecture
![Architecture](./framework.png)
The kernel is divided into three layers: the application layer, the proxy layer, and the transport layer.
The core is divided into three layers: Application Layer, Proxy Layer, and Transport Layer.
Each layer contains several modules, which are independent of each other. Modules of the same type can be seamlessly replaced.
Each layer contains several modules. Modules are independent of each other, and modules of the same type can be seamlessly replaced.
### Application Layer
The application layer contains some commonly used functions in proxy layers, which are abstracted for reuse in different proxy modules.
The Application Layer contains common functions used in the Proxy Layer. These functions are abstracted to be reused across different proxy modules.
The modules at the application layer should be implemented purely in software and should not be dependent on hardware or platform-related technologies.
Modules in the Application Layer should be pure software implementations, independent of hardware or platform-specific technologies.
List of Important Modules:
Important module list:
- Dispatcher: Used to transfer data received by the inbound agent to the outbound agent;
- Router: Routing module, see [Routing Configuration](../../config/routing.md) for details;
- DNS: Built-in DNS server module;
- Proxy Manager: Proxy manager;
- **Dispatcher**: Used to transmit data received by the inbound proxy to the outbound proxy.
- **Router**: Routing module, see [Routing Configuration](../../config/routing.md) for details.
- **DNS**: Built-in DNS server module.
- **Proxy Manager**: Manages proxies.
### Proxy Layer
The proxy layer is divided into two parts: Inbound Proxy and Outbound Proxy.
The Proxy Layer is divided into two parts: Inbound Proxy and Outbound Proxy.
The two parts are independent of each other, where the inbound proxy does not rely on a specific outbound proxy, and vice versa.
The two parts are independent of each other. An inbound proxy does not depend on a specific outbound proxy, and vice versa.
#### Inbound Proxy
- Implement the [proxy.Inbound](https://github.com/xtls/Xray-core/blob/main/proxy/proxy.go) interface;
- Implements the [proxy.Inbound](https://github.com/xtls/Xray-core/blob/main/proxy/proxy.go) interface.
#### Outbound Proxy
- Implement the [proxy.Outbound](https://github.com/xtls/Xray-core/blob/main/proxy/proxy.go) interface;
- Implements the [proxy.Outbound](https://github.com/xtls/Xray-core/blob/main/proxy/proxy.go) interface.
### Transport Layer
The transport layer provides a set of tools and modules related to network data transmission.
The Transport Layer provides tool modules related to network data transmission.
docs/en/development/intro/guide.md
+92 -72
View File
@@ -4,94 +4,94 @@
### Version Control
Project X's code is hosted on GitHub:
Project X code is hosted on GitHub:
- Xray Core [xray-core](https://github.com/XTLS/Xray-core)
- Installation script [Xray-install](https://github.com/XTLS/Xray-install)
- Configuration template [Xray-examples](https://github.com/XTLS/Xray-examples)
- Xray documentation [Xray-docs-next](https://github.com/XTLS/Xray-docs-next)
- Xray Core: [Xray-core](https://github.com/XTLS/Xray-core)
- Install Script: [Xray-install](https://github.com/XTLS/Xray-install)
- Configuration Templates: [Xray-examples](https://github.com/XTLS/Xray-examples)
- Xray Documentation: [Xray-docs-next](https://github.com/XTLS/Xray-docs-next)
You can use [Git](https://git-scm.com/) to get the code.
You can use [Git](https://git-scm.com/) to fetch the code.
### Branch
### Branches
- The main branch is the backbone of this project.
- The main branch is also the release branch of this project.
- It is necessary to ensure that main can be compiled and used normally at any time.
- If you need to develop new features, please create a new branch for development. After development and sufficient testing, merge it back to the main branch.
- Please delete branches that have been merged into the main branch and are no longer necessary.
- The trunk branch of this project is `main`.
- The release branch of this project is also `main`.
- Ensure that `main` is compilable and usable at any given time.
- If you need to develop new features, please create a new branch for development. After development is complete and fully tested, merge it back into the trunk branch.
- Branches that have already been merged into the trunk and are no longer necessary should be deleted.
### Release
<Badge text="WIP" type="warning"/> (Note: this is not translatable as it is a technical tag)
<Badge text="WIP" type="warning"/>
- Create two release channels: one for the beta version and another for the stable version.
- The beta version, also known as the daily build, is mainly used for specific testing, experimentation, and instant feedback and improvement.
- The stable version, updated regularly (e.g. monthly), merges stable modifications and releases them.
- Establish two release channels: Bleeding Edge and Stable.
- Bleeding Edge: Can be daily builds, mainly used for specific testing scenarios, trying out new features, and obtaining immediate feedback for further improvement.
- Stable: Scheduled updates (e.g., monthly), merging stable changes and releasing.
### Citing other projects
### Referencing Other Projects
- Golang
- It is recommended to use the Golang standard library and libraries under [golang.org/x/](https://pkg.go.dev/search?q=golang.org%2Fx) for product code;
- If you need to reference other projects, please create an issue for discussion beforehand;
- Other
- Tools that do not violate the agreement of both parties and are helpful to the project can be used.
- For product code, it is recommended to use the Golang standard library and libraries under [golang.org/x/](https://pkg.go.dev/search?limit=25&m=package&q=golang.org%2Fx).
- If you need to reference other projects, please create an issue for discussion beforehand.
- Others
- Tools that do not violate the agreements of either party and are helpful to the project can be used.
## Development Process
### Before Writing Code
If you encounter any issues or have any ideas for the project, please create an [issue](https://github.com/XTLS/Xray-core/issues) for discussion to reduce redundant work and save time spent on coding.
### Modify the code
- Golang
- Please refer to [Effective Go](https://golang.org/doc/effective_go.html);
- Run `go generate core/format.go` before each push;
- If you need to modify protobuf, such as adding new configuration items, please run: `go generate core/proto.go`;
- It is recommended to pass the test before submitting a pull request: `go test ./...`;
- It is recommended to have more than 70% code coverage for newly added code before submitting pull requests.
- Other
- Please pay attention to the readability of the code.
### Pull Request
- Before submitting a PR, please run `git pull https://github.com/xray/xray-core.git` to ensure that the merge can proceed smoothly;
- One PR only does one thing. If there are fixes for multiple bugs, please submit a PR for each bug;
- Due to Golang's special requirements (Package path), the PR process for Go projects is different from other projects. The recommended process is as follows:
1. Fork this project first and create your own `github.com/<your_name>/Xray-core.git` repository;
2. Clone your own Xray repository to your local machine: `git clone https://github.com/<your_name>/Xray-core.git`;
3. Create a new branch based on the `main` branch, for example `git branch issue24 main`;
4. Make changes on the new branch and commit the changes;
5. Before pushing the modified branch to your own repository, switch to the `main` branch, and run `git pull https://github.com/xray/xray-core.git` to pull the latest remote code;
6. If new remote code is obtained in the previous step, switch to the branch you created earlier and run `git rebase main` to perform branch merging. If there is a file conflict, you need to resolve the conflict;
7. After the previous step is completed, you can push the branch you created to your own repository: `git push -u origin your-branch`
8. Finally, send a PR from your new pushed branch in your own repository to the `main` branch of `xtls/Xray-core`;
9. Please fully describe the purpose of this PR, including the problem solved, the new feature added, or the modifications made in the title and body of the PR;
10. Please be patient and wait for the developer's response.
If you find any issues or have any ideas for the project, please create an [issue](https://github.com/XTLS/Xray-core/issues) for discussion to reduce repetitive work and time spent on code.
### Modifying Code
#### Functional issue
- Golang
- Please refer to [Effective Go](https://golang.org/doc/effective_go.html).
- Before every push, please run: `go generate core/format.go`.
- If you need to modify protobuf, such as adding new configuration items, please run: `go generate core/proto.go`.
- Before submitting a pull request, it is recommended to pass tests: `go test ./...`.
- Before submitting a pull request, it is recommended that new code has over 70% code coverage.
- Others
- Please pay attention to code readability.
Please submit at least one test case to verify changes to existing functionality.
### Pull Request
- Before submitting a PR, please run `git pull https://github.com/XTLS/Xray-core.git` to ensure the merge can proceed smoothly.
- One PR should do one thing. If there are fixes for multiple bugs, please submit a separate PR for each bug.
- Due to the special requirements of Golang (Package path), the PR process for Go projects differs from other projects. The recommended process is as follows:
1. Fork this project first and create your own `github.com/<your_name>/Xray-core.git` repository.
2. Clone your own Xray repository locally: `git clone https://github.com/<your_name>/Xray-core.git`.
3. Create a new branch based on the `main` branch, e.g., `git branch issue24 main`.
4. Make changes and commit them on the newly created branch.
5. Before pushing the completed branch to your own repository, switch to the `main` branch and run `git pull https://github.com/XTLS/Xray-core.git` to pull the latest remote code.
6. If new remote code was pulled in the previous step, switch back to the branch you created and run `git rebase main` to perform the branch merge operation. If you encounter file conflicts, you need to resolve them.
7. After the previous step is completed, you can push your created branch to your own repository: `git push -u origin your-branch`.
8. Finally, send a PR from the newly pushed branch in your repository to the `main` branch of `XTLS/Xray-core`.
9. In the title and body of the PR, please fully describe the problem solved / new feature added / intention of the code changes, etc.
10. Wait patiently for the developers' response.
### Changes to Code
#### Functional Issues
Please submit at least one Test Case to verify changes to existing functions.
#### Performance Related
Please provide the necessary test data to demonstrate performance issues in existing code or performance improvements in new code.
Please submit necessary test data to prove performance defects in existing code or performance improvements in new code.
#### New Feature
#### New Features
- If the new feature does not affect the existing functionality, please provide a toggle (such as a flag) that can be turned on/off, and keep the new feature disabled by default.
- For major new features (such as adding a new protocol), please submit an issue for discussion before development.
- If the new feature does not affect existing features, please provide a switch (e.g., flag) that can turn it on/off, and keep the new feature off by default.
- Before developing large new features (such as adding a new protocol), please submit an issue first and proceed with development after discussion.
#### Other
#### Others
It depends on the specific situation.
To be determined based on the specific situation.
## Xray Coding Guidelines
## Xray Coding Standards
The following content is applicable to Golang code in Xray.
The following applies to Golang code in Xray.
### Code Structure
@@ -100,7 +100,7 @@ Xray-core
├── app // Application module
│ ├── router // Router
├── common // Common code
├── proxy // Communication protocol
├── proxy // Communication protocols
│ ├── blackhole
│ ├── dokodemo-door
│ ├── freedom
@@ -111,21 +111,41 @@ Xray-core
### Coding Standards
Basic practices are consistent with the recommendations of the official Golang, with a few exceptions. Written here to help everyone familiarize themselves with Golang.
Basically consistent with the practices recommended by official Golang documentation, with some exceptions. Written here to help everyone get familiar with Golang.
#### Naming
- Use a single English word for file and directory names, such as hello.go;
- If not possible, use a hyphen for directories / underscore for files to connect two (or more) words, such as hello-world/hello_again.go;
- Use \_test.go to name test code files;
- Use PascalCase for types, such as ConnectionHandler;
- Do not force lowercase for abbreviations, i.e. HTML does not need to be written as Html;
- Use PascalCase for public member variables;
- Use camelCase for private member variables, such as `privateAttribute`;
- For easy refactoring, it is recommended to use PascalCase for all methods;
- Place completely private types in `internal`.
- Try to use single English words for file and directory names, such as `hello.go`.
- If unavoidable, use hyphens for directories / underscores for filenames to connect two (or more) words, e.g., `hello-world/hello_again.go`.
- Test code should end with `_test.go`.
- Use PascalCase for types, such as `ConnectionHandler`.
- Abbreviations are not forced to be lowercase, i.e., `HTML` does not need to be written as `Html`.
- Public member variables also use PascalCase.
- Private member variables use [lowerCamelCase](https://en.wikipedia.org/wiki/Camel_case), such as `privateAttribute`.
- To facilitate refactoring, it is recommended to use PascalCase for all methods.
- Put completely private types into `internal`.
#### Content Organization
- A file contains a main type and its related private functions;
- Testing-related files, such as Mock tools, should be placed in the testing subdirectory.
- A file contains one main type and its related private functions, etc.
- Test-related files, such as Mock utility classes, should be placed in the `testing` subdirectory.
#### Int32Range
**For end user**
A value representing an optional range, which can be written in the following ways:
- A single number or range enclosed in quotes:
- `""` (Treated as 0. Note: Not setting a field at all and setting it to empty might be two different concepts for some fields.)
- `"114"`
- `"114-514"`
- An independent int (in this case, it can only be a single number):
- `114`
**For dev**
If you need to include a range in the configuration file, please use the `Int32Range` type.
Use `.From` and `.To` to get values. When From > To (e.g., 1919-810), the values will be automatically swapped to ensure From is less than To. If you want to get the raw values, you can use `.Left` and `.Right`.
docs/en/development/protocols/mkcp.md
+54 -54
View File
@@ -1,6 +1,6 @@
# mKCP Protocol
mKCP is a stream transfer protocol, modified from the [KCP protocol](https://github.com/skywind3000/kcp), which can transmit any data stream in order.
mKCP is a stream transport protocol, modified from the [KCP Protocol](https://github.com/skywind3000/kcp), capable of transmitting arbitrary data streams in order.
## Version
@@ -10,83 +10,83 @@ mKCP has no version number and does not guarantee compatibility between versions
### Underlying Protocol
mKCP is a protocol based on UDP, and all communication uses UDP transmission.
mKCP is a UDP-based protocol; all communication is transmitted using UDP.
### Functions
- fnv: [FNV-1a](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) hash function
- Takes a string of arbitrary length as input parameter;
- Outputs a 32-bit unsigned integer.
- Input parameter is a string of arbitrary length;
- Outputs a 32-bit unsigned integer;
## Communication Process
1. mKCP splits data streams into several data packets for transmission. Each data stream has a unique identifier to distinguish it from other data streams. Each data packet in the data stream carries the same identifier.
2. mKCP does not have a handshake process. When receiving a data packet, it determines whether it is a new call or an ongoing call based on the identifier of the data stream it carries.
3. Each data packet contains several segments (Segment), which are divided into three types: data (Data), acknowledgment (ACK), and heartbeat (Ping). Each segment needs to be processed separately.
1. mKCP splits the data stream into several packets for transmission. A data stream has a unique identifier to distinguish different data streams. Every packet in a data stream carries the same identifier.
2. mKCP has no handshake process. When a packet is received, the identifier carried by it determines whether it is a new call or an ongoing one.
3. Each packet contains several segments. Segments are divided into three categories: Data, ACK (Acknowledgment), and Ping (Heartbeat). Each segment needs to be processed separately.
## Data Format
### Data Packet
### Packet
| 4 Bytes | 2 Bytes | L Bytes |
| ------- | ---------- | -------- |
| Auth A | Data Len L | Fragment |
| 4 Bytes | 2 Bytes | L Bytes |
| :--- | :--- | :--- |
| Authentication A | Data Length L | Segment Part |
as which:
Where:
- Authentication information A = fnv(fragment), big endian;
- The fragment may contain multiple sections.
- Authentication A = fnv(Segment Part), big endian;
- The Segment Part may contain multiple segments;
### Data snippet
### Data Segment
| 2 bytes | 1 byte | 1 byte | 4 bytes | 4 bytes | 4 bytes | 2 bytes | Len bytes |
| --------- | -------- | -------- | --------- | -------- | -------------- | -------- | --------- |
| Conv flag | Cmd flag | Opt flag | Timestamp | Sequence | Unacknowledged | Len flag | Data |
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes | 2 Bytes | Len Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Identifier Conv | Command Cmd | Option Opt | Timestamp Ts | Sequence Sn | Unacknowledged Una | Length Len | Data |
as which:
Where:
- Identifier Conv: Identifier for mKCP data stream
- Command Cmd: Constant 0x01
- Option Opt: Optional values include:
- 0x00: Empty option
- 0x01: Opposite party has sent all data
- Timestamp Ts: Time when the current segment was sent from the remote end, big endian
- Sequence Number Sn: The position of the data segment in the data stream, the sequence number of the starting segment is 0, and each new segment is sequentially added by 1
- Unacknowledged Sequence Number Una: The minimum Sn that the remote host is sending and has not yet received confirmation.
- Identifier Conv: The identifier of the mKCP data stream.
- Command Cmd: Constant `0x01`.
- Option Opt: Optional values are:
- `0x00`: Empty option.
- `0x01`: The peer has sent all data.
- Timestamp Ts: The time when the current segment was sent from the remote end, big endian.
- Sequence Sn: The position of this data segment in the data stream. The sequence number of the starting segment is 0, and each subsequent new segment increases by 1 in order.
- Unacknowledged Una: The smallest Sn that the remote host is sending and has not yet received an acknowledgment for.
### Confirmation snippet
### ACK Segment
| 2 bytes | 1 byte | 1 byte | 4 bytes | 4 bytes | 4 bytes | 2 bytes | Len \* 4 bytes |
| ------- | ------ | ------ | ------- | --------------- | --------- | ------- | ------------------- |
| Conv ID | Cmd | Opt | Wnd | Next Seq Number | Timestamp | Length | Received Seq Number |
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes | 2 Bytes | Len * 4 Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Identifier Conv | Command Cmd | Option Opt | Window Wnd | Next Receive Sn | Timestamp Ts | Length Len | Received Sns |
as which:
Where:
- Identifier Conv: Identifier of the mKCP data stream
- Command Cmd: Constant 0x00
- Option Opt: Same as above
- Window Wnd: The maximum sequence number that the remote host can receive
- Next receive sequence number Sn: The smallest sequence number of the data segment that the remote host has not received
- Timestamp Ts: The timestamp of the latest received data segment by the remote host, which can be used to calculate the delay
- Received sequence numbers: Each 4 bytes, indicating that the data of this sequence number has been confirmed received.
- Identifier Conv: The identifier of the mKCP data stream.
- Command Cmd: Constant `0x00`.
- Option Opt: Same as above.
- Window Wnd: The maximum sequence number the remote host can receive.
- Next Receive Sn: The smallest sequence number among the data segments not yet received by the remote host.
- Timestamp Ts: The timestamp of the latest data segment received by the remote host, used for calculating latency.
- Received Sns: Each is 4 bytes, indicating that data with this sequence number has been confirmed as received.
as which:
Note:
- The remote host expects to receive data within the serial number [Sn, Wnd) range.
- The remote host expects to receive data within the sequence number range [Sn, Wnd).
### Heartbeat Fragments
### Ping (Heartbeat) Segment
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes |
| ------- | ------ | ------ | --------------------- | ------------------- | ------- |
| Conv ID | Cmd | Opt | Unacknowledged Seq No | Next Receive Seq No | Rto |
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- |
| Identifier Conv | Command Cmd | Option Opt | Unacknowledged Una | Next Receive Sn | Latency Rto |
as which:
Where:
- Identifier Conv: Identifier for the mKCP data stream
- Command Cmd: Optional values include:
- 0x02: Remote host forcibly terminates the session
- 0x03: Normal heartbeat
- Option Opt: Same as above
- Unacknowledged sequence number Una: Same as the Una of the data fragment
- Next receive sequence number Sn: Same as the Sn of the acknowledgement fragment
- Delay Rto: Delay calculated by the remote host itself
- Identifier Conv: The identifier of the mKCP data stream.
- Command Cmd: Optional values are:
- `0x02`: Remote host forcibly terminates the session.
- `0x03`: Normal heartbeat.
- Option Opt: Same as above.
- Unacknowledged Una: Same as Una in the Data Segment.
- Next Receive Sn: Same as Sn in the ACK Segment.
- Latency Rto: The latency calculated by the remote host itself.
docs/en/development/protocols/muxcool.md
+79 -67
View File
@@ -1,6 +1,6 @@
# Mux.Cool Protocol
Mux.Cool protocol is a multiplexing transport protocol that is used to transmit multiple independent data streams within an established data stream.
The Mux.Cool protocol is a multiplexing transport protocol used to transmit multiple independent data streams within a single established data stream.
## Version
@@ -10,108 +10,120 @@ The current version is 1 Beta.
### Underlying Protocol
Mux.Cool must run on top of a reliable established data stream.
Mux.Cool must run on top of an established reliable data stream.
## Communication Process
Within a Mux.Cool connection, multiple sub-connections can be transmitted, each with a unique ID and status. The transmission process consists of frames, with each frame used to transmit data for a specific sub-connection.
A Mux.Cool connection can transmit multiple sub-connections. Each sub-connection has a unique ID and status. The transmission process consists of Frames, and each frame is used to transmit data for a specific sub-connection.
### Client behavior
### Client Behavior
When there is a need for a connection and there are no existing available connections, the client initiates a new connection to the server, referred to as the "main connection".
When there is a need for a connection and no existing connection is available, the client initiates a new connection to the server, hereafter referred to as the "main connection".
1. One main connection can be used to send several sub-connections. The client can decide independently how many sub-connections the main connection can handle.
2. For a new sub-connection, the client must send the `New` status to notify the server to establish the sub-connection, and then use the `Keep` status to transmit data.
3. When the sub-connection ends, the client sends the `End` status to notify the server to close the sub-connection.
4. The client can decide when to close the main connection, but must ensure that the server also maintains the connection.
5. The client can use the KeepAlive status to prevent the server from closing the main connection.
1. A main connection can be used to send multiple sub-connections. The client can decide the number of sub-connections the main connection can carry.
2. For a new sub-connection, the client must send the status `New` to notify the server to establish the sub-connection, and then use the status `Keep` to transmit data.
3. When a sub-connection ends, the client sends the `End` status to notify the server to close the sub-connection.
4. The client can decide when to close the main connection but must ensure the server also maintains the connection.
5. The client can use the `KeepAlive` status to prevent the server from closing the main connection.
### Server-side behavior
### Server Behavior
When a new sub-connection is received on the server side, the server should handle it as a normal connection.
When the server receives a new sub-connection, it should handle it as a normal connection.
1. When the status "End" is received, the server can close the upstream connection to the target address.
2. The same ID used in the request must be used to transfer sub-connection data in the server response.
3. The server cannot use the "New" status.
4. The server can use the KeepAlive status to avoid the client closing the main connection.
1. When receiving the `End` status, the server can close the uplink connection to the target address.
2. In the server's response, the same ID as the request must be used to transmit the sub-connection's data.
3. The server cannot use the `New` status.
4. The server can use the `KeepAlive` status to prevent the client from closing the main connection.
## Data Format
## Transmission Format
Mux.Cool uses symmetric transmission format, where the client and server send and receive data in the same format.
Mux.Cool uses a symmetric transmission format, meaning the client and server send and receive data in the same format.
### Frame Format
| 2 Bytes | L Bytes | X Bytes |
| ----------------- | -------- | --------------- |
| Metadata Length L | Metadata | Additional Data |
| 2 bytes | L bytes | X bytes |
| :--- | :--- | :--- |
| Metadata Length L | Metadata | Extra Data |
### Metadata
There are several types of metadata. All types of metadata contain two items, ID and Opt, with the following meanings:
There are several types of metadata. All types of metadata include ID and Opt items, with meanings as follows:
- ID: Unique identifier of the sub-connection
- For general MUX sub-connections, the ID is accumulated starting from 1
- For XUDP, the ID is always 0
- Opt:
- D(0x01): Additional data is available
* ID: Unique identifier for the sub-connection
* For general Mux sub-connections, the ID accumulates starting from 1.
* For [Single XUDP](https://github.com/XTLS/Xray-core/blob/main/common/xudp/xudp.go) implemented by Xray, the ID is always 0.
* Opt:
* D(0x01): Has extra data
When option Opt(D) is enabled, the additional data format is as follows:
When option Opt(D) is enabled, the extra data format is as follows:
| 2 Bytes | X-2 Bytes |
| ---------- | --------- |
| Length X-2 | Data |
| 2 bytes | X-2 bytes |
| :--- | :--- |
| Length X-2 | Data |
### New Sublink (New)
### New Sub-connection (New)
| 2 Bytes | 1 Byte | 1 Byte | 1 Byte | 2 Bytes | 1 Byte | A Bytes |
| ------- | ------ | ------ | --------- | ------- | ------ | ------- |
| ID | 0x01 | Option | Network N | Port | Type T | Address |
| 2 bytes | 1 byte | 1 byte | 1 byte | 2 bytes | 1 byte | A bytes | 8 bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| ID | 0x01 | Option Opt | Network Type N | Port | Address Type T | Address A | Global ID (XUDP) |
where:
Where:
- Network type N:
- 0x01: TCP, indicating that the traffic of the current sub-connection should be sent to the destination in the way of TCP.
- 0x02: UDP, indicating that the traffic of the current sub-connection should be sent to the destination in the way of UDP.
- 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;
* Network Type N:
* 0x01: TCP, indicating that the traffic of the current sub-connection should be sent to the target via TCP.
* 0x02: UDP, indicating that the traffic of the current sub-connection should be sent to the target via UDP.
* 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 bytes of domain name;
* When T = 0x03, A is a 16-byte IPv6 address;
* Global ID (XUDP):
* The client calculates a global unique ID for the UDP source 2-tuple. The server uses this to ensure that when XUDP reconnects after disconnection, it still uses the same port to communicate with the target.
If Opt(D) is enabled when creating a sub-connection, the data carried by this frame needs to be sent to the target host.
When creating a new sub-connection, if Opt(D) is enabled, the data carried in this frame needs to be sent to the target host.
### Keep sub-connections
### Keep Sub-connection (Keep)
| 2 Bytes | 1 Byte | 1 Byte |
| ------- | ------ | ------ |
| ID | 0x02 | Option |
TCP
If Opt(D) is enabled while maintaining sub-connections, the data carried by this frame needs to be sent to the target host. XUDP adds the UDP address after Opt(D), and the format is the same as creating a new sub-connection.
| 2 bytes | 1 byte | 1 byte |
| :--- | :--- | :--- |
| ID | 0x02 | Option Opt |
### End
UDP
| 2 Bytes | 1 Byte | 1 Byte |
| ------- | ------ | ------ |
| ID | 0x03 | Option |
| 2 bytes | 1 byte | 1 byte | 1 byte | 2 bytes | 1 byte | A bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| ID | 0x02 | Option Opt | Network Type N | Port | Address Type T | Address A |
If Opt(D) is enabled while maintaining sub-connections, the data carried by this frame needs to be sent to the target host.
When keeping a sub-connection, if Opt(D) is enabled, the data carried in this frame needs to be sent to the target host.
XUDP adds the UDP address after Opt(D), formatted the same as in "New Sub-connection", but without the Global ID.
### KeepAlive
### End Sub-connection (End)
| 2 Bytes | 1 Byte | 1 Byte |
| ------- | ------ | ---------- |
| ID | 0x04 | Option Opt |
| 2 bytes | 1 byte | 1 byte |
| :--- | :--- | :--- |
| ID | 0x03 | Option Opt |
While staying connected:
When closing a sub-connection, if Opt(D) is enabled, the data carried in this frame needs to be sent to the target host.
- If Opt(D) is enabled, the data carried by this frame must be discarded.
- ID can be a random value.
### Keep Connection (KeepAlive)
| 2 bytes | 1 byte | 1 byte |
| :--- | :--- | :--- |
| ID | 0x04 | Option Opt |
When keeping the connection:
* If Opt(D) is enabled, the data carried in this frame must be discarded.
* The ID can be a random value.
## Application
The Mux.Cool protocol is agnostic to the underlying protocol and can theoretically use any reliable streaming connection to transmit Mux.Cool protocol data.
The Mux.Cool protocol is independent of the underlying protocol. Theoretically, any reliable stream connection can be used to transmit Mux.Cool protocol data.
In target-oriented protocols such as Shadowsocks and VMess, a specified address must be included when establishing a connection. To maintain compatibility, the Mux.Cool protocol specifies the address as "v1.mux.cool". When the target address of the main connection matches this address, the Mux.Cool forwarding method is used. Otherwise, forwarding is done in the traditional way. (Note: This is an internal tag in the program, and VMess and VLESS do not send the "v1.mux.cool" address in data packets.)
In target-oriented protocols like Shadowsocks and VMess, a specified address must be included when the connection is established.
To maintain compatibility, the Mux.Cool protocol specifies the address as "v1.mux.cool". That is, when the target address of the main connection matches this, Mux.Cool forwarding is performed; otherwise, forwarding is performed in the traditional way. (Note: This is an internal marker within the program; VMess and VLESS do not send the "v1.mux.cool" address in the data packet.)
docs/en/development/protocols/vless.md
+46 -54
View File
@@ -1,99 +1,91 @@
# VLESS Protocol
VLESS is a stateless lightweight transmission protocol that can be used as a bridge between Xray clients and servers.
VLESS is a stateless lightweight transport protocol that serves as a bridge between Xray clients and servers.
## Request & Response
| 1 byte | 16 bytes | 1 byte | M bytes | 1 byte | 2 bytes | 1 byte | S bytes | X bytes |
| ---------------- | --------------- | ------------------------------- | ------------------------------- | ----------- | ------- | ------------ | ------- | ------------ |
| Protocol Version | Equivalent UUID | Additional Information Length M | Additional Information ProtoBuf | Instruction | Port | Address Type | Address | Request Data |
| 1 Byte | 16 Bytes | 1 Byte | M Bytes | 1 Byte | 2 Bytes | 1 Byte | S Bytes | X Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Protocol Version | Equivalent UUID | Addons Length M | Addons ProtoBuf | Command | Port | Address Type | Address | Request Data |
| 1 Byte | 1 Byte | N Bytes | Y Bytes |
| --------------------------------------------- | ---------------------------------- | ---------------------------------- | ------------- |
| Protocol Version, consistent with the request | Length of additional information N | Additional information in ProtoBuf | Response data |
| 1 Byte | 1 Byte | N Bytes | Y Bytes |
| :--- | :--- | :--- | :--- |
| Protocol Version, same as request | Addons Length N | Addons ProtoBuf | Response Data |
VLESS had the aforementioned structure as early as the second alpha test version (ALPHA 2), with BETA being the fifth test version.
VLESS has had the above structure since the second alpha version, ALPHA 2 (BETA is the fifth test version):
"`Response authentication`" has been replaced with "`Protocol version`" and moved to the front, allowing VLESS to upgrade and eliminate the overhead of generating pseudo-random numbers. The obfuscation-related structure has been replaced with "`Additional information`" (ProtoBuf) and moved forward, giving the protocol itself scalability, with minimal overhead ([gogo/protobuf](https://github.com/gogo/protobuf)). If there is no additional information, there is no relevant overhead.
> "Response Authentication" was replaced by "Protocol Version" and moved to the very front, allowing VLESS to be upgraded while eliminating the overhead of generating pseudo-random numbers. Obfuscation-related structures were replaced by Addons (ProtoBuf) and moved forward, giving the protocol itself extensibility with minimal overhead ([gogo/protobuf](https://github.com/gogo/protobuf)); there is no related overhead if there are no Addons.
I always thought that "response authentication" was not necessary, and ALPHA replaced crypto/rand with math/rand in order to improve the performance of random number generation, which is no longer needed.
I always felt that "Response Authentication" wasn't necessary. In ALPHA, to improve the performance of random number generation, `math/rand` replaced `crypto/rand`, but now neither is needed.
The "Protocol Version" not only serves as "Response Authentication", but also gives VLESS the ability to upgrade the protocol structure seamlessly, bringing infinite possibilities. The "Protocol Version" is 0 in the test version and 1 in the official version. If there are any incompatible protocol structural changes in the future, the version should be upgraded.
"Protocol Version" not only serves the function of "Response Authentication" but also gives VLESS the ability to upgrade protocol structures painlessly, bringing infinite possibilities.
The "Protocol Version" is 0 in test versions and 1 in official versions. If there are incompatible protocol structure changes in the future, the version should be upgraded.
The design of VLESS server is switch version, which supports all VLESS versions at the same time. If you need to upgrade the protocol version (which may not happen), it is recommended that the server support it one month in advance, and then change the client after one month. VMess requests also have protocol versions, but their authentication information is outside, and the instruction part is highly coupled and has fixed encryption, which makes the protocol version meaningless inside. The server does not judge it, and the response does not have a protocol version. Trojan's protocol structure does not have a protocol version.
The design of the VLESS server is "switch version," meaning it supports all VLESS versions simultaneously. If a protocol version upgrade is needed (we might not reach that step), the recommended practice is for the server to support it a month in advance, and update clients a month later. VMess requests also have a protocol version, but its authentication information is outside, while the command part is highly coupled and has fixed encryption, making the inner protocol version meaningless. The server doesn't check it, and the response has no protocol version. The Trojan protocol structure has no protocol version.
The following is a UUID. I used to think that 16 bytes were a bit long and considered shortening it. However, I later saw that Trojan used 56 printable characters (56 bytes), which completely dispelled this idea. The server needs to verify the UUID every time, so performance is also very important: VLESS's Validator has undergone multiple refactoring/upgrades. Compared with VMess, it is very concise and consumes very few resources. It can support a large number of users at the same time, and its performance is also very strong. The verification speed is extremely fast (sync.Map). API dynamically adds and deletes users, making it more efficient and smooth.
https://github.com/XTLS/Xray-core/issues/158
Next is the UUID. I initially thought 16 bytes was a bit long and considered shortening it, but after seeing Trojan use 56 printable characters (56 bytes), I completely dismissed that thought. The server verifies the UUID every time, so performance is crucial: The VLESS Validator has undergone multiple refactors/upgrades. Compared to VMess, it is extremely concise and resource-efficient, capable of supporting a very large number of users simultaneously, with robust performance and extremely fast verification speed (sync.Map). Adding or deleting users dynamically via API is also more efficient and smoother.
<https://github.com/XTLS/Xray-core/issues/158>
Introducing ProtoBuf is an innovation, which will be explained in detail later. The structure from "instruction" to "address" is currently identical to VMess and also supports Mux.
Introducing ProtoBuf is a pioneering move, which will be explained in detail later. The structure from "Command" to "Address" is currently identical to VMess and also supports Mux.
Overall, ALPHA 2 to BETA mainly includes: structural evolution, cleaning and integration, performance improvement, and more completeness. All of these are incremental improvements, please refer to [VLESS Changes](https://github.com/rprx/v2ray-vless/releases) for details.
Overall, from ALPHA 2 to BETA, the changes were mainly: structural evolution, cleanup and integration, performance improvement, and greater perfection. These happened bit by bit; see [VLESS Changes](https://github.com/rprx/v2ray-vless/releases) for details.
## ProtoBuf
It seems that only VLESS supports embedding ProtoBuf, which is a data exchange format that encodes information tightly into binary TLV (Tag Length Value) structures.
It seems only VLESS allows optional embedded ProtoBuf. It is a data exchange format where information is tightly encoded into binary in a TLV structure (Tag Length Value).
The reason is that I saw an article that said that SS has some drawbacks, such as the lack of a design error reporting mechanism, and the client cannot take further action based on different errors. (But I don't agree that all errors should be reported, otherwise it can't prevent active probing. In the next beta version, the server can return a custom string of information.) So I think a scalable structure is important, and in the future, it can also carry dynamic port instructions. Not only the response, but the request also needs a similar structure. I originally planned to design TLV by myself, but then I found that ProtoBuf is the structure, ready-made, and it is completely suitable for this purpose, and the support for various languages is also good.
The origin was an article I read stating that SS has some shortcomings, such as lacking an error reporting mechanism design, meaning clients cannot take further actions based on different errors.
(I don't agree that all errors should be reported; otherwise, active probing cannot be prevented. In the next beta, the server can return a string of custom information.)
So I realized an extensible structure is important. In the future, it could also carry things like dynamic port commands. Not just responses, requests also need a similar structure.
I originally planned to design TLV myself, but then realized ProtoBuf *is* this structure, a ready-made wheel perfectly suitable for this task, with good language support.
Currently, "Additional Information" only has Scheduler and SchedulerV, which are substitutes for MessName and MessSeed. **When you don't need them, the "Additional Information Length" is 0, so there is no ProtoBuf serialization/deserialization overhead**. Actually, I prefer to call this process "concatenation" because that's all pb does in principle, and the related overhead is minimal. The concatenated bytes are very compact, similar to ALPHA's solution, and those who are interested can output and compare them separately.
Currently, "Addons" only contain Scheduler and SchedulerV, which replace MessName and MessSeed. **When you don't need them, "Addons Length" is 0, so there is no ProtoBuf serialization/deserialization overhead.** Actually, I prefer to call this process "splicing" because that's what pb effectively does in principle, with minimal overhead. The spliced bytes are very compact, hardly different from the ALPHA scheme. Those interested can output and compare them separately.
To indicate different levels of support for additional information (Addons, which can be understood as plugins and can have many plugins in the future), the next beta version will add "Addon Version" before "Addon Length". 256-1 = 255 bytes is enough and reasonable (65535 is too much and there may be malicious padding), and only one-tenth of the existing space is used. In the future, there will not be so many addons at the same time, and most of the time there will be no addons at all. If it is not enough, you can upgrade to a newer version of VLESS.
To indicate different levels of support for Addons (can be understood as plugins; there can be many plugins in the future), the next beta will add an "Addons Version" before "Addons Length". 256 - 1 = 255 bytes is sufficient and reasonable (65535 is too much and might be maliciously filled). Current usage is only one-tenth of that. There won't be that many Addons simultaneously in the future, and in most cases, there are no Addons at all. If it really isn't enough, the VLESS version can be upgraded.
To reduce logical judgment and other expenses, it is temporarily decided that Addons will not use a multi-level structure. A month ago, there was an idea of "variable protocol format". PB can shuffle the order, but it is not necessary because the design of modern encryption will not allow bystanders to see that the headers of the two transmissions are the same.
To reduce overhead like logic checks, it is tentatively decided that Addons will not use a multi-level structure. A month ago, there was an idea of "variable protocol format". pb can shuffle order, but it's unnecessary because modern encryption designs prevent observers from seeing that two transmissions have the same header.
Below is an introduction to the concepts of Schedulers and Encryption, both of which are optional. One is designed to address issues related to traffic timing, while the other is designed to address cryptographic issues.
Below introduces the concepts of Schedulers and Encryption. **Both are optional.** One addresses traffic timing characteristics, and the other addresses cryptographic issues.
## Flow
## ~~Schedulers~~ Flow
### Flow Control (Formerly Traffic Scheduler)
~~Tentative Chinese name: Traffic Scheduler~~ (Updated 2020-09-03: Chinese name confirmed as "Flow Control"). Instructions are carried by ProtoBuf, controlling the data part.
The Flow Control command is carried by ProtoBuf and manages the data section.
I previously found that VMess's original shake "metadata obfuscation" brought no meaningful changes over TLS, only reducing performance, so VLESS deprecated it. Also, the term "obfuscation" is easily misunderstood as camouflage, so it was also deprecated. By the way, I've never been optimistic about camouflage: if it can't be exactly the same, isn't that a strong characteristic? If it can be exactly the same, why not just use the camouflage target directly? I used SSR at first, later found out it only superficially fooled ISPs, and never used it again.
I previously discovered that VMess's original "metadata obfuscation" feature didn't provide any meaningful changes in TLS but only decreased performance. Consequently, VLESS has abandoned this feature. Moreover, the term "obfuscation" is often misinterpreted as camouflage, so it has been discarded.
So, what problem does the "Traffic Scheduler" solve? It affects macroscopic traffic timing characteristics, not microscopic characteristics (which encryption solves). Traffic timing characteristics can be protocol-induced, like the Socks5 handshake in Socks5 over TLS; different characteristics on TLS look like different protocols to monitors. Infinite Schedulers would be equivalent to infinite protocols (redistributing the data size sent each time, etc.). Traffic timing characteristics can also be behavior-induced, such as how many files are loaded when visiting the Google homepage, the order, and the size of each file. Adding another layer of encryption doesn't effectively mask this information.
As for camouflage, if it can't be an exact match, wouldn't it be a noticeable characteristic? If it could be an exact match, why not use the intended target for camouflage directly? Initially, I used SSR but found it only provided superficial disguises, fooling operators. Thus, I stopped using it.
Schedulers don't need to wrap everything on the outside like Encryption below, because the tiny amount of header data is negligible compared to the subsequent data volume.
#### Purpose of Flow Control
Flow Control influences macro traffic temporal characteristics rather than micro characteristics addressed by encryption. Traffic temporal characteristics can be:
1. **Protocol-based**, e.g., Socks5 handshake when using Socks5 over TLS. Different traits on TLS are considered different protocols for monitors. Infinite schedulers equate to infinite protocols (reallocating data sent each time).
2. **Behavior-based**, e.g., loading files, their order, and size when accessing Google's homepage. Adding another encryption layer cannot effectively conceal this information.
Schedulers don't require wrapping like encryption since the header data's tiny amount is negligible compared to the remaining data.
BETA 2 is anticipated to introduce two basic schedulers: Zstd compression and dynamic data expansion. Advanced operations will control and distribute at a macro level, but for now, these remain under development.
BETA 2 is expected to launch two elementary Schedulers: Zstd compression and dynamic data expansion. Advanced operations involve controlling and allocating from a macro level, which is postponed for now.
## Encryption
Unlike VMess, which is highly coupled, VLESS allows the server and client to pre-agree on an encryption method, which is only encrypted with an outer layer. This is somewhat similar to using TLS, which does not affect any of the data carried, and can be understood as replacing TLS with pre-agreed encryption at the bottom. Compared with high coupling, this approach is more reasonable and flexible: if there is a security issue with one encryption method, it can be discarded and another one can be used directly, which is very convenient. The VLESS server also allows for different encryption methods to coexist.
Unlike VMess's high coupling, VLESS servers and clients will soon be able to agree on an encryption method in advance, wrapping only one layer of encryption on the outside. This is somewhat similar to using TLS; it doesn't affect any carried data and can be understood as swapping the underlying layer from TLS to a preset agreed encryption. Compared to high coupling, this method is more reasonable and flexible: if a security issue arises with one encryption method, just discard it and switch to another, very convenient. VLESS servers will also allow different encryption methods to coexist.
Compared with VMess, VLESS replaces security with encryption and disableInsecureEncryption with decryption, which solves all the problems. Currently, encryption and decryption only accept "none" and cannot be left blank (even if there are connection security checks in the future), as detailed in the VLESS configuration document. Encryption does not need to be moved out one level, firstly because it cannot reuse a lot of code, and secondly because it will affect the control granularity, which will be understood by looking at future applications.
Compared to VMess, VLESS effectively replaces `security` with `encryption` and `disableInsecureEncryption` with `decryption`, solving all problems. Currently, `encryption` and `decryption` only accept "none" and cannot be empty (even if connection security checks are added later). See [VLESS Configuration Documentation](https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md) for details. `encryption` doesn't need to be moved out one level, firstly because a lot of code can't be reused, and secondly because it affects control granularity. Future applications will make this clear.
Encryption supports two types of forms. One type is completely independent and requires an additional password, suitable for private use. The other type combines with the existing UUID for encryption, which is suitable for public use.
Encryption supports two forms. One is completely independent encryption requiring an extra password, suitable for private use. The other combines with the existing UUID for encryption, suitable for public use.
(If the first form is used and the password is disclosed in some form, e.g., shared by many people, MITM attacks are not far off.)
Redesigned dynamic ports might be released alongside encryption. Instructions will be carried by ProtoBuf, and the implementation will differ significantly from VMess dynamic ports.
(If the first type of encryption is used and the password is publicly available in some form, such as multiple people sharing it, then a man-in-the-middle attack is not far away.)
wrapping existing encryption is very simple, just adding a layer of writer & reader. BETA 3 is expected to support SS's aes-128-gcm and chacha20-ietf-poly1305:
Client `encryption` can be filled with "auto: ss_aes-128-gcm_0_123456, ss_chacha20-ietf-poly1305_0_987654". "auto" will choose the best fit for the current machine, 0 represents beta version, and the last part is the password. Server `decryption` is filled similarly; it will attempt decryption one by one upon receiving a request.
A redesigned dynamic port may be released simultaneously with encryption, and the command is carried by ProtoBuf. The specific implementation and the dynamic port of VMess will also have many differences.
It is very easy to cash out encrypted currency, which adds an extra layer of writer & reader. BETA 3 is expected to support SS's aes-128-gcm and chacha20-ietf-poly1305:
The encryption on the client-side can be filled with "auto: ss_aes-128-gcm_0_123456, ss_chacha20-ietf-poly1305_0_987654". Auto will choose the most suitable one for the current machine, 0 represents the beta version, and the last one is the password. The decryption on the server-side is also filled in a similar way, and each decryption attempt will be made when the request is received.
Not all combinations need to be tried one by one: VMess encryption is divided into three parts. The first part is the authentication information, which combines UUID, alterId, and time factors. The second part is the instruction part, which is encrypted using a fixed algorithm. The instruction contains the encryption algorithm used in the data part. The third part is the important data part. It can be seen that the VMess encryption and decryption method is actually many-to-one (adapted by the server), not just combining UUID. However, it is also a relatively difficult thing to encrypt only by combining UUID. It will not be available in a short time. Considering that we now have VMessAEAD available, there is no need to rush. If VLESS introduces an encryption method that combines UUID, it is equivalent to reconstructing the entire VMess.
Not all combinations need to be tried one by one: VMess encryption is divided into three parts. The first part is authentication info, combining UUID, alterId, and time factors. The second part is the command part, encrypted with a fixed algorithm; the command contains the encryption algorithm used for the data part. The third part is the important data part. It can be seen that VMess encryption/decryption is actually many-to-one (server adaptation), not just combining UUID. But encrypting just by combining UUID is relatively troublesome and won't be released soon. Given we have VMessAEAD now, there's no rush. If VLESS introduces encryption combined with UUID, it's equivalent to refactoring the entire VMess.
## UDP issues
[XUDP: VLESS & VMess & Mux UDP FullCone NAT](https://github.com/XTLS/Xray-core/discussions/252)
## Client Development Guide
## Client Development Guidelines
1. The VLESS protocol itself may have incompatible upgrades, but the parameters in the client configuration file are basically only increased and not decreased. The protocol implementation of the iOS client needs to keep up with the upgrade.
2. Visual standard: Please use VLESS as the UI identifier uniformly, instead of VLess / Vless / vless. The configuration file is not affected, and the code should follow naturally.
3. `Encryption` should be made into an input box instead of a selection box. The default value of the new configuration should be `none`, and if the user leaves it blank, it should be filled in with `none`.
1. The VLESS protocol itself will have incompatible upgrades, but client configuration file parameters will basically only increase, not decrease. iOS client protocol implementation needs to follow upgrades closely.
2. **Visual Standard: Please use VLESS uniformly for UI identifiers**, not VLess / Vless / vless. Configuration files are unaffected, code style follows natural conventions.
3. `encryption` should be an input box, not a select box. The default value for new configurations should be `none`. If the user leaves it empty, fill `none` automatically.
## VLESS Sharing Link Standard
Thank you to [@DuckSoft](https://github.com/DuckSoft) for the proposal!
Thanks to <img src="https://avatars2.githubusercontent.com/u/7822648?s=32" width="32px" height="32px" alt="a"/> [@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)
docs/en/development/protocols/vmess.md
+102 -101
View File
@@ -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.
docs/en/document/command.md
+83 -31
View File
@@ -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 <command>" for more information about a command.
```
### xray run
@@ -48,21 +51,40 @@ Xray. Multiple assign is accepted.
The -confdir=dir flag sets a dir with multiple json config
The -format=json flag sets the format of config files.
Default "json".
Default "auto".
The -test flag tells Xray to test config files only,
without launching the server
without launching the server.
The -dump flag tells Xray to print the merged config.
```
`-config=` / `-c=` are used to specify the location of the configuration file(s) to use. Supports multi-file configuration.
`-confdir=` is used to specify a folder containing multiple configuration files.
`-format=` is used to specify the format of the configuration files.
`-test` is used to test the validity of the configuration files.
`-dump` is used to display the result after merging multiple configuration files.
::: tip
Except from the default JSON format, config can also use TOML and YAML. It will automatically recognized from file extensions when the `-format` flag is not set.
In addition to the default JSON format, configuration files can also use TOML and YAML. If no format is specified, it will be identified by the file extension.
:::
::: tip
When `-config` is not specified, Xray will attempt to load `config.json` from the following paths in order:
- Working Directory
- The path specified by `Xray.location.asset` in [Environment Variables](../config/features/env.md#resource-file-path)
:::
```
xray run -dump
```
Used to output the result after merging multi-file configurations.
### xray version
Output Xray version, Golang version and other information.
Output Xray version, Golang version, and other information.
Usage:
@@ -72,7 +94,7 @@ Usage:
### xray api
To call Xray's gRPC API, it needs to be enabled in the configuration file.
Call Xray's gRPC API. Needs to be enabled in the configuration file.
Usage:
@@ -93,9 +115,9 @@ xray api <command> [arguments]
### xray convert
Convert config to protobuf, or convert typedMessage to JSON
Convert configuration files to protobuf or convert typedMessage to JSON.
usage:
Usage:
```
xray convert <command> [arguments]
@@ -106,25 +128,25 @@ The commands are:
json Convert typedMessage to json
```
Sub-command `pb`
`pb` subcommand usage example:
```bash
# Usage: xray convert pb [-debug] [-type] [json file] [json file] ...
# Usage: xray convert pb [-outpbfile out.pb] [-debug] [-type] [json file] [json file] ...
# mix three config files to mix.pb
xray convert pb c1.json c2.json c3.json > mix.pb
# Merge three configs into mix.pb
xray convert pb -outpbfile mix.pb c1.json c2.json c3.json
# Use -debug option to view the content of mix.pb
xray convert pb -debug mix.pb
# Start Xray-core with mix.pb
# Start Xray-core using mix.pb
xray -c mix.pb
# Detailed usage
# Detailed instructions
xray help convert pb
```
Sub-command JSON
`json` subcommand usage example:
```bash
# Usage: xray convert json [-type] [stdin:] [typedMessage file]
@@ -136,13 +158,13 @@ tmsg='{
echo ${tmsg} | xray convert json stdin:
# Outputs from above:
# The output of the above command is:
'{
"cipherType": "AES_256_GCM",
"password": "111"
}'
# Detailed usage
# Detailed instructions
xray help convert json
```
@@ -169,22 +191,22 @@ Generate UUID.
Usage:
```
xray uuid
xray uuid [-i "example"]
```
### xray x25519
Generate x25519 key pair。
Generate x25519 key pair.
Usage:
```
xray x25519 [-i "(base64.RawURLEncoding)" --std-encoding]
xray x25519 [-i "(base64.RawURLEncoding)" --std-encoding ]
```
### xray wg
Generate wireguard curve25519 key pair。
Generate WireGuard curve25519 key pair.
Usage:
@@ -193,8 +215,38 @@ xray wg [-i "(base64.StdEncoding)"]
```
::: tip
When `-config` is not specified, Xray will try to load `config.json` from the following paths:
When `-config` is not specified, Xray will attempt to load `config.json` from the following paths in order:
- Working Directory
- The path specified by `Xray.location.asset` in the [environment variable](../config/features/env.md).
:::
- The path specified by `Xray.location.asset` in [Environment Variables](../config/features/env.md#resource-file-path)
:::
### xray mldsa65
Generate MLDSA-65 post-quantum signature key pair for REALITY.
Usage:
```
xray mldsa65 [-i "seed (base64.StdEncoding)"]
```
### xray mlkem768
Generate ML-KEM-768 post-quantum key exchange key pair for VLESS Encryption.
Usage:
```
xray mlkem768 [-i "seed (base64.StdEncoding)"]
```
### xray vlessenc
Generate encryption/decryption option content that can be directly used for VLESS Encryption. In the generated configuration, you can use either X25519 or ML-KEM-768 authentication method, but the server and client must use the same authentication method. The ephemeral key exchange remains post-quantum secure regardless of the authentication method.
Usage:
```
xray vlessenc
```
docs/en/document/config.md
+27 -20
View File
@@ -1,25 +1,32 @@
# Configure and Run
After [downloading and installing Xray](./install.md), you need to configure it.
After you have [downloaded and installed](./install) Xray, you need to configure it.
For demonstration purposes, only a simple configuration method is introduced here. For more templates, please refer to [Xray-examples](https://github.com/XTLS/Xray-examples).
For demonstration purposes, only simple configuration methods are introduced here. For more templates: [Xray-examples](https://github.com/XTLS/Xray-examples)
If you need to set up more advanced features, please refer to the relevant instructions in the more detailed [configuration file](../config/).
To configure more complex features, please refer to the detailed instructions in [Configuration](../config/).
::: danger
To avoid your traffic being decrypted,<br>
You should use `xray uuid` or `uuidgen` to generate a unique UUID.<br>
On the server side, put it in `inbounds[0].settings.clients[0].id`.<br>
On the client side, put it in `outbounds[0].settings.vnext[0].users[0].id`.<br>
:::
## 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/).
docs/en/document/index.md
+24 -22
View File
@@ -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.
:::
docs/en/document/install.md
+68 -50
View File
@@ -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 <Badge text="WIP" type="warning"/>
@@ -72,33 +74,33 @@ The Linuxbrew package manager is used in the same way as Homebrew: `brew install
Currently, three third-party Overlays provide Portage installation scripts:
- **[CHN-beta/touchfish-os](https://github.com/gentoo-mirror/touchfish-os/tree/master/net-proxy/Xray)**: Individually maintained, designed for systemD systems
- **[Gentoo-zh](https://github.com/microcai/gentoo-zh)**: Community-maintained, designed for systemD systems
- **[JuanCldCmt/Xray-Overlay](https://github.com/JuanCldCmt/Xray-Overlay)**: Individually maintained, designed for openRC systems. Runs under the `xray` user group for enhanced security
- [CHN-beta/touchfish-os](https://github.com/gentoo-mirror/touchfish-os/tree/master/net-proxy/Xray): Personally maintained, suitable for systemD systems.
- [Gentoo-zh](https://github.com/microcai/gentoo-zh): Community maintained, suitable for systemD systems.
- [JuanCldCmt/Xray-Overlay](https://github.com/JuanCldCmt/Xray-Overlay): Personally maintained, suitable for openRC systems; runs with the xray user group to improve security.
Use `layman` or `eselect-repository` to add the Overlay to your local repository, then install.
Use layman or eselect-repository to add the Overlay locally, then install.
## Install via Docker
## Docker Installation
Currently two different styles of Docker images are provided:
Currently, two different styles of Docker images are provided:
- [teddysun/xray](https://hub.docker.com/r/teddysun/xray): Root privileges, shell environment, compatible with all architectures supported by Alpine. Compiled and built via a private server (dl.lamp.sh). Offers better ease of use
- [ghcr.io/xtls/xray-core](https://ghcr.io/xtls/xray-core): Rootless, no shell environment, supports more architectures. Compiled from the official repository with build provenance. Sacrifices convenience for extreme security
- [teddysun/xray](https://hub.docker.com/r/teddysun/xray): Has root privileges, has shell environment, compatible with all Alpine-supported architectures. Compiled and built by private server dl.lamp.sh. More convenient to use.
- [ghcr.io/xtls/xray-core](https://ghcr.io/xtls/xray-core): No root privileges, no shell environment, supports more architectures. Compiled and built by the official repository supporting traceability. Sacrifices convenience for more extreme security.
### Docker Image File Structure
teddysun/xray image:
teddysun/xray version image:
- `/usr/bin/xray`: Xray-core executable
- `/etc/xray/config.json`: Single configuration file (its directory is the mount point)
- `/usr/share/xray/`: Resource directory containing v2fly geodata files
- `/usr/bin/xray`: Xray main program
- `/etc/xray/config.json`: Single configuration file (its directory is a mount point)
- `/usr/share/xray/`: Resource file directory, stores v2fly version geolocation data files
- geoip.dat
- geosite.dat
ghcr.io/xtls/xray-core image:
ghcr.io/xtls/xray-core version image:
- `/usr/local/bin/xray`: Xray-core executable (owner: root:root, permissions: 755)
- `/usr/local/etc/xray/`: Configuration directory (mount point). Owner: root:root, directory permissions: 755, file permissions: 644
- `/usr/local/bin/xray`: Xray main program (Owner is root:root, file permissions 755)
- `/usr/local/etc/xray/`: Configuration file directory (Mount point) (Owner is root:root, directory permissions 755, file permissions 644)
- 00_log.json
- 01_api.json
- 02_dns.json
@@ -109,39 +111,55 @@ ghcr.io/xtls/xray-core image:
- 07_transport.json
- 08_stats.json
- 09_reverse.json
- `/usr/local/share/xray/`: Resource directory containing Loyalsoldier geodata files (same permissions as above)
- `/usr/local/share/xray/`: Resource file directory, stores Loyalsoldier version geolocation data files (Permissions same as above)
- geoip.dat
- geosite.dat
- `/var/log/xray/`: Log directory (mount point). Directory owner: root:root, permissions: 755. File owner: 65532:65532, permissions: 600
- `/var/log/xray/`: Log file directory (Mount point) (Directory owner is root:root, permissions 755; File owner is 65532:65532, permissions 600)
- access.log
- error.log
# GUI Client
# Graphical Clients
- OpenWrt
- [PassWall](https://github.com/xiaorouji/openwrt-passwall), [PassWall 2](https://github.com/xiaorouji/openwrt-passwall2)
- [ShadowSocksR Plus+](https://github.com/fw876/helloworld)
- [luci-app-xray](https://github.com/yichya/luci-app-xray) ([openwrt-xray](https://github.com/yichya/openwrt-xray))
- Asuswrt-Merlin
- [XRAYUI](https://github.com/DanielLavrushin/asuswrt-merlin-xrayui)
- Windows
- [v2rayA](https://github.com/v2rayA/v2rayA)
- [v2rayN](https://github.com/2dust/v2rayN)
- [Furious](https://github.com/LorenEteval/Furious)
- [Invisible Man - Xray](https://github.com/InvisibleManVPN/InvisibleMan-XRayClient)
- [AnyPortal](https://github.com/AnyPortal/AnyPortal)
- Android
- [v2rayNG](https://github.com/2dust/v2rayNG)
- [X-flutter](https://github.com/XTLS/X-flutter)
- [SaeedDev94/Xray](https://github.com/SaeedDev94/Xray)
- iOS & macOS arm64
- [SimpleXray](https://github.com/lhear/SimpleXray)
- [AnyPortal](https://github.com/AnyPortal/AnyPortal)
- iOS & macOS arm64 & tvOS
- [Happ](https://apps.apple.com/app/happ-proxy-utility/id6504287215) ([tvOS](https://apps.apple.com/us/app/happ-proxy-utility-for-tv/id6748297274))
- [FoXray](https://apps.apple.com/app/foxray/id6448898396)
- [Streisand](https://apps.apple.com/app/streisand/id6450534064)
- macOS arm64 & x64
- [Happ](https://apps.apple.com/app/happ-proxy-utility/id6504287215)
- [v2rayA](https://github.com/v2rayA/v2rayA)
- [v2rayN](https://github.com/2dust/v2rayN)
- [V2rayU](https://github.com/yanue/V2rayU)
- [V2RayXS](https://github.com/tzmax/V2RayXS)
- [Furious](https://github.com/LorenEteval/Furious)
- [FoXray](https://apps.apple.com/app/foxray/id6448898396)
- [OneXray](https://github.com/OneXray/OneXray)
- [GoXRay](https://github.com/goxray/desktop)
- [AnyPortal](https://github.com/AnyPortal/AnyPortal)
- Linux
- [v2rayA](https://github.com/v2rayA/v2rayA)
- [v2rayN](https://github.com/2dust/v2rayN)
- [Furious](https://github.com/LorenEteval/Furious)
- [GorzRay](https://github.com/ketetefid/GorzRay)
- [GoXRay](https://github.com/goxray/desktop)
- [AnyPortal](https://github.com/AnyPortal/AnyPortal)
# UUID Generator
Third-party UUID generator [uuidgenerator.net](https://www.uuidgenerator.net)
Third-party UUID generator: [uuidgenerator.net](https://www.uuidgenerator.net)
docs/en/document/level-0/ch01-preface.md
+50 -54
View File
@@ -1,99 +1,95 @@
# [Chapter 1] Simple and Plain Language
# [Chapter 1] Plain English Guide for Absolute Beginners
## 1.1 Who is this document written for?
## 1.1 Who is this document for?
One sentence: Written for newbies who are **(1) absolute beginners** and **(2) interested in learning how to build their own VPS**.
In short: It is written for newcomers who have **① Zero technical background** and **② A desire to learn how to self-host a VPS**.
## 1.2 Who is this document not written for?
## 1.2 Who is this document NOT for?
Including but not limited to: experts and professionals, beginners who are too lazy to tinker on their own, advanced users who already know how to tinker, wealthy users who insist on using airport services, and those who prefer using one-click scripts. In short, if you have a technical background or don't want to build it yourself, you can close this article directly, because this article may not be suitable for you and may even make you upset.
Including but not limited to: various tech gurus, beginners too lazy to tinker, experts who already know the ropes, big spenders determined to use "Airports" (VPN service providers), and the "Carefree Sect" determined to use one-click scripts... In short, as long as you have a technical foundation or are unwilling/don't want to build it yourself, you can close this article right now. This article probably won't meet your high standards and might just make you angry over nothing, which isn't worth it.
## 1.3 Declaration and Other Statements
## 1.3 Solemn Declaration and Other Declarations
Declaration:
**Solemn Declaration:**
My technical skills are extremely limited, so this article is inevitably full of errors and flaws. If you find any problems, please kindly point them out and don't be too harsh on me.
My technical skills are incredibly poor, so this text will inevitably have omissions and be full of flaws. If you find issues, please remind me gently; do not engage in personal attacks.
Disclaimer:
**Disclaimer:**
Please judge the reliability and usability of the content of this article by yourself. If you encounter any problems or negative results when establishing and using a VPS server based on the content of this article, I am not responsible for it.
Please judge the credibility, reliability, and usability of this content yourself. I am not responsible for any issues or adverse results arising from building and using a VPS server based on this content.
Verbose statement:
**Verbose Declaration:**
Considering the target audience of this article, which is "users with zero experience", many details will be explained in great detail, so the language may be verbose. Please be mentally prepared for this.
Based on the target audience of this article (Zero-basis users), many contents will be explained as exhaustively as possible. Therefore, the language will lean towards being wordy/long-winded. Please be mentally prepared.
## 1.4 Why is self-hosting a challenge?
## 1.4 Why is self-hosting a difficult problem?
To answer this question, we need to provide a little more background information.
To answer this question, we need to provide a bit more background information.
1. On the matter of accessing the internet through scientific means
**I. The matter of Scientific Internet Access (Circumvention)**
The act of accessing the internet using scientific methods has been around for almost 20 years (shocking!!!.jpg). Initially, one could do it with a little effort (changing the host file, using SSH), then one had to find a web proxy, and later, one had to develop a private protocol (such as Shadowsocks) and so on.
The practice of "Scientific Internet Access" (circumventing the firewall) has been developing for nearly twenty years (Shocking!!!.jpg). Initially, you only needed to move your hands a little (tweak the hosts file, connect via SSH). Later, you needed to find a web proxy, and then later you needed to write a private protocol (like Shadowsocks), and so on.
With the continuous iteration and upgrade of GFW technology over the past decade, to achieve the goal of [building your own scientific Internet access], the things that need to be done include but are not limited to:
With the GFW technology constantly iterating and upgrading over the last decade, the tasks required to achieve the goal of "Do-It-Yourself Circumvention" now include but are not limited to:
- Understand basic Linux commands
- Understand network transmission protocols
- Have the technical and financial ability to purchase and manage a VPS
- Have the technical and financial ability to purchase and manage a domain name
- Have the technical ability to apply for a TLS certificate, and so on.
- Understanding basic Linux system commands
- Understanding network transmission protocols
- Having the technical and financial capability to complete VPS purchase and management
- Having the technical and financial capability to complete Domain purchase and management
- Having the technical capability to complete TLS certificate application, etc.
This has turned the once simple act of [setting up a self-built VPS for accessing the internet in a secure and unrestricted manner] into a daunting challenge that intimidates newcomers.
This has turned the once-simple act of "self-hosted VPS circumvention" into a daunting challenge for newcomers.
2. Helplessness of Zero-based Users
**II. The helplessness of zero-basis users**
For non-technical users with zero foundation, if they complete the above series of operations, they will inevitably need to learn a lot of knowledge. However, after a little searching, newbies are likely to become even more confused: a large amount of information is scattered in various corners of the Internet: blogs, Q&A sites, groups, forums, GitHub, Telegram, YouTube, and so on. These pieces of information are chaotic and complex, with varying levels of quality, and may even contradict each other. Basically, they won't stop until they completely confuse the newcomer.
If a zero-basis, non-technical user wants to complete the series of operations above, they inevitably have to learn a vast amount of knowledge. However, after a little searching, the newcomer will likely become even more lost: massive amounts of information are scattered across every corner of the Internet (blogs, Q&A sites, groups, forums, GitHub, Telegram, YouTube, etc.). This information is chaotic, complex, of varying quality, and potentially contradictory. Basically, it won't stop until the newcomer is completely dizzy.
Faced with such chaotic information, newcomers suddenly shift from [information scarcity] to [information overload]. If they fail after several attempts of groping and guessing (which is highly probable), their enthusiasm is bound to be greatly frustrated. In this process, if they happen to seek help in some unfriendly places, they may be ridiculed even more: "You're so inexperienced, just use the airport, why bother messing around!" "Go learn Linux first before coming back to ask."
Faced with this disorganized information, the newcomer suddenly goes from "information scarcity" to "information overload." If they try to muddle through a few times and end up failing (which is highly probable), their enthusiasm will inevitably suffer a major setback. During this process, if they happen to go to some unfriendly places to ask for help, they might be ridiculed, adding insult to injury: "If you're so bad at this, just use an Airport, why are you blindly tinkering?", "Go learn Linux first before coming back to ask."
At this moment, probably only an "hehe" can express the mood.
At this point, perhaps only a sarcastic "Heh" can express one's mood.
## 1.5 "Why not just use the airport?"
## 1.5 "Isn't using an airport enough?"
An Airport refers to a pre made solution, where a provider is responsible all technical aspects of hosting and providing the service as mentioned in section 1.4, with the user only paying for the right to use the service.
First, I want to ask those who sneer: Is "using an airport" really a panacea?
First of all, I would like to respond to critics by asking a question: Is using an airport really a cure all?
Secondly, I believe there is a fundamental difference between "not understanding" and "not wanting to understand." While entitled "giant babies" with bad attitudes are naturally annoying, people who genuinely want to self-study but can't find the way shouldn't be subjected to unwarranted eye-rolls and discrimination. It is precisely this toxic community atmosphere that makes no distinction regarding newcomers that prompted me to write this article. So, without further ado, let's look at the pros and cons of airports:
Secondly, I believe that there is a fundamental difference between "not understanding" and "not wanting to understand". The bad attitude of some people who just want handouts is naturally annoying, but those who sincerely want to learn but don't know how should not be subject to unjustified contempt and discrimination. It is precisely this kind of bad community atmosphere that does not distinguish between newcomers that prompted me to write this article. So without further ado, let's take a look at the advantages and disadvantages of using an airport:
**I. Advantages of "Airports"**
- Advantages of "Airports"
A so-called "Airport" is a "Line Provider" (VPN/Proxy Service). They handle the string of technical operations and management mentioned in 1.4, and the user pays for the right to use it. Therefore, its advantages are at least:
1. **Stability**: Airports usually feature multiple exit nodes, hence resistance to attempts at blocking these node, if one get block simply switch to another
2. **Speed**: Airports typically make use of high capacity machines and high throughput network infrastructures, therefore you can expect a higher overall network speed
3. **Safety**: Airports are generally have good security practices, such as encryption and firewalls to ensure the security of user data
4. **reliability**: Airports employ a dedicated team to manage their services ensuring they remain online and reliable
5. **support**: you can generally expect an Airport to have a support team to answer your queries.
6. **Simplicity**: One-click rule addition, Scannable configurations, etc.
7. **diverse-exit-nodes**: Useful to access geo-restricted content or to get a lower ping for gaming
1. **Simple User Operation**: Scanning QR codes, one-click rule addition, etc.
2. **Many Line Choices**: Can unlock network services in different countries and regions; such as IPLC dedicated lines, game acceleration services, etc.
3. **Many Access Nodes**: Stronger ability to resist node blocking; if one gets blocked, just switch to the next.
- Risks of "Airport"
**II. Risks of "Airports"**
"The counterpart of convenience in 'internet' security is 'risk', some risk of 'airports' you can find on the market are"
The other side of the "convenience" coin is "risk." Based on the technical characteristics and market situation of "Airports," the risks are at least:
1. service providers can obtain all infomation that passes through their servers, these data are very likely stored by the providers for a long time with little legal means to stop them
2. there is little governance on the market for "airports", meaning there are plenty cases of fraud where providers disappear after being paid
3. Service providers can face regulatory pressures, while large providers are relatively secure, they cannot avoid attention from the government, In 2020 there are many cases where several large airports experience major service disruptions
4. A providers technical prowess is difficult to determine, the quality of the service provided varies greatly, with false advertising being common
1. **"Airports" can fully access user information**: All user traces on the Internet *inevitably* pass through and are *very likely* stored on their servers for a long time. These records are not bound by any legally effective user privacy agreements (**peeping, recording your every move**).
2. **"Airports" lack market regulation**: There are inevitably malicious merchants aiming at fraud (**active exit scams/running away**).
3. **"Airports" face regulatory pressure**: While big airports are relatively secure, they cannot avoid attracting attention. In 2020, several large airports suspended operations or ran away, severely interfering with users' normal usage (**passive exit scams/forced shutdown**).
4. **"Airport" technical levels are hard to determine**: Line quality varies greatly, and deceptive practices are common (**slow speeds, frequent drops, inability to connect**).
## 1.6 So should you host your own tunnel?
## 1.6 So, do you want to self-host or not?
Now that you have seen the advantages and risks of using a service provider, please think carefully and make your own decision on what to use. After all, the best plan is the one that suits you best.
Now that you have seen the advantages and risks of airports, please think fully and decide for yourself what to use. After all, the solution that suits you best is the best solution.
![It's Your Choice!](./ch01-img01-choice.png)
1. If you decide to use an existing service provider, you can close this article now.
1. If you decide to use an airport, you can close this article now.
2. If you decide to build it yourself, please continue reading the following chapters!
2. If you decide to self-host, please continue reading the following chapters!!
In short, the goal of this article is to serve as a starting point for users with zero experience, providing thorough explanations and demonstrations for each step, even if it may seem overly detailed or repetitive. The aim is to assist beginners in completing the entire process of deploying a VPS server from the first command input to successfully accessing the internet via the client, and gradually introducing them to basic Linux operations, laying a foundation for further self-learning.
In short, the goal of this article is to become the knowledge starting point for zero-basis users. It provides full explanations and demonstrations for every step, clearly (even **naggingly, chattily, and wordily**) assisting newcomers to complete the entire process from **inputting the first command, deploying the VPS server, to successfully circumventing the firewall on the client side**. In this process, it helps newcomers gradually contact and become familiar with basic Linux operations, laying a foundation for further self-study.
## 1.7 Some digressions
## 1.7 A few extra words
1. There is a wealth of information beyond the wall, so please learn to think rationally and independently. Don't take sides easily and don't believe in sensational information. (This also serves as an reminder for friends live beyond the wall)
1. Information outside the wall is mixed. Please be sure to learn rational, independent critical thinking. Do not blindly take sides, and do not readily trust sensational information.
2. We sincerely hope that with a more open internet, everyone can access knowledge in real time, find better entertainment, experience this amazing world, and find like-minded individual to befriend, but do not become a scapegoat for anyone with ulterior motives.
2. I sincerely hope that after obtaining a smoother network, you can acquire fresh knowledge, richer entertainment, contact a better world, and make more like-minded friends, but do not become a scapegoat for anyone with ulterior motives.
3. Your internet identity is still your identity, and achieving absolute anonymity is extremely difficult. Therefore, please be sure to comply with the relevant laws and regulations in your personal location and the location of your IP address. Self-preservation should be your highest priority. (TLDR. Please take responsibility for your action on the internet)
3. Your internet identity is still your identity. Absolute anonymity is extremely difficult, so please be sure to comply with the relevant laws and regulations of your personal location and your IP location. At all times, self-protection is the most basic bottom line.
## 1.8 Your Progress
docs/en/document/level-0/ch02-preparation.md
+29 -28
View File
@@ -1,52 +1,53 @@
# [Chapter 2] Prerequisite and preparations
# [Chapter 2] Raw Materials Preparation
This chapter is rather special because it involves monetary transactions. This article takes a neutral stance on the project and does not make specific recommendations. What I can do is to tell you what you need to prepare.
This chapter is somewhat special because it involves monetary transactions. Based on the neutral stance of this project, no specific recommendations will be made. What I can do is tell you what you need to prepare.
## 2.1 Acquiring a VPS
## 2.1 Obtain a VPS
You need to obtain a healthy VPS with an unblocked IP, and perform the following basic preparations in the management console:
You need to obtain a healthy VPS whose IP is not blocked, and complete the following basic preparations in the management panel:
1. Install Debian 10 64 bit Operating System on your VPS.
2. Note down the IP address of VPS (this article will use `"100.200.300.400"` as an example, which is an intentionally incorrect and illegal IP address. Please replace it with your real IP address).
3. Note down the SSH remote login port of VPS.
4. Note down the username and password for SSH remote login.
1. Install the **Debian 10 64bit** system in the VPS management panel.
2. Make a note of the VPS IP address (this article will use `"100.200.300.400"` to represent it).
::: tip
This is a deliberately written illegal IP; please replace it with your real IP.
:::
3. Make a note of the VPS SSH remote login port.
4. Make a note of the SSH remote login username and password.
Buying a VPS is a relatively complex matter. It is recommended to first learn the relevant knowledge and choose one that suits your own economic ability and network requirements. In addition, you can choose to take advantage of some benefits offered by tech giants (such as permanent free or limited-time free packages offered by Oracle Cloud Infrastructure and Google Cloud Platform). In any case, you must act within your means.
Purchasing a VPS is a relatively complex matter. It is recommended to learn some relevant knowledge first and choose one that fits your financial ability and line quality needs. Additionally, you can choose to take advantage of free offers from major international tech giants (such as the permanent free or limited-time free tiers provided by Oracle and Google). In short, please act according to your means.
:::tip Explanation
Regarding the choice of Debian 10 as the operating system, let me elaborate a bit: No matter what you have heard online, no matter which guru has told you that XXX version of Linux is better or XXX version of Linux is more powerful, these sectarian disputes have **nothing to do with you right now**! Using Debian 10 is enough to optimize your VPS server for security, stability, and performance (such as using cloud-optimized kernel, timely support of BBR, etc.). After you become familiar with Linux, you can try other Linux distributions.
::: tip Note
Regarding the choice of Debian 10 as the operating system, let me add a few words here: No matter what you hear online, no matter which "guru" tells you that XXX version of Linux is better or XXX version of Linux is cooler, these Linux distro wars **have absolutely nothing to do with you right now**! Using Debian 10 is sufficient to allow your VPS server to run securely and stably while receiving enough optimization (such as cloud-specific kernels, timely BBR support, etc.). Once you are familiar with Linux, it won't be too late to look back and try other Linux distributions.
:::
## 2.2 Obtaining a Desired Domain Name
## 2.2 Obtain a Desired Domain Name
You need to obtain a domain name and add an A record in the DNS settings, pointing to the IP address of your VPS.
You need to obtain a domain name and add an A record in the DNS settings pointing to your VPS IP address.
1. Please choose a reliable international domain name service provider. Choose some common domain name suffixes, and make sure not to use the `.cn` suffix.
2. In the DNS settings, add an A record pointing to the IP address of your VPS (the name of the A record can be anything, and in this article, it will be represented by `"a-name"`). The complete domain name will be represented by `"subdomain.yourdomain.com"` or `"a-name.yourdomain.com"`. The effect is as shown in the picture below:
1. Please choose a reliable international domain registrar. Choose some common domain suffixes, but be careful **not** to use the `.cn` suffix.
2. In the DNS settings, add an **A record** pointing to your VPS IP address (The name of the A record can be anything; this article will use `"a-name"` to represent it. The full domain name will be represented as `"subdomain.yourdomain.com"` or `"a-name.yourdomain.com"`). The effect is shown in the figure below:
![Add A Record](./ch02-img01-a-name.png)
::: tip
This is **not** a real usable website. Please replace it with your real website URL.
This is **not** a real, usable URL; please replace it with your real URL.
:::
## 2.3 Software you need to install on your local computer
## 2.3 Software to Install on Your Local Computer
1. SSH remote login tool
1. **SSH Remote Login Tool**
* Windows: [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html)
* macOS/Linux: Terminal
- Windows: [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html)
- macOS/Linux: Terminal
2. **Remote File Copy Tool**
* Windows: [WinSCP](https://winscp.net/eng/index.php)
* macOS/Linux: Terminal
2. Remote file copying tool
- Windows: [WinSCP](https://winscp.net/eng/index.php)
- macOS/Linux: Terminal
3. Reliable text editor
- Windows/macOS/Linux: [VSCode](https://code.visualstudio.com)
3. **Reliable Text Editor**
* Windows/macOS/Linux: [VSCode](https://code.visualstudio.com)
## 2.4 Your Progress
If you have all the raw materials ready as mentioned above, you have already obtained the key to unlocking the door to a new world. So, what are you waiting for? Let's quickly move on to the next chapter and step through this door!
If you have prepared all the raw materials above, you have obtained the key to opening the door to a new world. So what are you waiting for? Let's move on to the next chapter and walk through that door!
> ⬛⬛⬜⬜⬜⬜⬜⬜ 25%
docs/en/document/level-0/ch03-ssh.md
+44 -49
View File
@@ -2,88 +2,83 @@
## 3.1 Remote Login to VPS (PuTTY)
First of all, considering that the user base of Windows is the largest among the zero-based population, this article uses Windows as an example for demonstration.
First, given that Windows has the largest user base among beginners, this article will use Windows as an example.
Secondly, although PowerShell and WSL after Windows 10 can also achieve a good SSH operation experience, not all versions of Windows have the latest components. Therefore, this article uses the classic PuTTY as an example to provide a detailed explanation of SSH remote login operation. (If you use other tools, the operations after the SSH login are the same.)
Secondly, although modern Windows 10 and later versions feature PowerShell and WSL which offer a great SSH experience, not all versions of Windows have the latest components. Therefore, we will use the classic tool **PuTTY** for this detailed SSH tutorial. (If you use other tools, the operations after logging in are identical.)
Follow me step by step and let's start the operation.
Now, follow me step by step.
1. Go to the [official website](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) of PuTTY and download the version that suits your operating system (this article uses the 64-bit version as an example).
1. Go to PuTTY's [official website](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) and download the version suitable for your operating system (this article uses the 64-bit version).
![Download PuTTY](./ch03-img01-putty-download.png)
![Download PuTTY](./ch03-img01-putty-download.png)
2. After installation and running, you will see the main interface of PuTTY. Now please take out your notebook from the previous chapter where you wrote down the **IP address (VPS IP)** and **port (VPS PORT)** of your VPS in the corresponding positions of the following figure. In order to save time and avoid repeatedly entering these details in the future, we can save the session (Saved Sessions), and simply load it in the future with one click.
2. After installation, open PuTTY. Now, take out the [notebook](./ch02-preparation.md#21-getting-a-vps) where you jotted things down in the previous chapter. Fill in your VPS **IP Address** and **Port** in the corresponding fields shown below. To avoid typing this every time, we can save the session. Just click `Save` under Saved Sessions, and in the future, click `Load` to restore settings instantly.
![PuTTY Settings](./ch03-img02-putty-settings.png)
![Configure PuTTY](./ch03-img02-putty-settings.png)
3. I suggest setting `keepalive` to `60` seconds in the `Connection` to prevent SSH from automatically disconnecting after a period of inactivity. Be sure to save the settings again.
3. I suggest setting `Seconds between keepalives` under `Connection` to `60`. This prevents SSH from automatically disconnecting due to inactivity. **Make sure to save your session settings again.**
![Prevent frequent disconnection](./ch03-img03-putty-keepalive.png)
![Prevent frequent disconnections](./ch03-img03-putty-keepalive.png)
::: warning Attention
Any update to the PuTTY configuration needs to be manually saved to the session again. Otherwise, it will be lost after closing.
::: warning Note
Any setting updates in PuTTY must be manually saved to the Session again, otherwise, they will be lost when you close the program.
:::
4. Click on Open to enter the SSH connection window, then enter the username and password corresponding to the following figure to establish a connection with your VPS remote host. (This article assumes that the default username is `root`. Also, when entering a password in the Linux system, there will be no prompt like `******`, which can avoid password length leakage. It's not that your keyboard is broken!)
1. Click `Open` to enter the SSH connection window. Enter your username and password as shown below to connect to your VPS. (This article assumes the default username is `root`. Also, when typing passwords in Linux, **no asterisks `******` will appear**. This prevents password length leakage—your keyboard isn't broken!)
![SSH Remote Login](./ch03-img04-ssh-login.png)
![SSH Remote Login](./ch03-img04-ssh-login.png)
## 3.2 Successfully Logging in SSH! Introduction to Command Line Interface!
## 3.2 Successfully Logged into SSH! Meet the Command Line Interface
1. If you have filled in your information correctly, you will see a similar interface as the picture below, indicating that you have successfully logged in:
1. If you entered everything correctly, you will see a screen similar to the one below, indicating a successful login:
![Logging in to VPS for the first time](./ch03-img05-ssh-login-success.png)
![First Login to VPS](./ch03-img05-ssh-login-success.png)
This interface is equivalent to the "desktop" of a remote server, but it does not have familiar icons and a mouse, nor does it have colorful graphics. Instead, all you see is simple text. This is the "**Command Line Interface**" - shortened as `CLI`.
This interface is the remote server's [Desktop], but without the icons, mouse, or colorful graphics you are used to. It's just simple text. This is the **Command Line Interface** (CLI).
All the following operations require you to act like a hacker in a movie and complete them in this command-line interface. Maybe you will feel unfamiliar, but please believe me, using the command-line interface is neither scary nor mysterious. In the end, it just turns your familiar mouse operations into textual commands, **you say it, it does it**.
All subsequent operations require you to work in this interface, just like a hacker in the movies. It might feel strange, but trust me, the command line is neither scary nor mysterious. Ultimately, it just turns your mouse clicks into text commands: **You say it, it does it**.
2. Now, you can observe and familiarize yourself with the command line environment a little bit. This interface has actually provided you with some useful information, such as the system kernel version (e.g. `4.19.37-5` in the picture), last login time and IP address. Of course, depending on the VPS, the interface you see may be slightly different.
2. Now, look around and get familiar with the CLI environment. This interface actually tells you some useful info, like the system kernel version (e.g., `4.19.37-5` in the image), last login time, and IP. Of course, depending on your VPS, what you see might differ slightly.
3. Please pay attention to the line at the bottom of the command line, to the left of the flashing cursor, there is a string of characters. The one shown in the figure is `root@vps-server:~#`. How to understand this string? It's very simple:
3. Pay attention to the last line, to the left of the flashing cursor. There is a string of characters. In the image, it shows `root@vps-server:~#`. How should you understand this? Simple:
- The current user is `root`
- The server `root` is on is `vps-server`
- The folder `root` is currently in is `~`
- The `#` indicates where you can type commands
- The current user is `root`
- The server where `root` is located is `vps-server`
- The current directory where `root` is located is `~`
- After `#` is the place where you can input commands.
The first two are intuitive. The third is about the Linux file system; for now, just know that "`~`" is the [Current User's Home Base]. The fourth, the prompt `#`, doesn't need much thought. Just know that in future articles, commands you need to type will start with `#` or `$`, indicating **where** you start typing. (So when copying commands, **only copy the content after this symbol**, do not copy the prompt itself.)
The first two are pretty straightforward, no need to explain further. The third one is about the folder system in Linux. You don't need to go too deep into it for now. Just know that "`~`" represents **the home directory of the current user**. As for the fourth one, the prompt symbol "`#`", you don't need to worry about it either. Just know that in future articles, there will be some commands that you need to input, and they will be preceded by "`#`" or "`$`" to indicate **where you should input the command**. (So when you copy the command, **just copy the content after the prompt symbol** and don't copy the prompt symbol itself.)
## 3.3 Updating Linux Software for the First Time
## 3.3 Updating software on Linux for the first time!
1. Just like your phone (Android or iPhone) checks the App Store for updates (security patches and new features), Linux has a very similar update logic. If you can update apps on your phone, you can update Linux software!
1. Just like your phone, whether it's Android or iPhone, in order to keep your apps up-to-date (to get security patches and new features), you will occasionally receive update notifications from the app store, telling you how many apps need to be updated. Linux systems also have a similar update mechanism that works logically. So as long as you know how to update phone apps, you can learn how to update Linux software!
2. In Linux, every app is called a "package". The program that manages apps is naturally called the "Package Manager". You can install, update, and uninstall software, or even update the Linux system itself through it. The package manager is powerful, but for now, you only need to know that the Debian system's manager is called `apt`. Next, let's use `apt` to perform a full software update to get familiar with it.
2. In Linux, each application is called a "package". The program that manages the applications is naturally called a "package manager". You can use it to install, update, and uninstall various software, and even update the Linux system itself. Package managers in Linux are very powerful, but we won't go into details here. For now, you only need to know that the package manager for the Debian system is called `apt`. Next, we will first use `apt` to do a comprehensive update of the software to familiarize you with its basic operations.
3. Basic Linux commands for beginners:
3. Tiny White Linux Basic Commands:
| Code | Command Name | Description |
| :---: | :---: | :---: |
| `cmd-01` | `apt update` | Check for software updates |
| `cmd-02` | `apt upgrade` | Execute software updates |
| Number | Command Name | Command Description |
| :------: | :-----------: | :----------------------: |
| `cmd-01` | `apt update` | Query software updates |
| `cmd-02` | `apt upgrade` | Perform software updates |
4. Now enter the first command to fetch update information:
4. Now, please enter the first command to get update information.
```shell
apt update
```
```shell
apt update
```
5. Then enter the second command. When asked whether to continue `(Y/n)`, type `y` and hit Enter to start the installation:
This is a command used in a Linux terminal to update the package list from the repositories configured on the system.
```shell
apt upgrade
```
5. Then enter the second command, and when asked if you want to continue installing `(Y/n)`, type `y` and press enter to confirm and start the installation.
6. The complete process is demonstrated below:
```shell
apt upgrade
```
This is a command in the shell terminal to upgrade the installed packages on a Debian or Ubuntu Linux system.
6. The complete demonstration of the process is as follows:
![Demonstration of the software update process for the first time](./ch03-img06-apt-upgrade-full.gif)
![First Software Update Demo](./ch03-img06-apt-upgrade-full.gif)
## 3.4 Your Progress
**Congratulations on taking another solid step!** Now, you can log in to your remote server via SSH! After logging in, besides upgrading the software, what else should you do? Please enter the next chapter to find out!
**Congratulations on taking another solid step!** Now, you can log in to your remote server via SSH! After logging in and updating software, what should you do next? Head to the next chapter to find out!
> ⬛⬛⬛⬜⬜⬜⬜⬜ 37.5%
docs/en/document/level-0/ch04-security.md
+265 -297
View File
@@ -1,351 +1,319 @@
# [Chapter 4] Security and Protection
# [Chapter 4] Security Protection
## 4.1 Why Do We Need Security Protection?
## 4.1 Why Security Protection is Necessary
Security protection for Linux servers is a complex and huge subject. Countless websites, apps, services, and even offline infrastructure are built on the foundation of Linux, which involves huge economic benefits and commercial value. This also means that there is a huge motivation for black and gray industries to launch attacks. However, these services are so important that major security vulnerabilities are not allowed. Therefore, countless operation and maintenance professionals are working hard on the battlefield of security attacks and defense, which enables us to enjoy a basic stable modern digital life.
Security protection for Linux servers is a vast and complex topic. Countless websites, apps, services, and even offline infrastructure are built upon the foundation of Linux. Behind this lies enormous economic interest and commercial value, which naturally implies that the black/gray market has a huge motivation to attack. However, these services are so critical that major security vulnerabilities simply cannot be allowed. Consequently, countless operations professionals strive on the battlefield of security offense and defense, allowing everyone to enjoy a basically stable modern digital life.
Now, you have a VPS and will open its data access channel to achieve the goal of traffic forwarding, which means you are now on the front line of the security battle and face all risks. However, at the same time, newcomers tend to have a polarized view of security issues due to lack of knowledge and information: either they feel it is as light as a feather and has nothing to do with them, or they feel it is as heavy as Mount Tai and feel anxious all day long.
Now that you own a VPS and will be opening up its data access channels to achieve traffic forwarding, you have effectively placed yourself on the front lines of this security battlefield, facing all risks directly. However, due to a lack of knowledge and information, newcomers often view security issues with polarized attitudes: they either feel it's trivial and has nothing to do with them, or they feel the weight is unbearable and live in constant fear.
- For the former, my suggestion is: safety is of utmost importance. Try to gather more information on safety issues to avoid regretting after experiencing losses.
* **For the former**, my advice is: No security matter is too small. Try to research security information as much as possible to avoid regretting it only after you have suffered a loss.
* **For the latter**, my advice is: Don't panic. Our servers generally don't hold high value and won't attract high-level targeted attacks. We mostly face malicious scanning and login attempts by automated scripts. Just follow this article to implement basic protections.
- For the latter, my suggestion is: don't worry too much, our servers still don't have too much value and generally won't attract high-level attacks. The basic threats we need to face are mostly malicious scans and login attempts from some automated scripts. Just follow this article to do some basic protection.
## 4.2 What Exactly Are the Specific Risks?
## 4.2 What are the specific risks
Just as we configured in the "Remote Login" chapter, anyone only needs to know four elements—**[IP Address] + [Port] + [Username] + [Password]**—to log into your VPS server. Obviously, the security of these four elements is the baseline we need to protect. Let's analyze them one by one:
Just like the configuration we did in the "Remote Login" section, anyone who knows the four elements of [IP address] + [port] + [username] + [password] can log in to your VPS server. So obviously, the security of these four elements is the bottom line that we need to protect. Let's analyze them one by one:
1. **[IP Address]**: Malicious scripts randomly attempt and scan IP ranges. You can simply consider this public information; it cannot be hidden.
2. **[Port]**: If using the default port, then **[Port = `22`]**.
3. **[Username]**: If using the default user, then **[Username = `root`]**.
4. **[Password]**: There is no default password; it is definitely randomly generated by the VPS backend or set by you. This means if your server uses default settings, three of the four elements are already known. The security of your entire server relies entirely on a small string of passwords. Here are a few scenarios:
* If you use the random password generated by the VPS panel, it usually contains a dozen mixed-case letters and symbols, which is relatively safe.
* If, for the sake of memory, you changed the password to something ultra-weak like `123456`, cracking your VPS server would be effortless.
* If, for the sake of memory, you changed the password to something complex but used elsewhere, it is essentially unsafe. You must understand that hackers have "cheat sheets," such as **Password Dictionaries**, containing tens of thousands to millions of leaked real passwords.
1. [IP Address]: Malicious scripts randomly attempt to scan IP ranges, which can be regarded as public information and cannot be hidden.
5. **But you must understand**, no hacker is actually sitting in front of a computer trying your password one by one. All attack attempts are carried out automatically by malicious scripts working 24/7. Perhaps while you are sound asleep, your server is enduring round after round of impacts.
2. [Port]: If you are using the default port, then [Port = `22`].
Once the password is successfully brute-forced, it means all your four elements are mastered by the attacker. The malicious script will quickly log in, obtain the highest `root` control of the server, install/deploy its malicious services, and then use your server to do various bad things 24 hours a day (such as mining, spreading viruses, sending spam/phishing emails, acting as a BT relay, or even becoming a public node for the dark web, etc.). If the malicious script is restrained, it can be quite stealthy. Since newcomers generally don't observe VPS login records, process changes, CPU usage, or traffic changes, it is difficult to discover that you have been hacked until your VPS provider bans your account or you receive a lawyer's letter.
3. [Username]: If using the default user, then [Username = `root`]
6. **Don't forget**, you likely used real payment information to obtain the VPS, and you leave your IP address when logging into various websites and social platforms. These are directly or indirectly related to your identity. **Once these bad things happen, they will inevitably be linked to you.**
4. [Password]: There is no default value for the password. It must be randomly generated by the VPS backend or set by you. In other words, if all the settings of your server are default, then three of the four elements are already known. Therefore, the security of your entire server relies on a small password. In this case, there are several situations:
## 4.3 What Security Protections Will We Implement?
- If you use a VPS management background to generate passwords randomly, it usually contains random uppercase and lowercase letters, symbols, and is relatively secure.
Based on the analysis above, what we need to do is naturally strengthen the **[Port]**, **[Username]**, and **[Password]** elements to reduce the risk of being breached:
- If you changed your password to something super weak like `123456` just for the sake of easy memorization, hacking into your VPS server would be a piece of cake.
1. **[Port]**: Change the SSH remote login port to a **[Non-22 Port]** (Section 4.4).
2. **[Username]**: Create a **[Non-root]** new user and disable root SSH remote login (Sections 4.5, 4.6).
3. **[Password]**: Enable SSH RSA key authentication and disable password authentication (Section 4.7).
- If you change your password to a more complex one that you have used elsewhere just for the sake of easy memory, it is not really safe. You should understand that hackers have cheats in their hands, such as `password tables`, which contain tens of thousands, hundreds of thousands, millions, or even more real leaked passwords.
Remember to follow the order so you don't lock yourself out.
5. But you should understand that no hacker really sits in front of a computer and tries your password repeatedly. All attack attempts are carried out automatically by malicious scripts, which work tirelessly for 24 hours. Perhaps while you are sleeping soundly every night, your server is enduring round after round of attacks.
## 4.4 Change SSH Remote Login Port to Non-22 Port
Once the password is successfully cracked, it means that all four of your elements have been mastered by the attacker. The malicious script will quickly log in to the server, obtain the highest `root` control of the server, install and deploy its malicious services, and then use your server to do all kinds of bad things 24 hours a day (such as mining, spreading viruses, sending spam emails, fraudulent emails, acting as a BT relay, and even dark web public nodes, and so on). If the malicious script is relatively restrained, it can actually achieve considerable concealment. Generally, newcomers will not observe and pay attention to indicators such as login records, process changes, CPU usage changes, and traffic changes of the VPS, so it is difficult for you to discover that you have been hacked. Until your VPS service provider blocks your account or you receive a lawyer's letter.
Now, let's solve the **[Port = `22`]** issue. (Note: Some VPS providers already use a non-22 port by default. You can skip this step or follow along to change it to another port).
6. Don't forget that when you obtain a VPS, you probably need to use your real payment information, and when you log in to various websites and social platforms, your IP address will also be recorded, which has a direct or indirect relationship with your identity. Therefore, once these bad things happen, they will inevitably be associated with you.
1. **Newbie Linux Basic Commands:**
## 4.3 What security measures do we need to take
| ID | Command Name | Command Description |
| :---: | :---: | :---: |
| `cmd-03` | `nano` | Text Editor |
| `cmd-04` | `systemctl restart` | Restart a specific service |
Based on the above analysis, what we need to do is to strengthen the three elements of [port], [username], and [password] to reduce the risk of being hacked.
2. **Newbie Linux Basic Configuration Files:**
1. [Port]: Modify the SSH remote login port to a [non-22 port] (4.4).
2. [Username]: Create a [non-root] new user and disable root user SSH remote login (4.5, 4.6).
3. [Password]: Enable RSA key verification for SSH login and disable password verification login (4.7).
| ID | Config File Location | File Description |
| :---: | :---: | :---: |
| `conf-01` | `/etc/ssh/sshd_config` | SSH Remote Login Program Settings |
Remember to follow the order and don't lock yourself out.
3. The first thing we need to do is **[Use the `nano` text editor to open the `SSH Remote Login Program Settings`]**. In Windows, you would "find the file and double-click it." What about in Linux? Look at the command description above; isn't it simple? That's right, it is:
## 4.4 Change the SSH Remote Login Port to a Non-22 Port
```shell
nano /etc/ssh/sshd_config
```
Now, let's solve the problem of "port = `22`". (Note: some VPS service providers have non-22 ports set as default, so you can ignore this step if that's the case. Of course, you can also follow this article to change it to another port.)
4. After the file opens, you enter the `nano` interface. Observe briefly, and you'll find that it displays important shortcut keys at the bottom of the screen (in the red box below). It's like an open-book exam; no need for rote memorization. Isn't that thoughtful?
1. Basic commands of Little White Linux:
![nano interface](./ch04-img01-nano-ui.png)
| ID | Command Name | Description |
| :------: | :-----------------: | :---------------: |
| `cmd-03` | `nano` | Text editor |
| `cmd-04` | `systemctl restart` | Restart a service |
5. The second thing we need to do is **[Find `Port` in the opened file and modify its port number]**. The number after `Port` is the SSH port. It is generally recommended to change it to an integer greater than `1024` and less than `65535` (this article uses `9753` as an example). Combining with `nano` shortcuts, how should we operate? As expected, you got it right again!
* Use `ctrl+w` to enter search mode, then type `Port 22` and hit Enter.
* Delete `22` and change it to `9753`.
* **Note:** If the line starts with a `#`, it means this line is **[Not Effective]** (commented out). You can write a new one without `#` at the end of the file like I did, or just delete the `#`.
2. Basic Configuration Files of Little White Linux
::: warning
Using `9753` as an example in this article means that with the release of this article, this port will become a minor characteristic. It might be prioritized by attackers or interfered with/blocked by the GFW. Therefore, I strongly suggest you use a different port number you come up with yourself. After all, you have over 60,000 ports to choose from freely.
:::
| Number | Configuration File Location | File Description |
| :-------: | :-------------------------: | :-------------------------------: |
| `conf-01` | `/etc/ssh/sshd_config` | SSH Remote Login Program Settings |
6. The third thing we need to do is **[Save the file and exit]**.
* If you observed carefully in step 3, you'd notice that save isn't the common `ctrl+s`.
* **Correct Shortcuts:** Save is `ctrl+o` + `Enter`, Exit is `ctrl+x`.
* **(Some Operating Systems)** Add a firewall rule for the new SSH port; otherwise, you won't be able to login via SSH after the instance restarts.
* Example for Ubuntu `ufw`:
3. The first thing we need to do, of course, is to [open the SSH remote login program settings with the text editor `nano`]. In Windows, you will [find the file and double-click] it. What should you do in Linux? Take a close look at the command instructions above, isn't it simple? Yes, it is:
```shell
sudo ufw allow 9753/tcp
```
```shell
nano /etc/ssh/sshd_config
```
7. The final thing to do is **[Restart the SSH service to make changes take effect]**:
This is a command in the shell terminal to open the `sshd_config` file located in the `/etc/ssh/` directory using the `nano` text editor.
```shell
systemctl restart ssh
```
4. Once the file is opened, you will enter the interface of `nano`. After observing for a while, you will find that it displays important shortcut keys at the bottom of the screen (enclosed in a red box in the figure below). You can take the exam directly without memorizing them, which is very user-friendly, isn't it?
*Then try to open a new session in your SSH software to see if you can connect. If there are issues, you can modify the configuration via the old SSH session (the SSH session that was already open when sshd restarted will not be closed).*
![Interface of nano](./ch04-img01-nano-ui.png)
8. Full process demonstration:
5. The second thing we need to do is to **find the `Port` item in the opened file and modify its port**. The number after `Port` is the SSH port. It is generally recommended to change it to an integer greater than `1024` and less than `65535` (this article takes `9753` as an example). Please think about how to operate it with the shortcut keys of `nano`. You are right again! It is:
![Changing port demonstration](./ch04-img02-sshd-conf-full.gif)
- Use `ctrl+w` to enter search mode, then type `Port 22` and press Enter
- Delete `22` and replace it with `9753`
- Note: If this line starts with `#`, it means that this line is [commented out] and [does not take effect]. You can write a new line at the end of the file without `#`, or delete the `#` to enable this line.
9. **Modify PuTTY Configuration**
Now that the new port is effective, you must use `9753` the next time you log in with PuTTY. So, please go to PuTTY settings, change the port number, and **Save Session**. You know where to change it, right? (If not, re-read the previous content!)
## 4.5 Create a Non-root New User
Step two, let's solve the **[Username = `root`]** issue.
First, you need to understand that `root` in a Linux system is not just a simple administrator account. It is the **foundation** of the entire system, the master, the supreme god. Once the `root` account has a security issue, the entire system is at the mercy of others with nowhere to run. So follow me to operate:
1. **Newbie Linux Basic Commands:**
| ID | Command Name | Command Description |
| :---: | :---: | :---: |
| `cmd-05` | `adduser` | Add a user to the system |
| `cmd-06` | `apt install` | Install specific software |
| `cmd-07` | `visudo` | Dedicated editor for modifying sudo permissions |
2. The first thing to do is **[Add a new user and set a login password]**. You can name it whatever you want; I will use `vpsadmin` as an example:
```shell
adduser vpsadmin
```
After executing the command, follow the prompts. **Be sure to set a user password** (don't forget that you won't see `******` when typing the password). Afterward, the system will ask for some additional user info; you can ignore these and just keep hitting Enter.
![Create new user](./ch04-img03-adduser.png)
::: warning
Using `vpsadmin` as an example means this username will also become a minor characteristic upon this article's release. Like the port, I strongly suggest you use a different username you create yourself.
:::
3. Full process demonstration:
![Create new user demonstration](./ch04-img04-adduser-full.gif)
4. The second thing to do is **[Install the `sudo` function]** (`sudo` allows a standard account to temporarily gain the power of `root` at critical moments to save the world).
```shell
apt update && apt install sudo
```
Smart users may have noticed this line is actually two commands. The first half `apt update` you've seen and used before; it refreshes software version info. The latter `apt install` is the **[Install Command]**. Joined by `&&`, it means [Refresh available software, AND THEN install the latest version of the `sudo` program].
5. The third thing to do is **[Add the `vpsadmin` user to the `sudo` list, granting them eligibility to borrow `root` powers]**.
```shell
visudo
```
Under `User Privilege Specification`, add a line: `vpsadmin ALL=(ALL) NOPASSWD: ALL`.
::: warning
I want to specifically explain the `NOPASSWD` setting. It means the `vpsadmin` user does not need to enter an extra password when using `root` privileges. **This is contrary to general security advice.** The reason I recommend this is that many newcomers ignore danger and persist in using the `root` account simply because they find repeatedly entering passwords annoying. Weighing the lesser of two evils, I believe **[The risk of using the `root` user directly]** is greater than **[The risk of not entering a password when using `sudo`]**, hence the recommendation.
If you prefer to follow tradition and enter a password every time you use `sudo`, change that line to `vpsadmin ALL=(ALL:ALL) ALL`.
:::
6. Full process demonstration:
![Sudo config demonstration](./ch04-img05-sudo-full.gif)
## 4.6 Disable Root SSH Remote Login
1. Now you are getting familiar with Linux, so let's have you think: what is the first thing we need to do? Correct, it is still **[Use the `nano` editor to open `SSH Remote Login Program Settings`]**. What? Can't remember how? Go review the content above and come back! ... Correct Answer:
```shell
nano /etc/ssh/sshd_config
```
2. Find the `PermitRootLogin Yes` item, and change its setting to `no`. Remember how? ... Correct Answer:
* Use `ctrl+w` to enter search mode, type `PermitRootLogin`, and Enter.
* Delete `yes` and change it to `no`.
3. Save the file and exit. Remember how? ... Correct Answer:
* Save is `ctrl+o`, then `Enter` to confirm.
* Exit is `ctrl+x`.
4. Restart the SSH service to make changes take effect. Remember... Never mind, here is the answer:
```shell
systemctl restart ssh
```
5. Full process demonstration:
![Disable root login demonstration](./ch04-img06-ssh-no-root-full.gif)
6. Next time you log in via PuTTY, the `root` user will no longer connect; you must switch the username to `vpsadmin`! For convenience, set `vpsadmin` as the default login username in PuTTY. (Nagging Note: Don't forget to Save Session).
![PuTTY default user](./ch04-img07-putty-default-user.png)
## 4.7 Use RSA Key Login and Disable Password Login
Step three, let's solve the problem of the **[Password]** potentially being brute-forced.
As mentioned earlier, hackers don't stupidly try every combination; they use cheat methods like "password dictionaries." Unless you use a randomly generated ultra-long password (via 1Password, macOS Keychain, etc.), you are easily vulnerable.
While ultra-long random passwords improve security, they are basically impossible to memorize and tedious to type manually. To solve this dilemma, we can abandon **[Password Authentication]** and switch to the more secure **[Key Authentication]**.
**[Key Authentication]** involves generating a **[Pair]** of related key files (Public Key and Private Key). You upload the **[Public Key]** to the VPS. Every time you log in, SSH matches the **[Public Key]** with the **[Private Key]**. If the validation confirms it is the correct **[Key Pair]**, authentication passes. (In other words, you don't need to remember or type complex passwords; you just need to protect the **[Private Key]** file from leaking).
::: warning
This article uses `9753` as an example, which means that with the release of this article, this port will become a feature that may be prioritized or blocked by attackers or the Great Firewall of China. Therefore, I strongly recommend that you use another port that you come up with yourself, after all, you have over 60,000 ports to choose from freely.
:::
6. The third thing we need to do is to [save the file and exit].
- If you observed carefully in step 3, you would have noticed that saving is not done by the common `ctrl+s`.
- The correct shortcut keys: save is `ctrl+o` + `enter`, and exit is `ctrl+x`.
- (For some operating systems) Add a firewall rule to set the new SSH port, otherwise, you won't be able to log in via SSH after the instance restarts.
- For example, on Ubuntu using ufw.
```shell
sudo ufw allow 9753/tcp
```
7. The last thing we need to do is to [restart the SSH service to make the changes take effect].
```shell
systemctl restart ssh
```
Then you can try opening a new session in your SSH software to check if you can connect. If there are any issues, you can modify the configuration through the old SSH session (SSH connections that are already open will not be closed when restarting sshd).
8. The complete process demonstration is as follows:
![Demonstration of modifying non-22 port](./ch04-img02-sshd-conf-full.gif)
9. Modify PuTTY Configuration
"Now that the new port is in effect, you will need to use `9753` the next time you log in with PuTTY. So please go to the PuTTY settings to change the port number and save the session. Well, you should know where to change it, right? (If you don't know, you need to reread the previous content!)"
## 4.5 Creating a New User Without Root Access
In the second step, let's solve the issue of the username being `root`.
Firstly, you need to understand that `root` in Linux system is not just a simple administrator account. It is the foundation of the entire system, the ruler and the supreme god of the system. Once the `root` account has security issues, the entire system will be vulnerable and there will be nowhere to hide. So, let's follow me to carry out the operations:
1. Little White Linux Basic Commands:
| Number | Command Name | Command Description |
| :------: | :-----------: | :-----------------------------------------------: |
| `cmd-05` | `adduser` | Add new user to the system |
| `cmd-06` | `apt install` | Install a software package |
| `cmd-07` | `visudo` | Special editor to modify sudo permission settings |
2. The first thing we need to do is to [add a new user and set a login password]. You can choose any name you want, here I will use `vpsadmin` as an example:
```shell
adduser vpsadmin
```
This is a command in the shell terminal to add a new user named "vpsadmin".
After executing the command, follow the prompts to operate. Be sure to set a user password (remember that you won't see `******` when setting the password). Afterwards, the system will ask you for some additional user information, which can be ignored by pressing Enter all the way.
![Creating a new user](./ch04-img03-adduser.png)
::: warning
This article takes "vpsadmin" as an example, which means that with the release of this article, this username will also become a significant feature, and may be the first choice for attackers to try. Therefore, just like ports, I strongly recommend that you use another username that you come up with yourself.
:::
3. The complete process demonstration is as follows:
![Creating a new user](./ch04-img04-adduser-full.gif)
4. The second thing we need to do is to install the `sudo` function (which allows ordinary accounts to temporarily obtain the power of `root` at critical moments and unleash their full power to save the world).
```shell
apt update && apt install sudo
```
This is a shell command to update the package list and install the "sudo" package.
You may have noticed that this command actually consists of two commands. The first half, `apt update`, you have seen and used before, is to refresh the software version information on the server. The latter half, `apt install`, is the installation command that will be used this time. The two commands are connected together to instruct the system to refresh the latest available software and then install the latest version of the `sudo` program. `&&` is used to link the two commands together for execution.
5. The third thing we need to do is to add the `vpsadmin` user to the `sudo` list, so that they have the privilege to borrow the power of `root`.
```shell
visudo
```
(Note: `visudo` is a command used in Linux/Unix systems to edit the sudoers file, which specifies which users or groups are allowed to run certain commands with administrative privileges.)
Simply add the following line under `User Privilege Specification`: `vpsadmin ALL=(ALL) NOPASSWD: ALL`.
::: warning
I want to specifically explain the setting of `NOPASSWD`. It means that when the `vpsadmin` user temporarily uses the `root` permission, no additional password needs to be entered. This is contrary to general security recommendations. The reason why I recommend this is that many newcomers insist on using the `root` account because they feel relaxed when using `root` without repeatedly entering passwords. "Choosing the lesser of two evils," I believe that the risk of [directly using the `root` user] is greater than the risk of [not entering a password when using `sudo`], so I made the above suggestion.
If you want to follow the traditional practice and enter a password every time you use `sudo`, then you can change this line to `vpsadmin ALL=(ALL:ALL) ALL`.
6. The complete process demonstration is as follows:
![Creating a new user](./ch04-img05-sudo-full.gif)
## 4.6 Disabling SSH Remote Login for Root User
1. Now that you're gradually getting familiar with Linux, it's time for you to think. What's the first thing we need to do? That's right, it's still to use the `nano` editor to open the `SSH remote login program settings`. What? You can't remember how to do it? Then go back and review the content above and come back! ............ Correct answer:
```shell
nano /etc/ssh/sshd_config
```
This is a command line instruction to open and edit the `sshd_config` file located at `/etc/ssh/` using the `nano` text editor.
2. Find the line `PermitRootLogin Yes`, and change the value after it to `no`. Do you remember how to do it? ............ Correct answer:
- Use `ctrl+w` to enter search mode, then enter `PermitRootLogin` and press enter.
- Delete `yes` and change it to `no`.
3. Save the file and exit. Do you remember how to do it? ............ Correct answer: N/A (The correct answer is not provided in the given text.)
- Save is `ctrl+o`, then press `Enter` to confirm.
- Exit is `ctrl+x`.
4. Restart the ssh service to make the changes take effect. Do you remember...? Never mind, let's just reveal the correct answer:
```shell
systemctl restart ssh
```
(This is a Linux shell command to restart the SSH service.)
5. The complete process is demonstrated as follows:
![Disable SSH remote login for root user](./ch04-img06-ssh-no-root-full.gif)
6. Next time you log in remotely via SSH using PuTTY, you will no longer be able to connect as the `root` user. You will need to use the username `vpsadmin` instead. For convenience, you can set `vpsadmin` as the default login username in PuTTY. (Tip: Don't forget to save the session.)
![PuTTY Setting Default User Name](./ch04-img07-putty-default-user.png)
## 4.7 Login with RSA Key and Disable Password Login
In the third step, we will solve the problem of the password being cracked.
As mentioned earlier, hackers are not foolish enough to crack your password by brute force, but rather they use cheating methods such as "password tables". Unless you use a randomly generated super long password (such as with 1Password, or macOS keychain and other password management tools), it's easy to fall victim to this.
Although a very long random password can improve security, it is usually difficult to remember and manually enter, which can also lead to mistakes. To solve this problem, we can simply abandon the "password verification" method and switch to a more secure "key verification" method.
The so-called "key authentication" refers to generating a pair of related key files (public key and private key), uploading the "public key" to the VPS for backup. Each time you log in, SSH will match the "public key" and "private key". If the verification is correct, the "key pair" will be verified and the authentication will pass. (In other words, you don't need to remember and enter complex passwords, just protect the "private key" file from being leaked.)
::: warning
This article uses `RSA` keys as an example because `RSA` keys have a long history of support in various devices and `SSH` clients and can still provide sufficient security. However, it is not the only choice available.
This article uses `RSA` keys as an example because `RSA` has a long history of support across various devices and SSH clients, and it currently provides sufficient security. However, it is by no means the only choice.
Other common keys include:
- `DSA` - It has been mathematically proven to be insecure, so never use it.
- `ECDSA` - It has high security with small keys, but its algorithm is suspected to have a backdoor by the NSA. If there is something on your VPS that is worth the attention of the NSA, do not use it.
- `Ed25519` - This is an algorithm that is very similar to `ECDSA`, and it has similar performance advantages. At the same time, all of its documentation is public, so it is generally considered to be free of backdoors.
* `DSA` - Mathematically proven insecure. Never use it.
* `ECDSA` - Small key size, high security, but its algorithm is suspected of having an NSA backdoor. If you have things on your VPS the NSA cares about, don't use it.
* `Ed25519` - An algorithm very similar to `ECDSA` with similar performance benefits. Its documentation is fully public, so it is generally considered backdoor-free.
So, if your device and software both support it, I recommend choosing `Ed25519` keys as a priority.
Therefore, if your devices and software support it, I recommend prioritizing `Ed25519` keys.
:::
Now let's configure the [Key Authentication]!
Now, let's configure **[Key Authentication]**!
1. Run `PuTTYgen` (PuTTY Key Generator). The location is `Start Menu` --> `All Programs` --> `PuTTY (64-bit)` --> `PuTTYgen`.
1. Run `PuTTYgen` (PuTTY Key Generator). Location: `Start Menu` --> `All Programs` --> `PuTTY (64-bit)` --> `PuTTYgen`.
1. Click `Generate` to start (move your mouse randomly in the blank area to increase randomness).
1. Click on `Generate` to start the generation process (move the mouse randomly in the blank area of the interface to add random numbers).
![Generate key](./ch04-img08-puttygen-save.png)
![Generate Key](./ch04-img08-puttygen-save.png)
::: warning
The image uses a `2048` bit `RSA` key as an example. However, to achieve security equivalent to `ECDSA/Ed25519` `256` bit keys, you need to use a `3072` bit `RSA` key (change the number in the bottom right to `3072`).
:::
1. You can set a password for the private key to add a layer of security.
2. Click `Save public key` to save the public key, name it `id_rsa.pub`.
3. Click `Save private key` to save the private key, name it `id_rsa` (PuTTY private keys come with a `.ppk` extension).
4. **Most Importantly:** Scroll down and copy **all** the content in the red box above, save it as a file named `authorized_keys`. (Saving with vscode might default to a `.txt` extension; that's fine, we will remove the extension when uploading to VPS).
![Save key content](./ch04-img09-puttygen-save-keys.png)
2. **Upload the public key to the `vpsadmin` user on the VPS.**
1. This step requires `WinSCP` which we prepared earlier.
2. Download and install from the [official site](https://winscp.net/eng/index.php). It will prompt you to import PuTTY settings; do it!
![Import session](./ch04-img10-winscp-import-session.png)
3. If it doesn't prompt or you installed it earlier, configure it as shown below.
![WinSCP login](./ch04-img11-winscp-ui.png)
4. The left directory in WinSCP is your local computer; locate the folder where your keys are.
5. The right directory in WinSCP is the VPS. Default is `/home/vpsadmin/`. Click `X hidden` in the bottom right to show hidden files.
![Local and Remote folders](./ch04-img12-winscp-locations.png)
6. Right-click on the right side (VPS) and create a new folder named `.ssh` (Note the dot `.`).
![Create .ssh folder](./ch04-img13-winscp-newfolder-key.png)
7. Upload the **[Public Key]** `authorized_keys` into the `.ssh` folder.
![Upload key](./ch04-img14-winscp-upload-key.png)
8. During upload (or after), rename `authorized_keys.txt` to `authorized_keys` (remove the `.txt` extension).
![Rename key](./ch04-img15-winscp-rename-key.png)
9. Full process demonstration:
![WinSCP full demo](./ch04-img16-winscp-full.gif)
3. **Configure VPS to Enable RSA Key Login and Disable Password Login.**
1. **Newbie Linux Basic Commands:**
| ID | Command Name | Command Description |
| :---: | :---: | :---: |
| `cmd-08` | `sudo` | Run a command with `root` privileges |
| `cmd-09` | `chmod` | Change permissions of target file/folder |
2. Remote SSH into your VPS (PuTTY).
3. Change permissions of `authorized_keys` to `600` (Read/Write for owner only).
```shell
chmod 600 ~/.ssh/authorized_keys
```
4. Modify SSH Configuration. We've done this many times, but now we are the normal user `vpsadmin`, not the omnipotent `root`. We don't have permission to edit SSH config directly. We need the `sudo` command:
```shell
sudo nano /etc/ssh/sshd_config
```
5. Find (`ctrl+w`) `PasswordAuthentication` and change it to `no`.
6. Find (`ctrl+w`) `PubkeyAuthentication` and change it to `yes`. Save (`ctrl+o`) and Exit (`ctrl+x`).
7. Restart SSH service. (Nagging Note: Don't forget you need `sudo` for permission now).
```shell
sudo systemctl restart ssh
```
8. Full process follows:
![Disable password login full demo](./ch04-img17-rsa-login-full.gif)
4. **Configure PuTTY to use the Private Key.**
The VPS side has the public key. Now specify the private key location for PuTTY to use during login (Nagging Note: Don't forget to Save Session).
![PuTTY private key](./ch04-img18-putty-privatekey-location.png)
5. At this point, **[Key Login]** is enabled, **[Password Authentication]** is disabled, and PuTTY has the default username and private key saved. In the future, just load the `VPS-SERVER` config in PuTTY and click `Open` for one-click login.
If you set a password for your private key, you will need to enter that passphrase to unlock the key when logging in, as shown below:
![Private key passphrase](./ch04-img19-putty-privatekey-passphrase.png)
6. Don't forget to configure the key for `WinSCP` as well, otherwise, you won't be able to log in to transfer files later:
![WinSCP private key](./ch04-img20-winscp-privatekey-location.png)
::: warning
The example in this image is based on a `2048`-bit `RSA` key. However, in reality, if you want to achieve the same level of security as a `256`-bit key for `EDCSA/Ed25519`, you need to use a `3072`-bit `RSA` key. (i.e., change the number in the bottom right corner to `3072`)
:::
2. You can add a password to your private key to increase security.
3. Click on `Save public key` to save the public key with the file name `id_rsa.pub`.
4. Click on `Save private key` to save the private key with the file name `id_rsa` (PuTTY private keys come with the `.ppk` extension).
5. Most importantly, copy and save all the content inside the red box below by scrolling down, with the file name `authorized_keys`. (If you save it using vscode, it will be saved as a text file with a `.txt` extension, which is fine. We will remove the extension when uploading it to VPS later.)
![Save Key](./ch04-img09-puttygen-save-keys.png)
2. Upload the public key to the "vpsadmin" user on the VPS.
1, This step requires the use of the previously prepared `WinSCP`.
2, Go to the [official website](https://winscp.net/eng/index.php) to download and install. It will prompt you to import PuTTY settings, and of course, you can import them with one click!
![One-click Import Session](./ch04-img10-winscp-import-session.png)
3, If there is no prompt for import or you have already installed it in advance, configure it according to the following figure.
![WinSCP login settings](./ch04-img11-winscp-ui.png)
4, The directory on the left side of WinSCP is the folder and files on your local computer. Please locate the folder where the key is stored.
5, The directory on the right side of WinSCP is the folder and files on the VPS server, which are located in the `/home/vpsadmin/` folder by default. To display hidden files, please click on `X hidden` in the lower right corner.
![Local and remote folders](./ch04-img12-winscp-locations.png)
6, Right-click on the right side (in VPS) and create a new folder named `.ssh` (note the period at the beginning).
![Create a folder to place public key in VPS](./ch04-img13-winscp-newfolder-key.png)
7, Upload the [public key] `authorized_keys` to the `.ssh` folder.
![Upload authorized_keys](./ch04-img14-winscp-upload-key.png)
8, When uploading, rename the [public key] from `authorized_keys.txt` to `authorized_keys` (remove the `.txt` extension).
![Ensure there is no file extension](./ch04-img15-winscp-rename-key.png)
9, The complete process demonstration is as follows:
![Complete demonstration of WinSCP operation](./ch04-img16-winscp-full.gif)
3. Enable RSA key authentication for SSH login and disable password authentication login on the VPS side.
- Basic Linux Commands:
| Number | Command | Description |
| :------: | :-----: | :-----------------------------------------------: |
| `cmd-08` | `sudo` | Run a command with `root` privileges |
| `cmd-09` | `chmod` | Change the permissions of a target file/directory |
- SSH remote connection to VPS (PuTTY)
- Change the permission of the `authorized_keys` file to `600` (only the owner can read and write).
```shell
chmod 600 ~/.ssh/authorized_keys
```
This is a command in shell script to change the permissions of the `authorized_keys` file to `600` for the current user's SSH directory (`~/.ssh/`).
4. Modify SSH configuration. We have used this many times, but now that we have changed from the almighty `root` to the ordinary user `vpsadmin`, we do not have the permission to edit SSH configuration directly. At this time, we need to use the `sudo` command:
```shell
sudo nano /etc/ssh/sshd_config
```
(This is a command in the shell/terminal to open the sshd_config file located in the /etc/ssh/ directory with the sudo privilege using the nano text editor.)
5. Find (`ctrl+w`) `PasswordAuthentication` and change it to `no`.
6. Find (`ctrl+w`) `PubkeyAuthentication`, change it to `yes`, then save (`ctrl+o`) and exit (`ctrl+x`).
7. Restart the SSH service. (Note: Don't forget to use `sudo` to gain permission.)
```shell
sudo systemctl restart ssh
```
This is a command in the shell terminal to restart the SSH service with root privileges using the `systemctl` command.
8. The complete process is as follows:
![Enable SSH key verification and disable password verification](./ch04-img17-rsa-login-full.gif)
4. The public key has been set up on the VPS end. Now we need to specify the private key location for PuTTY to use when logging in. (Reminder: Don't forget to save the session.)
![Specify private key location in PuTTY](./ch04-img18-putty-privatekey-location.png)
5. Now, the [Key-based login] has been successfully enabled, [Password authentication] has been successfully disabled, and the default login username and private key have been saved for PuTTY. In the future, when using PuTTY to log in, simply load the `VPS-SERVER` configuration, click `Open`, and you can log in with just one click.
If you have set a password for your private key, you need to enter this password to use the key when logging in, as shown in the following figure:
![Enter Private Key Password](./ch04-img19-putty-privatekey-passphrase.png)
6. Don't forget to set the corresponding key for `WinSCP`, otherwise you won't be able to log in when you want to transfer files later.
![WinSCP Specify Private Key Location](./ch04-img20-winscp-privatekey-location.png)
::: warning
Any software that requires SSH login needs key verification. As there are too many software, it is impossible to show them one by one. Please set it up according to your needs.
Any software that needs to log in via SSH will now require key authentication. There are too many software options to show individually, so please configure them yourself according to your needs.
:::
## 4.8 Your Progress
Up to this point, your VPS has completed the basic security measures of [port], [username], and [password]. Although it is not completely impregnable, most malicious scripts should no longer be able to harm you.
Up to this point, your VPS has completed the basic security guarantees for the three elements: **[Port]**, **[Username]**, and **[Password]**. While far from impregnable, common malicious scripts should no longer be able to harm you!
Now that we finally have a secure system foundation, in the next chapter, we can start step by step to install and configure the infrastructure that Xray needs! (What infrastructure? A web page, a certificate)
Now we finally have a secure system foundation. In the next chapter, we can start gradually installing and configuring the infrastructure required for Xray! (What infrastructure? A webpage, a certificate).
> ⬛⬛⬛⬛⬜⬜⬜⬜ 50%
docs/en/document/level-0/ch05-webpage.md
+148 -109
View File
@@ -1,160 +1,199 @@
# Chapter 5: Website Building
# [Chapter 5] Website Setup
## 5.1 Why should you create a website?
## 5.1 Why create a website?
Some newcomers may be confused: why do I need to build a website for securing an open digital environment? I don't know how to code! Isn't it very complicated?
Newcomers might be confused: why do I need to build a website just to access the "scientific internet" (circumvent the firewall)? I don't know programming; isn't it very troublesome?
First, let's answer the first question. The reasons for building a website are:
Let's answer the first question. Reasons for building a website:
1. Apply for a legitimate TLS certificate (very important)
2. Provide reasonable fallback to prevent active probing attacks and improve security
3. Set up a camouflage site (such as a blog, private cloud storage, multimedia site, game site, etc.) with a reasonable frontend when directly accessed, making traffic usage look more legitimate.
1. To apply for a legitimate TLS certificate (Very important).
2. To provide a reasonable fallback mechanism to prevent active probing attacks and improve security.
3. To build a camouflage site (such as a blog, private cloud drive, multimedia site, game site, etc.) so that there is a legitimate front-end when accessed directly, making traffic usage look more reasonable.
Now let's answer the second question:
Now for the second question:
1. As a demonstration, this article uses only the simplest "single-file HTML page + Nginx" setup to achieve the above objectives, so it is **very easy**.
2. This website can not only be used for camouflage but also for real development and growth. The complexity depends entirely on you.
3. For the goals of "camouflage" and "website operation", uniqueness and personalization are needed. Students who need this can search and learn by themselves. This content has completely deviated from scientific online access, so this article will not go into depth.
1. This article, as a demonstration, uses only a very simple [single-file HTML page + Nginx] to achieve the above goals, so it is **very simple**.
2. This website can be more than just camouflage; you can actually make it big and strong. The complexity depends entirely on you.
3. For the goals of "camouflage" and "website operation," what is needed is individuality and showing your true self. Interested students can search and learn on their own. This content has completely deviated from "scientific internet access," so this article will not delve into it.
## 5.2 Log in to VPS, install and run Nginx
## 5.2 Login to VPS, Install and Run Nginx
1. Here we use commands that have been explained in detail before, so they won't be repeated. If you don't understand, please refer to the previous chapters.
1. The commands used here have been explained in detail previously, so they won't be repeated. Students who don't understand can review the previous chapters.
```shell
sudo apt update && sudo apt install nginx
```
```shell
sudo apt update && sudo apt install nginx
```
2. After completion, Nginx will automatically run. Open the browser on Windows and enter `http://100.200.300.400:80`. If you see the interface shown below, it means Nginx is running normally.
2. After completion, Nginx runs automatically. Now open a browser on Windows and enter `http://100.200.300.400:80`. If you see the interface below, Nginx is running normally.
![Nginx default interface](./ch05-img01-nginx-default-running.png)
![Nginx Default Page](./ch05-img01-nginx-default-running.png)
## 5.3 Create the simplest web page
3. If you cannot see the Nginx default page mentioned above, you may need to configure the default firewall component, Uncomplicated Firewall (UFW), on the Debian system to enable HTTP (80) and HTTPS (443) port traffic.
1. Basic Linux commands for beginners:
| No. | Command Name | Command Description |
| :------: | :----------------: | :-----------------------: |
| `cmd-10` | `mkdir` | Create a new folder |
| `cmd-11` | `systemctl reload` | Reload a specific service |
a. Verification method, input:
2. Basic Linux configuration files for beginners:
| No. | Configuration File Location | File Description |
| :-------: | :-------------------------: | :--------------------: |
| `conf-02` | `/etc/nginx/nginx.conf` | Nginx program settings |
```shell
sudo ufw status
```
3. Create a dedicated folder `/home/vpsadmin/www/webpage/` for the website and create the web page file `index.html`
```shell
mkdir -p ~/www/webpage/ && nano ~/www/webpage/index.html
```
b. If the output is as follows, indicating ports 80 and 443 are not enabled, proceed to step c.
::: warning
If you are not using the username `vpsadmin`, please be sure to understand the meaning of the "~" symbol in this command (this is related to Step 5 content):
```shell
Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
```
- If it is a **non-root user**, "~" is equivalent to `/home/username`
- If it is a **root user**, "~" is equivalent to `/root`
:::
c. Command to enable Nginx ports 80 and 443 in UFW:
4. Copy the entire content below, save (`ctrl+o`) and exit (`ctrl+x`).
```shell
sudo ufw allow 'Nginx Full'
```
```html
<html lang="">
<!-- Text between angle brackets is an HTML tag and is not displayed.
Most tags, such as the HTML and /HTML tags that surround the contents of
a page, come in pairs; some tags, like HR, for a horizontal rule, stand
alone. Comments, such as the text you're reading, are not displayed when
the Web page is shown. The information between the HEAD and /HEAD tags is
not displayed. The information between the BODY and /BODY tags is displayed.-->
<head>
<title>Enter a title, displayed at the top of the window.</title>
</head>
<!-- The information between the BODY and /BODY tags is displayed.-->
<body>
<h1>Enter the main heading, usually the same as the title.</h1>
<p>Be <b>bold</b> in stating your key points. Put them in a list:</p>
<ul>
<li>The first item in your list</li>
<li>The second item; <i>italicize</i> key words</li>
</ul>
<p>Improve your image by including an image.</p>
<p>
<img src="https://i.imgur.com/SEBww.jpg" alt="A Great HTML Resource" />
</p>
<p>
Add a link to your favorite
<a href="https://www.dummies.com/">Web site</a>. Break up your page
with a horizontal rule or two.
</p>
<hr />
<p>
Finally, link to <a href="page2.html">another page</a> in your own Web
site.
</p>
<!-- And add a copyright notice.-->
<p>© Wiley Publishing, 2011</p>
</body>
</html>
```
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
<html lang="">
<head>
<title>Enter a title, displayed at the top of the window.</title>
</head>
<body>
<h1>Enter the main heading, usually the same as the title.</h1>
<p>Be <b>bold</b> in stating your key points. Put them in a list:</p>
<ul>
<li>The first item in your list</li>
<li>The second item; <i>italicize</i> key words</li>
</ul>
<p>Improve your image by including an image.</p>
<p>
<img src="[https://i.imgur.com/SEBww.jpg](https://i.imgur.com/SEBww.jpg)" alt="A Great HTML Resource" />
</p>
<p>
Add a link to your favorite
<a href="[https://www.dummies.com/](https://www.dummies.com/)">Web site</a>. Break up your page
with a horizontal rule or two.
</p>
<hr />
<p>
Finally, link to <a href="page2.html">another page</a> in your own Web
site.
</p>
<p>&#169; Wiley Publishing, 2011</p>
</body>
</html>
```
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:
![Web page settings demonstration](./ch05-img02-nginx-conf-full.gif)
![Webpage Setup Demo](./ch05-img02-nginx-conf-full.gif)
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:
![http web page success](./ch05-img03-nginx-http-running.png)
![HTTP Webpage Success](./ch05-img03-nginx-http-running.png)
## 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%
docs/en/document/level-0/ch06-certificates.md
+124 -173
View File
@@ -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:
![acme.sh installation demo](./ch06-img01-acme-install.gif)
![acme.sh installation demo](./ch06-img01-acme-install.gif)
## 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%
docs/en/document/level-0/ch07-xray-server.md
+401 -416
View File
@@ -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:
![Xray server installation process demonstration](./ch07-img01-xray-install.gif)
## 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:
![Xray server installation process demonstration](./ch07-img02-xray-cert-install.png)
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:
![Xray Server Installation Demo](./ch07-img01-xray-install.gif)
## 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:
![Xray Certificate Install Demo](./ch07-img02-xray-cert-install.png)
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:
![Automatically install certificates for Xray every month](./ch07-img03-crontab-cert-renew.gif)
![Automatically install certificates for Xray monthly](./ch07-img03-crontab-cert-renew.gif)
## 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:
![Create log file and `config.json` configuration file](./ch07-img04-xray-log-and-config.gif)
5) The complete process demonstration is as follows:
![Creating log files and `config.json` configuration file](./ch07-img04-xray-log-and-config.gif)
## 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:
![Start and check Xray running status](./ch07-img05-xray-start-and-status.gif)
![Start and check the running status of Xray](./ch07-img05-xray-start-and-status.gif)
## 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
```
![Update Debian Kernel and Enable BBR](./ch07-img06-bbr-proper.gif)
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
```
![Update Debian kernel and enable `BBR`](./ch07-img06-bbr-proper.gif)
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
```
![http auto redirect to https](./ch07-img07-http-to-https.gif)
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
```
![http auto redirect to https active](./ch07-img08-http-to-https-check.png)
8. The complete process is demonstrated as follows:
## 7.9 Server Optimization 3: Richer Fallbacks
![http automatically jumps to https](./ch07-img07-http-to-https.gif)
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
![http automatically jumps to https](./ch07-img08-http-to-https-check.png)
## 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
docs/en/document/level-0/ch08-xray-clients.md
+148 -150
View File
@@ -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):
![Xray数据流向](./ch08-img01-flow.png)
![Xray Data Flow](./ch08-img01-flow.png)
这其中的关键点是：
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
![TO INFINITY AND BEYOND!](./ch08-img02-buzz.png)
:::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.
:::
docs/en/document/level-0/ch09-appendix.md
+40 -40
View File
@@ -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) |
docs/en/document/level-0/index.md
+11 -11
View File
@@ -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
docs/en/document/level-1/fallbacks-lv1.md
+232 -232
View File
@@ -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.
docs/en/document/level-1/fallbacks-with-sni.md
+83 -106
View File
@@ -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
![Xray Fallback Flow](./fallbacks-with-sni-resources/xray-fallbacks.svg)
![Xray Fallback Process](./fallbacks-with-sni-resources/xray-fallbacks.svg)
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
![DNS Records](./fallbacks-with-sni-resources/xray-dns-records.webp)
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:
![API Token permission settings](./fallbacks-with-sni-resources/cf-api-token-permissions-for-acme.webp)
![API Token Permissions](./fallbacks-with-sni-resources/cf-api-token-permissions-for-acme.webp)
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
<!-- prettier-ignore-start -->
[^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)
<!-- prettier-ignore-end -->
docs/en/document/level-1/index.md
+9 -7
View File
@@ -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)
docs/en/document/level-1/routing-lv1-part1.md
+113 -114
View File
@@ -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**.
![路由三兄弟](./routing-lv1-img01-trio.jpg)
![The Routing Trio](./routing-lv1-img01-trio.jpg)
三兄弟桃园结义，不求同年同月同日生，但求同年同月同日死。
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”` | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | 它的内层就是【路由规则】的明细设置 |
| `"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!
docs/en/document/level-1/routing-lv1-part2.md
+143 -143
View File
@@ -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
docs/en/document/level-1/routing-with-dns.md
+286
View File
@@ -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:
- <https://github.com/gfwlist/gfwlist>
- <https://github.com/v2fly/domain-list-community>
- <https://github.com/Loyalsoldier/v2ray-rules-dat>
However, it is impossible for them to cover every website; they suffer from lag and cannot be 100% trusted.
Here are a few examples:
- `geosite:cn` is a hodgepodge. Anything remotely related to China gets thrown in. Even if a domain is blocked by the GFW, it might not be removed in time.
If you rely solely on whether the target domain is in this list to decide on direct connection, it won't work perfectly. For example, `ai.ytimg.com` and `login.corp.google.com` remain in the list despite being blocked.
- The [README](https://github.com/Loyalsoldier/v2ray-rules-dat) of `v2ray-rules-dat` states: Apple, Microsoft, and Google CN domains exist in both `geosite:cn` and `geosite:geolocation-!cn`. But in reality, this is not always the case. (See: [PR#328](https://github.com/Loyalsoldier/v2ray-rules-dat/pull/328))
- What if the domain isn't in any list?
This undoubtedly causes trouble for traffic splitting. If your rules aren't updated in time, traffic that should go directly might be proxied, or some websites might not open at all.
What if an unknown domain has a server in China and you want to connect directly as much as possible, but after all your efforts, you encounter the legendary [DNS Leak](https://github.com/XTLS/BBS/issues/3#issuecomment-3505661189)?
So, is there a way to achieve 99.99% secure and precise traffic splitting?
The answer is: **Absolutely.**
## Achieving Precise Splitting with Xray-core DNS Module
By making reasonable use of Xray's ~~wheelchair-like~~ powerful built-in DNS features—such as Fallbacks, ECS (EDNS Client Subnet), IP filtering, and Tagging—and carefully adjusting their order, you can obtain a much more accurate and real-time routing condition than `geosite cn/!cn`: the IP address. This works because IP geolocation, especially CN geolocation, changes much less frequently than domain lists.
Before reading further, you need to fully read and understand the "Beginner Skills: Analysis of the Routing Feature [Part 1](./routing-lv1-part1.md) & [Part 2](./routing-lv1-part2.md)".
At the same time, you should have practically memorized the official configuration guide. You must fully understand the functions of `domainStrategy` in routing/outbounds, `sniffing` options in inbounds, and the behaviors produced by their different combinations.
Ready? Please try to understand the following paragraph:
When using **socks/http inbounds**, the request is a domain name. When it reaches the **Routing** module, a `domainStrategy` other than `AsIs` can use the built-in DNS to resolve an IP specifically for routing matching. When the traffic reaches a local **direct outbound**, a `domainStrategy` other than `AsIs` in the outbound can use the built-in DNS to resolve the IP again for the actual connection. The request sent to the Xray Server (remote) contains only the domain name; which IP is actually accessed depends on the server's direct outbound.
The situation becomes more complex with **Transparent Proxy**. If inbound `sniffing` is enabled and `destOverride` includes `[http, tls]`:
- If `routeOnly = false`, the requested IP will be wiped, and the subsequent flow acts just like a socks inbound.
- If `routeOnly = true`, both the domain and IP are available. When reaching the **Routing** module, it can match against both domain and IP rules directly. The local **direct outbound** will also use this IP. The request sent to the Xray Server contains only the IP. How does the server handle it? It repeats the process described above.
Having trouble? You need to re-read the official guide and try to understand it. Otherwise, it will be difficult for you to utilize the resolution results of the DNS module in the examples below for correct traffic splitting.
---
#### Example 1: This configuration resolves precise, CDN-friendly IP addresses. It guarantees no DNS Leaks while ensuring that if a domain has a server in China, it is prioritized. This is highly suitable for realIp transparent proxy scenarios
```json
{
"dns": {
"servers": [
// Prevent Google CAPTCHA issues and prevent Google China from being monitored (since many 3rd party sites load Google Fonts, etc.)
{
"address": "1.1.1.1",
"skipFallback": true,
"domains": ["geosite:google", "geosite:google-cn"]
},
{
"address": "8.8.8.8",
"skipFallback": true,
"domains": ["geosite:google", "geosite:google-cn"],
"finalQuery": true // Terminate the query chain
},
// Resolve domains considered by the community to be in China via Direct connection.
// If the result is not as expected, it might be blocked or have left China.
// Resolve via Proxy for fallback in case it is blocked or left China.
{
"tag": "dns-direct",
"address": "114.114.114.114",
"skipFallback": true,
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
{
"tag": "dns-direct",
"address": "223.5.5.5",
"skipFallback": true,
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
{
"address": "1.1.1.1",
"skipFallback": true,
"domains": ["geosite:cn"]
},
{
"address": "8.8.8.8",
"skipFallback": true,
"domains": ["geosite:cn"],
"finalQuery": true // Terminate the query chain
},
// Resolve domains considered non-Chinese via Proxy.
// If the result is not as expected, attempt optimized direct connection.
{
"address": "1.1.1.1",
"skipFallback": true,
"domains": ["geosite:geolocation-!cn"],
"expectIPs": ["geoip:!cn"]
},
{
"address": "8.8.8.8",
"skipFallback": true,
"domains": ["geosite:geolocation-!cn"],
"expectIPs": ["geoip:!cn"]
},
{
"address": "8.8.8.8",
"clientIp": "222.85.85.85", // Provide your local ISP IP to get direct-connection optimized A/AAAA records
// e.g., if you are Henan Telecom, use a Henan Telecom DNS (pun intended / example)
// Cannot guarantee 100% China CDN friendliness as not all authoritative servers support ECS
"skipFallback": true,
"domains": ["geosite:geolocation-!cn"]
},
{
"address": "8.8.4.4",
"clientIp": "222.85.85.85", // Same as above
"skipFallback": true,
"domains": ["geosite:geolocation-!cn"],
"finalQuery": true // Terminate the query chain
// You might wonder: Are these 4 rules redundant with the 4 above? Can they be simplified?
// Actually no, this is for extreme speed and because some authoritative DNS do not support ECS.
},
// Unknown domains, prioritize China. If unexpected, attempt optimized proxy.
{
"address": "8.8.8.8",
"clientIp": "222.85.85.85", // Same as above
"expectIPs": ["geoip:cn"]
},
{
"address": "8.8.4.4",
"clientIp": "222.85.85.85", // Same as above
"expectIPs": ["geoip:cn"]
},
"1.1.1.1",
"8.8.8.8"
],
"tag": "dns-proxy",
"enableParallelQuery": true // Intelligent parallel query: All parallel, smart grouping, race within group
},
"routing": {
"domainStrategy": "Depends entirely 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...
}
```
```mermaid
graph TD
A[Receive DNS Query] --> B{Domain Classification};
B -->|geosite:google<br>Google Domains| C["Query via <b>Proxy</b><br>Foreign DNS (1.1.1.1...)"];
C --> C_OUT[Likely returns Foreign IP];
C_OUT --> Z[End Query];
B -->|geosite:cn<br>Known/Suspected CN Domains| D["Query via <b>Direct</b><br>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["<b>Fallback</b>: Query via <b>Proxy</b><br>Foreign DNS (1.1.1.1...)"];
G --> G_OUT[Return correct Foreign IP];
G_OUT --> Z;
B -->|geosite:geolocation-!cn<br>Known/Suspected Foreign| I["Query via <b>Proxy</b><br>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["<b>Fallback</b>: Query via <b>Proxy+ECS</b><br>Foreign DNS (8.8.8.8...)"];
L --> L_OUT[Return optimized CN IP];
L_OUT --> Z;
B -->|Unknown Domains| N["Query via <b>Proxy+ECS</b><br>Foreign DNS (8.8.8.8...)<br>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["<b>Fallback</b>: Query via <b>Proxy</b><br>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.
<br>
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.
docs/en/document/level-1/work.md
+23 -23
View File
@@ -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.
docs/en/document/level-2/index.md
+15 -15
View File
@@ -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 <img src="https://avatars2.githubusercontent.com/u/57820613?s=32" width="32" height="32" alt="a"/> [@kirin](https://github.com/kirin10000)
[Introduction to Transparent Proxy](./transparent_proxy/transparent_proxy.md) by <img src="https://avatars2.githubusercontent.com/u/57820613?s=32" width="32" height="32" alt="a"/> [@kirin](https://github.com/kirin10000)
An Introduction to Transparent Proxies.
An introductory chapter on Transparent Proxy.
[TProxy Configuration Tutorial](./tproxy.md) by <img src="https://avatars2.githubusercontent.com/u/41363844?s=32" width="32" height="32" alt="a"/> [@BioniCosmos](https://github.com/BioniCosmos)
[Transparent Proxy (TProxy) Configuration Tutorial](./tproxy.md) by <img src="https://avatars2.githubusercontent.com/u/41363844?s=32" width="32" height="32" alt="a"/> [@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 <img src="https://avatars.githubusercontent.com/u/110686480?s=32" width="32" height="32" alt="a"/> [@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 <img src="https://avatars.githubusercontent.com/u/110686480?s=32" width="32" height="32" alt="a"/> [@SQLimit](https://github.com/SQLimit)
[Using Nginx or HAProxy to Build TLS Tunnels to Hide Fingerprints](./nginx_or_haproxy_tls_tunnel.md) by <img src="https://avatars.githubusercontent.com/u/110686480?s=32" width="32" height="32" alt="a"/> [@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 <img src="https://avatars2.githubusercontent.com/u/57820613?s=32" width="32" height="32" alt="a"/> [@kirin](https://github.com/kirin10000)
[[Transparent Proxy] Bypassing Xray Traffic via GID](./iptables_gid.md) by <img src="https://avatars2.githubusercontent.com/u/57820613?s=32" width="32" height="32" alt="a"/> [@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 <img src="https://avatars.githubusercontent.com/u/28607089?s=32" width="32" height="32" alt="a"/> [@Zzz3m](https://github.com/Zzz3m)
[Directing Specific Traffic to Specific Exits via Xray for Global Routing "Traffic Splitting"](./redirect.md) by <img src="https://avatars.githubusercontent.com/u/28607089?s=32" width="32" height="32" alt="a"/> [@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 <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@yuhan6665](https://github.com/yuhan6665)
[Enhancing Proxy Security via Cloudflare Warp](./warp.md) by <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@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 <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@yuhan6665](https://github.com/yuhan6665)
Adapt traffic statistics and scripts compatible with Xray.
Traffic statistics and scripts adapted for Xray.
docs/en/document/level-2/iptables_gid.md
+98 -86
View File
@@ -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
```
docs/en/document/level-2/nginx_or_haproxy_tls_tunnel.md
+107 -105
View File
@@ -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: <https://learn.microsoft.com/en-us/azure/application-gateway/self-signed-certificates>
根证书 ca.crt 服务器证书 server.crt 服务器密钥 server.key
Root certificate: `ca.crt`; Server certificate: `server.crt`; Server key: `server.key`.
至少需要生成一个 server.pem，客户端可以同样使用此证书用于双端认证；或者生成两个证书，一个 client，一个 server，用于双端认证
You need to generate at least one `server.pem`. The client can use this same certificate for mutual authentication; or generate two certificates, one for client and one for server, for mutual authentication.
需准备 fullchain.crt 用于认证（ cat server.crt ca.crt > fullchain.crt ），server.pem （ cat server.crt server.key ca.crt > server.pem ）用于解密
Prepare `fullchain.crt` for verification (`cat server.crt ca.crt > fullchain.crt`) and `server.pem` (`cat server.crt server.key ca.crt > server.pem`) for decryption.
### haproxy_client 配置
### haproxy_client Configuration
```
```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -623,12 +625,12 @@ frontend xray
backend tunnel
server tunnel tunnel.example.com:443 tfo allow-0rtt ssl crt /path/to/client.pem verify required ca-file /path/to/fullchain.crt sni str(tunnel.example.com) alpn h2
# 网址自定义，和自签证书一致即可，hosts 中配置 IP 解析，sni 的 str 设定 sni，用于服务端识别
# The URL is custom, just keep it consistent with the self-signed certificate. Configure IP resolution in hosts. Set sni with `sni str()` for server-side identification.
```
### haproxy_server 配置
### haproxy_server Configuration
```
```haproxy
global
log /dev/log local0 alert
log /dev/log local1 alert
@@ -653,14 +655,14 @@ defaults
timeout server 300s
frontend tls-in
bind :::443 tfo allow-0rtt ssl crt /path/to/server.pem verify optional ca-file /path/to/fullchain.crt crt /path/to/www.example.com.pem alpn h2,http/1.1
bind :::443 tfo allow-0rtt ssl crt /path/to/server.pem verify optional ca-file /path/to/fullchain.crt crt /path/to/[www.example.com](https://www.example.com).pem alpn h2,http/1.1
use_backend xray if { ssl_fc_sni tunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /tunnel }
use_backend server1 if { ssl_fc_sni atunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /path2 }
use_backend server2 if { ssl_fc_sni btunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /path3 }
use_backend server3 if { ssl_fc_sni ctunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /path4 }
default_backend web
# Haproxy 支持多个 pem 解密
# 可根据多个客户端的不同 sni 分流，也可以 path 分流，方式多样，更多 acl 见 Haproxy 文档
# Haproxy supports multiple pem decryptions
# Can route based on different client SNIs, or based on path. Various methods available. See Haproxy docs for more ACLs.
backend xray
server xray abns@vless.sock proto h2
@@ -678,6 +680,6 @@ 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.
docs/en/document/level-2/redirect.md
+86 -189
View File
@@ -1,146 +1,100 @@
---
title: 出站流量重定向
title: Outbound Traffic Redirection
---
# 基于 fwmark 或 sendThrough 的流量重定向
# Traffic Redirection Based on fwmark or sendThrough
通过 Xray 将特定的流量指向特定出口，实现全局路由“分流”
Direct specific traffic to specific exits via Xray to achieve global routing "traffic splitting".
## 前言
## Foreword
之前在网络上看到许多代理或者 VPN 会接管全局路由，如果与 Xray 同时安装，会导致 Xray 失效。参考了网络上许多教程，及时分流，也是通过维护一张或者多张 CIDR
路由表来实现的。这种情况下并不优雅，如果我想可以任意替换，实现按需分流，那有没有更好的办法呢？有！
Previously, I noticed that many proxies or VPNs take over the global routing table. If installed alongside Xray, this causes Xray to fail. I referred to many tutorials online, and even immediate traffic splitting was achieved by maintaining one or more CIDR routing tables. This approach is not elegant. If I want to be able to replace interfaces arbitrarily and achieve on-demand splitting, is there a better way? Yes!
通过 fwmark 或 Xray 的 sendThrough，再简单配合路由表功能即可实现：
By using `fwmark` or Xray's `sendThrough`/`sockopt.interface`, combined simply with routing table functions, we can achieve:
1. Xray 可设置指定的 Tag、域名等走指定接口。如果您的接口是双栈的，可以指定 IPV4 或者 IPV6
2. 其余用户则走原 IPV4 或者 IPV6
1. Xray can set specific Tags, domains, etc., to go through a specific interface. If your interface is dual-stack, you can specify IPv4 or IPv6.
2. The rest of the users will use the original IPv4 or IPv6.
具体设置如下（以 Debian10 为例）：
The specific settings are as follows (using Debian 10 as an example):
## 1、安装代理或者 VPN 软件（例如 Wireguard、IPsec 等）
## 1. Install Proxy or VPN Software (e.g., WireGuard, IPsec, etc.)
根据不同系统和不同软件，请参考官方安装方法
Please refer to the official installation methods for different systems and software.
## 2、编辑 VPN 配置文件（以 WireGuard 为例）
## 2. Edit VPN Configuration File (Using WireGuard as an example)
原始文件：
<Tabs title="if-config">
<Tab title="fwmark1">
Original file:
```ini
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxx
Address = "your wg0 v4 address"
Address = "your wg0 v6 address"
PrivateKey = <PriKey>
Address = <IPv4>
Address = <IPv6>
DNS = 8.8.8.8
MTU = 1280
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxx
PublicKey = <Pubkey>
AllowedIPs = ::/0
AllowedIPs = 0.0.0.0/0
Endpoint = "ip:port"
Endpoint = <EndpointIP>:<Port>
```
在 `[Interface]` 下添加如下命令：
Add the following commands under `[Interface]`:
```ini
Table = off
PostUP = ip -4 rule add fwmark <mark> lookup <table>
PostUP = ip -4 route add default dev <接口名称> table <table>
PostUP = ip -4 rule add table main suppress_prefixlength 0
Table = <table>
### fwmark
PostUP = ip rule add fwmark <mark> lookup <table>
PostDown = ip rule del fwmark <mark> lookup <table>
PostUP = ip -6 rule add fwmark <mark> lookup <table>
PostUP = ip -6 rule add not fwmark <table> table <table>
PostUP = ip -6 route add ::/0 dev <接口名称> table <table>
PostUP = ip -6 rule add table main suppress_prefixlength 0
PostDown = ip -4 rule delete fwmark <mark> lookup <table>
PostDown = ip -4 rule delete table main suppress_prefixlength 0
PostDown = ip -6 rule delete fwmark <mark> lookup <table>
PostDown = ip -6 rule delete not fwmark <table> table <table>
PostDown = ip -6 rule delete table main suppress_prefixlength 0
PostDown = ip -6 rule del fwmark <mark> lookup <table>
## sendThrough
PreUp = ip rule add from <IPv4> lookup <table>
PostDown = ip rule del from <IPv4> lookup <table>
PreUp = ip -6 rule add from <IPv6> lookup <table>
PostDown = ip -6 rule del from <IPv6> lookup <table>
## sockopt.interface
PreUp = ip rule add oif %i lookup <table>
PostDown = ip rule del oif %i lookup <table>
PreUp = ip -6 rule add oif %i lookup <table>
PostDown = ip -6 rule del oif %i lookup <table>
```
::: tip
- 此命令表示 IPv4 中 fwmark 为 `<mark>`，IPv6 中 fwmark 为`<mark>`，::/0 全局 v6 走 WireGuard
- 可根据自己需求增删命令，mark 值要与 Xray-core 中设置为相同，table 值自定
- 如果不支持配置文件，可以在系统中修改路由表
- This configuration integrates `fwmark` / `sendThrough` / `sockopt.interface`, meaning:
- Connections sent to this device `%i` / Connections sent to this `<IPv4/6>` / Connections marked with `fwmark` `<mark>`
- Will be forwarded using WireGuard.
- `%i` is a placeholder in the WireGuard configuration file, which represents the device name to be replaced at startup.
:::
</Tab>
Save it.
<Tab title="sendThrough1">
You can also install this handy tool:
```ini
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxx
Address = "your wg0 v4 address"
Address = "your wg0 v6 address"
DNS = 8.8.8.8
MTU = 1280
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxx
AllowedIPs = ::/0
AllowedIPs = 0.0.0.0/0
Endpoint = "ip:port"
```
在 `[Interface]` 下添加如下命令：
```ini
Table = off
PostUP = ip -4 rule add from "your wg0 v4 address" lookup <table>
PostUP = ip -4 route add default dev wg0 table <table>
PostUP = ip -4 rule add table main suppress_prefixlength 0
PostUP = ip -6 rule add not fwmark <table> table <table>
PostUP = ip -6 route add ::/0 dev wg0 table <table>
PostUP = ip -6 rule add table main suppress_prefixlength 0
PostDown = ip -4 rule delete from "your wg0 v4 address" lookup <table>
PostDown = ip -4 rule delete table main suppress_prefixlength 0
PostDown = ip -6 rule delete not fwmark <table> table <table>
PostDown = ip -6 rule delete table main suppress_prefixlength 0
```
::: tip
- 此命令表示 IPV4 中来自 `your wg0 v4 address` 地址的走 WireGuard，IPv6 中::/0 全局 v6 走 WireGuard）
- 可根据自己需求增删命令，实现 v6 分流，也可以与 fwmark 融合
- 如果不支持配置文件，可以在系统中修改路由表
:::
</Tab>
</Tabs>
保存
可顺手安装
::: warning
If the `DNS` field in `[Interface]` is used, this program is required.
:::
```bash
apt install openresolv
```
## 3、启用 WireGuard 网络接口
## 3. Enable WireGuard Network Interface
加载内核模块
Load the kernel module:
```bash
modprobe wireguard
```
检查 WG 模块加载是否正常
Check if the WG module is loaded correctly:
```bash
lsmod | grep wireguard
```
## 4、Xray-core 配置文件修改
<Tabs title="xray-config">
<Tab title="fwmark2">
## 4. Xray-core Configuration Modification
```json
{
@@ -167,105 +121,48 @@ lsmod | grep wireguard
{
"protocol": "freedom",
"settings": {
"domainStrategy": "UseIPv6"
//设置默认用户走指定方式”UseIPv6”或者”UseIPv4”
"domainStrategy": "UseIPv4"
}
// Modify here, can be v4 or v6
},
// <--Please choose between different schemes--> Scheme 1: fwmark
{
"protocol": "freedom",
"tag": "wg0",
"streamSettings": {
"sockopt": {
"mark": <mark>
"mark": // <mark>
}
},
"settings": {
"domainStrategy": "UseIPv6"
}
//设置fwmark为<mark>的用户走指定方式”UseIPv6””UseIPv4”
},
{
"protocol": "blackhole",
"settings": {},
"tag": "blocked"
}
],
"policy": {
"system": {
"statsInboundDownlink": true,
"statsInboundUplink": true
}
},
"routing": {
"rules": [
{
"inboundTag": [
"api"
],
"outboundTag": "api"
},
{
"outboundTag": "wg0",
"inboundTag": [
"<inboundTag>"
//需要之前在inbound中指定好Tag，我这里是api生成的,还可以添加域名等等
]
},
{
"outboundTag": "blocked",
"protocol": [
"bittorrent"
]
}
]
},
"stats": {}
}
```
</Tab>
<Tab title="sendThrough2">
```json
{
"api": {
"services": [
"HandlerService",
"LoggerService",
"StatsService"
],
"tag": "api"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": <port>,
"protocol": "dokodemo-door",
"settings": {
"address": "127.0.0.1"
},
"tag": "api"
}
],
"outbounds": [
{
"protocol": "freedom",
"settings": {
"domainStrategy": "UseIPv4"
}
//修改此处，可v4或者v6
},
}, // Users with fwmark set to <mark> use the specified strategy "UseIPv6" or "UseIPv4"
// <--Please choose between different schemes--> Scheme 2: sendThrough
{
"tag": "wg0",
"protocol": "freedom",
"sendThrough": "your wg0 v4 address",
//修改此处，可v4或者v6
// Modify here, can be v4 or v6
"settings": {
"domainStrategy": "UseIPv4"
}
//修改此处，可v4或者v6
// Modify here, can be v4 or v6
},
// <--Please choose between different schemes--> Scheme 3: sockopt.interface
{
"tag": "wg0",
"protocol": "freedom",
"settings": {
"domainStrategy": "UseIPv4"
},
"streamSettings": {
"sockopt": {
"interface": "wg0"
}
}
},
// <--Please choose between different schemes--> End
{
"protocol": "blackhole",
"settings": {},
@@ -290,7 +187,7 @@ lsmod | grep wireguard
"outboundTag": "wg0",
"inboundTag": [
"<inboundTag>"
//需要之前在 inbound 中指定好 Tag，我这里是 api 生成的,还可以添加域名等等
// Need to specify the Tag in inbound beforehand; here it's generated by api, domains can also be added, etc.
]
},
{
@@ -305,43 +202,43 @@ lsmod | grep wireguard
}
```
</Tab>
</Tabs>
::: tip
可以通过修改 "domainStrategy": "UseIPv6"来控制对应用户的访问方式 实测优先级要高于系统本身的 gai.config
You can control the access method for corresponding users by modifying `"domainStrategy": "UseIPv6"`. Actual tests show priority is higher than the system's own `gai.config`.
:::
## 5、系统设置配置
## 5. System Settings Configuration
::: tip
需要打开系统的 ip_forward
You need to enable the system's `ip_forward`.
`sysctl -w net.ipv4.ip_forward=1`
`sysctl -w net.ipv6.conf.all.forwarding=1`
:::
## 6、完成 WireGuard 相关设置
## 6. Complete WireGuard Settings
开启隧道
Start the tunnel:
```bash
wg-quick up wg0
```
开机自启
Enable auto-start on boot:
```bash
systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0
```
验证 IPv4/IPv6
Verify IPv4/IPv6:
> 自行验证 Google 搜索 myip
> Run `curl ip-api.com -4/-6` on the proxy / Visit ip-api.com via browser
## 后记
## Postscript
本文本意是可以避免的多余的流量浪费，将路由和分流的功能交给 Xray 处理。避免了维护路由表的繁琐工作。顺便技术提升 UP。
The intention of this article is to avoid unnecessary waste of traffic by handing over the routing and splitting functions to Xray. This avoids the tedious work of maintaining routing tables. It also serves to level up your technical skills.
## 感谢
## Acknowledgments
@Xray-core @V2ray-core @WireGuard @p3terx @w @Hiram @Luminous @Ln @JackChou
[XTLS/Xray-core](https://github.com/XTLS/Xray-core); [v2fly/v2ray-core](https://github.com/v2fly/v2ray-core); [WireGuard](https://www.wireguard.com/); [@p3terx](https://p3terx.com/); @w; @Hiram; @Luminous; @Ln; @JackChou;
<!--剩下几位大佬我实在找不到他们的地址或Github空间，请大家帮忙找吧-->
docs/en/document/level-2/tproxy.md
+29 -55
View File
@@ -1,24 +1,24 @@
---
title: TProxy 透明代理
title: TProxy Transparent Proxy
---
# 透明代理（TProxy）配置教程
# Transparent Proxy (TProxy) Configuration Tutorial
本配置基于[TProxy 透明代理的新 V2Ray 白话文教程](https://guide.v2fly.org/app/tproxy.html)，加入了 Xray 的新特性，使用 VLESS + XTLS Vision 方案，并将旧教程中默认出站代理的分流方式改为默认出站直连，使用者请按照实际情况进行修改。
This configuration is based on the [New V2Ray Plain Guide for Transparent Proxy (TProxy)](https://guide.v2fly.org/app/tproxy.html), adding new features from Xray. It utilizes the VLESS + XTLS Vision scheme. Unlike the old tutorial which defaulted to proxying outbound traffic, this configuration defaults to direct connection for outbound traffic. Users should adjust this according to their actual needs.
本文中所有配置已在 Raspberry Pi 2B、Ubuntu 20.04 环境下测试成功，如在其它环境中使用请自行调整配置。
All configurations in this article have been successfully tested on Raspberry Pi 2B and Ubuntu 20.04. If you are using a different environment, please adjust the configuration accordingly.
## 开始之前
## Before You Start
请检查您的设备是否有可用的网络连接，且服务端已经配置成功，客户端已经安装完毕。
Please check that your device has an active network connection, the server-side is successfully configured, and the client is installed.
需注意的是，目前很多透明代理教程都会将 Linux 系统的 IP 转发打开，但这样会导致 Splice 性能下降。详情请参考[大案牍术破案纪实第三篇--我们是如何破解 Splice 性能下降甚至低于 Direct 之谜的](https://github.com/XTLS/Xray-core/discussions/59)。
It is worth noting that many transparent proxy tutorials instruct you to enable IP Forwarding on Linux. However, doing so can degrade `Splice` performance. For details, please refer to [Detective Story Part 3: How we solved the mystery of Splice performance dropping even below Direct](https://github.com/XTLS/Xray-core/discussions/59).
这里我想要补充的是，很多透明代理教程会使用 Netfilter 进行分流，使直连流量直接发出而不经过 Xray，这时必须开启 IP 转发；也有的教程，如本文，会将所有流量导入 Xray 之中，由 Xray 的路由模块进行分流，这时无需开启 IP 转发。
I would like to add that many transparent proxy tutorials use Netfilter for traffic splitting (routing), allowing direct traffic to go out without passing through Xray. In that case, IP Forwarding must be enabled. However, some tutorials, like this one, direct *all* traffic into Xray, and the routing module within Xray handles the splitting. In this scenario, IP Forwarding does **not** need to be enabled.
## Xray 配置
## Xray Configuration
为了更好的分流体验，请替换默认路由规则文件为 [Loyalsoldier/v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat)，否则 Xray-core 将无法加载本配置。
For a better routing experience, please replace the default routing rule files with [Loyalsoldier/v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat); otherwise, Xray-core will not be able to load this configuration.
```bash
sudo curl -oL /usr/local/share/xray/geoip.dat https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat
@@ -71,7 +71,7 @@ sudo curl -oL /usr/local/share/xray/geosite.dat https://github.com/Loyalsoldier/
"settings": {
"vnext": [
{
"address": "服务端域名",
"address": "Server_Domain",
"port": 443,
"users": [
{
@@ -118,7 +118,7 @@ sudo curl -oL /usr/local/share/xray/geosite.dat https://github.com/Loyalsoldier/
],
"dns": {
"hosts": {
"服务端域名": "服务端 IP"
"Server_Domain": "Server_IP"
},
"servers": [
{
@@ -168,26 +168,22 @@ sudo curl -oL /usr/local/share/xray/geosite.dat https://github.com/Loyalsoldier/
```
::: tip TIP
本配置会劫持所有发往 53 端口的流量以解决 DNS 污染问题，所以客户端和本机的 DNS 服务器的地址可以随意配置。
This configuration hijacks all traffic sent to port 53 to solve DNS pollution issues, so the DNS server addresses on the client and the local machine can be configured arbitrarily.
:::
## 策略路由配置
## Policy Routing Configuration
```
sudo ip route add local default dev lo table 100 # 添加路由表 100
sudo ip rule add fwmark 1 table 100 # 为路由表 100 设定规则
```bash
sudo ip route add local default dev lo table 100 # Add routing table 100
sudo ip rule add fwmark 1 table 100 # Set rules for routing table 100
```
## Netfilter 配置
## Netfilter Configuration
::: warning 注意
nftables 配置与 iptables 配置二选一，不可同时使用。
::: warning Note
Choose either **nftables** or **iptables** configuration. Do not use both simultaneously.
:::
<Tabs title="netfilter">
<Tab title="nftables1">
```nftables
#!/usr/sbin/nft -f
@@ -226,15 +222,11 @@ table ip xray {
}
```
::: tip 使用方法
::: tip Usage
将上述配置写入一个文件（如 `nft.conf`），之后将该文件赋予可执行权限，最后使用 root 权限执行该文件即可（`# ./nft.conf`）。
Write the above configuration to a file (e.g., `nft.conf`), then give the file executable permissions, and finally execute the file with root privileges (`# ./nft.conf`).
:::
</Tab>
<Tab title="iptables1">
```bash
iptables -t mangle -N XRAY
iptables -t mangle -A XRAY -d 10.0.0.0/8 -j RETURN
@@ -270,21 +262,11 @@ iptables -t mangle -A XRAY_SELF -p udp -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -j XRAY_SELF
```
</Tab>
After the configuration is complete, change the default gateway of other devices in the LAN to the IP of this device to bypass the firewall directly. After successfully testing on both other hosts and the local machine, you can proceed to the next step.
</Tabs>
## Persistence and Auto-start
配置完成后，将局域网内其它设备的默认网关改为该设备 IP，就可以直接翻墙了。在其它主机和本机皆测试成功后，可进行下一步配置。
## 配置永久化与开机自启
<br/>
<Tabs title="netfilter2">
<Tab title="nftables2">
首先将已经编辑好的 nftables 配置文件移动到 `/etc` 目录下，并重命名为 `nftables.conf`。然后编辑 `/lib/systemd/system/nftables.service`。
First, move the edited `nftables` configuration file to the `/etc` directory and rename it to `nftables.conf`. Then edit `/lib/systemd/system/nftables.service`.
```ini
[Unit]
@@ -309,17 +291,13 @@ ExecStop=/usr/sbin/nft flush ruleset ; /usr/sbin/ip route del local default dev
WantedBy=sysinit.target
```
最后 enable 即可。
Finally, enable it.
</Tab>
For persistence with `iptables`, it is recommended to install `iptables-persistent` directly.
<Tab title="iptables2">
During the installation process, you will be prompted to "Save current IPv4 rules?". If you have already applied the iptables configuration to the system, select "Yes". If not, it doesn't matter; after installation, apply the configuration and then execute `netfilter-persistent save` (root privileges required).
关于 iptables 的永久化，建议直接安装 `iptables-persistent`。
安装过程中会提示你选择“是否保存配置”，如果已经将 iptables 配置写入系统，那么此时选择“是”即可；如果尚未写入也没有关系，安装完毕后将配置写入，然后执行 `netfilter-persistent save` 即可（需要 root 权限）。
之后编辑 `/lib/systemd/system/netfilter-persistent.service`。
After that, edit `/lib/systemd/system/netfilter-persistent.service`.
```ini
[Unit]
@@ -340,7 +318,3 @@ ExecStop=/usr/sbin/netfilter-persistent stop ; /usr/sbin/ip route flush dev lo t
[Install]
WantedBy=multi-user.target
```
</Tab>
</Tabs>
docs/en/document/level-2/tproxy_ipv4_and_ipv6.md
+101 -96
View File
@@ -1,33 +1,33 @@
---
title: TProxy 透明代理 (ipv4 and ipv6)
title: TProxy Transparent Proxy (IPv4 and IPv6)
---
# TProxy 透明代理（ipv4 and ipv6）配置教程
# TProxy Transparent Proxy (IPv4 and IPv6) Configuration Tutorial
本配置参考了[TProxy 透明代理的新 V2Ray 白话文教程](https://guide.v2fly.org/app/tproxy.html)，[透明代理（TProxy）配置教程](https://xtls.github.io/document/level-2/tproxy.html#%E5%BC%80%E5%A7%8B%E4%B9%8B%E5%89%8D)以及[透明代理通过 gid 规避 Xray 流量](https://xtls.github.io/document/level-2/iptables_gid.html)，加入了透明代理对 ipv6 的支持，并且使用 VLESS-TCP-XTLS-RPRX-Vision 方案对抗封锁 (推荐使用 1.7.2 及之后版本)。
This configuration is based on the [New V2Ray Plain English Guide for TProxy Transparent Proxy](https://guide.v2fly.org/app/tproxy.html), the [Transparent Proxy (TProxy) Configuration Tutorial](https://xtls.github.io/document/level-2/tproxy.html#%E5%BC%80%E5%A7%8B%E4%B9%8B%E5%89%8D), and [Bypassing Xray Traffic via GID](https://xtls.github.io/document/level-2/iptables_gid.html). It adds support for IPv6 transparent proxying and utilizes the VLESS-TCP-XTLS-RPRX-Vision scheme to counter blocking (version 1.7.2 or later is recommended).
关于 Xray 的配置并不是本文重点，使用者可依实际情况进行修改，具体可以参考[官方文档示例](https://github.com/XTLS/Xray-examples)或其他优秀示例 比如[@chika0801](https://github.com/chika0801/Xray-examples) 又如[@lxhao61](https://github.com/lxhao61/integrated-examples)。
The configuration of Xray itself is not the main focus of this article. Users should modify it according to their actual situation. For specific details, please refer to the [official document examples](https://github.com/XTLS/Xray-examples) or other excellent examples such as [@chika0801](https://github.com/chika0801/Xray-examples) and [@lxhao61](https://github.com/lxhao61/integrated-examples).
::: warning 注意
::: warning Note
若使用其他配置，你需要着重注意客户端配置中 `outbound` 中`tag` 为 `proxy` 的部分，其他部分不变
If you use other configurations, you need to pay special attention to the part where the `tag` is `proxy` in the `outbound` section of the client configuration. Other parts remain unchanged.
服务端配置也要同时改变
The server configuration must also be changed accordingly.
:::
此配置意在解决例如 Netflix 等默认使用 ipv6 连接的网站无法通过旁路由进行代理的问题，或对 ipv6 代理有需要。
This configuration aims to solve the problem where websites that default to IPv6 connections, such as Netflix, cannot be proxied through a side router (gateway), or to satisfy the need for IPv6 proxying.
本文网络结构为单臂旁路由
The network structure in this article is a Single-Arm Router (Side Router).
本文中所有配置已在 Arch Linux (Kernel: 6.0.10) 环境下测试成功，如在其它环境中同理
All configurations in this article have been successfully tested in an Arch Linux (Kernel: 6.0.10) environment. The logic is the same for other environments.
注意安装相应程序 `# sudo apt install iptables ip6tables` 或 `# sudo apt install nftables`。
Note that you need to install the corresponding programs: `# sudo apt install iptables ip6tables` or `# sudo apt install nftables`.
若旁路由未安装 xray 程序，可以手动下载相应 xray 程序如 [Xray-linux-64.zip](https://github.com/XTLS/Xray-core/releases/download/v1.7.0/Xray-linux-64.zip) ，然后复制 [install-release.sh](https://github.com/XTLS/Xray-install/blob/main/install-release.sh) 文件到旁路由，赋予可执行权限 `# chmod 700 install-release.sh`，然后使用 `# ./install-release.sh --local Xray-linux-64.zip` 根据提示进行本地安装。
If the Xray program is not installed on the side router, you can manually download the corresponding Xray program, such as [Xray-linux-64.zip](https://github.com/XTLS/Xray-core/releases/download/v1.7.0/Xray-linux-64.zip), then copy the [install-release.sh](https://github.com/XTLS/Xray-install/blob/main/install-release.sh) file to the side router, grant executable permission `# chmod 700 install-release.sh`, and then use `# ./install-release.sh --local Xray-linux-64.zip` to perform a local installation according to the prompts.
## Xray 配置
## Xray Configuration
### 客户端配置
### Client Configuration
```json
{
@@ -49,8 +49,7 @@ title: TProxy 透明代理 (ipv4 and ipv6)
},
"streamSettings": {
"sockopt": {
"tproxy": "tproxy",
"mark": 255
"tproxy": "tproxy"
}
}
},
@@ -69,17 +68,19 @@ title: TProxy 透明代理 (ipv4 and ipv6)
],
"outbounds": [
{
//此为默认outbound，路由(routing)模块若未匹配到任何规则，则默认走此 proxy 出口，如果你希望直连国内优先请将下面 direct 出口放到 outbound 第一，看不懂可忽略
// This is the default outbound. If the routing module does not match any rules,
// it defaults to this "proxy" exit. If you prefer direct connection for domestic traffic as priority,
// please move the "direct" outbound below to the first position in outbounds. Ignore if you don't understand.
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "yourdomain.domain", //改为你自己的域名，直接填写ipv4或ipv6地址也可以
"address": "yourdomain.domain", // Change to your own domain. Direct IPv4 or IPv6 address is also acceptable.
"port": 443,
"users": [
{
"id": "uuid", //填写uuid，可通过在终端中输入 xray uuid 生成；此处也支持任意字符串（https://xtls.github.io/config/inbounds/vless.html#clientobject）
"id": "uuid", // Fill in UUID. Can be generated by typing 'xray uuid' in terminal; Arbitrary strings are also supported ([https://xtls.github.io/config/inbounds/vless.html#clientobject](https://xtls.github.io/config/inbounds/vless.html#clientobject))
"encryption": "none",
"flow": "xtls-rprx-vision"
}
@@ -92,12 +93,12 @@ title: TProxy 透明代理 (ipv4 and ipv6)
"mark": 255
},
"network": "tcp",
"security": "tls", //注意使用 xtls-rprx-vision 流控此处需为 tls
"security": "tls", // Note: must be tls when using xtls-rprx-vision flow
"tlsSettings": {
//注意使用 xtls-rprx-vision 流控此处需为 tlsSettings
// Note: must be tlsSettings when using xtls-rprx-vision flow
"allowInsecure": false,
"serverName": "yourdomain.domain", //改为你自己的域名
"fingerprint": "chrome" //此设置建议先看下Release, https://github.com/XTLS/Xray-core/releases/tag/v1.7.3
"serverName": "yourdomain.domain", // Change to your own domain
"fingerprint": "chrome" // Recommended to check Release notes for this setting: [https://github.com/XTLS/Xray-core/releases/tag/v1.7.3](https://github.com/XTLS/Xray-core/releases/tag/v1.7.3)
}
}
},
@@ -136,16 +137,16 @@ title: TProxy 透明代理 (ipv4 and ipv6)
"hosts": {
"domain:googleapis.cn": "googleapis.com",
"dns.google": "8.8.8.8",
"你的VPS域名": "你的VSP IP" //如果 outbound 的 proxy 里 address 填的域名：希望代理走ipv4，这里 VPS IP 填VPS的ipv4, 希望代理走ipv6，这里VPS IP 填VPS的ipv6；outbound 的 proxy 里 address 填的 IP，这行不用写。
"Your_VPS_Domain": "Your_VPS_IP" // If 'address' in outbound proxy is a domain: fill VPS IPv4 if you want proxy via IPv4, fill VPS IPv6 if via IPv6; If 'address' is an IP, skip this line.
},
"servers": [
"https://1.1.1.1/dns-query",
"[https://1.1.1.1/dns-query](https://1.1.1.1/dns-query)",
{
"address": "119.29.29.29",
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
"https://dns.google/dns-query",
"[https://dns.google/dns-query](https://dns.google/dns-query)",
"223.5.5.5",
"localhost"
]
@@ -179,7 +180,7 @@ title: TProxy 透明代理 (ipv4 and ipv6)
"outboundTag": "direct"
},
{
"ip": ["geoip:private", "geoip:cn"], //此处可加入 VPS IP 避免 ssh 时被代理
"ip": ["geoip:private", "geoip:cn"], // Can add VPS IP here to avoid proxying SSH connections
"outboundTag": "direct"
},
{
@@ -203,7 +204,7 @@ title: TProxy 透明代理 (ipv4 and ipv6)
}
```
### 服务端配置
### Server Configuration
```json
{
@@ -214,7 +215,7 @@ title: TProxy 透明代理 (ipv4 and ipv6)
"domainStrategy": "IPIfNonMatch",
"rules": [
{
//阻止 cnip 提高安全性，或者可以将 cn 流量导入 warp 中，详见https://xtls.github.io/document/level-2/warp.html
// Block CN IP to improve security, or you can route CN traffic into Warp, see [https://xtls.github.io/document/level-2/warp.html](https://xtls.github.io/document/level-2/warp.html)
"ip": ["geoip:cn"],
"outboundTag": "block"
}
@@ -227,14 +228,14 @@ title: TProxy 透明代理 (ipv4 and ipv6)
"settings": {
"clients": [
{
"id": "uuid", //与客户端相同
"id": "uuid", // Same as client
"flow": "xtls-rprx-vision"
}
],
"decryption": "none",
"fallbacks": [
{
"dest": 8080 //回落，需要 web 配合，参见白话文，不设置也行
"dest": 8080 // Fallback, requires web server cooperation, see the plain English guide. Optional.
}
]
},
@@ -245,7 +246,7 @@ title: TProxy 透明代理 (ipv4 and ipv6)
"certificates": [
{
"certificateFile": "/etc/ssl/private/fullchain.crt",
"keyFile": "/etc/ssl/private/crt.key" //参照小小白话文将生成的 fullchain.crt 以及 cert.key证书的路径相应填于此处(https://xtls.github.io/document/level-0/ch06-certificates.html#_6-4-%E6%AD%A3%E5%BC%8F%E8%AF%81%E4%B9%A6%E7%94%B3%E8%AF%B7)
"keyFile": "/etc/ssl/private/crt.key" // Refer to the Beginner's Guide to fill in the path of the generated fullchain.crt and cert.key here ([https://xtls.github.io/document/level-0/ch06-certificates.html#_6-4-%E6%AD%A3%E5%BC%8F%E8%AF%81%E4%B9%A6%E7%94%B3%E8%AF%B7](https://xtls.github.io/document/level-0/ch06-certificates.html#_6-4-%E6%AD%A3%E5%BC%8F%E8%AF%81%E4%B9%A6%E7%94%B3%E8%AF%B7))
}
]
}
@@ -269,36 +270,38 @@ title: TProxy 透明代理 (ipv4 and ipv6)
}
```
## Netfilter 配置
## Netfilter Configuration
### 首先设置策略路由
### First, Set Policy Routing
```bash
# 设置策略路由 v4
# 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
# 直连从主路由发出
ip route add default via 192.168.31.1 #写主路由 ipv4, 采用局域网设备上网设置方法一可不写此命令
ip -6 route add default via fd00:6868:6868::1 #写主路由 ipv6, 采用局域网设备上网设置方法一可不写此命令
# Direct connection goes out from the main router
ip route add default via 192.168.31.1 # Write main router IPv4. Not needed if using Method 1 for LAN devices.
ip -6 route add default via fd00:6868:6868::1 # Write main router IPv6. Not needed if using Method 1 for LAN devices.
```
::: tip 使用方法
::: tip Usage
直接将命令复制到旁路由终端执行
Copy the commands directly to the side router terminal and execute them.
:::
::: tip 关于直连从主路由发出
::: tip About "Direct connection goes out from the main router"
在旁路由使用命令`ip route show`，如果使用下属方法一，则`default via`后应是主路由 ip，无需更改；如使用下述方法二，则`default via`后应是旁路由 ip，此时直连网站 DNS 解析会回环，造成直连网站无法访问，因此需指定为主路由 ip。
Run the command `ip route show` on the side router.
If you use **Method 1** below, the `default via` should be the main router's IP, and no change is needed.
If you use **Method 2** below, the `default via` would be the side router's IP. In this case, DNS resolution for direct connections will loop back, causing direct websites to be inaccessible, so it must be specified as the main router's IP.
:::
如果是在路由器上指定了默认网关为旁路由（亦即下述“局域网设备上网设置方法二”），那么就需要设置上述 `# 直连从主路由发出` ，除了通过 iproute2 命令行方式设置，也可以通过 dhcpcd 或者 systemctl-network 设置静态 IP，这里以 dhcpcd 为例，编辑 `/etc/dhcpcd.conf` 文件，在最下方加入如下配置，具体 IP 根据你的实际情况修改，其中 `interface` 可以通过 `# ip link show` 查看要设定的网口或者无线设备。
If you specified the default gateway as the side router on the main router (i.e., "LAN Device Internet Setup Method 2" below), then you need to set the above `# Direct connection goes out from the main router`. besides setting it via `iproute2` command line, you can also set a static IP via `dhcpcd` or `systemctl-network`. Here we take `dhcpcd` as an example. Edit the `/etc/dhcpcd.conf` file and add the following configuration at the bottom. Modify the specific IP according to your actual situation. The `interface` can be viewed via `# ip link show` to see the network port or wireless device to be configured.
```
interface enp0s25
@@ -308,19 +311,19 @@ static routers=192.168.31.1
static domain_name_servers=192.168.31.1 fd00:6868:6868::1
```
这样通过静态 IP 设置 IP 及网关后就无需每次开机设置 `# 直连从主路由发出`。
By setting the IP and gateway via static IP this way, there is no need to set `# Direct connection goes out from the main router` every time you boot.
::: warning 注意
::: warning Note
以下 nftables 配置与 iptables 配置二选一，不可同时使用。
Choose **either** the following nftables configuration **or** iptables configuration. Do not use both simultaneously.
:::
### 使用 iptables
### Using iptables
此处配置将 ipv4 与 ipv6 写在同一文件中。
This configuration writes IPv4 and IPv6 into the same file.
```bash
# 代理局域网设备 v4
# Proxy LAN devices v4
iptables -t mangle -N XRAY
iptables -t mangle -A XRAY -d 127.0.0.1/32 -j RETURN
iptables -t mangle -A XRAY -d 224.0.0.0/4 -j RETURN
@@ -332,7 +335,7 @@ iptables -t mangle -A XRAY -p udp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
iptables -t mangle -A PREROUTING -j XRAY
# 代理局域网设备 v6
# Proxy LAN devices v6
ip6tables -t mangle -N XRAY6
ip6tables -t mangle -A XRAY6 -d ::1/128 -j RETURN
ip6tables -t mangle -A XRAY6 -d fe80::/10 -j RETURN
@@ -343,7 +346,7 @@ ip6tables -t mangle -A XRAY6 -p udp -j TPROXY --on-ip ::1 --on-port 12345 --tpro
ip6tables -t mangle -A XRAY6 -p tcp -j TPROXY --on-ip ::1 --on-port 12345 --tproxy-mark 1
ip6tables -t mangle -A PREROUTING -j XRAY6
# 代理网关本机 v4
# Proxy Gateway Itself v4
iptables -t mangle -N XRAY_MASK
iptables -t mangle -A XRAY_MASK -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A XRAY_MASK -d 255.255.255.255/32 -j RETURN
@@ -354,7 +357,7 @@ iptables -t mangle -A XRAY_MASK -p udp -j MARK --set-mark 1
iptables -t mangle -A XRAY_MASK -p tcp -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -j XRAY_MASK
# 代理网关本机 v6
# Proxy Gateway Itself v6
ip6tables -t mangle -N XRAY6_MASK
ip6tables -t mangle -A XRAY6_MASK -d fe80::/10 -j RETURN
ip6tables -t mangle -A XRAY6_MASK -d fd00::/8 -p tcp -j RETURN
@@ -364,13 +367,13 @@ ip6tables -t mangle -A XRAY6_MASK -p udp -j MARK --set-mark 1
ip6tables -t mangle -A XRAY6_MASK -p tcp -j MARK --set-mark 1
ip6tables -t mangle -A OUTPUT -j XRAY6_MASK
# 新建 DIVERT 规则，避免已有连接的包二次通过 TPROXY，理论上有一定的性能提升 v4
# Create DIVERT rule to avoid packet re-traversal through TPROXY for existing connections, theoretical performance boost v4
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -I PREROUTING -p tcp -m socket -j DIVERT
# 新建 DIVERT 规则，避免已有连接的包二次通过 TPROXY，理论上有一定的性能提升 v6
# Create DIVERT rule to avoid packet re-traversal through TPROXY for existing connections, theoretical performance boost v6
ip6tables -t mangle -N DIVERT
ip6tables -t mangle -A DIVERT -j MARK --set-mark 1
ip6tables -t mangle -A DIVERT -j ACCEPT
@@ -378,16 +381,16 @@ ip6tables -t mangle -I PREROUTING -p tcp -m socket -j DIVERT
```
::: tip 使用方法
::: tip Usage
将上述配置写入一个文件（如 `iptables.rules`），之后将该文件赋予可执行权限`# chmod 700 ./iptables.rules`
Write the above configuration into a file (e.g., `iptables.rules`), then grant executable permission to the file: `# chmod 700 ./iptables.rules`.
最后使用 root 权限执行该文件即可：`# ./iptables.rules`或`# source iptables.rules`。
Finally, execute the file with root privileges: `# ./iptables.rules` or `# source iptables.rules`.
:::
### 使用 nftables
### Using nftables
此处合并 ipv4 与 ipv6
This merges IPv4 and IPv6.
```
#!/usr/sbin/nft -f
@@ -428,30 +431,30 @@ table inet xray {
```
::: tip 使用方法
::: tip Usage
将上述配置写入一个文件（如 `nftables.rules`），之后将该文件赋予可执行权限`# chmod 700 ./nftables.rules`
Write the above configuration into a file (e.g., `nftables.rules`), then grant executable permission to the file: `# chmod 700 ./nftables.rules`.
最后使用 root 权限执行该文件即可：`# ./nftables.rules`或`# source nftables.rules`
Finally, execute the file with root privileges: `# ./nftables.rules` or `# source nftables.rules`.
:::
其中，网关地址`192.168.0.0/16`, `fd00::/8`等可由`ip address | grep -w inet | awk '{print $2}'`以及`ip address | grep -w inet6 | awk '{print $2}'`[获得](https://xtls.github.io/document/level-2/iptables_gid.html#_4-%E8%AE%BE%E7%BD%AE-iptables-%E8%A7%84%E5%88%99)
Where gateway addresses `192.168.0.0/16`, `fd00::/8`, etc., can be [obtained](https://xtls.github.io/document/level-2/iptables_gid.html#_4-%E8%AE%BE%E7%BD%AE-iptables-%E8%A7%84%E5%88%99) by `ip address | grep -w inet | awk '{print $2}'` and `ip address | grep -w inet6 | awk '{print $2}'`.
或者在 windows 网络设置中查看。
Or check in Windows Network Settings.
又或者在路由器“上网设置”中查看。
Or check in the Router's "Internet Settings".
如果前缀`192.168`, `fd00:`相同可不更改，若不同如 `fc00:`, `fe00:` 等则更改为相应值，写法可通过 Goolge 搜索得到如 `fc00::/7`, `fe00::/9`。
If the prefixes `192.168`, `fd00:` are the same, you don't need to change them. If they are different, such as `fc00:`, `fe00:`, etc., change them to the corresponding values. The notation (like `fc00::/7`, `fe00::/9`) can be found via Google search.
### 开机自动运行 Netfilter 配置
### Auto-run Netfilter Configuration on Boot
首先确认已经运行过上述相应 Netfilter 命令，并且成功测试透明代理配置，以确保接下来输出正确的文件。
First, confirm that you have run the corresponding Netfilter commands above and successfully tested the transparent proxy configuration to ensure the output files are correct.
#### 若使用 iptables 配置
#### If using iptables configuration
1. 首先通过 `# iptables-save > /root/iptables.rulesv4` `# ip6tables-save > /root/iptables.rulesv6` 将 iptables 配置写入 `iptables.rulesv4` 和 `iptables.rulesv6` 文件中
1. First, save the iptables configuration to `iptables.rulesv4` and `iptables.rulesv6` files: `# iptables-save > /root/iptables.rulesv4` and `# ip6tables-save > /root/iptables.rulesv6`.
2. 然后在 `/etc/systemd/system/` 目录下创建一个名为 `tproxyrules.service` 的文件，添加以下内容并保存
2. Then create a file named `tproxyrules.service` in the `/etc/systemd/system/` directory, add the following content, and save it:
```
[Unit]
@@ -482,13 +485,13 @@ ExecStop=/sbin/ip rule del fwmark 1 table 100 ; \
WantedBy=multi-user.target
```
3. 最后执行 `systemctl enable tproxyrules` 命令。
1. Finally, execute the command `systemctl enable tproxyrules`.
#### 如果使用 nftables 配置
#### If using nftables configuration
1. 首先通过 `# nft list ruleset > /root/nftables.rulesv46` 将 nftables 配置写入 `nftables.rulesv46` 文件中
1. First, write the nftables configuration to the `nftables.rulesv46` file: `# nft list ruleset > /root/nftables.rulesv46`.
2. 在 `/etc/systemd/system/` 目录下创建一个名为 `tproxyrules.service` 的文件，然后添加以下内容并保存
2. Create a file named `tproxyrules.service` in the `/etc/systemd/system/` directory, then add the following content and save it:
```
[Unit]
@@ -517,55 +520,57 @@ ExecStop=/sbin/ip rule del fwmark 1 table 100 ; \
WantedBy=multi-user.target
```
3. 最后执行 `systemctl enable tproxyrules` 命令。
1. Finally, execute the command `systemctl enable tproxyrules`.
::: tip tproxyrules.service
注意其中主路由器 IP 地址，根据实际修改
Note the Main Router IP address, modify it according to reality.
`ExecStartPre=/bin/sh -c 'until ping -c1 192.168.31.1; do sleep 1; done;'` 命令为确保获得 IP 地址后再执行命令，否则会诡异报错，其中 IP 地址为主路由器地址，根据实际修改。
The command `ExecStartPre=/bin/sh -c 'until ping -c1 192.168.31.1; do sleep 1; done;'` ensures that the command is executed only after obtaining an IP address, otherwise weird errors may occur. The IP address is the main router address, modify it according to reality.
:::
::: warning 注意
::: warning Note
如果通过 dhcpcd 等设置了静态 IP 及网关，则上述相关 `ip route add/del` 设置需删除
If you have set a static IP and gateway via dhcpcd, etc., the related `ip route add/del` settings above should be removed.
:::
## 局域网设备上网设置
## LAN Device Internet Setup
此处假定旁路由 ipv4, ipv6 地址分别为`192.168.31.100`, `fd00:6868:6868::8866`, 旁路由的 ipv4, ipv6 地址可由命令`ip add`获得。
Assuming the IPv4 and IPv6 addresses of the side router are `192.168.31.100` and `fd00:6868:6868::8866` respectively. The IP addresses of the side router can be obtained by the command `ip add`.
### 方法一
### Method 1
局域网设备上网有两种方式，第一种就是在使用设备上进行静态 IP 的配置，将网关指向旁路由 IP。注意绝大部分手机仅支持手动配置 ipv4 网关，不支持手动配置 ipv6 网关，除非 root 后进行相关设置。
There are two ways for LAN devices to access the Internet. The first is to configure a static IP on the device and point the gateway to the side router IP. Note that most mobile phones only support manual configuration of IPv4 gateways and do not support manual configuration of IPv6 gateways unless rooted and configured accordingly.
以 windows 设备为例，可以先开启 DHCP 记录自动分配的 IP 以参考，然后手写静态配置。
Taking a Windows device as an example, you can first enable DHCP to record the automatically assigned IP for reference, and then write the static configuration manually.
::: tip DNS 设置
::: tip DNS Settings
此配置劫持 DNS 流量，DNS 可以随便写
This configuration hijacks DNS traffic, so DNS can be written arbitrarily.
It is recommended to set it to the side router IP to prevent DNS leaks.
:::
<img width="231" alt="image" src="https://user-images.githubusercontent.com/110686480/208310266-632e36b9-a23b-4b90-aa28-583b50e87c66.png"> <img width="238" alt="image" src="https://user-images.githubusercontent.com/110686480/208309659-e3172218-ef27-4a94-a017-225f8e05b611.png">
### 方法二
### 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).
<img width="700" alt="image" src="https://user-images.githubusercontent.com/110686480/208310174-2245a890-eb6b-4341-899f-81c6ac8255ff.png">
## 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 <https://ipv6-test.com/>, you can see the following results (you need to proxy this website to see the result below):
<img width="700" alt="image" src="https://user-images.githubusercontent.com/110686480/208743723-f8a2751b-43d0-4353-9383-5ae0e00e9449.png">
## 写在最后
## 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.
docs/en/document/level-2/traffic_stats.md
+12 -12
View File
@@ -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
docs/en/document/level-2/transparent_proxy/transparent_proxy.md
+122 -108
View File
@@ -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:
![Netfilter](./netfilter.png)
**假设使用路由器作为网关(即我们平时的上网方式)，那么：**
**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...
docs/en/document/level-2/warp.md
+120 -26
View File
@@ -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"
}
]