การจัดการโฮสติ้งมักรบกวนการพัฒนา คุณเขียนโค้ดในเอดิเตอร์ เปิดแดชบอร์ดโฮสติ้งเพื่อสร้างเว็บไซต์ สลับไปยังเทอร์มินัลเพื่อแพ็กหรือพุชโปรเจกต์ กลับไปที่แดชบอร์ดเพื่อตรวจสอบการดีพลอย และเปิดเครื่องมือเพิ่มเติมเมื่อ DNS, บันทึก (logs) หรือทรัพยากรเซิร์ฟเวอร์ต้องการการดูแล
Hostinger Connector ช่วยลดการสลับบริบทนั้น มันเชื่อมต่อบริการของ Hostinger เข้ากับเครื่องมือเขียนโค้ด AI ผ่าน Model Context Protocol (MCP) ทำให้คุณสามารถถามผู้ช่วย AI ให้ตรวจสอบหรือจัดการทรัพยากรโฮสติ้งที่รองรับได้โดยไม่ต้องออกจากเอดิเตอร์
ฟังดูสะดวกดี แต่มันก็ทำให้เกิดคำถามที่สำคัญกว่านั้น: คุณไว้วางใจให้ผู้ช่วย AI ทำงานโฮสติ้งจริงได้แม่นยำแค่ไหน?
เพื่อหาคำตอบ ฉันทดสอบ Hostinger Connector กับ VS Code และ GitHub Copilot บนบัญชี Hostinger จริง ฉันใช้แอปพลิเคชัน Express.js ขนาดเล็กชื่อ PulseWatch และทำตามเวิร์กโฟลว์ตั้งแต่การติดตั้งไปจนถึงการดีพลอยขึ้นไลฟ์ ฉันยังทดสอบการดีพลอยซ้ำ บันทึกบิลด์ (build records) บันทึก (logs) และการกู้คืนหลังจากตั้งใจทำให้คำสั่งเริ่มต้นของแอปพลิเคชันเสีย
นี่คือวิธีที่ฉันให้คะแนน Hostinger Connector ในด้านที่สำคัญที่สุดสำหรับนักพัฒนาที่กำลังตัดสินใจว่าจะใช้มันหรือไม่: ราคา, ขอบเขตฟีเจอร์, การใช้งานในแต่ละวัน, ความแม่นยำในการทำงานจริง, และการสนับสนุนที่อยู่เบื้องหลังเมื่อมีปัญหา คะแนนแต่ละส่วนสะท้อนสิ่งที่ฉันพบจริงระหว่างการทดสอบ ไม่ใช่หน้าเว็บการตลาด
| พารามิเตอร์ | คะแนน | เหตุผลที่ให้คะแนนนี้ |
|---|---|---|
| ราคา | 9.7/10 | Connector ไม่มีค่าบริการแยกต่างหากเลย และถูกรวมฟรีมากับทุกแผน ต้นทุนเดียวคือทรัพยากรโฮสติ้งพื้นฐานที่คุณต้องใช้อยู่แล้ว |
| ฟีเจอร์ | 9.5/10 | ขอบเขตฟีเจอร์ครอบคลุมมากกว่าการดีพลอย ตั้งแต่เว็บไซต์ โดเมน DNS ฐานข้อมูล แคมเปญอีเมล ทรัพยากร VPS บันทึก และการวินิจฉัย ซึ่งครอบคลุมมากกว่าเครื่องมือดีพลอยทั่วไป |
| ความง่ายในการใช้งาน | 9.1/10 | การติดตั้งและ OAuth ทำได้รวดเร็วและไม่ต้องตั้งค่าด้วยตนเอง การดีพลอยซ้ำก็ง่าย การตั้งค่าเว็บไซต์ Node.js แรกเริ่มต้องทำผ่าน hPanel เพราะ AI หาเป้าหมายที่ถูกต้องไม่เจอ ซึ่งเป็นช่องโหว่จริงเพียงจุดเดียวในขั้นตอนที่โดยรวมลื่นไหล |
| ความแม่นยำในการทำงาน | 8.5/10 | การวิเคราะห์โปรเจกต์ การแก้ไขโค้ด การแพ็ก การดีพลอย และการกู้คืนทำงานได้ดี แต่ AI นำโดเมนที่สร้างขึ้นเองมาใช้ซ้ำ และตีความการตรวจสอบการเข้าถึงเกินจริงก่อนที่เป้าหมายจะมีอยู่จริง |
| การสนับสนุน | 9.5/10 | Kodee ให้คำตอบที่แม่นยำและเฉพาะเจาะจงต่อคำถามทางเทคนิคจริงตั้งแต่ครั้งแรก และผู้เชี่ยวชาญมนุษย์ที่ติดตามผลก็เฉียบคมยิ่งกว่า แม้การส่งต่อจะต้องขอโดยตรงถึงสองครั้ง แต่ทั้งคำตอบจาก AI และมนุษย์ก็เชื่อถือได้เมื่อได้รับคำตอบแล้ว |
| ภาพรวม | 9.3/10 | เป็นเครื่องมือเวิร์กโฟลว์ที่มีคุณค่าสำหรับผู้ใช้ Hostinger ที่ทำงานในเอดิเตอร์ที่รองรับ AI มันไม่มีค่าใช้จ่ายเพิ่ม ครอบคลุมฟีเจอร์หลากหลาย และทั้งการตั้งค่าและการสนับสนุนก็ทำได้ดีในการทดสอบ ความแม่นยำในการทำงานกับเป้าหมายดีพลอยใหม่เป็นจุดเดียวที่ต้องระวัง |
Hostinger Connector ไม่ได้ขายเป็นผลิตภัณฑ์แยกต่างหาก Hostinger ระบุว่า Connector รวมฟรีมากับทุกแผน ซึ่งหมายความว่าไม่มีค่าบริการรายเดือนของ Connector แยกต่างหากที่จะเพิ่มเข้าไปในบิลโฮสติ้งของคุณ
อย่างไรก็ตาม คำว่า “ฟรี” ต้องมีบริบท Connector จัดการทรัพยากรของ Hostinger; มันไม่ได้มาแทนที่ทรัพยากรเหล่านั้น คุณยังต้องมีโฮสติ้ง คลาวด์ VPS โดเมน อีเมล หรือบริการ Hostinger อื่น ๆ ที่เข้าเงื่อนไขสำหรับงานที่คุณต้องการให้มันทำ
ในช่วงเวลาที่รีวิวนี้ Hostinger ระบุหน้า Landing Page ของ Connector ว่าเน้น Business Web Hosting และ Cloud Startup
| แผน | ราคาส่งเสริมการขาย | ระยะเวลาที่จ่ายล่วงหน้าตามที่แสดง | ราคาต่ออายุ | เว็บแอป | เว็บไซต์ |
|---|---|---|---|---|---|
| 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 เลือกแผนตามจำนวนเว็บไซต์และเว็บแอปที่คุณต้องการ ทรัพยากรที่ต้องใช้ และระดับการสนับสนุนที่คุณต้องการ Connector เป็นชั้นการจัดการที่รวมมาให้ ไม่ใช่ผลิตภัณฑ์หลักที่ถูกตั้งราคา
Hostinger โฆษณาการรับประกันคืนเงินภายใน 30 วันสำหรับการซื้อโฮสติ้งที่มีสิทธิ์ ไม่มีนโยบายคืนเงินของ Connector แยกต่างหากให้ประเมิน เพราะ Connector ไม่มีค่าธรรมเนียมแยก
การกระทำที่มีให้ใช้จะแตกต่างกันไปตามบริการ Hostinger ในบัญชีของคุณและเครื่องมือที่ AI client ที่เชื่อมต่อสามารถเข้าถึงได้
Hostinger ยังระบุข้อจำกัดอัตรา (rate limits) ด้วย ตาม FAQ ของ Connector ค่าเริ่มต้นคือ 60 คำขอต่อนาทีและ 1,000 คำขอต่อชั่วโมง โดยข้อมูล rate-limit จะถูกส่งกลับใน response headers
ขีดจำกัดเหล่านี้ถือว่ากว้างพอสำหรับการใช้งานแบบโต้ตอบ แต่เวิร์กโฟลว์ที่อัตโนมัติหรือทำซ้ำบ่อย ๆ ก็ควรหลีกเลี่ยงการเรียกซ้ำที่ไม่จำเป็น
ก่อนที่ฉันจะตัดสินได้ว่า Hostinger Connector ทำงานดีแค่ไหนในการดีพลอยและจัดการโฮสติ้งจริง ฉันต้องรู้ก่อนว่าต้องใช้อะไรบ้างเพื่อให้มันเริ่มทำงาน
เครื่องมือที่ออกแบบมาให้คุณอยู่ในเอดิเตอร์ตลอดจะหมดเสน่ห์เร็วมาก หากการตั้งค่าต้องไปแก้ไฟล์คอนฟิก สร้างโทเค็น API หรือยืนยันตัวตนซ้ำหลายครั้ง ส่วนนี้พูดถึงการตั้งค่าเท่านั้น ส่วนการทดสอบงานจริงจะตามมาในทันที
ฉันติดตั้ง Hostinger Connector จาก VS Code Marketplace มันขึ้นเป็นผลการค้นหาอันดับแรกเมื่อฉันค้นหา “Hostinger” ผู้เผยแพร่ระบุว่าเป็น Hostinger Official และการติดตั้งสำเร็จตั้งแต่ครั้งแรกภายในไม่ถึงสองนาที
| รายละเอียด | ผลลัพธ์ |
|---|---|
| การค้นหาใน Marketplace | ผ่าน, ปรากฏขึ้นทันที |
| การยืนยันผู้เผยแพร่ | Hostinger Official |
| การติดตั้ง | เสร็จภายในไม่ถึงสองนาที |
| เวอร์ชันของส่วนขยาย ณ เวลาทดสอบ | 1.3.1 |
| จำนวนการติดตั้งใน Marketplace | 8,140 |
| คะแนนผู้ใช้ | 5 ดาว จาก 2 คะแนนรีวิว |
แถวสุดท้ายนั้นควรระวังไว้ คะแนน 5 ดาวฟังดูดี แต่ตัวอย่างจาก 2 รีวิวบอกอะไรฉันแทบไม่ได้เกี่ยวกับประสบการณ์ผู้ใช้โดยทั่วไป ฉันจะไม่ยึดตัวเลขนั้นเป็นหลักในการรีวิว
ข้อกำหนดเบื้องต้นหนึ่งอย่างทำให้ฉันประหลาดใจ: Hostinger Connector มีเครื่องมือของ Hostinger ให้ แต่ต้องมีเอเจนต์ AI ที่ทำงานอยู่ในเอดิเตอร์อยู่แล้วจึงจะเรียกใช้เครื่องมือเหล่านั้นได้จริง
ส่วนขยายเองไม่มีอะไรให้คุยด้วยถ้าอยู่ลำพัง ใน VS Code เอเจนต์นั้นคือ GitHub Copilot Chat เนื่องจากตอนนี้มันเป็นอินเทอร์เฟซ AI ที่ VS Code เปิดให้เรียกใช้เครื่องมือ MCP ได้ ฉันมี Copilot ทำงานอยู่แล้ว จึงไม่ทำให้ช้า แต่ผู้อ่านควรรู้ว่า Connector จะมีประโยชน์ได้ก็ต่อเมื่อมีเอเจนต์ AI อยู่เบื้องหลัง
ถ้าไม่มีการติดตั้งและลงชื่อเข้าใช้ ก็ไม่มีอะไรให้มันเชื่อมต่อด้วย
สิ่งที่การติดตั้งไม่ต้องการ:
การติดตั้งส่วนขยายเองเป็นหนึ่งในส่วนที่ราบรื่นที่สุดของการทดสอบทั้งหมด ข้อแม้เดียวจริง ๆ คือมีสิ่งพึ่งพาที่ Hostinger ไม่ได้พูดถึงอย่างชัดเจน: ส่วนขยายต้องมีเอเจนต์ AI ที่ทำงานอยู่ในเอดิเตอร์ของคุณเพื่อจะทำอะไรได้เลย
เมื่อมีส่วนขยายแล้ว คำถามถัดไปคือการเชื่อมเข้ากับบัญชีจริงจะง่ายพอ ๆ กันหรือไม่
การเชื่อมบัญชีใช้ OAuth ผ่านปุ่ม “1-Click Connect” VS Code เปิดหน้าการอนุญาตของ Hostinger ในเบราว์เซอร์ ตรวจพบเซสชัน Hostinger ที่มีอยู่แล้วของฉัน และขอให้ฉันอนุมัติสิทธิ์สำหรับสิ่งที่ระบุว่า hostinger-mcp
หลังจากฉันคลิก Allow ฉันก็ถูกส่งกลับไปที่ VS Code โดยแสดงข้อความ “Connected via OAuth.”
| การตรวจสอบ | ผลลัพธ์ |
|---|---|
| การเชื่อมต่อแบบคลิกเดียว | ผ่าน |
| เบราว์เซอร์เปิดอัตโนมัติ | ผ่าน |
| ตรวจพบเซสชัน Hostinger ที่มีอยู่แล้ว | ผ่าน |
| ต้องใช้โทเค็น API ด้วยตนเอง | ไม่ |
| แสดงหน้าการอนุญาต | ใช่ |
| อธิบายสิทธิ์อย่างชัดเจน | ใช่ แต่กว้าง |
| กลับมาที่ VS Code ได้สำเร็จ | ผ่าน |
หน้าการอนุญาตบอกฉันว่า Connector สามารถจัดการเว็บไซต์ โฮสติ้ง โดเมน การสมัครใช้งาน และบริการ Hostinger อื่น ๆ ได้
นั่นเป็นเพียงรายการหมวดหมู่ ไม่ใช่รายละเอียดสิทธิ์แบบแยกเป็นรายการ ฉันอยากให้ตรงนี้ละเอียดกว่านี้ เพราะ “จัดการการสมัครใช้งาน” และ “จัดการเว็บไซต์” มีระดับความเสี่ยงต่างกันมาก
สิ่งที่ให้ฉันควบคุมได้บางส่วนคือแผงแยกภายในส่วนขยายที่แสดงทุกหมวดเครื่องมือ และให้เปิดหรือปิดแต่ละหมวดได้ทีละรายการ:
| หมวดเครื่องมือ | จำนวนเครื่องมือที่มี | สถานะเริ่มต้น |
|---|---|---|
| เว็บไซต์ | 80 | เปิดใช้งาน |
| โดเมน | 26 | เปิดใช้งาน |
| การสมัครใช้งานและการชำระเงิน | 7 | เปิดใช้งาน |
| การตลาดผ่านอีเมล | 12 | เปิดใช้งาน |
| อีคอมเมิร์ซ | 12 | ปิดใช้งาน |
| VPS | 62 | ปิดใช้งาน |
นั่นคือเครื่องมือทั้งหมด 199 รายการ โดยเปิดใช้งาน 125 รายการตามค่าเริ่มต้น ฉันปิด Ecommerce และ VPS ไว้ก่อนจนกว่าจะพร้อมทดสอบโดยตรง และส่วนขยายก็เคารพขอบเขตนั้นตลอดการทดสอบ
นี่คือรายละเอียดด้านความปลอดภัยที่ไม่ได้อยู่บนหน้าเว็บการตลาดของ Hostinger แต่สำคัญสำหรับใครก็ตามที่กำลังตัดสินใจว่าจะให้ผู้ช่วย AI เข้าถึงบัญชีมากแค่ไหน ฉันมองว่านี่เป็นจุดแข็งจริง ๆ
การยกเลิกการเชื่อมต่อบัญชีทำได้จากแผงเดียวกัน โดยไม่ต้องเปลี่ยนรหัสผ่าน Hostinger หรือค้นหาโทเค็นที่บันทึกไว้
การอนุญาตทำได้รวดเร็วและไม่ต้องจัดการโทเค็นเอง แต่หน้าสิทธิ์แบบกว้างเกินไป ไม่ได้ละเอียดเท่าการควบคุมเครื่องมือระดับหมวดหมู่ในส่วนขยาย ซึ่งช่วยจำกัดความเสี่ยงจริงได้มากกว่า
Hostinger ระบุการรองรับไคลเอนต์ต่อไปนี้ ซึ่งรวบรวมมาจากหน้าต้อนรับของส่วนขยาย:
| เอดิเตอร์หรือไคลเอนต์ | Hostinger ระบุไว้ |
|---|---|
| VS Code | ใช่ |
| Cursor | ใช่ |
| Windsurf | ใช่ |
| Devin Desktop | ใช่ |
| Antigravity | ใช่ |
| Claude Code | ใช่ |
| OpenAI Codex CLI | ใช่ |
ฉันใช้ VS Code กับ GitHub Copilot เป็นสภาพแวดล้อมหลักในการทดสอบ
การตั้งค่าบอกฉันว่า Connector เข้าถึงได้ง่าย มันยังไม่ได้บอกอะไรเกี่ยวกับว่ามันทำงานได้ดีแค่ไหนเมื่อเชื่อมต่อแล้ว ซึ่งเป็นคำถามที่ยากกว่าและฉันจะไปต่อที่ตรงนั้น
การติดตั้งและเชื่อมต่อส่วนขยายเป็นส่วนที่ง่าย สิ่งที่สำคัญจริง ๆ คือมันทำงานโฮสติ้งจริงได้ถูกต้องหรือไม่ ดังนั้นฉันจึงสร้างแอปพลิเคชัน Express.js ขนาดเล็กชื่อ PulseWatch แล้วทดสอบ Connector ตามเส้นทางเดียวกับที่นักพัฒนาจะทำหลังติดตั้ง: ตรวจสอบบัญชี หาเป้าหมายดีพลอย ดีพลอยโปรเจกต์ อัปเดต ดูผลลัพธ์ และกู้คืนจากความล้มเหลวที่ฉันตั้งใจสร้างขึ้น
| การทดสอบ | สิ่งที่ฉันต้องการเรียนรู้ |
|---|---|
| อ่านข้อมูลบัญชี | มันเข้าใจบัญชีโฮสติ้งได้แม่นยำแค่ไหน? |
| หาเป้าหมายดีพลอย | มันระบุเว็บไซต์ที่ถูกต้องได้โดยไม่เดาหรือไม่? |
| วิเคราะห์โปรเจกต์ Node.js | มันเข้าใจแอปก่อนแตะต้องมันหรือไม่? |
| ดีพลอย PulseWatch | มันย้ายโปรเจกต์จริงจากเอดิเตอร์ไปยังโฮสติ้งไลฟ์ได้หรือไม่? |
| เผยแพร่การอัปเดตเนื้อหา | มันมีประโยชน์สำหรับงานพัฒนาแบบปกติหรือไม่? |
| ตรวจสอบบิลด์และบันทึก | มันให้หลักฐานที่มีประโยชน์หลังดีพลอยหรือไม่? |
| ดีพลอยเวอร์ชันที่เสีย | มันเปิดเผยความล้มเหลวของแอปจริงได้หรือไม่? |
| กู้คืนแอปพลิเคชัน | มันกู้คืนรีลีสที่ดีอยู่แล้วอย่างปลอดภัยได้หรือไม่? |
PulseWatch ถูกทำให้เรียบง่ายโดยตั้งใจ: เซิร์ฟเวอร์ Express, หน้าโฮมเพจ, สคริปต์เริ่มต้นใน package.json และ /api/health endpoint ที่ส่งกลับ JSON เอ็นด์พอยต์ด้านสุขภาพ (health endpoint) นี้กลายเป็นสิ่งสำคัญในภายหลัง
แพลตฟอร์มโฮสติ้งสามารถรายงานว่าบิลด์เสร็จสมบูรณ์ได้ แม้ว่าแอปพลิเคชันจะล้มเหลวเมื่อเริ่มต้นจริง เอ็นด์พอยต์สดช่วยให้ฉันมีวิธีตรวจสอบแยกต่างหากว่าโปรเซสที่ดีพลอยนั้นตอบสนองจริงหรือไม่ แทนที่จะเชื่อเพียงสถานะที่แสดง
ฉันเริ่มจากพรอมต์แบบอ่านอย่างเดียวก่อนจะอนุญาตให้ผู้ช่วยเข้าใกล้การเปลี่ยนแปลงใด ๆ บนไลฟ์ ถ้ามันอธิบายบัญชีของฉันได้ไม่ถูกต้อง ฉันก็คงไม่มีเหตุผลมากพอที่จะเชื่อใจให้มันจัดการดีพลอย, DNS หรือการกระทำกับ VPS
เครื่องมือรายการเว็บไซต์ของ Connector ส่งกลับเว็บไซต์ห้าแห่ง:
แต่ในบัญชีของฉันจริง ๆ มีมากกว่านั้น hPanel แสดงเว็บไซต์ที่กระจายอยู่ในแผน Premium, Business และ Growth รวมถึงไซต์ WordPress ไซต์ PHP/HTML โปรเจกต์ Website Builder และโดเมนชั่วคราวหลายรายการ
ในการถามแยกอีกครั้งเกี่ยวกับแผนโฮสติ้งที่เปิดใช้งานอยู่ ผู้ช่วยบอกฉันว่าฉันมี “หนึ่งแผนโฮสติ้งที่ใช้งานอยู่” แต่ hPanel แสดงสามแผน: Premium, Growth และ Business
| การตรวจสอบ | ผลลัพธ์ |
|---|---|
| ระบุเว็บไซต์ที่รู้จัก | ผ่าน |
| ระบุแผนโฮสติ้งทั้งหมด | ไม่ผ่าน |
| ตรวจพบแผน Business ที่ไม่ได้ใช้งาน | ไม่ผ่าน |
| ไม่มีการเปลี่ยนแปลงบัญชี | ไม่มี |
เพื่อความยุติธรรมต่อ Connector เมื่อฉันโต้แย้งและชี้ให้เห็นความไม่สอดคล้อง มันก็แก้ไขตัวเอง อธิบายอย่างชัดเจนว่าสิ่งใดที่มันตรวจสอบแล้วและสิ่งใดที่มันคาดเดา และไม่พูดผิดซ้ำอีก
นั่นเป็นรูปแบบความล้มเหลวที่ดีกว่าการดันทุรังยืนยัน แต่ก็หมายความว่าคำตอบแรกสำหรับคำถามระดับบัญชีไม่ควรถูกเชื่อทันที
การเข้าถึงแบบอ่านอย่างเดียวใช้งานได้ แต่คำตอบแรกสำหรับคำถามเกี่ยวกับบัญชีโดยรวมยังไม่ครบถ้วน มันแก้ไขตัวเองเมื่อถูกทักท้วง ซึ่งสำคัญ แต่ฉันไม่ควรต้องเป็นฝ่ายทักท้วงตั้งแต่แรก
ช่องว่างในการมองเห็นบัญชีนั้นกลายเป็นตัวอย่างของปัญหาใหญ่กว่า การทดสอบที่แท้จริงว่ามันสำคัญแค่ไหนคือเมื่อฉันขอให้ Connector หาเว็บไซต์ใหม่ที่มันไม่เคยถูกบอกชื่อมาก่อน
ตรงนี้เองที่การทดสอบเผยให้เห็นมากที่สุด ฉันขอให้ผู้ช่วยระบุเว็บไซต์ Node.js ที่สร้างใหม่ โดยไม่บอกโดเมนให้มัน และไม่แตะต้องเว็บไซต์ใดที่มีอยู่แล้ว
การเลือกเป้าหมายเป็นข้อกำหนดด้านความปลอดภัยพื้นฐานสำหรับเครื่องมือที่สามารถทำงานกับบัญชีจริงได้ ดังนั้นฉันจึงอยากดูว่ามันจัดการความไม่แน่นอนอย่างไร แทนที่จะตอบแบบเดาได้สวย ๆ
สิ่งที่เกิดขึ้น มีดังนี้ตามลำดับ:
| ขั้นตอน | สิ่งที่ Connector ทำ | ผลลัพธ์ |
|---|---|---|
| 1 | ใช้ชื่อโดเมนจากความพยายามก่อนหน้าที่ล้มเหลวซ้ำ: pulsewatch-temp-20260714.hostingersite.com | โดเมนนี้ไม่เคยถูกส่งกลับมาจากการเรียก list เว็บไซต์ใด ๆ |
| 2 | รันการตรวจสอบการเข้าถึงบนโดเมนนั้น | ส่งกลับ is_accessible: true |
| 3 | ถือว่าผลนั้นเป็นการยืนยันว่าเว็บไซต์มีอยู่จริง | ไม่ถูกต้อง การเข้าถึงได้ไม่เท่ากับการเป็นระเบียนเว็บไซต์ที่มีอยู่และดีพลอยได้ |
| 4 | พยายามดีพลอยโดยใช้ resource IDs ที่ไม่ได้ยืนยันว่าเป็น hosting order IDs | Hostinger ส่งกลับ [Hosting:9999] Not found สองครั้ง |
ปัญหาหลัก: รหัส ID สองรายการที่มันใช้เป็น domain resource IDs ไม่ใช่ hosting order IDs มันไม่เคยยืนยันความแตกต่างนี้ก่อนจะเรียกเครื่องมือสร้างเว็บไซต์จริงด้วยรหัสดังกล่าว
เมื่อฉันขอให้มันอธิบายเอง ในที่สุดผู้ช่วยก็ให้คำอธิบายที่ถูกต้อง: มันมีเครื่องมือรายการเว็บไซต์ที่ใช้งานได้อยู่ตลอด แต่ไม่เรียกมันอีกครั้งหลังจากฉันสร้างไซต์ใหม่ผ่าน hPanel ดังนั้นมันจึงเติมช่องว่างด้วยโดเมนที่ไม่ได้รับการตรวจสอบแทนที่จะรีเฟรชข้อมูล
เมื่อฉันขอให้มันรันเครื่องมือรายการนั้นใหม่และตรวจดูว่ามีเรคคอร์ดใหม่หรือไม่ มันกลับไปเรียกเครื่องมือค้นหาการดีพลอยที่ไม่เกี่ยวข้องสามตัวแทน และรายงานว่า “ไม่มีเว็บไซต์ใหม่ปรากฏขึ้น” ซึ่งข้อสรุปจากการเรียกเครื่องมือที่มันทำจริงไม่สามารถรองรับได้
ทั้งหมดนี้ไม่ได้สร้างเว็บไซต์แปลกปลอมไว้ในบัญชีของฉัน การเรียกที่ล้มเหลวไม่ทิ้งอะไรไว้ แต่รูปแบบนั้นควรเรียกชื่อให้ชัดเจน เมื่อข้อมูลไม่ครบ ผู้ช่วยเติมช่องว่างด้วยการคาดเดาที่ฟังดูเป็นไปได้, ถือว่าสัญญาณอ่อนเป็นหลักฐานที่แรง, และลงมือกับบัญชีจริงก่อนที่สมมติฐานนั้นจะถูกตรวจสอบ
นี่คือข้อค้นพบที่สำคัญที่สุดในส่วนนี้ Connector จะเดาเป้าหมายแล้วลงมือจากการเดานั้น แทนที่จะหยุดแล้วถาม มันล้มเหลวอย่างปลอดภัยในที่นี้ แต่พฤติกรรมที่เอาสัญญาณอ่อนมาตีความเป็นหลักฐานคือสิ่งที่ต้องระวังในการใช้งานจริง
เมื่อ Connector หาเป้าหมายเองไม่ได้ ฉันจึงเหลือทางเลือกเดียว: สร้างเป้าหมายด้วยตัวเองแล้วดูว่านั่นจะเปลี่ยนอะไรหรือไม่
เนื่องจาก Connector หาเป้าหมายใหม่ไม่เจออย่างน่าเชื่อถือ ฉันจึงทำการตั้งค่าเริ่มต้นให้เสร็จด้วยตัวเองผ่าน hPanel เพื่อดูว่า Hostinger เตรียมอะไรไว้ก่อนที่การดีพลอยผ่าน Connector จะเป็นไปได้
เส้นทางคือ: สร้างไซต์ใหม่ → เว็บแอป Node.js → โดเมนชั่วคราว → Hostinger เลือกศูนย์ข้อมูลในสหราชอาณาจักรให้อัตโนมัติ โดยประมาณเวลาแฝง 147ms → มีตัวเลือกวิธีดีพลอยสามแบบ
หน้าจอที่สามนี้ควรชี้ให้เห็นเป็นพิเศษ Hostinger เสนอตัวเลือก “Build with Hostinger Connector” เป็นวิธีดีพลอยเคียงข้าง GitHub import และการอัปโหลดไฟล์ด้วยตนเอง ฉันเลือกมันโดยคาดว่าจะให้มันตั้งค่าเว็บไซต์ให้เสร็จ
แต่แทนที่จะเป็นเช่นนั้น มันกลับพาฉันไปยังหน้า installation ของ Connector เอง ซึ่งฉันทำไปแล้ว นี่คือช่องโหว่จริงในการเริ่มต้นใช้งาน ตัวเลือกที่นำเสนอว่าเป็นเส้นทางของ Connector กลับไม่ได้ provision อะไรเลย
ฉันกลับไปและเลือกการอัปโหลดไฟล์ด้วยตนเองแทน Hostinger ยอมรับไฟล์ archive ของโปรเจกต์ฉัน (11.46 KB โดยไม่รวม node_modules ) และหน้าตั้งค่าแสดงการตรวจจับอัตโนมัติที่ถูกต้อง:
ฉันคลิก Deploy มันเสร็จเรียบร้อย และ Hostinger กำหนดโดเมนชั่วคราวจริงให้: orange-walrus-700988.hostingersite.com นั่นเป็นโดเมนคนละตัวกับที่ Connector เคยสร้างขึ้นเองก่อนหน้านี้ ฉันเปิดทั้งหน้าโฮมเพจและ /api/health ด้วยตัวเอง และยืนยันว่าทั้งคู่ทำงานได้
เส้นทางแบบแมนนวลทำงานได้อย่างราบรื่นทันทีเมื่อฉันเลิกนั่งรอให้ Connector หาเจอ ปุ่ม “Build with Hostinger Connector” บนหน้าจอนี้ควรถูกแก้หรือเอาออก ตอนนี้มันสัญญาในสิ่งที่มันไม่ได้ทำ
ตอนนี้มีเว็บไซต์จริงที่ยืนยันแล้วอยู่หนึ่งแห่ง คำถามถัดไปคือ Connector จะทำตัวต่างออกไปหรือไม่เมื่อมันมีสิ่งที่ชัดเจนให้ค้นหาแล้ว
เมื่อมีเว็บไซต์จริงที่ยืนยันแล้ว ฉันกลับไปที่ Connector และขอให้มันตรวจสอบโดเมนนั้นอย่างแม่นยำ คราวนี้มันทำงานได้เรียบร้อย
| การตรวจสอบ | ผลลัพธ์ |
|---|---|
| จดจำไซต์ว่าเป็นเป้าหมายดีพลอย Node.js | ผ่าน |
| พบบันทึกการดีพลอยที่เสร็จสมบูรณ์ | ผ่าน |
| พบบันทึกบิลด์ Node.js ที่ตรงกัน | ผ่าน |
| การดีพลอยและบิลด์ใช้ UUID เดียวกัน | ผ่าน |
นั่นยืนยันบางอย่างที่สำคัญ: ความล้มเหลวก่อนหน้านี้เป็นเรื่องของการหาและสร้างเป้าหมายใหม่ ไม่ใช่เรื่องความสามารถของ Connector ในการทำงานกับไซต์ Node.js เมื่อมีไซต์นั้นอยู่แล้ว
จากนั้นฉันทดสอบฟีเจอร์ที่ Hostinger โปรโมตมากที่สุด: เปลี่ยนโค้ดหนึ่งบรรทัดในเครื่อง แล้วเผยแพร่โดยไม่ต้องเปิด hPanel
ฉันขอให้ผู้ช่วยเปลี่ยนข้อความบนหน้าโฮมเพจหนึ่งบรรทัด จาก “Monitor Every Service. Catch Every Issue.” เป็น “Monitor Every Service. Resolve Issues Faster.”
| ขั้นตอน | ผลลัพธ์ |
|---|---|
| พบข้อความเดิม | ผ่าน |
| เปลี่ยนเฉพาะบรรทัดที่ขอ | ผ่าน |
| ตรวจสอบแอปในเครื่องก่อนดีพลอย | ผ่าน |
แพ็กโปรเจกต์ โดยไม่รวม node_modules และ .git | ผ่าน |
| ดีพลอยไปยังเว็บไซต์ที่ยืนยันแล้วซึ่งมีอยู่ | ผ่าน |
| ตรวจสอบสถานะการดีพลอยและบิลด์ภายหลัง | ผ่าน |
ทั้งกระบวนการใช้เวลาประมาณหนึ่งนาที ผู้ช่วยรายงานการดีพลอยใหม่เป็น “pending” ทันทีหลังส่ง เพราะมันตรวจสอบก่อนที่ Hostinger จะประมวลผลเสร็จ
เมื่อฉันรีเฟรชเว็บไซต์จริงด้วยตัวเอง หัวข้อใหม่ก็ขึ้นแล้ว
บันทึกบิลด์ที่มันดึงมาภายหลังมีรายละเอียดและมีประโยชน์: เพิ่มแพ็กเกจ 67 รายการ ตรวจสอบแล้ว 68 รายการ ไม่พบช่องโหว่ zero vulnerabilities ไม่มีข้อผิดพลาด
สำหรับไซต์ที่มีอยู่แล้ว นี่คือเวิร์กโฟลว์ที่ใกล้เคียงกับสิ่งที่ 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 จะรายงานอะไร
| สถานะที่แสดง | สิ่งที่ยืนยันได้ | สิ่งที่ไม่ยืนยัน |
|---|---|---|
| Build: completed | ติดตั้ง dependencies เสร็จ, ขั้นตอนบิลด์จบแล้ว | แอปพลิเคชันเริ่มทำงานจริง |
| Deployment: completed | Hostinger รับและประมวลผลรีลีสแล้ว | ทุกเส้นทางทำงานปกติ |
บันทึกบิลด์ที่เข้าถึงผ่าน Connector แสดงการติดตั้ง dependency สำเร็จ และไม่มีอะไรอื่น ข้อผิดพลาดตอนรันไทม์แบบ missing-module ไม่ปรากฏในนั้นเลย นักพัฒนาที่มองเพียงป้าย “completed” สีเขียวคงไม่มีเหตุผลที่จะสงสัยว่าไซต์เสีย
การกู้คืนทำได้ราบรื่น ผู้ช่วยกู้คืน package.json จากแบ็กอัป ตรวจสอบแอปในเครื่องอีกครั้ง ดีพลอยซ้ำ และยืนยันการแก้ไขโดยเรียก /api/health endpoint จริงแทนที่จะเชื่อสถานะการดีพลอย
เอ็นด์พอยต์นั้นส่งกลับการตอบสนองที่บอกว่าระบบใช้งานได้ ซึ่งเป็นหลักฐานเพียงอย่างเดียวในการทดสอบทั้งหมดที่พิสูจน์ได้จริงว่าแอปพลิเคชันกำลังทำงานอยู่
นี่คือข้อค้นพบสำคัญข้อที่สอง สถานะ completed ไม่ใช่หลักฐานว่าแอปพลิเคชันใช้งานได้ และบันทึกของ Connector เองก็จะไม่บอกเรื่องนั้นให้คุณรู้ การกู้คืนเองทำงานได้ดีเมื่อฉันรู้แล้วว่ามีปัญหาอะไรให้กู้คืน
หลังจากความล้มเหลวที่ป้ายสถานะไม่สามารถเปิดเผยได้ ฉันอยากรู้ว่าตรงไหนอีกบ้างที่ความมั่นใจของ Connector อาจวิ่งนำความสามารถจริงของมัน Environment variables คือการทดสอบถัดไป
ฉันขอให้ผู้ช่วยเพิ่ม environment variable ที่ไม่เป็นอันตราย, ยืนยันว่ามีความสามารถเฉพาะของ Connector สำหรับการตั้งค่านั้นก่อนจะทำอะไร และหยุดถ้าไม่มี
มันค้นหาเครื่องมือที่มีอยู่ พบว่าไม่มีการกระทำเฉพาะสำหรับจัดการ Node.js environment variables และหยุดก่อนจะเปลี่ยนโค้ดหรือการดีพลอยใด ๆ
นี่คือพฤติกรรมที่ฉันอยากเห็นในจุดอื่น ๆ ของการทดสอบนี้ เมื่อต้องเจอกับข้อจำกัดจริง มันหยุดแทนที่จะเดา ฉันจะไม่สรุปว่า Hostinger Connector ไม่มีการรองรับ environment variable ที่ไหนเลยในชุดเครื่องมือของมัน เพียงแต่ไม่มีการกระทำดังกล่าวถูกเปิดให้ใช้ในการทดสอบครั้งนี้
| การทดสอบ | ผลลัพธ์ | ข้อค้นพบสำคัญ |
|---|---|---|
| สำรอง manifest ที่ใช้งานได้ | ผ่าน | สร้างไฟล์สำหรับกู้คืนก่อนแก้ไข |
| ใส่ entry point ที่หายไป | ผ่าน | เพิ่มความล้มเหลวแบบควบคุม |
| ทำให้เกิดความล้มเหลวในเครื่อง | ผ่าน | MODULE_NOT_FOUND ยืนยันแล้ว |
| ดีพลอยเวอร์ชันที่เสีย | ผ่าน | Hostinger ยอมรับ archive |
| สถานะบิลด์ตรวจจับความล้มเหลว | ไม่ผ่าน | Build ยังแสดงว่า completed |
| บันทึกบิลด์แสดงข้อผิดพลาดรันไทม์ | ไม่ผ่าน | ข้อผิดพลาด missing-module ไม่ปรากฏ |
| กู้คืน manifest ที่ใช้งานได้ | ผ่าน | กู้คืนคำสั่ง start เดิมได้ |
| ดีพลอยเวอร์ชันที่ใช้งานได้ซ้ำ | ผ่าน | การดีพลอยเสร็จสมบูรณ์ |
| ตรวจสอบ health endpoint จริง | ผ่าน | API ส่งกลับสถานะใช้งานได้ |
Hostinger Connector ทำงานแบบงานประจำที่กำหนดชัดเจนได้ดี:
มันอ่อนแอกว่าเมื่องานต้องตีความข้ามข้อมูลบัญชีที่ไม่ครบถ้วน:
รูปแบบนี้มีประโยชน์เมื่อคุณต้องตัดสินใจว่าจะให้อำนาจอิสระกับผู้ช่วยมากแค่ไหน
ใช้พรอมต์กว้างสำหรับการตรวจสอบที่มีความเสี่ยงต่ำ ใช้พรอมต์ที่เฉพาะเจาะจงและระบุเงื่อนไขการยืนยันอย่างชัดเจนสำหรับการกระทำที่เปลี่ยนโครงสร้างพื้นฐานจริง
ตัวอย่างเช่น แทนที่จะใช้:
| ดีพลอยแอปนี้ไปยังเว็บไซต์ชั่วคราวใหม่ของ Hostinger |
ให้ใช้:
| แสดงรายการเว็บไซต์ที่ Hostinger ส่งกลับมาในปัจจุบัน ระบุเว็บไซต์ Node.js เฉพาะเมื่อมันปรากฏอยู่ในผลลัพธ์นั้น แสดงโดเมนที่แน่นอนและหลักฐานก่อนดีพลอย อย่าสร้าง อนุมาน หรือใช้โดเมนซ้ำที่ไม่ได้ถูกส่งกลับมาจาก Hostinger |
พรอมต์ที่สองจำกัดพื้นที่ให้ผู้ช่วยคาดเดาได้น้อยลง
การทำให้ Hostinger Connector เริ่มใช้งานได้เป็นเรื่องง่าย โดยไม่มีแรงเสียดทานแบบที่มักเจอในการตั้งค่าทั่วไป และการควบคุมระดับหมวดเครื่องมือก็ทำให้ฉันมีอำนาจจริงว่าจะให้ AI แตะอะไรได้บ้าง
เมื่อมีเว็บไซต์จริงที่มีโดเมนชัดเจนแล้ว มันทำงานได้ดี: การเปลี่ยนข้อความเพียงบรรทัดเดียวจากการแก้ไขไปสู่ไลฟ์ใช้เวลาประมาณหนึ่งนาที พร้อมบันทึกบิลด์ที่มีประโยชน์
ปัญหาเกิดขึ้นก่อนหน้านั้น ไม่ใช่ทีหลัง เมื่อเจอเป้าหมายใหม่ที่มันหาไม่เจอ Connector กลับสร้างโดเมนขึ้นมาเองและลงมือกับมันก่อนตรวจสอบ มันยังติดป้ายดีพลอยที่เสียว่า “completed” ทั้งที่แอปจริงล่มอยู่ โดยไม่มีข้อผิดพลาดรันไทม์ในบันทึกของมันเอง สิ่งเหล่านี้ไม่ได้ทำให้เครื่องมือนี้ไม่น่าเชื่อถือสำหรับไซต์ที่มีอยู่แล้ว แต่ก็หมายความว่าการดีพลอยใหม่และการตรวจสถานะหลังดีพลอยต้องมีการตรวจสอบครั้งที่สองก่อนที่คุณจะเชื่อมัน
Hostinger สร้างการสนับสนุนโดยอิงกับแชตสดและการช่วยเหลือตนเองมากกว่าการโทรศัพท์ ดังนั้นฉันจึงมุ่งทดสอบในจุดที่ผู้ใช้ส่วนใหญ่มักจะเจอจริง: ผู้ช่วย AI ที่ฝังอยู่ใน hPanel การส่งต่อไปยังมนุษย์ที่อยู่ข้างหลัง และฐานความรู้ที่นักพัฒนาจะหันไปดูก่อนเปิดแชต
| ช่องทาง | ความพร้อมใช้งาน | หมายเหตุ |
|---|---|---|
| แชตสด (Kodee, AI) | 24/7 | เข้าถึงผ่าน “Ask AI” ใน hPanel |
| แชตสด (มนุษย์) | เมื่อส่งต่อเท่านั้น | ไม่ใช่คิวตรง ถูกส่งผ่าน Kodee |
| อีเมล / ทิกเก็ต | support@hostinger.com | ระยะเวลาตอบที่ระบุไว้คือ 1 วันทำการ |
| โทรศัพท์ | ไม่มีให้บริการ | ไม่มีสายโทรศัพท์สาธารณะสำหรับการสนับสนุนทั่วไป |
| Knowledge Base | บริการตนเอง | support.hostinger.com |
| บทเรียนและ Academy | บริการตนเอง | คู่มือทีละขั้นตอนและช่อง YouTube |
เนื่องจากแชตสดคือช่องทางที่ Hostinger ชี้ให้ผู้พัฒนาใช้เมื่อต้องการเรื่องเร่งด่วน และเป็นช่องทางที่มีแนวโน้มจะถูกใช้จริงขณะดีบักการดีพลอยมากที่สุด ฉันจึงทดสอบเส้นทางนั้นโดยตรงแทนที่จะส่งอีเมลทิกเก็ต
ฉันเปิดแชตสดผ่าน “Ask AI” ใน hPanel และถาม Kodee คำถามที่ตอบผิดได้จริง: สถานะ build completed บนการดีพลอย Node.js รับประกันหรือไม่ว่าแอปกำลังรันอยู่จริง และฉันจะหาหลักฐานอื่นจากที่ไหน
คำตอบแรกของ Kodee ชัดเจนและถูกต้อง:
“Completed” มักหมายถึงขั้นตอน build เสร็จสมบูรณ์; มันไม่ได้รับประกันว่าแอปยังปกติดีหลังเปิดใช้งาน ตรวจสอบบันทึกตอนรันไทม์: ใน hPanel ไปที่ Websites → Dashboard → Deployments สำหรับบันทึก build แล้วเปิด stderr.log ในโฟลเดอร์ nodejs เพื่อดูข้อผิดพลาดตอนเริ่มต้น เช่น Port already in use หรือ Module not found
คำตอบเดียวนี้ก็จะช่วยคลายความกำกวมเดียวกับที่การทดสอบการกู้คืนจากความล้มเหลวของฉันพบก่อนหน้านี้ในรีวิวนี้ Kodee ระบุชื่อไฟล์ log จริง โฟลเดอร์ที่ถูกต้อง และอธิบายเส้นแบ่งที่ถูกต้องระหว่าง build สำเร็จกับความสมบูรณ์ของตอนรันไทม์
อย่างไรก็ตาม ฉันอยากดูด้วยว่าจะพาฉันไปหามนุษย์จริงได้หรือไม่ จึงบอก Kodee ว่าฉันต้องการยืนยันเรื่องนี้กับเจ้าหน้าที่สนับสนุนโดยตรง
แต่การได้คุยกับมนุษย์กลับยากกว่าที่คิด ฉันขอ live agent โดยตรง แต่กลับถูกส่งกลับไปที่ Kodee สองครั้ง โดยแต่ละครั้งอธิบายว่ามันเร็วกว่าไม่ต้องรอ:
ฉันเข้าใจว่าทำไมคุณถึงอยากได้แบบนั้น ฉันช่วยคุณยืนยัน build, คำสั่ง start, และ runtime logs ตรงนี้ได้เลย ซึ่งมักจะเป็นวิธีที่เร็วที่สุดในการหาต้นตอปัญหา
ก่อนที่เราจะเข้าคิวให้ผู้เชี่ยวชาญ ฉันสามารถช่วยแก้ปัญหาและประหยัดเวลารอให้คุณได้
| ความพยายาม | คำขอของฉัน | การตอบของ Kodee |
|---|---|---|
| 1 | “Can you connect me with a live agent?” | เสนอให้มันช่วยแก้เอง |
| 2 | “I’d still like to speak with a human agent. Please connect me.” | เสนออีกครั้ง ขอ domain และ start command |
| 3 | คลิก “Go to human” / พิมพ์ “I want to continue with a human” | ส่งต่อแล้ว |
ต้องขอแบบตรงและชัดเจนถึงสองครั้งก่อนที่ Kodee จะหยุดส่งฉันกลับไปหาตัวมันเอง สำหรับคำถามที่ฉันแก้เองได้ ความติดขัดนี้ถือว่าเล็กน้อย แต่สำหรับคนที่กำลังเผชิญเหตุขัดข้องและต้องการคนจริง ๆ มันคือจุดที่น่าหงุดหงิดจริง
สิ่งที่เกิดขึ้นต่อมาไม่ใช่การส่งต่อสดแบบที่คำว่า “connect me with a human” มักจะหมายถึง Kodee อธิบายโมเดลจริงอย่างตรงไปตรงมา:
ฉันได้ส่งคำขอของคุณไปยังผู้เชี่ยวชาญจากทีมของเรา ซึ่งจะตรวจสอบแชตของเราเป็นการส่วนตัวและส่งคำตอบกลับมาให้ฉัน แล้วฉันจะถ่ายทอดคำตอบนั้นให้คุณที่นี่
นี่คือการตรวจสอบแบบไม่พร้อมกัน ไม่ใช่การโอนสายสด Kodee ยังเป็นอินเทอร์เฟซอยู่; มนุษย์ตรวจบทสนทนาเบื้องหลังและ Kodee จึงถ่ายทอดคำตอบเมื่อมันมาถึง ความแตกต่างนี้สำคัญสำหรับผู้อ่านที่กำลังตัดสินใจว่าจะส่งต่อหรือไม่ เพราะ “human agent” ที่นี่ไม่ได้แปลว่ามีคนใหม่เข้ามาในหน้าต่างแชตเหมือนระบบไลฟ์แชตทั่วไป
ฉันกดดันหัวข้อทางเทคนิคเดิมต่อในระหว่างรอ โดยขอให้ Kodee ยืนยันเส้นทาง log ที่แน่นอน และถามว่า stderr.log จะถูกเติมเสมอหรือไม่ มันตอบได้ดีด้วยตัวเอง โดยระบุถูกต้องว่า log อาจว่างเปล่าหากแอปไม่เคยเริ่มทำงานเต็มที่หรือเขียนข้อผิดพลาดไว้ที่อื่น
ผลการตรวจสอบจากผู้เชี่ยวชาญมาหลังจากประมาณ 3 นาที มีชื่อในแชตว่า Mayas และคำตอบนั้นดีกว่าคำตอบของ Kodee เอง โดยแม่นยำกว่าและชัดเจนกว่า:
domains/[your-domain]/nodejs/stderr.log คือที่ตั้งที่ถูกต้อง มันไม่ได้ถูกสร้างหรือเติมเสมอไป คุณจะเห็นรายการในนั้นเมื่อแอปเขียนไปที่ stderr เช่น uncaught exceptions หรือ unhandled rejections หากคำสั่งเริ่มต้นผิดและโปรเซสออกโดยไม่มีเสียง stderr.log อาจว่างหรือไม่มีอยู่
Mayas ยังเพิ่มการตรวจสำรองอีกสองอย่างที่ Kodee ไม่ได้พูดถึง: ตรวจ stdout.log เพื่อดูเอาต์พุตสุดท้ายก่อนล่ม และดูบรรทัดยืนยันการเริ่มต้นที่หายไป ซึ่งเป็นสัญญาณว่าแอปไม่เคยเริ่มจริง
| การตรวจสอบ | ผลลัพธ์ |
|---|---|
| คำตอบทางเทคนิคครั้งแรกถูกต้อง | ใช่ |
| สามารถส่งต่อให้มนุษย์ได้ | ใช่ แต่ต้องต้านทานก่อนสองครั้ง |
| รูปแบบการส่งต่อ | เป็นการตรวจแบบไม่พร้อมกันและถ่ายทอด ไม่ใช่การโอนสด |
| ผู้ตอบที่ระบุชื่อ | Mayas |
| เวลาตอบกลับของการตรวจโดยมนุษย์ | ประมาณ 3 นาที |
| คำตอบของมนุษย์แม่นยำกว่าคำตอบ AI | ใช่ |
ฐานความรู้ของ 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” โดยตรง ซึ่งให้ผลลัพธ์ห้ารายการ ส่วนใหญ่เกี่ยวข้องเพียงเล็กน้อย รวมถึงคู่มือปลั๊กอิน affiliate marketing และบทความทั่วไปเกี่ยวกับ Node.js hosting
บทความที่อธิบายการตั้งค่า Connector จริง ๆ ชื่อว่า “How to Set Up Web Hosting MCP on Local IDEs” และอยู่ภายใต้ Features → General Information
การค้นหาด้วยชื่อการตลาดของผลิตภัณฑ์จริง ๆ เจอมัน แต่ผู้อ่านที่ไล่ดูตามหมวด หรือค้นหา “MCP” โดยไม่รู้แบรนด์ของ Hostinger อาจพลาดได้ง่าย และความไม่ตรงกันระหว่างชื่อที่ใช้การตลาดกับชื่อที่ใช้ในเอกสารก็ควรรู้ไว้ก่อนจะเริ่มค้นหา
บทความนั้นดีมากเมื่อหาเจอแล้ว มันอัปเดตล่าสุดหกวันก่อนที่ฉันจะทดสอบ และครอบคลุม:
จุดสุดท้ายตรงกับสิ่งที่ฉันพบโดยตรงในการทดสอบนี้: Devin Desktop ตรวจจับอัตโนมัติได้ ขณะที่ OpenAI Codex ต้องใช้วิธีแมนนวล บทความนี้อธิบายความแตกต่างนั้นได้ถูกต้อง
คำตอบแรกของ Kodee ต่อคำถามทางเทคนิคที่ยากนั้นแม่นยำและเฉพาะเจาะจง ซึ่งไม่ใช่สิ่งที่ผู้ช่วยสนับสนุน AI ทุกตัวทำได้ ฐานความรู้ที่รองรับก็ดีและละเอียดเมื่อคุณหามันเจอ แม้ชื่อการตลาดของผลิตภัณฑ์กับชื่อในเอกสารจะไม่ตรงกัน ดังนั้นการค้นหาจึงเชื่อถือได้กว่าการไล่ดูตามหมวด
จุดที่อ่อนกว่าคือเส้นทางส่งต่อไปยังมนุษย์ Kodee ส่งฉันกลับไปหามันเองถึงสองครั้งก่อนจะยอมรับคำขอที่ชัดเจนให้พูดกับคน และแม้จะได้คนแล้ว “human agent” ก็หมายถึงการตรวจแบบไม่พร้อมกันและส่งคำตอบผ่านแชตเดิม ไม่ใช่การโอนสายสด เมื่อมีมนุษย์ดูจริง คำตอบกลับดีกว่า Kodee เอง โดยแม่นยำกว่าและมีขั้นตอนวินิจฉัยเพิ่มอีกสองข้อที่ Kodee ไม่ได้เสนอ
สำหรับคำถามส่วนใหญ่ Kodee เพียงตัวเดียวก็จะให้คำตอบที่แม่นยำได้เร็ว ถ้าคุณต้องการให้คนช่วยยืนยันคำตอบจริง ๆ ให้เตรียมพร้อมว่าจะต้องขอมากกว่าหนึ่งครั้ง และต้องรอคำตอบที่ถูกส่งกลับมาผ่านแชตแทนการคุยแบบสด
คุ้มค่า สำหรับนักพัฒนาที่โฮสต์กับ Hostinger อยู่แล้วและอยากให้การดีพลอยแบบประจำจัดการจากเอดิเตอร์ได้ การตั้งค่าใช้เวลาเพียงไม่กี่นาที, OAuth ทำให้ไม่ต้องใช้ API key, และเมื่อมีเว็บไซต์ที่มีโดเมนชัดเจนแล้ว Connector ก็ส่งการอัปเดตขึ้นไลฟ์ได้ภายในประมาณหนึ่งนาทีพร้อมบันทึกให้ตรวจสอบ Kodee เองก็ให้คำตอบสนับสนุนที่เฉียบพอจะแก้ปัญหาทางเทคนิคจริงได้ตั้งแต่ครั้งแรก
ข้อควรระวังคือเรื่องความไว้วางใจ ไม่ใช่ความสะดวก เมื่อเจอเป้าหมายใหม่ที่มันหาไม่เจอ Connector กลับสร้างโดเมนขึ้นมาเองและลงมือก่อนตรวจสอบ
มันยังติดป้ายดีพลอยที่เสียว่า “completed” ในขณะที่แอปจริงล่มอยู่ โดยไม่มีข้อผิดพลาดตอนรันไทม์ในบันทึกของมันเอง ใช้มันเพื่อเร่งงานบนไซต์ที่มีอยู่แล้ว ตรวจสอบทุกอย่างที่มันทำกับเป้าหมายใหม่ และเช็กเว็บไซต์จริงด้วยตัวคุณเองหลังการดีพลอยที่สำคัญ
| ชื่อแพลน | เนื้อที่ | CPU | RAM | OS | ราคา | |
|---|---|---|---|---|---|---|
| Free Trial | ไม่จำกัด | - | ฿0 | รายละเอียด | ||
| KVM 1 | 50 GB | 1 core | 4 GB | ฿190 | รายละเอียด | |
| KVM 2 | 100 GB | 2 core | 8 GB | ฿250 | รายละเอียด | |
| KVM 4 | 200 GB | 4 core | 16 GB | ฿370 | รายละเอียด | |
| KVM 8 | 400 GB | 8 core | 32 GB | ฿730 | รายละเอียด |
| Description | Expert Review |
|---|---|
| โฮสติ้งราคาประหยัดพร้อมประสิ�... | Read Shared Hosting Review |
| โฮสติ้ง WordPress ที่ ast และปลอดภัย พร�... | Read Wordpress Hosting Review |
| โฮสติ้ง VPS ที่ปรับขนาดได้ พร้อม�... | 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 |
| โฮสติ้งที่รวดเร็วและยืดหยุ่น ... | Read Nodejs Hosting Review |
| โฮสติ้งที่ปรับให้เหมาะสมสำหร�... | Read Woocommerce Hosting Review |
| โฮสติ้งเซิร์ฟเวอร์เฉพาะสำหรั�... | Read Minecraft Server Hosting Review |
| โซลูชันการโฮสต์ที่ปรับขนาดได�... | Read Agency Hosting Review |
| โฮสติ้งที่รวดเร็วและปลอดภัย ป... | 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 |
| โฮสติ้งที่รวดเร็วและได้รับกา�... | Read Ruby on Rails Review |
| โฮสติ้งที่อัดแน่นด้วยฟีเจอร์�... | 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 key ไม่ได้วางโทเค็นลงในตัวแก้ไข และไม่ได้เก็บข้อมูลรับรองไว้ในไฟล์การกำหนดค่า
No. Hostinger ระบุว่า การเรียกใช้ Connector API จะโต้ตอบกับบัญชีจริง ใช้เว็บไซต์ทดสอบ โดเมน หรือ VPS เฉพาะสำหรับการเรียนรู้เวิร์กโฟลว์ อย่าคิดว่าพรอมต์ถูกจำลองขึ้นเพียงเพราะส่งผ่านแชต AI
ใช่ Hostinger ระบุขีดจำกัดเริ่มต้นไว้ดังนี้:
– 60 คำขอต่อนาที
– 1,000 คำขอต่อชั่วโมง
Hostinger ยังระบุด้วยว่ารายละเอียดของ rate-limit จะแสดงอยู่ในส่วนหัวของการตอบกลับ
ขีดจำกัดเหล่านี้ควรเพียงพอสำหรับการใช้งานแบบโต้ตอบทั่วไป หลีกเลี่ยงการเรียกซ้ำที่ไม่จำเป็น โดยเฉพาะเมื่อการตอบกลับก่อนหน้าได้มีข้อมูลที่ต้องการอยู่แล้ว
ใช่ ฉันได้ปรับใช้แอปพลิเคชัน Express.js ไปยัง Hostinger และต่อมาจึงใช้ Connector เพื่อเผยแพร่เวอร์ชันที่อัปเดตจาก VS Code Hostinger ตรวจพบ Express เลือก Node.js 22.x และใช้โฟลเดอร์รากของโปรเจกต์เป็นไดเรกทอรีรากในระหว่างการปรับใช้ครั้งแรกผ่าน hPanel เมื่อเว็บไซต์มีอยู่แล้วในฐานะเป้าหมาย Node.js ที่รู้จัก การปรับใช้อีกครั้งผ่าน Connector ก็ทำงานได้สำเร็จ
ไม่จำเป็นเสมอไป ในการทดสอบที่ควบคุมของฉัน Hostinger แสดงว่าบิลด์เสร็จสมบูรณ์หลังจากที่ฉันเปลี่ยนสคริปต์เริ่มต้นให้ไปอ้างอิงไฟล์ JavaScript ที่ไม่มีอยู่จริง ล็อกบิลด์ที่ดึงมาได้แสดงการติดตั้ง dependency สำเร็จ แต่ไม่ได้เปิดเผยความล้มเหลวของการเริ่มรันไทม์ ควรตรวจสอบเว็บไซต์ที่ใช้งานจริงหรือเรียกใช้ health endpoint หลังการ deploy เสมอ
ไม่ทั้งหมด Connector สามารถลดความถี่ที่นักพัฒนาต้องออกจากโปรแกรมแก้ไขของตนได้ โดยเฉพาะอย่างยิ่งสำหรับการ deploy และการตรวจสอบบัญชีแบบปกติ hPanel ยังคงมีประโยชน์สำหรับการจัดการบัญชีแบบเห็นภาพ การตั้งค่าเริ่มต้น การกำหนดค่าละเอียด และสถานการณ์ที่ AI ไม่สามารถค้นพบหรือเปิดเผยทรัพยากรที่ต้องการได้อย่างถูกต้อง
ตอบคำถามไม่กี่ข้อและค้นหาคำตอบที่เหมาะสมสำหรับคุณ!
เริ่มต้นการค้นหาโฮสติ้ง
