С 22 октября 2026 года продуктовые серверы Cloudflare MCP перестали отвечать по привычным ссылкам с окончанием /sse. Если вы подключали к своему ИИ-помощнику или редактору кода поиск по документации Cloudflare, управление контейнерами или облачный браузер, старый адрес теперь выдаёт ошибку 410 Gone и разрывает связь. Чтобы вернуть доступ, в настройках клиента нужно заменить хвост ссылки на /mcp — например, указать docs.mcp.cloudflare.com/mcp. Однако одной правки текста в конфиге мало: если вы авторизовывались через старый адрес, сервер сбросит прежнее разрешение и потребует войти через браузер заново. Без перерыва продолжили работать только те подключения, которые уже смотрели на /mcp.
Для тех, кто только знакомится с такими инструментами, поясним устройство на простом примере. Стандарт MCP (Model Context Protocol) работает как переходник, через который языковая модель в редакторе сама обращается к внешним сервисам: ищет свежие справки или проверяет журналы ошибок без ручного копирования текста. Долгое время ссылки в экосистеме Cloudflare заканчивались на /sse — по названию старого способа передачи данных (Server-Sent Events) с удержанием открытого соединения.
Почему старая ссылка работала до октября и зачем её сломали без переадресации
Отключение 22 октября многих застало врасплох: старый адрес исправно отвечал всю осень, хотя о переезде предупреждали ещё летом. В июльском обновлении продуктовые серверы перевели на протокол Streamable HTTP с единой точкой входа /mcp. В августе на пути /sse закрыли старый транспорт для GET-запросов, но сам адрес оставили работать как запасную дверь для современных POST-команд. Поэтому обновлённые клиенты спокойно общались с сервером по старой ссылке, пока 22 октября в журнале изменений Cloudflare и релизе docs-ai-search 0.5.0 эту совместимость не убрали совсем.
Почему инженеры не включили тихую переадресацию со старого адреса на новый, как на обычных сайтах? В примечаниях к docs-ai-search 0.5.0 названа точная причина. При входе через браузер (протокол OAuth) программа сверяет паспорт безопасности ресурса с исходным адресом запроса. Если бы сервер молча перенаправил запрос с /sse на /mcp, клиент забраковал бы несовпадающие метаданные и выдал глухую ошибку авторизации, где новый адрес /mcp даже не упоминается. Зато жёсткий ответ 410 Gone в формате application/problem+json возвращается ещё до проверки пароля — и стандартные клиенты MCP сразу показывают правильную ссылку прямо в окне ошибки.
Почему после правки адреса приходится входить заново
Даже после замены последних букв адреса на /mcp старая сессия не продолжит работу. Модуль авторизации обновили до версии workers-oauth-provider 1.2.4 и привязали защищённый ресурс строго к пути /mcp. Все разрешения, выданные ранее для /sse или голого домена, при попытке обновить сеанс получают отказ invalid_grant. К тому же сервер не переносит прежнее согласие в браузере (проверка isConsentRemembered() не учитывает старые подтверждения), поэтому окно подтверждения прав откроется ещё раз.
Если вы подключаете сервер не через браузер, а по прямому ключу API Cloudflare, токен теперь тоже проверяется для ресурса /mcp. Заодно исправили путаницу в кодах ошибок: просроченный или неизвестный ключ (код 9109: Invalid access token) теперь получает честный ответ 401 invalid_token вместо прежнего 403 insufficient_scope, из-за которого пользователи зря искали недостающие права в настройках кабинета.
Разборы таких тихих изменений в рабочих инструментах и понятные инструкции по сборке автоматизаций мы регулярно выкладываем в телеграм-канале Ковчег.
На каких серверах сработает подсказка 410 и почему новая ссылка выдаёт ошибку в браузере
При ручной починке настроек легко попасть в две ловушки. Первая возникает, когда обновлённый адрес вроде docs.mcp.cloudflare.com/mcp вставляют в адресную строку браузера для проверки и видят ошибку 405 Method not allowed. Пугаться не нужно: сервер исправен, просто вкладка браузера шлёт запрос чтения страницы (GET), а точка /mcp принимает только рабочие команды POST от программы-клиента (на них сервер штатно отвечает кодом 200).
Вторая тонкость связана с тем, что разные адреса из обновлённого 22 октября каталога серверов Cloudflare и репозитория на GitHub ведут себя неодинаково:
- Действующие продуктовые серверы (docs, containers, browser, dex, casb, а также blog и demo-day) на пути /sse отдают код 410 Gone с точной ссылкой на /mcp.
- Десять устаревших узких серверов (radar, observability, bindings, ai-gateway, graphql, logs, builds, dns-analytics, auditlogs, autorag) тоже возвращают 410 Gone, но компания советует переходить с них на единый сервер API.
- Единый сервер API (mcp.cloudflare.com/mcp, заменяющий тысячи команд тремя функциями search(), execute() и docs()) и сервер документации агентов (agents.cloudflare.com/mcp) на запрос к /sse отвечают не подсказкой 410, а пустой ошибкой 404 Not Found.
Не стоит обманываться и пометкой в справке по транспорту MCP, где написано, что устаревший SSE можно временно сохранить ради старых клиентов. Этот совет относится только к разработчикам, которые пишут собственные серверы на конструкторе McpAgent. На готовых серверах самой Cloudflare путь /sse закрыт окончательно. А вы уже проверяли в настройках своего редактора, какие внешние серверы до сих пор подключены по старым ссылкам?
