把 MCPHub 部署在 Homelab 上：统一管理 MCP 服务的实际体验

MCPHub 是什么#

MCPHub 不是一个新的业务 MCP Server，而是放在 MCP 客户端和多个上游 MCP Server 之间的一层管理与代理服务。

按照 MCPHub 官方文档，它可以集中管理多个 MCP Server，并支持 stdio、SSE、Streamable HTTP 和 OpenAPI 等接入方式。对下游客户端而言，MCPHub 暴露的是统一的 HTTP MCP 接口；对上游服务而言，它负责连接、转发和管理。

它提供的入口可以粗略理解为：

因此，MCPHub 更像 MCP 世界里的一个轻量网关：上游服务可以不断增加，下游设备只需要记住一个服务地址，具体接入哪些服务则由 MCPHub 统一管理。

为什么我把它放在 Homelab 上#

Homelab 通常是家庭网络中比较稳定、持续运行的设备。把 MCPHub 放在 Homelab （绿联4800 Plus，绿联应该给我广告费）上，它适合承担一个长期在线的内网服务角色：有固定地址、可以运行 Docker，也方便统一做反向代理、备份和监控。

我的使用方式可以抽象成这样：

1
各台设备上的 Agent
2
        |
3
        | 只配置 MCPHub 的一个 HTTP 地址
4
        v
5
Homelab 上的 MCPHub
6
        |
7
        | 连接并管理上游 MCP 服务
8
        +--> Linear
9
        +--> Cloudflare
10
        +--> Bytebase

这里最重要的变化是：MCP 的“连接配置”从每一台终端，移动到了一个集中管理的位置。

多台设备只配置一次#

我平时会在 MacBook Pro、Mac mini 和桌面台式机之间切换。如果没有 MCPHub，每个 MCP Server 通常都需要分别配置：

• MCP Server 的启动命令或远程 URL；
• npm、Python 或其他运行时依赖；
• 环境变量；
• 上游 API token；
• 不同客户端各自的 MCP 配置格式。

服务数量少的时候，这些配置还可以手动复制。真正麻烦的是后续维护：某个 Server 改了参数，需要每台设备同步；某个 token 轮换了，需要逐台修改；换了一台新电脑，又要重新查一遍文档和配置。

接入 MCPHub 后，终端侧只需要配置一个地址，例如：

1
{
2
  "mcpServers": {
3
    "mcphub": {
4
      "type": "streamable-http",
5
      "url": "https://mcp.example.com/mcp"
6
    }
7
  }
8
}

这个示例中的域名只是占位符。实际使用时，可以是 Homelab 在内网或 VPN 中可访问的地址，也可以通过反向代理提供 HTTPS。

之后添加 Linear、Cloudflare 或 Bytebase，不需要再修改每一台电脑上的 Agent 配置。新设备只要完成一次 MCPHub 连接配置，就可以获得已经开放给它的工具。

这带来的便利不是“少写几行 JSON”这么简单，而是把终端配置从“每个服务一份”收敛成了“一个网关地址一份”。设备越多、服务越多，这个差异越明显。

token 集中放在 MCPHub，Agent 不直接接触#

这是我使用 MCPHub 最看重的能力之一。

如果 Linear、Cloudflare、Bytebase 的 token 都写在本地 Agent 配置里，那么这些 token 至少会进入以下位置之一：本机配置文件、环境变量、客户端调试信息、备份文件，甚至某些自动化工具的上下文。Agent 不一定会恶意读取，但凭据进入终端以后，暴露面就扩大了。

更合理的链路是：

1
Agent -> MCPHub -> 上游 MCP Server -> Linear / Cloudflare / Bytebase
2
                         |
3
                         +-- 使用保存在 Homelab 侧的凭据

MCPHub 的配置支持通过环境变量引用敏感值，类似这样：

1
{
2
  "mcpServers": {
3
    "cloudflare": {
4
      "type": "streamable-http",
5
      "url": "https://upstream.example.com/mcp",
6
      "headers": {
7
        "Authorization": "Bearer ${CLOUDFLARE_TOKEN}"
8
      }
9
    }
10
  }
11
}

在正常代理链路中，Agent 只需要知道工具名称、参数 schema 和调用结果，不需要知道 CLOUDFLARE_TOKEN 的实际值。换句话说，模型可以提出“查询某个资源”这样的工具调用，但它不应该因此得到上游 HTTP 请求里使用的 token。

不过，这个边界不能被夸大成“token 绝对不会泄露”。至少还要注意：

• Homelab 上的 MCPHub 配置、环境变量和备份文件仍然需要保护；
• MCPHub 管理后台的管理员权限等同于高权限运维权限；
• 上游 MCP Server 不应把请求头、环境变量或敏感配置原样返回到工具结果；
• 日志、错误堆栈和调试输出不能包含 token；
• MCPHub 的访问认证、反向代理和网络入口不能裸奔在公网；
• token 轮换、撤销和最小权限仍然要在 Linear、Cloudflare、Bytebase 等上游系统中完成。

所以准确的说法是：把 token 放在 MCPHub，可以避免 token 被复制到每台终端和每个 Agent 配置中；但 MCPHub 本身仍然属于需要重点保护的凭据边界。

多个 MCP 聚合成一个地址#

如果每个 MCP 都单独暴露给 Agent，客户端配置可能会变成这样：

1
Linear MCP       -> 一个地址
2
Cloudflare MCP   -> 一个地址
3
Bytebase MCP     -> 一个地址
4
其他 MCP         -> 继续增加地址

服务数量继续增加后，会出现两个问题。

第一，客户端配置会越来越长。第二，模型一次性看到的工具数量会越来越多，工具描述、参数和相似名称都会占用上下文，也增加了选错工具的机会。

MCPHub 可以把这些服务聚合到一个统一入口，也可以按照使用场景分组。例如：

1
/mcp/development
2
    ├── Linear
3
    └── Bytebase
4

5
/mcp/infrastructure
6
    └── Cloudflare

这样，开发类 Agent 连接 development 分组，基础设施类 Agent 连接 infrastructure 分组。需要全部工具时再连接 /mcp。

分组的价值不只是整理配置。根据 MCPHub 文档，分组端点只暴露组内 Server 的工具，因此可以减少工具发现开销，也能把不常用的工具限制在更小的访问范围内。

接入后的日常体验#

没有网关时，变化发生在每一台客户端；有网关后，变化主要发生在 MCPHub 的管理面板或配置中。

MCPHub 文档还提供了 Server 状态、日志和健康检查能力；配置更新可以热加载，不必为了增加或调整一个 MCP 而重启所有客户端。对个人来说，这减少了重复劳动，也让 MCP 接入不再只是散落在各台电脑上的配置文件。

当然，集中管理也会带来集中故障：Homelab 停机、网络不可达或 MCPHub 自身异常时，多个 Agent 可能同时失去工具能力。因此它适合配合 Homelab 的容器自动重启、配置备份、健康检查和必要的故障告警使用。

我会怎么使用它#

如果只是个人或小团队使用，我会遵循几个简单原则：

1. MCPHub 放在内网或 VPN 内，不直接把管理端口暴露到公网。
2. 使用 HTTPS、访问认证和强管理员密码，反向代理只开放真正需要的入口。
3. token 使用环境变量或密钥托管机制，不把真实凭据提交到 Git。
4. 按用途建立小而清晰的分组，不默认让所有 Agent 看到全部工具。
5. 读操作和写操作分开，生产写操作尽量增加人工确认或业务审批。
6. 备份 MCPHub 配置，但备份文件本身也要按敏感数据保护。
7. Homelab、MCPHub 和上游 MCP Server 都保留可追踪的日志，并定期检查异常调用。

如果只是为了“少配几次 MCP”，统一入口已经足够体现价值。对我来说，最重要的是让 MCP 的配置和凭据集中在一个自己能管理的地方，同时让各台设备保持轻量。

结语#

MCPHub 给我的最大感受，是把 MCP 从“某台电脑上的一段配置”变成了“一个可以长期运行和管理的服务入口”。

它解决了多设备重复配置、token 到处复制和 MCP 地址越来越多的问题，也让我可以在 Homelab 上统一查看和调整这些 MCP 服务。

但网关只是边界的一部分。即使是个人使用，也需要关注谁可以访问 MCPHub、凭据是否会出现在日志或备份里，以及 Homelab 或 MCPHub 故障后如何恢复。

当 MCP 服务数量开始增加时，尽早把这些问题放到一个集中入口里考虑，往往比等到每个客户端都积累一套不可控配置后再收拾更省事。

参考资料#

• MCPHub 官方文档
• MCPHub：Server Management
• MCPHub：Group Management
• MCPHub：Authentication & Security
• MCPHub：Monitoring & Observability
• MCPHub：MCP Settings Configuration