Вступление

Когда работаешь с узкими техническими темами, быстро становится понятно: обычной LLM недостаточно просто сказать "будь экспертом". Модель может звучать уверенно, но при этом смешивать старые практики с новыми, не учитывать версии, клиентские ограничения, DNS, routing, threat model и реальные условия сети.

Особенно это заметно в темах Xray-core, VLESS, REALITY, XHTTP, split tunneling и клиентских VPN-профилей. Здесь нельзя отвечать в стиле "ставь вот так, это лучший вариант". То, что работает в одной связке клиент-сервер, может сломаться на другой версии Xray-core, в другом GUI-клиенте, на другом провайдере или при другой модели угроз.

Поэтому я решил сделать не просто промпт, а отдельный AI-скилл - Senior Xray VPN Architect. Его задача - не генерировать случайные конфиги, а работать как инженерный помощник: уточнять контекст, проектировать архитектуру, ревьюить JSON, различать client-side и server-side routing, предупреждать о рисках и давать проверяемые шаги.

Что такое Senior Xray VPN Architect

Senior Xray VPN Architect - это доменный AI-скилл для работы с авторизованной приватной VPN/proxy-инфраструктурой на базе Xray-core. Он нужен для проектирования, ревью, диагностики, миграции и мониторинга решений, где используются VLESS, REALITY, XHTTP, TLS, XTLS Vision, DNS-routing, split tunneling, WARP outbound, CDN/reverse proxy и разные клиентские приложения.

Важно: это не "бот для обхода всего подряд" и не набор копипастных туториалов. Скилл изначально проектировался как defensive/private-network инструмент: для собственных серверов, собственных клиентов, легитимного администрирования, приватности и устойчивости связи.

Система состоит из нескольких слоёв:

  • главный файл поведения - SKILL.md;
  • decision framework для выбора архитектуры - decision-framework.md;
  • набор проверенных топологий - vetted-topologies.md;
  • справка по XHTTP и REALITY - xhttp-reality.md;
  • справка по DNS/routing и split tunnel - dns-routing.md;
  • справка по клиентской совместимости - client-compatibility.md;
  • эксплуатация и мониторинг - operations-monitoring.md;
  • список первоисточников для актуализации - current-sources.md;
  • шаблоны ответов - architecture-brief.template.md и config-review.template.md;
  • Python-линтер для Xray JSON-конфигов - lint_xray_config.py;
  • интерфейсное описание скилла - openai.yaml.

Именно эта структура отличает скилл от обычного длинного промпта. Здесь есть роль, правила, база знаний, режимы работы, шаблоны, проверки и требования к актуальности.

Почему одного системного промпта мало

Первый соблазн при создании такого помощника - написать большой системный промпт: "ты Senior Architect, отвечай профессионально". Но этого недостаточно.

Проблема в том, что сложная инфраструктура не описывается одним правилом. Для качественного ответа нужно учитывать:

  • версию Xray-core;
  • конкретный клиент и его backend;
  • способ импорта профиля: URI, subscription, raw JSON, panel profile;
  • серверную топологию;
  • DNS-модель;
  • routing policy;
  • threat model;
  • наличие CDN, домена, reverse proxy;
  • допустимую сложность поддержки;
  • fallback и rollback.

Если всё это просто засунуть в один промпт, получится длинная каша. Поэтому я разделил знания на отдельные reference-файлы. Главный файл SKILL.md задаёт поведение, а дополнительные файлы используются как инженерная память.

Safety-границы как обязательный слой

Отдельный важный слой - safety. Скилл должен помогать только в авторизованном контексте: собственные серверы, собственные устройства, приватная инфраструктура, defensive administration, аудит конфигураций и устойчивость связи.

В SKILL.md прямо задано, что скилл не должен помогать со скрытым доступом, кражей учётных данных, атаками, боттингом, массовым abuse, destructive scanning или обходом ограничений там, где у пользователя нет разрешения.

Ещё одно важное правило - не раскрывать секреты. В скилле отдельно указано, что нельзя публиковать UUID, private keys, WARP private keys, short IDs, session keys, tokens, subscription URLs, panel credentials и чувствительные IP-адреса.

Это важно не только для работы самого агента, но и для публикации файлов скилла. Если я прикладываю файлы к статье, они должны быть sanitized: без ключей, токенов, реальных серверов, временных S3-ссылок, presigned URLs, доменов и любых данных, по которым можно восстановить рабочую инфраструктуру.

Режимы работы: не отвечать одинаково на разные задачи

Один и тот же вопрос про Xray может означать совершенно разные задачи. Пользователь может хотеть:

  • спроектировать новую архитектуру;
  • проверить уже существующий JSON;
  • понять, почему не работает подключение;
  • мигрировать с одной схемы на другую;
  • настроить мониторинг;
  • просто разобраться в концепции.

Поэтому в SKILL.md скилл разделён на режимы:

  • architecture - проектирование топологии;
  • config-review - ревью существующего конфига;
  • troubleshooting - диагностика проблемы;
  • migration - переход с одной схемы на другую;
  • monitoring - эксплуатация, проверки, ротации;
  • explanation - объяснение концепции без готового деплоя.

Это простое разделение сильно улучшает качество ответов. Агент перестаёт отвечать общими словами и начинает работать в правильном режиме.

Например, если пользователь приносит JSON, скилл должен не рассказывать теорию про VLESS, а сначала провести config-review: найти P0/P1/P2-проблемы, указать где проблема, почему это риск, как исправить и как проверить. Для этого используется шаблон config-review.template.md.

Если задача архитектурная, то используется другой формат: короткий вывод, рекомендуемая топология, требования, DNS/routing, client compatibility, monitoring, risks and fallback. Такой формат зафиксирован в architecture-brief.template.md.

Decision Framework: как скилл выбирает архитектуру

Важная часть скилла - decision-framework.md. Его задача - не дать модели выбрать транспорт "по моде".

В мире VPN/proxy-инфраструктуры легко скатиться в лозунги:

  • "VLESS всегда лучший";
  • "REALITY решает всё";
  • "XHTTP самый устойчивый";
  • "CDN всё скроет";
  • "latest значит правильно".

В нормальной архитектуре так не работает. Любое решение должно быть привязано к constraints.

Decision framework заставляет смотреть на:

  • цель пользователя: full tunnel, split tunnel, target services, low latency, resilience, maintainability;
  • threat model: passive observation, active probing, DNS leakage, provider blocking, target-service VPS blocking;
  • среду: страна, ISP, VPS location, CDN, domain;
  • клиентские устройства и GUI;
  • стоимость, сложность, обновления, мониторинг и fallback.

После этого для каждой кандидатной топологии нужно указать:

  • fit;
  • required versions/client support;
  • expected latency/overhead;
  • detection and failure surface;
  • operational burden;
  • fallback path.

Такой подход превращает ответ из "ставь X" в инженерное сравнение trade-offs.

Проверенные топологии: паттерны, а не универсальные рецепты

Отдельный файл vetted-topologies.md содержит набор проверенных архитектурных паттернов. Это не готовые рецепты, которые надо применять всегда, а именно паттерны, которые выбираются по условиям.

Внутри есть несколько основных вариантов.

Direct VLESS + REALITY + TCP/Vision

Это простой вариант для личной инфраструктуры с минимальным количеством moving parts. Он может быть хорошим выбором, если клиент поддерживает REALITY/Vision, серверный IP доступен из нужных сетей, а пользователю не нужен CDN или origin shielding.

Но у него есть ограничения: VPS IP виден клиентской сети, cover/serverName strategy может измениться, а GUI-клиенты могут некорректно импортировать параметры.

VLESS + XHTTP + REALITY

Эта схема нужна не потому, что XHTTP "новый", а только если его свойства подходят под конкретную задачу. Здесь обязательно нужно проверять версию Xray-core, версию клиента, режим XHTTP и способ импорта профиля.

Особенно важно, что связка XHTTP + REALITY + auto может быть чувствительной к версии. Это отдельно раскрывается в xhttp-reality.md.

CDN XHTTP + TLS

Этот вариант имеет смысл, если у пользователя есть домен, CDN/reverse proxy и готовность поддерживать сертификаты, DNS, origin hardening и CDN constraints.

Но CDN - это не магия. CDN может менять поведение, ломать streaming assumptions, добавлять latency или раскрывать origin при неправильной настройке.

WARP outbound

WARP outbound полезен не как "универсальное решение против блокировок", а как отдельный egress для сервисов, которые не любят VPS IP. Это серверная routing-задача: трафик уже пришёл на VPN-сервер, и сервер решает, через какой outbound его выпустить.

Cascade entry + exit

Cascade помогает разделить visible entry node и exit node, но увеличивает задержку, сложность и количество точек отказа.

Split-tunnel RU/direct + foreign proxy

Этот паттерн нужен, когда локальные, банковские, государственные, региональные или чувствительные к географии сервисы должны идти напрямую, а остальной трафик - через proxy. Но здесь особенно важно понимать, где именно исполняется routing policy.

Главное уточнение: split tunneling нужно решать на стороне клиента

Один из важных архитектурных выводов, который я добавил отдельно: настоящий пользовательский split tunneling должен решаться на стороне клиента или локального gateway, а не только на сервере VPN.

Почему?

Потому что сервер видит только тот трафик, который уже попал в туннель. Если запрос уже ушёл на VPN-сервер, сервер может выбрать egress: freedom, WARP, cascade, другой proxy outbound. Но сервер уже не может сделать "direct через локального провайдера пользователя", потому что локальный direct должен произойти до отправки трафика в туннель.

Правильное разделение такое:

Client-side / gateway-side routing:
  local/private/RU domains/IPs -> direct через локальную сеть пользователя
  selected foreign/default traffic -> proxy/VPN
  selected blocked/noisy traffic -> block

Server-side routing:
  traffic already inside VPN tunnel -> freedom / WARP / cascade / another outbound

Поэтому скилл должен уметь не только давать server config, но и генерировать client JSON с split tunnel, если клиент это поддерживает.

Пример логики клиентского профиля:

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "<REDACTED_SERVER_DOMAIN>",
            "port": 443,
            "users": [
              {
                "id": "<REDACTED_UUID>",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:ru", "domain:su", "domain:xn--p1ai"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "outboundTag": "proxy"
      }
    ]
  }
}

Это не production-config, а иллюстрация принципа. В реальной задаче скилл должен уточнить клиент, версию, core/backend, способ импорта, DNS-модель, geosite/geoip dataset и то, сохраняет ли клиент custom routing rules.

Эта логика связана сразу с двумя файлами: dns-routing.md и client-compatibility.md.

Почему client compatibility критична

Одна из частых ошибок: считать, что если Xray-core поддерживает функцию, значит она заработает в любом клиенте. Это не так.

Файл client-compatibility.md отдельно фиксирует принцип: server-side Xray support не гарантирует client UI/import support.

Проблемы могут быть такими:

  • GUI-клиент молча выкидывает неизвестные поля;
  • URI импортирует только параметры подключения, но не routing;
  • subscription URL не переносит полноценную DNS/routing policy;
  • клиент использует старый embedded core;
  • клиент поддерживает REALITY, но не поддерживает нужный flow;
  • XHTTP есть на сервере, но отсутствует в интерфейсе клиента;
  • NekoBox/NekoRay могут использовать другой backend или переводить формат;
  • v2rayNG может импортировать connection URI, но routing остаётся отдельной настройкой;
  • v2rayA/gateway-сценарии зависят от TUN, DNS и router rules.

Поэтому скилл должен спрашивать:

  • точное имя клиента;
  • платформу;
  • версию;
  • core/backend;
  • способ импорта;
  • поддерживаются ли REALITY-параметры;
  • поддерживается ли XHTTP mode;
  • сохраняются ли DNS/routing rules;
  • есть ли raw JSON mode.

И только после этого можно говорить, где будет жить split tunnel: на клиенте, на локальном gateway, на сервере или гибридно.

DNS и routing как отдельный слой архитектуры

VPN-конфиг - это не только inbound и outbound. DNS и routing часто важнее, чем выбор транспорта.

Файл dns-routing.md фиксирует несколько принципов:

  • DNS вне нужного пути может раскрывать домены;
  • браузер, ОС, клиент и Xray могут резолвить по-разному;
  • нужно явно проектировать, кто и через какой outbound резолвит домены;
  • routing rules должны идти от специфичных к широким;
  • final catch-all должен быть явным;
  • .ru, .su, .рф и punycode нужно учитывать отдельно;
  • нельзя считать, что geosite/geoip dataset всегда свежий и одинаковый у всех.

Это особенно важно для split tunnel. Если пользователь хочет, чтобы российские и локальные сервисы шли напрямую, а остальные через VPN, мало просто написать пару domain rules. Нужно проверить DNS path, direct/proxy path, local/private ranges, punycode, geosite/geoip и поведение конкретного клиента.

Именно поэтому скилл должен отвечать не "вставь эти правила", а "вот модель, вот где она исполняется, вот что проверить".

XHTTP и REALITY: не магия, а version-sensitive слой

XHTTP и REALITY - одна из причин, почему скиллу понадобилось правило актуализации. Эти технологии нельзя описывать как вечные рецепты.

Файл xhttp-reality.md фиксирует, что XHTTP вырос из SplitHTTP, а основные пользовательские режимы - auto, packet-up, stream-up, stream-one. Поведение этих режимов зависит от версии, и нельзя переносить старые SplitHTTP-сниппеты без проверки текущего xhttpSettings.

Для диагностики XHTTP + REALITY скилл должен уточнять:

  • точную версию Xray-core;
  • есть ли downloadSettings;
  • какой effective HTTP path используется: H1, H2 или H3;
  • поддерживает ли клиент GUI нужный режим и поля;
  • как ведёт себя Browser Dialer;
  • не влияют ли CDN/reverse proxy/TLS/ALPN на поведение.

Отдельный принцип: REALITY нельзя описывать как "полностью недетектируемый". Скилл должен говорить о detection surface, active probing resistance, operational fragility cover domain и fallback, а не обещать абсолютную устойчивость.

Правило актуальности: когда нельзя отвечать из памяти

В файле current-sources.md собраны первоисточники, которые скилл должен проверять для свежих и спорных вопросов:

  • Xray-core releases;
  • Xray-core repository;
  • Project X docs;
  • XHTTP: Beyond REALITY discussion;
  • Xray examples;
  • REALITY repository;
  • transport config source;
  • XHTTP/SplitHTTP transport code;
  • client-specific docs and release notes.

Это важно, потому что документация может отставать от release notes и кода. Особенно это касается XHTTP, Browser Dialer, H2/H3, QUIC/finalmask, REALITY interaction и client GUI support.

Общее правило такое: если вопрос звучит как "latest", "current", "2026", "сейчас работает?", "поддерживает ли клиент?", "как ведёт себя XHTTP mode?", скилл не должен уверенно отвечать из старой памяти. Он должен проверять первоисточники.

Линтер как детерминированная проверка

Один из самых полезных компонентов скилла - lint_xray_config.py.

LLM может посмотреть на JSON и пропустить очевидную ошибку: отсутствующий outbound, неправильный outboundTag, неявный domainStrategy, debug logs, пустые DNS servers или неочевидную связку XHTTP + REALITY + auto.

Линтер не заменяет полное ручное ревью и не валидирует всю Xray schema. Но он ловит базовые architecture и hygiene signals:

  • JSON должен парситься;
  • root должен быть JSON object;
  • должны быть inbounds;
  • должны быть outbounds;
  • log.loglevel не должен быть debug в production;
  • XHTTP/SplitHTTP должен быть замечен отдельно;
  • XHTTP + REALITY + auto требует version-specific review;
  • REALITY settings должны быть проверены на базовые поля;
  • DNS servers должны быть заданы осознанно;
  • routing rules должны существовать;
  • outboundTag должен ссылаться на существующий outbound;
  • domainStrategy должен быть явным;
  • final routing rule должен иметь понятное поведение.

То есть скилл получает не только "рассуждение", но и маленький детерминированный инструмент проверки. Это снижает риск галлюцинаций и делает config-review более воспроизводимым.

Шаблоны ответов: предсказуемый вывод вместо потока мыслей

Даже если модель знает тему, она может забыть важный слой ответа. Например, хорошо описать transport, но забыть DNS. Или дать топологию, но не указать fallback. Или найти проблему, но не сказать, как её проверить.

Поэтому в скилле есть шаблоны:

  • architecture-brief.template.md - для проектирования;
  • config-review.template.md - для ревью конфигов.

Для архитектуры ответ должен содержать:

  • context;
  • threat model;
  • recommended topology;
  • DNS and routing;
  • client compatibility;
  • monitoring and fallback;
  • open questions.

Для config-review:

  • scope;
  • findings;
  • checks;
  • residual risks.

Такой формат заставляет агента мыслить слоями и не пропускать важные части.

Operations и monitoring: жизнь после деплоя

VPN/proxy-инфраструктура не заканчивается первым рабочим подключением. Её нужно обновлять, мониторить, документировать и уметь откатывать.

Файл operations-monitoring.md описывает Day-2 operations:

  • держать known-good rollback config;
  • не держать debug logs в production;
  • защищать panel/admin endpoints;
  • документировать топологию;
  • проверять server reachability;
  • проверять handshake/connect success;
  • измерять latency из разных сетей;
  • проверять DNS behavior;
  • проверять direct/proxy routing;
  • мониторить target-service reachability;
  • следить за error rate, restart count и traffic anomalies;
  • читать release notes перед major update;
  • тестировать обновления на одном клиенте/профиле;
  • держать старый binary/config для rollback.

Это превращает скилл из "помощника на момент настройки" в помощника для эксплуатации.

Пример рабочего сценария

Представим запрос:

> Хочу личный Xray VPN. Российские и локальные сервисы должны идти напрямую, остальное - через VPN. Клиент - v2rayN или NekoBox. Некоторые сервисы, которые не любят VPS IP, возможно, нужно выпускать через WARP.

Обычный ответ мог бы сразу предложить server routing. Но Senior Xray VPN Architect должен действовать иначе.

Сначала он определяет режим: architecture или migration.

Потом уточняет:

  • версию Xray-core;
  • клиент и его версию;
  • платформу;
  • raw JSON или subscription;
  • нужен ли TUN;
  • где должна исполняться routing policy;
  • какие домены идут direct;
  • какие идут proxy;
  • нужен ли WARP как server-side egress;
  • какая DNS-модель допустима.

Дальше он разделяет архитектуру:

Client-side:
  local/private/RU -> direct
  foreign/default -> proxy
  optional blocklist -> block

Server-side:
  accepted VPN traffic -> freedom / WARP / cascade / fallback

После этого скилл может дать sanitized client JSON, server-side topology, DNS/routing checks, compatibility risks и rollback plan.

Ключевой момент: он не должен выдавать "магический конфиг". Он должен объяснить, где исполняется каждое правило и как проверить, что оно реально работает.

Подготовка файлов к публикации

Так как к статье прикладываются файлы скилла, их нужно обязательно вычистить от чувствительных данных.

Перед публикацией нужно удалить или заменить:

  • реальные UUID;
  • private keys;
  • public keys, если они связаны с рабочей инфраструктурой;
  • WARP private keys;
  • short IDs;
  • session keys;
  • API keys;
  • tokens;
  • subscription URLs;
  • panel credentials;
  • SSH hostnames;
  • SSH usernames, если они раскрывают инфраструктуру;
  • реальные IP-адреса VPS;
  • реальные домены;
  • REALITY serverNames/cover domains, если они чувствительные;
  • presigned/S3-ссылки;
  • временные ссылки с AWSAccessKeyId, Signature, token, Expires;
  • .env;
  • cookies;
  • логи с IP, UUID, email, user IDs, tokens;
  • любые рабочие конфиги, которые можно импортировать и использовать без изменений.

Для замены лучше использовать понятные placeholders:

<REDACTED_UUID>
<REDACTED_PRIVATE_KEY>
<REDACTED_PUBLIC_KEY>
<REDACTED_SHORT_ID>
<REDACTED_SERVER_IP>
<REDACTED_DOMAIN>
<REDACTED_SUBSCRIPTION_URL>
<REDACTED_PANEL_PASSWORD>
<EXAMPLE_XRAY_VERSION>
<EXAMPLE_CLIENT_VERSION>

Отдельно нужно проверить markdown, JSON, YAML, Python-файлы, комментарии, команды, названия файлов, архивные metadata и git history, если скилл публикуется как репозиторий.

Для статьи можно добавить такую формулировку:

> Все приложенные файлы являются sanitized-версией скилл-системы. Из них удалены реальные ключи, UUID, IP-адреса, домены, subscription URLs, токены, presigned links и любые данные, позволяющие восстановить рабочую инфраструктуру.

Что получилось в итоге

В результате получился не "VPN-бот", а маленькая инженерная система вокруг LLM.

Senior Xray VPN Architect умеет:

  • проектировать топологии;
  • ревьюить JSON-конфиги;
  • диагностировать проблемы;
  • планировать миграции;
  • объяснять концепции;
  • учитывать client-side split tunneling;
  • генерировать client JSON, если клиент поддерживает такой формат;
  • разделять client routing, gateway routing и server routing;
  • проверять DNS/routing логику;
  • учитывать client compatibility;
  • давать monitoring и fallback;
  • использовать первоисточники для свежих вопросов;
  • не делать абсолютных обещаний.

Главный вывод для меня такой: хороший AI-скилл - это не длинный промпт. Это система из роли, safety-границ, режимов работы, базы знаний, шаблонов, проверок, линтера и правил актуализации.

Именно такая структура помогает LLM перестать быть генератором уверенных советов и стать полезным техническим помощником, который мыслит не лозунгами, а архитектурными trade-offs.