bug(panel): client Flow (xtls-rprx-vision) is incorrectly applied to linked VLESS-xHTTP inbounds in multi-inbound mode

[solynexxx]

Describe the bug

Under the new multi-inbound client feature in v3, assigning a client to both VLESS-TCP-Reality and VLESS-xHTTP inbounds copies the client's flow parameter (e.g., xtls-rprx-vision) to the VLESS-xHTTP inbound configuration as well. Since VLESS-xHTTP does not support the XTLS-Vision flow, Xray-core rejects connections on the xHTTP transport.

How to repeat the problem?

1. Create a VLESS-TCP inbound (with Reality enabled) and a VLESS-xHTTP inbound.
2. Edit a client, select both inbounds under "Linked Inbounds".
3. Set the client's Flow to xtls-rprx-vision.
4. Save the client and check the generated Xray config (config.json).
5. You will see "flow": "xtls-rprx-vision" under the xhttp client configuration.
6. Try connecting to the vless-xhttp inbound—it will fail.

Expected action

The panel's config generator should dynamically strip or ignore the "flow" parameter for the VLESS-xHTTP inbound, even if the client has Flow set to "xtls-rprx-vision" for TCP-Reality.

Received action

The panel writes "flow": "xtls-rprx-vision" into the client settings of the linked VLESS-xHTTP inbound, causing xHTTP connections to fail.

3x-ui Version

3.1.0

Xray-core Version

26.5.9

Checklist

• This bug report is written entirely in English.
• This bug report is new and no one has reported it before me.

[routegg]

When editing a client, a duplicate profile appears without any assigned inbound, while the modified profile drops to the bottom of the page as if it were a new one.

[Marseille-Geertje]

Коллеги, научите чинить отвалившиеся xHTTP клиенты. ))

[gfx73]

+1. Having one user with reality + tcp and tls + xhttp breaks the things. Flow is applied to all inbounds on server side. While user gets correct vless link without the flow for tls configuration, the xray server assumes user should have the flow and doesn't accept the connection.

app/proxyman/inbound: connection ends > proxy/vless/inbound: account 9e91553a-c609-4d48-a823-6087ba2750d2 is rejected since the client flow is empty. Note that the pure TLS proxy has certain TLS in TLS characters.

The only workaround is to use reality without xtls-rprx-vision which is not desired

[idykman]

+1. Having one user with reality + tcp and tls + xhttp breaks the things. Flow is applied to all inbounds on server side. While user gets correct vless link without the flow for tls configuration, the xray server assumes user should have the flow and doesn't accept the connection.

even reality+tcp and reality+xhttp combo for the same user is broken because of flow copyed to xhttp inbound

+1

[Mannokia]

Several critical issues occur when managing clients in 3x-ui.

Problems observed
When enabling or disabling a client, the password either changes automatically or disappears completely. As a result, client connections stop working.
UUIDs also periodically change or disappear unexpectedly. This causes the core to crash with an error related to invalid configuration.
When renaming a client, a new client entry is created with the new name, while the old client remains in the panel without assigned connections.
Additionally, if the client has a Hysteria connection configured, renaming the client creates a new client containing all original connections except Hysteria. The Hysteria connection remains attached to the old client.
Expected behavior
Enabling/disabling a client should not modify passwords or UUIDs.
Renaming a client should only change the client name without creating duplicate entries.
All client connections, including Hysteria, should remain attached to the renamed client.
Actual behavior
Passwords and UUIDs are unexpectedly modified or lost.
Duplicate client entries appear after renaming.
Hysteria connections remain bound to the old client entry.

[anartikov]

I’d also like to add to the above that in the trojan-grpc inbound, if you look at its full settings (export them), you can see that the attached client has Flow = set.

At the same time, in the client itself, this field is empty.

Additionally, several inbounds are connected to this client. If you remove the trojan-grpc inbound and save the changes, it does not get removed — in other words, it is not even possible to detach it from the client.

[Artyxxs]

Коллеги, научите чинить отвалившиеся xHTTP клиенты. ))

@Marseille-Geertje
В XHTTP инбаунде в меню advanced - all копируете всё, и в любом текстовом редакторе находите и заменяете все значения "flow": "xtls-rprx-vision" на "flow": ""
Закидываете в тот же инбаунд измененный конфиг, проверьте чтобы он после вставки не сбросился, такое бывает, и только потом сохраняете.
Лучше использовать именно сторонние редакторы, так как на встроенном в панель редакторе часто слетает все.

[msgtv]

Такая же проблема если у клиента есть два подключения VLESS-TCP-Reality и VLESS-GRPC-Reality.

VLESS-GRPC-Reality перестает работать

[Ramazik]

v3.2.0 - the problem is still relevant

For example, I have an inbound with xhttp traffic (id = 4) and inbound with raw (tcp) traffic (id = 8). If I replace the string "flow": "xtls-rprx-vision" with "flow": "" in the extended template (json) of the incoming xhttp connection for client "A", then when I edit the profile of client "A", to which both of these inbounds are connected, I will see that the flow parameter in its profile is empty. If I select xtls-rprx-vision from the drop-down list and save the profile of client "A", I will again see the string "flow": "xtls-rprx-vision" for client "A" in the extended template of the xhttp connection inbound.

[idykman]

The bug still exist in 3.2.0, please reopen the issue

[MHSanaei]

will fix in the next version