Настройка Claude Code и GitHub для работы через прокси в Windows

Claude Code работает в терминале: вы вызываете его через bash, PowerShell или напрямую в интегрированном терминале редактора, а он читает репозиторий, правит файлы, создаёт ветки и открывает pull request. Связка с GitHub нужна для полного цикла: от issue до PR с ревью, а не только для локальных правок. В России тут добавляется отдельная проблема: доступ к API модели блокируется по региону, и терминал упирается в таймауты. Ниже разбираем обе стороны: как связать Claude Code с GitHub и как провести трафик терминала через прокси в Windows, не ломая остальную сеть.

Если вы только начинаете, посмотрите базовую страницу про claude code и инструкцию claude code скачать. Про региональные ограничения отдельно написано в claude code в россии.

Два способа связать Claude Code и GitHub

Способов связки два, и они закрывают разные сценарии.

Первый: локальная работа через gh CLI и git. Claude Code запускается на вашей машине, работает с локальной копией репозитория, создаёт ветки, коммитит и открывает pull request через установленный GitHub CLI. Всё происходит в вашем терминале, интеграция на стороне GitHub не требуется, кроме авторизации gh auth login. Этот путь подходит, когда вы пишете код за своей машиной и хотите, чтобы модель помогала прямо в процессе.

Второй: GitHub Actions и приложение Claude в репозитории. Здесь Claude Code реагирует на события в самом GitHub: вы упоминаете @claude в issue или в комментарии к PR, срабатывает workflow, и модель выполняет задачу на раннере GitHub. Авто-ревью pull request, превращение issue в PR, ответы на вопросы по коду, всё это работает без вашего локального терминала. Ставится через команду /install-github-app, которая заводит нужное приложение и добавляет секрет с ключом API в настройки репозитория.

Какой способ нужен именно вам, зависит от задачи. Для парного программирования за своей машиной хватает локального gh. Для командного авто-ревью и автоматизации по событиям нужен GitHub Actions. Их можно использовать одновременно: локально Claude Code помогает писать код и открывать PR, а на стороне GitHub тот же PR автоматически получает ревью от @claude. Разница в том, где выполняется запрос к модели: в первом случае из вашего терминала на Windows, во втором из инфраструктуры GitHub. Именно от этого зависит, нужен ли вам прокси, и об этом ниже.

Локально: gh CLI, git и pull request

Минимальный набор для локальной работы: установленный git, GitHub CLI (gh) и сам Claude Code. После gh auth login терминал получает доступ к вашим репозиториям, и дальше Claude Code умеет создавать ветку, коммитить изменения и открывать pull request от вашего имени.

Проверить, что gh авторизован, можно командой gh auth status: она покажет аккаунт и активный протокол. Если вместо аккаунта выводится сообщение о том, что вы не залогинены, повторите gh auth login и выберите вход через браузер или через токен. Убедитесь, что git тоже видит ваши учётные данные, иначе git push будет спрашивать логин на каждом действии.

Типичный цикл выглядит так. Вы описываете задачу, Claude Code предлагает правки, создаёт ветку вида fix/login-timeout, вносит изменения, запускает тесты, если они есть, и открывает PR через gh pr create. Дальше вы смотрите diff и решаете, мержить или дорабатывать. Всё это идёт через ваш bash или PowerShell, поэтому важно, чтобы у процесса терминала был рабочий доступ к API модели.

Здесь и всплывает основная сложность на Windows из России: git до GitHub обычно ходит без проблем, а вот запросы Claude Code к API модели блокируются по региону. Терминал висит на таймауте, а вы не сразу понимаете, что дело не в коде и не в токене. Признак именно этой ситуации: git fetch и git push отрабатывают за секунды, а любой запрос к модели зависает и обрывается по времени.

GitHub Actions: авто-ревью и issue-to-PR

Workflow для Claude в GitHub Actions настраивается через /install-github-app. Команда пошагово проводит установку: заводит GitHub-приложение, запрашивает права на репозиторий, добавляет workflow-файл и кладёт секрет с ключом API в Secrets репозитория. После этого упоминание @claude в issue или в комментарии к pull request запускает action.

Workflow-файл появляется в репозитории по пути .github/workflows/, обычно с именем вроде claude.yml. В нём прописаны события, на которые реагирует action, и обращение к секрету с ключом. Секрет хранится в настройках репозитория, в разделе Settings → Secrets and variables → Actions, и в самом файле не светится, туда попадает только ссылка на его имя. Если после установки @claude не отвечает, первым делом проверьте, что секрет с ключом действительно добавлен и назван так же, как в workflow-файле.

Сценарии, которые это закрывает:

• Авто-ревью PR. По событию pull_request модель разбирает diff, оставляет комментарии по severity и предлагает правки. Первый авто-ревью обычно делают через @-упоминание в открытом PR, чтобы проверить, что workflow сработал.
• Issue в PR. Вы описываете задачу в issue, упоминаете @claude, и action создаёт ветку, вносит изменения и открывает pull request. Дальше он проходит обычный review.
• Ответы на вопросы по коду. Упоминание @claude в комментарии к коду даёт объяснение или предложение без ручного переключения контекста.

Важный момент про Actions: они выполняются на раннерах GitHub, а не на вашей машине. Значит, региональная блокировка API вас там не касается, запросы к модели уходят из инфраструктуры GitHub. Прокси нужен именно для локальной части: когда Claude Code запускается в вашем терминале на Windows. Проще говоря, для авто-ревью в облаке GitHub прокси не требуется, а для работы в терминале, требуется.

Почему на Windows трафик терминала тяжело развести

Windows не умеет разводить трафик по приложениям. Системный прокси в настройках сети либо применяется ко всему, либо игнорируется отдельными программами, а Claude Code в терминале может честно не читать эти настройки. Городить это через переменные окружения HTTP_PROXY в каждой сессии bash и PowerShell быстро надоедает и легко ломается: забыли переменную в одном окне, и запрос ушёл напрямую, мимо прокси.

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

Отдельная беда с QUIC. Многие клиенты по умолчанию пробуют HTTP/3 поверх UDP, а HTTP CONNECT-прокси такой трафик не пропускает. В итоге часть запросов уходит по UDP мимо прокси, а вы видите нестабильные обрывы без понятной причины.

Мы сделали Proxy Control как раз для этой задачи: развести трафик по приложениям на Windows так, чтобы терминал с Claude Code гарантированно шёл через прокси, а всё остальное осталось как было.

Как это решает Proxy Control

Программа поднимает виртуальный сетевой адаптер (TUN) на sing-box, забирает в него весь трафик машины и раздаёт по правилам, привязанным к имени процесса. Каналов четыре:

Канал	Куда идёт трафик	Типичные приложения
Дом	Обычный интернет провайдера	Системные службы, локальные утилиты
VPN	Через ваш узел VPN	Браузер, мессенджеры
Прокси	Через HTTP CONNECT	Claude, Cursor, node
Блок	Соединение отклоняется	Телеметрия, нежелательное

Claude всегда идёт через прокси, и канал у него сменить нельзя. Это защита от ситуации, когда процесс модели случайно ушёл бы домой или в VPN и упёрся в блокировку. Для процесса node, через который часто работает терминал и инструменты вокруг Claude Code, вы назначаете канал вручную.

Неизвестное блокируется. Когда в системе появляется новый процесс, которому канал ещё не назначен, он встаёт в список со статусом «ожидает» и в интернет не выходит, пока вы не распределите его руками. Это сделано намеренно: лучше явный отказ, чем незаметная утечка мимо прокси.

Для приложений на прокси заблокированы UDP и IPv6, иначе QUIC ушёл бы мимо HTTP-прокси. DNS работает по DoH, чтобы провайдер не видел домены, которые вы запрашиваете. Это снимает как раз ту проблему с HTTP/3, из-за которой запросы терминала обрывались.

Что происходит при отказе канала

Режим fail-closed. Если прокси недоступен, Claude и прокси-приложения уходят в блок, а не домой. Если узел VPN мёртв, то же самое для VPN-приложений. Продукт скорее откажет в соединении, чем незаметно выпустит трафик не туда, где вы ожидаете его увидеть.

Пока туннель пересобирается (например, при смене правил), ставится блокирующее правило брандмауэра. Трафик в этот момент не уходит мимо маршрутов, а встаёт на несколько секунд. Для терминала это значит короткую паузу, а не тихую утечку запроса в обычную сеть.

Чтобы проверить, что всё идёт как задумано, есть три собственные пробы: копии curl, прибитые к каналам. Они запрашивают внешний IP и показывают три разных адреса. Если IP канала совпал с домашним, программа прямо пишет про утечку, а не красит статус в зелёный. Плюс живая сверка через локальный API sing-box: видно, каким каналом идёт каждый процесс на самом деле, а не что записано в конфиге. Для Claude Code это удобно: вы наглядно убеждаетесь, что процесс терминала реально ушёл в прокси.

Установка и запуск

Установка простая: распаковать архив и запустить Install.bat. Python и sing-box лежат внутри, интернет при установке не нужен, ставить заранее ничего не требуется. Ключ вида CPC-XXXXXX-XXXXXX, один ключ на один компьютер: по нему программа получает срок действия и персональные реквизиты прокси.

Туннель поднимается сам при запуске программы, старт проходит 15 шагов с проверками. Если один из шагов не прошёл, программа останавливается на нём и показывает, что именно не сработало, а не запускается наполовину. После того как вы сменили канал у приложения, нужно нажать «Применить маршруты»: показывается подтверждение с отсчётом 10 секунд, Claude переживает эту паузу и восстанавливается сам.

Порядок первого запуска обычно такой: запустили программу, дождались, что туннель поднялся, нашли в списке процесс терминала или node, назначили ему канал «Прокси», нажали «Применить маршруты». После этого запускаете Claude Code в терминале и убеждаетесь по пробам, что процесс ушёл на прокси-адрес.

Удаление через Uninstall.bat: снимает туннель, правило брандмауэра, задания планировщика, ярлык и папку продукта. Лицензия при этом остаётся привязанной к компьютеру.

Частые вопросы и ошибки

Claude Code висит на таймауте, хотя git push работает. Это типичная картина региональной блокировки. git до GitHub идёт свободно, а запросы к API модели упираются в блок. Разведите процесс терминала на канал прокси, тогда запросы модели пойдут правильным путём. Подробнее про API написано на странице claude code api.

Часть запросов обрывается без причины. Скорее всего клиент пробует QUIC поверх UDP, а HTTP-прокси такой трафик не пропускает. У прокси-приложений UDP и IPv6 заблокированы намеренно, чтобы этого не было. Если вы настраивали прокси вручную через переменные окружения, проверьте, что HTTP/3 отключён.

Новый инструмент не выходит в сеть. Так и должно быть, пока вы не назначили ему канал. Найдите процесс в списке со статусом «ожидает» и переведите его на нужный канал, после чего нажмите «Применить маршруты».

После смены канала Claude Code отвалился на пару секунд. Это ожидаемо: при нажатии «Применить маршруты» туннель пересобирается, и на время отсчёта стоит блокирующее правило. Ждать переустановки не нужно, соединение восстановится само.

Нужен ли GitHub Actions, если я работаю только локально. Нет. Для локального цикла с gh, ветками и pull request достаточно установленного CLI и рабочего доступа к API. Actions нужны для авто-ревью и автоматизации по событиям в репозитории.

Как работать из редактора. Если вы вызываете Claude Code из интегрированного терминала VS Code, логика та же: канал назначается процессу терминала. Про связку с редактором есть отдельная страница vs code claude.

Сроки и тарифы разобраны на странице claude code подписка. Подписка на Proxy Control: 495 ₽/мес помесячно, от 395 ₽/мес при оплате за год, есть тарифы на 2, 3, 6 и 12 месяцев. Регистрация через почту или бота, поддержка в Telegram.