Static credentials for unmanaged external Hosts

[arkimx]

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:

1. disable the static Host in Remnawave;
2. 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:

1. a credential-source selector;
2. one static UUID, password, or auth field;
3. a required existing Inbound selection;
4. the existing Host and Internal Squad visibility controls;
5. 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.

[remnawave]

Думаю, что дополнительной реализации не требуется, так как уже существует Mapper в Advanced настройках Хоста.

[arkimx]

Спасибо за объяснение. Я изучил схему Mapper и код генераторов. Насколько я понял, с помощью Mapper действительно можно задать фиксированные данные авторизации для структурированных форматов подписки. Например, фиксированный UUID VLESS можно установить в следующих полях:

• Xray JSON: settings.vnext.0.users.0.id
• Mihomo/Stash: uuid
• sing-box: uuid

Однако я не смог найти способ сделать то же самое для Xray Base64. В описании Mapper указано, что операции base64 применяются только к query string сгенерированной ссылки.

В ссылке VLESS UUID находится вне query string:

vless://UUID@address:port?parameters#remark

Поэтому операция Mapper с параметром uuid, как мне кажется, только добавит ?uuid=…, но не заменит настоящий UUID перед символом @. Похожая проблема возникает с паролями Trojan и Hysteria2, а в Shadowsocks данные авторизации находятся в закодированной части ссылки перед @.

Возможно, я неправильно понимаю, как нужно использовать эту часть Mapper. Не могли бы вы привести пример, как с помощью Mapper заменить настоящий UUID VLESS в ссылке Xray Base64 на фиксированный UUID?

Предполагаемый сценарий использования — временный внешний endpoint, который использует одни и те же фиксированные данные авторизации для всех пользователей и добавляется в их подписки, включая Xray Base64, а не только Mihomo и другие структурированные форматы.

Если сейчас это невозможно, возможно, Mapper можно было бы расширить, чтобы он позволял изменять credential/authentication-компонент Base64-ссылки, а не только её query-параметры. Я полностью понимаю, если реализация этого сейчас не является приоритетной задачей.

English version

Thank you for the explanation. I looked through the Mapper schema and generator code. As I understand it, Mapper can set a fixed credential for structured subscription formats. For example, a fixed VLESS UUID can be written to:

• Xray JSON: settings.vnext.0.users.0.id
• Mihomo/Stash: uuid
• sing-box: uuid

However, I could not find a way to do the same for Xray Base64. The Mapper description says that base64 operations are applied only to the query string of the generated share link.

In a VLESS link, the UUID is outside the query string:

vless://UUID@address:port?parameters#remark

Therefore, setting a uuid parameter through the Base64 Mapper appears to produce ?uuid=…, rather than replacing the actual UUID before @. The same issue appears to apply to Trojan and Hysteria2 credentials, while a Shadowsocks link stores its credentials in the encoded authority section.

Perhaps I am misunderstanding how this part of Mapper should be used. Could you please provide an example showing how to replace the actual VLESS UUID in an Xray Base64 share link with a fixed UUID?

The intended use case is an external temporary endpoint that uses the same fixed credential for every user and appears in their subscriptions, including Xray Base64—not only Mihomo or other structured formats.

If this is not currently possible, perhaps Mapper could be extended to modify the credential/authentication component of a Base64 share link, in addition to its query parameters. I completely understand if implementing this is not currently a priority.

[remnawave]

@arkimx

Поэтому операция Mapper с параметром uuid, как мне кажется, только добавит ?uuid=…, но не заменит настоящий UUID перед символом @. Похожая проблема возникает с паролями Trojan и Hysteria2, а в Shadowsocks данные авторизации находятся в закодированной части ссылки перед @.

Да, вы правы. В текущем виде невозможно для base64 заменить данные, которые не находятся в query-параметрах.

Вы можете запретить использование bas64 через Response Rules, чтобы ваши пользователи не получали подписку такого формата. Однако, разумеется, требуется чтобы клиентские приложение поддерживали другой формат подписки – Xray-Json и так далее.

[remnawave]

Для base64, возможно, в следующей версии появятся дополнительные опции.

[remnawave]

Реализация для изменения параметров в base64 готова. Будет доступна в следующей версии.