本地部署爱好者的宿命服务越装越多端口早晚打架。我机器上常年跑着 Ollama、LM Studio还有察元桌面版知识库跑在 62581一直相安无事。直到上周一早上Claude Code 里察元的 46 个工具集体消失一段排错实录就此展开顺手把处理过程完整记下来给同病相怜的人省点时间。现场像是服务挂了其实不是现象很典型Claude Code 提示 MCP 服务连不上工具全部不可用。按老规矩先打健康检查curlhttp://127.0.0.1:62588/healthz不返回 online。第一反应是服务没起来重启 WPS——没用。加载项明明装得好好的昨天还正常用着。这时候冷静下来想healthz 不通只有两种可能要么服务没起来要么服务起来了但我够不着它。第二种可能的头号嫌疑犯默认端口 62588 被别的进程抢走了。定位一条 netstat 定案Windows 下一行命令查端口占用netstat-ano|findstr62588输出显示 62588 已经被另一个进程监听——上周装的一个本地小工具默认也用这个段位的端口撞了个正着。察元的 MCP 服务默认端口就是 62588端口被占服务自然起不来。病因找到剩下的就是换端口而且不用改任何代码。回头看这次排错healthz 加 netstat 两条命令就完成了定位前后不到五分钟如果没有先分诊的习惯大概率会走上重装加载项、重装智能体、清配置的弯路折腾一小时还未必能好。工具越智能越要给排错留一套笨办法先确认事实再动手改。为什么偏偏是端口察元的 MCP 服务是一个单文件常驻进程Windows 上注册开机自启不依赖 Node.js 环境加载项、sidecar、智能体三方都靠 62588 这个地址会合。这类本机服务架构的代价就是端口独占地址一旦被抢整条链路一起断。而这几年本地部署爆发式增长一台机器上挤着 Ollama、LM Studio、各种 sidecar默认端口撞车几乎是必然会遇到的事遇到不丢人会处理就行。处理CHAYUAN_MCP_PORT 三步闭环察元支持用 CHAYUAN_MCP_PORT 环境变量指定服务端口整个处理就三步。第一步把新端口写进用户环境变量setx CHAYUAN_MCP_PORT62599第二步让服务读到新值。setx 只对之后启动的进程生效注销重登或者重启 chayuan-mcp 进程让自启服务用新端口拉起来。macOS 和 Linux 用户思路完全一致把 CHAYUAN_MCP_PORT 写进对应平台的服务环境里重启生效差别只在写法。第三步验证。对着新端口再打一次 healthzcurlhttp://127.0.0.1:62599/healthz返回 online服务侧收工。最容易漏的一步同步所有客户端服务搬家了客户端还指着旧地址。Claude Code 用新 URL 重新注册claude mcpadd--transporthttp chayuan-wps-mcp http://127.0.0.1:62599/mcpCodex 的 config.toml、Cursor 的 .mcp.json 里那个 url 字段也要同步改不然就是服务明明在线、Agent 就是连不上的灵异现场——其实不是灵异是地址没跟上。改完把每个客户端的会话都重开一遍工具列表全部拉得出来才算闭环完成。我就是漏了 Cursor 那份配置多排查了二十分钟教训深刻。复盘三条一排错顺序别乱先 healthz 分清服务问题还是链路问题再 netstat 查占用直奔病因别上来就重装。二本地服务多的机器装新工具前先扫一眼常用端口62581、62588 这些常驻端口心里要有数与其事后救火不如装机时错开。三改端口是环境变量、重启服务、同步客户端配置三步闭环少任何一步它都会在半小时后以另一种报错回来找你。四改完做一次全链路验收healthz、工具列表、实际写一条测试批注三层全过再交还使用别只验到一半就宣布修复。边界收尾换了端口安全模型没有变服务依然只监听 127.0.0.1本机即信任边界不需要配置 Token。真有跨机器访问的需求正路是走代理方案而不是把监听地址裸露到网络里。这套流程也适合所有本地服务多的开发者和运维不止察元任何依赖默认端口的本机服务被占方法论完全一致。端口冲突是小事但排错的章法是通用能力——下次任何本机服务莫名失踪healthz 加 netstat 这套组合拳照打不误。
本地部署爱好者的宿命服务越装越多端口早晚打架。我机器上常年跑着 Ollama、LM Studio还有察元桌面版知识库跑在 62581一直相安无事。直到上周一早上Claude Code 里察元的 46 个工具集体消失一段排错实录就此展开顺手把处理过程完整记下来给同病相怜的人省点时间。现场像是服务挂了其实不是现象很典型Claude Code 提示 MCP 服务连不上工具全部不可用。按老规矩先打健康检查curlhttp://127.0.0.1:62588/healthz不返回 online。第一反应是服务没起来重启 WPS——没用。加载项明明装得好好的昨天还正常用着。这时候冷静下来想healthz 不通只有两种可能要么服务没起来要么服务起来了但我够不着它。第二种可能的头号嫌疑犯默认端口 62588 被别的进程抢走了。定位一条 netstat 定案Windows 下一行命令查端口占用netstat-ano|findstr62588输出显示 62588 已经被另一个进程监听——上周装的一个本地小工具默认也用这个段位的端口撞了个正着。察元的 MCP 服务默认端口就是 62588端口被占服务自然起不来。病因找到剩下的就是换端口而且不用改任何代码。回头看这次排错healthz 加 netstat 两条命令就完成了定位前后不到五分钟如果没有先分诊的习惯大概率会走上重装加载项、重装智能体、清配置的弯路折腾一小时还未必能好。工具越智能越要给排错留一套笨办法先确认事实再动手改。为什么偏偏是端口察元的 MCP 服务是一个单文件常驻进程Windows 上注册开机自启不依赖 Node.js 环境加载项、sidecar、智能体三方都靠 62588 这个地址会合。这类本机服务架构的代价就是端口独占地址一旦被抢整条链路一起断。而这几年本地部署爆发式增长一台机器上挤着 Ollama、LM Studio、各种 sidecar默认端口撞车几乎是必然会遇到的事遇到不丢人会处理就行。处理CHAYUAN_MCP_PORT 三步闭环察元支持用 CHAYUAN_MCP_PORT 环境变量指定服务端口整个处理就三步。第一步把新端口写进用户环境变量setx CHAYUAN_MCP_PORT62599第二步让服务读到新值。setx 只对之后启动的进程生效注销重登或者重启 chayuan-mcp 进程让自启服务用新端口拉起来。macOS 和 Linux 用户思路完全一致把 CHAYUAN_MCP_PORT 写进对应平台的服务环境里重启生效差别只在写法。第三步验证。对着新端口再打一次 healthzcurlhttp://127.0.0.1:62599/healthz返回 online服务侧收工。最容易漏的一步同步所有客户端服务搬家了客户端还指着旧地址。Claude Code 用新 URL 重新注册claude mcpadd--transporthttp chayuan-wps-mcp http://127.0.0.1:62599/mcpCodex 的 config.toml、Cursor 的 .mcp.json 里那个 url 字段也要同步改不然就是服务明明在线、Agent 就是连不上的灵异现场——其实不是灵异是地址没跟上。改完把每个客户端的会话都重开一遍工具列表全部拉得出来才算闭环完成。我就是漏了 Cursor 那份配置多排查了二十分钟教训深刻。复盘三条一排错顺序别乱先 healthz 分清服务问题还是链路问题再 netstat 查占用直奔病因别上来就重装。二本地服务多的机器装新工具前先扫一眼常用端口62581、62588 这些常驻端口心里要有数与其事后救火不如装机时错开。三改端口是环境变量、重启服务、同步客户端配置三步闭环少任何一步它都会在半小时后以另一种报错回来找你。四改完做一次全链路验收healthz、工具列表、实际写一条测试批注三层全过再交还使用别只验到一半就宣布修复。边界收尾换了端口安全模型没有变服务依然只监听 127.0.0.1本机即信任边界不需要配置 Token。真有跨机器访问的需求正路是走代理方案而不是把监听地址裸露到网络里。这套流程也适合所有本地服务多的开发者和运维不止察元任何依赖默认端口的本机服务被占方法论完全一致。端口冲突是小事但排错的章法是通用能力——下次任何本机服务莫名失踪healthz 加 netstat 这套组合拳照打不误。
原理与实现：从Cookie共享到JWT方案)
