[Bug]: When a node is disabled, its inbounds should not remain usable by clients, or at least they should be removed from generated subscriptions.

[ahmetakdag101]

Describe the bug

I am using 3X-UI in a multi-node setup.

When I disable a node from the Nodes page, the node status changes to disabled in the main panel. However, the inbounds deployed on that node are still available to clients.

The client can still connect to the disabled node’s inbounds, and the same inbounds are still shown/attached in the client configuration/subscription.

From an admin perspective, disabling a node should make that node unavailable for clients, or at least exclude that node’s inbounds from generated subscriptions.

Currently, disabling a node seems to stop only panel-side node management/sync, but it does not disable the Xray inbounds on the remote node and does not remove them from the client subscription.

How to reproduce the problem

1. Set up 3X-UI with multiple nodes.
2. Create inbounds deployed to a remote node.
3. Create a client and attach this client to inbounds from multiple nodes.
4. Verify that the client can connect to the remote node.
5. Go to the Nodes page in the main panel.
6. Disable that remote node.
7. Check the client’s attached inbounds/subscription.
8. Try connecting to the disabled node’s inbound.

Actual result:
The client can still connect to the disabled node’s inbound, and the disabled node’s inbound is still included in the client subscription.

Expected result:
When a node is disabled, its inbounds should either be disabled on the remote node or excluded from generated subscriptions, so clients cannot continue using that node.

Expected behavior

When a node is disabled from the Nodes page, the panel should make that node unavailable for clients.

Expected behavior:

• The disabled node’s inbounds should be disabled on the remote node, or
• The disabled node’s inbounds should be excluded from generated subscriptions, or
• The client should not be able to connect to any inbound that belongs to the disabled node.

From an admin perspective, disabling a node should mean that clients can no longer use that node.

Actual behavior

When I disable a node from the Nodes page, the node appears disabled in the main panel, but clients can still connect to that node’s inbounds.

The disabled node’s inbounds are still attached to the client and still appear in the client/subscription configuration.

So disabling the node only seems to disable panel-side node management/sync, but it does not stop Xray/inbounds on the remote node and does not remove those inbounds from client subscriptions.

Relevant logs

No error is shown in the panel.

Behavior observed:
- The node is disabled in the Nodes page.
- The node’s inbounds are still attached to the client.
- The subscription/client configuration still includes the disabled node’s inbounds.
- The client can still connect to the disabled node’s inbounds.

Screenshots

Node disabled/off
Client still has F-N3 / node inbounds attached

3x-ui version

v3.2.7

Xray-core version

26.6.1

How did you install 3x-ui?

install.sh script

Operating system

Ubuntu 22.04.5 LTS

Which parts of the panel are affected?

Multi-node (sub-nodes), Subscription (share links / Clash / JSON)

Browser (only if it is a UI bug)

Not UI-specific. Tested with Chrome.

Is the panel behind a reverse proxy or CDN?

None

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]

Thanks for the detailed report. After tracing the code, your observation is correct — disabling a node in the Nodes page only affects panel-side management/sync; it has no effect on client subscriptions or the remote Xray process. Here's exactly what happens and why.

What "disable node" currently does

NodeService.SetEnable (web/service/node.go:380-383) only flips the enable column in the database:

func (s *NodeService) SetEnable(id int, enable bool) error {
    db := database.GetDB()
    return db.Model(model.Node{}).Where("id = ?", id).Update("enable", enable).Error
}

That flag is checked by the panel's sync/probe logic (e.g. UpdatePanels, GetWebCertFiles), but nothing sends a signal to the remote node's Xray process. The remote panel keeps running with all its inbounds active.

Why subscriptions are unaffected

The subscription query in sub/subService.go:235-251 (getInboundsBySubId) only checks the inbound's own enable flag — it never joins the nodes table:

WHERE
    inbounds.protocol in ('vmess','vless','trojan','shadowsocks','hysteria')
    AND clients.sub_id = ? AND inbounds.enable = ?   -- ← no node.enable check

Similarly, loadNodes() (sub/subService.go:704-717) loads all nodes regardless of enable status (WHERE address \!= ''), so the disabled node's address is still used to build subscription links.

Two things would need to change to get the expected behavior

1. Subscription filtering — getInboundsBySubId would need to join nodes and add (inbounds.node_id IS NULL OR nodes.enable = true) so inbounds on disabled nodes are excluded from generated subscriptions.
2. Remote-node action — the panel currently has no mechanism to push a "disable/stop Xray" command to a remote node when you toggle it off. Implementing that would require a new API call on the sub-node side.

Either one alone gives a partial improvement; both together give the full behavior you're describing.

Workaround for now

To prevent clients from using a disabled node's inbounds:

• Manually disable each inbound that belongs to the node (toggle the inbound off in the Inbounds page). A disabled inbound (inbounds.enable = false) is excluded from subscription output.
• Or delete the client–inbound attachments for that node's inbounds so the client's subscription no longer references them.

This is a genuine feature gap; I've added the enhancement label alongside bug since closing it requires new functionality.

[ahmetakdag101]

Thank you for checking the code and confirming the behavior.

Your explanation makes sense. I understand now that the node enable flag only affects panel-side management/sync and does not affect subscriptions or the remote Xray process.

For multi-node providers, it would be very useful if disabling a node could at least exclude that node's inbounds from generated subscriptions. Fully stopping/controlling the remote Xray process would also be helpful, but I understand that it requires a separate remote-node API action.

For now, I will use the workaround by disabling the inbounds that belong to the node.

Thanks again for the detailed explanation.

[MHSanaei]

Fixed

[ahmetakdag101]

Thanks for the detailed explanation.

I updated to the latest release v3.2.8 and tested this again.

The issue still exists:

• I disabled a node from the Nodes page.
• The node appears disabled in the main panel.
• However, the services/inbounds of that node still remain available in the client configuration/subscription.
• The user can still connect to that disabled node’s services.

So in practice, disabling a node does not make the node unavailable for users. It only disables panel-side management/sync.

From an admin perspective, this is confusing. If a node is disabled, I expect that users should no longer be able to use services from that node, or at least the disabled node’s inbounds should be excluded from generated subscriptions.

Otherwise, what is the practical meaning of disabling a node?

Should we delete the node or manually disable every inbound that belongs to that node to prevent users from using it?

I think at minimum, when node.enable = false, subscriptions should exclude inbounds that belong to that node.

A full remote action to stop/disable Xray on the sub-node would be even better, but subscription filtering by node.enable would already solve the most important user-facing problem.