First, thank you for confirming that the previously reported Host-selection bug and the Internal Squad allowlist feature will be fixed or added in the next release. I appreciate your work on Remnawave and your attention to community feedback.
Use case
I would like to suggest a way to add a temporary external proxy server to user subscriptions without managing that server through Remnawave Node.
For example, the primary Nodes may temporarily be:
- unavailable;
- blocked by a user’s ISP;
- offline for maintenance;
- inaccessible from a particular region.
In this situation, the administrator may have access to another external VLESS, Trojan, Shadowsocks, or Hysteria2 server and want to temporarily add it to user subscriptions.
The external server should not need to:
- be managed through Remnawave Node;
- receive the panel’s user list;
- use each user’s individual credentials;
- report traffic usage to Remnawave.
It only needs to appear in the subscription as an additional temporary connection option.
Current limitation
A normal Host can already use an arbitrary address, and its selected Nodes are only a visual assignment. Therefore, the external server address itself is not the problem.
The limitation is credential generation.
When Remnawave generates a subscription, it currently uses the requesting user’s individual credentials:
- VLESS — the user’s UUID;
- Trojan — the user’s password;
- Shadowsocks — the user’s password;
- Hysteria2 — the user’s individual authentication value.
An external server configured with one fixed UUID or password cannot accept those per-user credentials.
Proposed solution
Instead of introducing a completely separate External Host entity, add the following setting to the existing Host form:
Credential source
- Per-user credentials — existing behavior;
- Static credentials — new behavior for an external or unmanaged server.
All existing and newly created Hosts should default to Per-user credentials, preserving complete backward compatibility.
When Static credentials is selected, the form could display one additional field appropriate for the selected Inbound protocol:
- VLESS — static UUID;
- Trojan — static password;
- Shadowsocks — static password or credential appropriate for the selected encryption method;
- Hysteria2 — static auth value or password.
Inherit other settings from an Inbound
To avoid building another complicated editor for transports, TLS, REALITY, WebSocket, gRPC, XHTTP, and other parameters, the external Host could continue to use an existing Inbound from a Config Profile.
The selected Inbound would be used only as the configuration source for:
- protocol;
- transport;
- security;
- flow;
- encryption method;
- SNI;
- path;
- REALITY public key and short ID;
- TLS and other connection parameters.
The address, port, and existing Host Overrides would continue to be configured in the Host form.
The Inbound would not necessarily need to be active on a Remnawave Node. An administrator could create an Inbound matching the external server and use it only as a subscription-generation configuration source.
This would avoid the need to develop a separate manual builder for every protocol and transport option.
Subscription generation
The static Host should be appended alongside normal Hosts rather than replacing them.
It should be supported in every subscription format where the selected protocol is supported:
- Xray Base64;
- Xray JSON;
- Mihomo;
- Clash;
- Stash;
- Sing-box;
- RAW subscription response.
Support for Xray Base64 is particularly important because not every user uses Mihomo or another structured subscription format.
For Base64 output, Remnawave should generate a normal share link containing the configured static credentials:
- vless://STATIC-UUID@…
- trojan://STATIC-PASSWORD@…
- ss://…
- hysteria2://STATIC-AUTH@…
Presumably, this would not require a completely separate implementation in every generator. Once the Host is converted into a normal ResolvedProxyConfig containing the static credential, the existing generators should be able to process it like other Hosts.
Naturally, the Host should appear only in subscription formats and clients that support the selected protocol.
Internal Squad access
The static Host should use the same visibility controls as a normal Host:
- access for all otherwise eligible squads;
- exclusion of selected Internal Squads;
- the planned Allow only selected Internal Squads mode.
This would allow an administrator to:
- expose the emergency Host to everyone;
- expose it only to selected squads;
- exclude particular squads;
- gradually enable it only for affected groups.
Management and revocation
Existing Host controls could be reused:
- Host Visibility;
- Enable/Disable;
- tags;
- display order;
- subscription-type exclusions;
- Internal Squad visibility.
The administrator can be assumed to own or operate the external endpoint. When the emergency ends, the administrator can:
- disable the static Host in Remnawave;
- revoke or rotate the static UUID/password directly on the external server.
Therefore, even if a client has cached the old configuration and has not refreshed its subscription, the administrator can immediately terminate access by revoking the credential on the external endpoint.
Because the credential is intentionally shared, Remnawave should not attempt to calculate per-user traffic or manage individual users on that external server.
The interface could display a short warning:
This Host uses shared static credentials. Per-user traffic accounting and individual user revocation are unavailable.
Suggested minimum first version
To reduce implementation effort, the first version could include only:
- a credential-source selector;
- one static UUID, password, or auth field;
- a required existing Inbound selection;
- the existing Host and Internal Squad visibility controls;
- support through the existing subscription generators, including Base64.
A fully manual protocol, transport, and security editor would not be necessary.
Expected behavior
- Existing Hosts continue using per-user credentials.
- A static Host uses one administrator-provided credential for every recipient.
- The static Host appears alongside normal Hosts.
- Connection parameters are inherited from the selected Inbound.
- The static Host does not require a Remnawave Node.
- Remnawave does not provision users on the external server.
- Traffic through the external server is not included in Remnawave statistics.
- The feature works with Base64 and other supported subscription formats.
- Internal Squad visibility rules apply as they do to normal Hosts.
- Disabling the Host removes it on the next subscription refresh.
- The administrator can immediately revoke the credential on the external server.
Possible naming
The name External Host may be confused with the existing External Squads feature.
More precise alternatives include:
- Static-Credential Host;
- Unmanaged Host;
- External Endpoint;
- Subscription-Only Host.
My preferred UI design would be a setting rather than a completely new Host type:
Credential source: Per-user / Static
I understand that even this reduced-scope version affects the backend, frontend, API contracts, and testing for multiple protocols. If it would take too much development time or does not fit the project’s current plans, I completely understand.
Thank you for considering the suggestion.