# wulabing/Xray_onekey: an Nginx-fronted VLESS + XTLS installer, and why its own README now points elsewhere > Xray_onekey is a shell installer that stands up a VLESS + TCP + TLS proxy with Nginx in front, on Debian, Ubuntu, Rocky, Alma, Oracle Linux or CentOS. The project still ships fixes, but its README now recommends REALITY and a different repository for new nodes. **wulabing/Xray_onekey** — Xray 基于 Nginx 的 VLESS + XTLS 一键安装脚本 - Repository: https://github.com/wulabing/Xray_onekey - Stars: 9,249 · Forks: 3,459 - Language: Shell - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/wulabing-xray-onekey ## The problem Xray_onekey solves, and the users it assumes Standing up a working VLESS endpoint by hand means editing Xray's JSON config, issuing a certificate, deciding whether a web server sits in front, and wiring the whole thing into systemd. Xray_onekey collapses that into one shell script. It is aimed at people who already know what a TLS handshake is: the README states plainly that using it requires Linux fundamentals and hands-on experience, some knowledge of computer networking, and basic computer skills. That is not marketing modesty. The script asks for a domain and a certificate path, and the README's advice for everything else is to accept the default value. If you do not understand a setting, the documentation says, use the script's default for everything except the domain name. The intended user is therefore someone running a personal node who wants the configuration correct without reading Xray-core's config schema, not a platform team provisioning proxy infrastructure for an organisation. ## Two install paths: Nginx in front versus Xray in front The repository offers two distinct topologies, and the branch you fetch determines which one you get. The Nginx-forward path installs VLESS + TCP + TLS + Nginx + WebSocket, with Nginx terminating TLS and Xray listening behind it. The main-branch path installs VLESS + TCP + TLS + Nginx with flow control set to xtls-rprx-vision, meaning Xray handles the TLS layer itself. That second path also supports a coexistence mode in which the vision inbound and a VLESS + TCP + TLS + Nginx + WebSocket fallback run side by side. The distinction matters because the README's first paragraph warns that nested TLS caused by placing Nginx in front may lead to connection blocking, and directs readers to wulabing/xray_docker for REALITY. In other words, the project's own documentation treats the Nginx-forward configuration as the legacy option and the Xray-in-front configuration as the current one. The repository layout reflects this split: install.sh at the top level, alongside config/, binary/, basic/ and ss_whitelist/ directories. ## Installing Xray_onekey and running a first node Prerequisites come first: a domain name with its A record pointed at the server, and wget available. The README gives a single command per topology. For the Xray-in-front build, with Xray terminating TLS and xtls-rprx-vision flow control, the documented command is: ```bash wget -N --no-check-certificate -q -O install.sh "https://raw.githubusercontent.com/wulabing/Xray_onekey/main/install.sh" && chmod +x install.sh && bash install.sh ``` The script downloads itself, makes itself executable and runs. Expect an interactive prompt asking for the domain and the settings it needs; the README's guidance is to keep the defaults for anything you do not recognise. For the older Nginx-in-front build with WebSocket, the README points at a different branch: ```bash wget -N --no-check-certificate -q -O install.sh "https://raw.githubusercontent.com/wulabing/Xray_onekey/nginx_forward/install.sh" && chmod +x install.sh && bash install.sh ``` After installation, the configuration lives at /usr/local/etc/xray/config.json and the service is managed by systemd. The README's troubleshooting examples use journalctl -u xray and systemctl restart xray, which tells you the unit name is xray. Logs go to /var/log/xray/error.log, with one documented exception described below. The import link format the script produces follows the specification in XTLS/Xray-core issue 91, linked from the README. ## The WebSocket deprecation warning that never reaches your log file Anyone running the Nginx-forward topology should know about a logging quirk the README documents in detail. Xray has marked the WebSocket transport as deprecated. Since Xray-core v26.1.23, starting an inbound with the ws transport prints a warning stating that the feature is deprecated, not recommended for using, and might be removed. The warning is emitted before the log file is created, so it appears only in journalctl -u xray and never in /var/log/xray/error.log. If you have been checking only the error log for signs of trouble, you have been missing the one message that tells you the transport is on a removal path. The practical consequence is that a WebSocket-based node is a migration candidate, not a long-term configuration, and the README's own recommendation is to move to REALITY or XHTTP. ## The v1.4.0 certificate bug that silently broke existing nodes The most consequential item in the release history is a notice for existing users: nodes installed with v1.3.11 or earlier had an inbound TLS configuration that never actually loaded any certificate, so clients could not complete the TLS handshake. The remedy is either a reinstall or a manual edit, renaming "xtlsSettings" to "tlsSettings" in /usr/local/etc/xray/config.json and then running systemctl restart xray. This is the kind of failure that is easy to misdiagnose, because the service starts cleanly and the config parses; only the handshake fails. It also sets a floor for how much you should trust an old pinned copy of the script. If you are running a node you set up years ago and never touched, check the config key before assuming the problem is on the client side. ## What v1.4.1 fixed, and what it says about the script's maintenance The v1.4.1 release notes describe four fixes, each tied to a numbered issue. On Debian 13, the script previously installed libpcre3-dev, which Debian 13 removed; because it was part of a single apt install command, the whole command failed and packages listed alongside it, including openssl, were never installed. Those pcre, zlib and openssl development packages were leftovers from when Nginx was compiled from source, and Nginx now comes as a binary from the official repository, so they were removed. The port-in-use check no longer force-kills Nginx: it used to kill -9 whatever held port 80, leaving nginx.service in a failed (Result: signal) state when that was a running Nginx; it now tries systemctl stop nginx first and falls back to kill -9 only if the port is still held. A limits.conf corruption bug is fixed: when /etc/security/limits.conf does not end with a newline, the appended * soft nofile 65536 was concatenated onto the previous line, corrupting the existing limit and defeating the line-anchored cleanup, so repeated installs accumulated garbage and the file-descriptor tuning never took effect. Finally, the BBR step now validates the source before executing, printing its version and aborting if validation fails, because the upstream ylx2016/Linux-NetSpeed repository can serve an outdated script. The last push to the repository was on 2026-08-15, so the fixes are recent rather than historical. ## Where Xray_onekey is the wrong tool, and what to use instead The clearest limitation is stated by the project itself: the Nginx-in-front plus nested TLS structure can be targeted and blocked, and the README recommends migrating to REALITY or XHTTP for the long run. The alternative it names is wulabing/xray_docker, the same maintainer's Docker-based project, which the README presents as the REALITY path. The difference in approach is not cosmetic. Xray_onekey is an imperative shell script that mutates a host: it installs packages, edits /etc/security/limits.conf, manages systemd units and writes /usr/local/etc/xray/config.json directly. xray_docker packages the same kind of endpoint as a container, which changes how upgrades, rollbacks and host state are handled. If you are provisioning more than a handful of nodes, or you want the proxy isolated from the host's package manager, the container route is the one the project points at. Xray_onekey is also a poor fit for CentOS 7: the README notes that CentOS 7 reached end of life on 2024-06-30, that official repositories moved to vault.centos.org, and that the script prints a warning and continues but dependency installation may fail. Support expectations are low too. The README states that the maintainer provides only very limited support and directs users to the Telegram discussion group. ## Licence and upgrade cost The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code. It says nothing about the legal status of running a proxy node in your jurisdiction, which is a separate question the repository does not address. On upgrade cost: because the installer mutates host state rather than declaring it, re-running the script is the documented update path, and the v1.4.1 limits.conf fix exists precisely because repeated installs used to accumulate damage. Budget for the fact that an upgrade touches system packages, systemd units and security limits, not just the Xray binary. ## Conclusion Adopt Xray_onekey if you already run a VLESS + TCP + TLS node on a supported distribution and want a maintained installer with a documented upgrade path; the v1.4.1 fixes for Debian 13 dependencies, the port-80 kill behaviour, limits.conf corruption and BBR source validation are concrete reasons the current script is better than a pinned old copy. Do not adopt it for a new deployment unless you have read the README's own warning that Nginx-in-front nested TLS can be targeted and blocked and that REALITY is the recommended option, in which case wulabing/xray_docker is the repository the project points you to. Before installing, verify three things: that your node was not built with v1.3.11 or earlier, because those inbounds never loaded a certificate and need a reinstall or a rename of "xtlsSettings" to "tlsSettings" in /usr/local/etc/xray/config.json followed by systemctl restart xray; that your distribution is on the supported list, since CentOS 7 reached end of life on 2024-06-30 and its repositories moved to vault.centos.org; and that you can live with WebSocket transport, which Xray has marked deprecated since Xray-core v26.1.23 and may remove. ## FAQ ### What is Xray_onekey and who is it for? It is a Shell installer that sets up a VLESS + TCP + TLS endpoint with Nginx, on Debian, Ubuntu, Rocky Linux, AlmaLinux, Oracle Linux or CentOS. The README states that using it requires Linux fundamentals, networking knowledge and hands-on experience, and that the maintainer provides only very limited support. ### How do I install Xray_onekey on Linux? Prepare a domain with an A record and install wget, then fetch and run the script from the branch matching your topology. The Xray-in-front build uses the main branch and supports xtls-rprx-vision flow control; the Nginx-in-front WebSocket build uses the nginx_forward branch. ### Which operating systems does Xray_onekey support? Debian 10 or newer (Debian 12 and 13 recommended), Ubuntu 20.04 or newer, Rocky Linux 8 or newer, AlmaLinux 8 or newer, Oracle Linux 7 or newer, and CentOS 7 or newer including Stream. The README warns that CentOS 7 reached end of life on 2024-06-30 and that dependency installation may fail on it. ### Why is WebSocket transport deprecated in Xray_onekey? Xray has marked the ws transport as deprecated, and since Xray-core v26.1.23 starting such an inbound prints a warning that the feature is not recommended and might be removed. The README notes that this warning is emitted before the log file is created, so it appears only in journalctl -u xray and never in /var/log/xray/error.log. ### My Xray_onekey node fails the TLS handshake. What should I check? The v1.4.0 notes state that nodes installed with v1.3.11 or earlier had an inbound TLS configuration that never loaded a certificate. The fix is to reinstall, or to rename "xtlsSettings" to "tlsSettings" in /usr/local/etc/xray/config.json and then run systemctl restart xray. ### Is there an alternative to Xray_onekey for REALITY? Yes. The README warns that the Nginx-in-front nested TLS structure can be blocked and recommends REALITY, pointing readers to wulabing/xray_docker. That project packages the endpoint as a container rather than mutating the host with a shell script. ## Sources - [Issues](https://github.com/wulabing/Xray_onekey/issues) - [License: MIT](https://github.com/wulabing/Xray_onekey/blob/main/LICENSE) - [README](https://github.com/wulabing/Xray_onekey/blob/main/README.md) - [wulabing/Xray_onekey on GitHub](https://github.com/wulabing/Xray_onekey) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wulabing-xray-onekey