GitHub Copilot через свой сервер: доступ из России

MAATRIX

GitHub Copilot то подключается, то виснет на «Sign in», то молча перестаёт предлагать автодополнения — и это не всегда про блокировки. Проблема часто в том, что Copilot живёт не в браузере, а внутри IDE, и стандартный «VPN-плагин для Chrome» ему попросту не виден. Разберёмся, как поднять доступ через собственный сервер так, чтобы он реально работал на уровне системы, а не только для сайтов.

Почему у Copilot всё иначе, чем у сайтов в браузере

Расширение Copilot для VS Code или плагин для JetBrains — это отдельный процесс, который сам открывает HTTPS-соединения к серверам GitHub (в первую очередь к api.githubcopilot.com и связанным доменам github.com, copilot-proxy.githubusercontent.com). Он не ходит через прокси вашего браузера и не видит его настроек. Если у вас включено расширение-VPN в Chrome, а IDE запущена отдельным процессом — для Copilot с точки зрения сети вообще ничего не изменилось.

Отсюда и типичная путаница: сайт github.com открывается нормально (сам GitHub для обычного просмотра доступен из России), а Copilot внутри редактора выдаёт ошибку авторизации или «GitHub Copilot could not connect to server». Дело не в блокировке github.com как такового, а в том, что IDE — отдельное сетевое приложение со своим стеком соединений, и ему нужен туннель на уровне операционной системы.

Почему нужен туннель именно на уровне системы

Есть два принципиально разных подхода:

• Прокси в браузере или расширение — трафик заворачивается только для вкладок браузера. IDE, терминал, git, Docker — всё это идёт напрямую и туннель не видит.
• VPN на уровне ОС (WireGuard, OpenVPN) — создаётся виртуальный сетевой интерфейс, через который проходит вообще весь трафик машины, включая VS Code, JetBrains, curl, git push и что угодно ещё.

Для Copilot годится только второй вариант. Причём важно, чтобы туннель был поднят и стабилен до того, как вы откроете IDE или хотя бы до первого запроса на автодополнение — иначе Copilot успевает получить ошибку соединения, закэшировать её и потом не пытается переподключиться сам, приходится перезапускать редактор.

Практическая проверка: если у вас уже настроен WireGuard на своём сервере (по шагам это описано в статье про установку WireGuard на VPS), просто убедитесь, что интерфейс wg0 поднят и активен ещё до запуска VS Code:

sudo wg show wg0
# должен показать handshake не старше 2-3 минут

Собственный сервер: что арендовать и как настроить

Для Copilot не нужен мощный сервер — это не GPU-инференс и не рендеринг видео, нагрузка минимальная (по сути постоянный поток небольших HTTPS-запросов). Достаточно младшего VPS в США или Великобритании с WireGuard на борту. Ключевое требование — стабильный аптайм и низкий джиттер, а не производительность CPU.

Минимальная настройка на сервере:

# на сервере (Ubuntu 24.04)
sudo apt install wireguard -y
wg genkey | tee server_private.key | wg pubkey > server_public.key

# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <server_private.key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.8.0.2/32

На клиенте (вашем ноутбуке) — обратная конфигурация, с AllowedIPs = 0.0.0.0/0, чтобы через туннель шёл весь трафик, а не только отдельные подсети. Именно полный туннель, а не split-tunnel на конкретные домены, снимает саму категорию проблем — не придётся вручную вылавливать, какие ещё поддомены GitHub задействует Copilot Chat или Copilot для тестов, а их за последний год стало заметно больше.

После подключения проверьте не только «есть ли интернет», а то, откуда вас видит сеть — этому посвящена отдельная статья как проверить IP и страну после туннеля. Заодно стоит проверить именно домен Copilot напрямую:

curl -I https://api.githubcopilot.com

Если ответ приходит быстро и без обрыва соединения — туннель работает так, как нужно IDE.

Настройка в VS Code и JetBrains

Если WireGuard поднят системно, отдельно ничего прописывать в VS Code обычно не нужно — расширение просто ходит через дефолтный сетевой стек ОС, а тот уже маршрутизирует всё через wg0. Но есть нюансы, из-за которых Copilot иногда «не видит» рабочий туннель:

• В VS Code проверьте параметр http.proxySupport в settings.json — если раньше стоял прокси через браузер или корпоративный прокси, лучше явно сбросить его на "override", чтобы IDE не пыталась одновременно использовать и старый прокси, и системный туннель:

{
  "http.proxySupport": "override",
  "http.proxy": ""
}

• В JetBrains IDE (IntelliJ IDEA, PyCharm, WebStorm) прокси настраивается отдельно от системного: Settings → Appearance & Behavior → System Settings → HTTP Proxy. Убедитесь, что там стоит «No proxy» — иначе IDE игнорирует системный интерфейс и тянет старые настройки.
• После смены сети (переподключение WireGuard, смена сервера) в обеих IDE надёжнее сделать Reload Window / перезапуск, чем ждать, пока Copilot сам заметит новый маршрут — на практике переподключение distinguishes «просто разрыв» от «сеть окончательно недоступна» и во втором случае перестаёт ретраить.

Нюанс с оплатой подписки

Тут отдельная засада, которую сервер сам по себе не решает: свой сервер в США даёт вам доступ к сети Copilot, но не даёт вам возможности оплатить подписку. GitHub Copilot Individual или Business оплачивается картой, привязанной к платёжному аккаунту GitHub, и российские карты Visa/Mastercard для международных платежей с 2022 года не работают — платёжные системы разорвали обслуживание таких карт за рубежом.

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

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

Это отдельная категория задач от аренды сервера, и полезно не путать одно с другим: сама аренда VPS у большинства провайдеров, включая MAATRIX, оплачивается из России картой или криптовалютой без проблем — тут ограничений нет. А вот именно за подписку Copilot платит GitHub, и требования у него свои.

Проверка и типичные ошибки

Если после настройки Copilot всё равно не работает, порядок диагностики такой:

1. Проверьте туннель отдельно от IDE — curl -I https://api.githubcopilot.com из терминала. Если curl тоже не отвечает, дело не в Copilot, а в сети целиком.
2. Проверьте, что DNS не «утекает» — иногда системный резолвер продолжает ходить к локальному DNS-провайдеру в обход туннеля, и домены GitHub резолвятся в адреса, до которых нет нормального маршрута. Пропишите DNS явно в конфиге WireGuard (DNS = 1.1.1.1 в секции [Interface] на клиенте).
3. Ошибка авторизации после смены IP — GitHub иногда просит повторный вход при резкой смене геолокации сессии. Это нормально при первом подключении через новый сервер, разово перелогиньтесь через GitHub: Sign In в командной палитре VS Code.
4. «Copilot is disabled» без явной причины — проверьте статус подписки на github.com/settings/copilot напрямую через тот же туннель: иногда причина не в сети, а в приостановленной оплате (см. пункт про карту выше).

Если после всех проверок доступ то появляется, то пропадает — обычно это нестабильность самого туннеля (пересборка соединения, потеря handshake), а не проблема на стороне GitHub. Стоит проверить логи WireGuard на сервере и, если разрывы частые, посмотреть общие причины в статье про WireGuard, который обрывает соединение.

Честная альтернатива: Continue со своим сервером

Если вас смущает зависимость от одной подписки, одного туннеля и одного провайдера одновременно — есть более гибкий путь. Continue — open-source расширение для VS Code и JetBrains с той же идеей автодополнения и чата по коду, но без привязки к конкретному поставщику модели и без отдельной подписки на сам инструмент.

Ключевая разница в том, куда именно уходят запросы:

Честно: Copilot заметно плотнее интегрирован с самим GitHub — работа с pull request'ами, issues, контекст репозитория у него встроены лучше. Continue выигрывает там, где важна независимость: можно развернуть прокси к Claude или OpenAI на собственном сервере (см. статьи про прокси к Claude и прокси к OpenAI) и не зависеть от того, работает ли конкретно домен api.githubcopilot.com сегодня. Для многих связка «свой сервер + Continue + API-ключ модели» оказывается проще в поддержке, чем постоянно следить за состоянием туннеля под одну конкретную подписку.

Частые вопросы