xray-vless-reality and the one-command Reality proxy server

What the script actually does: eight effective lines

The README is unusually candid about its own size. It says the one-click script is extremely simple, that the effective statements are eight lines: five for BBR, one to install Xray, one to generate the x25519 public and private key, and one to generate the UUID. Everything else in the script exists to check for beginner input mistakes or to verify that the prerequisites for the build are met.

That framing is the most useful thing in the documentation, because it tells you the script is not hiding much. The rest of the README says the same thing from the other direction: if you do not trust open source scripts, you can execute those eight effective statements yourself and then modify the four lines in the configuration file, and you will reach the same result.

So the script is doing four jobs. It edits sysctl so the kernel uses BBR congestion control and the fq queue discipline. It runs the upstream Xray installer. It generates the two credentials you need, an x25519 key pair and a UUID. And it writes a configuration file that you then edit.

The audience is someone with a Linux server and no patience for the manual version of the same four steps, and the assumption behind the design is that the reader is not an experienced operator, which is why the input validation is as long as the useful code.

The four commands, and the configuration that follows them

The manual path is laid out in the README in full, and reading it is the fastest way to understand what the installer automates.

Enabling BBR means removing the existing congestion control and default qdisc lines from sysctl.conf and appending the BBR and fq settings, then applying them:

sed -i '/net.ipv4.tcp_congestion_control/d' /etc/sysctl.conf
sed -i '/net.core.default_qdisc/d' /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control = bbr" >>/etc/sysctl.conf
echo "net.core.default_qdisc = fq" >>/etc/sysctl.conf
sysctl -p >/dev/null 2>&1

Installing Xray is a single upstream command, and the README points at the source:

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

The credentials come from the Xray binary itself:

xray x25519

and

xray uuid

The README explains the split that catches people out: the private key is used on the server and the public key is used on the client. The configuration file is written to /usr/local/etc/xray/config.json, and the README is clear that four lines need changing by hand. The port is 443 by default, the destination site name is something you choose, the private key goes in, and the UUID goes in. The Reality protocol also defines ShortId and SpiderX, and for personal use the README says you can leave those alone.

After that, the script prints a VLESS link so you can import it into a client, and the README repeats the point that the client uses the public key, which is not the same value as the private key on the server.

The Reality layer, and the condition that rules it out

There is one limitation stated early in the README, and it is a hard boundary rather than a caveat.

The Reality layer is a direct TCP connection, so if your VPS is already blocked then it certainly will not work, and the README points at a different project for that case, v2ray_wss.

That single sentence decides whether this project applies to you. Reality works by making the server look like an ordinary TLS site, borrowing the certificate and handshake of a real destination you choose, and the README suggests picking something like learn.microsoft.com. The configuration sets the dest to that site on port 443, lists the server names, and puts the private key in the realitySettings block. The networking is tcp and the security is reality, with xver set to 0.

Everything else in the config is ordinary Xray. The inbound listens on 0.0.0.0 on port 443 with protocol vless, the client entry carries the flow xtls-rprx-vision, and decryption is none. Outbounds are a freedom outbound tagged direct and a blackhole outbound tagged block, and the routing rules send private IP ranges to the block outbound, so local addresses are not proxied. Sniffing is enabled and overrides to http and tls, and the DNS section lists both Google and Cloudflare resolvers over IPv4 and IPv6 plus localhost.

For an IPv6-only server the README suggests adding IPv4 egress with WARP:

bash <(curl -L git.io/warp.sh) 4

Parameters, environment variables and the uninstall path

The script accepts parameters positionally, and the README documents each one with its default.

The netstack value, where 6 means an IPv6 inbound and 4 means an IPv4 inbound. The port, which defaults to 443. The domain, which defaults to learn.microsoft.com. And the UUID, which is generated automatically if you do not supply one.

So the shortest form and the longest form both work:

bash <(curl -L https://github.com/crazypeace/xray-vless-reality/raw/main/install.sh) 6
bash <(curl -L https://github.com/crazypeace/xray-vless-reality/raw/main/install.sh) 6 443 learn.microsoft.com 1b0b723f-0544-4f9c-8df8-2b8975c5e47a

Environment variables are the alternative path, and the rule is worth reading carefully. Once at least one environment variable is defined, the parameters are ignored in favour of the environment, and the interactive flow is skipped, with unset parameters taking their default values. So these are for a long-lived setup rather than a one-off run:

export _MYIP_=1.2.3.4
export _MYPORT_=8443
export _MYDOMAIN_=example.com
export _MYUUID_=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
bash install.sh

A single command form is also documented, where the variables apply only to that execution.

Removing it is a single upstream command:

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ remove --purge

One more dependency to note before you start: the script begins with apt update and apt install -y curl, so the target machine is a Debian or Ubuntu derivative with apt available. The README also points at a Reality-capable v2rayN build for people who use the PAC mode of v2rayN.

Why reviewing the script matters more than usual here

The usual objections to running a shell script from the internet apply everywhere. This one has a specific twist, because the script is not only a wrapper, it also writes to the host's kernel configuration.

The sysctl edits are the part to look at first. The script deletes the existing congestion control and default queue discipline lines from /etc/sysctl.conf and appends BBR and fq, then applies them with sysctl -p. Those are host-level changes with effects on every connection the machine makes, not on Xray alone, and they persist across reboots. The README says so plainly by listing the BBR lines among the effective statements, but a reader who only sees the one-line install command may not realise the scope of what the script touches.

The second thing to weigh is the supply chain of the install itself. The script calls the upstream Xray installer directly from GitHub over curl, and the uninstall path calls the same installer with a remove argument. That is the same upstream project that ships the binaries, and the README links it as the source, which is the right relationship to have. But it means the script you review is not the only thing that runs.

The third is the network reachability of the download URLs themselves. Both the script and the Xray installer are fetched over HTTPS from GitHub, and the README's own warning about a blocked VPS applies to the installation step as much as to the service: on a server from which GitHub is not reachable, the install will fail before the proxy is configured.

None of this makes the script dangerous by design. The argument is that the host-level sysctl change and the upstream installer call deserve a read, and the README hands you the eight lines to read.

Editorial conclusion

xray-vless-reality is a good fit for someone with a Linux VPS who wants a VLESS plus Reality server configured in one step and is comfortable reviewing a script before running it, since the README sets out the same eight effective commands and the four configuration lines you would otherwise have to work out. It is a poor fit if your server's IP is already unreachable from where you are, because Reality sits on top of a direct TCP connection and the README says plainly that in that case it will not work, and it is a poor fit if you want the script to install anything other than Xray, since the install pulls a separate upstream installer. Before running it, read install.sh end to end, change the UUID, the private key, the site name and the port as the README marks, and check the two places where the script writes outside the Xray configuration, since those are the lines that affect the host itself.

Frequently asked questions

Official sources

1. crazypeace/xray-vless-reality on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README