MHSanaei/3x-ui · warning

node {name} is disabled

Error message

node {name} is disabled

What it means

Manager's remote-runtime cache returns this when loadNode succeeds but the node row has Enable=false: the runtime layer refuses to construct a Remote for a disabled node, so any inbound/client operation routed to that node fails with a named error. It is a deliberate policy gate — data still exists in the DB, but dispatching config changes to a disabled node is blocked to avoid drifting state.

Source

Thrown at internal/web/runtime/manager.go:104

		return rt, nil
	}
	if rt, ok := m.remotes[*nodeID]; ok {
		m.mu.RUnlock()
		return rt, nil
	}
	m.mu.RUnlock()

	m.mu.Lock()
	defer m.mu.Unlock()
	if rt, ok := m.remotes[*nodeID]; ok {
		return rt, nil
	}
	n, err := loadNode(*nodeID)
	if err != nil {
		return nil, err
	}
	if !n.Enable {
		return nil, errors.New("node " + n.Name + " is disabled")
	}
	rt := NewRemote(n, m.egressResolver)
	m.remotes[*nodeID] = rt
	return rt, nil
}

func (m *Manager) Local() Runtime { return m.local }

func (m *Manager) RemoteFor(node *model.Node) (*Remote, error) {
	if node == nil {
		return nil, errors.New("node is nil")
	}
	m.mu.RLock()
	if rt, ok := m.remotes[node.Id]; ok {
		if sameRemoteIdentity(rt.node, node) {
			m.mu.RUnlock()
			return rt, nil
		}

View on GitHub (pinned to ad32144c42)

Solutions

  1. Re-enable the node in panel node settings if it should receive operations
  2. If decommissioned, update callers/scripts to stop targeting that node id
  3. Refresh the node list in the UI before acting on it
  4. For maintenance flows, queue changes and apply after re-enable rather than bypassing the runtime
Defensive patterns

Strategy: validation

Validate before calling

node, err := loadNode(id)
if err == nil && !node.Enable {
    return fmt.Errorf("node %s is disabled — enable it or retarget the operation", node.Name)
}

Try / catch

rt, err := manager.RemoteByID(id)
if err != nil {
    if strings.Contains(err.Error(), "is disabled") {
        // policy gate: enable the node or stop targeting it — do not retry
    }
    return err
}

Prevention

When it happens

Trigger: An API call or UI action that targets inbounds on a node that was disabled in node settings; automation that references a node id after an admin disabled it; cached node list in the frontend not reflecting the disable.

Common situations: Taking a sub-node offline for maintenance while old clients/scripts still reference it; node decommission workflow.

Related errors


AI-assisted analysis of MHSanaei/3x-ui@ad32144c42 (2026-08-15). Data as JSON: /api/errors/64af1140a8e32ead. Report an issue: GitHub.