管理托管通常会打断开发流程。你在编辑器里编写代码，打开托管面板创建网站，切换到终端打包或推送项目，回到面板检查部署；当需要处理 DNS、日志或服务器资源时，又要打开更多工具。

Hostinger Connector 减少了这种上下文切换。它通过模型上下文协议（MCP）将 Hostinger 服务连接到 AI 编码工具，让你无需离开编辑器，就能让 AI 助手检查或管理受支持的托管资源。

这听起来很方便。但它也引出了一个更重要的问题：你能相信 AI 助手准确执行真实的托管任务吗？

为了找出答案，我使用 VS Code 和 GitHub Copilot 在一个真实的 Hostinger 账户上测试了 Hostinger Connector。我使用一个名为 PulseWatch 的小型 Express.js 应用程序，并遵循从安装到上线部署的完整流程。我还测试了重复部署、构建记录、日志，以及在我故意破坏应用启动命令后进行恢复。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

浏览 Hostinger

Hostinger Connector 优缺点

评分明细

以下是我对 Hostinger Connector 在开发者决定是否使用时最重要的几个方面所做的评分：成本、功能范围、日常可用性、执行真实任务的准确性，以及出问题时的支持。我给出的每一项分数都反映了我在测试中的实际发现，而不是营销页面上的说法。

Hostinger Connector 方案与价格

Hostinger Connector 并不是单独售卖的产品。Hostinger 表示 Connector 免费包含在每个套餐中，这意味着你的托管账单上不会额外增加 Connector 的月费。

不过，“免费”需要放在语境中理解。Connector 管理的是 Hostinger 资源；它并不取代这些资源。你仍然需要一个符合条件的 Hostinger 托管、云、VPS、域名、电子邮件或其他服务，才能让它执行你想要的任务。

在本次评测时，Connector 落地页重点展示了 Business Web Hosting 和 Cloud Startup。

价格显示的是税前金额。促销价和续费费率可能会变化，因此应查看当前结账总额，而不要只看广告中的月费。

价格提示： 不要只是为了使用 Connector 而购买更高档套餐。应根据你需要的网站数量、Web 应用数量、它们所需资源以及你想要的支持级别来选择套餐。Connector 是一个包含在内的管理层，而不是定价的主要产品。

Hostinger 提供适用于符合条件托管购买的 30 天退款保证。由于 Connector 没有单独收费，因此没有独立的 Connector 退款政策可供评估。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

浏览 Hostinger

功能

• Node.js 应用部署
• PHP 和 HTML 部署
• WordPress 网站管理
• Website Builder 和 Horizons 工作流
• GitHub 连接部署
• 域名连接与组织
• DNS 检查与更新
• SSL 和网站诊断
• 数据库管理
• VPS 设置与管理
• Docker 项目部署
• CPU 和内存监控
• 带宽和磁盘检查
• 服务和容器重启
• 恶意软件扫描
• 备份恢复
• 电子邮件营销活动设置
• 部署和构建检查

具体可用的操作取决于你账户中的 Hostinger 服务，以及连接的 AI 客户端所暴露的工具。

Hostinger 还记录了速率限制。根据 Connector FAQ，默认额度为每分钟 60 次请求、每小时 1,000 次请求，并且速率限制信息会在响应头中返回。

这些限制对于交互式使用来说已经很宽松，不过自动化或高度重复的工作流仍应避免不必要的重复调用。

易用性

1. 安装与认证

在判断 Hostinger Connector 是否真的能很好地部署和管理托管之前，我首先需要知道它启动起来有多容易。

如果一个以留在编辑器内为卖点的工具，安装却需要编辑配置文件、生成 API 令牌，或者反复重新认证，那么它的吸引力会很快下降。本节只讲设置过程。实际任务测试紧随其后。

安装扩展

我从 VS Code Marketplace 安装了 Hostinger Connector。我搜索“Hostinger”时，它是第一个结果，发布者显示为 Hostinger Official，而且第一次安装就成功了，不到两分钟。

最后一行值得加一句说明。5 星看起来不错，但只有两条评价的样本对我来说几乎说明不了什么。我不会在评测文案里过度依赖这个数字。

有一个前提让我有些意外：Hostinger Connector 提供的是 Hostinger 工具，但要真正调用这些工具，还需要编辑器里已经有一个 AI 代理处于激活状态。

扩展本身什么也做不了。 在 VS Code 中，这个代理就是 GitHub Copilot Chat，因为它目前是 VS Code 提供给 MCP 工具调用的 AI 接口。我已经启用了 Copilot，所以这并没有拖慢我，但读者应该知道，Connector 的实用性取决于编辑器背后是否有可用的 AI 代理。

如果没有安装并登录一个代理，那它就没有可连接的对象。

安装扩展本身并不需要：

• API 密钥
• 从 hPanel 复制的令牌
• 手动编辑 MCP 配置文件
• 本地存储的凭据
• 自定义服务器命令

安装扩展本身是整个测试过程中最顺利的部分之一。唯一真正的限制是 Hostinger 没有放在最显眼位置的一项依赖：该扩展需要编辑器中的一个 فعال AI 代理才能发挥作用。

扩展安装完成后，接下来的问题是，将它连接到真实账户是否也同样简单。

连接账户

账户连接通过一个“1-Click Connect”按钮使用 OAuth 完成。VS Code 在我的浏览器中打开了 Hostinger 授权页面，检测到我现有的 Hostinger 会话，并要求我为一个标记为 hostinger-mcp 的项目批准访问权限。

点击 Allow 后，我被带回 VS Code，界面显示“Connected via OAuth”。

授权界面告诉我，Connector 可以管理网站、托管、域名、订阅以及其他 Hostinger 服务。

这只是一个类别列表，而不是逐项权限明细。我希望这里能更细化一些，因为“管理订阅”和“管理网站”对应的风险级别完全不同。

真正给了我一些控制权的是扩展内的一个独立面板，它列出每个工具类别，并允许我逐项启用或禁用：

总共有 199 个工具，其中 125 个默认启用。我在直接测试它们之前先将 Ecommerce 和 VPS 保持关闭状态，而扩展在整个测试过程中都遵守了这个边界。

这类安全细节不会出现在 Hostinger 的营销页面上，但它对任何正在决定要把多少账户访问权交给 AI 助手的人都很重要。我会把它视为一个真正的优点。

断开账户可以在同一个面板中完成，而不需要更改 Hostinger 密码或寻找存储的令牌。

授权过程很快，也不需要我手动管理令牌，但权限界面过于笼统，而不是逐项细化。扩展内部的类别级工具控制，比 OAuth 界面更能限制实际风险。

支持的编辑器

Hostinger 根据扩展自身的引导屏幕列出了以下受支持客户端：

我使用 VS Code 搭配 GitHub Copilot 作为主要测试环境。

设置过程告诉我 Connector 很容易上手。它还没有回答更难的问题：一旦连接后，它是否真的能做好工作。

2. Hostinger Connector 实战表现

安装和连接扩展只是最简单的部分。真正重要的是它能否正确完成真实的托管工作，所以我构建了一个名为 PulseWatch 的小型 Express.js 应用程序，并让 Connector 走一遍开发者在安装后会经历的同样路径：检查账户、找到部署目标、部署项目、更新它、检查结果，以及从我故意制造的故障中恢复。

PulseWatch 刻意保持简单：一个 Express 服务器、一个主页、一个 package.json start 脚本，以及一个返回 JSON 的 /api/health 端点。后来证明这个健康端点很重要。

托管平台可以报告构建完成，但应用程序在启动时仍然失败。一个实时端点让我可以独立检查已部署进程是否真的在响应，而不是仅仅相信状态徽章。

读取账户数据

我先从只读提示开始，再让助手接触任何实时更改。如果它连我的账户都不能准确描述，那我就没有理由信任它去执行部署、DNS 或 VPS 操作。

Connector 的网站列表工具返回了五个站点：

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

而我的账户实际上拥有更多网站。hPanel 显示网站分布在 Premium、Business 和 Growth 套餐下，包括 WordPress 网站、PHP/HTML 网站、Website Builder 项目以及多个临时域名。

在另一条询问我当前托管计划的提示中，助手告诉我我有“一个有效托管计划”。hPanel 显示的是三个：Premium、Growth 和 Business。

公平地说，当我指出这个差异并要求它重新检查时，Connector 纠正了自己，明确区分了它已经验证过的内容和它曾经假设的内容，而且没有再次重复错误说法。

这比它坚持错误更好，但这也意味着，任何关于账户整体状态的问题，第一次回答都不应被直接当真。

只读访问有效，但关于账户范围的第一个回答并不完整。被质疑后它会纠正自己，这一点很重要，但我本不该需要去质疑它。

账户可见性的这个缺口，后来预示了更大的问题。真正检验它是否重要的，是下一步：当我让 Connector 找一个它从未被明确告知名称的新网站时。

寻找部署目标

这正是测试揭示最多问题的地方。我要求助手在不指定域名、也不触碰任何现有网站的情况下，识别一个新创建的 Node.js 网站。

目标选择对于一个能够作用于真实账户的工具来说，是基本的安全要求，所以我想看看它在面对不确定性时会如何处理，而不是面对一个明确答案时会怎样。

以下是实际发生的顺序：

根本问题是：它使用的两个 ID 是域名资源 ID，而不是托管订单 ID。它在调用实时网站创建工具之前，根本没有确认这一点。

当我让它解释自己的行为时，助手最终给出了准确说明：它一直有一个可用的网站列表工具，却在我通过 hPanel 创建新网站之后没有再次调用它，因此它用一个未经验证的域名来填补空白，而不是刷新数据。

当我要求它明确重新运行那个列表工具并检查是否有新记录时，它却调用了三个无关的部署查询工具，并报告“没有出现新网站”，而它实际调用的这些工具根本无法支持这一结论。

这一切并没有在我的账户里留下任何多余的网站。失败的调用没有产生任何后遗影响。但这个模式值得明确指出：在数据不完整的情况下，助手会用看似合理的假设去填空，把弱信号当作强证据，并在假设被验证之前就对真实账户采取行动。

这是本节最重要的发现。 Connector 会猜测一个目标，并基于这个猜测采取行动，而不是先停下来提问。这里它虽然失败得还算安全，但把弱信号当成证据的习惯，才是你在自己的账户里需要警惕的地方。

既然 Connector 无法独立找到目标，我只剩下一种办法：自己创建目标，看看这是否会改变什么。

在 hPanel 中完成设置

由于 Connector 无法可靠地独立定位新目标，我只好通过 hPanel 手动完成初始设置，看看 Hostinger 在 Connector 部署可行之前会准备什么。

路径如下：创建新网站 → Node.js Web 应用 → 临时域名 → Hostinger 自动选择了位于英国的数据中心，预估延迟为 147ms → 提供三种部署方式可选。

那个第三个界面本身就值得单独指出。Hostinger 将“使用 Hostinger Connector 构建”作为一种部署方式，与 GitHub 导入和手动文件上传并列展示。我选择它，是以为它会完成该网站的设置。

结果它把我重定向到了 Connector 自己的安装页面，而这个我早就已经完成了。这是一个真正的引导缺口。那个被呈现为 Connector 原生路径的选项，实际上并没有完成任何部署。

于是我返回去选择了手动文件上传。Hostinger 接受了我的项目压缩包（11.46 KB，已排除 node_modules），设置页面显示自动检测结果准确无误：

• 框架预设：Express
• Node 版本：22.x
• 根目录：./

我点击了 Deploy。部署成功完成，Hostinger 分配了一个真实的临时域名：orange-walrus-700988.hostingersite.com。这与 Connector 之前捏造的域名不同。我手动打开主页和 /api/health，并确认两者都可正常工作。

一旦我不再等待 Connector 替我寻找目标，手动路径就运行顺畅了。“Build with Hostinger Connector” 按钮应该被修复或移除。现在它承诺了自己做不到的事情。

现在一个真实、已确认的网站已经存在。下一个问题是：当 Connector 面对一个明确存在的目标时，它的表现是否会不同。

部署并更新线上应用

在一个真实、已确认的网站就位后，我回到 Connector 并要求它检查那个确切的域名。这一次它运行得很顺利。

这确认了一件重要的事：之前的失败与定位和创建新目标有关，而不是与 Connector 在已有 Node.js 网站上工作的能力有关。

接下来，我测试了 Hostinger 最强调的功能：在本地修改一行代码，然后无需打开 hPanel 就发布出去。

我要求助手将主页文案从“Monitor Every Service. Catch Every Issue.”改为“Monitor Every Service. Resolve Issues Faster.”

整个更新大约花了一分钟。助手在提交后立即把新部署报告为“pending”，只是因为它检查得太早，Hostinger 还没处理完。

当我自己刷新线上网站时，新标题已经上线了。

它随后检索到的构建日志非常具体且有用：新增 67 个包，审计 68 个包，未发现漏洞，没有错误。

对于已存在的网站，这几乎就是 Hostinger 承诺的工作流。编辑、在本地验证、发布，并在大约一分钟内确认结果，全程无需离开编辑器。这是整个测试中最强的一项结果。

一次顺利部署只能说明成功路径可用。为了看看 Connector 在压力下究竟会怎样，我故意把应用弄坏了。

测试故障恢复

只有在真实故障面前依然可靠的工具，才算真正赢得信任，而不仅仅是在一个干净的演示里表现正常。我故意破坏了应用，想看看 Connector 的状态报告和日志是否真的能帮助我诊断问题。

在做任何改动之前，助手先把 package.json 备份为 package.json.bak，这本身就是个好习惯。

然后我让它把启动脚本从“start”: “node server.js”改成“start”: “node missing-server.js”，这个文件并不存在。

在本地运行证实了一个真实且可复现的错误：Error: Cannot find module ‘…/missing-server.js’.

我故意把这个损坏版本也部署了出去，想看看 Hostinger 会如何报告。

Connector 获取到的构建日志只显示了依赖安装成功，其他内容都没有。那个缺少模块的运行时错误并未出现在日志里。一个只看见绿色“completed”徽章的开发者，根本不会怀疑网站其实已经坏了。

恢复过程很顺利。助手从备份中还原了 package.json，在本地验证应用，然后重新部署，并且通过直接调用线上 /api/health 端点确认修复，而不是仅仅相信部署状态。

那个端点返回了可运行的响应，这是整个测试中唯一真正证明应用在运行的证据。

这是第二个主要发现。完成状态并不证明应用正在运行，而 Connector 自己的日志也不会告诉你这一点。一旦我知道存在问题，恢复本身表现得很好。

在经历了一个状态徽章无法揭示的故障之后，我想知道 Connector 的自信还会在哪些地方超出它的实际能力。环境变量是下一个测试项目。

尝试配置环境变量

我要求助手添加一个无害的环境变量，在动任何东西之前先确认是否存在专门的 Connector 能力，如果没有就停止。

它搜索了可用工具，没有找到用于管理 Node.js 环境变量的专门操作，于是停止了，没有修改任何代码或部署内容。

这才是我希望在本次测试其他地方也能看到的行为。面对真实限制时，它停下来了，没有去猜。我不会据此断言 Hostinger Connector 在其工具集中任何地方都没有环境变量支持，只能说明在本次测试中没有暴露出这样的操作。 

故障与恢复测试总结

这次测试对可靠性的说明

Hostinger Connector 在常规、确定性任务上表现良好：

• 读取已知部署记录
• 编辑指定文件
• 运行本地命令
• 打包项目
• 部署到已知网站
• 检查构建状态
• 检索可用日志
• 还原并重新部署一个已知可用版本

而在需要基于不完整账户数据进行解释时，它就弱一些：

• 识别新创建的网站
• 区分域名可访问性与网站存在性
• 判断完成的构建是否意味着应用健康

这种模式在决定给助手多大自主权时很有参考价值。

低风险检查可以使用更宽泛的提示。对于会更改线上基础设施的操作，则应使用更精确的提示，并要求明确确认。

例如，不要这样说：

而应这样说：

第二个提示缩小了助手进行假设的空间。

易用性总体结论

让 Hostinger Connector 运行起来很容易，几乎没有传统的设置摩擦，而细粒度的工具类别控制让我能真正决定 AI 可以接触什么。

一旦存在一个已知域名的真实网站，它就能很好地完成工作：一个单行复制修改，从编辑到上线大约只用了 1 分钟，并且有有用的构建日志作为佐证。

问题出现在更早的流程中，而不是后面。面对一个它无法找到的新目标时，Connector 会在检查之前先捏造一个域名并据此行动。它还会在应用实际上已宕机时把破损部署标记为“completed”，而它自己的日志里也没有运行时错误。这些问题并不意味着它不适合管理已有网站，但这确实意味着，对新的部署和部署后的状态，你在完全信任之前应该再核对一次。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

浏览 Hostinger

支持水平

Hostinger 将支持建立在实时聊天和自助服务之上，而不是电话支持，因此我把测试重点放在大多数用户真正会接触到的地方：hPanel 中内置的 AI 助手、其背后的人类升级支持，以及开发者在打开聊天窗口之前会使用的知识库。

支持渠道

鉴于实时聊天是 Hostinger 面向开发者在紧急情况下推荐的渠道，也是最可能在调试部署时真正被使用的渠道，我直接测试了这条路径，而不是先提交一封电子邮件工单。

实时聊天：Kodee 与人工接手

我通过 hPanel 中的“Ask AI”打开实时聊天，并向 Kodee 提了一个容易出错的问题：Node.js 部署中显示构建完成，是否就意味着应用实际上正在运行，以及如果不是，我该在哪里找到证据。

Kodee 的第一条回复具体而正确：

“Completed”通常只意味着构建步骤成功完成；这并不能保证应用在启动后仍然健康。要捕捉错误的启动命令或其他运行时崩溃，请查看运行时日志：在 hPanel 中进入 Websites → Dashboard → Deployments 查看构建日志，然后打开你应用在 nodejs 文件夹中的 stderr.log，查找类似 Port already in use 或 Module not found 之类的启动错误。

这一条回答就足以解释本评测前面的故障恢复测试中遇到的确切歧义。Kodee 指出了一个真实的日志文件、正确的文件夹，并准确区分了构建成功与运行时健康。

不过，我还想看看是否能接通真人客服，所以我告诉 Kodee，我想直接向支持工程师确认这一点。

但联系真人比我预期的更难。我直接要求一位真人客服，却两次被带回 Kodee，每次都被包装成“更快”的选择：

我理解你为什么会这样想。我可以在这里帮你验证构建、启动命令和运行时日志，这通常是最快定位问题的方法。

在为你排队一位专家之前，我可以解决这个问题并替你节省等待时间。

我连续两次明确提出请求后，Kodee 才停止把我重新带回自己这里。对于一个我自己就能解决的问题，这种阻碍只是小麻烦。对于正在遭遇故障、并希望有人接手的人来说，这会非常令人沮丧。

接下来发生的并不是人们通常理解的那种实时转接。Kodee 直接说明了实际模型：

我已将你的请求转交给我们团队中的一位专家，他会亲自审查我们的聊天记录并把答案发送给我，然后由我在这里转达给你。

这是一种异步审核，而不是实时转接。Kodee 仍然是界面；真人在后台审查对话，等答案到来后再由 Kodee 转达。这个区别很重要，因为它会影响读者对是否升级处理的判断；在这里，“真人客服”并不意味着像大多数实时聊天系统那样有新的人直接进入聊天窗口。

在等待期间，我继续追问同一技术线索，要求 Kodee 确认确切的日志路径以及 stderr.log 是否总是会有内容。它给出了一个可靠的回答，正确指出如果应用从未完全启动或把错误写到了别处，这个日志可能是空的。

大约 3 分钟后，名为 Mayas 的同事在聊天中给出了专家审核结果，这个答案比 Kodee 的更好，而不是简单重复：

domains/[your-domain]/nodejs/stderr.log 是正确位置。它并不总是被生成或填充。只有当应用向 stderr 写入内容时，比如未捕获异常或未处理的拒绝，那里才会有条目。如果启动命令错误而进程静默退出，stderr.log 可能为空或缺失。

Mayas 还补充了两个 Kodee 没有提到的备用检查：查看 stdout.log 以了解崩溃前的最后输出，以及寻找缺少启动确认行作为应用从未启动的迹象。

知识库

Hostinger 的知识库按宽泛的产品类别组织：Getting Started、hPanel、Website Builder、Hostinger Horizons、Domains、DNS、Files Management、Email、MySQL Databases、Website、VPS、Agency Hosting Plans、Hostinger Reach、SSL Certificates、PHP、Profile Management、Billing、Affiliates and Referrals、Features、cPanel 和 About Hostinger。

这些类别中没有一个是专门给 Hostinger Connector 的。我找到正确文章的唯一方式是直接搜索“Hostinger Connector”，结果返回了五条内容，大多只是松散相关，包括一个联盟营销插件指南和一篇通用的 Node.js 托管文章。

真正记录 Connector 设置的文章标题是“How to Set Up Web Hosting MCP on Local IDEs”，归类在 Features → General Information 下。

用产品的营销名称搜索可以找到它，但如果读者只是浏览分类，或者不知道 Hostinger 的品牌命名而只搜索“MCP”，就很容易错过，而营销名称与文档名称不一致这一点值得在查找前就知道。

找到之后，这篇文章本身很强。它在我测试前 6 天刚刚更新，内容涵盖：

• 通过扩展进行推荐的一键 OAuth 设置
• 适用于扩展不直接支持的 IDE 的手动设置路径，使用 API 令牌
• Mac、Linux 和 Windows 的确切配置文件路径
• 完整的 JSON 配置示例
• 用于确认连接成功的逐步验证提示
• 哪些受支持客户端会自动检测连接，哪些需要手动填写配置

最后一点与我测试中遇到的情况一致：Devin Desktop 可以自动检测，而 OpenAI Codex 需要手动方法。文章对此区分是正确的。

支持总体结论

Kodee 对一个困难技术问题的第一条回答准确且具体，这不是所有 AI 支持助手都能做到的。支撑它的知识库文章一旦找到也很新且很详细，不过产品的营销名称与文档标题并不一致，所以搜索比浏览分类更可靠。

较弱的一点是人工升级路径。Kodee 两次把我带回它自己那里，才最终接受我想找真人的直接请求，而且即使如此，“真人客服”指的也不是实时转接，而是通过同一个聊天窗口异步审核并转述。等到真人真的审查后，答案比 Kodee 的更好、更精确，也多了两个 Kodee 没提供的诊断步骤。

对于大多数问题，单靠 Kodee 就能快速给出准确答案。如果你确实想让真人来核实答案，预计需要不止一次请求，而且要接受一段等待时间，得到的是转述后的回复，而不是实时对话。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

浏览 Hostinger

最终结论：Hostinger Connector 值得使用吗？

值得，前提是你已经在 Hostinger 上托管网站，并希望在编辑器里处理常规部署。设置只花了几分钟，OAuth 不需要任何 API 密钥，而且一旦存在一个已知域名的网站，Connector 就能在大约 1 分钟内把一次实时更新发布出去，并提供日志作为支撑。Kodee 自身的支持回答也足够敏锐，第一次就解决了一个真实技术问题。

问题在于信任，而不是便利性。面对一个它无法找到的新目标时，Connector 会先捏造一个域名，再基于它采取行动。

它还会在应用实际上已宕机时把破损部署标记为“completed”，而它自己的日志里也没有运行时错误。把它用于已经存在的网站可以加快工作流程；但任何针对全新目标的操作都要先核实，而对任何重要部署之后，也要亲自检查线上网站。

Hostinger

5.0

2,470 user reviews

￥11 /mo

起步价

浏览 Hostinger

Rating based on expert review

• 用户体验
  4.9
• 技术支持
  4.9
• 功能
  4.8
• 可靠性
  4.7
• 定价
  4.5