mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-06 06:02:09 +03:00
Chester Fishmans
b42a1c0ba1
* fix(systemd): harden shipped x-ui unit files The units ran the panel as root with no sandboxing: systemd-analyze security rates them 9.6 UNSAFE. Add NoNewPrivileges, ProtectSystem=full with ReadWritePaths for the default XUI_DB_FOLDER/XUI_BIN_FOLDER/XUI_LOG_FOLDER stores, kernel and clock protections, UMask=0077, RestrictAddressFamilies, a CapabilityBoundingSet with NET_ADMIN/NET_BIND_SERVICE/NET_RAW and SystemCallFilter=@system-service. PrivateTmp is deliberately omitted: the web updater hands a path inside the system temp directory to a systemd-run transient unit, which does not share the service's private tmpfs. ProtectHome stays read-only because installs keep TLS certificates under the root home directory. Fixes #6605 * fix(systemd): ship ReadWriteDirectories= alias for systemd < 231 ReadWritePaths= only exists since systemd 231; install.sh still supports CentOS 7 (systemd 219), where the directive is ignored and ProtectSystem=full would leave the panel state directory read-only, breaking its database. * fix(systemd): keep root's DAC bits and regenerate the write paths Two follow-ups to the hardening, both reported by review on #6718. CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH were dropped from the bounding set. Root holds them normally, and a bounding set is subtracted from root too: the panel could no longer read a private key it does not own (a Caddy-issued certificate under its own state dir, an acme.sh home, any 0600 file owned by another account). That fails quietly for TLS -- the panel listener logs the tls.LoadX509KeyPair error and keeps serving plain HTTP, and Xray inbounds using that key stop -- so both bits stay. ProtectSystem=full plus a hard-coded ReadWritePaths list broke installs whose XUI_DB_FOLDER/XUI_LOG_FOLDER/XUI_BIN_FOLDER live outside the defaults, and the workaround of editing the unit did not survive an update, because install.sh and update.sh reinstall the unit from the release tarball. The folders actually in use are now resolved from the same env file the unit passes to the panel and regenerated into x-ui.service.d/10-xui-write-paths.conf on every install and update, so a relocated store stays writable and the list is not reset. The unit keeps the plain-install defaults plus XUI_SERVICE, which the in-panel updater needs when systemd-run is unavailable and it falls back to a child process that inherits this sandbox while update.sh lands the unit again. Uninstall removes the drop-in with the unit. * fix(systemd): keep the seccomp whitelist off old systemd, tighten the rest Review of the previous head found that SystemCallFilter=@system-service plus SystemCallErrorNumber=EPERM is a hard regression on the platforms this PR means to keep working. @-named filter groups exist from systemd 239 on, and older systemd does not ignore an unknown group name: on <231 the name fails to resolve and the filter stays the built-in whitelist of execve/exit/exit_group/ rt_sigreturn/sigreturn, on 231..238 it degrades to @default. Either way the panel then gets EPERM on read/openat/mmap/clone and cannot start -- a CentOS 7 or Ubuntu 18.04 install would come up dead after this update. The two directives now live in the generated drop-in and are written only when "systemctl --version" reports 239 or newer, so old hosts keep the rest of the hardening and simply go without seccomp. The same review listed three more items, all addressed here: - a comment claiming ProtectSystem=full "keeps everything outside /var, /run and the listed ReadWritePaths read-only" -- that is `strict`; `full` locks down /usr, /boot, /efi and /etc; - /etc/systemd/system was granted writable for the in-panel updater's fallback, but that fallback cannot work under this sandbox at all: update.sh also stages the release archive beside the main folder, replaces /usr/bin/x-ui and calls the package manager. The entry is gone and update.sh now stops up front with one clear message when the directories it needs are read-only, instead of failing halfway with "Failed to download x-ui"; - CAP_DAC_READ_SEARCH is redundant next to CAP_DAC_OVERRIDE, so the bounding set keeps just the latter. Relocating a store by editing the env file alone is documented in the unit and in the generated drop-in: the drop-in is only written by install/update, so one of those has to be re-run afterwards. Verified with a local harness (9 checks: plain defaults, relocated store read from the env file, the same list produced by update.sh, duplicate collapse, seccomp present at systemd 249 and absent at 238, read-only guard) and bash -n on install.sh, update.sh, x-ui.sh. systemd-analyze is not available here, so the unit files themselves are unverified by a parser. * fix(systemd): actually wire the read-only guard, drop the superseded drop-in Re-review of the previous head caught two leftovers from that commit: - require_writable_update_paths was defined but never called, so the guard the unit comments, the commit message and the PR comment promise did not exist at all. It is now called at the top level, before install_base, i.e. before anything with a side effect: a sandboxed fallback run stops with one clear message instead of failing halfway, which on a relocated main folder meant the old install removed and the service folder rewritten before dying on /usr/bin. - the drop-in this branch replaced (10-xui-write-paths.conf) is no longer written or referenced, but nothing removed it either. Whoever installed the build that wrote it keeps its wider list, including the writable service folder, until it is deleted by hand. Both generators now remove it. Harness extended to 11 checks: the superseded file is gone after a run, the guard is actually called, plus the previous nine (defaults, env-file relocation, same list from update.sh, dedupe, seccomp at 249 / absent at 238, read-only guard) and bash -n on the three scripts. * fix(systemd): correct two comments and keep spaces out of the path list Second-opinion review of the previous head (two models, both asked to state platforms and versions) produced three actionable items: a wrong comment kept from the earlier commits, a wrong generalisation about the filter groups, and a path-list case that would leave the panel unable to start. - the ProtectSystem= comment claimed strict leaves /var and /run writable. It does not: strict mounts the whole hierarchy read-only and only the kernel API filesystems stay as they are. The sentence was already wrong before this branch and moving it to ProtectSystem=full did not fix it. - "the @-named filter groups need systemd >= 239" is the wrong generalisation: named groups exist since 231, it is @system-service that arrived in 239. The unit files, both script comments and the drop-in body now name the group. - a folder containing whitespace (XUI_DB_FOLDER="/srv/panel data") was written into ReadWritePaths= verbatim. That directive is a whitespace-separated list, so the entry splits into "-/srv/panel" and "data", and systemd rejects the whole drop-in: the panel then does not start at all. Such folders are left out and reported to the operator instead; the other paths are still written. Harness extended with three checks for the whitespace case (folder left out, remaining paths intact, warning emitted) and the duplicate-store case now reads its own env file instead of the previous one, so it tests what it claims. 14 checks plus bash -n on the three scripts, all passing. * fix(systemd): act on the independent review of the drop-in generator A read-only review of the branch head (another model, given the diff and the sources, asked to cite only verified lines) confirmed the earlier work and turned up four items that are fixed here: - a folder name carrying a literal % went into ReadWritePaths= as it was, and systemd expands %-specifiers in unit files: with XUI_DB_FOLDER=/srv/x%-ui the entry no longer named the directory the panel writes to and the panel could not write its database. The path is now emitted as %%; the duplicate check keeps comparing the unescaped value. - systemd older than 229/242/244 does not know NoNewPrivileges, ProtectClock, ProtectHostname and ProtectKernelLogs. It logs them and carries on, so CentOS 7 (systemd 219, which install.sh explicitly supports) runs with less hardening than the unit lists. install.sh and update.sh now print which protections need a newer systemd, which ones still apply, and that upgrading systemd is what changes it. - the updater's writability guard asked [[ -w ]] about the parent directories. It creates and removes a probe file instead, so an immutable attribute or a full filesystem is caught as well (a read-only mount was already caught). - the generator's comment claimed to resolve the folders the service actually uses, while the shipped unit hard-codes WorkingDirectory= and ExecStart= under /usr/local/x-ui. The comment now states what XUI_MAIN_FOLDER really feeds -- the location install.sh/update.sh install into and the base for a relative XUI_BIN_FOLDER -- and that a relocated main folder needs the unit edited too. Rejected from the same review, with the evidence: that [[ -w ]] cannot see a read-only mount (access(W_OK)/faccessat consults __mnt_is_readonly before the mode bits), and that the /etc ReadWritePaths entry is an exception granted for /etc rather than a default store already in the list. Harness extended: 19 checks (escaped %, the old-systemd note, whitespace and duplicate folders, seccomp gating, the read-only guard) plus bash -n on the three scripts, all passing. * fix(systemd): name the hardening old systemd really ignores The old-systemd note fired only below 239 and listed wrong versions: RHEL 8 (239) and Debian 10 (241) silently lose ProtectHostname and RestrictSUIDSGID (242), ProtectKernelLogs (244) and ProtectClock (245) with no note, while CentOS 7 was told NoNewPrivileges (187) and ProtectHome=read-only (214) were not applied although both are. The note is now built from a directive/version table taken from systemd.exec(5) and lists only what the running systemd lacks. Also drop the removal of 10-xui-write-paths.conf: only an intermediate commit of this branch wrote that file, no release ever shipped it. --------- Co-authored-by: Кот <kot@zeroclaw.local> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>
English | فارسی | العربية | 中文 | Español | Русский | Türkçe
3X-UI is an advanced, open-source web control panel for managing Xray-core servers. It provides a clean, multi-language interface for deploying, configuring, and monitoring a wide range of proxy and VPN protocols — from a single VPS to multi-node deployments.
Built as an enhanced fork of the original X-UI project, 3X-UI adds broader protocol support, improved stability, per-client traffic accounting, and many quality-of-life features.
Important
This project is intended for personal use only. Please do not use it for illegal purposes or in a production environment.
Features
- Multi-protocol inbounds — VLESS, VMess, Trojan, Shadowsocks, WireGuard, AmneziaWG, TUIC v5, Hysteria2, MTProto, HTTP, SOCKS (Mixed), Dokodemo-door / Tunnel, and TUN.
- Modern transports & security — TCP (Raw), mKCP, WebSocket, gRPC, HTTPUpgrade, and XHTTP, secured with TLS, XTLS, and REALITY.
- AmneziaWG built in — DPI-resistant WireGuard runs inside the panel on a userspace network stack, with no kernel module, DKMS, or extra packages to install.
- TUIC v5 sidecar — High-performance QUIC-based proxy with native UDP relay traffic metering, 0-RTT handshakes, and BBR congestion control.
- MTProto proxies — per-client FakeTLS secrets, ad-tags, and quotas, applied live without dropping existing connections.
- Fallbacks — serve multiple protocols on a single port (e.g. VLESS and Trojan on 443) using Xray's fallback support.
- Per-client management — traffic quotas, expiry dates, IP limits with trusted-address exemptions, HWID device limits, scheduled renewal cycles, live online status, and one-click share links, QR codes, and subscriptions.
- Traffic statistics — per inbound, per client, and per outbound, with reset controls.
- Multi-node support — manage and scale across multiple servers from a single panel, including cloning inbounds onto other nodes.
- Outbound & routing — WARP, NordVPN, PIA, custom routing rules, load balancers with balancer-to-balancer fallback, and outbound proxy chaining. Bundled geosite and geoip categories are browsable straight from the rule editor.
- Built-in subscription server — raw, JSON, and Clash output, auto-selected from the client's User-Agent, plus custom page templates.
- Telegram and Discord bots for remote monitoring and management.
- RESTful API with scoped, optionally expiring tokens and an in-panel API reference.
- Installable panel (PWA) — pin 3X-UI to a desktop or phone home screen.
- Flexible storage — SQLite (default) or PostgreSQL.
- 13 UI languages with dark and light themes.
- Fail2ban integration for enforcing per-client IP limits.
Screenshots
Click to expand
Quick Start
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)
To install a specific version, append its tag (e.g. v3.7.0):
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh) v3.7.0
To install the rolling dev build (latest per-commit pre-release from main, not a stable release), pass dev-latest:
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh) dev-latest
During installation a random username, password, and access path are generated. After installation, run x-ui to open the management menu, where you can start/stop the service, view or reset your login credentials, manage SSL certificates, and more.
Every release asset is published with a .sha256 sum next to it. Both install.sh and the updater verify the archive against that sum and abort on a mismatch.
For full documentation — installation, configuration, operations, and the complete API reference — visit docs.sanaei.dev.
Unattended install
The installer also runs non-interactively for cloud-init.
Set XUI_NONINTERACTIVE=1 (or pipe with no TTY) and it installs end-to-end with
zero prompts, generating random credentials and writing them to
/etc/x-ui/install-result.env. See deploy/ for:
- Cloud-init user-data — unattended install on any cloud (Hetzner/AWS/DO/Vultr/GCP/Azure/Oracle)
- Hetzner Cloud notes — cloud-init deployment on Hetzner
Supported Platforms
Operating systems: Ubuntu, Debian, Armbian, Fedora, CentOS, RHEL, AlmaLinux, Rocky Linux, Oracle Linux, Amazon Linux, Virtuozzo, Arch, Manjaro, Parch, openSUSE (Tumbleweed / Leap), Alpine, and Windows.
Architectures: amd64 · 386 · arm64 (aarch64) · armv7 · armv6 · armv5 · s390x.
Database Options
3X-UI supports two backends, chosen during the install:
- SQLite (default) — a single file at
/etc/x-ui/x-ui.db. Zero setup, ideal for small and medium deployments. - PostgreSQL — recommended for high client counts or multi-node setups. The installer can install PostgreSQL locally for you, or accept a DSN to an existing server.
At runtime the backend is selected via environment variables (the installer writes these to /etc/default/x-ui for you):
XUI_DB_TYPE=postgres
XUI_DB_DSN=postgres://xui:password@127.0.0.1:5432/xui?sslmode=disable
Migrating an existing SQLite install to PostgreSQL
x-ui migrate-db --dsn "postgres://xui:password@127.0.0.1:5432/xui?sslmode=disable"
# then set XUI_DB_TYPE and XUI_DB_DSN in /etc/default/x-ui and restart:
systemctl restart x-ui
The source SQLite file is left untouched; remove it manually once you have verified the new backend.
Docker
The default docker compose up -d keeps using SQLite. To run with the bundled PostgreSQL service, uncomment the two XUI_DB_* env lines in docker-compose.yml and start with the profile:
docker compose --profile postgres up -d
The image bundles Fail2ban (enabled by default) to enforce per-client IP limits. Fail2ban bans offenders with iptables, which requires the NET_ADMIN capability. docker-compose.yml already grants it via cap_add; if you start the container with docker run instead, add the capabilities yourself, otherwise bans are logged but never applied:
docker run -d --cap-add=NET_ADMIN --cap-add=NET_RAW ... ghcr.io/mhsanaei/3x-ui
Environment Variables
| Variable | Description | Default |
|---|---|---|
XUI_DB_TYPE |
Database backend: sqlite or postgres |
sqlite |
XUI_DB_DSN |
PostgreSQL connection string (when XUI_DB_TYPE=postgres) |
— |
XUI_DB_FOLDER |
Directory for the SQLite database file | /etc/x-ui |
XUI_DB_MAX_OPEN_CONNS |
Maximum open connections (PostgreSQL pool) | — |
XUI_DB_MAX_IDLE_CONNS |
Maximum idle connections (PostgreSQL pool) | — |
XUI_INIT_WEB_BASE_PATH |
The initial URI path for the web panel | / |
XUI_ENABLE_FAIL2BAN |
Enable Fail2ban-based IP-limit enforcement | true |
XUI_LOG_LEVEL |
Log verbosity (debug, info, warning, error) |
info |
XUI_DEBUG |
Enable debug mode | false |
XUI_TUNNEL_HEALTH_MONITOR |
Enable the tunnel health monitor (probes a URL and restarts xray after repeated failures; a restart drops all clients) | false |
XUI_TUNNEL_HEALTH_PROXY |
Proxy the probe is sent through; point it at a local xray inbound so the probe tests the tunnel (e.g. socks5://127.0.0.1:1080). Empty means the probe only checks host connectivity |
— |
XUI_TUNNEL_HEALTH_URL |
URL probed for tunnel health | https://www.cloudflare.com/cdn-cgi/trace |
XUI_TUNNEL_HEALTH_INTERVAL |
Interval between probes | 30s |
XUI_TUNNEL_HEALTH_TIMEOUT |
Per-probe timeout | 10s |
XUI_TUNNEL_HEALTH_FAILURES |
Consecutive failures before a restart is triggered | 3 |
XUI_TUNNEL_HEALTH_COOLDOWN |
Minimum delay between consecutive restarts | 5m |
NODE_TOKEN_ENCRYPTION |
Encryption at rest for node API tokens: off, migration, or required (note: no XUI_ prefix) |
off |
XUI_NODE_TOKEN_KEY_FILE |
JSON keyring (mode 0600) holding the active key id and its base64 32-byte keys |
/etc/x-ui/node_token_key.json |
XUI_NODE_TOKEN_KEY |
A single base64 32-byte key, used only when the key file cannot be loaded | — |
The complete list is on the environment variables reference.
Supported Languages
The panel UI is available in 13 languages:
English · فارسی · العربية · 中文（简体） · 中文（繁體） · Español · Русский · Українська · Türkçe · Tiếng Việt · 日本語 · Bahasa Indonesia · Português (Brasil)
Contributing
Contributions are welcome. Please read the Contributing Guide before opening an issue or pull request.
A Special Thanks to
Acknowledgment
- Iran v2ray rules (License: GPL-3.0): Enhanced v2ray/xray and v2ray/xray-clients routing rules with built-in Iranian domains and a focus on security and adblocking.
- Russia v2ray rules (License: GPL-3.0): This repository contains automatically updated V2Ray routing rules based on data on blocked domains and addresses in Russia.
Community Tools
Tools and integrations built by the community around 3x-ui.
- terraform-provider-3x-ui (License: MIT): Manage inbounds, clients, panel settings, and Xray configuration as code with Terraform / OpenTofu.
- 3X-UI Manager (License: MIT): Native Android client for 3x-ui — dashboard, inbounds, clients with QR sharing, nodes and multi-panel management. Available on F-Droid.
Support project
If this project is helpful to you, you may wish to give it a🌟
Star History