mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-06-05 20:54:14 +00:00
Xray panel supporting multi-protocol multi-user expire day & traffic & ip limit (Vmess & Vless & Trojan & ShadowSocks & Wireguard)
dokodemo-doorfail2banhttprealityshadowsocksshadowsocks2022socks5trojanutlsvlessvmesswireguardxtlsxtls-rprx-visionxtls-rprx-vision-udp443
4f8b0b90c8
Adds an initial, intentionally minimal scaffold for a dedicated SOCKS5
inbound (Xray 'socks' protocol, RFC 1928). The existing 'mixed' inbound
already supports SOCKS+HTTP on the same port, but several deployments
need a pure SOCKS5 inbound — for example chained outbounds and clients
that don't tolerate HTTP CONNECT on the same listener.
This PR is purposely a scaffold so other contributors can finish the
full integration (sub link generation, routing UI helpers, Xray runtime
AddUser hooks, translations, docs, tests). It does NOT claim feature
completeness.
What's included
---------------
Backend (Go):
* database/model/model.go: add Socks model.Protocol constant ('socks')
next to Mixed, with a doc comment explaining the difference vs Mixed.
Frontend (JS/Vue):
* frontend/src/models/inbound.js
- Add Protocols.SOCKS ('socks') to the protocol enum, so the
existing 'Object.values(Protocols)' selector picks it up
automatically in the inbound create/edit modal.
- New Inbound.SocksSettings class (auth, accounts, udp, ip)
that serialises in the exact shape Xray's socks inbound expects
(https://xtls.github.io/config/inbounds/socks.html).
- New Inbound.SocksSettings.SocksAccount for password-mode users.
- Wire SOCKS into Inbound.Settings.getSettings() and fromJson()
dispatchers so create/edit/restore round-trips work.
* frontend/src/pages/inbounds/InboundFormModal.vue
- Extend the existing 'HTTP / Mixed accounts' form so SOCKS shares
the same accounts editor + auth/UDP/UDP-IP fields. SOCKS reuses
the MIXED shape because Xray's socks and mixed inbounds accept
the same settings keys.
- New addAccountByProtocol() helper dispatches to the correct
Account class per protocol (Http / Mixed / Socks) so each
protocol stores accounts in the right namespace.
What's intentionally NOT done (help wanted)
-------------------------------------------
1. sub/subService.go GetLink: SOCKS currently returns '' (same as
MIXED/HTTP/Tunnel). If we want a 'socks://' subscription link, that
needs its own gen* function. The existing comment on GetLink already
lists socks/http/mixed as link-less, so this is consistent for now.
2. Xray runtime AddUser / UpdateInbound hooks in web/service/inbound.go
— accounts are persisted in settings JSON and Xray picks them up on
restart, but live add-user without restart is not wired.
3. Routing UI: routing pages already accept any inbound tag, so SOCKS
inbounds are routable as-is; a dedicated 'protocol == socks' helper
in routing rule editors would be a nice follow-up.
4. Translations (web/translation/*.json): the protocol name is rendered
as the raw string 'socks' in the dropdown today; we don't yet have
a localised label.
5. Tests: xray/process_test.go has no SOCKS-specific case yet.
Why scaffold instead of full feature?
-------------------------------------
The protocol surface area touches db model, settings serialisation,
form UI, sub link generation, routing rules, and translations for 13
locales. Landing a vetted scaffold first lets multiple contributors
parallelise the remaining work without merge churn on a giant PR.
Refs
----
- Xray socks inbound spec: https://xtls.github.io/config/inbounds/socks.html
- RFC 1928 (SOCKS Protocol Version 5)
Co-developed-by: 3x-ui community (call for contributions)
|
||
|---|---|---|
| .github | ||
| .vscode | ||
| config | ||
| database | ||
| frontend | ||
| logger | ||
| media | ||
| sub | ||
| util | ||
| web | ||
| windows_files | ||
| xray | ||
| .env.example | ||
| .gitignore | ||
| .nvmrc | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| DockerEntrypoint.sh | ||
| Dockerfile | ||
| DockerInit.sh | ||
| go.mod | ||
| go.sum | ||
| install.sh | ||
| LICENSE | ||
| main.go | ||
| README.ar_EG.md | ||
| README.es_ES.md | ||
| README.fa_IR.md | ||
| README.md | ||
| README.ru_RU.md | ||
| README.zh_CN.md | ||
| update.sh | ||
| x-ui.rc | ||
| x-ui.service.arch | ||
| x-ui.service.debian | ||
| x-ui.service.rhel | ||
| x-ui.sh | ||
English | فارسی | العربية | 中文 | Español | Русский
3X-UI — advanced, open-source web-based control panel designed for managing Xray-core server. It offers a user-friendly interface for configuring and monitoring various VPN and proxy protocols.
Important
This project is only for personal usage, please do not use it for illegal purposes, and please do not use it in a production environment.
As an enhanced fork of the original X-UI project, 3X-UI provides improved stability, broader protocol support, and additional features.
Quick Start
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)
For full documentation, please visit the project Wiki.
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.
Support project
If this project is helpful to you, you may wish to give it a🌟
Stargazers over Time
