Я полез в логи Mac после блокировки Claude, а починил только доступ к рабочим сайтам

Разбирался я вместе с Codex. Он читал журналы, писал скрипты и сопоставлял результаты, а команды с sudo я запускал сам в Terminal. Всё описанное было в августе-октябре 2026 года, время минское. IP сайтов здесь исторические, по ним настраивать ничего не надо.

Что нашлось в журналах Claude

Начал с папки ~/Library/Logs/Claude/. В web-журналах повторялись три маркера: app-unavailable-in-region, region_unavailable и Claude isn’t available in your region. Искал так:

rg -n \ -e ‘app-unavailable-in-region’ \ -e ‘region_unavailable’ \ -e “Claude isn’t available in your region” \ “$HOME/Library/Logs/Claude”/claude.ai-web*.log

В основном файле нашлось 1 264 строки, с двумя ротациями 2 891. Это строки журнала. Приложение повторяет запросы и пишет один отказ по нескольку раз, так что «2 891 утечка» была бы враньём.

Для подробного разбора я взял девять дат. Часть ошибок шла сразу после пробуждения Mac, часть рядом с активностью WireGuard. Самым подозрительным выглядело 29 сентября, за два дня до блокировки.

Совпадение по времени есть, состояния туннеля и IP запросов в журналах нет

Последовательность красивая, но она ничего не доказывает. Окно WireGuard открылось, а это не момент подключения туннеля: расширение уже работало раньше. Запись о меню не говорит, какой пункт я нажал. Вполне возможно, я полез в WireGuard как раз потому, что Claude уже ругался.

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

Почему сеть задним числом не восстановить

У WireGuard нашёлся бинарный файл tunnel-log.bin. По исходному коду кольцевого журнала WireGuard видно, что он держит 2 048 записей и новые пишутся поверх старых. 3 октября все 2 048 записей были за 3 октября, сентябрь уже затёрся.

Часть системной истории тоже не сохранилась. По некоторым контейнерам macOS отвечала Operation not permitted, то есть журнал мог быть, просто прочитать его не дали.

Отдельно пришлось разобраться с пометкой (direct) в логе Claude. Она про выбор HTTP-прокси внутри приложения и ничего не говорит о том, ушёл ли пакет через системный VPN. Для себя я разложил так:

1. (direct) в логе приложения значит только то, что запрос не пошёл через HTTP-прокси.

2. route get с ответом utunN показывает, что сейчас маршрут к этому адресу идёт в туннель.

3. Внешний IP от контрольного сервиса показывает адрес только для этого запроса.

4. region_unavailable значит, что сервер отказал по региону, и больше ничего.

Сегодняшняя проверка IP не восстанавливает вчерашний. И проверка одного адреса не говорит про все соединения приложения.

Через VPN перестали открываться рабочие сайты

Пока я копался в Claude, появилась вторая проблема, уже рабочая. При включённом WireGuard не открывались amoCRM, приложение TGBooster и Geekjob. Каждый раз выключать VPN ради CRM неудобно, и это ломало саму идею.

Я сравнил два пути, не выключая WireGuard: обычный маршрут и физический интерфейс en0. Обычный запрос выглядел так, для второго добавлялся —interface en0:

curl -q —proxy ‘’ —ipv4 —silent —show-error \ –connect-timeout 5 —max-time 8 —output /dev/null \ –write-out ‘http=%{http_code} remote=%{remote_ip} connect=%{time_connect}\n’ \ https://app.tgbooster.ru/companies

На другом Mac или по кабелю интерфейс может называться иначе. Запросы к Anthropic для таких проверок я не отправлял, сравнивал только рабочие сайты и контрольный сервис. 4 октября через VPN все пять адресов падали по тайм-ауту, через en0 отдавали HTTP 200: страница TGBooster, его JS и CSS на cdn.tgbooster.ru, публичная страница amoCRM, скрипт входа на statix.amocrm.ru и главная Geekjob.

Где рвётся, на VPN-сервере, в промежуточной сети или в защите сайта, я не выяснил. Писать «сайт блокирует VPN» было бы слишком сильно.

Две детали стоили мне времени. Одного основного домена мало: TGBooster тянет скрипты со своего CDN, а странице входа amoCRM нужен statix.amocrm.ru, которого в моём первом списке не было. И проверочный скрипт сначала считал ответ 401 от amoCRM сетевой ошибкой. На деле HTTPS-соединение прошло и пришла страница авторизации, это не вход, но и не тайм-аут.

Почему я не стал пускать через VPN только Claude

Первый план был простым: несколько сетей Claude в туннель, всё остальное напрямую. Проверка нашла дыру сразу. 4 октября downloads.claude.ai смотрел на 35.190.46.17, а этой сети в списке не было. В сетевых требованиях Desktop перечислены целые семейства доменов, и короткий список найденных IP их не покрывает.

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

Сначала попробовал сделать это через AllowedIPs. Расчёт был правильный: все 127 подготовленных IPv4-префиксов появились в системе. Но адреса amoCRM всё равно уходили через оставшийся VPN default route на utun8. Физический default route рядом не помогал, он был привязан к интерфейсу. Пришлось смотреть, что система реально выбирает для конкретного адреса:

/sbin/route -n get 23.111.99.17 /sbin/route -n get 1.1.1.1

Что вернуло доступ

Сработали явные маршруты к отдельным IPv4-адресам через домашний шлюз. Начал с одного адреса Geekjob, проверил, потом добавил остальные:

sudo /sbin/route -n add -host 185.209.28.104 192.168.100.1

185.209.28.104 тогда был адресом Geekjob, 192.168.100.1 это шлюз моей сети. На другой машине и то и другое надо смотреть заново. После каждого маршрута я проверял три вещи: куда идёт рабочий адрес, куда идёт контрольный и проходит ли обычный HTTP-запрос без привязки к en0.

VPN остался основным путём, напрямую идут только проверенные рабочие адреса

Для amoCRM, TGBooster и Geekjob вышло десять маршрутов. Адреса Claude, которые я проверял, остались в туннеле. Потом так же добавил Cossa и Telemetr, Telemetr сразу отдал нормальную страницу с HTTP 200.

И снова споткнулся о свой скрипт. Он требовал у route get флаг STATIC, а macOS может вернуть клонированную запись с WASCLONED, хотя путь уже правильный. Переписали проверку на сравнение назначения, шлюза и интерфейса.

У решения есть честные ограничения. Маршруты живут до перезагрузки. В другой сети прежний шлюз не подходит. Сайт поменял DNS, и адреса надо пересматривать. Правило по IP действует на весь адрес, даже если на нём сидят несколько сайтов. А скрипты проверяли публичные страницы, работу внутри аккаунтов я смотрел руками в браузере.

Как защита от утечки уронила мне интернет

Оставалась защита на случай, когда туннель падает. Маршрут решает, куда отправить пакет, а kill switch должен запретить выход напрямую. Одни AllowedIPs такого запрета не давали.

Мы собрали временные правила PF, системного пакетного фильтра: туннель и выбранные рабочие адреса можно, остальной прямой выход нельзя. Первый тест прошёл. На время испытаний я закрывал Claude, Claude Code и браузеры с Claude. При ручном отключении WireGuard контрольный HTTPS-адрес перестал отвечать, а три рабочих сайта продолжили отдавать 200.

Дальше появилась служба через launchd. Она находила интерфейс WireGuard и шлюз, восстанавливала маршруты, следила за правилами PF и писала журнал. IPv6 в ней просто блокировался. Проверки при включённом VPN, ручном отключении и после перезагрузки прошли. Тут я и поторопился: решил, что этого хватит для постоянной работы.

Вечером 5 октября интернет пропал и с VPN, и без него. В журнале службы с 21:29 до 21:32 крутилось одно и то же:

Own anchor/table changed Own PF hook/order missing

Служба пыталась восстановить правила PF, снова видела расхождение и по своей же логике закрывала всё. Переключение VPN такую блокировку не снимало.

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

Цикл ошибок журнал подтверждает. Что первым нарушило правила, я не знаю, поэтому не скажу, что виновата только служба. Но она точно участвовала или усилила сбой, и оставлять её было нельзя. Сделали заготовленный откат: остановили службу, убрали автозапуск, вернули исходный /etc/pf.conf, удалили её маршруты, журналы сохранили. Контрольные запросы снова пошли и через VPN, и напрямую. Рабочие маршруты потом вернул отдельным скриптом, а самодельный guard так и остался выключен.

Что осталось на 8 октября

Доступ к рабочим сайтам при включённом WireGuard есть. Проверенные адреса Claude идут через VPN, это видно по снимкам маршрутов. Устойчивой защиты при падении туннеля нет, guard откатан. Какой IP Anthropic видел в сентябре и почему заблокировали аккаунт, я так и не узнал.

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

Если повторять такую настройку, я бы делал так:

1. Сравнить один и тот же запрос через туннель и через физический интерфейс.

2. Открыть страницу в браузере и выписать все домены, с которых она грузит скрипты и стили.

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

4. Добавлять маршруты по одному и после каждого проверять рабочий и контрольный адрес.

5. До любых правил PF вести свой короткий журнал: время, профиль VPN, интерфейсы, маршруты, состояние фильтра, ответ контрольного запроса.

Когда это не сработает

Точечные маршруты не переживут перезагрузку и смену Wi-Fi без отдельного скрипта. Если сайт часто меняет IP или сидит за большим CDN, список адресов придётся постоянно обновлять. А kill switch из нескольких удачных тестов не получается: сон и пробуждение, смену сети, падение расширения и ошибки самой проверки я так и не прогнал.

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

Я 19 лет в маркетинге и работаю как внешний руководитель маркетинга, поэтому amoCRM и рекламные кабинеты для меня рабочий инструмент каждый день. Сетевик из меня так себе, и этот текст скорее про то, как не выдать красивую хронологию за доказательство.

А вы как держите рабочие сервисы при включённом VPN: точечными маршрутами, отдельным профилем или просто выключаете туннель?