Skip to main content
本地 MCP Server 配好能跑了，接下来你可能会发现一些边界：换台电脑要重新配，团队里其他人想用但没法共享，或者 Server 需要长期在线但本地机器会关机。这篇把 5 个真实会碰到的”本地跑不了”场景列出来，每个给出本地方案的具体限制和上云之后怎么解决，最后用一棵决策树帮你判断要不要上 VPS。关于如何在本地把 MCP Server 跑通，可以先看 Claude Desktop + Cursor 本地 MCP Server 配置从零到跑通。

​
本地 MCP Server 的架构限制

先说清楚本地 MCP Server 的工作方式，才能理解它的限制在哪里。 本地 MCP Server 使用 stdio transport：客户端（Claude Desktop / Cursor）启动 Server 进程，两个进程在同一台机器上通过标准输入输出通信。这个机制决定了两点：① Server 和客户端必须在同一台机器上；② Server 的生命周期由客户端控制，客户端退出 Server 也退出。 
# 查看当前系统上 Claude Desktop 启动的 MCP Server 进程
# macOS
ps aux | grep "mcp-server"

# Windows PowerShell
Get-Process | Where-Object {$_.Name -like "*mcp*"}
这两个特点在单机单人场景下没有任何问题，但一旦需求扩展，就会碰到下面的场景。

​
场景 1：多设备——配置要同步三遍

具体问题： 在公司 Mac 上配好了连接内部数据库的 MCP Server，回家发现家里机器没配，周末用 Windows 本又得再配一遍。改了一个配置参数，三台机器都要改。 本地方案的限制： 
# 公司 Mac 上的配置路径
~/Library/Application Support/Claude/claude_desktop_config.json

# 家里 Mac 上同样的路径，但是空的
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json
# 输出：{}
你可以把配置文件放到 Git 或 iCloud 同步，但 Server 依赖的环境变量（API Key、数据库连接字符串）不能提交到 Git，secrets 管理立刻变成新问题。 上云之后如何解决： MCP Server 部署到 VPS，暴露一个 HTTPS URL。所有客户端的配置只有一行 URL 和一个 Bearer Token，不管用哪台机器，配置文件内容完全一样： 
{
  "mcpServers": {
    "my-db-server": {
      "url": "https://mcp.your-domain.com/mcp",
      "headers": {
        "Authorization": "Bearer your-token"
      }
    }
  }
}
换台机器只需要复制粘贴这段 JSON，30 秒搞定。

​
场景 2：团队共享——不可能让每个人都装一遍

具体问题： 写了一个连接内部数据库的 MCP Server，让团队里另外 2 个后端同学也用上。本地方案意味着每个人的机器都要：① 安装 Node.js；② 克隆 Server 代码；③ 配置数据库连接凭证；④ 在自己的客户端里填入配置。数据库密码要分发给每个人，离职了还得改密码。 本地方案的限制： 3 个人的机器上跑着 3 个 Server 实例，数据库连接数×3，凭证管理变成安全隐患。团队再大一点，维护成本线性增长。 上云之后如何解决： 一个 VPS 上跑一个 Server 实例，数据库凭证只存在 VPS 的环境变量里。给每个团队成员发一个独立的 Bearer Token，离职了只需要吊销对应 Token，数据库密码不用动： 
# 在 VPS 上为新成员生成 Token（Server 侧维护 Token 列表）
openssl rand -hex 32
# 把生成的 Token 加入 Server 的鉴权配置，发给成员

​
场景 3：7×24 在线——本地机器关机就断了

具体问题： MCP Server 里有一个工具需要监听 webhook（比如接收 GitHub push 事件后自动整理代码变更日志），或者有定时任务（每天凌晨拉取报表数据缓存起来）。本地机器一关机，这些功能全部断掉。 本地方案的限制： 
# 本地 MCP Server 完全依赖客户端保持活跃
# 检查 Claude Desktop 是否在运行
pgrep -x "Claude"
# 没有输出说明 Claude 关了，Server 也跟着停了
即使你想让本地机器不关机，还要面对：家庭宽带 IP 经常变动、没有固定域名、ISP 封锁 80/443 端口等问题。 上云之后如何解决： VPS 通过 systemd 管理 Server 进程，机器重启后自动拉起，7×24 在线。webhook 回调有固定的公网 IP 和域名可以注册： 
# VPS 上查看 MCP Server 服务状态
systemctl status mcp-server

# 配置开机自启
systemctl enable mcp-server

​
场景 4：出口 IP 风控——机房 IP 被第三方 API 拒绝

具体问题： MCP Server 内部需要调用某些第三方 API（OpenAI、Notion、某个数据提供商），这些 API 会对请求来源 IP 做风控。家用宽带 IP 在某些平台被标记为高风险，直接拒绝请求；机房 IP 的 ASN 归属是数据中心，同样被部分平台限速或拒绝。 上云之后如何解决： VPS 的出口 IP 固定，便于申请 API 白名单。如果机房 IP 仍然被风控，可以在 Server 里配置出口代理： 
// 在 MCP Server 代码里配置出口代理
import { HttpsProxyAgent } from "https-proxy-agent";

const agent = new HttpsProxyAgent("http://user:pass@proxy-host:port");

const response = await fetch("https://api.openai.com/v1/chat/completions", {
  agent,
  method: "POST",
  headers: { "Authorization": `Bearer ${process.env.OPENAI_API_KEY}` },
  body: JSON.stringify({ model: "gpt-4o", messages: [] })
});

​
场景 5：对外售卖——不可能把本地机器的地址给用户

具体问题： 写了一个对接自研数据服务的 MCP Server，想做成付费产品卖给用户。本地方案完全不可行：你不可能把家里 Mac 的 IP 地址和端口给用户，更无法保证服务可用性。 上云之后如何解决： VPS 配好域名和 HTTPS 之后，你有了一个对外可访问的 https://api.your-product.com/mcp 端点。给每个付费用户生成独立 Token，接入计费系统控制用量： 
# VPS 上为新付费用户生成唯一 Token
NEW_TOKEN=$(openssl rand -hex 32)
echo "新用户 Token：$NEW_TOKEN"

# 把 Token 写入 Server 的鉴权白名单
echo "TOKEN_$USER_ID=$NEW_TOKEN" >> /opt/mcp-server/.env
systemctl restart mcp-server

​
决策树：要不要上 VPS？

按顺序回答下面的问题，碰到”是”就停下来： 
你有多台设备需要用同一个 MCP Server？
├── 是 → 上 VPS
└── 否 ↓

你需要和其他人共享这个 MCP Server？
├── 是，人数 > 2 或凭证安全性有要求 → 上 VPS
└── 否 ↓

MCP Server 需要持续运行（接 webhook / 定时任务）？
├── 是 → 上 VPS
└── 否 ↓

MCP Server 内部调用的第三方 API 对来源 IP 有限制？
├── 是，且本地 IP 已经被拒 → 上 VPS
└── 否 ↓

你打算把这个 MCP Server 作为产品卖给他人？
├── 是 → 上 VPS（必须）
└── 否 → 继续用本地配置，不需要上 VPS
大多数独立开发者和个人站长，如果只是给自己用、单台设备、不需要持续在线，本地配置完全够用。一旦涉及多人、多设备或商业化，本地方案的维护成本会快速超过 VPS 的费用。

​
上 VPS 之前需要什么

确认上云后，需要准备：
  1. 一台有独立公网 IP 的 VPS——不是 NAT 后的内网机，80 和 443 端口要能通
  2. 一个域名——Let’s Encrypt 签发 HTTPS 证书需要绑定域名，裸 IP 无法申请免费证书
  3. 基础 Linux 运维能力——能 SSH 进去、能跑 apt / systemctl 命令就够
# SSH 连接 VPS 后先确认基础条件
# 检查公网 IP
curl -s https://api.ipify.org

# 检查 80/443 端口是否已开放（新机器应为空）
ss -tlnp | grep -E ':(80|443)'

# 检查系统版本（推荐 Ubuntu 22.04）
lsb_release -a
三个条件确认之后，部署本身不复杂。在云端 VPS 上自托管 Remote MCP Server：从零到远程调用完整配置从这里接手：先把 stdio 换成 Streamable HTTP，再走完 Nginx HTTPS 反代、Bearer Token 鉴权、systemd 守护进程配置，最后在 Claude Desktop 和 Cursor 里接入验证。

​
常见问题

没有区别。两者使用完全相同的 MCP 协议和 JSON-RPC 2.0 报文格式，区别只在传输层：本地用 stdio（进程管道），云端用 Streamable HTTP（HTTPS 端点）。MCP Server 的业务逻辑代码完全不需要改，只需要换 transport 的初始化方式。
有，用 ngrok 或 Cloudflare Tunnel 做临时隧道，可以把本地端口映射成公网 HTTPS URL，适合测试和演示场景。不适合生产用途，因为稳定性和安全性都有限：
# 用 ngrok 临时暴露本地 3000 端口
ngrok http 3000
# 会生成一个 https://xxx.ngrok-free.app 的临时 URL
取决于 Server 的内存占用。一个轻量 Node.js MCP Server 空载大约 50-100MB 内存，1GB 内存的 VPS 跑 5-8 个没有问题。如果 Server 有 AI 推理或大量文件处理，按实际负载估算。
主要改 transport 初始化部分：把 StdioServerTransport 换成 StreamableHTTPServerTransport，加一个 Express HTTP 服务层。业务逻辑（工具定义、资源读取、提示词模板）一行不用改。
本文最后更新于 2026-03。MCP 协议规范和客户端配置格式会随版本迭代，建议每 3 个月对照 MCP 官方文档检查一次。