Деньги на ИИ-системе

Это не ещё один случайный VPN. Задача - получить один стабильный IP, которым пользуешься только ты, и не смешивать страну карты, аккаунта и сетевого выхода.

Важно: соблюдай правила сервисов, которыми пользуешься. Не публикуй IP, UUID, Reality keys, short_id, JSON-профиль, QR, URI, токены, полные логи и домашние пути. Этот файл - про личную инфраструктуру и безопасную настройку, а не про доступ к чужим аккаунтам или приватным системам.

Когда что понадобится

Этап	Что подготовить	Зачем
Перед выбором страны	Страна карты, валюта карты, страна аккаунта, почта, возможный номер телефона	Чтобы IP, платёж и аккаунт не выглядели как случайная смесь стран
Перед покупкой VPS	Страна и город VPS, публичный IPv4, тариф, скорость, способ оплаты, ссылка на панель хостинга	Чтобы сразу купить сервер в нужной стране и не переделывать
Перед настройкой сервера	SSH-доступ, Ubuntu 24.04 LTS, имя sudo-пользователя, firewall провайдера	Чтобы не потерять доступ и не сломать рабочую конфигурацию
Перед генерацией профиля	Версия sing-box, версия клиента подключения, безопасное имя профиля, путь для JSON	Чтобы профиль импортировался без несовместимых полей
Перед проверкой	IP до включения, IP после включения, DNS-проверка, скорость, журнал клиента	Чтобы доказать, что маршрут работает end-to-end

Что понадобится

• Компьютер с доступом к терминалу: macOS, Windows или Linux.
• Аккаунт у VPS-провайдера в нужной стране.
• Способ оплаты VPS.
• Публичный IPv4 у сервера.
• Ubuntu 24.04 LTS на VPS.
• SSH-ключ для входа без пароля.
• sing-box на VPS.
• Клиент подключения на устройстве: SFM для macOS или другой sing-box-совместимый клиент для Windows/Linux.
• Reality handshake host: публичный hostname, который открывается с VPS по TCP/443, например сайт крупного публичного сервиса.

Главная логика

Тебе нужно привести в порядок три вещи:

• страна банковской карты;
• страна сетевого выхода;
• страна и поведение аккаунта.

Если карта одной страны, IP другой, номер третьей, а почта выглядит как случайный одноразовый аккаунт, риск блокировки растёт. Свой VPS не даёт магической гарантии, но убирает главную проблему публичных VPN: общий IP, на котором сидят сотни людей.

По публичному отчёту Anthropic за январь-июнь 2026 было заблокировано 11,4 млн аккаунтов, подано 398 тыс. апелляций и отменено 42 тыс. блокировок. Поэтому лучше заранее настроить инфраструктуру аккуратно, чем потом надеяться на апелляцию.

Целевая архитектура

Claude Code / Codex / браузер / локальные приложения
↓
локальный клиент подключения с TUN
↓
VLESS + Reality по TCP/443
↓
sing-box на VPS
↓
интернет

Жёсткий инвариант:

• Claude Code не ставится на VPS.
• Codex не ставится на VPS.
• Node.js, браузер, Git-проекты и файлы авторизации не копируются на VPS.
• На VPS работает только sing-box и необходимые системные компоненты.
• Код, проекты, токены, SSH-ключи и авторизация остаются локально.

1. Выбери страну под карту

Сначала реши, чем ты будешь платить за подписки и зарубежные сервисы.

Практическое правило:

• если карта Казахстана - VPS лучше брать в Казахстане;
• если карта Армении - ищи VPS в Армении или максимально близкую рабочую схему;
• если карта Грузии - проверь, есть ли нормальные VPS-провайдеры и скорость;
• если карта Гонконга, Сингапура или Испании - VPS подбирай под эту страну или близкий понятный маршрут;
• если есть только российская карта - сначала найди VPS, который можно оплатить, но не путай оплату VPS с оплатой подписки.

Не выбирай страну “на глаз”. Агент сам не поймёт, какая страна нужна, если ты не скажешь ему страну карты и фактическую страну использования.

2. Не начинай с публичного VPN

Публичный VPN часто даёт общий IP, которым пользуются десятки или сотни людей. Для обычного браузинга этого может хватать, но для платных AI-сервисов это слабое место.

Свой VPS лучше тем, что:

• IP закреплён за твоим сервером;
• маршрут не меняется сам по себе;
• можно выбрать страну под карту;
• можно проверить провайдера, город, DNS и скорость;
• можно одной кнопкой включать и выключать маршрут.

3. Подбери VPS-провайдера

Перед покупкой проверь:

• страна и город сервера совпадают с твоей задачей;
• есть публичный IPv4 без CGNAT;
• доступен входящий TCP/443;
• правила провайдера разрешают tunneling/sing-box;
• есть root-доступ и Ubuntu 24.04;
• есть web-console или rescue mode;
• можно заменить IP или переустановить сервер;
• можно оплатить выбранным способом;
• тариф подходит по скорости и лимиту трафика;
• есть status page, SLA или свежие независимые отзывы.

Для одного персонального endpoint ищи минимальный разумный тариф. Мощный сервер не нужен. По скорости 10-20 Мбит/с обычно достаточно для Claude, Codex, браузера и обычной работы. Если через endpoint будет работать несколько человек или тяжёлый трафик, бери тариф быстрее.

Не полагайся только на “локацию дата-центра” у российского провайдера. Иногда сервер физически находится в нужной стране, но провайдер, платёжные признаки или сеть всё равно выглядят не так, как нужно. Для чувствительных подписок лучше выбирать провайдера и оплату в той же логике страны.

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

Ты - независимый исследователь VPS-хостингов. Найди и сравни пять VPS у пяти разных провайдеров в нужной мне стране.

МОИ ДАННЫЕ
- Нужная страна VPS: [СТРАНА]
- Предпочтительный город: [ГОРОД ИЛИ “НЕВАЖНО”]
- Фактическая страна использования: [СТРАНА]
- Страна выпуска карты: [СТРАНА]
- Платёжная система: [VISA / MASTERCARD / МИР / ДРУГАЯ]
- Валюта карты: [RUB / USD / EUR / ДРУГАЯ]
- Международные платежи: [ДА / НЕТ / НЕИЗВЕСТНО]
- Альтернативная оплата: [СБП / PAYPAL / КРИПТОВАЛЮТА / НЕТ]
- Максимальный бюджет: [СУММА В МЕСЯЦ]
- Количество устройств: [ЧИСЛО]

КОНТЕКСТ
VPS нужен только как сетевой endpoint:
локальное устройство -> клиент подключения с TUN -> VLESS + Reality -> sing-box на VPS -> интернет.
Claude Code, Codex и проекты остаются локально. На сервере будет только sing-box.

ЗАДАЧА
1. Найди пять реально доступных предложений у разных провайдеров.
2. Ищи как российских провайдеров с дата-центром в нужной стране, так и иностранных.
3. Не добавляй вариант, если фактическую локацию сервера подтвердить нельзя.
4. Используй актуальные данные и указывай дату проверки.

Для каждого варианта проверь:
- реальный дата-центр в нужной стране;
- возможность оплаты моей картой или альтернативным способом;
- итоговую цену с публичным IPv4 и обязательными доплатами;
- отдельный публичный IPv4 без CGNAT;
- root-доступ и Ubuntu 24.04;
- доступность входящего TCP/443;
- разрешён ли tunneling/sing-box правилами провайдера;
- vCPU, RAM, диск, скорость и лимит трафика;
- наличие firewall, web-console или rescue mode;
- возможность заменить IP или переустановить сервер;
- стабильность: status page, SLA и свежие отзывы.

ИСТОЧНИКИ
Используй официальные страницы тарифов, оплаты, документацию, AUP/ToS, status page и свежие независимые отзывы. Для ключевых фактов дай прямые ссылки. Если оплату, локацию или другое условие нельзя подтвердить, ставь UNKNOWN. Ничего не покупай, не регистрируй аккаунты и не проводи списания.

ФОРМАТ РЕЗУЛЬТАТА
Составь таблицу:
| Место | Провайдер | Тариф и ссылка | Страна/город | Характеристики | Цена | Оплата моей картой | IPv4 | TCP/443 и sing-box | Console/rescue | Стабильность | Риск | Вердикт |

Вердикты:
- GO - все обязательные условия подтверждены;
- CONDITIONAL GO - есть некритичные UNKNOWN;
- NO-GO - нет публичного IPv4, TCP/443, root-доступа, нужной локации или правила запрещают tunneling.

После таблицы укажи:
1. Какой VPS выбрать первым.
2. Почему он победил.
3. Какой вариант оставить запасным.
4. Что проверить непосредственно перед оплатой.

В конце заполни:
VPS_HOSTING_NAME=
VPS_ORDER_URL=
VPS_PLAN_NAME=
VPS_COUNTRY=
VPS_CITY=
VPS_PRICE=
VPS_PAYMENT_METHOD=
VPS_PAYMENT_CONFIDENCE=CONFIRMED / UNKNOWN
VPS_PUBLIC_IPV4=ЗАПОЛНИТЬ ПОСЛЕ ПОКУПКИ
VPS_INITIAL_SSH_USER=
VPS_SSH_PORT=22
VPS_PROVIDER_FIREWALL=
VPS_CONSOLE_OR_RESCUE=
VPS_OS=Ubuntu 24.04 LTS
VPS_IP_REPLACEMENT_POLICY=
MAIN_RISK=
BACKUP_PROVIDER=

Не запрашивай реквизиты карты, пароли, SMS-коды или документы. Не обещай отсутствие блокировок и не предлагай чужие карты, купленные аккаунты или вымышленные данные.

4. Заполни входные данные для настройки

После выбора VPS собери данные в одну заметку.

VPS_HOSTING_NAME=[название хостинга]
VPS_PANEL_URL=[ссылка на панель или документацию]
VPS_PLAN_NAME=[название тарифа]
VPS_COUNTRY=[страна]
VPS_CITY=[город]
VPS_PUBLIC_IPV4=[публичный IPv4]
VPS_OS=[Ubuntu 24.04 LTS]
VPS_INITIAL_SSH_USER=[root или другой первичный пользователь]
VPS_ADMIN_USER=[имя нового sudo-пользователя]
VPS_SSH_PORT=[22]
LOCAL_SSH_PRIVATE_KEY_PATH=[только локальный путь к ключу, без содержимого]
VPS_PROVIDER_FIREWALL=[включён / выключен / неизвестно]
LOCAL_CLIENT_NAME=[SFM или другой sing-box-совместимый клиент]
LOCAL_CLIENT_VERSION=[например 1.13.14]
LOCAL_OS_VERSION=[версия системы]
REALITY_HANDSHAKE_HOST=[например www.microsoft.com]
LOCAL_PROFILE_OUTPUT_PATH=[например ~/Downloads/almaty-reality.json]
LOCAL_PROFILE_NAME=[безопасное имя профиля]

Критичные поля:

• VPS_PUBLIC_IPV4;
• VPS_COUNTRY;
• VPS_INITIAL_SSH_USER;
• VPS_ADMIN_USER;
• REALITY_HANDSHAKE_HOST;
• LOCAL_CLIENT_NAME;
• LOCAL_PROFILE_OUTPUT_PATH.

Если критичного поля нет, настройку не начинай.

5. Создай SSH-ключ

На своём компьютере открой терминал и выполни:

ssh-keygen -t ed25519

Покажи публичный ключ:

cat ~/.ssh/id_ed25519.pub

Скопируй строку, которая начинается так:

ssh-ed25519 AAAA...

Это публичный ключ. Приватный ключ без .pub никуда не отправляй и не вставляй в чат:

~/.ssh/id_ed25519

6. Создай VPS

В панели хостинга создай сервер.

Минимальный набор:

• Ubuntu 24.04 LTS;
• публичный IPv4;
• SSH-ключ вместо пароля;
• порт SSH по умолчанию 22, если нет причины менять;
• firewall провайдера понятен: включён, выключен или будет настроен вручную.

После создания сохрани:

VPS_PUBLIC_IPV4
VPS_INITIAL_SSH_USER
VPS_PANEL_URL

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

Ты - системный инженер. Настрой выбранный VPS как персональный сетевой endpoint для локального клиента подключения.

ЦЕЛЕВАЯ АРХИТЕКТУРА
локальные Claude Code и Codex -> клиент подключения с TUN -> VLESS + Reality по TCP/443 -> sing-box на VPS -> интернет.

ЖЁСТКИЙ ИНВАРИАНТ
Claude Code, Codex, Node.js, браузер, Git-проекты, VS Code Server и файлы авторизации на VPS не устанавливать и не копировать.
На сервере работает только sing-box и необходимые системные компоненты. Код и агенты остаются локально.

ВХОДНЫЕ ДАННЫЕ
VPS_HOSTING_NAME=[НАЗВАНИЕ_ХОСТИНГА]
VPS_PANEL_URL=[ССЫЛКА_НА_ПАНЕЛЬ_ИЛИ_ДОКУМЕНТАЦИЮ]
VPS_PLAN_NAME=[НАЗВАНИЕ_ТАРИФА]
VPS_COUNTRY=[СТРАНА]
VPS_CITY=[ГОРОД]
VPS_PUBLIC_IPV4=[ПУБЛИЧНЫЙ_IPV4]
VPS_OS=[UBUNTU_24_04_LTS]
VPS_INITIAL_SSH_USER=[ROOT_ИЛИ_ДРУГОЙ]
VPS_ADMIN_USER=[ИМЯ_НОВОГО_SUDO_ПОЛЬЗОВАТЕЛЯ]
VPS_SSH_PORT=[22]
LOCAL_SSH_PRIVATE_KEY_PATH=[ТОЛЬКО_ЛОКАЛЬНЫЙ_ПУТЬ_К_КЛЮЧУ, НЕ СОДЕРЖИМОЕ]
VPS_PROVIDER_FIREWALL=[ВКЛЮЧЁН / ВЫКЛЮЧЕН / НЕИЗВЕСТНО]
LOCAL_CLIENT_NAME=[SFM ИЛИ ДРУГОЙ SING-BOX-СОВМЕСТИМЫЙ КЛИЕНТ]
LOCAL_CLIENT_VERSION=[ВЕРСИЯ]
LOCAL_OS_VERSION=[ВЕРСИЯ_СИСТЕМЫ]
REALITY_HANDSHAKE_HOST=[НАПРИМЕР_www.microsoft.com]
LOCAL_PROFILE_OUTPUT_PATH=[НАПРИМЕР_~/Downloads/almaty-reality.json]
LOCAL_PROFILE_NAME=[БЕЗОПАСНОЕ_ИМЯ_ПРОФИЛЯ]

ПРАВИЛО РАБОТЫ
Сначала ничего не меняй.
Проверь входные данные и выведи подробный план с фазами, командами верхнего уровня, точками проверки, возможным откатом и ручными действиями в панели хостинга и клиенте подключения.
Если критическое поле отсутствует, перечисли только недостающие поля.
Если всё заполнено, попроси одно подтверждение: «НАЧИНАЕМ».
Только после подтверждения выполняй план по фазам.

ПЛАН, КОТОРЫЙ ТЫ ОБЯЗАН ПОКАЗАТЬ

1. PREFLIGHT
Проверить публичный IP, SSH-доступ, версию и архитектуру Ubuntu, свободен ли TCP/443, текущие правила firewall, нет ли на сервере чужой или действующей конфигурации, соответствует ли выбранная версия sing-box версии и возможностям клиента подключения.

2. SAFETY
Создать timestamped backup существующих конфигураций. Не перезаписывать неизвестный работающий сервер. Не удалять существующие файлы. Не закрывать исходную SSH-сессию до проверки нового входа. Для каждой мутации заранее указать способ отката.

3. SSH HARDENING
Создать отдельного sudo-пользователя. Добавить ему только публичный SSH-ключ. Проверить свежий вход во втором терминале. Перед изменением SSH выполнить sshd -t. Только после успешного второго входа отключать root/password login. После reload проверить ещё один новый вход.

4. УСТАНОВКА SING-BOX
Использовать только официальный репозиторий SagerNet. Установить sing-box и необходимые системные компоненты. Зафиксировать установленную версию. Не устанавливать Claude Code, Codex, Node.js, Git-проекты или браузер.

5. ПРОВЕРКА REALITY HANDSHAKE HOST
Проверить, что REALITY_HANDSHAKE_HOST открывается с VPS по TCP/443. Проверить корректность выбранного hostname. Не выпускать отдельный сертификат под собственный домен, если применяется Reality. Никогда не включать insecure=true.

6. ГЕНЕРАЦИЯ СЕКРЕТОВ
Сгенерировать UUID, Reality private/public keypair и short_id. Хранить значения в root-only файлах. Установить права 600. Не печатать секреты в чат, не выводить их в публичный лог, не помещать в shell history, не показывать на записи экрана, не передавать через URI или QR.

7. SERVER CONFIG
Создать конфигурацию sing-box со следующей логикой:
- inbound: VLESS;
- listen: 0.0.0.0;
- port: TCP/443;
- пользователь с UUID;
- flow: xtls-rprx-vision;
- TLS enabled;
- Reality enabled;
- Reality private_key хранится только на сервере;
- short_id совпадает с клиентским профилем;
- handshake server соответствует REALITY_HANDSHAKE_HOST;
- outbound: direct.

Перед запуском обязательно выполнить:
sing-box check -c /etc/sing-box/config.json

Если проверка не проходит - остановиться. Не запускать service с невалидным конфигом.

8. FIREWALL
Сначала убедиться, что OpenSSH разрешён. Затем разрешить TCP/443 в UFW. Если у провайдера есть отдельный firewall, остановиться и дать точные ручные действия в панели. После включения UFW проверить, что SSH-сессия и новый вход работают. Не менять SSH-порт без отдельной необходимости.

9. SERVICE
Включить и запустить sing-box. Проверить systemctl status, безопасные строки Journal и listener на TCP/443. Не считать active service или открытый TCP/443 доказательством end-to-end подключения.

10. CLIENT PROFILE
Создать локальный JSON-профиль клиента со следующей логикой:
- TUN inbound;
- auto_route=true;
- DNS направляется через туннель;
- private IP и локальная сеть идут через direct;
- final route идёт через VLESS outbound;
- server - публичный IPv4 VPS;
- server_port - 443;
- UUID совпадает с сервером;
- flow - xtls-rprx-vision;
- TLS enabled;
- server_name совпадает с REALITY_HANDSHAKE_HOST;
- uTLS fingerprint - chrome;
- Reality enabled;
- используется Reality public_key;
- short_id совпадает с сервером.

11. СОВМЕСТИМОСТЬ КЛИЕНТА
Профиль должен соответствовать установленной версии клиента. Для SFM 1.13.14:
- не добавлять dns_mode;
- не использовать Linux-only auto_redirect;
- не использовать insecure=true;
- не добавлять strict_route без отдельной доказанной необходимости;
- не использовать Linux/Android-only поля.

Перед импортом проверить клиентский JSON совместимой версией sing-box.

12. СОХРАНЕНИЕ И ИМПОРТ
Сохранить профиль локально по адресу LOCAL_PROFILE_OUTPUT_PATH. Установить права 600. Не публиковать профиль. Не коммитить его в Git. Не вставлять его содержимое в чат. Не создавать QR или URI. Не показывать содержимое JSON в публичной записи.

Дать точный UI-маршрут в SFM:
Панель -> + -> Import from File -> выбрать JSON -> Type Local -> Create -> Stop старого профиля -> выбрать новый профиль -> Play.
Не включать Always On до полного тестирования.

13. HANDOFF
Выдать sanitized-отчёт:
1. Итоговый статус: READY_FOR_TEST / BLOCKED.
2. Что установлено на VPS.
3. Что сознательно осталось локально.
4. Версии sing-box и клиента.
5. Результат sing-box check.
6. Состояние service и listener.
7. Путь к локальному профилю без показа содержимого.
8. Какие ручные действия остались в клиенте или панели хостинга.
9. Rollback по шагам.
10. Заполненные безопасные поля для промпта тестирования.

ПРАВИЛА ИСПОЛНЕНИЯ
- Перед каждой фазой напиши, что будет изменено и как это откатить.
- После каждой фазы покажи PASS / FAIL и короткое доказательство без секретов.
- При FAIL остановись.
- Не меняй несколько параметров одновременно.
- Не отключай TLS-проверку.
- Не закрывай исходную SSH-сессию, пока новый пользователь и новый вход не проверены.
- Не включай Always On до полного end-to-end теста и проверки Stop.
- Не публикуй IP, UUID, Reality keys, short_id, profile JSON, QR, URI, токены, полные логи или домашние пути.
- Для записи экрана сформируй отдельный sanitized-отчёт, где чувствительные значения замаскированы.

7. Preflight перед изменениями

Перед настройкой сервер не трогаем. Сначала проверяем состояние.

На своём компьютере:

ssh root@VPS_PUBLIC_IPV4

На VPS:

uname -a
lsb_release -a
sudo ss -ltnp
sudo ufw status verbose

Проверить:

• публичный IP совпадает с купленным VPS;
• SSH-доступ работает;
• версия и архитектура Ubuntu понятны;
• TCP/443 свободен;
• текущие правила firewall понятны;
• на сервере нет чужой действующей конфигурации;
• выбранная версия sing-box совместима с клиентом подключения.

8. Safety перед настройкой

Перед каждой мутацией зафиксируй, как откатиться.

• Создать backup существующих конфигов с timestamp.
• Не перезаписывать неизвестный работающий сервер.
• Не удалять существующие файлы.
• Не закрывать исходную SSH-сессию, пока новый вход не проверен.
• Не менять несколько параметров одновременно.
• После каждой фазы показывать PASS / FAIL и короткое доказательство без секретов.
• При FAIL остановиться, а не продолжать поверх ошибки.

9. Создай отдельного sudo-пользователя

На VPS:

adduser proxyuser
usermod -aG sudo proxyuser
mkdir -p /home/proxyuser/.ssh
cp /root/.ssh/authorized_keys /home/proxyuser/.ssh/authorized_keys
chown -R proxyuser:proxyuser /home/proxyuser/.ssh
chmod 700 /home/proxyuser/.ssh
chmod 600 /home/proxyuser/.ssh/authorized_keys

Проверь вход во втором терминале:

ssh proxyuser@VPS_PUBLIC_IPV4
sudo whoami

Ожидаемый результат:

root

Только после этого можно усиливать SSH.

10. Защити SSH

На VPS:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Вставь:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Проверь синтаксис:

sudo sshd -t

Если ошибок нет:

sudo systemctl reload ssh

В новом терминале проверь свежий вход:

ssh proxyuser@VPS_PUBLIC_IPV4

Старую root-сессию закрывай только после успешной проверки нового входа.

11. Настрой firewall

Для схемы VLESS + Reality нужен TCP/443.

На VPS:

sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

В панели провайдера, если есть отдельный firewall, тоже разреши:

Порт	Протокол	Зачем
22	TCP	SSH
443	TCP	VLESS + Reality

Не открывай лишние порты без причины. После включения UFW проверь, что текущая SSH-сессия жива и новый вход работает.

12. Установи sing-box

Используй официальный репозиторий SagerNet.

sudo mkdir -p /etc/apt/keyrings
sudo curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc
sudo chmod a+r /etc/apt/keyrings/sagernet.asc

Создай файл репозитория:

sudo nano /etc/apt/sources.list.d/sagernet.sources

Вставь:

Types: deb
URIs: https://deb.sagernet.org/
Suites: *
Components: *
Enabled: yes
Signed-By: /etc/apt/keyrings/sagernet.asc

Установи:

sudo apt-get update
sudo apt-get install -y sing-box jq
sing-box version

Версию сохрани в отчёт. На VPS не ставь Claude Code, Codex, Node.js, браузер, Git-проекты и файлы авторизации.

13. Проверь Reality handshake host

Reality в этой схеме не требует собственного домена и отдельного сертификата. Нужен корректный handshake host.

Проверь, что hostname открывается с VPS по TCP/443:

curl -I https://REALITY_HANDSHAKE_HOST

Пример:

curl -I https://www.microsoft.com

Правила:

• hostname должен быть корректным и доступным с VPS;
• server_name клиента должен совпадать с выбранным hostname;
• handshake.server на сервере должен соответствовать тому же hostname;
• не используй собственный домен и отдельный сертификат, если работаешь по Reality;
• никогда не включай insecure: true как способ “починить” TLS.

14. Сгенерируй секреты

На VPS сгенерируй UUID:

sing-box generate uuid

Сгенерируй Reality keypair:

sing-box generate reality-keypair

Сгенерируй short_id:

openssl rand -hex 4

Сохрани значения в root-only файлы:

sudo install -d -m 700 /root/reality-setup
sudo nano /root/reality-setup/secrets.env
sudo chmod 600 /root/reality-setup/secrets.env

Требования:

• UUID совпадает на сервере и в клиентском профиле;
• Reality private key хранится только на сервере;
• Reality public key попадает в клиентский профиль;
• short_id совпадает на сервере и клиенте;
• секреты не печатаются в чат;
• секреты не попадают в публичный лог, Git, QR или URI.

15. Создай серверный конфиг

Серверная логика:

• inbound: VLESS;
• listen: 0.0.0.0;
• port: TCP/443;
• пользователь с UUID;
• flow: xtls-rprx-vision;
• TLS enabled;
• Reality enabled;
• Reality private key только на сервере;
• short_id совпадает с клиентским профилем;
• handshake server соответствует REALITY_HANDSHAKE_HOST;
• outbound: direct.

Примерная структура:

{
  "log": { "level": "info", "timestamp": true },
  "inbounds": [
    {
      "type": "vless",
      "tag": "vless-in",
      "listen": "0.0.0.0",
      "listen_port": 443,
      "users": [
        {
          "uuid": "__UUID__",
          "flow": "xtls-rprx-vision"
        }
      ],
      "tls": {
        "enabled": true,
        "server_name": "__REALITY_HANDSHAKE_HOST__",
        "reality": {
          "enabled": true,
          "handshake": {
            "server": "__REALITY_HANDSHAKE_HOST__",
            "server_port": 443
          },
          "private_key": "__REALITY_PRIVATE_KEY__",
          "short_id": ["__SHORT_ID__"]
        }
      }
    }
  ],
  "outbounds": [
    { "type": "direct", "tag": "direct" }
  ]
}

Перед запуском:

sudo sing-box check -c /etc/sing-box/config.json

Если проверка не проходит - остановись. Не запускай service с невалидным конфигом.

16. Запусти service

После успешного sing-box check:

sudo systemctl enable --now sing-box
sudo systemctl status sing-box --no-pager
sudo journalctl -u sing-box --output cat -e
sudo ss -ltnp | grep ':443'

PASS:

• service active;
• listener на TCP/443 есть;
• в журнале нет критических ошибок;
• sing-box check проходит.

Не считай это полной проверкой подключения. Это только проверка сервера.

17. Создай клиентский профиль

Клиентская логика:

• TUN inbound;
• auto_route: true;
• DNS идёт через tunnel;
• private IP и локальная сеть идут через direct;
• final route идёт через VLESS outbound;
• server - публичный IPv4 VPS;
• server_port - 443;
• UUID совпадает с сервером;
• flow - xtls-rprx-vision;
• TLS enabled;
• server_name совпадает с REALITY_HANDSHAKE_HOST;
• uTLS fingerprint - chrome, если клиент это поддерживает;
• Reality enabled;
• используется Reality public key;
• short_id совпадает с сервером.

Не добавляй поля, которые не поддерживает установленная версия клиента. Для SFM 1.13.14:

• не добавляй dns_mode;
• не используй Linux-only auto_redirect;
• не используй insecure: true;
• не добавляй strict_route без доказанной необходимости;
• не используй Linux/Android-only поля.

Перед импортом проверь клиентский JSON совместимой версией sing-box.

18. Сохрани профиль безопасно

Сохрани клиентский профиль локально по адресу из LOCAL_PROFILE_OUTPUT_PATH.

Правила:

• права на файл - 600;
• не публиковать профиль;
• не коммитить его в Git;
• не вставлять содержимое профиля в чат;
• не создавать QR или URI;
• не показывать JSON в публичной записи экрана;
• после импорта удалить временные копии.

Файл профиля - это ключ от твоего сервера.

19. Импортируй профиль в клиент

Для SFM:

Панель -> + -> Import from File -> выбрать JSON -> Type Local -> Create

После импорта:

• Stop старого профиля;
• выбрать новый профиль;
• нажать Play;
• не включать Always On до полного тестирования;
• если система просит Network Extension, разрешить.

Для Windows/Linux логика та же: импортировать локальный sing-box JSON в совместимый клиент и включить профиль только после проверки.

Этот промпт используется после настройки. Он read-only: не исправляет конфиги, не перезапускает службы и не меняет firewall без отдельного разрешения.

Ты - независимый проверяющий. Проведи read-only тест готовой схемы:
локальные Claude Code и Codex -> клиент подключения с TUN -> VLESS + Reality -> sing-box на VPS -> интернет.

Это диагностический прогон.
Не исправляй конфигурацию, не обновляй пакеты, не перезапускай службы и не меняй firewall без отдельного разрешения.
Сначала собери доказательства, затем поставь вердикт.

ВХОДНЫЕ ДАННЫЕ
VPS_HOSTING_NAME=[НАЗВАНИЕ_ХОСТИНГА]
VPS_PLAN_NAME=[НАЗВАНИЕ_ТАРИФА]
VPS_COUNTRY=[ОЖИДАЕМАЯ_СТРАНА]
VPS_CITY=[ОЖИДАЕМЫЙ_ГОРОД]
VPS_PUBLIC_IPV4=[ПУБЛИЧНЫЙ_IPV4]
VPS_SSH_USER=[SUDO_ПОЛЬЗОВАТЕЛЬ]
VPS_SSH_PORT=[22]
LOCAL_SSH_PRIVATE_KEY_PATH=[ЛОКАЛЬНЫЙ_ПУТЬ, НЕ СОДЕРЖИМОЕ]
SFM_APP_VERSION=[ВЕРСИЯ]
SFM_PROFILE_NAME=[ИМЯ_ПРОФИЛЯ]
LOCAL_DEMO_PROJECT_PATH=[БЕЗОПАСНАЯ_DEMO_ПАПКА]
TEST_NETWORK_1=[ДОМАШНИЙ_WIFI]
TEST_NETWORK_2=[МОБИЛЬНЫЙ_HOTSPOT_ИЛИ_НЕТ]

ПРАВИЛА РАБОТЫ С СЕКРЕТАМИ
Не проси и не печатай:
- UUID;
- Reality private/public keys;
- short_id;
- содержимое profile JSON;
- QR или URI;
- токены Claude/Codex;
- файлы авторизации;
- полные логи.

Реальный IP можно использовать для машинного сравнения, но в итоговом отчёте и публичных командах его необходимо замаскировать.

ТЕСТ-ПЛАН

1. BASELINE НА ЛОКАЛЬНОМ УСТРОЙСТВЕ ПРИ STOP В КЛИЕНТЕ
Зафиксировать:
- внешний IP;
- страну;
- работоспособность обычного HTTPS;
- работоспособность DNS;
- локальный pwd;
- локальный Git root;
- локальный путь команды claude;
- локальный путь команды codex.

Полный IP в отчёте не показывать.

2. STATIC CHECKS НА VPS
По SSH проверить:
- установленную версию sing-box;
- результат sing-box check для активного server config;
- systemctl is-active sing-box;
- последние безопасные строки Journal;
- listener на TCP/443;
- правила UFW для OpenSSH и TCP/443;
- отсутствие Claude Code, Codex, Node.js и project directories на VPS.

Ничего не перезапускать и не исправлять.

3. CLIENT START GATE
Попросить пользователя вручную:
1. Открыть SFM.
2. Нажать Stop, если активен другой профиль.
3. Выбрать нужный Local profile.
4. Нажать Play.

После этого проверить:
- запустился ли Network Extension;
- появился ли utun-интерфейс;
- нет ли в Journal SFM ошибок fatal;
- нет ли parse error;
- нет ли authentication error;
- нет ли Reality/TLS error;
- какой профиль фактически выбран.

Показывать только безопасные строки журнала.

4. END-TO-END ROUTE
Проверить:
- внешний IP после Play совпадает с VPS_PUBLIC_IPV4;
- страна соответствует VPS_COUNTRY;
- обычный HTTPS-сайт открывается;
- DNS работает;
- маршрут до публичного адреса идёт через utun-интерфейс клиента;
- локальная сеть продолжает работать;
- private IP не отправляются через VPS.

Открытый TCP/443 и active service не считать достаточным доказательством.

5. ПРОВЕРКИ В БРАУЗЕРЕ
Дай пользователю ручной чек-лист для:
- browserleaks.com/dns;
- browserleaks.com/webrtc.

Проверить:
- нет ли неожиданного DNS-маршрута;
- не показывается ли нежелательный публичный адрес;
- совпадает ли наблюдаемая страна с VPS_COUNTRY.

Не объявлять эти пункты PASS, пока пользователь не подтвердил результат.
Не публиковать полный IP или список DNS-серверов.

6. ПРОВЕРКА ЛОКАЛЬНЫХ АГЕНТОВ
В LOCAL_DEMO_PROJECT_PATH:
- показать локальный pwd;
- показать локальный Git root;
- подтвердить локальный путь команды claude;
- подтвердить локальный путь команды codex;
- запустить Claude Code;
- дать Claude Code read-only задачу прочитать demo README;
- запустить Codex;
- дать Codex такую же read-only задачу;
- подтвердить, что оба агента читают локальные файлы;
- подтвердить, что на VPS нет проекта и агентов.

Не выполнять повторный login.
Не показывать auth-файлы, токены, реальные проекты или клиентские данные.

7. STOP И ПРОВЕРКА ОТКАТА
Попросить пользователя нажать Stop в SFM.
После Stop проверить:
- внешний IP вернулся к baseline;
- обычный маршрут восстановлен;
- DNS работает;
- локальная сеть работает;
- интернет продолжает работать;
- Claude Code и Codex остаются установленными и локальными.

8. ВТОРАЯ СЕТЬ
Повторить ключевые проверки через TEST_NETWORK_2:
- запуск SFM;
- внешний IP;
- страна;
- DNS;
- HTTPS;
- Stop.

Если вторая сеть недоступна, поставить MANUAL_PENDING, а не PASS.

ФОРМАТ ОТЧЁТА

1. ОБЩИЙ ВЕРДИКТ
GREEN - сервер, клиент, end-to-end маршрут, DNS, локальные агенты и Stop доказаны.
YELLOW - основная схема работает, но остались ручные или сетевые проверки.
RED - профиль не стартует, IP не совпадает, DNS не работает, есть ошибки Reality/TLS/authentication либо Stop не восстанавливает маршрут.

2. ТАБЛИЦА ПРОВЕРОК
Колонки:
| Тест | Ожидаемый результат | Фактический результат | PASS / FAIL / MANUAL_PENDING | Безопасное доказательство |

3. ПЕРВАЯ ТОЧКА ОТКАЗА
Назови только самую раннюю подтверждённую проблему. Не перечисляй десять возможных причин без доказательств.

4. СЛЕДУЮЩЕЕ ОДНО ДЕЙСТВИЕ
Дай один минимальный следующий шаг для диагностики. Ничего автоматически не исправляй.

5. ЧТО МОЖНО ПОКАЗАТЬ В ПУБЛИЧНОЙ ЗАПИСИ
Составь список sanitized-доказательств:
- версия sing-box;
- sing-box check PASS;
- active service;
- замаскированный listener TCP/443;
- страна до и после;
- безопасная строка SFM Journal;
- локальный pwd в demo-папке;
- локальные пути claude и codex;
- успешная read-only задача;
- возврат маршрута после Stop.

6. ЧТО ОБЯЗАТЕЛЬНО СКРЫТЬ
- полный IP;
- UUID;
- private/public Reality keys;
- short_id;
- server config;
- profile JSON;
- QR;
- URI;
- токены;
- auth-файлы;
- полные логи;
- реальные домашние пути;
- названия клиентских проектов.

КРИТЕРИЙ GREEN
Наличие active service или открытого TCP/443 недостаточно.
GREEN возможен только после:
1. живого подключения SFM;
2. совпадения внешнего IP с VPS;
3. рабочего DNS и HTTPS;
4. локального запуска Claude Code и Codex;
5. доказательства, что проект остаётся на локальном устройстве;
6. успешного возврата маршрута после Stop.

20. Проверь IP до и после

До включения профиля:

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep '^ip='

Сохрани исходный IP.

После Play:

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep '^ip='

PASS:

• IP изменился;
• новый IP совпадает с публичным IPv4 VPS;
• страна и город соответствуют выбранной задаче;
• провайдер выглядит ожидаемо.

Дополнительно проверь DNS и WebRTC в браузере:

• browserleaks.com/dns;
• browserleaks.com/webrtc.

Полный IP и список DNS-серверов не публикуй.

21. Проверь DNS, интернет и скорость

При включённом профиле:

curl -I https://example.com

Проверь:

• сайты открываются;
• DNS работает;
• скорость достаточна для работы;
• в журнале клиента нет fatal, authentication failed, TLS mismatch;
• Claude, Codex, браузер и локальные инструменты используют новый маршрут.

Скорость 10-20 Мбит/с обычно достаточна для одиночной работы с AI-сервисами, браузером и обычными задачами.

22. Проверь локальных агентов

В безопасной demo-папке проверь:

• локальный pwd;
• локальный Git root;
• локальный путь команды claude;
• локальный путь команды codex;
• Claude Code запускается локально;
• Codex запускается локально;
• оба агента читают локальные demo-файлы;
• на VPS нет проекта, Claude Code, Codex, Node.js и файлов авторизации.

Не выполняй повторный login. Не показывай auth-файлы, токены, реальные проекты или клиентские данные.

23. Проверь Stop

В клиенте нажми Stop.

Снова проверь IP:

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep '^ip='

PASS:

• вернулся исходный IP;
• обычный маршрут восстановлен;
• DNS работает;
• локальная сеть работает;
• интернет продолжает работать;
• понятно, как быстро откатиться.

Не включай Always On, пока не проверены Play, Stop, DNS и внешний IP.

24. Проверь вторую сеть

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

• запуск клиента;
• внешний IP;
• страна;
• DNS;
• HTTPS;
• Stop.

Если второй сети нет, ставь MANUAL_PENDING, а не PASS.

25. Удали временные копии

После успешного импорта:

• удали временный JSON из Downloads или Desktop;
• удали переданную копию с VPS, если она там создавалась;
• оставь секреты только в root-only файлах;
• не храни профиль в папке проекта;
• не отправляй профиль в мессенджеры.

Если что-то не работает

Проблема	Что проверить
Клиент не запускает профиль	Журнал клиента, совместимость версии sing-box, лишние поля в JSON
Сервер active, но соединения нет	sing-box check, systemctl status, listener на TCP/443, firewall VPS и firewall провайдера
IP не изменился	Выбран ли новый профиль, нажата ли Play, есть ли auto_route: true, уходит ли final route в VLESS outbound
DNS перестал работать	Настройки DNS в клиентском JSON, detour через tunnel, правило DNS hijack, отсутствие несовместимых полей
authentication failed	UUID на сервере и клиенте, short_id, public/private key pair, не был ли пересоздан только один профиль
TLS mismatch	REALITY_HANDSHAKE_HOST, server_name, Reality public key, short_id, handshake server
Проверка 443 не проходит	Проверяй именно TCP/443, правила UFW, firewall провайдера и listener sing-box
Клиент ругается на поле	Убери поле, которое не поддерживает версия клиента, и снова проверь JSON

Не лечи TLS-ошибку через insecure: true. Это маскирует проблему, а не исправляет схему.

Что в итоге должно получиться

На VPS:

• Ubuntu;
• sing-box;
• VLESS + Reality inbound;
• root-only секреты;
• минимальные firewall-правила.

На твоём устройстве:

• Claude Code, Codex, браузер и проекты;
• локальный клиент подключения;
• импортированный профиль;
• возможность включить Play и выключить Stop.

Главная проверка простая: после Play внешний IP становится IP твоего VPS, DNS и интернет работают, а после Stop возвращается обычное подключение.

Источники для сверки

• Anthropic Transparency Hub
• sing-box TLS / Reality fields
• sing-box VLESS outbound
• sing-box for Apple platforms / SFM

Claude с нуля за 1 час

Улучшатель промтов