Cline 在 JetBrains 里报 Healthcheck timed out、MCP hub not available 怎么解决
Cline 有两条报错，真因都相当反直觉——按常规思路排查，基本查不到。
这篇讲这两条，以及它们共同示范的一个道理：当一个插件「加载不出来」时，问题往往不在插件本身，而在它周围的环境。
一、Healthcheck timed out：系统拦住了 IDE 启动子进程
在 IntelliJ 里加载 Cline，弹出错误对话框：
Failed to load Cline
Healthcheck timed out
java.lang.IllegalStateException: Healthcheck timed out
对应 GitHub 上 cline/cline 的 issue #6398（已关闭，70 条评论）。原报告环境是 Cline v3.29.1 / 插件 1.0.1。
社区给的解法：macOS 的开发者工具权限
issue 里有一条评论给出了具体解法，值得完整引用其操作：
我遇到过这个症状。对我来说的解决办法是：macOS 阻止了 IntelliJ 启动子进程，包括 node.js——而 Cline 插件正是靠它跑的。
到「系统设置 | 隐私与安全性 | 开发者工具」里点 +，把 IntelliJ 加进去。
这条的价值在于它解释了「healthcheck 超时」为什么会发生：Cline 的 JetBrains 插件需要拉起一个 node.js 进程，插件通过健康检查确认那个进程起来了没有。macOS 的安全机制拦住了进程启动，健康检查自然等不到回应，超时。
报错说的是「健康检查超时」，真因是「进程根本没被允许启动」。
按常规思路，看到 timeout 会去查网络、查防火墙、查插件版本——没人会想到去系统的隐私设置里加个应用。
这是社区办法，官方未在文档中确认。 但它有明确的因果解释，而且操作可逆（加错了删掉就行），值得优先一试。
另外两条线索
issue 里还有两条有用的信息：
版本线索：有评论说 1.0.0 版本没有这个加载失败问题。所以如果上面的权限设置不管用，降级到 1.0.0 验证一下，能判断这是不是版本引入的。
日志位置：有评论贴出了 ~/.cline/cline-plugin.log 里的内容。这是排查 JetBrains 版 Cline 的日志位置，比在 IDE 界面上猜有用得多。那条评论里的日志显示的是内部资源加载失败，环境是隔离网（airgapped）下的 Rider 2025.2.2 + Debian 12，插件 1.0.5——说明在隔离网环境下，1.0.5 仍会复现。
排查顺序
- macOS 用户：先去「系统设置 → 隐私与安全性 → 开发者工具」，把你的 JetBrains IDE 加进去
- 看日志：
~/.cline/cline-plugin.log，找加载失败的具体原因 - 版本验证：降到 1.0.0 试试，判断是不是版本问题
- 隔离网环境：注意有报告显示这种环境下问题更顽固，日志里可能是内部资源加载失败
二、MCP hub not available：可能是你挪了面板位置
发消息给 Cline，报：
API Streaming failed: MCP hub not available
对应 issue #969（已关闭）。原报告是全新安装、全新设置下就出现。
两条社区办法
第一条（最高赞，76 个赞）：重启 VS Code。
评论里提到有人在 Windsurf 里用 Cline，更新到最新版后出现这个问题，完全退出再重启之后就好了。
这是最省事的一条，先试它。
第二条（真正反直觉的那条）：把 Cline 移回主侧边栏。
有评论描述得很清楚：
这个问题是我把 Cline 从主侧边栏移到副侧边栏之后开始的！（就是放 Copilot Chat 的那个副侧边栏。）解决办法是把 Cline 移回主侧边栏，然后重启 VS Code。
另一位评论者确认了同样的情况——他为了在主侧边栏放另一个工具，把 Cline 挪到副侧边栏，然后就报这个错。
面板放在哪，按理说是纯 UI 的事，不该影响功能。 两位评论者都表达了同样的困惑。但从排查角度，这条信息非常有用：
如果你最近调整过面板布局，先把它挪回去试试。
排查顺序
- 完全退出 VS Code 再打开（不是关窗口，是退出应用）
- 回想最近有没有挪过 Cline 的面板位置——挪过就先挪回主侧边栏，然后重启
- 还不行再去查 MCP 服务本身的配置
三、第三条：Model is not supported
顺带记一条形态不同的。用 Cline 配合 VS Code 的语言模型 API（vscode-lm）时：
Request Failed: 400 {"error":{"message":"Model is not supported for this request.","code":"model_not_supported","param":"model","type":"invalid_..."}}
对应 issue #7228（已关闭），原报告是 Cline 3.35.0，所有模型都报这个。
这条 issue 里没有得到官方确认的解法。 评论区有人贴了第三方仓库的链接作为修复方案——本文不引用也不推荐第三方的修复脚本或补丁，因为无法核实其内容与安全性。装来路不明的修复工具，风险可能比原问题大。
还有评论提到装旧版本 Cline 也一样复现，所以降级这条路在这里可能不通。
从报错本身能读出的信息：code 是 model_not_supported，param 是 model——这是模型标识层面的问题，不是网络、不是认证。如果你在用 vscode-lm 这条路径，可以试试换回直接配置 API 提供商，绕开这一层。
四、这三条的共同点
把它们放在一起看，有个共同的规律：
插件「加载不出来」或者「用不了」时，真因常常在插件之外。
- Healthcheck 超时 → 真因在操作系统的安全策略
- MCP hub 不可用 → 真因（其中一种）在你的面板布局
- Model not supported → 真因在中间的模型接入层
这几个地方的共同点是：排查插件问题时，没人会想到去查它们。
所以遇到这类问题，除了常规的「重装、降级、看日志」，还值得问几个问题：
- 最近改过什么系统设置或者 IDE 设置吗？（哪怕看起来完全无关）
- 它需要启动别的进程吗？那个进程被允许启动吗？
- 中间还隔着别的组件吗？（比如 vscode-lm 这样的接入层）
这三个问题在本文的三条报错里各命中一条。
五、「加载不出来」的通用排查清单
这三条虽然真因各异，但排查一个「插件加载不出来」的问题，有一套通用顺序能覆盖大部分情况。按成本从低到高：
第一，完全退出 IDE 再打开。 注意是退出应用，不是关窗口——很多 IDE 关掉窗口后进程还在。这一步解决的问题比想象中多，issue #969 里最高赞的评论给的就是这个。
第二，回想最近改了什么。 不只是插件相关的：系统更新、IDE 更新、改过设置、挪过面板、装过别的插件、公司推过策略。本文里「挪面板」和「系统安全设置」这两条真因，都只能靠这一步想起来。
第三，找日志。 这是分水岭——在此之前是碰运气，从这一步开始是排查。JetBrains 版 Cline 的日志在 ~/.cline/cline-plugin.log。
第四，看它是不是要启动别的进程。 很多插件的实际工作进程是独立的（Node、Python、容器）。那个进程起不来，插件就废了，而报错通常只说「超时」或「加载失败」。
第五，版本对照。 降到一个已知能用的版本，判断是不是回归。
第六，换环境验证。 换台机器、换个 IDE、换个用户，看还复不复现。
大多数人卡住，是因为在第一步和第五步之间反复横跳（重装、重启、再重装），跳过了第二、三、四步——而真因往往就在那三步里。
六、总结
Healthcheck timed out：社区解法是在 macOS 的**「系统设置 → 隐私与安全性 → 开发者工具」里把 JetBrains IDE 加进去**——真因是系统拦住了 IDE 启动 node.js 子进程。日志在~/.cline/cline-plugin.log；有报告称 1.0.0 版本没这个问题。MCP hub not available：先完全退出 VS Code 重启；如果最近把 Cline 面板挪到过副侧边栏，挪回主侧边栏再重启。Model is not supported（vscode-lm）：issue 里无官方解法，本文不推荐来路不明的第三方修复；可以试试绕开 vscode-lm 直接配 API 提供商。- 共同规律：插件用不了时，真因常在插件之外——系统安全策略、IDE 布局、中间接入层。
- 以上均为社区经验，官方未在文档中确认。
本文引用的 issue 编号与内容来自 cline/cline 仓库 issue #6398、#969、#7228 的公开评论，核对日 2026-08-08。版本与产品行为会变化，以官方为准。