Server Description: Hints to the Client in Happ/INCY

By default the client shows the user the technical "VLESS | TCP | REALITY" — to an ordinary person this is scary gibberish. Server Description lets you label the tile in a human way: "Connect," "YouTube ad-free," "ChatGPT." Below is where it's enabled and what the limitations are. It works in Happ, INCY, and other extended clients.

This material is about engineering your own infrastructure and is educational in nature. You are responsible for complying with the laws of your own jurisdiction.

Why it's needed

Most services dump on the user dozens of hosts and strings like VLESS | gRPC, VLESS | TCP | REALITY, and the person gets lost: what to pick out of this, how one differs from another. The ordinary client doesn't need this — they need to press one button and have it work. Server Description lets you replace the technical string with a hint by meaning: the client sees not the protocol but the tile's purpose.

The point is for the person to choose by eye, not decode terms. Label the main balancer "Connect" — the client taps it and doesn't think.

Where it's configured

In the Remnawave panel the field lives in the advanced settings of a specific host:

Hosts → select the host you need → Advanced → scroll down → Server Description — enter any text.

Each host is labeled separately, so you can hang clear labels on all the tiles the client sees.

Good label examples

Label by purpose, not by technicals:

• The main balancer (with auto-select behind it) — "Connect" or "Auto-select."
• A dedicated RF node for video — "YouTube ad-free."
• A node/profile with WARP for AI services — "ChatGPT, Gemini, Claude."
• A backup transport — "Backup channel."

This way the user immediately sees which tile they need and isn't scared off by arcane terms. It directly cuts the "what should I choose" tickets.

Two important limitations

Here's the honest fly in the ointment — don't promise the client something that won't work.

1. Maximum 30 characters. The field is short. varchar(30) — you can't fit a long phrase, so plan the labels to be compact.

2. Only "extended" clients see it. Server Description is understood by Happ, INCY, FlClash X, Flowvy, koala-clash, prizrak-box and the like. But v2rayTun, v2rayNG, V2Box, Streisand, and the browser will not show this label — they're left with the technical string VLESS | TCP | REALITY. So if your audience sits on v2rayTun — the nice labels won't reach them.

The practical takeaway: if you're building UX around human-readable labels, aim for Happ/INCY as the primary client — there it works perfectly. For a mixed audience keep labels compact and don't tie anything critical to them.

If the label is "not visible" in Happ

A common situation: you entered a Server Description, but the app still shows the technical string. Almost always this is the client cache — Happ is holding an old version of the subscription. The cure:

• The client taps "Update subscription" — often that's enough.
• Didn't help — delete the profile and re-add by link. A full re-import reliably pulls in fresh labels.
• Better to check on a real device with the client your audience uses, not in the browser — in the browser labels aren't shown anyway, and you'll conclude "it doesn't work."

INCY as an alternative to Happ

Worth knowing: to truly customize Happ for your brand (pushes, logo, your own buttons) you need the paid partner subscription from Happ's developer, and they ask a lot for it. INCY is the same kind of extended client, it understands Server Description and human-readable labels just as well, looks great, and doesn't charge for the basics. If you're just choosing the "face" of your service — take a look at INCY as the primary one, and keep Happ as a backup.

Bottom line

Server Description is a cheap way to make a service friendly: labels by meaning instead of protocols, up to 30 characters, works in Happ/INCY and kin (but not in v2rayTun/the browser). Not visible — update or re-import the subscription. How to set up the routing rules on the client side themselves (what goes direct and what through the node) — in the article "Client-Side Routing Rules."