Claude на Linux через свой сервер

MAATRIX

Официального десктопного приложения Claude под Linux у Anthropic нет — ни .deb, ни .rpm, ни flatpak с их стороны не публикуется, и это не забытая функция, а осознанный выбор: под Linux компания делает ставку на веб-версию claude.ai. Из России этот сайт с большинства провайдеров либо не открывается, либо виснет на экране входа. Решение то же, что и для любого другого сервиса с гео-ограничением — собственный WireGuard-сервер, поднятый под вашим IP и подключённый на уровне всей системы, а не одной вкладки. Разберём установку штатными пакетами дистрибутива, автозапуск через systemd и главную ловушку для Linux-десктопа — DNS, который может резолвиться в обход туннеля даже при поднятом соединении.

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

Раз официального клиента нет, весь трафик к Claude идёт через обычный браузер — Firefox, Chrome, Brave или их производные. Это одновременно и проще, и коварнее, чем с нативным приложением. Проще — потому что не нужно разбираться с кэшем сессии отдельного процесса, как это бывает у десктопных Electron-клиентов других сервисов. Коварнее — потому что современные браузеры на Linux всё активнее используют DNS over HTTPS (DoH): резолвинг имён уходит напрямую на захардкоженный сервер по HTTPS, минуя системные настройки сети. IP-пакеты после этого честно идут через WireGuard, а вот запрос «какой у claude.ai IP» может уйти по старому пути — и Anthropic определит регион по нему, а не по IP самого соединения.

Браузерное расширение-прокси эту проблему не решает вовсе: оно туннелирует трафик только своей вкладки, а DoH в браузере как был отдельным механизмом, так и остаётся. Публичные VPN-подписки с общим IP снимают вопрос региона, но добавляют другой — общий адрес на тысячи пользователей регулярно попадает в списки, которые Anthropic банит централизованно, и вы наследуете чужую репутацию адреса. Персональный IP на собственном сервере плюс туннель, поднятый для всей системы, закрывают оба риска сразу.

Установка WireGuard: пакеты для apt и dnf

Клиентская часть ставится теми же командами, что и серверная, — разница только в конфиге. На Debian, Ubuntu и производных:

sudo apt update
sudo apt install -y wireguard wireguard-tools

На Fedora, AlmaLinux, RHEL и других RPM-дистрибутивах:

sudo dnf install -y wireguard-tools

Начиная с ядра 5.6 модуль WireGuard встроен в сам Linux-ядро, поэтому на актуальных Ubuntu 22.04+, Debian 12, Fedora и AlmaLinux 9 отдельно собирать wireguard-dkms не нужно — достаточно wireguard-tools, которые дают утилиты wg и wg-quick. Проверить, что модуль виден системе:

sudo modprobe wireguard && echo OK
lsmod | grep wireguard

Если modprobe ругается на отсутствие модуля — ядро либо слишком старое, либо собрано без него (характерно для некоторых минималистичных сборок и части VPS-образов с урезанным ядром), и тогда придётся ставить wireguard-dkms отдельно и пересобирать модуль под текущий kernel.

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

Клиентский конфиг и первый запуск через wg-quick

Сгенерируйте пару ключей на клиенте:

wg genkey | tee client_private.key | wg pubkey > client_public.key

Добавьте публичный ключ клиента как peer в конфиг сервера (/etc/wireguard/wg0.conf на VPS):

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

и перезапустите интерфейс на сервере: sudo wg-quick down wg0 && sudo wg-quick up wg0.

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

sudo install -m 600 /dev/null /etc/wireguard/wg0.conf
sudo nano /etc/wireguard/wg0.conf

Содержимое:

[Interface]
PrivateKey = <client_private.key>
Address = 10.40.0.2/24
DNS = 10.40.0.1

[Peer]
PublicKey = <публичный ключ сервера>
Endpoint = <IP_сервера>:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0, ::/0 заворачивает в туннель весь трафик машины, а не только диапазоны Anthropic — список их адресов не публикуется и периодически меняется, так что перечислять подсети вручную не имеет смысла. PersistentKeepalive = 25 не даёт соединению «засыпать» за NAT на время простоя, что особенно заметно на ноутбуках после сна.

Поднимаем и проверяем:

sudo wg-quick up wg0
wg show wg0 latest-handshakes
curl -4 ifconfig.me

Время последнего handshake должно быть свежим (не более пары минут назад), а curl — вернуть IP сервера, а не домашний адрес. Если возвращается прежний IP, скорее всего в таблице маршрутов остался более специфичный маршрут по умолчанию, перебивающий тот, что добавил wg-quick — проверьте это командой ip route.

Автозапуск: systemd-юнит wg-quick@

Поднимать туннель вручную после каждой перезагрузки — то, что забывается быстро, а Claude в браузере в этот момент просто открывается напрямую, без каких-либо предупреждений о падении VPN. Пакет wireguard-tools ставит шаблонный systemd-юнит wg-quick@.service, который включается по имени конфига:

sudo systemctl enable --now wg-quick@wg0
systemctl status wg-quick@wg0

На настольных дистрибутивах с NetworkManager юнит иногда стартует раньше, чем поднимается сама сеть — тогда на этапе загрузки он падает с ошибкой «network is unreachable». Лечится добавлением зависимости от network-online.target:

sudo systemctl edit wg-quick@wg0

В открывшемся override-файле:

[Unit]
After=network-online.target
Wants=network-online.target

Дальше sudo systemctl daemon-reload и sudo systemctl restart wg-quick@wg0. Журнал загрузки для диагностики:

journalctl -u wg-quick@wg0 -b --no-pager

Для ноутбука, где туннель нужен не постоянно, автозапуск можно и не включать, ограничившись коротким алиасом alias vpnup='sudo wg-quick up wg0' в ~/.bashrc или ~/.zshrc — но тогда придётся не забывать поднимать его перед каждым визитом на claude.ai вручную.

Claude в браузере на Linux: нюансы без официального приложения

Раз клиента нет, всё сводится к обычной вкладке, и здесь есть пара практических моментов. Во-первых, если в браузере уже стоит расширение вроде VPN-прокси или смены геолокации для других задач, отключите или удалите его на время работы через системный туннель — расширение может подменять заголовки или сам DNS-запрос параллельно с WireGuard, и итоговая картина для Anthropic получится противоречивой: часть сигналов укажет на сервер, часть — на исходную сеть.

Во-вторых, если вы заходите в Claude из разных браузерных профилей или из контейнеров Firefox (Multi-Account Containers), помните, что туннель WireGuard работает на уровне всей ОС и одинаков для всех профилей — разделение тут не сетевое, а только по cookies и локальному хранилищу сессии.

В-третьих, неофициальные обёртки claude.ai в Electron или nativefier, которые иногда ставят на Linux вместо полноценного приложения, — это просто браузер в отдельном окне, использующий тот же Chromium-движок и ту же сетевую логику. Никакой отдельной настройки для них не требуется, но и отдельного преимущества перед обычной вкладкой они не дают.

Проверка DNS: резолвится ли claude.ai через туннель

Это ключевая проверка именно для десктопного Linux, и её обычно пропускают. Если у вас systemd-resolved (Ubuntu, Fedora, большинство современных дистрибутивов), посмотрите, какой интерфейс отвечает за резолвинг после поднятия wg0:

resolvectl status wg0
resolvectl query claude.ai

Во втором выводе должна быть строка вида -- link: wg0 — она подтверждает, что запрос ушёл через туннель, а не через DNS провайдера. Если резолвер выбрал другой интерфейс, закрепите все домены за wg0 явно:

sudo resolvectl domain wg0 "~."

Это делает wg0 резолвером по умолчанию на всё время, пока интерфейс активен, и снимает конфликт с другими сетевыми адаптерами.

На системах без systemd-resolved проверяйте напрямую /etc/resolv.conf — после wg-quick up он должен указывать на DNS-сервер из строки DNS = в конфиге. Если этого не произошло, wg-quick не смог переписать файл — типично, когда сетью параллельно управляет NetworkManager и перезаписывает файл обратно при каждом событии сети.

Отдельный источник утечки — DoH внутри самого браузера, работающий независимо от системного резолвера. В Firefox отключается в about:preferences#privacy → «DNS через HTTPS»; в Chrome и Chromium-производных — chrome://settings/security → «Использовать безопасный DNS». После изменения настройки закройте вкладку с claude.ai полностью и откройте заново: уже установленные соединения браузер на лету не переоткрывает. Финальный чек — открыть в том же браузере сервис вроде dnsleaktest.com и убедиться, что и IP, и DNS-сервер показывают страну вашего VPS, а не домашнего провайдера.

Если после всех шагов Claude всё ещё показывает ошибку доступа, а сеть при этом настроена верно, стоит свериться со статьёй про типичные ошибки WireGuard и их решения — там разобраны случаи, когда причина не в клиенте, а в самом сервере или файрволе провайдера.

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