Feature request: support Unix domain socket path in inbound Listen field

[w3struk]

Is your feature request related to a problem?

No

Describe the solution you'd like

Currently, the inbound Listen field only accepts IP addresses. Unix socket support would enable architectures where Caddy (or another reverse proxy) communicates with Xray via local sockets instead of TCP 127.0.0.1:<port>. This is useful for:

1. Security — no TCP port listening at all (even localhost), access controlled by filesystem permissions
2. Performance — avoids TCP stack overhead for local IPC
3. Architecture parity with Reality fallback — Xray already uses Unix sockets for fallback dest ("dest": "/run/xray/xhttp_in.sock") and for realitySettings.target. It's inconsistent that the listen field of an inbound cannot use the same mechanism.

Describe alternatives you've considered

No response

Checklist

• This feature report is written entirely in English.

[MHSanaei]

Implemented. Unix domain socket paths in the inbound Listen field are now fully supported. The core already worked — the listen string is passed to Xray verbatim and port 0 is accepted (since #4783), and the Go subscription/link layer deliberately ignores the bind listen (resolveInboundAddress), even rewriting @-socket fallback children to the master's listen. The only gap was the frontend resolveAddr, which would emit the socket path as the host in share/sub links (e.g. vless://uuid@/run/xray/x.sock:0). It now treats a path-style listen (starting with / or @, optional ,perm suffix) as having no client-reachable address and falls back to the node/host. Added a help hint under the Listen field across all locales.

Usage: set Listen to the socket path (e.g. /run/xray/in.sock, optionally /run/xray/in.sock,0666) and Port to 0, then front it with Caddy/another reverse proxy. Thanks for the well-reasoned request.

[w3struk]

simplescreenrecorder-2026-06-03_11.41.14.mp4

@MHSanaei please take a look

[MHSanaei]

Read the example
Should start with /

[w3struk]

Read the example Should start with /

Thanks for the UDS support work. I think there is one remaining edge case for Linux abstract Unix sockets (@name).

Repro

1. Add/edit an inbound that listens on an abstract UDS, for example XHTTP behind Caddy.
2. Set Listen to @uds_xhttp.
3. Try to set Port to 0.

Actual behavior

The form still treats @uds_xhttp as a normal TCP listen value, so the port input minimum remains 1. A dummy non-zero port works because xray-core ignores the port for UDS listeners, but this is misleading and inconsistent with
filesystem UDS behavior.

Code references

The issue seems localized to the inbound form:

• InboundFormModal.tsx defines isUdsListen as wListen.startsWith('/') only:
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/pages/inbounds/form/InboundFormModal.tsx#L163-L166

• The port input then uses that boolean for min={isUdsListen ? 0 : 1}:
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/pages/inbounds/form/InboundFormModal.tsx#L491-L497

Other code paths already treat both filesystem and abstract UDS as UDS:

• inbound-link.ts checks both / and @ in isUnixSocketListen():
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/lib/xray/inbound-link.ts#L753-L766

• sub/subService.go also excludes both @... and /... listens from advertised subscription addresses:
  https://github.com/MHSanaei/3x-ui/blob/main/sub/subService.go#L727-L734

The generic inbound port validation already allows 0, so this does not look like a backend validation issue:

• Frontend InboundPortSchema allows min(0):
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/schemas/primitives/port.ts#L3-L6

• Go model.Inbound.Port allows gte=0:
  https://github.com/MHSanaei/3x-ui/blob/main/database/model/model.go#L56-L58

Expected behavior

Listen values starting with / or @ should both be treated as Unix Domain Socket inbounds by the form, so Port: 0 is accepted for both:

• filesystem UDS: /run/xray/in.sock
• abstract UDS: @uds_xhttp

A minimal fix may be to change the form-side detection to something equivalent to:

const isUdsListen = wListen.startsWith('/') || wListen.startsWith('@');

and add a regression test for listen = '@xray-abstract' with port = 0.

[CursedSisyphus]

please add support for abstract uds

[w3struk]

Read the example Should start with /

Thanks for the UDS support work. I think there is one remaining edge case for Linux abstract Unix sockets (@name).

Repro

1. Add/edit an inbound that listens on an abstract UDS, for example XHTTP behind Caddy.

2. Set `Listen` to `@uds_xhttp`.

3. Try to set `Port` to `0`.

Actual behavior

The form still treats @uds_xhttp as a normal TCP listen value, so the port input minimum remains 1. A dummy non-zero port works because xray-core ignores the port for UDS listeners, but this is misleading and inconsistent with filesystem UDS behavior.

Code references

The issue seems localized to the inbound form:

* `InboundFormModal.tsx` defines `isUdsListen` as `wListen.startsWith('/')` only:
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/pages/inbounds/form/InboundFormModal.tsx#L163-L166

* The port input then uses that boolean for `min={isUdsListen ? 0 : 1}`:
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/pages/inbounds/form/InboundFormModal.tsx#L491-L497

Other code paths already treat both filesystem and abstract UDS as UDS:

* `inbound-link.ts` checks both `/` and `@` in `isUnixSocketListen()`:
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/lib/xray/inbound-link.ts#L753-L766

* `sub/subService.go` also excludes both `@...` and `/...` listens from advertised subscription addresses:
  https://github.com/MHSanaei/3x-ui/blob/main/sub/subService.go#L727-L734

The generic inbound port validation already allows 0, so this does not look like a backend validation issue:

* Frontend `InboundPortSchema` allows `min(0)`:
  https://github.com/MHSanaei/3x-ui/blob/main/frontend/src/schemas/primitives/port.ts#L3-L6

* Go `model.Inbound.Port` allows `gte=0`:
  https://github.com/MHSanaei/3x-ui/blob/main/database/model/model.go#L56-L58

Expected behavior

Listen values starting with / or @ should both be treated as Unix Domain Socket inbounds by the form, so Port: 0 is accepted for both:

* filesystem UDS: `/run/xray/in.sock`

* abstract UDS: `@uds_xhttp`

A minimal fix may be to change the form-side detection to something equivalent to:

const isUdsListen = wListen.startsWith('/') || wListen.startsWith('@');

and add a regression test for listen = '@xray-abstract' with port = 0.

@MHSanaei

[MHSanaei]

@w3struk ok