Remnawave Integration

1. Applying HTTP Response Headers

Remnawave supports two ways to apply HTTP response headers to subscription profiles.

Method 1 — Global (for all apps)

In the Remnawave admin panel, open Subscription → Settings → Response Headers. Add any headers there — they will be returned to all clients on every subscription fetch.

For External Squads, headers are configured per squad: Users → External Squads → Headers.

Method 2 — Per-App via Response Rules (Prizrak-Box specific)

Response Rules let you apply headers only when the request comes from a specific client, identified by the User-Agent header. This way you can send Prizrak-Box–specific settings without affecting other apps.

Go to Subscription → Response Rules and create a new rule. Place it at the top of the list to ensure priority.

Note

Full Remnawave Response Rules documentation: docs.rw/learn-en/routing-rules

Prizrak-Box identifies itself with a User-Agent of the following format on every platform:

Platform	User-Agent
Desktop	prizrak-box/{version} (Desktop Build; {OS} OS; Prizrak-Core {core})
Android	prizrak-box/{version} (Android Build; Prizrak-Core {core})
Apple	prizrak-box/{version} (Apple Build; Prizrak-Core {core})

For example, prizrak-box/1.0.21-beta06 (Desktop Build; Windows OS; Prizrak-Core v1.19.33-r1).

The condition prizrak-box/ matches all of them. Older versions sent a string with a Clash-Meta/ prefix (Clash-Meta/Prizrak-Box (...)), so a rule written as Clash-Meta/Prizrak-Box ( no longer matches new versions — use prizrak-box/ instead.

Use the following JSON as a template — it covers all headers supported by Prizrak-Box:

{
  "name": "Prizrak-Box",
  "description": "Headers for Prizrak-Box clients",
  "enabled": true,
  "operator": "AND",
  "conditions": [
    {
      "headerName": "user-agent",
      "operator": "CONTAINS",
      "value": "prizrak-box/",
      "caseSensitive": false
    }
  ],
  "responseType": "MIHOMO",
  "responseModifications": {
    "headers": [
      {
        "key": "profile-logo",
        "value": "https://example.com/logo.png"
      },
      {
        "key": "announce-url",
        "value": "https://t.me/your_channel"
      },
      {
        "key": "fallback-domain",
        "value": "backup.example.com"
      },
      {
        "key": "pxa-latency-dots",
        "value": "1"
      },
      {
        "key": "pxa-simple-mode",
        "value": "1"
      },
      {
        "key": "pxa-global-mode-mp",
        "value": "1"
      },
      {
        "key": "pxa-conns-view-mp",
        "value": "1"
      },
      {
        "key": "pxa-rp-mp",
        "value": "1"
      }
    ]
  }
}

Remove the headers you don’t need. For a full description of each header see Supported Headers.

---

2. Custom Mihomo Template

To deliver a fully custom Mihomo config to Prizrak-Box clients — for example, one with the Smart proxy group — specify a subscriptionTemplate in the Response Rule:

{
  "name": "Prizrak-Box Smart Template",
  "description": "Custom Mihomo template with Smart proxy group for Prizrak-Box",
  "enabled": true,
  "operator": "AND",
  "conditions": [
    {
      "headerName": "user-agent",
      "operator": "CONTAINS",
      "value": "prizrak-box/",
      "caseSensitive": false
    }
  ],
  "responseType": "MIHOMO",
  "responseModifications": {
    "subscriptionTemplate": "SmartPrizrak"
  }
}

Note

Full Remnawave Response Rules documentation: docs.rw/learn-en/routing-rules

The subscriptionTemplate value (SmartPrizrak in the example) must match the name of a template configured in your Remnawave panel.

For details on the Smart proxy group type and its configuration parameters, see Smart Proxy Group.

---

3. AGE Encryption

Remnawave can encrypt the Mihomo config with age before delivering it to Prizrak-Box. Only the client that holds the matching secret key can decrypt and apply the config.

For a complete setup guide — key generation, Remnawave response rule configuration, and Prizrak-Box client setup — see AGE Encryption.

---

4. Remnawave-Specific Mihomo Keys for Subscription Templates

Remnawave supports special keys that extend the standard Mihomo configuration and are available inside subscription templates. These keys allow fine-grained control over proxy groups and providers directly from the template.

Full reference: docs.rw/guides/templates/mihomo

---

5. Proxy and Group Descriptions

Prizrak-Box shows a short description next to a server or a proxy group in the proxy list. Keep it up to 30 characters — that is the limit of the field in the Remnawave panel.

Server description (proxies)

Set it in the host settings of the Remnawave panel:

1. Open the host for editing.
2. In the Options block press Add.
3. In the Subscription section choose Server description.
4. Enter the text (up to 30 characters) and save the host.

Prizrak-Box reads it from the serverDescription key of the proxy in the subscription. Remnawave sends this key only to the clients it recognises, and a User-Agent that starts with prizrak-box/ is one of them, so no extra setup is needed.

Group description

The description of a proxy group is added to the Mihomo template, like the other group parameters, with the description key:

proxy-groups:
  - name: 👻 Prizrak
    type: select
    description: Auto-pick the best location
    proxies:
      - 🇩🇪 Germany
      - 🇫🇮 Finland

The group description is shown in the row of the group when it is nested in another proxy group.

All keys and display rules are described in Proxy and Group Descriptions.

---

6. Prizrak-Core Feature Support

Prizrak-Box runs on the Prizrak-Core core, which has features that regular Mihomo does not. To deliver them to users through the subscription, add the required options to the proxy with the Remnawave host mapper, in the mihomo list.

• Only the Mihomo subscription changes. Xray JSON and base64 subscriptions stay as they are while their lists in the mapper are empty.
• Clients on regular Mihomo ignore unknown keys and keep working as before.

Setting up the host mapper

1. Open Hosts and select the host to edit.
2. In the Options block, click Add and pick Mapper in the Advanced group.
3. A Mapper row with the status Not set appears in the Advanced section. Click it to open the mapper JSON editor.
4. Paste the JSON from the examples below and click Save in the host card. The mapper status changes to Configured.

Note

Make sure Mihomo is not checked in Exclude from subscription type, otherwise the host does not reach the Mihomo subscription together with the mapper options.

mux.cool Multiplexing

Prizrak-Core supports mux.cool multiplexing, compatible with Xray. Xray servers managed by Remnawave need no extra setup: they accept mux.cool on their own.

{
  "xrayJson": [],
  "mihomo": [
    {
      "op": "set",
      "value": {
        "enabled": true,
        "max-carriers": 4,
        "max-concurrency": 8,
        "max-connections": 3,
        "xudp-concurrency": 16,
        "xudp-proxy-udp443": "reject"
      },
      "to": "['mux.cool']"
    }
  ],
  "base64": []
}

The set rule writes the value object into the mux.cool key of this host’s proxy. In the Mihomo subscription the proxy gets this block:

proxies:
  - name: 🇩🇪 Germany
    type: vless
    # ...
    mux.cool:
      enabled: true
      max-carriers: 4
      max-concurrency: 8
      max-connections: 3
      xudp-concurrency: 16
      xudp-proxy-udp443: reject

Caution

Do not enable mux.cool and smux on the same proxy. Clients on regular Mihomo ignore the mux.cool key and connect without multiplexing.

REALITY ML-DSA-65

If mldsa65Seed is set in the REALITY inbound of an Xray server, the server signs the REALITY certificate with a post-quantum ML-DSA-65 signature. Prizrak-Core verifies this signature when the proxy’s reality-opts contain the public key mldsa65-verify.

Put the ML-DSA-65 public key in base64url format into value. It is the mldsa65Verify value that xray mldsa65 prints together with the inbound’s mldsa65Seed.

{
  "xrayJson": [],
  "mihomo": [
    {
      "op": "set",
      "value": "<mldsa65Verify>",
      "to": "['reality-opts']['mldsa65-verify']"
    }
  ],
  "base64": []
}

The rule writes the key into the reality-opts of this host’s proxy:

proxies:
  - name: 🇩🇪 Germany
    type: vless
    # ...
    reality-opts:
      public-key: <X25519 public key>
      short-id: <short id>
      mldsa65-verify: <mldsa65Verify>

Caution

The key must match the server’s mldsa65Seed. If the key is wrong or ML-DSA-65 is not enabled on the server, Prizrak-Core rejects the REALITY certificate and does not connect.

XHTTP Flow Control (h2-flow)

For hosts with the XHTTP transport, Prizrak-Core can enable the HTTP/2 flow governor. With it, the server sends data no faster than the client reads it and does not fill large HTTP/2 windows. This lowers memory use on the client and helps on weak devices. The Xray server needs no setup: the governor works on the client side through standard HTTP/2 flow control. If the server runs Jolymmiles/Xray-core with its own governor (h2Flow), the two work together, and the governor can be on either side or on both.

The governor is off by default and works only in h2 mode, that is ALPN h2 or an empty ALPN. With ALPN h3 or http/1.1 the option has no effect.

{
  "xrayJson": [],
  "mihomo": [
    {
      "op": "set",
      "value": {
        "enabled": true,
        "max-stream-receive-window": 16777216,
        "max-connection-receive-window": 33554432
      },
      "to": "['xhttp-opts']['h2-flow']"
    }
  ],
  "base64": []
}

The rule writes the h2-flow block into the xhttp-opts of this host’s proxy:

proxies:
  - name: 🇩🇪 Germany
    type: vless
    network: xhttp
    # ...
    xhttp-opts:
      # ...
      h2-flow:
        enabled: true
        max-stream-receive-window: 16777216
        max-connection-receive-window: 33554432

max-stream-receive-window and max-connection-receive-window are optional HTTP/2 receive windows in bytes, per stream and per connection, from 65535 to 1 GiB. With the governor they cap the window. Leave them out to keep Go’s default windows (4 MiB per stream); then "enabled": true alone is enough in value.

Note

Add the rule only to hosts with the XHTTP transport. Proxies with other transports do not use the xhttp-opts key. The older h2-flow-control: true key still works, but the h2-flow block is the main one.