# Support adding nodes behind a single management IP

**URL:** https://f.docs.rw/t/topic/128
**Category:** Предложения
**Created:** 2026-06-10T22:08:30Z
**Posts:** 1

## Post 1 by @remnawave — 2026-06-10T22:08:30Z

### Reference Issues

_No response_

### Summary

Please add support for using a single management IP for multiple nodes in Remnawave.

My use case:  
I have nodes that are not directly reachable from the panel, so I access them through one public host using socat/port forwarding. Because of this, several nodes may share the same management IP, but use different management ports.

Currently it would be useful if Remnawave allowed node identification and connection by:

- management IP / hostname
- management port
- optionally a unique node ID or label independent from IP

Expected behavior:

- multiple nodes can be added with the same management IP
- nodes are treated as separate if their management ports differ
- the panel correctly stores and displays such nodes without conflicts

Example:

- node-a → 1.2.3.4:22021
- node-b → 1.2.3.4:22022
- node-c → 1.2.3.4:22023

Why this is needed:  
This is useful when access to remote nodes is organized through a single jump host, reverse proxy, NAT, or socat TCP forwarding. Right now such deployments are harder or impossible to manage cleanly if uniqueness is tied to IP only.

Possible implementation:  
Use IP+port as a unique key instead of IP only, or allow a separate internal unique identifier for each node.

### Basic Example

A basic example of this feature:

The panel connects to multiple nodes through the same public management IP, but on different ports.

Example:

- Node 1: [management.example.com:22021](http://management.example.com:22021)
- Node 2: [management.example.com:22022](http://management.example.com:22022)
- Node 3: [management.example.com:22023](http://management.example.com:22023)

All three should be allowed in the panel at the same time and handled as separate nodes.

This would support setups where socat, NAT, or port forwarding is used to reach otherwise inaccessible nodes through one reachable host.

### Drawbacks

Potential drawbacks and impacts:

- Additional validation logic may be required, because node uniqueness would need to be based on IP/hostname + port instead of IP only.
- Existing database constraints or UI assumptions may need adjustment if they currently treat management IP as unique.
- Some parts of the panel or API may need updates to avoid conflicts in filtering, displaying, or editing nodes with the same IP.
- Migration handling may be needed for existing installations if uniqueness rules are changed.

Overall, the impact should be limited if the system already stores the management port separately.

### Unresolved questions

Some unresolved questions:

- Is node uniqueness currently enforced only at the UI level, or also at the database level?
- Should uniqueness be based on hostname+port, IP+port, or a separate internal node identifier?
- Should the panel allow duplicate IPs only when ports differ, or always rely on an internal unique ID?
- Are there any parts of the current node communication logic that assume one management IP always maps to exactly one node?
- Would this require changes only in the panel, or also in the node registration / backend logic?