Cursor через свой сервер: настройка доступа

MAATRIX

Если вы работаете из России, Cursor периодически «тупит»: автодополнение зависает на середине строки, чат обрывается на полуслове, а иногда редактор вовсе не может достучаться до серверов ИИ. Дело не в самом Cursor, а в маршруте до его бэкенда — пакеты идут через нестабильные публичные VPN-приложения или прокси, которые не рассчитаны на постоянные потоковые соединения. Решение прямое: поднять собственный сервер за границей и завести туннель на уровне операционной системы, чтобы Cursor, как и всё остальное на компьютере, просто не знал, что находится в другой сети.

Почему Cursor вообще требует отдельной настройки

Cursor — это форк VS Code на Electron, но большая часть его «магии» (автодополнение Tab, чат, индексация кодовой базы) происходит не локально, а через собственный бэкенд редактора. Запросы уходят на серверы Cursor и дальше — к моделям (Claude, GPT и другие, в зависимости от выбранного провайдера). У приложения нет отдельного богатого интерфейса для настройки прокси: оно наследует системные сетевые настройки и переменные окружения HTTP_PROXY/HTTPS_PROXY, а также http.proxy из настроек VS Code — но этого достаточно только для обычных HTTP-запросов.

Проблема в том, что Tab-автодополнение и стриминг чата держат постоянное соединение (по сути, длинный поток данных, обновляющийся построчно). Такие соединения гораздо чувствительнее к обрывам и джиттеру, чем разовый HTTP-запрос: один сброс пакета — и вместо подсказки вы видите крутящийся индикатор «Generating…», который либо зависает, либо откатывается. Простая подстановка прокси в настройках это не всегда решает — соединение всё равно periodически рвётся, потому что путь до сервера прокси сам по себе нестабилен.

Туннель на уровне системы: чем он лучше прокси в приложении

Прокси, прописанный внутри Cursor или через переменные окружения, работает только для части трафика редактора и требует, чтобы каждое приложение поддерживало прокси корректно — а Electron-приложения в этом плане капризны: часть модулей обращается к сети напрямую, минуя системные настройки.

Туннель на уровне ОС (VPN-подключение через WireGuard) решает это радикальнее: весь исходящий трафик машины, включая Cursor, браузер, терминал и прочие индексирующие процессы, идёт через один и тот же стабильный канал к вашему серверу и дальше в интернет с его IP-адреса. Никаких настроек прокси внутри приложений не требуется — с точки зрения Cursor вы просто находитесь в другой точке мира с хорошим и предсказуемым соединением.

Дополнительный плюс: тот же туннель разом чинит доступ и к другим сервисам — GitHub Copilot, npm-реестрам, Docker Hub и всему остальному, что периодически blocked или нестабильно из России. Это удобнее, чем городить отдельный прокси под каждый инструмент.

Выбираем и готовим сервер

Для WireGuard-туннеля не нужен мощный сервер — это не вычислительная нагрузка, а сетевой прокси. Хватает 1 vCPU и 1–2 ГБ RAM, но важнее не характеристики, а расположение: чем ближе сервер к дата-центрам, где физически стоит инфраструктура моделей и бэкенда Cursor, тем ниже и стабильнее будет задержка.

Перед арендой стоит явно проверить, какая локация даёт минимальный пинг лично для вас: маршруты из России до разных дата-центров США могут ощутимо отличаться. Ориентиры по реальным замерам — в статье про пинг и латентность из США: берите её как отправную точку, но обязательно перепроверьте на своём провайдере — цифры у каждого будут своими.

Поднимаем WireGuard на сервере

После аренды сервера и подключения по SSH ставим WireGuard и генерируем ключи:

apt update && apt install wireguard -y

# ключи сервера
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key

# ключи клиента (ноутбука)
wg genkey | tee /etc/wireguard/client_private.key | wg pubkey > /etc/wireguard/client_public.key

Конфиг сервера /etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <содержимое server_private.key>
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <содержимое client_public.key>
AllowedIPs = 10.10.0.2/32

Включаем форвардинг пакетов и firewall:

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

ufw allow 51820/udp
ufw allow OpenSSH

systemctl enable --now wg-quick@wg0

Проверить интерфейс: wg show должен показать активный wg0 без ошибок.

Настраиваем клиент и подключаем Cursor

На клиентской машине (там, где стоит Cursor) создаём файл wg0.conf:

[Interface]
PrivateKey = <содержимое client_private.key>
Address = 10.10.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <содержимое server_public.key>
Endpoint = <ip-вашего-сервера>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0 — это полный туннель: весь трафик машины уходит через сервер. Это самый надёжный вариант именно для Cursor, потому что не нужно вручную прописывать домены его бэкенда (они периодически меняются). Если вам важно, чтобы через сервер шёл только трафик отдельных приложений, а остальное — напрямую (сплит-туннель), это тоже возможно через более узкие AllowedIPs и policy-based routing, но это отдельная, более тонкая настройка, которая требует ручной работы с таблицами маршрутизации операционной системы.

Важный момент — не забудьте DNS = 1.1.1.1 (или любой другой публичный DNS) в клиентском конфиге: если DNS-запросы продолжат уходить через старый провайдерский резолвер, часть доменов Cursor может резолвиться некорректно, даже когда сам туннель уже поднят.

После wg-quick up wg0 (или подключения через GUI-клиент WireGuard) проверьте, что трафик действительно идёт через сервер:

curl ifconfig.me

IP должен совпадать с адресом вашего сервера. После этого просто перезапустите Cursor — никаких дополнительных настроек прокси внутри самого редактора не требуется.

Задержка решает: почему важна близость к провайдеру модели

Здесь и кроется главный нюанс всей схемы. Туннель убирает нестабильность маршрута, но не убирает физику: если сервер стоит далеко от инфраструктуры, куда обращается Cursor, добавляется лишний «крюк» — трафик сначала идёт до вашего сервера, а уже потом до бэкенда редактора и моделей. При нестабильном или просто долгом соединении на этом отрезке автодополнение может подтормаживать или обрываться на потоковой генерации, даже если сам туннель работает исправно.

Поэтому при выборе локации сервера ориентируйтесь не на «США вообще», а на минимальный измеренный пинг именно до нужных сервисов с вашего провайдера. Замерить легко:

ping api2.cursor.sh
mtr api2.cursor.sh

Если после подключения туннеля пинг заметно выше 150–200 мс и скачет — стоит попробовать другую локацию сервера или другого провайдера канала. Точных цифр «сколько именно должно быть» дать нельзя — это зависит от вашего домашнего интернета, времени суток и загрузки конкретного маршрута, поэтому воспринимайте любые цифры в статьях (включая эту) как ориентир, а не гарантию, и проверяйте сами через ping/mtr уже после развёртывания.

Continue + свой LiteLLM — честная альтернатива для гибкости

Если для вас важнее контроль над тем, какая модель отвечает за автодополнение и чат, а не проприетарные фичи Cursor (вроде глубокой индексации кодовой базы), стоит рассмотреть связку Continue — open-source расширение для VS Code — со своим LiteLLM-шлюзом на том же сервере.

В этом варианте вы вообще не поднимаете туннель на уровне системы: Continue напрямую обращается к вашему серверу как к OpenAI-совместимому API-эндпоинту, а LiteLLM на сервере уже сам маршрутизирует запросы к нужным моделям (Claude, GPT, локальным моделям — что угодно). Это честнее в плане прозрачности: вы видите весь путь запроса и полностью управляете тем, какая модель и с какими параметрами используется под капотом.

Минусы тоже есть: Continue не имеет доступа к части закрытых фич Cursor (например, его собственной модели для Tab-автодополнения, обученной именно на задаче предсказания следующего изменения), поэтому качество автодополнения может ощутимо отличаться. Если хочется попробовать этот путь — пошаговая установка LiteLLM на сервере и подключение Continue разобраны в статье про установку и настройку Continue на VPS.

Отдельно, если вы уже используете LiteLLM для других задач (не только для Continue), пригодится общая инструкция по установке LiteLLM на VPS — сервер под туннель и сервер под LiteLLM вполне можно совместить в одном.

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