x-ui-pro: one script for an Xray panel behind nginx

The repository is one shell script and a readme

x-ui-pro is an open-source project that provides an auto-installation script for a lightweight and secure web proxy server. The project combines the features of x-ui, v2rayA, WARP, psiphon, Tor and nginx into one solution, described as offering many protocols and tools for bypassing internet restrictions.

The repository is remarkably small for what it does. The top level has media/ for the screenshots, a readme.md and x-ui-pro.sh. That is the entire codebase, and it is worth sitting with that for a moment. The script downloads and configures other people's software. It is an installer and a configuration generator, not an implementation of a proxy protocol, and it is the pieces it pulls in that do the actual work.

The feature list is what that combination buys. It handles WebSocket, GRPC, HttpUpgrade and XHTTP through nginx. It supports multiple users and configuration over port 443. It installs multiple domains behind one server and panel. It adds security and lower detection with nginx. It renews SSL automatically and reloads services daily. It backs up x-ui.db to /var/backups every day. It provides the X-UI and Xray and V2rayA admin web panel. It works with a Cloudflare CDN or IP. It ships 170 random fake HTML templates. It can change the country used by Tor and Psiphon. And it is Linux only.

The primary language is Shell, there are no GitHub releases beyond the numbered versions, and the most recent release is 13.2.0 from 2026-05-11, with the repository last pushed to on 2026-05-27.

The install is a piped command run as root

The installation command is long, and every part of it is an argument the script understands.

sudo su -c "$(command -v apt||echo dnf) -y install wget;bash <(wget -qO- raw.githubusercontent.com/GFW4Fun/x-ui-pro/master/x-ui-pro.sh) -panel 1 -xuiver v2.9.3 -cdn off -secure no -country xx"

Breaking it down is instructive. The first half makes sure wget exists, using apt or dnf depending on what is available. The second half fetches the script from the master branch of the repository and runs it with bash, with the arguments -panel 1, -xuiver v2.9.3, -cdn off, -secure no and -country xx.

The panel argument selects which admin panel you get, and the README lists the four options.

-panel 0-Alireza0_XUI  1-MHSanaei_XUI 2-FranzKafkaYu_XUI 3-AghayeCoder_tx-ui

So the values are indexes into four different upstream panel projects, which is a detail worth pausing on. The script does not implement a panel, it installs one of four, and choosing between them is choosing between other people's codebases with their own update histories and their own security posture. The default in the example is 1, which is MHSanaei's fork of the X-UI panel.

The -xuiver argument pins the XUI panel version, and the README says the default is the latest version, while the example pins 2.9.3. Pinning is the safer choice, since an unpinned panel version means an unpinned piece of a system that handles your credentials and your traffic configuration.

nginx in front, port 443, and the CDN switch

The architecture the script builds is nginx sitting in front of the proxy, which is what gives the project its low detection claim and its multiple protocol support.

The idea is that clients speak ordinary TLS on port 443 to nginx, and nginx forwards the connection to the Xray or V2ray core using WebSocket, GRPC, HttpUpgrade or XHTTP. From the outside the traffic looks like a website, and from the inside the protocol is whatever the core supports. Because nginx terminates the TLS and serves the domain, several domains can be added to one server and panel, and the README notes that adding a subdomain means creating an A record in DNS with no need to reinstall the panel.

The -cdn flag controls whether the domain points at a Cloudflare CDN. The README is explicit about the difference. With cdn on, access is only possible from the CDN IP, and with cdn off the origin is reachable directly. That is a meaningful operational difference: a CDN fronted deployment hides the origin address, and a direct deployment does not, at the cost of the CDN sitting in the path.

The -country flag filters who may connect. With a list such as -country ru,cn,de,fi,us only users from those countries are allowed to connect, and the value xx allows all countries. The README states that this works with cdn on. The list of valid country codes is given explicitly, which is a small sign of how the flag is implemented, since it is a client country check rather than a server region selection.

The fake HTML templates are the other part of the low detection story. The script can install one of 170 random templates as the site nginx serves, so a port 443 request that is not a proxy connection returns a plausible website instead of an error.

Secure mode moves work to the client

The -secure flag enables nginx authentication plus blocking of bad user agents, and the README marks it as for advanced users only.

What is blocked is a list of strings the script matches against the client user agent, and the list includes xray, v2ray, go-http-client, vpn, proxy, tunnel and bot. The purpose is to stop a probe that arrives with a recognisable agent from getting a clean answer from the server.

The important caveat is stated twice in the README, in the arguments section and again in the secure mode section. Secure mode requires the GFW Anti-DPI UA Random Patcher or MahsaNG on the client side only. In other words, the server side hardening only works if the client also randomises its user agent, and the two projects named are separate repositories that you install on the client.

The README also names a specific string to clean up, the phrase Go-http-client/x, and says it appears in the xray, v2ray and singbox cores. That is a hint about where the default agent string comes from, and it is the sort of detail that explains why the block list is written the way it is.

The final guidance in that section is the operationally important one. The points above are highly recommended, and you should always use port 443 and enable TLS. That is a statement that the configuration without TLS and without the standard port is the configuration most likely to be blocked, and it is a good reason to follow the defaults rather than improvise.

Hardening flags and the daily backup path

The script includes several operational switches beyond the installation itself, and these are the ones that matter after the first run.

The UFW switch enables the firewall and is described as preventing direct access to the xui, xray and v2ray ports. That is the point of it. The panel and the proxy cores have their own listening ports, and if those are reachable from the internet the nginx front is decorative. Turning on the firewall is the difference between the panel being a web application and being a public administration interface.

The clean key switch disables WARP, Psiphon and WARP clean key, and the WARP and Tor country switches set the exit country for those services, with US and XX used in the examples for a fixed and a random choice. There is also a WARP licence key argument, and a random template switch for the fake site.

The backup behaviour is documented rather than configured by a flag. The script backs up x-ui.db to /var/backups daily, and that file is the panel's database, holding the users, the inbounds and the configuration. A daily copy is a good default, and it is also a thing to check, because a backup directory nobody has looked at is only a backup until the day it is needed.

Two hardening commands in the README are outside the script entirely. One disables ICMP echo with sysctl on both IPv4 and IPv6, and one changes the SSH port away from 22 and updates the firewall rule and restarts sshd in the same command. The README also links a separate system optimisation script.

Running a root shell script from the internet deserves a moment's thought

The honest framing of this project is that the deliverable is a script that another script downloads and runs as root, and that the script installs and configures software from several other projects.

That is a normal shape for a self-hosted server installer, and the same pattern appears in many of these tools. It is also the pattern with the largest blast radius. A root shell that fetches a file over the network and executes it gives the author of that file, and anyone who can modify it, the ability to do anything to the host. The mitigating practices are unglamorous but real. Read x-ui-pro.sh before running it. Pin the panel version, as the example command does with -xuiver v2.9.3. Keep the panel and the proxy ports behind a firewall, which the -ufw switch does. Enable TLS on 443. And take the daily x-ui.db backup seriously.

The licence deserves a note too. The repository metadata does not declare a licence, so the permissions for reuse, modification and redistribution are whatever the LICENSE situation turns out to be, and there is no licence file in the top level listing. If you intend to fork it or use it commercially, that is a question to settle with the author rather than assume.

There is also the operational and legal reality that a proxy server is visible to the network it sits on and, in many jurisdictions, to the authorities. The country filters, the random templates and the CDN mode are all ways of reducing that visibility, and they are also ways of operating a service that some providers' terms of service prohibit. CDN providers set their own terms for what may be proxied through their network, and the project is built assuming that CDN fronting is a normal deployment mode. Read those terms before you depend on the arrangement.

Editorial conclusion

x-ui-pro fits a server administrator who wants a working proxy panel with nginx in front, TLS on port 443 and CDN support in one command rather than by assembling x-ui, Xray, v2rayA and nginx by hand, and who can read the script it runs. It does not fit a managed platform, since everything is a single Linux host with a root level installer, and it does not fit anyone who cannot audit what they execute. Verify three things before you run it: the script you fetch, since the install command pipes a remote file into a root shell and the version that runs is whatever is on the master branch at that moment, the panel fork you select with -panel, since the four options are different upstream projects with different trust histories, and the terms of the CDN and provider you point the traffic through, since a Cloudflare fronted proxy is a different arrangement from a self-hosted one in both performance and policy.

Frequently asked questions

Official sources

1. GFW4Fun/x-ui-pro on GitHub
2. Issues
3. README
4. Releases