Remove invalid VuePress code from docs

This commit is contained in:
Meow
2026-01-24 06:33:55 +08:00
parent 8db6a5dba7
commit aefcd935e1
34 changed files with 45 additions and 160 deletions
+1 -1
View File
@@ -160,6 +160,6 @@ ghcr.io/xtls/xray-core version image:
- [GoXRay](https://github.com/goxray/desktop)
- [AnyPortal](https://github.com/AnyPortal/AnyPortal)
# UUID Generator
## UUID Generator
Third-party UUID generator: [uuidgenerator.net](https://www.uuidgenerator.net)
@@ -1,7 +1,3 @@
---
title: SNI Fallback
---
# Camouflage and Routing by Domain via SNI Fallback
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.
+2 -6
View File
@@ -1,7 +1,3 @@
---
title: GID Transparent Proxy
---
# Transparent Proxy: Bypassing Xray Traffic via GID
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.
@@ -145,11 +141,11 @@ ulimit -SHn 1000000
sudo -u xray_tproxy xray -c /etc/xray/config.json &
```
*First command:*
_First command:_
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.
*Second command:*
_Second command:_
Runs the Xray client as a user with `uid=0` and a non-zero `gid`. The `&` at the end indicates running in the background.
@@ -1,10 +1,8 @@
---
title: Using Nginx or HAProxy to Build TLS Tunnels to Hide Fingerprints
---
# Using Nginx or HAProxy to Build TLS Tunnels to Hide Fingerprints
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.
# Building HTTPS Tunnels with Nginx on Client & Server to Hide Fingerprints
## Building HTTPS Tunnels with Nginx on Client & Server to Hide Fingerprints
Network Structure:
-4
View File
@@ -1,7 +1,3 @@
---
title: Outbound Traffic Redirection
---
# Traffic Redirection Based on fwmark or sendThrough
Direct specific traffic to specific exits via Xray to achieve global routing "traffic splitting".
+1 -5
View File
@@ -1,7 +1,3 @@
---
title: TProxy Transparent Proxy
---
# Transparent Proxy (TProxy) Configuration Tutorial
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.
@@ -14,7 +10,7 @@ Please check that your device has an active network connection, the server-side
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).
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.
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 Configuration
@@ -1,7 +1,3 @@
---
title: TProxy Transparent Proxy (IPv4 and IPv6)
---
# TProxy Transparent Proxy (IPv4 and IPv6) Configuration Tutorial
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).
@@ -1,7 +1,3 @@
---
title: Traffic Statistics
---
# Traffic Statistics Configuration Tutorial
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+).
+2 -6
View File
@@ -1,15 +1,11 @@
---
title: Enhancing Proxy Security via Cloudflare Warp
---
# Enhancing Proxy Security via Cloudflare Warp
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 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.
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.
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