# Расширить Security Layer в Host Overrides: добавить REALITY и настройки realitySettings / tlsSettings

**URL:** https://f.docs.rw/t/topic/522
**Category:** Предложения
**Created:** 2026-08-11T00:36:30Z
**Posts:** 2

## Post 1 by @Gwynbleidd_YTV — 2026-08-11T00:36:30Z

В настройках Host уже есть возможность переопределить `Security Layer`, однако сейчас этого недостаточно для сложных Xray-конфигураций.

На данный момент можно выбрать:

```
DEFAULT
TLS
NONE
```

При этом:

- нельзя выбрать `REALITY`;
- нельзя задать отдельные `realitySettings`;
- нельзя полноценно задать `tlsSettings`;
- параметры security фактически продолжают зависеть от выбранного runtime inbound.

Это создаёт проблему, например, для рабочей Xray-схемы:

```
Client XHTTP + REALITY
        ↓
VLESS RAW + REALITY :443
        ↓
REALITY termination
        ↓
fallback
        ↓
Unix socket
        ↓
VLESS XHTTP
security: none
```

Внутренний XHTTP inbound здесь **должен иметь `security: none`** , поскольку REALITY уже обработан внешним inbound.

Но клиенту при этом необходимо выдать:

```
network = xhttp
security = reality

realitySettings:
  serverName / SNI
  publicKey
  shortId
  fingerprint
```

Если Host привязать непосредственно к runtime XHTTP inbound, Remnawave наследует `security: none` и генерирует неправильную клиентскую конфигурацию.

Сейчас приходится создавать отдельный **donor inbound** с:

```
network = xhttp
security = reality
```

и нужными `realitySettings`.

Этот inbound не участвует в передаче трафика и нужен исключительно как источник параметров для генерации подписки.

Предлагаю расширить существующий механизм `Security Layer` в Host Overrides:

```
Security Layer:
- Default
- None
- TLS
- Reality
```

И в зависимости от выбранного значения показывать соответствующий блок настроек.

Для `REALITY`, например:

```
realitySettings:
- serverName / SNI
- publicKey
- shortId
- fingerprint
- spiderX при необходимости
```

Для `TLS`:

```
tlsSettings:
- serverName
- ALPN
- fingerprint
- остальные необходимые client-side параметры
```

То есть Host должен иметь возможность **полностью переопределить client-facing transport security независимо от security выбранного inbound**.

Это позволит корректно использовать fallback/socket и другие сложные Xray-схемы без создания фиктивных donor inbound.

---

## Post 2 by @remnawave — 2026-08-11T05:14:20Z

Если вы на **dev** -ветке панели находитесь, можете попробовать использовать свежий `Mapper`(Advanced-раздел Хоста).

Думаю, что это будет намного гибче и удобнее.

Например

```
{
  "xrayJson": [
    {
      "op": "set",
      "value": {
        "shortId": "<shortId>",
        "publicKey": "<pubkey>",
        "serverName": "example.com",
        "fingerprint": "chrome"
      },
      "to": "streamSettings.realitySettings"
    },
    {
      "op": "set",
      "value": "reality",
      "to": "streamSettings.security"
    }
  ],
  "mihomo": [],
  "base64": []
}
```