Как я оставил проекты на Mac, а доступ к Claude Code вынес на VDS

Конечно же уже все слышали об очередной волне блокировок Claude, накрывшей в начале октября пользователей с наших просторов и продолжающихся по сей день. Моя Max лицензия отлетела ровно за день до оплаты и я даже сначала не сообразил в чем дело и пошел проверять баланс на заветной карте. Но баланс остался нетронутым. 
Зная, что обращение в поддержку ничего не даст, я не стал терять времени и пошел покупать новую подписку, попутно изучая причины блокировок у других людей, комменты на форумах и предположения разного рода. Однозначного ответа что делать не нашлось, но схожие симптомы(у меня были разные страны для банковской карты, ВДСки, страны подписки в Anthropic) я у себя проследил и решил со следующим аккаунтом быть поосмотрительнее. Ах да, забыл про нюанс, что подписку за 200 с лишним баксов(в круг выходит аж 250 сейчас) мы раскидываем с товарищем вскладчину, поэтому решение должно учитывать и это.

С чего я начинал

Я взял новую ВДСку в одной европейской стране, в которой у меня была банковская карта и выбрал ее же при регистрации в Anthropic. Получив от нее креды в виде рутового логопасса и публичного айпишника, я быстро настроил ее привычным ansible плейбуком: поднял узел netbird(сервер у меня на домашнем микроте, а пирами подключаю различные внешние устройства), накатил общие для всех моих Линуксов настройки, агенты мониторинга, нового юзера и публичный ssh ключ. Добавил Claude агента и получил для него токен.

В детали получения SIM-карты, банковской карты и покупки подписки вдаваться не буду: для этой статьи не принципиально, каким способом они были получены. Важное условие моей исходной конфигурации — SIM-карта, Visa и VDS в одной стране.

Это не опубликованное Anthropic правило «три страны обязательно должны совпадать». В документации отдельно описаны поддерживаемые страны, проверка телефонного номера и требования к оплате. В частности, требования к фактическому местонахождению пользователя не заменяются наличием VDS. Совпадение страны этих трёх вещей само по себе не гарантирует доступ. Но мне кажется интересным проверить именно эту гипотезу. Каждый кодит как хочет, а я кодю, как я хочу.. ну или как там говорят..

Итак, на этот момент я получил:

• Мой уже немолодой, но верный Mac М1 Pro 14 с VS Code, расширением Claude Code и локальными проектами

• Linux VDS с установленным Claude Code и работающей авторизацией моего аккаунта через долгоживущий токен, зашитый в /etc/environment

• NetBird между машинами и доступ по SSH-ключу

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

Первая попытка: VS Code Remote SSH

Начал с первого нагугленного(наКложенного?). VS Code уже умеет работать через SSH через плагин VS Code Remote SSH. Выглядело все банально: доустановить серверную часть редактора и расширение Claude Code на VDS. Уже существующая авторизация на Linux должна позволять выполнять запросы к моделям. И оно заработало! В окне файловая система, терминал и исполняемая на Linux магия появляющихся слов... Но мой обычный локальный проект с Mac сам по себе там не появился.. Я почему-то наивно полагал, что произойдет именно это. 
Но оказалось, что все не так. Да, технически можно клонировать репозиторий на сервер, настроить синхронизацию или даже полностью перенести разработку. Для другой задачи это было бы нормальным решением, но часть файлов я психологически не готов размещать на чужой, далекой от меня машине, так что пришлось сформулировать требование точнее:

Claude Code читает и меняет мои файлы на Mac. Запросы к модели выходят через Linux. Авторизация Anthropic остаётся на Linux.

После этой фразы Remote SSH отошел на второй план и остался как прямой доступ для части проектов, но я двинулся дальше.

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

Следующая идея — запустить HTTP-прокси на Linux и направить в него локальный Claude.

Это решает вопрос исходящего сетевого адреса. Но прокси не передаёт приложению авторизацию из другого процесса на другой машине. Если клиент на Mac не имеет подходящих кредов, то всего лишь одно изменение маршрута не залогинит его в аккаунт, которым пользуется Linux.

Поэтому понадобились две разные функции:

API-шлюз и HTTP-прокси — разные сервисы. Вывешиваем оба порта на наш localhost Mac через SSH-туннель.

Ну и понятно, что нейросеть не работает на моём VDS, а вычисляет ответ в облаке Anthropic. На VDS находятся шлюз, токен для Claude и самое важное: сетевой выход с правильный айпишником. На моем Маке остается мой локальный агент(с прописанными в конфигах значениями - об этом ниже), файлы и исполнение локальных инструментов. Схематично:

Иными словами репозитории как файлы на VDS не синхронизируются, остаются у меня локально. К модели уходят только выбранные агентом фрагменты файлов и результаты локальных команд.

Шаг 1. Проверить то, что уже работает

Установив на Linux claude и авторизовавшись через magic link, коротким запросом к модели проверяем работоспособность. Я уточнил что она знает о своем окружении и внешнем айпишнике. Ответ меня устроил, все шло по плану. Существующий серверный Claude работает.

Одной из итераций фиксировал версии в ансибле и вот что получилось:

Версии CLI позднее сыграли злую шутку, в очередной раз подтвердив аксиому, что за ними всегда надо следить и не полагаться на последнюю. 

Далее в командах будет встречаться claude-vds — мой SSH alias для ВДСки, и dev — пользователь Linux. Порты оставил такими, какими они были в рабочей настройке.

Шаг 2. Поднять API-шлюз на Linux

Вычитал, что есть такая штука как CLIProxyAPI. Выбрал версию 8.0.20: официальный архив под мою архитектуру на VDS. Сам бинарник разместил в ~/.local/share/claude-gateway/, конфигурацию и серверный auth-файл — в ~/.config/claude-gateway/. Установленная авторизация в моём окружении приходила через CLAUDE_CODE_OAUTH_TOKEN из /etc/environment - это шарит доступ в Клод между разными пользователями.

Для этого setup-token auth-файл содержал тип claude, существующий access_token и признак is_setup_token: true. Каталоги с credentials получили права 700, файлы — 600.

Для Mac создал отдельный ключ для шлюза. Это не OAuth-токен Anthropic, а авторизация Мака на Линуксе. Ключ переслал на Мак по SSH.

Основная часть серверного конфига выглядела так:

config-version: 8

server:
  host: "127.0.0.1"
  port: 18317

management:
  allow-remote: false
  secret-key: ""
  disable-control-panel: true

access:
  api-keys:
    - "<КЛЮЧ_ШЛЮЗА>"

oauth:
  auth-dir: "/home/dev/.config/claude-gateway/auth"

upstream:
  claude:
    disable-claude-cloak-mode: true
    disable-cloaking-model-list: true

routing:
  retry:
    request-retry: 0

observability:
  logs:
    debug: false
    request-log: false
  usage:
    usage-statistics-enabled: false

models:
  catalog: "/home/dev/.config/claude-gateway/models.json"

Важно, что это конфигурация для конкретного релиза, сверялся с примерами по доке. Пустой management secret в этой настройке оставляет управление отключённым.

Каталог моделей из исходников того же тега и запуск процесса с --local-model. Ниже расскажу, почему каталог пришлось дополнить.

Для запуска бинарника сделал отдельный systemd-сервис от непривилегированного пользователя. Команда запуска:

/home/dev/.local/share/claude-gateway/cli-proxy-api \
  --config /home/dev/.config/claude-gateway/config.yaml \
  --local-model

Для службы задал перезапуск при сбое, настроил привилегии, оставив запись только в её рабочие каталоги. Публичный HTTP-порт на VDS не открывал: слушатель строго привязан к 127.0.0.1

Первая ошибка:

Сначала импорт авторизации пытался выполнить перед стартом службы через ExecStartPre. Скрипт рассчитывал получить токен из окружения, но в окружении systemd нужной переменной не оказалось. Служба падала ещё до запуска шлюза.

Исправил это без нового логина: импорт выполнил на Linux отдельно, а служба стала читать готовый auth-файл. Для последующего обновления серверной авторизации составил отдельный скрипт. Автоматическое бесконечное продление setup-token из этого не следует, да и не закладываю осознанно - жизненный цикл credentials буду обслуживать руками пока не надоест

Шаг 3. Сетевой прокси

Второй сервис — Tinyproxy из репозитория ОС. Его конфигурация:

Port 18889
Listen 127.0.0.1
Timeout 600
LogLevel Warning
MaxClients 64
Allow 127.0.0.1
ConnectPort 443
DisableViaHeader Yes

Сервис также запускается отдельным systemd unit с Restart=on-failure. Он тоже слушает только loopback.

Вы спросите, а зачем же этот второй канал, если уже есть API-шлюз? А потому что настройка ANTHROPIC_BASE_URL адресует только запросы к моделям, а у самого локального клиента Клода остаются обращения к другим адресам сети, поиск в Интернете, MCP и другие способы передать неправильный айпи адрес и засветить ненужную Антропикам информацию. Поддержка этих переменных описана в сетевой документации Claude Code.

Tinyproxy не получает мой серверный OAuth, ему оно и не нужно. Его задача — только пересылка трафика и он делает это хорошо.

Шаг 4. Один SSH, два туннеля

На Mac оставил обычное SSH-подключение к VDS через NetBird. Можно было бы юзать и публичный адрес, но у меня уже есть определенная архитектура сети и я ей следую)
Пример записи в ~/.ssh/config:

Host claude-vds
    HostName <АДРЕС_VDS_В_NETBIRD>
    User dev
    IdentityFile ~/.ssh/claude-vds
    IdentitiesOnly yes
    ServerAliveInterval 30
    ServerAliveCountMax 3

Сам туннель — два локальных проброса:

ssh -NT \
  -o BatchMode=yes \
  -o ExitOnForwardFailure=yes \
  -o StrictHostKeyChecking=yes \
  -o ControlMaster=no \
  -o ControlPath=none \
  -o ConnectTimeout=15 \
  -L 127.0.0.1:18317:127.0.0.1:18317 \
  -L 127.0.0.1:18889:127.0.0.1:18889 \
  claude-vds

Первый 127.0.0.1 в каждом -L — адрес привязки слушателя на Mac. Второй — адрес назначения, к которому SSH подключится уже со стороны Linux.

Получились два маршрута:

• Mac :18317 → SSH → Linux :18317 → CLIProxyAPI → Anthropic;

• Mac :18889 → SSH → Linux :18889 → Tinyproxy → внешний HTTP(S)-адрес.

Итого: NetBird даёт нужную мне сетевую связность между машинами. SSH аутентифицирует соединение и переносит эти два канала. Он не синхронизирует проекты и не определяет, где агент исполняет команды.

Проверку ключа SSH-сервера оставил включённой. Сама команда предполагает, что ключ хоста уже проверен и сохранён в known_hosts.

Ну и чтобы не держать терминал с туннелем открытым, добавил пользовательский LaunchAgent на свой Мак:

~/Library/LaunchAgents/ru.devroadmap.claude-gateway-tunnel.plist

В ProgramArguments — аргументы SSH отдельными элементами массива. Для запуска и восстановления использую RunAtLoad=true, KeepAlive=true, ThrottleInterval=15. У SSH свои keepalive-проверки, у launchd — перезапуск завершившегося процесса. Один процесс держит оба порта - пока удобно работает. После сна или потери сети соединение может восстанавливаться, но уже оборванный запрос к модели это не возобновляет

Шаг 5. Локальный Claude Code

Ключ гейтвея сохранил на Mac в:

~/.config/claude-gateway/client-key

Права файла — 600. Дальше внес все важные настройки в ~/.claude/settings.json, сохранив прежние hooks, permissions и другие прежние настройки:

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://127.0.0.1:18317",
    "HTTP_PROXY": "http://127.0.0.1:18889",
    "HTTPS_PROXY": "http://127.0.0.1:18889",
    "NO_PROXY": "localhost,127.0.0.1,::1",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1"
  },
  "apiKeyHelper": "/bin/cat /Users/you/.config/claude-gateway/client-key"
}

Здесь /Users/you нужно заменить своим абсолютным путём. Это фрагмент для объединения с существующим конфигом, а не предложение стереть остальные настройки.

apiKeyHelper возвращает локальному клиенту ключ моего шлюза. ANTHROPIC_BASE_URL указывает, куда его отправить. В проверке claude auth status метод авторизации определяется как api_key_helper.

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

И еще одна важная вещь: в настройках VS Code добавил claudeCode.disableLoginPrompt=true. Эта настройка убирает приглашение войти в аккаунт и сам доступ обеспечивается через apiKeyHelper. Без нее каждый раз попадал на свой старый логин в заблокированный аккаунт.

Шаг 6. Проверка

Итак, ответ через глобально установленный claude на самом Линуксе ответ от модели я получил. Через Remote-SSH тоже получил. Но проверка нового варианта решения ввела в ступор: в ответ на запрос только ошибки. Выглядело как очередная проблема доступа, но копнувши глубже я увидел:

unknown provider for model

Гугл довольно быстро вывел на подсказки и удалось выяснить, что клиент обратился к вспомогательной модели claude-haiku-5-5, которой не оказалось в каталоге CLIProxyAPI 8.0.20. Проблема решилась банально дополнением каталога записью этой модели. Сначала попробовал перенаправлять запросы Haiku на другую модель, но быстро передумал. После добавления записи повторил реальные запросы к разным моделям и больше ошибок не увидел. С волнением жду обновления версий)

Шаг 7. Больше проверок

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

Проверки разделил по смыслу:

Делюсь с товарищем

Мы с товарищем пользуемся одной учётной записью Claude. Токенов хватает, за редкими исключениями, но в целом все устраивает. Над совместным проектом мы могли бы работать используя Remote-SSH и git, но остаются личные вопросы, которые несколькими пользователями с рутом на одной виртуалке безопасно разделить так просто не получится. 

 Я не учёл, что мы собираемся применять их на одной VDS и что в конфиге были общие имена systemd-служб и те же порты.

При проверке исходников обнаружилось: в промпте одновременно требовались существующий серверный OAuth, CLIProxyAPI и абсолютный запрет «не включать подмену клиента». При чтении профиля Anthropic возвращал 403 из-за недостаточных прав. Шлюз в такой ситуации мог сформировать служебный идентификатор аккаунта. Кроме того, для OAuth он применял профиль идентификации Claude CLI даже с отключённым cloaking.

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

Обработка OAuth, заголовков и служебных metadata остаётся. Это видно в логике авторизации и политике идентификации клиента.

Заодно пришлось отделить две ошибки:

• 403 на чтении профиля может означать отсутствие соответствующего scope;

• отказ в запросе к Messages API означает проблему с реальным обращением к модели.

 На моей Linux-машине системные службы и слушатели 127.0.0.1 были общими для обеих установок. Когда установка товарища использовала claude-api-gateway.service и порты 18317/18889, мой SSH-туннель продолжал подключаться, но трафик попадал уже в другой экземпляр шлюза. Он ждал другой relay key, поэтому Claude на Mac стал получать 401 Invalid API key - такой текст ошибки возвращает CLIProxyAPI.

Восстановил только свою установку: создал отдельные systemd-службы с собственным префиксом, перенёс API на порт 18327, прокси — на 18899 и добавил отдельный SSH alias devroadmap-claude-me. На Mac изменил только адреса шлюза и прокси. Серверный OAuth и relay key моей установки остались на месте, а авторизацию товарища я не менял. Короткий запрос через новый маршрут снова вернул OK.

Вывод из этой части уже не про OAuth: копируя конфиг на общую машину, нужно разнести имена служб, порты и SSH alias. На общем VDS сетевое пространство и системные службы общие даже для разных Linux-пользователей.

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

Что означает «Anthropic видит только IP VDS»

Для запросов, отправленных по описанным каналам, сетевой выход находится на VDS. При этом Anthropic получает авторизацию, содержимое запросов и связанные с ними метаданные. IP-адресом сведения о клиенте не исчерпываются.

Кроме того, эти настройки относятся к настроенному клиенту Claude Code. Они не превращают Mac в машину с принудительным общесистемным выходом через VDS. Браузер, другие приложения и отдельные инструменты, не учитывающие HTTP-прокси, могут использовать свои маршруты.

Локальные инструменты остаются под локальными разрешениями Claude Code. Облачная модель не получает из-за этого самостоятельный SSH-доступ к Mac или ко всей домашней сети. Если дать агенту локальный терминал, сетевые инструменты и соответствующие credentials, он сможет выполнять разрешённые действия через них — это уже отдельная настройка полномочий.

Для меня результат оказался полезным: рабочее окружение осталось на ноутбуке, серверная авторизация осталась на VDS, а нужный сетевой маршрут удалось проверить.

Выводы:

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

Теперь проекты открываются обычными локальными папками в VS Code. За доступ к модели отвечает VDS. Между ними — управляемое SSH-соединение с двумя пробросами, которое мне больше не нужно запускать вручную.

Я собирал эту среду для работы над своим проектом с дорожными картами изучения IT. В этот раз полезным материалом оказалась сама настройка рабочего инструмента: с промежуточной архитектурой, ошибкой systemd, неудачным промптом и конфликтом двух одинаковых конфигураций на одной VDS.

Интересно, как у вас устроена такая граница: переносите рабочую среду целиком на сервер или оставляете инструменты локально, вынося только доступ к модели? И как вообще боретесь с блокировками со стороны Антропика?