x-ui-yg: a Chinese installer script with two closed binaries at the repository root

Installation is a curl into bash, offered in two spellings

The whole installation is two one line commands and they differ only in the fetch tool:

bash <(wget -qO- https://raw.githubusercontent.com/yonggekkk/x-ui-yg/main/install.sh)

bash <(curl -Ls https://raw.githubusercontent.com/yonggekkk/x-ui-yg/main/install.sh)

Both pull install.sh from the main branch of the repository and hand it to bash through process substitution, so nothing is written to disk before it runs. That is the documented path, and it is worth naming what it means: the script that runs is whatever is on the main branch at the moment of the fetch, not a tagged release, so the version you get is not the version you can name afterwards. The repository does carry two release tags, xui_yg and xui_ygb, but neither is referenced by the install command. The README is in Chinese throughout, with a blog post linked for related notes and points to watch.

Two binaries at the root, and the README says they are not open sourced

The repository contains nine entries and two of them are executables, one named for amd64 and one for arm64, sitting at the top level next to install.sh. The README has one line about them, in the declaration section at the bottom: the binary files are not open sourced, and anyone who minds should not install or use it. That sentence is the most consequential line in the document and it is placed after the credits rather than at the top. Everything a reviewer can audit is the script and the configuration; the artefact that actually runs on the server is a compiled file with no published source. For a tool whose entire surface is a panel that manages network configuration for an operator, that is the line to weigh before running anything. The declaration also states that all code comes from integrating code from reference projects on GitHub together with ChatGPT.

Four upstream projects are credited as the source of the code

The declaration names four projects as the references the code is built from. The first is vaxilu/x-ui, the original panel, which the README also names at the top as the project whose panel settings this modification tries to match. The second is MHSanaei/3x-ui, a panel with the same shape of purpose under a different maintainer. The third is qist/xray-ui. The fourth is warpplus, linked to the bepass-org repository, which is where the VPN component referenced later in the feature list comes from. So this is a fork of a fork of a panel, with one feature borrowed from an unrelated VPN client project, plus generated code. Two things follow for anyone reading it. Panel behaviour is comparable to the originals because that is the stated goal, so documentation for x-ui will largely apply. And the licence position is unclear: this repository records no licence at all, and each of the four upstream projects carries its own terms.

Panel settings are deliberately kept aligned with the original

The first heading in the README states the design intent rather than a feature: this is a slimmed down modified version of x-ui, and the relevant settings in the panel are kept as consistent as possible with the original by vaxilu. That single sentence explains a lot about the project. A panel that keeps the original's setting names and layout can be documented by the original's documentation and migrated by people who have used it, which is why a slimmed fork is useful at all. The cost is that nothing here is a clean design, and the local additions sit alongside originals that were written for a different scope. The other stated goals are deployment shaped rather than feature shaped: direct installation on VPS machines that are pure IPv4, pure IPv6, amd64, or arm64, with Alpine supported and the newest Ubuntu recommended. That recommendation is a signal about which combination the author tests, and the two root binaries match the two architectures named.

The protocol list in the description is longer than the panel it wraps

The repository description is the only place the feature set is enumerated, and it is a long single sentence. It says the script supports Hysteria2, the Xhttp transport protocol, ENC encryption, and MLDSA65 encryption. It also describes an integrated Argo setup with fixed and temporary tunnels that can coexist, and Psiphon as a free VPN with 30 countries for routing or splitting traffic. The last clause is about output rather than transport: support for configuration output of some node aggregation subscriptions, of sing-box subscriptions, and of clash-meta subscriptions. Read together, that is a panel front end over more than one protocol implementation, with subscription generation for two client families. What the README does not do is document any of it. The video tutorial list is the closest thing to documentation in the page, with eight videos covering reality modes, the Argo tunnels, multi protocol aggregate subscriptions, Alpine support, multi IP splitting, the WARP and Psiphon switching, Xhttp, and Hy2 with self signed and IP certificates.

Subscription nodes are generated locally, and that is a stated design choice

One line in the README addresses a specific worry and is worth reading as a design claim rather than as marketing. It states that the subscription nodes for this project are generated locally and that it does not use node conversion or other third party external link references, so there is no need to worry about the subscription being seen by the author of an external link. That is a narrow and verifiable claim in a category where subscription conversion services are common: the generated configuration is produced on the server rather than handed to another service. It is also the reason the tree contains a config.json and a version file, since a locally generated subscription needs configuration and a version to be versioned. Two other root files have no explanation anywhere in the page. One is ssh.yml, whose contents and purpose are not described anywhere in the visible text, and the other is the version file, which the install script presumably reads. Their roles are inferred from their names, not from anything stated.

Docker lives in another repository, and two tags stop in mid 2025

The Docker version is not in this repository. A separate repository maintained by ShaoG-R holds it, and the README links it as such, so container support is a fork of the fork rather than a feature of it. That division also splits the maintenance burden across two owners, which is worth knowing before you pick an install method. The rest of the page is contact information and acknowledgements. The author runs a blog, a YouTube channel, a Telegram group and a Telegram channel, all four linked. There is a tip request addressed to a WeChat account, and a request for a star on the repository. The homepage recorded for the project is not a repository or a documentation site at all but an individual blog post, on a Blogspot address, which means the project's primary written documentation lives outside version control in a blog engine that can change. The two releases are dated 2025-06-10 and 2025-03-12, while the most recent commit is dated 2026-09-15.

Editorial conclusion

x-ui-yg fits an operator who wants the x-ui panel set up by a single script on a supported architecture and is comfortable with the panel being a fork rather than the original. It does not fit anyone who needs to audit or build the panel binary, because two architecture specific binaries sit at the repository root and the README states plainly that the binary files are not open sourced and that those who mind should not install it. Before running the script, read the declaration: the code is described as an integration of four reference projects and a language model, and no licence is recorded for the repository.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yonggekkk/x-ui-yg on GitHub