Cloudflare WARP на сервере: установка и настройка

MAATRIX

Cloudflare WARP на десктопе — это просто «включил и забыл». На сервере всё иначе: если поставить клиент по умолчанию, он перехватит весь исходящий трафик и оборвёт вам SSH-сессию через пять секунд. При этом WARP на VPS — рабочий инструмент: он умеет заворачивать только нужные запросы через сеть Cloudflare, менять исходящий IP и открывать доступ к ресурсам, защищённым Cloudflare Access. Разберём, как поставить warp-cli, не потерять доступ к серверу и выбрать правильный режим работы.

Зачем WARP нужен именно на сервере

WARP — это клиент, который заворачивает трафик в сеть Cloudflare через протокол на основе WireGuard. На пользовательском устройстве смысл обычно в приватности и ускорении до анкаст-сети Cloudflare. На сервере задачи другие:

• Доступ к ресурсам за Cloudflare Access / Zero Trust. Если внутренний сервис (админка, API, self-hosted инструмент) закрыт политикой Zero Trust и пускает только клиентов с активным WARP-туннелем, серверу-потребителю тоже нужен зарегистрированный клиент — иначе он просто получит блок на уровне edge.
• Смена исходящего IP для конкретных запросов. Скрипт или демон на сервере может ходить наружу через IP из диапазонов Cloudflare, а не через «голый» IP хостинг-провайдера — полезно, когда целевой сервис по-разному относится к datacenter IP и к IP крупных CDN-сетей.
• Проверка того, как ваш собственный сайт или API выглядит из сети Cloudflare — например, если вы отлаживаете правила Cloudflare Access или WAF и хотите воспроизвести запрос «как от клиента с WARP».

Важно понимать ограничение: WARP — это не резидентный IP и не гарантия обхода антифрод-систем. Диапазоны Cloudflare хорошо известны, и часть сервисов их либо не различает, либо, наоборот, помечает как «известный CDN/прокси». Если задача — именно резидентный IP, почитайте отдельно про резидентный IP против обычного IP сервера — это принципиально другой инструмент.

Установка warp-cli на Ubuntu/Debian

Официальный пакет ставится из репозитория Cloudflare. На Ubuntu 24.04 / Debian 12:

curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list

sudo apt update
sudo apt install cloudflare-warp

Пакет ставит два компонента: фоновый сервис warp-svc (systemd-юнит) и утилиту командной строки warp-cli, через которую вы им управляете. Проверьте, что служба поднялась:

sudo systemctl status warp-svc

На RHEL-подобных дистрибутивах (AlmaLinux, Rocky) репозиторий и пакет называются так же, но подключаются через yum-config-manager — если у вас именно такой сервер, свериться стоит с актуальной страницей pkg.cloudflareclient.com, потому что имена репозиториев Cloudflare время от времени меняет.

Регистрация и первый запуск

Прежде чем что-либо заворачивать, клиент нужно зарегистрировать — это создаёт локальный ключ устройства и привязывает его к аккаунту (или к организации, если вы используете Zero Trust):

warp-cli registration new

Для обычного бесплатного WARP этого достаточно. Если сервер должен присоединиться к корпоративной сети Zero Trust (например, чтобы получить доступ к внутренним сервисам через Access), регистрация идёт по лицензионному ключу команды:

warp-cli registration license XXXXXXXX-XXXXXXXX-XXXXXXXX

Ключ выдаётся в дашборде Cloudflare Zero Trust в разделе управления устройствами. После регистрации проверьте статус:

warp-cli status
warp-cli account

Пока не подключайтесь командой connect вслепую на удалённом сервере — сначала разберитесь с режимом работы в следующем разделе, иначе рискуете отрезать себе SSH.

Режим Proxy vs режим WARP: что выбрать для сервера

У клиента несколько режимов, которые переключаются командой:

warp-cli mode <режим>

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

warp-cli mode proxy
warp-cli connect

Если вам всё же нужен полный туннель warp (например, чтобы вообще весь трафик сервера шёл через Cloudflare) — сначала откройте вторую сессию доступа к серверу помимо SSH: консоль провайдера (VNC/serial console) или отдельный туннель, не зависящий от смены маршрута. На бесплатном клиенте гибкого split-tunneling (исключений по IP/порту) нет — эта возможность доступна только в организации Zero Trust с настроенными политиками устройства. Без неё warp — это всё-или-ничего, и на удалённом сервере без запасного канала входа это реальный риск заблокировать себе доступ.

Настройка Proxy-режима: порт и проверка

По умолчанию SOCKS5-прокси слушает 127.0.0.1:40000. Порт можно посмотреть и поменять:

warp-cli settings
warp-cli proxy port 40000

Проверить, что прокси действительно поднят и трафик идёт через Cloudflare:

curl -x socks5h://127.0.0.1:40000 https://www.cloudflare.com/cdn-cgi/trace/

В ответе смотрите на строки warp=on и ip= — второй должен показывать адрес из диапазона Cloudflare, а не IP вашего хостинга. Для сравнения выполните тот же запрос без -x, чтобы увидеть «обычный» исходящий IP сервера, и держите под рукой проверку IP и страны после туннеля — методика та же, просто источник трафика другой.

Дальше прокси нужно указать конкретному приложению или скрипту — WARP сам по себе ничего не заворачивает, пока вы явно не направите через него запрос. Для curl это флаг -x, для Python — requests с параметром proxies, для systemd-сервиса — переменные окружения HTTPS_PROXY/ALL_PROXY в юните:

[Service]
Environment=HTTPS_PROXY=socks5h://127.0.0.1:40000
Environment=ALL_PROXY=socks5h://127.0.0.1:40000

Так вы заворачиваете через WARP ровно один процесс, не трогая остальной сервер — это и есть основной сценарий использования на VPS.

Доступ к ресурсам за Cloudflare Access и смена исходящего IP

Если внутренний сервис закрыт политикой Cloudflare Access и требует, чтобы клиент был участником вашей WARP-сети (Zero Trust, режим «WARP-to-WARP» или правило доступа по факту наличия туннеля), одного SOCKS5-прокси может быть недостаточно — нужен полноценный туннель именно в режиме warp или warp+doh, зарегистрированный по лицензии организации. В этом случае сервер физически становится узлом вашей корпоративной сети, и Access видит его как «доверенное устройство».

Для более лёгкого сценария — просто дать сервису запрос с IP из сети Cloudflare, чтобы обойти geo-ограничение или блокировку по диапазону датацентра — обычно достаточно proxy-режима и точечного проксирования нужного запроса. Учитывайте два нюанса, о которых честно стоит сказать сразу:

• IP, который вы получите через WARP, — общий для множества клиентов Cloudflare, а не выделенный лично вам. Он может попасть под рейт-лимит или репутационный блок из-за чужой активности — это не находится под вашим контролем.
• Некоторые сервисы отдельно распознают трафик из известных облачных/CDN-диапазонов (в том числе Cloudflare) и применяют к нему более строгие правила, а не более мягкие. WARP тут не «серебряная пуля», а один из инструментов — иногда он помогает, иногда нет, и заранее это не всегда предсказуемо.

Если задача шире, чем разовые запросы — например, нужен постоянный туннель между офисом и сервером или проброс внутреннего сервиса наружу без открытия портов, — это уже область Cloudflare Tunnel, а не WARP-клиента. Разница в направлении: WARP заворачивает исходящий трафик сервера наружу, Cloudflare Tunnel публикует ваш внутренний сервис наружу без входящих правил файрвола. Установка описана в статье как установить и настроить Cloudflare Tunnel на VPS, а частые проблемы с ним разобраны отдельно в материале про ошибки Cloudflare Tunnel на сервере.

Автозапуск, диагностика и типичные проблемы

Служба warp-svc устанавливается как systemd-юнит и по умолчанию стартует при загрузке сервера. После настройки режима и подключения проверьте автозапуск явно:

sudo systemctl enable --now warp-svc

Сама команда connect сохраняет состояние — при перезагрузке демон снова поднимет туннель/прокси в том режиме, который был выставлен последним. Если после ребута прокси не отвечает:

warp-cli status
journalctl -u warp-svc -n 100 --no-pager

Частые причины проблем на серверах:

• Клиент завис в состоянии регистрации. Помогает warp-cli registration delete с последующей повторной регистрацией — состояние иногда портится после смены IP хостинга или после клонирования диска с уже зарегистрированным клиентом (у клона должен быть свой ключ устройства, а не унаследованный).
• connect есть, а curl через прокси не идёт. Почти всегда — не совпадает порт: проверьте warp-cli settings и то, какой порт реально слушает ss -tlnp | grep warp.
• После смены режима с warp на proxy (или обратно) трафик не переключается сразу. Клиенту иногда нужно явное warp-cli disconnect && warp-cli connect — просто смена режима на лету применяется не всегда чисто.
• Заблокировали себе SSH после warp-cli mode warp. Это тот самый риск полного туннеля без исключений. Восстанавливать доступ придётся через консоль провайдера (VNC/serial), заходить локально и переключать режим обратно на proxy.

Для базового мониторинга состояния подключения подойдёт тот же принцип, что и для любого туннеля: опрашивайте статус процесса и делайте контрольный запрос через прокси по расписанию, фиксируя момент, когда warp=on в ответе cdn-cgi/trace пропадает.

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