reza 4f8b0b90c8 feat(inbound): scaffold dedicated SOCKS5 inbound protocol ... 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)		2026-05-18 08:07:17 +00:00
..
model	feat(inbound): scaffold dedicated SOCKS5 inbound protocol	2026-05-18 08:07:17 +00:00
db.go	fix: ignore duplicate column errors during AutoMigrate on upgraded DBs	2026-05-14 11:10:38 +02:00