企业官网建设流程全解析

本地开发机上跑着一个通过 stdio MCP 接入的工具，在 Cursor 或 Claude Code 里用得挺顺畅。直到某天你需要从另一台机器、甚至同事的电脑上调用它时，问题就冒出来了——绝大多数 MCP server 默认走 stdio，也就是客户端必须在同一台机器上拉起子进程、通过标准输入输出交换 JSON-RPC 消息。这种模型天生绑定本机，远程调用根本无从谈起。要解决"本地服务器也能远程安全调用"，最直接的路就是把它从 stdio MCP 转成 HTTP MCP，让协议跑在 HTTP 之上，再往前走一步挂上鉴权和 TLS。

这篇文章我会把转换的原理、方案选型、实操代码和远程暴露时的安全加固完整讲一遍。适合手里已经有一个能跑的 stdio MCP server、想把它共享给远程客户端或团队成员的人。内容不挑具体 SDK，Python 和 TypeScript 两边我都会给到可落地的写法。

1. 先搞清楚 stdio 和 HTTP 两种传输方式到底差在哪

1.1 stdio 的启动模型：谁拉起谁、标准输入输出怎么走

MCP 客户端的配置里通常写的是 command 加 args，比如 Claude Code 里是这样：

{ "mcpServers": { "demo": { "command": "node", "args": ["server.js"] } } }

客户端负责 spawn 这个子进程，然后通过 stdin 写 JSON-RPC 请求、从 stdout 读响应。stdio 模式里有个约定俗成的规则：所有日志一律走 stderr，绝不能往 stdout 打印任何非协议内容，否则会把协议流污染掉，客户端直接解析失败。

这个模型的好处是简单，没有端口、没有网络权限、没有跨域问题，服务器跟着客户端进程走，退出就干净。坏处也很明显：server 的生命周期被客户端绑定，调用方和 server 必须物理上在同一台机器上。我一开始玩 MCP 时觉得这设计挺合理，毕竟本地工具链嘛，但真到要远程调用的时候，就会发现 stdio 根本不给机会。

还有一个隐藏问题：stdio 模式下 server 无法感知调用方身份。它只看到一个进程拿着 stdin/stdout 跟它说话，没有 IP、没有 header、没有任何身份信息。这在本地无所谓，但放到远程就是安全隐患的根源。

1.2 HTTP 传输模型：跨网络、无进程边界

2025 年 3 月 26 日更新的 MCP 协议里，Streamable HTTP 已经是主推的传输方式，取代了早期那个"POST 请求 + SSE 长连接"的老式 HTTP+SSE 方案。

Streamable HTTP 的工作方式很直观：客户端向一个固定 URL 发 POST，请求体是标准 JSON-RPC。服务端响应可以是普通 JSON，也可以升级为 SSE 流，用于推送 notifications 这类服务端主动消息。会话状态通过Mcp-Session-Id这个 header 维持，客户端每次请求带上它，服务端就知道你是老熟人。

和 stdio 相比，最核心的差别在于：server 不再是被拉起的进程，而是一个常驻的 HTTP 服务。调用方是谁无所谓，只要能访问到 URL 就行。这就把 MCP 的能力边界从"单机"扩展到了"整个网络"。

代价是引入了一整套分布式问题：会话隔离、超时控制、鉴权、TLS、CORS、限流。所以说，转换本身不难，难的是转换完之后怎么让这个服务安全稳定地暴露出去。

1.3 转换的本质：换传输层，不换协议层

很多第一次接触 MCP 的人会被"stdio 转 HTTP"这个词吓到，以为要动协议、改工具定义。其实完全不是这么回事。

MCP 的 JSON-RPC 方法层是传输无关的。initialize、tools/list、tools/call、resources/read、prompts/get这些方法，不管底下走的是管道还是网络，语义完全一致。工具返回的 content block 结构也一模一样。

所以转换本质上是把"字节流动的渠道"从进程管道换成 HTTP，你的 tools、resources、prompts 的逻辑一行都不用动。我用一个类比给你感受下：协议层像是你和朋友约定好的聊天内容，stdio 和 HTTP 只是不同形式的电话线。换线，不影响你们聊什么。

这一点是整个方案能低成本落地的根本原因。后面你在实操里会看到，改动量小到可能只需要改一行配置。

2. 四类转换方案，按侵入程度排个序

2.1 最省事：现成代理工具给 stdio 包一层 HTTP 壳

如果你不想改代码，或者你手里的 server 是个编译好的二进制、拿不到源码，那么代理工具是首选。这类工具的思路是：它负责把你的 server 命令当作子进程 spawn 起来，内部对接 stdin/stdout，对外暴露一个 HTTP/SSE 端点。

以 mcp-proxy 为例，命令大致是这样的：

npx mcp-proxy --transport streamable-http "node ./dist/server.js"

把原来客户端配置里的 command 和 args 原封不动塞进去，mcp-proxy 就会在本地开一个 HTTP 端口，把进来的 JSON-RPC 请求翻译成 stdin 写入，再从 stdout 读响应返回给远端。

这个方案的优点是真的零侵入，适合快速验证、临时共享。但它只是解决了"通不通"的问题，没有解决"安全不安全"的问题。比如 mcp-proxy 本身不提供用户鉴权，暴露到公网就等于谁都能调你的工具。所以我建议代理方案只用于内网或者配合前面的网关做端口隐藏，别直接裸奔到公网。

2.2 推荐方案：用官方 SDK 改 transport

这是我最推荐的方式。无论 Python 还是 TypeScript，官方 SDK 都提供了对应的 HTTP transport 实现，改动量小到惊人。

Python 这边，FastMCP 的run()方法有个 transport 参数，原来是stdio，你把启动方式改成http，server 就会自动以 HTTP 服务的形式跑起来。

TypeScript 那边则是把StdioServerTransport换成StreamableHTTPServerTransport，用 Express 的 route 把请求导进去，代码量多了一些但要处理的细节也更可控。

这个方案的好处是你完全掌握服务端行为：监听地址、端口、路径、会话策略、中间件都能自己定义。后续要加鉴权、审计日志也方便。缺点是比起代理方案，需要动一点代码，但对于大多数项目来说成本很低。

2.3 调试兜底：MCP Inspector

还有一条路容易被忽略：MCP Inspector。它本身是官方调试工具，既能在浏览器里启动一个 stdio server，也支持通过 remote URL 直接连接一个 HTTP MCP server。

npx @modelcontextprotocol/inspector

打开 Inspector 面板，在远程连接框里填你的 HTTP 地址，就能以客户端身份发起握手、调工具、看请求响应报文。转换之后先用 Inspector 验证一遍，比直接上 Cursor 或者 Claude Code 排查要快得多，因为你可以完整看到协议层的每个请求。

但注意，Inspector 是调试工具，没有任何鉴权和限流能力，绝对不能当作生产环境网关挂在公网。

2.4 方案对比：什么场景选什么

我的习惯是：个人临时远程用，直接代理工具；要给整个团队用、或者要接生产环境的，一定走 SDK 改造，把鉴权和日志做在服务层。下面的实操部分，我按推荐方案展开。

3. 实操：用 FastMCP 把 stdio server 改造成 HTTP server

3.1 Python FastMCP：改动可能就一行

先看最小例子。假设你原来有一个典型的 FastMCP server：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("demo") @mcp.tool() def list_files(path: str) -> list[str]: """返回指定目录下的文件列表""" import os return os.listdir(path) if __name__ == "__main__": mcp.run(transport="stdio")

改造成 HTTP 只需两步：设置监听地址和端口，再在run()里把 transport 换成 http：

from mcp.server.fastmcp import FastMCP mcp = FastMCP( "demo", host="127.0.0.1", port=8000 ) @mcp.tool() def list_files(path: str) -> list[str]: """返回指定目录下的文件列表""" import os return os.listdir(path) if __name__ == "__main__": mcp.run(transport="http")

启动后你会看到 uvicorn 的日志，默认服务跑在http://127.0.0.1:8000/。不同版本的 FastMCP 对挂载路径处理略有差异，有些会挂在/mcp下，保险起见看启动日志，或者两个路径都试一下。

这里面有个容易被忽略的点：监听地址。如果你希望这个服务之后能通过外网访问，先把host改成"0.0.0.0"，否则只监听 loopback，外面的请求永远进不来。但我也提醒一句：0.0.0.0意味着局域网内所有机器都能扫到，配合后面第 4 节的安全措施一起做，别单独开。

依赖方面，别忘了pip install "mcp[cli]"，FastMCP 启动 HTTP 服务依赖 uvicorn，mcp[cli]会把它一起带进来。

3.2 TypeScript SDK：手动装配 Streamable HTTP transport

TypeScript 那边没有 FastMCP 那么"魔法"，需要自己在 HTTP 框架里接一下 transport。下面用 Express 示例：

import express from "express"; import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js"; const app = express(); app.use(express.json()); const server = new McpServer({ name: "demo", version: "1.0.0" }); server.tool("list_files", { path: { type: "string" } }, async ({ path }) => { const fs = await import("node:fs"); return { content: [{ type: "text", text: fs.readdirSync(path).join("\n") }] }; }); let transport: StreamableHTTPServerTransport | null = null; app.post("/mcp", async (req, res) => { if (!transport) { transport = new StreamableHTTPServerTransport({ enableJsonResponse: true, sessionIdGenerator: undefined }); await server.connect(transport); } await transport.handleRequest(req, res); }); app.get("/mcp", async (req, res) => { if (!transport) { transport = new StreamableHTTPServerTransport({ enableJsonResponse: true, sessionIdGenerator: undefined }); await server.connect(transport); } await transport.handleRequest(req, res); }); app.delete("/mcp", async (req, res) => { if (transport) { await transport.handleRequest(req, res); await server.close(); transport = null; } }); app.listen(3000, () => { console.log("MCP server listening on http://127.0.0.1:3000/mcp"); });

这段代码里有几个关键点。enableJsonResponse: true允许服务端对适合 JSON 响应的请求直接返回 JSON，而不是全部走 SSE，这样大部分常规的tools/list、tools/call客户端解析起来更省事。

sessionIdGenerator: undefined表示不自动生成会话 ID，也就是无状态模式。对大多数只调工具、不维护会话的 server 来说无状态够用，还能避免会话泄漏问题。如果你的 server 内部有状态（比如某个浏览器实例、数据库连接事务），那就需要改成会话模式，后面我会专门说。

路由我统一挂在/mcp下，GET是为了支持某些客户端建立 SSE 连接，DELETE用于会话释放，这是 Streamable HTTP transport 的三个标准动作。一个完整的 MCP HTTP server，这三个方法缺一不可。

3.3 用 curl 和 Inspector 验证转换结果

服务启动后，先用 curl 打一发最基础的手握请求，确认 transport 层是通的：

curl -X POST http://127.0.0.1:8000/ \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-03-26", "capabilities": {}, "clientInfo": { "name": "curl", "version": "1.0" } } }'

如果返回里有"result"字段，里面有serverInfo和protocolVersion，说明 HTTP transport 已经通了。这里不用纠结是否要带会话 ID，curl 的目的是验证链路活着，完整的协议握手交给 MCP 客户端去做。

更完整的验证方式是用 Inspector 的远程连接模式：

npx @modelcontextprotocol/inspector

在浏览器界面里选择"远程连接"，填http://127.0.0.1:8000/（或者你的/mcp路径），点连接。如果能看到 serverInfo、能列出工具、能成功调用工具，那这个 HTTP MCP server 就基本合格了。

3.4 客户端侧接入：Cursor 和 Claude Code 的配置差异

转换完成后，本地客户端改成 HTTP 直连就能用。

Cursor 的 MCP 配置加一个 HTTP server：

{ "mcpServers": { "demo": { "type": "http", "url": "http://127.0.0.1:8000/", "headers": { "Authorization": "Bearer your-token" } } } }

Claude Code 则用命令添加：

claude mcp add demo --transport http http://127.0.0.1:8000/ --header "Authorization: Bearer your-token"

这里有个版本的坑：老版本客户端很可能还按 SSE 的方式连，或者压根不支持 Streamable HTTP。所以给团队推广之前，先确认客户端的 MCP 版本支持2025-03-26协议，否则会看到一堆莫名其妙的握手失败。

4. 远程调用安全加固：不进网关等于裸奔

4.1 为什么 MCP server 绝对不能裸奔

很多人觉得 MCP server 就是个 API，大不了被人扫到调用一下，能有多大损失。这是最危险的想法。

MCP server 的本质是工具执行接口。很多人在里面装了 shell 工具、文件读写工具、数据库查询工具。这种能力暴露到公网且无鉴权，约等于把一台带着钥匙的管理机器挂在公网上——别人拿到的不是一个只读接口，而是一把能直接调用任意工具的门禁卡。

而且 MCP 的 JSON-RPC 请求极其简单，几分钟就能用脚本批量扫描公网开放端口并尝试tools/list。所以不管你的工具列表有多简单，只要走到公网，鉴权层就是刚需，没有任何商量余地。

4.2 第一层：用反向代理终结 TLS

我通常的建议是把 MCP server 跑在内网或本机，用一个公网 VPS 上的反向代理做入口。TLS 也在这一层终结，应用本身不用自己处理证书。

Caddy 是最省心的选择，自动申请和续期证书：

mcp.example.com { reverse_proxy 127.0.0.1:8000 }

Caddy 会自动申请 HTTPS 证书，配置量少到没有可讲的复杂度。如果你更熟悉 Nginx，也完全没问题，需要注意把默认的 60 秒代理超时调大：

server { listen 443 ssl; server_name mcp.example.com; ssl_certificate /etc/letsencrypt/live/mcp.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/mcp.example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 300s; proxy_send_timeout 300s; } }

这里把超时调到 300 秒，原因后面会讲，很多 MCP 工具本身耗时就长，默认 60 秒很容易触发 504。

如果你压根没有公网机器，但这台本地服务器只是你想在出差时从个人笔记本远程调用，那还有个轻量办法：本地保持监听127.0.0.1，通过 SSH 反向隧道把端口映射到一台跳板机：

ssh -R 9000:localhost:8000 user@your-vps

这样 VPS 上只有127.0.0.1:9000被监听，完全不暴露公网端口，再从跳板机本地访问。成本低、安全边界清晰，没有公网入口泄漏的风险。

4.3 第二层：在应用层加 Token 校验

光有 TLS 还不够，通信加密解决的是"路上的窃听"，但没法阻止"有人拿到了 URL 就乱调"。必须在应用层加身份校验。

最简单有效的是 Bearer Token。在 FastMCP 场景下，可以用一个前置中间件拦截请求。如果你用的是 SDK 改造方案，在 Express 上加一件事就行：

app.use("/mcp", (req, res, next) => { const expected = process.env.MCP_TOKEN; const auth = req.headers.authorization || ""; if (auth !== `Bearer ${expected}`) { res.status(401).json({ jsonrpc: "2.0", id: null, error: { code: -32001, message: "unauthorized" } }); return; } next(); });

MCP_TOKEN用环境变量注入，不要写死在代码里。这样即使tools/list或者其他方法被命中，也会先撞上 401。

Caddy 里也可以做一个前置校验，挡在反代前：

mcp.example.com { @unauthorized not header Authorization "Bearer *" respond @unauthorized 401 reverse_proxy 127.0.0.1:8000 }

不过 header 校验的规则匹配有坑，Authorization里值如果带特殊字符容易误判，我一般只在验证阶段这么干，正式环境还是在应用层做判断更可靠。

4.4 多会话与状态隔离：远程多用户下更要注意

stdio 模式下，每个 MCP 客户端启动的是独立子进程，会话天然隔离。你在这个客户端开的浏览器实例、连的数据库，跟另一个客户端互不干扰。

转成 HTTP 后，所有请求打在同一个服务进程上。如果你的 server 是无状态的（比如纯文本处理、简单文件枚举），那无所谓。但一旦工具里有状态，例如 Playwright MCP 持有浏览器实例、某个工具持有数据库连接池，多个远程客户端同时调用就会出现互相踩踏的情况。

处理方式有两种。一是保持无状态会话，每个请求独立处理，不保存状态，这对大部分工具场景够用。二是按会话创建 transport 实例，用Mcp-Session-Id区分不同客户端，给每个会话分配独立的内部状态容器。

TypeScript 那边的经典做法是用一个Map<string, StreamableHTTPServerTransport>存会话 ID 到 transport 的映射，每次请求进来先根据 header 里的 sessionId 查表，查到就用对应 transport 处理，查不到就新建。这个复杂度比单例模式高不少，只有在工具确实有状态时才需要。我自己的原则是：能无状态就无状态，省掉一整类并发问题。

5. 从本地切到远程之后我踩过的几个坑

5.1 客户端用了老的 SSE 传输方式，一直连不上

这是我踩过最隐蔽的坑。早期 MCP 的 HTTP+SSE 传输方式，客户端需要同时维护两个端点：一个发消息、一个收服务端推送。后来被 Streamable HTTP 统一成一个 POST 端点，但很多客户端版本根本没跟上。

症状表现为：客户端配置没问题、端口通、证书也正常，但初始化永远失败，calling tool 一直转圈。排查方式是把客户端日志打开看具体在请求哪个 URL，如果还带着/sse字样，基本可以断定是旧协议在捣乱。

解决办法要么升级客户端到支持新协议的版本，要么在中间加一层协议适配。这个坑特别容易出现在团队里，因为大家客户端版本参差不齐。

5.2 Nginx 默认 60 秒超时，长任务全挂

有一次我接了个 MCP 工具，功能是根据一段长文本生成分析报告，后端模型推理要跑 70 多秒。本地 stdio 模式跑得好好的，一改成 HTTP 远程访问就稳定在 60 秒左右返回 504。

原因就是 Nginx 的proxy_read_timeout默认只有 60 秒。HTTP 模式下，服务端还没来得及返回，网关已经把请求掐了。修复办法就是前面配置里写的，把超时调到 300 秒甚至更长。

这里我要提醒一句：调大超时只是治标。MCP 协议本身支持异步通知和服务端推送，如果你的工具任务经常超过几分钟，更合理的做法是设计成"任务提交 + 结果查询"的异步模式，避免长期占用 HTTP 连接。当然这是架构层面的事，大多数工具场景先调超时撑住再说。

5.3 环境变量和密钥传递方式变了

stdio 模式下，server 是被客户端 spawn 的，环境变量从客户端进程继承。比如你在 Cursor 里配好了DATABASE_URL，你的 MCP server 通过process.env.DATABASE_URL能直接读到。

转成 HTTP 常驻服务之后，这个链路断了。服务不是你启动的，它自己只认它自己的环境变量。或者说，当年你在本地 .env 里配的密钥并不会跟着 HTTP 请求传过来，因为你没也不会在 HTTP header 里传密钥，那太危险了。

我踩过的是：本地所有工具正常，搬到服务器上后数据库类工具全部 500。排查到最后才发现是服务进程本身缺少DATABASE_URL环境变量。HTTP 模式下，密钥统一从服务进程的环境变量或密钥管理服务读取，别再指望从客户端侧注入了。

5.4 监听地址和防火墙的限制

还有个常见问题：明明在本地curl http://127.0.0.1:8000/好好的，但远程访问就是超时。

如果你用的是 FastMCP，先检查 host 是否设置成了0.0.0.0。代码里写了127.0.0.1，那服务只监听回环地址，不管你怎么配网关都进不来。其次检查服务器防火墙，很多云服务器的安全组策略默认只放行 80 和 443，8000 这种端口得手动开，或者干脆用反代把 443 映射到内网服务，不直接暴露这个端口。

我的经验是尽量用反代而不是裸端口。裸端口意味着每次换端口都要过一遍安全组、防火墙、还有各种扫描器的问候。用 Caddy/Nginx 统一从 443 进，内部再分流，管理起来干净很多。

如果做完了这些还是连不上，最后一招是tcpdump或者看反代日志判断请求到底有没有到达服务层。走一遍链路就能定位问题出在防火墙、路由还是应用本身。

我在实际切换过程中最大的体会是：stdio 转 HTTP 不难，难的是转变思维习惯。stdio 是"我用我的电脑启动你的进程"，HTTP 是"任何人只要能访问这个 URL 就能使用你的能力"。后面的路，也就是鉴权、超时、会话隔离和密钥管理，才是这个转换的真正成本所在。我现在固定的做法是无状态工具直接走 HTTP、加 Token、套 Caddy，有状态工具再单独评估会话方案。如果你只是自己远程用，SSH 反向隧道加本机监听是最稳的起步方案；如果要给团队用，至少把第 4 节的鉴权和 TLS 都补齐再放出去。