Темы



Сервисы Cloudflare для частных origin-серверов теперь доступны всем30.10.2026 17:23

Коротко сгенерировано ИИ по тексту статьи
  • Cloudflare открыла всем сервисы для приватных origin-серверов: проксируемая запись A или AAAA может указывать на частный IP, а трафик идёт через существующее подключение Cloudflare One.
  • Для приватных приложений доступны WAF, управление ботами, ограничение частоты запросов, кэширование, правила преобразования и переписывания, а также Workers; Argo Smart Routing и Aegis не поддерживаются.
  • Для запуска нужны право на Private Origins, подключение Cloudflare One и Unified Routing; открывать входящий трафик в межсетевом экране не требуется.

Почему это важно: Это позволяет внутренним API и другим приватным сервисам принимать запросы через интернет без публичного IP или открытого входящего порта и использовать средства защиты Cloudflare.

Сегодня сервисы Cloudflare для приватных origin-серверов стали общедоступны. Укажите в проксируемой DNS-записи частный IP-адрес, и Cloudflare будет подключаться к origin-серверу через существующее подключение Cloudflare One. Ваш origin-сервер останется приватным, а межсетевой экран веб-приложений (WAF), кэширование, управление ботами и Workers будут работать так же, как и для публичных origin-серверов.

В июне мы запустили эту возможность в закрытом бета-тестировании, чтобы решить проблему, о которой нам часто рассказывали клиенты: их внутренние API, бэкенды ИИ-агентов, MCP-серверы и операционные инструменты не были рассчитаны на доступ из интернета, но этим сервисам всё равно нужно принимать запросы от партнёров, клиентов или агентов через интернет. До запуска бета-версии, чтобы поставить Cloudflare перед такими сервисами, требовалось открыть публичный IP-адрес, разрешить входящий трафик на порту межсетевого экрана или запустить cloudflared рядом с origin-сервером.

Из-за этих требований приватные приложения часто оставались без тех же средств защиты и контроля, которые использовались для публичных приложений, включая WAF, управление ботами, ограничение частоты запросов, кэширование, ускорение трафика, правила переписывания и Workers.

Что стало общедоступно сегодня

Во время закрытого бета-тестирования подходящие клиенты запрашивали доступ через свою команду по работе с клиентами. Сегодня мы открываем доступ и для тех, кто не участвовал в бета-тестировании.

Укажите в проксируемой записи A или AAAA частный IP-адрес — и сервисы Cloudflare для приложений будут работать так же, как и с публичными origin-серверами:

  • WAF и управляемые правила
  • Управление ботами
  • Ограничение частоты запросов
  • Кэширование
  • Правила преобразования и переписывания
  • Workers

Некоторые ограничения сохраняются. Argo Smart Routing и Aegis не поддерживаются, а для проверок работоспособности origin-серверов требуется Load Balancing. Полный список действующих ограничений см. в документации для разработчиков.

Ваш origin-сервер сохраняет частный IP-адрес, и добавлять исключения для входящего трафика в межсетевой экран не нужно. Если вы используете Cloudflare WAN или Cloudflare Mesh, на origin-сервере также не потребуется запускать программный коннектор.

Как это работает

Создайте проксируемую запись A или AAAA, указывающую на ваш origin-сервер. Для поддерживаемых диапазонов частных IP-адресов параметр Использовать маршрутизацию через частную сеть включается автоматически. Если ваш origin-сервер использует публичный IP-адрес, доступный только через частную сеть, этот параметр можно включить вручную.

Остальная часть обработки запроса не меняется: завершение TLS-соединения, WAF, правила и кэширование по-прежнему работают в сети Cloudflare.

Этот параметр автоматически включается для частных IPv4-адресов RFC 1918, адресов CGNAT RFC 6598 (100.64.0.0/10) и локальных IPv6-адресов RFC 4193 (fc00::/7). Для этих диапазонов его нельзя отключить; попытка сделать это через API приведёт к ошибке.

Как выглядит API

Для клиентов, автоматизирующих развёртывание через API, маршрутизация через частную сеть — это просто дополнительный атрибут стандартной DNS-записи.

POST /zones/{zone_id}/dns_records
{
 "type": "A",
 "name": "app.example.com",
 "content": "10.0.0.50",
 "ttl": 300,
 "proxied": true,
 "private_routing": true
}

В фоновом режиме прокси-платформа Cloudflare определяет, куда направлять трафик для app.example.com, обращаясь к Origin API Cloudflare. Ответ содержит метаданные, указывающие, что подключение к адресу назначения должно проходить по частному сетевому маршруту: 

{
 "zone_name": "example.com",
 "ipv4_addresses": ["10.0.0.50"],
 "private_routing": true
}

Ключевой сигнал — флаг private_routing. Увидев его, наш прокси вместо попытки подключиться напрямую к частному IP-адресу через публичный интернет передаёт запрос уровню частных сетей. Тот направляет соединение по уже существующему подключению клиента к частной сети — будь то IPsec, GRE, Cloudflare Tunnel, CNI или Cloudflare Mesh.

В публикации о бета-версии подробнее описан уровень маршрутизации.

Начало работы

Для начала вам потребуется:

  1. Право на использование Private Origins в вашей учётной записи. Попросите свою команду по работе с клиентами включить его.
  2. Подключение Cloudflare One по IPsec, GRE, CNI, Cloudflare Tunnel или через Cloudflare Mesh.
  3. Включённая в вашей учётной записи Unified Routing. Новые и существующие учётные записи можно обновить через команду по работе с клиентами.
  4. Если вы подключаетесь через Cloudflare WAN или Cloudflare Mesh, в вашей учётной записи должна быть включена Unified Routing, а также настроен обратный маршрут для исходных диапазонов Cloudflare (100.64.0.0/12 для IPv4 и 2606:4700: cf1:5000::/64 для IPv6). Новые и существующие учётные записи можно перевести на Unified Routing через команду по работе с клиентами.

Затем создайте проксируемую запись A или AAAA для частного IP-адреса и убедитесь, что включён параметр Использовать маршрутизацию через частную сеть. Существующие настройки WAF, кэширования и управления ботами будут применяться к этому имени хоста без дополнительных изменений.

Примечание по итогам бета-тестирования: если запросы завершаются по тайм-ауту и не доходят до origin-сервера, сначала проверьте обратный маршрут. Самой распространённой проблемой при настройке было отсутствие маршрута для исходного диапазона Cloudflare.

После включения функции следуйте документации для разработчиков — в ней описан весь процесс настройки.

Что дальше

Сегодняшний релиз охватывает публичный трафик, направляемый к приватным origin-серверам. Следующий шаг — работа с трафиком между частными сетями: пользователи, сервисы и ИИ-агенты в одной частной сети смогут обращаться к приложениям в других частных сетях через сервисы Cloudflare для приложений.

Работа над решением уже идёт; закрытое бета-тестирование планируется начать в начале 2027 года. Если вы хотите принять в нём участие, свяжитесь со своей командой по работе с клиентами.

Наша цель — предоставить приватным приложениям те же средства защиты и контроля, что и публичным. Например, сотрудник, открывающий wiki.company.internal, сможет воспользоваться WAF, ограничением частоты запросов и управлением ботами. Эти средства можно будет использовать и для обмена данными между сервисами в облаках и центрах обработки данных, даже если ни одна из сторон не обращается к публичному интернету.

А пока сегодняшний релиз позволяет использовать WAF, кэширование, управление ботами и Workers для приватных origin-серверов через уже действующие у вас подключения — так же, как и для публичных приложений.

Есть вопросы или отзывы? Присоединяйтесь к обсуждению на  форумах сообщества или свяжитесь со своей командой по работе с клиентами.

© Cloudflare Blog