[Bug]: Universal subscription link for VLESS+XHTTP is not parseable by third-party clients (duplicate mode/x_padding_bytes inside "extra" JSON)

[KillReal1234]

Describe the bug

The VLESS+XHTTP line in the plain/universal subscription (base64 list of URIs) duplicates fields both as flat query params and inside a raw JSON blob in extra:

vless://@host:443?alpn=h2%2Chttp%2F1.1&extra=%7B%22mode%22%3A%22packet-up%22%2C%22xPaddingBytes%22%3A%22100-1000%22%7D&fp=firefox&host=host&mode=packet-up&path=%2F...&security=tls&type=xhttp&x_padding_bytes=100-1000

extra (and the duplicated mode/x_padding_bytes) are not part of any documented VLESS/XHTTP URI convention. Third-party parsers (mihomo, subconverter) either drop this node or fail entirely on it. This appears related to #4347 (Clash/Mihomo subscription returns Error! for XHTTP), but affects the raw/universal subscription output as well, not only the dedicated /clash/ endpoint.

How to reproduce the problem

1. Create a VLESS inbound with XHTTP transport (mode packet-up), TLS enabled.
2. Add a client, enable subscription.
3. Fetch the plain subscription URL and base64-decode it.
4. Feed the decoded VLESS+XHTTP line to mihomo (as a proxy-provider) or to a subconverter instance — parsing fails / node is dropped.

Expected behavior

Only emit the standard, documented XHTTP query params (mode, path, host, extra padding settings as flat params if needed) without the redundant raw extra JSON blob, so third-party clients can parse the link.

Related issue = 4347

Actual behavior

No response

Relevant logs

Screenshots

No response

3x-ui version

3.5.0

Xray-core version

26.7.11

How did you install 3x-ui?

install.sh script

Operating system

Ubuntu 24.04

Which parts of the panel are affected?

Subscription (share links / Clash / JSON)

Browser (only if it is a UI bug)

No response

Is the panel behind a reverse proxy or CDN?

Yes — Nginx

Before submitting

• I searched existing issues and this bug has not been reported.
• I am running the latest released version of 3x-ui (or have verified the bug still exists on it).
• This bug report is written in English.
• I have redacted any sensitive data (tokens, real domains, client UUIDs).

[github-actions]

Confirmed against current source. This is real and reproducible, but it's the direct consequence of a deliberate trade-off made across two earlier issues, not an isolated oversight — so the "expected behavior" in the report (just drop extra) would silently reopen a previously-fixed regression for a different client family.

Title: Plain/universal subscription and share links intentionally double-encode XHTTP mode/padding as both flat params and a JSON extra blob; generic URI parsers (subconverter, mihomo used as a raw proxy-provider) don't understand extra

Severity: Medium

Category: API / Correctness (share-link interop)

Why this matters

• Root cause, confirmed line-by-line in internal/sub/service.go: genVlessLink (line 772) → applyShareNetworkParams, whose "xhttp" case (lines 1240-1242) calls applyXhttpExtraParams(xhttp, params). That function (line 2102) sets flat mode and x_padding_bytes, and packs the same fields into a JSON blob written to extra (lines 2115-2120) via buildXhttpExtra (line 1954). That reproduces your link exactly: flat mode=packet-up + flat x_padding_bytes=100-1000 + extra={"mode":"packet-up","xPaddingBytes":"100-1000"}.
• This is intentional, not accidental. The comment directly above applyXhttpExtraParams (lines 2084-2101) states the dual encoding exists so "every popular client can read at least one": flat params for sing-box-family clients (Karing, NekoBox, OpenWRT sing-box, Podkop), extra JSON for xray-core-family clients (v2rayNG, Happ, Furious, Exclave). internal/sub/service_test.go (lines 373-376) pins this with an explicit comment: mode rides inside extra "so clients that only read the extra JSON keep the xhttp mode ([Bug]: Regression of #4364: Karing loses XHTTP packet-up mode when VLESS link contains extra/x_padding_bytes #5446)".
• That reference is load-bearing: extra carries mode specifically because of After one of the recent updates, profiles stopped importing correctly into karing #4364 and its regression [Bug]: Regression of #4364: Karing loses XHTTP packet-up mode when VLESS link contains extra/x_padding_bytes #5446 — both about Karing silently dropping transport.mode when extra was present but incomplete. Removing extra (this report's requested fix) would reopen that exact regression for Karing. This is a genuine three-way conflict between client families over a single URI shape, not a bug with one obviously-correct output.
• This only affects the plain/universal link list and individual share links. The other two subscription formats already avoid it, because they carry XHTTP settings as native structured fields instead of URL params:
  • Clash/Mihomo YAML: internal/sub/clash_service.go, buildXhttpClashOpts (line 438) emits a native xhttp-opts map, no extra. This is what fixed Clash/Mihomo subscription returns Error! when all subscribed inbounds use VLESS + XHTTP #4347.
  • Sing-box JSON: internal/sub/json_service.go emits xhttpSettings as a nested object, also no extra.
• Notably, Settings → Subscription → "Auto-detect Clash/Mihomo clients" (subClashAutoDetect, off by default, merged yesterday in commit 129f50d / feat(sub): auto-detect subscription format by User-Agent (Updated) #5826) already closes the mihomo half of this gap when enabled together with Clash/Mihomo subscription (subClashEnable, also off by default): a request to the standard subscription URL whose User-Agent matches the configured regex (default (?i)(clash|mihomo)) is transparently served the native Clash YAML instead of the raw list (internal/sub/controller.go lines 343-346). That only helps if mihomo subscribes to the panel URL directly as a remote proxy-provider — it sends its own User-Agent in that case. It does not help the workflow in this report (decode the base64 payload by hand, paste the raw line into a local proxy-provider), because no HTTP request reaches the panel there, so nothing to detect.
• subconverter is the harder case: it consumes the raw/universal link directly, and whether its own default User-Agent would match subClashUserAgentRegex if pointed at the panel's subscription URL isn't something this repository's source can confirm.

Recommendation

This needs a maintainer decision, since the client families disagree on what a VLESS+XHTTP URI should contain:

1. Keep the current dual-encoding and treat this as a documentation gap — point Clash-family consumers (mihomo, subconverter) at the dedicated /clash/ endpoint (or the new auto-detect) instead of the raw/universal one.
2. Add an explicit option to omit extra from plain/share-link output, accepting that opting in regresses Karing-style clients back to the After one of the recent updates, profiles stopped importing correctly into karing #4364/[Bug]: Regression of #4364: Karing loses XHTTP packet-up mode when VLESS link contains extra/x_padding_bytes #5446 symptom.
3. Narrow buildXhttpExtra so extra is only emitted when fields with no flat-param equivalent are actually set (i.e., a plain mode + xPaddingBytes config like this report's would stay on flat params only), reserving extra for the rarer multiplexing/session fields. This would need re-verifying against Karing's actual parsing behavior first, since that's unconfirmed here and is exactly what After one of the recent updates, profiles stopped importing correctly into karing #4364/[Bug]: Regression of #4364: Karing loses XHTTP packet-up mode when VLESS link contains extra/x_padding_bytes #5446 turned on.

Tagging @MHSanaei since this trades off two already-supported client families against each other and needs a decision on priority (or on branching by detected client).

This reply was generated automatically; a maintainer may follow up.

[MHSanaei]

The extra JSON param is intentional for xray-core clients (added in #4065); dropping it regresses v2rayNG/Happ and friends. Closing — happy to reconsider with a concrete standard-only encoding that keeps the bidirectional fields.