Руководство

Раздельная маршрутизация прокси-клиента для стабильной работы MCP

Claude Code иногда выдаёт ошибку сертификата. Инструменты Яндекс Директа то появляются в списке, то исчезают. Страница в браузере открывается, а из терминала подключение рвётся. Знакомая картина? Разбираемся, почему установленный на компьютере прокси-клиент может влиять на TLS-подключение к российскому MCP-серверу и как настроить раздельную маршрутизацию — чтобы локальный трафик шёл напрямую, без лишнего слоя прокси.

Симптомы

Если у вас установлен прокси-клиент с перехватом всего трафика (Clash Verge, Stash, Shadowrocket, Surge, V2Box и подобные инструменты маршрутизации) и он работает в режиме «весь трафик через прокси», вы можете столкнуться с такими проблемами при работе с российскими сервисами:

Что видно пользователю

Claude Code при старте выдаёт UNKNOWN_CERTIFICATE_VERIFICATION_ERROR — и инструменты MCP не регистрируются
ChatGPT, Cursor или Cline подключаются к MCP «через раз» — иногда сразу, иногда через 10 попыток
Админка Яндекс Директа, Метрика, VK Ads загружаются очень медленно (5+ секунд на страницу)
В браузере сайт открывается, а в терминале curl https://lidfly.ru падает по таймауту
Команда dig +short lidfly.ru возвращает странные адреса вида 198.18.0.34 вместо настоящего IP российского сервера

Почему это происходит

Прокси-клиенты с TUN-режимом работают по принципу «перехватить весь трафик». Это удобно для типовых задач маршрутизации (корпоративный прокси, split DNS в офисе, работа через специальный шлюз) — не нужно настраивать каждое приложение отдельно. Все процессы на компьютере автоматически идут через сконфигурированный прокси-сервер.

Но когда прокси активен, через него проходит и трафик на локальные российские сервисы — в том числе на lidfly.ru, серверы Яндекса, VK и любые другие. Типовой маршрут пакета выглядит так:

Ваш компьютер → прокси-клиент перехватывает соединение → зашифрованный туннель до прокси-сервера → прокси-сервер расшифровывает и переоткрывает соединение → запрос доходит до исходного сервера → ответ проходит тем же путём в обратном порядке

Для подключения к локальному сервису это создаёт несколько проблем:

Повышенная задержка — к прямому RTT добавляется RTT до прокси-сервера. Вместо 10 мс до локального дата-центра получается 100–200 мс
Двойное шифрование — поверх TLS-сессии с конечным сервером накладывается ещё один слой шифрования туннеля
Подмена IP на служебные — в режиме fake-IP клиент заменяет реальные адреса на диапазон 198.18.0.0/15 для внутренней маршрутизации. Для большинства приложений это прозрачно, но строгие TLS-стеки (например, Bun, на котором работает Claude Code) иногда пытаются выполнить verify для фейкового адреса и падают с UNKNOWN_CERTIFICATE_VERIFICATION_ERROR
Гонки при переподключении — после разрыва соединения прокси-клиент может не успеть восстановить соответствие fake-IP ↔ domain, и TLS-handshake завершается сбоем

Это не проблема сервера. Сертификат lidfly.ru валидный (Let's Encrypt E7, срок действия актуален). curl из терминала минуя прокси (с системным Keychain) подключается успешно. Проблема возникает именно на стыке: Bun + fake-IP + TLS verify.

Решение: раздельная маршрутизация

Все популярные прокси-клиенты поддерживают split routing — раздельную маршрутизацию по правилам. Идея простая: определённые адреса идут напрямую, остальные — через прокси.

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

По домену — всё, что заканчивается на .ru, идёт напрямую. Правило срабатывает по SNI, без DNS-резолва — мгновенно
По геолокации IP — если домен находится на другом TLD, но резолвится в российский IP (например, CDN с .com-доменом, но хостингом в РФ), тоже напрямую. Матчится по встроенной базе GeoIP (Country.mmdb)

Добавим оба правила в конфиг прокси-клиента.

Настройка по клиентам

Clash Verge / Clash Meta / mihomo

Clash Verge Rev

macOS, Windows, Linux

Открываем папку профилей клиента:

macOS: ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/
Windows: %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\profiles\
Linux: ~/.config/clash-verge-rev/profiles/

Открываем файл Merge.yaml — это специальный файл, который применяется поверх активного профиля. Редактировать сам профиль подписки не нужно — при автообновлении ваши правила затрутся.

Merge.yaml

profile: store-selected: true prepend-rules: - DOMAIN-SUFFIX,ru,DIRECT - GEOIP,RU,DIRECT dns: fake-ip-filter: - '+.ru'

Что это значит:

prepend-rules — добавить правила в начало списка (до финального MATCH, который отправляет остальное в туннель)
DOMAIN-SUFFIX,ru,DIRECT — любой домен, заканчивающийся на .ru, идёт напрямую
GEOIP,RU,DIRECT — любой российский IP идёт напрямую (проверяется по Country.mmdb)
fake-ip-filter: '+.ru' — для .ru доменов клиент не подменяет IP на фейковый, а отдаёт настоящий

Сохраняем файл. Открываем Clash Verge → вкладка Profiles → кликаем на активный профиль ещё раз (или меню ⋯ → Activate). Клиент пересоберёт конфиг и передаст его в движок mihomo.

Stash

macOS, iOS

Stash использует тот же формат правил, что Clash. Открываем приложение:

Settings (иконка шестерёнки) → Override
Включаем тумблер Enabled
В поле YAML вставляем:

Override → YAML

rules: - DOMAIN-SUFFIX,ru,DIRECT - GEOIP,RU,DIRECT dns: fake-ip-filter: - '+.ru'

Нажимаем Save
Возвращаемся на главный экран и переключаем тумблер подключения (выкл → вкл) — правила применятся

Shadowrocket

iOS, iPadOS

В Shadowrocket правила задаются через вкладку Configuration:

Открываем приложение → нижняя вкладка Config
Выбираем активную конфигурацию → Edit
Ищем секцию [Rule] — в самом верху секции, до FINAL,PROXY, добавляем две строки:

Раздел [Rule]

[Rule] DOMAIN-SUFFIX,ru,DIRECT GEOIP,RU,DIRECT # ... остальные правила конфигурации FINAL,PROXY

Сохраняем конфигурацию (кнопка Done в правом верхнем углу)
Выключаем и снова включаем тумблер подключения на главном экране

Также в Shadowrocket есть встроенный набор правил «China» (и аналогичный для России можно собрать через Rule Set). Для простоты двух строк выше обычно достаточно.

Surge

macOS, iOS

Surge хранит конфигурацию в текстовом файле с INI-подобным синтаксисом. Редактируем активный профиль:

На macOS: Surge в меню → Edit Profile (или ⌘E)
На iOS: Settings → Profiles → выбираем активный → Edit
В секции [Rule] добавляем две строки в самом верху:

Раздел [Rule]

[Rule] DOMAIN-SUFFIX,ru,DIRECT GEOIP,RU,DIRECT # ... существующие правила FINAL,PROXY,dns-failed

Сохраняем (⌘S)
Surge применит изменения автоматически, перезапуск не нужен

Системный прокси macOS и Windows (SOCKS/HTTP)

Настройки сети → Прокси

macOS / Windows

Если вы используете системные настройки прокси (Системные настройки → Сеть → Прокси), там есть поле Исключить для этих хостов и доменов (macOS) или Не использовать прокси-сервер для адресов (Windows).

Добавляем в него, через запятую:

Список исключений

*.ru, *.aatex.ru, localhost, 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Ограничение этого способа — здесь нельзя указать правило по GeoIP, только по доменам и подсетям. Для российских CDN, работающих на .com или .net доменах, записи придётся добавлять вручную.

Как проверить, что всё работает

После применения правил в терминале (macOS/Linux) или PowerShell (Windows) запускаем три команды:

DNS возвращает настоящий IP

dig +short lidfly.ru

Должен вернуть 5.188.119.183 — это реальный IP нашего сервера. Если видите 198.18.x.x — правила не применились, клиент ещё не перечитал конфиг.

HTTPS-подключение идёт напрямую

curl -sI https://lidfly.ru/ -o /dev/null \ -w "HTTP %{http_code} | IP %{remote_ip} | %{time_total}s\n"

Ожидаем примерно: HTTP 200 | IP 5.188.119.183 | 0.08s. Если время больше секунды или IP начинается с 198.18 — трафик всё ещё через туннель.

Остальной трафик продолжает идти через прокси

dig +short example.com

Здесь, наоборот, ожидаем 198.18.x.x (или любой другой служебный адрес вашего клиента) — это нормально. Значит маршрутизация через прокси для всего, что не попадает под DIRECT-правила, работает как раньше.

Если всё равно не подключается

Частые причины:

Клиент не перечитал конфиг. Правки в файле сохранились, но движок работает на старой копии. Лечение: в GUI клиента нажать кнопку Activate на активном профиле или выключить/включить тумблер подключения
DNS-кэш на стороне ОС. Команда сбрасывает на macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. На Windows: ipconfig /flushdns
Устаревшая база GeoIP. Если Country.mmdb в клиенте старше года, некоторые российские диапазоны могут отсутствовать. В Clash Verge: Settings → Update GeoIP Data. В других клиентах — аналогично
Конкретный клиент не видит Merge.yaml. Проверьте, что активный профиль существует и синхронизирован. Откройте файл config.yaml в той же папке и поищите в нём строку DOMAIN-SUFFIX,ru,DIRECT — если её там нет, значит профиль не был пересобран
AppTranslocation на macOS. Если приложение запущено из папки Downloads или временной папки Translocation, оно может не видеть изменения в конфиге. Переместите .app в /Applications и запустите оттуда

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

Что даёт раздельная маршрутизация

Правила DOMAIN-SUFFIX,ru,DIRECT и GEOIP,RU,DIRECT решают не только проблему TLS-сертификата у Bun. У раздельной маршрутизации есть чисто технические преимущества, которые полезны при любой прокси-конфигурации:

Меньшая задержка для локального трафика — соединения до сервисов, находящихся рядом с вами (в том же регионе), идут по короткому маршруту, без дополнительного hop до прокси-сервера и обратно
Отсутствие двойного шифрования — для локальных адресов не нужно оборачивать TLS-сессию в туннельное шифрование. Меньше CPU, меньше latency
Более стабильный TLS — строгие клиенты (Bun, некоторые сборки Node.js, Deno) не сталкиваются с fake-IP и не ломаются на verify сертификата
Разгрузка прокси-сервера — через него идёт только тот трафик, для которого это действительно нужно. Меньше объём — меньше шанс упереться в квоту
Предсказуемое поведение — при разрыве прокси-соединения локальные сервисы продолжают работать, потому что они не привязаны к прокси

Для остального трафика прокси работает как раньше — правила DIRECT добавляются перед финальным MATCH, а не вместо него.

Готово? Подключайте MCP

После настройки клиента трафик на lidfly.ru идёт напрямую. Можно подключать Яндекс Директ, VK Ads и LidFly к ИИ-клиенту без ошибок сертификата.

Получить API-ключ