Wood Chen
English

Cloudflare MCP 门户使用指南：合并远程工具、配置鉴权，以及让 AI 管理门户

0 评论7 阅读2.9k 字

多个远程 MCP 可以通过 Cloudflare MCP 门户合并成一个连接。客户端只配置门户地址，论坛、网站后台等服务仍在原来的服务器运行，门户负责转发、访问控制和工具管理。

这次已把基于 Discourse 内置 MCP 的论坛 MCP 和自建官网系统 MCP 接入同一个门户，并通过该入口分别验证了论坛登录身份和官网构建状态。下面整理配置方法、鉴权区别，以及使用 AI 管理门户的流程。示例域名和邮箱均为占位值。

门户究竟托管什么

门户托管的是统一访问入口，不是后端 MCP 程序。

AI 客户端
  └─ Cloudflare MCP 门户
       ├─ 论坛 MCP → 论坛
       └─ 自建官网系统 MCP → 网站内容管理

添加远程 MCP 时填写它已有的 HTTP URL。后端是否跑在 VPS、容器或 Workers 上，不由门户决定。把源码、Docker 镜像或一个 npx 命令填进门户，并不能让它自动在 Cloudflare 上运行。

如果目标是把 MCP 程序本身迁到 Cloudflare，需要另行部署适配 Workers 的服务，再将其接入门户。

哪些 MCP 能合并

现有服务 接入方式
自带远程 HTTP MCP 的论坛、网站后台 填写完整 MCP 端点并配置鉴权
提供远程 MCP 的第三方服务 检查其传输方式、OAuth 和回调要求后接入
自建 Streamable HTTP / SSE MCP 服务需能被门户访问，按其鉴权方式配置
只支持本地 stdio 的 MCP 不能直接添加，需要先转换成远程服务
只有 REST API、没有 MCP 的后台 需要 MCP 适配层，门户不会自动把 REST API 变成工具
只监听本机 localhost 的服务 不能直接作为云端门户的上游

例如，本地通过 npx @dokploy/mcp 启动的服务，即使调用的是远程 Dokploy 面板，MCP 进程本身仍在本地。这与后台已经提供 /mcp 的网站不同。

本次检查的 Dokploy 面板，/mcp 和 /api/mcp 都返回 404。官方独立 MCP 包的 HTTP 模式本地测试通过，但仍需要另行运行服务，因此没有加入门户。是否内置 MCP，应检查自己的版本和实际端点，不能只看软件名称。

鉴权分成两层

客户端登录门户

用户先通过 Cloudflare Access 登录门户。可用邮箱、身份提供商等规则限制访问范围。

桌面 MCP 客户端使用 Managed OAuth 获取访问凭据。这一步是登录门户，不是给 AI Cloudflare 账号管理权限。

门户和每个上游 MCP 都要配置对应的 Access 策略。只给门户配置 Allow，可能登录成功却看不到上游工具。

门户连接上游

上游有自己的鉴权要求，不能因为用户已经登录门户就省略。

上游鉴权 门户如何使用
Bearer Token 在服务器配置中保存 Token，门户调用时携带
自定义请求头 配置服务需要的静态鉴权头
OAuth 自动注册 上游支持 DCR 时，可自动注册客户端并授权
OAuth 手动注册 上游没有 DCR 时，预注册客户端，配置端点、Client ID 和回调
无鉴权 门户可连接，但原始上游地址仍可能被直接访问

本次自建官网系统 MCP 使用 Bearer Token，Token 配置在门户上，电脑不需要重复填写。论坛 MCP 使用 OAuth，登录门户后还要完成论坛授权。

门户入口受到 Access 保护，不代表原来的后端地址也被自动保护。谁能直连后端，仍由后端原有鉴权决定。不要为了方便接门户而移除后端鉴权。

论坛 MCP 的 OAuth 实际接法

这里的论坛系统使用 Discourse，接入的是论坛内置的远程 MCP 接口，不是在电脑上通过 npx 运行的独立 MCP 包。内置接口直接连接论坛，具体可用工具取决于当前 Discourse 版本、后台启用的能力，以及授权账号的权限。

本次使用的论坛内置 MCP 没有提供 DCR 注册端点，Cloudflare 的自动注册流程会失败。MCP URL 正确也可能出现“注册 MCP 服务器时出错”，应继续检查 OAuth 元数据，而不是反复换 URL。其他论坛服务是否支持 DCR，需要分别检查。

接入时使用论坛预注册客户端：

  1. 在论坛后台注册一个专用于门户的 OAuth 客户端。
  2. 添加门户实际使用的回调地址。
  3. Cloudflare 上游选择手动 OAuth，填写授权端点、Token 端点、Client ID 和 scopes。
  4. 保留 Require user auth，让用户通过客户端完成论坛授权。
  5. 登录后调用当前用户工具，确认实际绑定的账号。

本次 API 配置使用的回调是：

https://mcp.example.com/servers-callback

Cloudflare 还支持共享回调，不同配置路线实际使用的地址可能不同。应读取后台显示值或 API 返回的 effective redirect URI，按完整地址注册，不能照抄一个回调就默认适用于所有门户。

本次论坛要求 token_endpoint_auth_method: none，并且授权请求需要正确的 resource。Cloudflare 手动 OAuth API 又要求非空 client_secret，本次配置保留 none，以随机占位值满足该字段校验，随后实测授权和工具调用通过。这是已验证的特定组合，不是所有 OAuth 服务都适用的通用配置；真正需要密钥的服务必须使用其颁发的密钥。

手动 OAuth 需要用户授权上游。换电脑或客户端是否自动复用授权，本次没有验证，不承诺一次授权后所有设备永远免授权。也不要通过复制 OAuth Token 来同步登录。

客户端只添加一个连接

对于接受 mcpServers JSON 配置的客户端：

{
  "mcpServers": {
    "remote-mcp": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Codex 配置示例：

[mcp_servers.remote-mcp]
url = "https://mcp.example.com/mcp"

随后使用客户端的 OAuth 登录入口授权。URL 必须包含 /mcp，客户端也要支持远程 MCP 和对应的 OAuth 流程。

验证新连接后，再移除原来的直连，避免工具重复。若使用 CC Switch 等配置管理器，要同时检查它保存的 MCP 记录；只改客户端文件，旧配置可能再次被同步回来。

本次清理保留了 API 凭据留档，因为论坛定时任务和网站发布脚本仍可能使用 REST API。移除 MCP 连接不等于删除密钥文件、吊销全部授权或停止后端服务。

合并后工具怎么命名

普通模式下，门户工具可以带上游服务器前缀。以下使用通用示例：

forum-mcp_discourse_current_user_get
website-mcp_build_status

客户端还可能增加自己的连接名前缀。例如：

mcp__remote-mcp__forum-mcp_discourse_current_user_get
mcp__remote-mcp__website-mcp_build_status

这里的 forum-mcp 表示论坛 MCP，website-mcp 表示自建官网系统 MCP；它们是示例名称，不是要求所有服务使用相同名称。

名称以客户端实际加载结果为准。门户也支持工具别名、描述修改和启停，可以只暴露所需工具，不必修改后端源码。

怎么让 AI 修改门户配置

管理门户需要另一个连接：Cloudflare 官方 API MCP。

{
  "mcpServers": {
    "cloudflare-api": {
      "type": "http",
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

在客户端完成 Cloudflare OAuth 登录，选择账号及所需权限。AI 随后可以通过官方 MCP 查询 API 定义、读取现有资源，再调用 API 修改配置。官方 API MCP 使用 search / execute 模式，不需要把所有 Cloudflare API 都作为独立工具加载。

两种连接不要混淆：

  • cloudflare-api 用于管理 Cloudflare 资源，有能力修改 DNS、Access 等配置，具体取决于授权。
  • 自己的 remote-mcp 用于调用论坛、网站等业务工具。

可以给 AI 这样的任务：

先读取账号中的现有门户、DNS、Access 策略和上游服务器。将论坛 MCP 和自建官网系统 MCP 加入统一门户，入口使用 mcp.example.com，只允许 me@example.com。保留原有连接，修改前列出变更范围；完成后回读配置，分别调用两个只读工具验证。

涉及配置修改，要求 AI 先查当前 API schema，不猜字段；修改已有资源时先读取完整配置，保留其他字段。登录和上游授权需要由账号本人完成，不能让 AI 绕过授权。

用 API 创建门户还要单独创建代理 DNS 记录：

类型：CNAME
名称：mcp.example.com
目标：gateway.agents.cloudflare.com
Proxy：开启

不要覆盖已有用途的子域名，也不要为了测试临时设置 Everyone。测试应至少包括：正确用户能调用、未登录请求被拦截、上游身份正确，以及新连接正常后旧连接可以移除。

工具很多时可使用 Code Mode

只合并连接不会自动减少工具定义数量。工具很多时，门户可以启用 Code Mode，将上游工具集中到搜索和执行两个入口：

portal_codemode_search
portal_codemode_execute

AI 先搜索所需工具，再编写 JavaScript 调用，代码在隔离环境中执行。支持 opt-in 等策略，是否启用应结合客户端兼容性和实际模型表现测试。本次论坛与官网仍按普通工具模式验证，没有把 Code Mode 当成已测试功能。

自动任务如何鉴权

不方便弹浏览器的机器人可以使用 Access Service Token，但需要同时设置门户和各上游的 Service Auth 策略。

服务令牌不能代替用户完成上游 OAuth。要求每用户授权的上游不能直接给该类会话使用；支持此路线的上游需要关闭 Require user auth 并使用管理员凭据。手动 OAuth 上游要求每用户鉴权，不应强行改成共享管理员模式。

因此，“用户桌面登录”和“无人值守机器人调用”应分别设计，不能认为拿到一个门户地址就能通用。

优势与边界

统一入口减少的是连接配置的分散：增加一个上游时，可以在门户修改，不必给每台电脑复制一套服务端 Token。工具启停、访问策略和日志也可以集中管理。

OAuth 上游仍保留自身账号权限；用户换客户端后是否需要再次授权，要按实际流程验证。Skill 同步、连接配置同步和登录状态同步也不是同一件事。

门户多了一层请求转发，不能保证所有网络环境都更快或更稳定。后端掉线、Token 过期、工具 schema 不合法等问题，也不会因为接入门户自动消失。某些工具本身可以发帖、删除内容或修改服务器，门户登录成功不等于每次写操作都已获得用户确认。

本次已验证的结果是：论坛 MCP 与自建官网系统 MCP 共用一个门户，论坛当前用户返回预期身份，官网构建查询正常；无需额外部署一个聚合容器。只支持本地进程的 MCP 没有强行迁移，保留其原本的使用边界。

参考

  • Cloudflare MCP 门户：https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/
  • Managed OAuth：https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/managed-oauth/
  • Cloudflare 官方 API MCP：https://github.com/cloudflare/mcp
  • 门户 Service Token：https://developers.cloudflare.com/changelog/post/2026-06-26-mcp-portal-service-tokens/

配置流程按本次实测和官方说明整理；示例不包含 API Token、客户端密钥或实际访问邮箱。

原文发布于 SunAI 论坛。

AIcloudflareMCP

最后更新于 2026-10-09

相关文章

评论 0