mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-06-05 20:54:14 +00:00
2562e2eb82
Wraps up the 'help wanted' backend items from the SOCKS5 scaffold PR (#4452) so the dedicated socks inbound is a fully functional protocol end-to-end, not just a model constant. xray/api.go AddUser ------------------- Live add-user via the gRPC HandlerService now handles 'socks' and 'http' as first-class protocols. Previously these fell through the default branch and returned nil, so adding a new password-mode account to a running socks/http inbound silently required a full xray restart. - New 'socks' case constructs a proxy/socks.Account{Username, Password} from the panel-side map keys 'user' and 'pass' (matching how Inbound.SocksSettings.SocksAccount serialises in frontend/src/models/inbound.js). Username is required, password is optional so a no-pass account is still expressible if Xray ever allows it on a specific build. - New 'http' case mirrors the same shape via proxy/http.Account. The dedicated HTTP inbound isn't surfaced standalone in the panel UI yet, but the runtime API is symmetric with socks and several follow-up plans (e.g. exposing HTTP as a separate inbound) become one-line UI work instead of a backend refactor. Both branches reuse the existing getRequiredUserString / getOptionalUserString helpers, so a malformed userMap surfaces the same typed error message as the vless / vmess paths above. web/service/port_conflict.go ---------------------------- inboundTransports() now folds 'socks' into the same branch that already handles 'mixed': settings.udp=true means the inbound holds both tcp and udp on the listening port (socks5 UDP ASSOCIATE), settings.udp=false keeps it tcp-only. Without this, a socks+udp inbound would silently be classified as tcp-only and the validator would let a hysteria2 udp inbound coexist with it on the same port — both processes would then race for the udp socket at xray start, with one of them quietly failing. The two protocols share the exact same settings JSON shape for this field (it's the same proxy/socks server type under the hood), so the sane thing is to merge the case clauses rather than copy/paste the type-assertion. Comment updated to spell out why. web/service/tgbot.go -------------------- Add model.Socks to the excludedProtocols set in getInboundsAddClient so the Telegram bot doesn't offer a dedicated SOCKS inbound when the admin asks 'add a client to which inbound?'. SOCKS inbounds, like Mixed/HTTP, don't produce a per-client subscription URL (see the existing link-less branch in sub/subService.go::GetLink), so any client attached via the bot would have no way to actually subscribe. Added a header comment explaining the criterion so future protocols fall into the right bucket without an audit. Tests ----- web/service/port_conflict_test.go gains four cases that pin the new behaviour at the transport-bits level (TestInboundTransports): - socks + udp=true -> tcp|udp (matches Mixed) - socks + udp=false -> tcp only - socks + missing settings -> tcp only - socks + empty settings -> tcp only …plus two end-to-end conflict checks that mirror the existing shadowsocks/mixed coverage: - TestCheckPortConflict_SocksUDPBlocksUDPNeighbour: a socks+udp inbound on port N must clash with a hysteria2/udp on the same port. Catches a regression where the Socks branch is dropped from inboundTransports. - TestCheckPortConflict_SocksTCPCoexistsWithUDPNeighbour: a socks-tcp-only inbound must still let a hysteria2/udp neighbour bind the same port. Mirrors the #4103 vless+hysteria2 coexistence case. Out-of-scope (still tracked in the PR description) -------------------------------------------------- - Sub-link generation (sub/subService.go GetLink): SOCKS deliberately stays link-less for the reasons documented in the previous commit; no socks:// scheme is consistently understood across xray/v2ray client ecosystems. - Routing UI: routing rules in this fork already accept any inbound tag, so SOCKS inbounds are routable as-is. A dedicated 'protocol == socks' helper in the routing rule editor is a UX follow-up, not a correctness gap. - Translations: protocol labels are rendered raw in this fork; no per-locale label key exists for vmess/vless/mixed either, so adding one only for socks would be inconsistent. |
||
|---|---|---|
| .. | ||
| controller | ||
| entity | ||
| global | ||
| job | ||
| locale | ||
| middleware | ||
| network | ||
| runtime | ||
| service | ||
| session | ||
| translation | ||
| websocket | ||
| web.go | ||