# Xray_bash_onekey installs Xray and Nginx in one command, then keeps a rollback copy

> Xray_bash_onekey is a shell script that installs Xray with Reality, TLS or ws/gRPC/xHTTP behind Nginx, and afterwards exposes a management menu for services, security, traffic statistics and rule updates. The parts a sysadmin will care about are the reconfiguration paths, which come with automatic rollback, and the guard rails the README states plainly, including the instruction not to use it in production before verifying it works.

**hello-yunshu/Xray_bash_onekey** — Xray支持Reality/VLESS WebSocket/gRPC+TLS协议+Nginx的一键安装脚本      Xray supports Reality / VLESS WebSocket/gRPC+TLS protocols + Nginx with one-click install scripts

- Repository: https://github.com/hello-yunshu/Xray_bash_onekey
- Website: https://hey.run
- Stars: 663 · Forks: 222
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/hello-yunshu-xray-bash-onekey

## One command, then a menu called idleleo

The quick install is a single pipeline:

```bash
bash <(curl -fsSL https://github.com/hello-yunshu/Xray_bash_onekey/releases/latest/download/install.sh)
```

Everything after that is driven from a management menu invoked with the command idleleo, which the README describes as opening the Xray management menu for installation, services and security settings. The same command has a set of documented flags for the common operations, including idleleo --help, idleleo --show for installation information, idleleo --update for updating the script, idleleo --xray-update and idleleo --nginx-update for the components, idleleo --set-fail2ban, idleleo --traffic-blocker and idleleo --port-traffic for live traffic on a port.

The naming is worth a note. The install script is not called install.sh from a repository clone in the usual way, it is fetched from the releases page as the latest published artefact, and the administrative command is idleleo rather than something generic. The project is a fork, in the literal sense, of wulabing's V2Ray_ws-tls_bash_onekey, and the TCP acceleration script is taken from ylx2016's Linux-NetSpeed.

The preparation requirements are modest and stated up front: a server outside your own country with a public IP, a target domain that satisfies Xray's requirements for Reality, a domain plus correctly configured A and, in a dual stack environment, AAAA records for the TLS mode, and curl installed, with the two package manager commands given for CentOS and Debian or Ubuntu.

The project page is hey.run, the repository carries a Chinese first language README with English, French, Russian, Persian and Korean translations under i18n/languages, and the licence is GPL-3.0.

## Five install modes, each with different prerequisites

The script offers five modes and the differences are practical rather than cosmetic.

Reality plus Nginx is the recommended mode, and it can optionally add the ws, gRPC or xHTTP simple protocols for load balancing. Nginx plus TLS supports ws, gRPC and xHTTP and automatically obtains and renews Let's Encrypt certificates. The ws/gRPC/xHTTP ONLY mode is a standalone inbound without TLS, described as mainly for backend or load balancing use. XTLS ONLY is limited to specific scenarios such as traffic relay. The Docker mode is an image with Xray, Nginx and the main script preinstalled.

When you install one of the ws, gRPC or xHTTP modes you can pick a single transport or enable ws+gRPC+xHTTP together, and the script generates the matching ports, paths, share links and QR codes. One detail is worth knowing up front: Clash does not support xHTTP, and the script says so in the configuration output.

The mode table also decides what you need to have ready. Reality needs a target domain that meets Xray's requirements, and the TLS mode needs a domain of your own with DNS records pointing at the server, which is a different level of setup from a single inbound with no TLS.

The README also says the script supports Debian 12 and later, Ubuntu 24.04 and later, and CentOS Stream 10 and later, notes that some CentOS templates may have build issues and suggests changing system if you hit them, and recommends against CentOS for beginners.

## Reconfiguration comes in three paths, each with a limit

Running the installer again on an installed environment is the case most likely to break something, so the script treats it as a first class flow. It backs up the current running configuration automatically and offers three paths.

Keeping the configuration and redeploying preserves your custom routing, outbounds, DNS and multi user setup, and only changes the fields you chose, such as port, path, UUID and Reality parameters. The limit is explicit: it does not support changing the transport structure, so moving from ws to gRPC means you need the standard template rebuild instead.

The standard template rebuild uses the currently reusable parameters to generate a fresh standard template, which means custom routing, outbounds and DNS may be removed. It does not require the number of users to stay the same.

Mode switching moves you between protocol modes, for example from Reality to TLS, and by default reuses only the main user UUID and email, with other users not migrated automatically and a clear warning before the switch.

The safety property is the part that makes repeated changes on a live server much safer. Any step that fails during reconfiguration, whether writing the configuration, starting the service or a health check, triggers an automatic rollback to the backed up configuration. Backup directories use a unique timestamp, so repeated reconfigurations do not collide.

That is a much stronger position than a script that overwrites your config and hopes for the best, and it is the reason to prefer this project over hand-editing when you are not sure yet which mode you want.

## SNI Guard and fail2ban are the security layer

In Reality plus Nginx mode, SNI Guard is enabled by default. Unknown SNI, empty SNI and abnormal TLS do not reach the Xray Reality backend, and the default is an isolation policy using ssl_reject_handshake, while advanced users can switch to a self hosted decoy site fallback or to a direct TCP rejection.

The README is careful about what this feature is for. It is used to reduce active probing and misconfiguration exposure, and it does not aim at perfect camouflage. That framing matters, because a feature described as reducing exposure is a filter, not a guarantee, and treating it as the latter is how people get surprised.

Alongside it, fail2ban protection is built in and the script can install it, and there is built in traffic statistics, traffic blocking, and GeoIP and GeoSite rule updates with scheduled updating. Updates are covered for the script itself, Xray, Nginx and certificates, and the README says backups and failure rollback are provided for key updates.

The same care about reversibility shows up in the service management table, where starting and stopping are plain systemd calls, systemctl start xray and systemctl stop xray for the proxy and the same pair for nginx.

For an operator, that combination, a default deny for unknown SNI, a ban tool for repeated failures, and updates that can be rolled back, is a reasonable baseline for a service that is exposed to the internet.

## Dual stack handling and the client information file

The IPv4 and IPv6 support is the piece with the most moving parts, and the README describes it in detail. At install time the script can automatically detect the server's public egress capability, validate A and AAAA records per domain independently, and generate the matching share links and Clash configuration.

That is a real problem to solve. A server with a public IPv4 and a broken or missing AAAA record will confuse clients that prefer IPv6, and the failure looks like a connectivity problem rather than a DNS problem. Detecting the capability and checking the records separately is the way to find that before your users do.

The share links follow the proposal from the DuckSoft issue in the XTLS repository, which is marked beta, and are compatible with Qv2ray, V2rayN and V2rayNG. The project also implements the XTLS proposal for mapping a custom string to a VLESS UUID, following the UUIDv5 standard, and notes that this requires client support.

Once the installation finishes, the client details are written to a file you can read directly:

```bash
cat /etc/idleleo/info/xray_info.inf
```

The directory layout is documented too. The main directory is /etc/idleleo, the Xray configuration is /etc/idleleo/conf/xray/config.json, the Nginx configuration sits under /etc/idleleo/conf/nginx/, the installation information is /etc/idleleo/conf/install_config.json, and the certificate files have their own place, with custom certificates named xray.crt and xray.key and placed in /etc/idleleo/cert, where the README warns you to mind permissions and expiry and to renew them yourself. Automatic Let's Encrypt certificates are supported, valid for three months, and are theoretically renewed automatically.

## The Rill assistant diagnoses, it does not change your server

There is an AI operations assistant in the project, called RillML, and the README describes its scope carefully.

It provides local adaptive operations capability for Xray, with a built in assistant that watches the health of the Xray and Nginx services in real time, diagnoses faults and suggests handling. It runs without an external API, and you reach it from the main menu with the option 9 or with idleleo --rill-agent.

The four capabilities are monitoring, diagnosis, judgement and mode. Monitoring observes the services and configuration state. Diagnosis locates the root cause and attaches a confidence level, high, medium, low or insufficient evidence. Judgement classifies the fault type and marks in the text whether automatic handling is allowed or only a suggestion. Mode sets whether it acts intelligently, only observes, or is safely disabled.

The important line is the last one: the AI judgement engine is still in testing, the advice is to treat its output as diagnosis guidance, and by default it does not modify the system. There are commands to install or repair the engine, check its status, run a diagnosis, verify the engine, safely disable judgement and uninstall the engine.

For a sysadmin, a local diagnostics assistant that refuses to act without being told to is a reasonable design. The alternative, a tool that quietly rewrites your proxy configuration based on a model's opinion, would be a hard sell on a production host, and the README's own caution is the right default to keep.

## Docker, the AI skill path, and the README's warnings

Two alternative deployment paths exist. Docker is supported, with an image that has Xray and Nginx preinstalled and the container able to use all the original script functions, and the repository ships a docker-compose file:

```bash
git clone https://github.com/hello-yunshu/Xray_bash_onekey.git
cd Xray_bash_onekey
docker compose up -d
docker attach xray-onekey
```

The compose file runs the container with host networking, adds the NET_ADMIN capability, sets the timezone, keeps named volumes for the configuration, certificates, info, logs and the acme.sh data, and caps resources at two CPUs and 512M of memory with json file logging limited to three files of 10m each.

The other path is an AI skill deployment, with a separate repository, Xray_bash_onekey_skill, that lets an AI tool such as Trae collect the information, generate a non interactive script, run it and return the VLESS link, instead of you SSHing in and answering interactive questions. The supported modes there are Reality, TLS, ws ONLY and XTLS ONLY.

The README's caution list is worth reading before you install anything. It says to use the defaults for anything you do not understand, to enable Cloudflare CDN only after the install finishes, that the script assumes basic Linux and networking knowledge, that a single server should run a single proxy on the default port 443, that custom string to UUIDv5 mapping needs client support, that users who already installed Nginx through LNMP or similar scripts should watch for conflicts, and most importantly: do not use this script in a production environment before verifying that it works. The author is named as providing limited support.

The release tags track the upstream Xray version, v3.2.9 on 2026-09-25, v3.2.8 on 2026-09-10 and v3.2.7 on 2026-09-09, the last push was on 2026-10-14, and the repository is not archived.

## Conclusion

Xray_bash_onekey suits a sysadmin who wants a working Xray and Nginx deployment on a fresh server in minutes and who accepts an interactive script rather than a configuration file they maintain by hand, and the backup and rollback behaviour around reconfiguration is the feature that makes it usable more than once. It is the wrong tool if you need a declarative configuration as code, if your server already runs Nginx through another stack such as LNMP, or if you are on a distribution the README does not support. Verify first which mode matches your traffic needs and your domain situation, then run the installer on a throwaway host and check the generated client information at /etc/idleleo/info/xray_info.inf before you point production at it.

## FAQ

### How do I install Xray_bash_onekey and open the management menu?

Run the published install script with bash <(curl -fsSL https://github.com/hello-yunshu/Xray_bash_onekey/releases/latest/download/install.sh). After installation, the management menu is opened with the idleleo command, and the same command has flags such as --show for installation information and --help for the list of options.

### Which install modes does Xray_bash_onekey support?

Five: Reality plus Nginx, which is the recommended mode, Nginx plus TLS with automatic Let's Encrypt certificates, ws/gRPC/xHTTP ONLY without TLS, XTLS ONLY for relay style use, and Docker. The transport modes can also be combined as ws+gRPC+xHTTP, with matching ports, paths, share links and QR codes generated for each.

### What happens if a reconfiguration fails in Xray_bash_onekey?

The current running configuration is backed up before anything changes, and any failing step, whether writing the configuration, starting the service or a health check, triggers an automatic rollback to that backup. Backup directories use a unique timestamp so repeated reconfigurations do not conflict.

### Does the AI operations assistant in Xray_bash_onekey modify the server automatically?

Not by default. The Rill assistant monitors the Xray and Nginx services, diagnoses faults with a confidence level and suggests handling, but the judgement engine is still in testing, it works in smart, observation only or safely disabled modes, and the README advises treating its output as diagnosis guidance.

## Sources

- [hello-yunshu/Xray_bash_onekey on GitHub](https://github.com/hello-yunshu/Xray_bash_onekey)
- [License: GPL-3.0](https://github.com/hello-yunshu/Xray_bash_onekey/blob/main/LICENSE)
- [Project website](https://hey.run)
- [README](https://github.com/hello-yunshu/Xray_bash_onekey/blob/main/README.md)
- [Releases](https://github.com/hello-yunshu/Xray_bash_onekey/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hello-yunshu-xray-bash-onekey