[BUG]: Import / Reverse-Sync Existing Remote Node Configuration Into Master Panel

[neerro]

Is your feature request related to a problem?

Problem

The new multi-node management system in 3x-ui works well when a brand-new node is added and managed entirely from the master panel.

However, there is currently no way to attach an already existing remote node with active inbounds/clients and import its configuration into the central/master server.

When an existing node is added:

existing inbounds are not synchronized to the master panel
existing clients are not imported
the remote node continues working independently
the master panel cannot fully manage already configured services

This forces administrators to:

delete existing configurations
recreate all inbounds manually
reconfigure clients again from scratch

For production environments this is risky and inconvenient.

Describe the solution you'd like

Expected Behavior

There should be a way to perform a reverse/full synchronization from the remote node into the master panel.

Example workflow:

Add existing remote node
Click "Import existing configuration" / "Sync from node"

Master panel fetches:

inbounds
clients
traffic stats
remarks
ports/listen
expiry/limits
settings JSON
Central database becomes synchronized with the current remote-node state
Further management can continue normally from the master panel

Why This Is Important

This is a common practice in clustered/panel-management systems.
Without reverse-sync/import support:
existing deployments cannot be migrated safely
onboarding nodes into centralized management is difficult
administrators must rebuild working configurations manually
production migration risk increases significantly

The recent full-mirror sync improvements already synchronize master → node very well.
Adding node → master bootstrap/import synchronization would complete the feature set and make node management practical for real-world deployments.

Suggested Implementation Ideas

Possible approaches:
one-time "Import from node" action
bidirectional sync mode
initial bootstrap sync during node registration
conflict resolution strategy (master priority / node priority)

Could also include:
dry-run preview
duplicate detection
optional overwrite behavior
Environment

3x-ui version: 3.0.0/3.0.1
Multi-node mode
Existing remote nodes with preconfigured inbounds/clients

Describe alternatives you've considered

No response

Checklist

• This feature report is written entirely in English.

[abdalrahmanx9]

what are you talking about?
they are automatically synced when you connect a node

[neerro]

what are you talking about? they are automatically synced when you connect a node

If you read the report more carefully, you would probably notice that this is specifically about already existing inbounds created before v3.

Yes, synchronization works correctly for:

• newly created inbounds in v3
• inbounds created after node attachment
• changes made from the master panel

That is not the issue.

The problem appears during migration from older versions (for example 2.9.11 → 3.0.1).

If a remote node already had existing inbounds before upgrading to v3, those legacy/existing inbounds are NOT imported into the master panel when the node is attached.

So after connecting the node:

• newly created v3 inbounds sync correctly
• but pre-existing inbounds remain missing from the master panel

This issue is specifically about bootstrap/import synchronization for legacy nodes, not normal post-attach syncing.

[abdalrahmanx9]

it works fine i already updated from older version with already existing inbounds and the sync worked
there is an issue if they have same port and i already made a pr with it

[neerro]

it works fine i already updated from older version with already existing inbounds and the sync worked
there is an issue if they have same port and i already made a pr with it

Interesting. In my case it does not import legacy inbounds at all after upgrading from 2.9.11 to 3.0.1, even after changing ports to completely unique ones.

Newly created inbounds sync perfectly and work in both directions, so the node connection itself is fine.

The issue only affects older pre-v3 inbounds that already existed before the upgrade. They continue working on the remote node locally, but they never appear in the master panel after attaching the node.

So either:

• there is another edge-case besides duplicate ports
• or some legacy inbound structures/settings are skipped during the initial sync/import process

I tested with different ports specifically because I saw your PR mention port conflicts.

[arhnick-netizen]

With you i'am changed port 443 in local server (with node) to 444 for five sec and node remote server good view to me in local dashboard, after in local 444->443 and all good view in this local server. Problem will by :433 on local and remote server.

[neerro]

i'am changed port 443 in local server (with node) to 444 for five sec and node remote server good view to me in local dashboard,

I tried the same workaround, but unfortunately it still did not work in my case.

I temporarily changed the existing inbound port (from 443 to 444) on the local/master node, waiting for more than 30 sec, but nothing was changed, then changed the port back — but the legacy inbound still was not imported into the master panel.

[neerro]

After additional testing, I finally identified why some existing remote nodes are not imported correctly into the master panel.

The issue is NOT only related to duplicate inbound ports between the local/master node and the remote node, as already mentioned earlier by @abdalrahmanx9.

There is another important conflict condition:
duplicate client emails between the local and remote nodes.

In my case, the legacy/pre-v3 inbounds were not imported because some clients on the remote node had the same email values as clients already existing on the master/local node.

Current behavior:

node attaches successfully
new v3-created inbounds sync correctly
remote legacy inbounds continue working locally
BUT existing inbounds are silently skipped during import/sync if client emails conflict

This makes the problem much bigger than only duplicate ports.

At this point this looks less like a missing feature request and more like an actual synchronization/import bug in the bootstrap logic for existing nodes.

The system currently appears to partially reject or ignore inbound import when:

inbound ports conflict
OR client email identifiers conflict

[neerro]

@abdalrahmanx9

Since your PR already addresses duplicate port conflicts, could you also extend it to handle duplicate client emails across different remote nodes?

Right now, identical client emails appear to cause legacy inbounds to be skipped during the initial sync/import process, even when ports are completely unique.

In real deployments this is very common because many administrators reuse the same client email naming scheme on multiple servers/nodes.

Currently this leads to:

• silent inbound skipping
• incomplete node import
• missing legacy inbounds in the master panel
• difficult migration debugging

It would be great if the PR could also include:

• proper duplicate email handling
• conflict warnings/logs
• or node-scoped uniqueness instead of global email uniqueness

Because at the moment this behavior breaks existing-node migration even when the port-conflict issue is resolved.

[abdalrahmanx9]

Thanks for your efforts but it is already extended in the pr I just did not mention here in the issue