Работа в Claude Desktop и Claude Code
Антидетект-браузер надежно защищает сессию при работе через веб-интерфейс claude.ai. Но если тебе нужен официальный клиент Claude Desktop или консольная утилита Claude Code в терминале, правила игры меняются.
Оба инструмента работают как нативные процессы операционной системы Windows. Если запустить их без подготовки, они пойдут в интернет напрямую через твой домашний сетевой адаптер, мгновенно раскрыв реальный IP-адрес и сняв аппаратные идентификаторы твоего компьютера.
Если на этом компьютере раньше запускался Claude Desktop, Claude Code или открывался сайт claude.ai под другими аккаунтами, сначала обязательно запусти скрипт очистки cleanup_anthropic.ps1.
Иначе локальный machineId, MSIX-контейнеры и сохраненные сессионные токены моментально свяжут новую учетку с историей прошлых блокировок.
1. Роутинг: как заворачивать трафик под Claude Code
Сначала пойми, с чем воюешь, потому что тут всё не так просто, как кажется. Прописать $env:HTTP_PROXY в окне терминала — это не защита, а её имитация. Node переменные прокси не читает вообще, PowerShell через Invoke-WebRequest тоже их не читает, а git слушает только свою настройку http.proxy. То есть у тебя в одном окне будут процессы, которые ходят через прокси, и процессы, которые ходят напрямую с домашнего IP, и второй категории обычно больше. Один такой дочерний процесс — и весь аккаунт спалён, причём ты даже не узнаешь, что именно его выдало.
Так что забудь про переменные среды как про основной метод. Их можно выставить дополнительным слоем, но заворачивать надо либо всю систему в виртуальный адаптер, либо каждый процесс принудительно через драйвер.
Поверхностей у нас три, и свита у них разная:
| Поверхность | Что реально лезет в сеть | Чем палится |
|---|---|---|
| Claude Code | claude.exe, node.exe, git.exe, rg.exe, powershell.exe, cmd.exe, curl.exe | Любой дочерний процесс мимо туннеля |
| Claude Desktop | Claude.exe, cowork-svc.exe, апдейтер, VM Cowork | Нет полей для прокси, ходит напрямую |
| Веб | Профиль в антидетекте | Уже изолирован, трогать не надо |
Вариант A. Тюн-режим, полный туннель
Основной и самый надёжный вариант. Поднимаешь виртуальный сетевой адаптер, весь трафик машины уходит в туннель, и ловить процессы по имени тебе не нужно — они уже внутри. Заодно закрывается вся телеметрия и апдейтер, про которые ты наверняка забудешь.
Порядок такой. Импортируешь реквизиты своего резидентского прокси, включаешь TUN. Дальше самое важное: убиваешь всю выборочную маршрутизацию. Никакого Direct, никаких баз российских доменов, никаких «локальные сети в обход» кроме реальных 127.0.0.1/8 и 192.168.x.x. Строго Global, весь трафик через туннель. Если у клиента есть network lock или kill switch — включай, это не опция, а необходимость.
Потом проверяешь не одним curl, а двумя командами из того же окна, из которого будешь запускать claude:
curl.exe -s https://ipinfo.io/json
node -e "fetch('https://ipinfo.io/json').then(r=>r.json()).then(j=>console.log(j.ip, j.country))"
Обе строки обязаны показать IP прокси и нужную страну. Если curl показывает прокси, а node — домашний адрес, у тебя дыра ровно там, где ходит Claude Code, и это самый частый способ слить аккаунт на ровном месте.
Вариант B. Проксификатор, селективный перехват
Нужен тогда, когда гонять весь компьютер через туннель не хочешь: работаешь как обычно, а через прокси идут только процессы Claude. Работает на уровне драйвера WFP и перехватывает соединения по правилам.
Главная ошибка здесь — правила по именам процессов. Native-инсталлятор кладёт бинарник в %USERPROFILE%\.local\bin\claude.exe, npm-версия живёт в node_modules\.bin\, а node.exe может быть от nvm или fnm в совершенно другом месте. Поэтому правила делай по полным путям, а не по имени. И дефолтное правило ставь Block, а не Direct: иначе любой новый процесс, которого нет в списке, спокойно сходит домой напрямую, и ты об этом не узнаешь.
Остаются три вещи, без которых проксификатор бесполезен. Первое — включи резолв доменов через прокси, иначе DNS уходит твоему провайдеру, а CDN отдаёт ближайшую к тебе точку, и ты получаешь локальную задержку под чужим IP. Второе — поставь исключение на localhost и 127.0.0.1, без него OAuth-логин Claude Code сломается, а каждая неудачная попытка входа это событие в логах. Третье — UDP через SOCKS5 не ходит, так что либо разрешай фолбэк, либо просто отключай QUIC в профиле.
Чем это делать
Лично я держу два инструмента под разные задачи. v2rayN с Tun Mode на sing-box — мой основной вариант под Claude Desktop: одна кнопка, глобальный туннель, ничего не надо настраивать руками. Hiddify — то же самое, но проще интерфейсом и с локом, удобно, когда не хочется разбираться в маршрутах.
Clash Verge Rev хорош, если нужно fake-ip для DNS и отдельные профили под разные задачи. Netch — узкоспециализированный туннелизатор только под Windows в режиме полного перехвата. А Proxifier — единственный нормальный способ сделать селективно и без TUN, но требует аккуратности, см. подводные камни ниже.
Подводные камни, на которых люди теряют аккаунты
Начну с DNS. Публичных подтверждений, что Anthropic или Stripe ловят утечку резолвера как фрод-сигнал, нет — сайт видит IP, TLS и заголовки, а не твой домашний резолвер. Но проверить всё равно надо по двум причинам: во-первых, кривой DNS ломает гео CDN и ты получаешь локальную задержку под чужим IP, во-вторых, при локальном резолве запросы реально уходят провайдеру, и это видно не антифроду, а твоему ISP. Проверяй на browserleaks.com/dns, для консоли хватит nslookup claude.ai: сервер ответа не должен быть домашним.
Дальше IPv6. Сам по себе он через SOCKS5 не утекает: Chrome корректно проксирует IPv6-цели, прокси сам соединяется с назначением. Светит другое — WebRTC через UDP и нативные приложения в обход туннеля. Проверяй browserleaks.com/webrtc и отдельно смотри, что у тебя реально ходит по сети: Get-NetTCPConnection в момент работы Claude.
QUIC и HTTP/3 тоже лучше выключить, но не потому, что они «утекают». Chrome через SOCKSv5 проксирует только TCP и UDP не передаёт, а на QUIC падает и откатывается на TCP — со стороны это лишние ретраи и дёрганый стриминг ответов. Прямая утечка UDP возможна не из браузера, а из нативного приложения, которому не завернули UDP в туннель.
Cowork VM в десктопном клиенте разворачивает свою виртуалку со своим сетевым адаптером. При NAT-сети трафик идёт через хост и TUN его ловит, но при bridge/vSwitch часть пакетов может уйти мимо. Загляни в Get-NetAdapter и убедись, что у адаптера Cowork нет прямого выхода в физическую сеть.
Апдейтер и телеметрия — отдельная песня. Claude.exe обновляется с отдельного CDN, телеметрия летит на statsig и sentry. При селективном перехвате про них забывают, и апдейтер спокойно ходит напрямую. Либо TUN, либо правило на всю папку приложения целиком.
И последнее, про латентность. Американский резидентский прокси с RTT 250 мс и лимитом 2 ГБ — плохая пара для Claude Code: контексты большие, стриминг чувствителен к задержке, а трафик улетает быстрее, чем ты думаешь. Бери адрес с RTT до 150 мс и следи, сколько гигабайт съедает одна рабочая сессия.
Когда ты вводишь команду claude login, утилита генерирует ссылку для авторизации.
Ни в коем случае не кликай по ней напрямую в консоли!
Windows откроет ссылку в системном браузере по умолчанию (Chrome или Edge) под домашними отпечатками и без антидетекта.
Скопируй ссылку из терминала руками, перейди в свой профиль в Multilogin (или Octo Browser), вставь в адресную строку и подтверди вход строго внутри изолированной сессии.
Изоляция локальных конфигов
Файл ~/.claude.json и каталог ~/.claude хранят OAuth-токены сессии и уникальный machineId.
Не используй эти файлы на разных аккаунтах. Если нужно сменить учетку, сначала выполни полную очистку системы скриптом cleanup_anthropic.ps1, и только потом настраивай авторизацию заново.
2. Claude Desktop
У приложения нет полей для прокси. При старте оно лезет в сеть напрямую, а фоновая служба CoworkVMService вдобавок разворачивает виртуальную машину со своим сетевым адаптером. То есть мало завернуть сам процесс — надо ещё понимать, откуда пойдёт трафик изнутри виртуалки.
Не ставить вообще
Если тебе не нужна Cowork VM, самый безопасный вариант — не ставить клиент. Полноэкранная вкладка профиля в Multilogin даёт тот же чат и проекты, но с полной изоляцией железа, WebGL, шрифтов и сетевых пакетов. Ты просто не создаёшь ещё один процесс, который может утечь.
Глобальный TUN
Клиент нужен — держи Тун активным всё время работы. Заворачиваются Claude.exe и cowork-svc.exe, DNS обязательно через прокси. Приложение не запускай, пока адаптер не поднялся и не отдаёт чистый внешний IP: старт с домашнего адреса уже записан в логи, и второй раз его не перепишешь.
Отдельно проверь сеть у самой виртуалки. При NAT трафик идёт через хост и Тун его ловит, но при bridge часть пакетов уходит мимо. Смотри Get-NetAdapter и убедись, что у адаптера Cowork нет прямого выхода в физическую сеть.
Отдельная виртуалка
Максимальный вариант: чистая Windows в Hyper-V, VMware или VirtualBox, внутри постоянный туннель, чекеры прогнаны до установки клиента. Приложение видит виртуальное железо, твой настоящий machineId остаётся снаружи. Дороже по ресурсам, зато поверхности разделены полностью.
machineId и почему он важнее IPmachineId — локальный идентификатор, который клиентское приложение и CLI сохраняют у себя при первом запуске. Он переживает переустановку, смену аккаунта и сброс пароля. Если этот файл остался от забаненного профиля, новый аккаунт с большой вероятностью привяжут к старому, даже если IP другой.