---
date: 2026-07-25
tags:
  - подписки
  - приватность
  - hwid
  - клиенты
  - панели
aliases:
  - HWID-привязка
  - Привязка к клиенту
  - HWID device limit
  - Лимит устройств
link: https://docs.rw/docs/features/hwid-device-limit/
---

# 🔒 HWID-привязка и запрет «чужих» клиентов: как продавцы ограничивают выбор

> [!info] О чём заметка
> Разбор двух практик, которые встречаются у продавцов VPN-подписок: **привязка подписки к идентификатору устройства (HWID)** и **ограничение списка допустимых клиентов**. Здесь: как это устроено технически, почему прокси-ядра ([[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]], [[xray/project-x|Xray-core]]) об этом ничего не знают, что ограничение даёт продавцу и чем оборачивается для пользователя. Про сами клиенты — в [[Clash/07-clients|обзоре оболочек]] и [[xray/clients-and-routing|клиентах Xray]].

## TL;DR

- **Ни один прокси-протокол не знает, с какого устройства вы подключаетесь.** Сервер аутентифицирует пользователя по UUID или паролю — и всё. HWID в [[xray/vless|VLESS]], [[protocols/trojan|Trojan]] или [[protocols/shadowsocks|Shadowsocks]] отсутствует как понятие.
- Привязка живёт **этажом выше** — в HTTP-запросе за подпиской. Панель управления требует от клиента заголовок с идентификатором устройства (в Remnawave это `x-hwid`, плюс необязательные `x-device-os`, `x-ver-os`, `x-device-model`, `user-agent`), и **без него отдаёт 404** — подписку нельзя ни добавить, ни обновить.
- Отсюда и запрет «чужих» клиентов: заголовок умеют слать не все. По документации Remnawave это Happ, v2RayTun, Koala Clash, FlClashX, Prizrak-Box, Throne; в v2rayN, Hiddify и Passwall на июль 2026 висят открытые запросы на такую поддержку.
- Вторая форма привязки — **на стороне клиента**: Happ поддерживает шифрованные подписки `happ://crypto...`, скрывающие адреса серверов, и настройку, запрещающую подписчику просматривать и редактировать конфигурацию.
- У ограничений есть понятная цель — борьба с перепродажей одного аккаунта на десятки людей. Но у пользователя оно отнимает свободу выбора ядра, а продавцу отдаёт **инвентарь ваших устройств** и журнал их активности.
- Этот проект такие ограничения не применяет: конфигурация выдаётся в открытом виде, HWID не собирается, конкретный клиент не навязывается.

## Что вообще ограничивают

Стоит развести два разных механизма, которые в разговорах смешивают.

**Первое — лимит устройств (HWID device limit).** Подписка привязывается к идентификаторам устройств: сервер запоминает, с каких из них её загружали, и не даёт превысить установленное число. Формулировка задачи легитимная — один оплаченный доступ не должен работать у сорока человек одновременно.

**Второе — ограничение выбора клиента.** Прямое следствие первого: раз для работы нужен особый заголовок, годятся только те приложения, которые умеют его отправлять. Клиент без поддержки получает от панели ошибку и подписку добавить не может — независимо от того, оплачен ли доступ.

К этому добавляется третья, необязательная надстройка: **скрытие самой конфигурации от пользователя**, чтобы он не смог унести адреса серверов в другое приложение.

Проще говоря: сервер по-прежнему готов вас обслужить с любого клиента — просто вам не дают взять у него настройки. Ограничение построено не на протоколе, а на доступе к конфигу.

## Как это работает технически

Разберём на примере панели **Remnawave**, где механизм задокументирован явно ([HWID device limit](https://docs.rw/docs/features/hwid-device-limit/)).

Когда клиент идёт по ссылке подписки, он отправляет обычный HTTP-запрос. При включённом лимите панель ожидает в этом запросе набор заголовков:

- **`x-hwid`** — идентификатор устройства, **обязательный**;
- `x-device-os`, `x-ver-os`, `x-device-model` — операционная система, её версия и модель устройства;
- `user-agent` — название и версия приложения.

Дальше логика простая. Заголовка `x-hwid` нет — панель отвечает **404**, и пользователь не может ни добавить подписку, ни переподключить её заново. Заголовок есть — панель регистрирует устройство и сверяет, не превышен ли лимит.

Идентификатор при этом **генерирует само приложение** и хранит у себя; это не «серийный номер процессора», а стабильная строка, привязанная к установке. Отсюда практическое следствие: переустановка клиента или смена устройства нередко занимает слот, и его приходится освобождать через продавца.

> [!note] Лимит устройств — не криптографическая защита
> Механизм держится на добросовестности клиентского приложения: заголовок формирует и отправляет сам клиент. В апреле реализации встречались и ошибки в серверной части — в Remnawave, например, публиковалось предупреждение о состоянии гонки (race condition) в логике регистрации устройств, позволявшем зарегистрировать больше устройств, чем разрешено ([GHSA-985p-44h5-v3pq](https://github.com/remnawave/backend/security/advisories/GHSA-985p-44h5-v3pq)). Конкретная ошибка исправлена, но общий вывод остаётся: лимит — административная мера, а не гарантия.

## Что при этом делают ядра: ничего

Это ключевой раздел, ради которого заметка и написана.

**Прокси-ядра к HWID-привязке непричастны.** Ни [[Clash/02-mihomo|mihomo]], ни [[sing-box/sing-box-extended|sing-box]], ни [[xray/project-x|Xray-core]] не имеют понятия «идентификатор устройства». Всё, что знает сервер при подключении, — это учётные данные: UUID пользователя в [[xray/vless|VLESS]] и [[protocols/vmess|VMess]], хеш пароля в [[protocols/trojan|Trojan]], ключ в [[protocols/shadowsocks|Shadowsocks]]. В спецификациях протоколов поля «с какого устройства» просто нет.

Из этого следуют три практических вывода.

**Конфиг работает где угодно.** Если у вас на руках ссылка `vless://…`, она заведётся в любом ядре, поддерживающем нужный протокол и транспорт: в mihomo, в sing-box, в Xray-core, в клиенте на роутере. Сервер аутентифицирует вас по UUID и не различает приложения.

**Ломается не подключение, а получение конфига.** При включённом HWID-лимите вы упираетесь в стену на шаг раньше — на этапе загрузки подписки. Симптом узнаваемый: клиент сообщает об ошибке 404 или «подписка не найдена», хотя ссылка верная и оплата в порядке. Это не поломка ядра и не блокировка провайдером, а отказ панели отдать конфигурацию приложению без нужного заголовка.

**Автообновление подписки становится точкой отказа.** Даже если конфиг однажды получен вручную, при ротации серверов у продавца обновление не пройдёт — и узлы перестанут работать по мере смены адресов.

> [!tip] Как проверить, включена ли привязка
> Откройте ссылку подписки обычным браузером или запросите её через `curl`. Если возвращается конфигурация — HWID-лимита нет, и вы свободны в выборе ядра. Если приходит 404 или пустой ответ, а в «правильном» клиенте подписка работает — значит, панель фильтрует запросы по заголовкам. Отдельный признак — ссылка вида `happ://crypto...`: это шифрованная подписка, рассчитанная на конкретное приложение.

## Привязка на стороне клиента

Второй слой ограничений реализован не панелью, а самим приложением. У Happ, по [его документации](https://www.happ.su/main/ru/faq/adding-configuration-subscription), есть **шифрованные подписки** (ссылки начинаются с `happ://crypto…`), которые скрывают настройки серверов и сам адрес подписки, и **настройка, отключающая просмотр и редактирование конфигурации** для подписчиков — причём как для уже добавленных подписок, так и для будущих.

Оценивать это стоит без демонизации: **Happ — просто клиент**, он не продаёт доступ, а даёт продавцам инструменты, и те решают, включать их или нет. Вопрос не к приложению, а к тому, кто продаёт вам подписку с такими настройками.

Но следствие для пользователя однозначное: **вы не видите, к какому серверу подключаетесь**. Нельзя проверить адрес и страну выхода, нельзя перенести доступ в другое ядро, нельзя посмотреть, какие параметры маскировки вам выдали. Доверие к продавцу перестаёт быть проверяемым — а в теме обхода блокировок это дорого стоит: именно возможность посмотреть конфигурацию отличает «сервис, которому я доверился осознанно» от «чёрного ящика с моим трафиком внутри».

## Что это значит для приватности

HWID — **стабильный идентификатор**, который приложение отправляет при каждом обращении за подпиской. Вместе с сопутствующими заголовками продавец получает:

- **список ваших устройств** — сколько их, какие операционные системы, версии и модели;
- **журнал обращений** — когда и с какого устройства подписка обновлялась, то есть косвенную картину вашей активности и смены устройств;
- **устойчивую связку** «аккаунт ↔ конкретные устройства», которая переживает смену IP-адреса.

Ничего из этого не требуется для того, чтобы прокси работал. Это данные, собираемые ради контроля за перепродажей — и, как любые собранные данные, они могут утечь, быть переданы или запрошены. Общая логика тут та же, что и в остальных заметках про слежку: **чем меньше стабильных идентификаторов вы раздаёте, тем меньше связок можно построить**; про механику таких связок в вебе — в [[Localhost-tracking-Meta-Yandex-SOCKS5|разборе локальной слежки Meta и Яндекса]].

> [!warning] Обратная сторона: у ограничений есть причина
> Справедливо признать и мотив продавца. Один аккаунт, разошедшийся по десяткам людей, съедает канал, ухудшает связь остальным и повышает шанс, что сервер попадёт под блокировку из-за подозрительной активности. Лимит устройств — это попытка решить реальную проблему, а не только желание удержать пользователя. Спор не о том, есть ли у продавца интерес, а о том, кто платит за его решение: выбор клиента и часть приватности отдаёт пользователь.

## Позиция этого проекта

Ограничения выше — не отраслевая необходимость, а решение конкретного продавца. Практика проекта, в рамках которого ведётся это хранилище, противоположная. VPN-подписка выдаётся через Telegram-бота [@zapretvpns_bot](https://t.me/zapretvpns_bot) (подробный разбор — в заметке [[premium/zapret-vpn-bot|Zapret VPN-бот]]), и правила там такие:

- **Клиент выбирает пользователь.** Приложения не фильтруются ни по названию, ни по заголовку `User-Agent`: Happ, INCY или другой «обязательный» клиент не требуется. Подойдёт любое ядро, поддерживающее нужный протокол — [[Clash/02-mihomo|mihomo]] с его оболочками, [[sing-box/sing-box-extended|sing-box]], [[xray/project-x|Xray-core]], клиент на роутере.
- **Подписка — не единственный вход.** Кроме готового профиля формата mihomo выдаются прямые стандартные конфигурации: строка `vless://…`, файл WireGuard/AWG, параметры Hysteria 2. Не понимает ваше приложение подписку — берите прямой конфиг.
- **HWID не собирается.** Аппаратный идентификатор устройства не запрашивается, заголовок `x-hwid` при выдаче не требуется, инвентарь ваших устройств не ведётся. «Слот устройства» в интерфейсе — это просто номер конфига, который вы сами подписываете («телефон», «роутер»), а `Fingerprint` у VLESS — TLS-профиль браузера для маскировки; ни то, ни другое к железу отношения не имеет.
- **Конфигурация открыта.** Адрес сервера и параметры видны: их можно проверить, сохранить у себя и перенести на другое устройство и в другое ядро, не спрашивая разрешения.
- **Единственное реальное условие — техническое:** клиент должен понимать нужный протокол и формат конфига. Если не понимает — это вопрос совместимости, а не политика сервиса.

Проще говоря: доступ, который вы оплатили, остаётся вашим, а не работает только внутри одобренного приложения.

Это не значит, что вопрос доверия снимается: любой VPN-оператор технически видит адреса, к которым вы подключаетесь, — отсутствие HWID лишь сокращает объём собираемых о вас данных. Честные оговорки на этот счёт собраны в самой [[premium/zapret-vpn-bot|заметке о боте]].

## Что делать пользователю

- **Спрашивайте до оплаты**, есть ли лимит устройств и требуется ли конкретный клиент. Это нормальный вопрос, и уклончивый ответ сам по себе информативен.
- **Проверяйте ссылку подписки** запросом из браузера или `curl` (см. подсказку выше) — так вы узнаете реальное положение дел, а не рекламное.
- **Избегайте шифрованных подписок**, если для вас важна проверяемость: скрытый конфиг означает, что вы не можете убедиться даже в стране выхода.
- **Держите конфиг у себя.** Сохранённая ссылка `vless://…` или выгруженный YAML — это ваша страховка на случай, когда клиент перестанет обновляться или продавец сменит правила.
- Если ограничение уже мешает — помните, что упирается оно в **получение конфигурации**, а не в протокол: имея на руках параметры узла, вы вольны использовать любое ядро.

## 📚 См. также

- [[Clash/07-clients|Клиенты на ядре Clash/mihomo]] — какие оболочки живы и почему обновление ядра важнее обновления интерфейса.
- [[xray/clients-and-routing|Клиенты и маршрутизация Xray]] — как подключиться и развести трафик; там же про формат ключей и подписок.
- [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — выбор ядра, который HWID-привязка фактически отнимает.
- [[protocols/00-overview|Обзор протоколов]] — почему аутентификация в протоколах устроена как «UUID или пароль», без понятия устройства.
- [[premium/zapret-vpn-bot|Zapret VPN-бот]] — пример подписки без привязки к устройству и без обязательного клиента.
- [[Privacy|Приватность]] — общие принципы: меньше стабильных идентификаторов, меньше связок.
- 🔗 [HWID device limit — документация Remnawave](https://docs.rw/docs/features/hwid-device-limit/) — первоисточник по заголовкам и поведению панели.
- 🔗 [FAQ Happ: добавление конфигурации и подписки](https://www.happ.su/main/ru/faq/adding-configuration-subscription) — описание шифрованных подписок и скрытия конфигурации.

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/subscriptions/hwid-client-lock.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).