# A Brief Analysis of Fallbacks 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. Reviewing Fallbacks in the "Beginner's Guide" 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 { "inbounds": [ { "port": 443, "protocol": "vless", "settings": { "users": [ // ... ... ], "decryption": "none", "fallbacks": [ { "dest": 8080 // Default fallback to the probe-resistant proxy/service } ] }, "streamSettings": { // ... ... } } ] } ``` How do we explain this configuration in plain language? 1. **Xray's `[inbound port]` is `443`** This means `Xray` is responsible for listening to `HTTPS` traffic on port `443`. 2. **Xray's `[inbound protocol]` is `vless`** Only traffic using the `vless` protocol will flow into `Xray` for further processing. ::: 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. **The `[fallback dest]` is `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 **Q: Is it singular or plural?** 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? 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. **Traffic falling back to port `8080` is handled by a subsequent program** 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. **Summary: The complete data route for the simplest fallback in the Beginner's Guide is as follows:** ```mermaid graph LR; W(External HTTP:80 Request) --> N80(HTTP:80) subgraph Nginx External Listener N80 -.- N301(301 Redirect) -.- N443(HTTPS:443) end 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 ``` ## 2. Re-understanding Fallbacks (WHAT, HOW `v1`) 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. 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 Use Fallbacks (WHY `v1`) Initially, it was to defend against **[Active Probing]**. **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: - 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. 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: - 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. 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]. 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. 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. **Therefore, the [Complete Fallback Function] in `Xray` now possesses the following attributes:** - **Secure:** Fully resists active probing attacks. - **Efficient:** Almost zero performance loss. - **Flexible:** Flexible data shunting, reuse of common ports (like 443). ::: 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. Multi-layer Fallback Example and Interpretation Now that you understand what the [Perfect Form of Fallback] is, you can get your hands dirty configuring multi-layer fallbacks. ### 5.1 First, I will extract the server-side configuration for port 443 as follows ```json { "port": 443, "protocol": "vless", "settings": { "users": [ { "id": "", // Fill in your UUID "flow": "xtls-rprx-vision", "level": 0, "email": "love@example.com" } ], "decryption": "none", "fallbacks": [ { "dest": 1310, // Default fallback to Xray's Trojan protocol "xver": 1 }, { "path": "/websocket", // Must be changed to your custom PATH "dest": 1234, "xver": 1 }, { "path": "/vmesstcp", // Must be changed to your custom PATH "dest": 2345, "xver": 1 }, { "path": "/vmessws", // Must be changed to your custom PATH "dest": 3456, "xver": 1 } ] }, "streamSettings": { "network": "tcp", "security": "tls", "tlsSettings": { "alpn": ["http/1.1"], "certificates": [ { "certificateFile": "/path/to/fullchain.crt", // Absolute path to your certificate "keyFile": "/path/to/private.key" // Absolute path to your private key } ] } } } ``` How do we explain this configuration in plain language? 1. **Xray's `[inbound port]` is `443`** 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's `[inbound protocol]` is `vless`** `vless` protocol traffic flows directly into `Xray` for subsequent processing. 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` set to `1` means enabling the `proxy protocol` function to pass the real source IP backwards.** 5. **The fallback structure described above is shown in the diagram below:** ```mermaid graph LR; 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 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. **The Web Page Fallback is missing!** 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 The configuration segments for subsequent listening processing are as follows 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": { "users": [ { "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 } } } ``` 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. Traffic falling back to port `1234`. Look closely! It is actually `vless+ws`: ```json { "port": 1234, "listen": "127.0.0.1", "protocol": "vless", "settings": { "users": [ { "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. 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": { "users": [ { "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. Traffic falling back to port `3456`. Look closely again! It is actually `vmess+ws(+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": { "users": [ { "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. **With this, we can draw the complete fallback route for the template:** ```mermaid graph LR; 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 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 --> |Protocol = trojan Traffic| X2 X1310 --> |All Other Traffic| N80(Nginx:80) N80:::nginxclass --> H(index.html) H:::nginxclass classDef nginxclass fill:#FFFFDE ``` ## 6. Conclusion This concludes the introduction to `Xray`'s **[Fallback]** function. I hope this article helps you understand the power of `Xray`. ## 7. Bonus Question 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? Hint: HTTP automatic redirection to HTTPS.