Разработчик вынес авторизацию Claude Code на VDS, оставив проекты на Mac

В октябре у многих пользователей Claude из России и соседних стран снова посыпались аккаунты. У автора разбора на Habr Max-подписка слетела за день до списания денег, а поддержка, как он справедливо предположил, ничего бы не решила. Он купил новую подписку и собрал конфигурацию, в которой проекты лежат на его Mac, а авторизация Anthropic и сетевой выход находятся на Linux-сервере. Это личный эксперимент, и сам автор подчёркивает, что универсальной инструкцией его считать нельзя.

Почему не хватило Remote SSH и простого прокси

Первая идея была самой очевидной: поставить на VDS Claude Code и подключаться через VS Code Remote SSH. Это работает, но проекты с Mac на сервере сами не появляются. Клонировать репозитории и настраивать синхронизацию можно, но часть файлов автор не хотел держать на чужой машине. Требование получилось такое: Claude Code читает и меняет файлы на Mac, запросы к модели выходят через Linux, а авторизация остаётся на Linux.

Вторая идея — HTTP-прокси на сервере — тоже не сработала. Прокси меняет маршрут трафика, но не передаёт клиенту на Mac чужую авторизацию. Поэтому понадобились два разных компонента. CLIProxyAPI — шлюз, который принимает запрос локального Claude Code и обращается к Anthropic с серверными кредами. Tinyproxy пересылает остальной трафик клиента: веб-поиск, MCP и другие обращения, которые иначе пошли бы с домашнего адреса.

Как устроена связка

На Mac в settings.json прописаны ANTHROPIC_BASE_URL на локальный порт, HTTP_PROXY и HTTPS_PROXY на второй порт, а ключ шлюза отдаёт apiKeyHelper. Оба порта пробрасываются одним SSH-туннелем до сервера, где шлюз и прокси слушают только 127.0.0.1. Туннель поднимает и перезапускает LaunchAgent. Сама модель, разумеется, считает ответ в облаке Anthropic. На сервере остаются шлюз, токен и сетевой выход, а на Mac — файлы, агент и выполнение локальных инструментов. К модели уходят только фрагменты файлов, выбранные агентом, и результаты локальных команд.

Проверок автор сделал много, потому что ловушки попадались на каждом шаге. Он сверил внешний IP через прокси, проверил бинарник расширения VS Code и убедился, что файловые операции выполняются на Mac. Отдельно запустил клиент при недоступных шлюзе и прокси: ответ в обход не пришёл, только ошибка соединения.

Где всё ломалось

Первая проблема — systemd. Импорт авторизации в ExecStartPre не видел нужную переменную окружения, и служба падала до старта шлюза. Автор выполнил импорт отдельно, а служба стала читать готовый auth-файл. Обновлять токен приходится вручную.

Вторая — NO_PROXY. Без исключения для loopback запрос к локальному шлюзу сначала уходил в Tinyproxy, и ничего не работало.

Третья и самая поучительная — каталог моделей. Клиент обратился к вспомогательной модели claude-haiku-5-5, которой не было в каталоге CLIProxyAPI 8.0.20, и получил ошибку unknown provider for model. Решение — дополнить каталог записью о модели. Автор делает вывод, что версии клиента и шлюза нужно фиксировать и обновлять осознанно.

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

Что из этого взять и о чём помнить

Паттерн полезен и вне контекста блокировок. Если нужно держать креды и сетевой выход на одной машине, а файлы и инструменты на другой, схема «локальный агент, шлюз за SSH-туннелем, отдельный прокси» работает. Заодно она показывает, что API-шлюз и сетевой прокси решают разные задачи и не заменяют друг друга.

Но у подхода есть серьёзные оговорки. Сам автор признаёт, что наличие VDS не заменяет требований Anthropic к фактическому местонахождению пользователя и что совпадение стран карты, SIM и сервера ничего не гарантирует. Он же делит подписку с товарищем, и это отдельная зона риска: общие службы и порты на одной VDS, несколько пользователей с root. Токен setup-token хранится на сервере, а значит, сервер становится критичной точкой. Обход региональных ограничений и общий доступ к подписке могут противоречить условиям сервиса, так что аккаунт можно потерять снова. Командам лучше использовать такую архитектуру там, где у них есть законный доступ и нужен централизованный выход, а не как способ обойти правила провайдера.

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