Cloudflare расширил сетевые возможности Workers: теперь функция connect() работает и через VPC Networks, то есть edge-приложения могут открывать TCP-соединения к приватным сервисам внутри инфраструктуры компании. Для разработчиков это практичная новость: меньше промежуточных шлюзов, короче путь до Redis, MQTT, Memcached и других внутренних систем.
Но здесь есть важная поправка. Речь не о входящих TCP-соединениях в сами Workers. Платформа умеет открывать исходящие TCP-сокеты, а не принимать произвольные TCP-подключения напрямую в Worker.
Что именно Cloudflare добавил в Workers
Функция connect() появилась в Workers еще в мае 2023 года как API для исходящих TCP-соединений. В июне 2026 года Cloudflare расширил ее: теперь через VPC Networks Worker может подключаться не только к публичным адресам, но и к приватным сервисам, доступным через Cloudflare Tunnel, Mesh или WAN on-ramp.
На практике это означает, что Worker на краю сети может сходить по TCP к внутреннему Redis, очереди сообщений или собственному бинарному протоколу без отдельного HTTP-обвеса. Для команд, которые строят внутренние платформы, API-шлюзы или интеграции между облаком и on-premise, это полезнее любого красивого пресс-релиза.
При этом текущее ограничение сохраняется: через VPC Networks поддерживается именно обычный TCP. В документации Cloudflare прямо указано, что для этого сценария сейчас речь идет о plaintext TCP, без отдельного TLS-слоя на самом connect() внутри VPC-связки.
gRPC работает, но это отдельная история
Поддержка gRPC у Cloudflare действительно есть, но она относится не к «магическому» преобразованию TCP внутри Workers. Cloudflare позволяет проксировать gRPC-трафик на своих проксируемых endpoint'ах, если сервис работает по HTTP/2 и TLS, а сам gRPC включен в настройках зоны.
Иными словами, смешивать эти две функции в одну не стоит. connect() в Workers решает задачу исходящих TCP-подключений, в том числе к приватной инфраструктуре. gRPC в Cloudflare решает другую задачу: проксирование и защита API, которые уже говорят на gRPC поверх HTTP/2.
Из-за этого формулировка про то, что Workers «обрабатывают unary и server-streaming gRPC API, автоматически конвертируя запросы», звучит слишком смело и в текущем виде не подтверждается документацией. Если писать аккуратно, то корректнее говорить так: Cloudflare поддерживает gRPC на уровне своей сетевой платформы, а Workers расширяют сценарии интеграции с TCP-сервисами.
Значение для рынка
Для русскоязычной ИТ-аудитории смысл простой: Cloudflare делает Workers ближе к роли полноценного glue-кода между edge, приватной сетью и внутренними сервисами. Стартапам это сокращает число прослоек и время запуска, корпорациям дает более внятный путь к гибридной архитектуре, а интеграторам и МСБ позволяет собирать быстрые сервисы без отдельного парка промежуточных прокси.
Если у команды уже есть внутренние TCP-сервисы и желание вынести часть логики на edge, новость полезная. Если нужен именно «входящий TCP в Worker», такого обещания Cloudflare пока не дал в рабочем продукте.
Первоисточники: Cloudflare Workers VPC Changelog, Cloudflare Workers TCP sockets, Cloudflare gRPC connections, Cloudflare Blog: connect() for Workers.
Следующий логичный шаг для платформы — либо полноценная поддержка защищенных TCP-соединений внутри VPC-сценариев, либо более явная интеграция между Workers и gRPC-сервисами без лишней ручной обвязки.