管理主機服務通常會打斷開發流程。你喺編輯器入面寫程式，打開主機控制台建立網站，切換去終端機打包或推送專案，再返回控制台檢查部署，當 DNS、日誌或伺服器資源需要處理時，還要再打開更多工具。
Hostinger Connector 透過 Model Context Protocol（MCP）減少呢種情境切換。佢將 Hostinger 服務連接到 AI 編碼工具，讓你可以喺唔離開編輯器嘅情況下，叫 AI 助手檢查或管理受支援嘅主機資源。
呢樣聽落好方便。但更重要嘅問題係：你可唔可以信任 AI 助手準確執行真正嘅主機工作？
為咗搵答案，我用 VS Code 同 GitHub Copilot，喺一個真實嘅 Hostinger 帳戶上測試 Hostinger Connector。我用一個名為 PulseWatch 嘅細型 Express.js 應用程式，並跟住由安裝到正式部署嘅流程。我亦測試咗重複部署、建置記錄、日誌，以及刻意破壞應用程式啟動指令後嘅復原。
以下係我按對開發者決定是否使用 Hostinger Connector 最重要嘅範疇去評分：成本、功能範圍、日常可用性、佢執行真正工作嘅準確度，以及出事時背後支援嘅表現。每個分數都反映我實測所得，而唔係宣傳頁面。
| Parameter | Score | Why this score |
|---|---|---|
| Prices | 9.7/10 | Connector 完全冇額外訂閱費，並且隨每個計劃免費附送。唯一成本就係你本來都要用嘅底層主機資源。 |
| Features | 9.5/10 | 功能範圍唔止部署，仲涵蓋網站、網域、DNS、資料庫、電郵推廣、VPS 資源、日誌同診斷，比一般部署工具覆蓋更多範圍。 |
| Ease of Use | 9.1/10 | 安裝同 OAuth 都好快，亦唔需要手動設定，重複部署亦好容易。初次 Node.js 網站設定需要用 hPanel，因為 AI 未能識別出有效目標，呢個係整體順暢流程中唯一嘅缺口。 |
| Execution Accuracy | 8.5/10 | 專案分析、程式編輯、打包、部署同復原都表現良好。不過 AI 重用咗一個捏造嘅網域，並喺該目標尚未存在前過度解讀咗可及性檢查。 |
| Support | 9.5/10 | Kodee 第一次就對一個真實技術問題畀出準確而具體嘅答案，而人類專員嘅跟進更加精準。升級處理需要兩次直接要求，但一旦回應，AI 同人類答案都可靠。 |
| Overall | 9.3/10 | 對喺支援 AI 嘅編輯器工作、又已經係 Hostinger 用戶嘅人嚟講，呢個係一個有價值嘅工作流程工具。佢冇額外成本、涵蓋範圍廣，而且安裝同支援表現都經得起測試。對新部署目標嘅執行準確度係唯一要留意嘅地方。 |
Hostinger Connector 並唔係獨立銷售嘅產品。Hostinger 表示 Connector 會免費包含喺每個計劃之內，亦即係話你嘅主機帳單唔會額外加上一筆 Connector 月費。
不過，「免費」要有脈絡先有意思。Connector 管理嘅係 Hostinger 資源；佢唔係取代資源本身。你仍然需要一個合資格嘅 hosting、cloud、VPS、domain、email 或其他 Hostinger 服務，先可以執行你想要佢做嘅工作。
喺本次評測時間，Connector 登陸頁面重點顯示 Business Web Hosting 同 Cloud Startup。
| Plan | Promotional price | Upfront term shown | Renewal price | Web apps | Websites |
|---|---|---|---|---|---|
| Business | $3.79/month | $181.92 for 48 months | $16.99/month | 5 | 50 |
| Cloud Startup | $7.99/month | $383.52 for 48 months | $25.99/month | 10 | Unlimited |
價格係未計適用稅項前顯示。推廣價同續約價都可能變動，所以應該睇目前結帳總額，而唔係只憑標示嘅月費去判斷計劃。
價格洞見： 唔好只係為咗使用 Connector 而買更高級計劃。應該根據你需要嘅網站數量、web app 數量、所需資源，以及你想要嘅支援級別去選擇計劃。Connector 係一個包含喺內嘅管理層，而唔係主要定價產品。
Hostinger 公布適用嘅主機購買可享 30 天退款保證。因為 Connector 冇獨立收費，所以冇單獨嘅 Connector 退款政策要評估。
可用嘅具體動作會視乎你帳戶內嘅 Hostinger 服務，以及連接嘅 AI 客戶端所暴露嘅工具而定。
Hostinger 亦有文件記載速率限制。根據 Connector FAQ，預設配額係每分鐘 60 次請求同每小時 1,000 次請求，而速率限制資訊會喺回應標頭返回。
對互動式使用嚟講，呢啲限制相當寬鬆，不過自動化或者高度重複嘅工作流程仍然應該避免不必要嘅重複呼叫。
喺我可以判斷 Hostinger Connector 是否真係能夠良好地部署同管理主機之前，我首先要知道佢本身要幾多功夫先可以運作。
一個主打留喺編輯器內操作嘅工具，如果設定要改 config 檔、產生 API token，或者反覆重新認證，吸引力會好快消失。呢一節只講設定；實際任務測試會喺之後出現。
我喺 VS Code Marketplace 安裝咗 Hostinger Connector。我搜尋 “Hostinger” 時，佢係第一個結果，出版者標示為 Hostinger Official，並且喺第一次嘗試下於兩分鐘內完成安裝。
| Detail | Result |
|---|---|
| Marketplace search | Passed, appeared immediately |
| Publisher verification | Hostinger Official |
| Installation | Completed in under two minutes |
| Extension version at time of testing | 1.3.1 |
| Marketplace installs | 8,140 |
| User rating | 5 stars, based on two ratings |
最後一行值得加一個保留。五星聽起來好勁，但只有兩個評論樣本，對典型用戶體驗幾乎無法提供任何資訊。我唔會喺評測文案入面太倚賴呢個數字。
有一個前提令我有啲意外： Hostinger Connector 提供 Hostinger 工具，但實際呼叫佢哋需要編輯器內已經有一個 AI agent 活躍緊。
擴充功能本身冇任何嘢可以自行對話。喺 VS Code 入面，呢個 agent 就係 GitHub Copilot Chat，因為目前 VS Code 所暴露用於 MCP 工具呼叫嘅 AI 介面就係佢。我本身已經開住 Copilot，所以冇拖慢我，但讀者應該知道 Connector 只係同背後嘅 AI agent 一齊先有用。
如果冇安裝同登入，佢就冇嘢可以連接。
安裝擴充功能本身唔需要：
安裝擴充功能本身係整個測試最順暢嘅部分之一。唯一真正嘅陷阱係 Hostinger 冇喺最前面講清楚嘅依賴：擴充功能需要一個喺編輯器內活躍緊嘅 AI agent 先可以做任何事。
裝好擴充功能之後，下一個問題係連接真實帳戶會唔會同樣簡單。
帳戶連接係透過「1-Click Connect」按鈕使用 OAuth 完成。VS Code 會喺我嘅瀏覽器打開 Hostinger 授權頁面，偵測到我已經登入緊嘅 Hostinger session，並要求我批准一個標示為 hostinger-mcp 嘅存取權。
我一按 Allow，就返回 VS Code，畫面顯示「Connected via OAuth」。
| Check | Result |
|---|---|
| One-click connection | Passed |
| Browser opened automatically | Passed |
| Existing Hostinger session detected | Passed |
| Manual API token required | No |
| Authorization screen shown | Yes |
| Permissions explained | Yes, but broadly |
| Returned to VS Code successfully | Passed |
授權畫面話畀我知 Connector 可以管理 websites、hosting、domains、subscriptions 同其他 Hostinger 服務。
呢個只係一個類別列表，唔係按權限逐項拆開。我會希望呢度更細緻，因為「管理 subscriptions」同「管理 websites」涉及嘅風險層級非常唔同。
不過，真正幫我控制到部分風險嘅係擴充功能入面另一個面板，佢列出所有工具類別，並且容許我逐項啟用或停用：
| Tool category | Tools available | Default status |
|---|---|---|
| Websites | 80 | Enabled |
| Domains | 26 | Enabled |
| Subscriptions and Payments | 7 | Enabled |
| Email Marketing | 12 | Enabled |
| Ecommerce | 12 | Disabled |
| VPS | 62 | Disabled |
總共有 199 個工具，其中 125 個預設啟用。我保持 Ecommerce 同 VPS 關閉，直到我準備好直接測試佢哋，而擴充功能喺整個測試過程都尊重呢個邊界。
呢種安全細節喺 Hostinger 宣傳頁面上睇唔到，但對於要決定交幾多帳戶權限畀 AI 助手嘅人嚟講非常重要。我會稱之為真正嘅優點。
你可以喺同一個面板入面斷開帳戶，而唔需要更改 Hostinger 密碼或者去搵儲存咗嘅 token。
授權過程快捷，而且唔需要我自己管理 token，但權限畫面屬於廣泛描述，而唔係逐項細分。擴充功能入面按類別控制工具嘅功能，對限制實際風險比 OAuth 畫面本身更有幫助。
Hostinger 按擴充功能本身嘅導覽畫面列出以下支援客戶端：
| Editor or client | Listed by Hostinger |
|---|---|
| VS Code | Yes |
| Cursor | Yes |
| Windsurf | Yes |
| Devin Desktop | Yes |
| Antigravity | Yes |
| Claude Code | Yes |
| OpenAI Codex CLI | Yes |
我主要用 VS Code 配 GitHub Copilot 作為測試環境。
設定話畀我知 Connector 容易接觸到。佢仲未講到一旦連接後，實際上會唔會做得好，呢個更難嘅問題我接住就會測。
安裝同連接擴充功能係最易嘅部分。真正重要嘅係佢可唔可以正確完成真實主機工作，所以我建立咗一個名為 PulseWatch 嘅細型 Express.js 應用程式，並用 Connector 行一遍開發者安裝後通常會走嘅路：檢視帳戶、搵部署目標、部署專案、更新專案、檢查結果，以及從我故意引入嘅失敗中復原。
| Test | What I wanted to learn |
|---|---|
| Read account data | Can it accurately understand the hosting account? |
| Find a deployment target | Can it identify the right website without guessing? |
| Analyze the Node.js project | Does it understand the app before touching it? |
| Deploy PulseWatch | Can it move a real project from editor to live hosting? |
| Publish a content update | Is it useful for routine development work? |
| Inspect builds and logs | Does it give useful evidence after a deployment? |
| Deploy a broken version | Does it reveal a real application failure? |
| Recover the application | Can it restore a known-good release safely? |
PulseWatch 刻意保持簡單：一個 Express 伺服器、一個首頁、一個 package.json start script，同埋一個回傳 JSON 嘅 /api/health 端點。之後證明咗呢個 health 端點相當重要。
主機平台可以顯示建置完成，但應用程式啟動時仍然失敗。實際可運作嘅端點畀咗我另一個方法去檢查部署後嘅程序係咪真係有回應，而唔係單靠狀態徽章。
我先從唯讀提示開始，之後先容許助手接觸任何實際更改。如果佢連我個帳戶都描述唔準確，我就冇乜理由信任佢去做部署、DNS 或 VPS 操作。
Connector 嘅網站列表工具返回五個網站：
我嘅帳戶實際上有更多網站。hPanel 顯示網站分佈喺 Premium、Business 同 Growth 計劃之下，包括 WordPress 網站、PHP/HTML 網站、Website Builder 專案，同埋幾個臨時網域。
喺另一個問我有幾多個有效 hosting 計劃嘅提示入面，助手話我得「一個有效 hosting 計劃」。hPanel 顯示有三個：Premium、Growth 同 Business。
| Check | Result |
|---|---|
| Listed known websites | Passed |
| Listed all hosting plans | Failed |
| Detected the unused Business plan | Failed |
| Made any account changes | No |
公平啲講，當我指出呢個差異後，Connector 其實有更正，清楚區分咗佢已驗證嘅內容同佢作出假設嘅內容，亦冇再重複錯誤說法。
呢個失誤模式比起硬拗到底好，不過亦代表有關整個帳戶嘅問題，第一次回答唔應該照單全收。
唯讀存取有效，但任何關於整個帳戶嘅問題，第一次答案都唔完整。佢喺被挑戰後會更正，呢點重要，但我唔應該要先挑戰佢。
帳戶可見性上嘅呢個缺口，原來係更大問題嘅預告。真正測試佢係咪重要，就係下一步：當我要求佢搵一個未曾以名稱告知過嘅新網站時。
呢個地方暴露最多問題。我要求助手識別一個新建立嘅 Node.js 網站，但唔向我提供網域名稱，而且唔好觸碰任何現有網站。
對一個可以對實際帳戶執行操作嘅工具嚟講，目標選擇係基本安全要求，所以我想睇吓佢喺不確定情況下會點做，而唔係處理一個乾淨答案。
以下係發生嘅順序：
| Step | What the Connector did | Result |
|---|---|---|
| 1 | Reused a domain name from an earlier failed attempt: pulsewatch-temp-20260714.hostingersite.com | This domain had never been returned by any website-listing call |
| 2 | Ran an accessibility check on that domain | Returned is_accessible: true |
| 3 | Treated that result as confirmation the website existed | Incorrect. Accessibility is not the same as an existing, deployable website record |
| 4 | Attempted deployment using resource IDs it had not verified as hosting order IDs | Hostinger returned [Hosting:9999] Not found, twice |
根本問題係：佢用嘅兩個 ID 係網域資源 ID，而唔係 hosting order ID。喺對真實網站建立工具落手之前，佢從未確認過呢個分別。
當我要求佢解釋自己時，助手最終畀出咗準確說法：佢其實一開始一直都有一個可用嘅網站列表工具，但喺我透過 hPanel 建立新站之後，佢冇再呼叫一次，而係用一個未經核實嘅網域去填補空白，唔係重新整理資料。
當我直接要求佢重新執行該列表工具，並檢查有冇新記錄時，佢反而呼叫咗三個不相關嘅部署查詢工具，並報告「冇新網站出現」，而佢實際呼叫嘅工具根本唔足以支持呢個結論。
以上情況冇喺我帳戶入面製造任何多餘網站。失敗呼叫冇留下任何痕跡。但呢種模式值得直接講明。當資料唔完整時，助手會用聽落合理嘅假設去填補空白，將弱訊號當成強證據，並喺假設未驗證前對實際帳戶採取行動。
呢個係本節最重要嘅發現。 Connector 會對一個目標作出推測，並根據呢個推測去行動，而唔係停低問清楚。喺呢度佢失敗得算安全，但喺你自己帳戶入面，要小心嘅就係呢種將弱訊號當證據嘅習慣。
既然 Connector 自己搵唔到目標，我只剩低一個選項：自己建立目標，睇吓會唔會改變情況。
既然 Connector 無法可靠地自行搵到新目標，我就透過 hPanel 手動完成初始設定，睇吓 Hostinger 喺 Connector 部署之前會準備啲乜。
流程係：建立新網站 → Node.js web app → 暫時網域 → Hostinger 自動揀咗一個英國資料中心，估計延遲 147ms → 提供三種部署方式。
第三個畫面本身都值得特別指出。Hostinger 將「Build with Hostinger Connector」作為部署方式之一，同 GitHub import 同手動檔案上載並列。我原本以為揀呢個會完成網站設定。
結果佢只係重新導向去 Connector 自己嘅安裝頁面，而我已經完成過安裝。呢個係真實嘅上手流程缺口。作為 Connector 原生路徑嘅選項，實際上並冇幫我完成任何佈建。
我退返去，改用手動檔案上載。Hostinger 接受咗我嘅專案壓縮檔（11.46 KB，已排除 node_modules），而設定畫面顯示自動偵測正確：
我按咗 Deploy。部署成功完成，而 Hostinger 指派咗一個真正嘅暫時網域：orange-walrus-700988.hostingersite.com。呢個同 Connector 之前捏造出嚟嘅網域唔同。我手動打開首頁同 /api/health，確認兩個都可用。
當我唔再等 Connector 搵目標之後，手動路徑就完全順利運作。呢個畫面上「Build with Hostinger Connector」按鈕應該修正或者移除。依家佢承諾咗一樣其實冇做到嘅事。
而家有一個真實、已確認嘅網站存在。下一個問題係：當 Connector 面對一個實在嘅目標時，表現會唔會唔同。
有咗一個真實、已確認嘅網站之後，我返去用 Connector 要求佢檢視嗰個確切網域。呢次佢做得好順。
| Check | Result |
|---|---|
| Recognized the site as a Node.js deployment target | Passed |
| Found the completed deployment record | Passed |
| Found the matching Node.js build record | Passed |
| Deployment and build shared the same UUID | Passed |
呢個確認咗一樣好重要嘅事：之前嘅失敗係因為搵新目標同建立新目標，而唔係 Connector 無法同一個已存在嘅 Node.js 網站合作。
接住我測試 Hostinger 最重點宣傳嘅功能：喺本地改一行程式碼，然後唔打開 hPanel 就發布上線。
我要求助手將首頁文字由「Monitor Every Service. Catch Every Issue.」改做「Monitor Every Service. Resolve Issues Faster.」
| Step | Result |
|---|---|
| Found the existing text | Passed |
| Changed only the requested line | Passed |
| Verified the app locally before deploying | Passed |
Packaged the project, excluding node_modules and .git | Passed |
| Deployed to the existing, confirmed website | Passed |
| Checked deployment and build status afterward | Passed |
整個更新大約用咗一分鐘。助手喺提交部署之後即刻話新部署「pending」，純粹因為佢查詢嘅時間早過 Hostinger 完成處理。
等我自己重新整理 live site 時，新標題已經出現咗。
佢之後擷取到嘅建置日誌好具體亦有用：新增 67 個套件、檢查 68 個套件、零漏洞、冇錯誤。
對已存在嘅網站而言，呢個幾乎就係 Hostinger 承諾嘅工作流程：編輯、喺本地驗證、發佈，全部唔使離開編輯器，大約一分鐘完成。呢個係成個測試入面最強嘅結果。
一次成功部署只證明快樂路徑可行。為咗睇吓 Connector 喺壓力下到底會點，我故意破壞咗應用程式。
一個工具要獲得信任，必須捱得過真實故障，而唔只係乾淨示範。我刻意破壞應用程式，睇吓 Connector 嘅狀態報告同日誌係咪真係可以幫我診斷問題。
喺做任何改動之前，助手先將 package.json 備份做 package.json.bak，呢個本身就係一個好習慣。
之後我叫佢將 start script 由「start”: “node server.js” 改成「start”: “node missing-server.js”，一個根本唔存在嘅檔案。
喺本地執行確認咗一個真實可重現嘅失敗：Error: Cannot find module ‘…/missing-server.js’.
我刻意部署咗壞版本，想睇吓 Hostinger 會報告乜。
| Status shown | What it confirmed | What it did not confirm |
|---|---|---|
| Build: completed | Dependencies installed, build stage finished | The application actually started |
| Deployment: completed | Hostinger accepted and processed the release | Every route was healthy |
透過 Connector 擷取到嘅建置日誌，只顯示依賴安裝成功，而冇其他內容。缺少模組嘅執行階段錯誤完全冇出現喺入面。淨係睇住綠色「completed」徽章嘅開發者，根本唔會有理由懷疑網站已經壞咗。
復原過程好順利。助手由備份還原 package.json，喺本地驗證應用程式，重新部署，然後唔係信部署狀態，而係直接呼叫 live /api/health 端點確認修復。
呢個端點回傳咗正常運作嘅回應，而呢個係整個測試入面唯一真係證明應用程式有運行嘅證據。
呢個係第二個主要發現。完成狀態唔代表應用程式一定正常，而 Connector 自己嘅日誌亦唔會話你知呢一點。知道有問題之後，復原本身做得相當好。
經歷咗一個狀態徽章未能揭示嘅故障之後，我想知道 Connector 喺其他地方會唔會同樣過份自信。環境變數就係下一個測試。
我要求助手加入一個無害嘅環境變數，喺改任何嘢之前先確認係咪有一個專屬嘅 Connector 功能，冇就停手。
佢搜尋可用工具，發現冇專門處理 Node.js 環境變數嘅動作，並且喺未作出任何程式碼或部署改動前停咗手。
呢個就係我喺測試其他地方最想見到嘅行為。面對真實限制時，佢停咗低，而唔係亂估。我唔會因為今次測試冇見到相關動作，就斷定 Hostinger Connector 喺任何地方都冇環境變數支援；我只可以話喺今次測試中，冇暴露呢類動作。
| Test | Result | Key finding |
|---|---|---|
| Back up working manifest | Passed | Recovery file created before modification |
| Introduce missing entry point | Passed | Controlled failure added |
| Reproduce failure locally | Passed | MODULE_NOT_FOUND confirmed |
| Deploy broken version | Passed | Hostinger accepted the archive |
| Build status detects failure | Failed | Build still showed completed |
| Build logs expose runtime error | Failed | Missing-module error was absent |
| Restore working manifest | Passed | Original start command recovered |
| Redeploy working version | Passed | Deployment completed |
| Verify live health endpoint | Passed | API returned operational status |
Hostinger Connector 喺處理例行、可預測嘅工作時表現良好：
當任務需要喺不完整帳戶資料之間作出解讀時，佢就弱啲：
呢個模式對決定要畀助手幾多自主權好有用。
對低風險檢視，用較寬鬆嘅提示。對會改動正式基礎設施嘅動作，就要用更精確嘅提示同明確確認要求。
例如，唔好用：
| Deploy this app to a new temporary Hostinger site. |
而應該用：
| List the websites currently returned by Hostinger. Identify a Node.js website only if it appears in that result. Show me the exact domain and evidence before deploying. Do not generate, infer, or reuse a domain that was not returned by Hostinger. |
第二個提示限制咗助手作出假設嘅空間。
啟動 Hostinger Connector 好容易，幾乎冇一般安裝麻煩，而工具類別控制亦令我真係可以決定 AI 可以接觸啲乜。
一旦有一個已知網域嘅真實網站存在，佢就做得好：一個字嘅內容改動可以喺大約一分鐘內由編輯到上線，仲有有用嘅建置日誌做支持。
問題出喺前面，而唔係後面。面對一個佢未見過嘅新目標時，Connector 會捏造一個網域，並喺未驗證前就據此行動。佢亦會喺應用程式其實已經失效時，將一個壞部署標成「completed」，而自己嘅日誌又冇顯示執行階段錯誤。呢兩個問題唔代表工具對既有網站唔可靠，但意味住新部署同部署後狀態都要再睇多次，先好完全信任。
Hostinger 以即時聊天同自助資源為支援核心，而唔係電話支援，所以我將測試集中喺開發者最常會用到嘅地方：hPanel 入面嘅 AI 助手、背後嘅人類升級處理，以及開啟聊天之前開發者可能會先用嘅知識庫。
| Channel | Availability | Notes |
|---|---|---|
| Live chat (Kodee, AI) | 24/7 | 透過 hPanel 入面嘅「Ask AI」進入 |
| Live chat (human) | Escalation only | 唔係直接排隊，而係經 Kodee 轉介 |
| Email / ticket | support@hostinger.com | 聲稱回覆時間為 1 個工作天 |
| Phone | Not offered | 冇公開一般支援電話 |
| Knowledge Base | Self-service | support.hostinger.com |
| Tutorials and Academy | Self-service | 逐步指南同 YouTube 頻道 |
既然即時聊天係 Hostinger 指向開發者處理緊急問題嘅渠道，而且亦係好可能喺除錯部署時實際會用到嘅渠道，我直接測試咗呢條路，而唔係只係提交電郵 ticket。
我透過 hPanel 入面嘅「Ask AI」打開即時聊天，然後問 Kodee 一條有明確答案可錯嘅問題：一個 Node.js 部署嘅 completed 建置狀態，係唔係等於應用程式一定真係運行緊，以及我可以喺邊度搵到相反證據。
Kodee 嘅第一個回應具體而且正確：
「Completed」通常表示建置步驟成功完成；佢唔代表應用程式啟動後一定健康。要捉到錯誤嘅 start command 或其他執行階段崩潰，請檢查 runtime logs：喺 hPanel 去 Websites → Dashboard → Deployments 睇 build logs，然後打開你 app 嘅 nodejs 資料夾入面嘅 stderr.log，尋找例如 Port already in use 或 Module not found 呢類啟動錯誤。
呢個答案本身已經可以解決我前面故障復原測試入面遇到嘅同一個歧義。Kodee 指出咗真實嘅 log file、正確資料夾，亦正確分清楚建置成功同執行健康嘅分別。
不過，我亦想睇吓可唔可以直接接觸到真人客服，所以我同 Kodee 講，我想直接同支援工程師確認。
但要搵真人出嚟比我預期中難。我直接要求真人客服，但兩次都被轉返去 Kodee，每次都被包裝成比等候更快：
I understand why you’d want that. I can help you verify the build, start command, and runtime logs right here, which is usually the fastest way to pinpoint the issue.
Before we queue a specialist. I can resolve the issue and save you the wait.
| Attempt | My request | Kodee’s response |
|---|---|---|
| 1 | “Can you connect me with a live agent?” | Offered to solve it itself |
| 2 | “I’d still like to speak with a human agent. Please connect me.” | Offered again, asked for domain and start command |
| 3 | Clicked “Go to human” / typed “I want to continue with a human” | Escalated |
我需要兩次直接、明確嘅要求，Kodee 先停止將我導返去自己。對一個我自己可以解決嘅問題嚟講，呢種阻力唔算大。不過對一個正喺故障中、而且想搵真人嘅人嚟講，呢個就係真真正正令人沮喪嘅地方。
之後發生嘅，並唔係一般理解上即時轉接真人嗰種「live handoff」。Kodee 直接解釋咗實際模式：
I have shared your request with a specialist from our team who will personally review our chat and send me their answer, which I will then relay back to you here.
呢個其實係異步審閱，唔係即時轉接。Kodee 仍然係介面；真人喺背景審閱對話，之後 Kodee 再將答案轉述返嚟。對於想決定係咪升級處理嘅讀者而言，呢個分別好重要，因為喺呢度「human agent」唔代表有另一個人直接加入聊天視窗，方式唔同於一般即時聊天系統。
等待期間，我繼續同 Kodee 推進同一條技術線索，問佢確切日誌路徑，以及 stderr.log 係咪一定有內容。佢自己畀出咗一個幾好嘅答案，正確指出如果 app 從未完全啟動，或者錯誤喺其他地方寫出，日誌可能係空白。
大約 3 分鐘後，專員審閱結果到咗，喺對話入面標示係一位名叫 Mayas 嘅同事，佢嘅答案比 Kodee 更精準，而唔係淨係重複：
domains/[your-domain]/nodejs/stderr.log 係正確位置。呢個檔案唔一定會生成或有內容。只有當應用程式向 stderr 寫入時，例如未捕捉例外或未處理拒絕，入面先會有記錄。如果 start command 錯咗，而程序靜靜地退出，stderr.log 可能會係空白或者根本唔存在。
Mayas 亦補充咗兩個 Kodee 冇提過嘅備用檢查：睇 stdout.log 最後一段輸出作為崩潰前跡象，以及留意有冇缺少啟動確認行，作為應用程式根本未啟動嘅信號。
| Check | Result |
|---|---|
| First technical answer accurate | Yes |
| Human escalation available | Yes, but resisted twice before granted |
| Escalation model | Asynchronous review and relay, not live transfer |
| Named responder | Mayas |
| Response time for human review | About 3 minutes |
| Human answer more precise than AI answer | Yes |
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 日更新，涵蓋：
最後一點同我實測遇到嘅情況一致：Devin Desktop 會自動偵測，而 OpenAI Codex 就需要手動方法。文章喺呢個分別上講得正確。
Kodee 對一條困難技術問題嘅第一個答案準確而具體，呢點唔係每個 AI 支援助手都做到。支撐呢個答案嘅知識庫文章一旦搵到就相當新同詳細，不過產品嘅宣傳名稱同文件標題唔一致，所以搜尋比瀏覽分類更可靠。
較弱嘅部分係人類升級處理流程。Kodee 兩次將我導返去自己先肯處理真人請求，即使如此，「human agent」都只係透過同一個聊天介面做異步審閱，而唔係即時轉接。一旦真人睇過之後，答案比 Kodee 自己嘅更好、更精準，仲多咗兩個 Kodee 冇提供嘅診斷步驟。
對大多數問題嚟講，單靠 Kodee 已經可以好快畀到準確答案。如果你真係想要真人核實答案，就預咗要問多過一次，而且等到嘅會係經由轉述返嚟嘅短暫等候，而唔係即時對話。
值得，對於已經用 Hostinger、又想喺編輯器入面處理日常部署嘅開發者嚟講尤其如此。設定只需要幾分鐘，OAuth 令你唔需要 API key，而一旦有一個已知網域嘅網站存在，Connector 就可以大約一分鐘內將更新發佈到正式環境，仲有日誌支持。Kodee 自身嘅支援答案亦足以即時解決真實技術問題。
但關鍵唔在於方便，而在於信任。當佢面對一個佢搵唔到嘅新目標時，Connector 會捏造一個網域，並喺未核實前就據此行動。
佢亦會喺應用程式實際已經離線時，將一個壞部署標記為「completed」，而佢自己嘅日誌又冇顯示執行階段錯誤。你可以用佢嚟加快已存在網站嘅工作，但喺新目標上面一定要驗證佢做嘅每一步，而且喺每次重要部署之後都要自己檢查 live site。
| Description | Expert Review |
|---|---|
| 價格實惠的主機託管，具備高效能及簡易管理工具。 | Read Shared Hosting Review |
| 快速且安全的 WordPress 主機，提供一鍵安裝和高級功能。 | Read Wordpress Hosting Review |
| 可擴充的 VPS 主機託管，提供專用資源及 root 存取權限。 | Read VPS Review |
| 快速、靈活的雲端託管，提供卓越的正常運行時間及可擴展資源�... | Read Cloud Hosting Review |
| 在離岸數據中心位置提供安全及私密的主機託管方案。 | Read Offshore Hosting Review |
| 安全可靠的電郵託管服務，具備專業級功能。 | Read Email Hosting Review |
| 為開發人員提供靈活環境的可靠 Python 託管。 | Read Python Hosting Review |
| 高效能 PHP 主機託管，全面支援動態網站及應用程式。 | Read PHP Hosting Review |
| 可靠的 Windows VPS 主機託管，提供完整控制與自訂選項。 | Read Windows VPS Review |
| 為 Node.js 應用程式度身訂造的快速且靈活主機託管，提供最佳效�... | Read Nodejs Hosting Review |
| 為 WooCommerce 商店提供優化主機託管，具備高速和安全整合。 | Read Woocommerce Hosting Review |
| 專用伺服器託管，打造無縫的 Minecraft 遊戲體驗。 | Read Minecraft Server Hosting Review |
| 為數碼代理商及開發人員提供具可擴展性及進階功能的託管方案 | Read Agency Hosting Review |
| 為 Magento 電子商務網站優化的快速、安全主機託管。 | Read Magento Hosting Review |
| 高效能的 Linux 主機託管，確保網站運作穩定及安全。 | Read Linux Hosting Review |
| 強大可靠的 Java 主機託管解決方案，適用於動態網頁應用程式及�... | Read Java Hosting Review |
| 為電子商務網站提供優化主機服務，具備安全、快速及可靠的效�... | Read Ecommerce Hosting Review |
| 可靠的 Django 主機託管，提供高速效能及安全環境。 | Read Django Hosting Review |
| 易於使用的 cPanel 主機託管，具備強勁效能及可靠支援。 | Read Cpanel Hosting Review |
| 為企業提供強大的主機託管服務，具有高速、安全及可擴展性。 | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| 專用 SMTP 伺服器託管，提供可靠及安全的電郵傳送。 | Read SMTP Server Review |
| 為 Ruby on Rails 網頁應用程式度身打造嘅快速同經過優化嘅主機服�... | Read Ruby on Rails Review |
| 提供豐富功能嘅託管服務，整合 OpenClaw，用於建構同管理夾公仔�... | Read OpenClaw Review |
| 快速可靠嘅託管，配備英國本地伺服器，帶來最佳本地效能。 | Read UK Hosting Review |
| 價格實惠且可靠、設有印度伺服器的主機服務，可實現低延遲存�... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read MCP Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review |
Hostinger Connector 是一個基於 MCP 的整合，可將受支援的 AI 編碼環境連接到 Hostinger 服務。
它讓 AI 助手可以呼叫受支援的 Hostinger 工具，用於網站、部署、網域、DNS、資料庫、電郵及 VPS 資源相關的工作。
Connector 不是獨立的託管平台，也不會取代 hPanel。它提供另一種與 Hostinger 資源互動的方式。
Hostinger 目前列出：
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger 亦表示其他支援 MCP 的用戶端或許也可支援。設定及工具行為可因應不同用戶端而有所差異。
Hostinger Connector 可免費安裝，並已包括在 Hostinger 計劃內。喺呢篇評測所顯示的定價中，並無另外獨立嘅 Connector 訂閱。你仍然需要為底層嘅 Hostinger 服務付費，例如網頁寄存、雲端寄存，或者 VPS。
唔係。Hostinger Connector 使用 OAuth 驗證。在我設定 VS Code 時，我透過 Hostinger 的瀏覽器式授權流程登入。我冇生成 API 金鑰、冇喺編輯器貼上權杖，亦冇將憑證儲存在設定檔中。
唔。Hostinger 表示 Connector API 呼叫會與實際帳戶互動。學習工作流程時，請使用專用的測試網站、網域或 VPS。唔好因為指令係透過 AI 聊天發出，就以為佢只係模擬指令。
是的。Hostinger 文件說明的預設限制為：
• 每分鐘 60 次請求
• 每小時 1,000 次請求
Hostinger 亦指出，速率限制詳情會在回應標頭中返回。
這些限制應足以應付一般互動式使用。請避免不必要的重複呼叫，尤其是當先前的回應已包含所需資訊時。
係。 我已經將一個 Express.js 應用程式部署到 Hostinger，之後再用 Connector 從 VS Code 發佈更新版本。Hostinger 偵測到 Express，選擇咗 Node.js 22.x，並且喺初始嘅 hPanel 部署時將專案根目錄設為根目錄。一旦網站存在並被識別為 Node.js 目標，經由 Connector 進行重複部署就成功運作。
未必如此。在我的受控測試中，我將 start script 改為引用一個缺失的 JavaScript 檔案後，Hostinger 仍然顯示建置完成。檢索到的建置日誌顯示依賴項安裝成功，但沒有揭示執行階段的啟動失敗。部署後一定要驗證實際網站，或呼叫 health endpoint。
唔完全係。Connector 可以減少開發者需要離開編輯器嘅頻率，特別係例行部署同帳戶檢查。hPanel 對於可視化帳戶管理、初始設定、詳細配置，以及 AI 無法正確發現或顯示所需資源嘅情況仍然好有用。
