[Feature]: XHTTP: Add fields for configuring "xmux" for inbounds

[Viktus]

Is your feature request related to a problem?

In recent months TSPU in Russia has begun monitoring server connection patterns that deviate from normal browsing behavior — specifically, an anomalous number of connections within a short period of time. Article in russian dpi-tls-june-2026

more than 3 parallel TLS handshake attempts to the same SNI, with less than ~350-400 ms delay between them, within the last 60 seconds

The issue affects clients on Xray-core v25.10.15 and above due to changes in the default xmux settings from 32-16 to 1. This leads to a large number of simultaneous connections.

XHTTP client: Change default maxConcurrency to 1 for speed testing by @RPRX in XTLS/Xray-core@9cc7907

Describe the solution you'd like

Adding xmux settings in the extra section on the client side solves the issue, but these settings get reset after a subscription update.
Could you add xmux configuration fields to the XHTTP form and pass them in the subscription? This would resolve the issue mentioned above and eliminate the need for clients to manually reconfigure their settings after every subscription update.

Alternatives you've considered

No response

Concrete use case

Clients running the latest Xray versions are forced to manually add xmux configuration for XHTTP connections when connecting to servers behind DPI blockers

Mockups, screenshots, or examples

No response

Which parts of the panel would this affect?

Frontend (UI / panel pages), Subscription (share links / Clash / JSON), Xray config generation

Are you willing to help?

• I'd like to implement this feature myself and open a PR.
• I can help test once a PR is open.

Before submitting

• I searched existing issues and this feature has not been requested.
• This feature request is written in English.

[github-actions]

Good, well-scoped request. Here is what the codebase already has and what is still missing.

What already works (v3.3.0)

The subscription service in internal/sub/service.go — specifically buildXhttpExtra — already forwards xmux to clients when the field is present in the inbound's xhttpSettings JSON:

for _, field := range []string{"xmux", "downloadSettings"} {
    if v, ok := nonEmptyShareObject(xhttp[field]); ok {
        extra[field] = v
    }
}

The comment in that function explicitly notes: "client-only values are included only when present in the inbound JSON. Some deployments/imported configs carry them there, and the subscription link is the only place clients can receive them."

The XHttpStreamSettingsSchema (frontend/src/schemas/protocols/stream/xhttp.ts) already defines xmux as an optional field on the shared stream schema used by both inbounds and outbounds, and all six knobs are typed there (maxConcurrency, maxConnections, cMaxReuseTimes, hMaxRequestTimes, hMaxReusableSecs, hKeepAlivePeriod).

What is missing

The inbound XHTTP form (frontend/src/pages/inbounds/form/transport/xhttp.tsx) does not expose any xmux fields. The outbound XHTTP form (frontend/src/pages/xray/outbounds/transport/xhttp.tsx) already has a complete, toggle-gated xmux section that serves as a direct model.

What a PR would need to do

1. Add an XMUX toggle + the same six Form.Item blocks to frontend/src/pages/inbounds/form/transport/xhttp.tsx, under `['streamSettings', 'xhttpSettings', 'xmux', ...]' paths — mirroring the outbound form.
2. The server-side subscription code and the schema require no changes; they already handle the data end-to-end.

Note: xray-core's server runtime ignores the xmux field in an inbound config, so saving it there has no effect on the server itself — it is purely a mechanism for the panel to push xmux defaults to clients through subscription links.

[MHSanaei]

xmux (connection multiplexing) is a client-side / outbound dialer setting — xray-core''s XHTTP inbound (server) does not consume it, so the panel intentionally exposes xmux only on outbounds and strips it from inbound stream settings. There''s nothing for an inbound to do with xmux values, which is why the fields aren''t shown there. Closing as not applicable; the xmux fields remain available where they take effect (outbounds).