إدارة الاستضافة عادةً ما تقطع سير التطوير. تكتب الشيفرة في محرر، وتفتح لوحة تحكم الاستضافة لإنشاء موقع ويب، وتنتقل إلى الطرفية لحزم المشروع أو دفعه، ثم تعود إلى لوحة التحكم لفحص عملية نشر، وتفتح أدوات أخرى عندما تحتاج DNS أو السجلات أو موارد الخادم إلى اهتمام.
Hostinger Connector يقلل من هذا التبديل بين السياقات. فهو يربط خدمات Hostinger بأدوات البرمجة بالذكاء الاصطناعي عبر Model Context Protocol (MCP)، مما يتيح لك أن تطلب من مساعد ذكاء اصطناعي فحص موارد الاستضافة المدعومة أو إدارتها من دون مغادرة المحرر.
يبدو ذلك مريحًا. لكنه يثير سؤالًا أهم: هل يمكنك الوثوق بمساعد ذكاء اصطناعي لتنفيذ مهام استضافة حقيقية بدقة؟
لأعرف ذلك، اختبرت Hostinger Connector مع VS Code وGitHub Copilot على حساب Hostinger حقيقي. استخدمت تطبيق Express.js صغيرًا يُدعى PulseWatch واتّبعت سير العمل من التثبيت إلى النشر المباشر. كما اختبرت عمليات نشر متكررة، وسجلات البناء، والسجلات، والاستعادة بعد أن تعمدت كسر أمر بدء تشغيل التطبيق.
إليك كيف قيّمت Hostinger Connector عبر الجوانب التي تهم أكثر المطور الذي يقرر ما إذا كان سيستخدمه: التكلفة، ومدى الميزات، وسهولة الاستخدام اليومية، ومدى دقة تنفيذه للمهام الحقيقية، والدعم المتاح عندما يحدث خطأ. كل درجة تعكس ما وجدته فعلًا أثناء الاختبار، لا صفحة التسويق.
| المعيار | الدرجة | لماذا هذه الدرجة |
|---|---|---|
| الأسعار | 9.7/10 | لا يحمل Connector أي رسوم اشتراك منفصلة على الإطلاق، بل يأتي مجانيًا مع كل خطة. التكلفة الوحيدة هي مورد الاستضافة الأساسي الذي كنت ستحتاجه على أي حال. |
| الميزات | 9.5/10 | يمتد نطاق الميزات إلى ما هو أبعد من النشر ليشمل المواقع والنطاقات وDNS وقواعد البيانات وحملات البريد الإلكتروني وموارد VPS والسجلات والتشخيصات، مما يغطي مجالًا أوسع من أداة نشر نموذجية. |
| سهولة الاستخدام | 9.1/10 | كان التثبيت وOAuth سريعين ولم يتطلبا أي إعداد يدوي، وكانت عمليات النشر المتكررة سهلة. تطلب إعداد موقع Node.js الأولي استخدام hPanel بعد أن فشل الذكاء الاصطناعي في تحديد هدف صالح، وهي الفجوة الحقيقية الوحيدة في إعداد سلس بخلاف ذلك. |
| دقة التنفيذ | 8.5/10 | عمل تحليل المشروع، وتحرير الشيفرة، والتغليف، والنشر، والاستعادة بشكل جيد. أعاد الذكاء الاصطناعي استخدام نطاق مُختلق وفسر فحص الوصولية بشكل مفرط قبل أن يوجد ذلك الهدف. |
| الدعم | 9.5/10 | قدّم Kodee إجابة دقيقة ومحددة على سؤال تقني حقيقي من المحاولة الأولى، وكان ردّ المختص البشري أدقّ حتى. استغرق التصعيد طلبين مباشرين، لكن كلًا من إجابات الذكاء الاصطناعي والبشر كانت موثوقة بعد الحصول عليها. |
| الإجمالي | 9.3/10 | أداة سير عمل مفيدة لمستخدمي Hostinger الذين يعملون في محررات مدعومة بالذكاء الاصطناعي. تكلفتها لا تزيد شيئًا، وتغطي مجموعة واسعة من الميزات، وقد صمد كل من الإعداد والدعم جيدًا في الاختبار. دقة التنفيذ عند أهداف النشر الجديدة هي المجال الوحيد الذي يجب الانتباه إليه. |
لا يُباع Hostinger Connector كمنتج مستقل. تقول Hostinger إن Connector مشمول مجانًا مع كل خطة، وهذا يعني أنه لا توجد رسوم شهرية منفصلة لـ Connector تُضاف إلى فاتورة الاستضافة.
لكن “مجاني” يحتاج إلى سياق. يقوم Connector بإدارة موارد Hostinger؛ ولا يستبدلها. لا تزال بحاجة إلى خدمة استضافة أو سحابة أو VPS أو نطاق أو بريد إلكتروني أو أي خدمة Hostinger أخرى مؤهلة للمهام التي تريد أن ينفذها.
في وقت كتابة هذا التقييم، كانت صفحة 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 لتقييمها لأنه لا يفرض رسومًا مستقلة.
تعتمد الإجراءات الدقيقة المتاحة على خدمات Hostinger الموجودة في حسابك والأدوات التي يعرضها عميل الذكاء الاصطناعي المتصل.
توثّق Hostinger أيضًا حدود المعدل. ووفقًا لصفحة الأسئلة الشائعة الخاصة بـ Connector، فإن الحد الافتراضي هو 60 طلبًا في الدقيقة و1,000 طلب في الساعة، مع إرجاع معلومات الحد في ترويسات الاستجابة.
تلك الحدود سخية للاستخدام التفاعلي، رغم أن سير العمل الآلي أو شديد التكرار يجب أن يتجنب مع ذلك الطلبات المكررة غير الضرورية.
قبل أن أتمكن من الحكم على ما إذا كان Hostinger Connector ينشر الاستضافة ويديرها جيدًا، احتجت إلى معرفة ما يلزم لتشغيله من الأساس.
أداة مصممة للبقاء داخل المحرر تفقد جاذبيتها سريعًا إذا كان الإعداد يعني تعديل ملفات الإعداد، أو إنشاء رموز API، أو إعادة المصادقة مرارًا. يغطي هذا القسم الإعداد فقط. يلي ذلك مباشرة اختبار المهام العملي.
ثبّتُّ Hostinger Connector من VS Code Marketplace. ظهر كأول نتيجة عندما بحثت عن “Hostinger”، وكان الناشر مذكورًا على أنه Hostinger Official، وتم التثبيت من أول محاولة في أقل من دقيقتين.
| التفصيل | النتيجة |
|---|---|
| البحث في Marketplace | نجح، وظهر فورًا |
| التحقق من الناشر | Hostinger Official |
| التثبيت | اكتمل في أقل من دقيقتين |
| إصدار الإضافة وقت الاختبار | 1.3.1 |
| عمليات التثبيت في Marketplace | 8,140 |
| تقييم المستخدم | 5 نجوم، بناءً على تقييمين |
السطر الأخير يستحق التحفظ. خمس نجوم تبدو قوية، لكن عينة من تقييمين لا تخبرني بالكثير عن التجربة المعتادة للمستخدم. لن أعتمد على هذا الرقم في نص المراجعة.
فاجأني شرط مسبق واحد: يوفر Hostinger Connector أدوات Hostinger، لكنه يحتاج إلى وكيل ذكاء اصطناعي نشط بالفعل داخل المحرر كي يستدعيها فعليًا.
الإضافة نفسها لا تملك شيئًا تتحدث إليه بمفردها. في VS Code، يكون ذلك الوكيل هو GitHub Copilot Chat، لأنه حاليًا واجهة الذكاء الاصطناعي التي يعرضها VS Code لاستدعاءات أدوات MCP. كان Copilot نشطًا لدي بالفعل، لذا لم يبطئني هذا، لكن ينبغي أن يعرف القراء أن Connector لا يفيد إلا بقدر فائدة وكيل الذكاء الاصطناعي الموجود خلفه.
من دون تثبيت وكيل وتسجيل الدخول إليه، لا يوجد شيء يمكن أن يتصل به.
ما الذي لم يتطلبه التثبيت:
كان تثبيت الإضافة نفسها من أسلس أجزاء الاختبار بأكمله. القيد الحقيقي الوحيد هو اعتماد Hostinger لا يضعه في الواجهة بشكل واضح: تحتاج الإضافة إلى وكيل ذكاء اصطناعي نشط داخل المحرر كي تفعل أي شيء.
مع وجود الإضافة في مكانها، كان السؤال التالي هو ما إذا كان ربطها بحساب حقيقي سيكون بسيطًا بالقدر نفسه.
تم ربط الحساب عبر 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 لكنه مهم لأي شخص يقرر مقدار الوصول إلى الحساب الذي يمنحه لمساعد ذكاء اصطناعي. أعدّه نقطة قوة حقيقية.
كان إلغاء ربط الحساب متاحًا من اللوحة نفسها، من دون الحاجة إلى تغيير كلمة مرور Hostinger أو البحث عن رمز مخزّن.
كانت المصادقة سريعة ولم تتطلب مني إدارة رمز بنفسي، لكن شاشة الأذونات عامة أكثر مما هي تفصيلية. عناصر التحكم على مستوى الفئات داخل الإضافة تفعل أكثر للحد من المخاطر الحقيقية من شاشة OAuth نفسها.
تذكر 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 script للبدء، ونقطة نهاية /api/health تعيد JSON. واتضح أن نقطة النهاية الصحية تلك كانت مهمة لاحقًا.
يمكن لمنصة استضافة أن تُبلغ عن اكتمال البناء بينما يفشل التطبيق عند بدء التشغيل. منحتني نقطة نهاية حية وسيلة مستقلة للتحقق مما إذا كانت العملية المنشورة تستجيب فعلًا، بدلًا من الوثوق بشارة الحالة.
بدأت بطلبات للقراءة فقط قبل أن أسمح للمساعد بالاقتراب من أي تغييرات حية. إذا لم يستطع وصف حسابي بدقة، فلن يكون لدي سبب كبير للثقة به في عمليات النشر أو 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 | لم يكن هذا النطاق قد عاد من أي استدعاء لسرد المواقع |
| 2 | أجرى فحص الوصولية على ذلك النطاق | أعاد is_accessible: true |
| 3 | اعتبر تلك النتيجة تأكيدًا على وجود الموقع | غير صحيح. الوصولية ليست هي نفسها سجل موقع موجود وقابل للنشر |
| 4 | حاول النشر باستخدام معرفات موارد لم يتحقق منها على أنها معرفات طلب استضافة | أعاد Hostinger [Hosting:9999] Not found، مرتين |
المشكلة الأساسية: المعرفان اللذان استخدمهما كانا معرفي موارد نطاق، لا معرفي طلب استضافة. ولم يؤكد هذا التمييز قبل استدعاء أداة إنشاء موقع حي بهما.
عندما طلبت منه شرح ما فعل، قدم المساعد في النهاية رواية دقيقة: كانت لديه طوال الوقت أداة عاملة لسرد المواقع، لكنه لم يستدعها مرة أخرى بعد أن أنشأت موقعًا جديدًا عبر hPanel، فملأ الفجوة بنطاق غير مُتحقق منه بدلًا من تحديث بياناته.
عندما طلبت منه مباشرة أن يعيد تشغيل أداة السرد تلك ويتحقق من وجود سجل جديد، استدعى ثلاث أدوات أخرى غير ذات صلة خاصة باستخراج بيانات النشر، وذكر أن “موقعًا جديدًا لم يظهر”، وهو استنتاج لا يمكن أن تدعمه الاستدعاءات التي نفذها فعلًا.
لم يؤدِ أي من ذلك إلى إنشاء موقع ويب عالق في حسابي. لم تترك الاستدعاءات الفاشلة أي شيء وراءها. لكن النمط يستحق أن يُقال بوضوح. عند نقص البيانات، ملأ المساعد الفجوة بافتراض يبدو معقولًا، وتعامل مع إشارة ضعيفة باعتبارها دليلًا قويًا، وتصرف على حساب حي قبل التحقق من ذلك الافتراض.
هذه هي أهم نتيجة في هذا القسم. سيخمن Connector الهدف ويتصرف بناءً على هذا التخمين بدلًا من أن يتوقف ويسأل. لقد فشل بأمان هنا، لكن عادة التعامل مع إشارة ضعيفة كأنها إثبات هي ما يجب الانتباه إليه في حسابك أنت.
مع عجز Connector عن تحديد الهدف بنفسه، لم يتبقَّ أمامي سوى خيار واحد: أن أبني الهدف بنفسي وأرى ما إذا كان ذلك سيغيّر شيئًا.
بما أن Connector لم يتمكن من تحديد الهدف الجديد بشكل موثوق بنفسه، أنهيت الإعداد الأولي يدويًا عبر hPanel لأرى ما الذي يجهزه Hostinger قبل أن يصبح النشر عبر Connector ممكنًا.
كان المسار: إنشاء موقع جديد → تطبيق ويب Node.js → نطاق مؤقت → اختيار Hostinger تلقائيًا لمركز بيانات في المملكة المتحدة مع زمن وصول مُقدّر يبلغ 147ms → ثلاث طرق للنشر.
تستحق الشاشة الثالثة التنبيه بحد ذاتها. تعرض Hostinger “Build with Hostinger Connector” كطريقة نشر إلى جانب استيراد GitHub والرفع اليدوي للملفات. اخترتها متوقعًا أن تكمل إعداد الموقع.
بدلًا من ذلك، أعادت توجيهي إلى صفحة تثبيت 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 وطلبت منه فحص ذلك النطاق بالذات. هذه المرة نجح بوضوح.
| الفحص | النتيجة |
|---|---|
| تعرف على الموقع كهدف نشر 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 تمت مراجعتها، ولا توجد ثغرات، ولا أخطاء.
بالنسبة للمواقع القائمة، هذا قريب جدًا من سير العمل الذي تعد به 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 | تم تثبيت الاعتمادات، واكتملت مرحلة البناء | أن التطبيق بدأ فعليًا |
| Deployment: completed | قبلت Hostinger الإصدار وعالجته | أن كل المسارات سليمة |
أظهرت سجلات البناء المتاحة عبر Connector نجاح تثبيت الاعتمادات ولا شيء آخر. لم يظهر خطأ وقت التشغيل الخاص بالملف المفقود في السجلات. لن يكون لدى أي مطور يلمح إلى شارة “completed” خضراء سبب ليفترض أن الموقع معطل.
كانت الاستعادة سلسة. استعاد المساعد package.json من النسخة الاحتياطية، وتحقق من التطبيق محليًا، وأعاد النشر، وتأكد من الإصلاح عبر استدعاء نقطة النهاية /api/health الحية مباشرة بدلًا من الثقة في حالة النشر وحدها.
أعادت نقطة النهاية تلك ردًا عمليًا، وكان ذلك الدليل الوحيد في الاختبار كله الذي أثبت بالفعل أن التطبيق يعمل.
هذه هي النتيجة الثانية الكبرى. الحالة المكتملة ليست دليلًا على أن التطبيق يعمل، وسجلات Connector نفسها لن تخبرك بذلك. أما التعافي نفسه فعمل جيدًا بمجرد أن عرفت بوجود مشكلة يجب التعافي منها.
بعد فشل لم تستطع شارة الحالة كشفه، أردت أن أعرف أين أيضًا قد تتجاوز ثقة Connector قدرته الفعلية. كانت متغيرات البيئة هي الاختبار التالي.
طلبت من المساعد إضافة متغير بيئة غير ضار، والتأكد مما إذا كانت هذه الإعدادات موجودة كقدرة مخصصة في Connector قبل لمس أي شيء، والتوقف إذا لم تكن موجودة.
بحث في الأدوات المتاحة، ولم يجد أي إجراء مخصص لإدارة متغيرات بيئة Node.js، فتوقف قبل إجراء أي تغييرات على الشيفرة أو النشر.
هذا هو السلوك الذي أردت رؤيته في كل مكان آخر في هذا الاختبار. عندما واجه حدًا حقيقيًا، توقف بدلًا من التخمين. لن أستنتج أن Hostinger Connector لا يملك دعم متغيرات البيئة في أي مكان من أدواته، بل فقط أن أي إجراء من هذا النوع لم يكن معروضًا أثناء هذا الاختبار.
| الاختبار | النتيجة | الاستنتاج الرئيسي |
|---|---|---|
| نسخ البيان العامل احتياطيًا | نجح | تم إنشاء ملف استعادة قبل التعديل |
| إدخال نقطة دخول مفقودة | نجح | أُضيف فشل مضبوط |
| إعادة إنتاج الفشل محليًا | نجح | MODULE_NOT_FOUND تأكد |
| نشر النسخة المعطلة | نجح | قبلت Hostinger الأرشيف |
| هل تكشف حالة البناء عن الفشل | فشل | ظل البناء يظهر على أنه مكتمل |
| هل تكشف سجلات البناء خطأ التشغيل | فشل | لم يظهر خطأ الملف المفقود |
| استعادة البيان العامل | نجح | تمت استعادة أمر البدء الأصلي |
| إعادة نشر النسخة العاملة | نجح | اكتمل النشر |
| التحقق من نقطة النهاية الصحية الحية | نجح | أعاد API حالة تشغيلية |
أدى Hostinger Connector المهام الروتينية المحددة جيدًا بشكل جيد:
وكان أضعف عندما تطلبت المهمة تفسيرًا عبر بيانات حساب غير مكتملة:
هذا النمط مفيد عند تحديد مقدار الاستقلالية التي تمنحها للمساعد.
استخدم مطالبات أوسع للفحص منخفض المخاطر. واستخدم مطالبات دقيقة ومتطلبات تأكيد صريحة للإجراءات التي تغير البنية التحتية الحية.
على سبيل المثال، بدلًا من:
| انشر هذا التطبيق على موقع Hostinger مؤقت جديد. |
استخدم:
| اسرد المواقع التي يعرضها Hostinger حاليًا. حدّد موقع Node.js فقط إذا ظهر في تلك النتيجة. اعرض لي النطاق الدقيق والدليل قبل النشر. لا تنشئ نطاقًا ولم يرد من Hostinger ولا تستنتجه ولا تعِد استخدامه. |
المطالبة الثانية تضيق مساحة التخمين لدى المساعد.
كان تشغيل Hostinger Connector سهلًا، من دون أي احتكاك معتاد في الإعداد، ومنحتني عناصر التحكم التفصيلية على مستوى فئات الأدوات رأيًا حقيقيًا في ما يمكن للذكاء الاصطناعي لمسه.
بمجرد وجود موقع ويب حقيقي بعنوان معروف، أنجز المهمة بشكل جيد: انتقل تغيير نص من سطر واحد من التعديل إلى البث المباشر في نحو دقيقة، مدعومًا بسجلات بناء مفيدة.
ظهرت المشكلة في وقت أبكر من العملية، لا في نهايتها. عندما واجه هدفًا جديدًا لم يتمكن من العثور عليه، اخترع Connector نطاقًا وتصرف بناءً عليه قبل التحقق. كما وضع وسم “completed” على نشر معطل بينما كان التطبيق في الحقيقة متوقفًا، من دون أن يظهر خطأ التشغيل في سجلاته الخاصة. لا تجعل أيًّا من هاتين النقطتين الأداة غير موثوقة للمواقع القائمة، لكن كلتيهما تعنيان أن عمليات النشر الجديدة وحالة ما بعد النشر تحتاجان إلى نظرة ثانية قبل أن تثق بهما.
تبني Hostinger دعمها حول الدردشة الحية والخدمة الذاتية بدلًا من المكالمات الهاتفية، لذلك ركزت اختباري على المسار الذي سيسلكه معظم المستخدمين فعلًا: المساعد الذكي المدمج في hPanel، والتصعيد البشري خلفه، وقاعدة المعرفة التي سيلجأ إليها المطور قبل فتح دردشة أصلًا.
| القناة | التوفر | ملاحظات |
|---|---|---|
| الدردشة الحية (Kodee، الذكاء الاصطناعي) | 24/7 | يمكن الوصول إليها عبر “Ask AI” في hPanel |
| الدردشة الحية (بشر) | عبر التصعيد فقط | ليست قائمة مباشرة، بل تُوجَّه عبر Kodee |
| البريد الإلكتروني / التذكرة | support@hostinger.com | نافذة استجابة مذكورة مدتها يوم عمل واحد |
| الهاتف | غير متاح | لا يوجد خط هاتف عام للدعم |
| قاعدة المعرفة | خدمة ذاتية | support.hostinger.com |
| البرامج التعليمية وAcademy | خدمة ذاتية | أدلة خطوة بخطوة وقناة YouTube |
بما أن الدردشة الحية هي القناة التي توجه Hostinger المطورين إليها لأي أمر عاجل، وهي الأكثر احتمالًا أن تُستخدم أثناء تصحيح عملية نشر، فقد اختبرت ذلك المسار مباشرة بدلًا من إرسال تذكرة بريد إلكتروني.
فتحت الدردشة الحية عبر “Ask AI” في hPanel وطرحت على Kodee سؤالًا يمكن أن يُخطئ فيه جواب حقيقي: هل يضمن وضع بناء مكتمل على نشر Node.js أن التطبيق يعمل فعلًا، وأين سأجد الدليل على عكس ذلك.
كانت إجابة Kodee الأولى محددة وصحيحة:
“Completed” تعني عادةً أن مرحلة البناء انتهت بنجاح؛ لكنها لا تضمن أن التطبيق سليم بعد التشغيل. لاكتشاف أمر بدء تشغيل خاطئ أو تعطل آخر في وقت التشغيل، تحقق من سجلات وقت التشغيل: في hPanel انتقل إلى Websites → Dashboard → Deployments لسجلات البناء، ثم افتح stderr.log للتطبيق في مجلد nodejs لأخطاء البدء مثل Port already in use أو Module not found.
كانت تلك الإجابة وحدها ستعالج الغموض نفسه الذي واجهني في اختبار التعافي من الفشل الذي أجريته سابقًا في هذه المراجعة. سمّى Kodee ملف سجل حقيقيًا، والمجلد الصحيح، وميز بشكل صحيح بين نجاح البناء وصحة التشغيل.
ومع ذلك، أردت أيضًا أن أرى إن كان بإمكاني الوصول إلى موظف بشري حقيقي، لذلك قلت لـ Kodee إنني أود تأكيد ذلك مباشرة مع مهندس دعم.
لكن الحصول على إنسان على الخط كان أصعب مما توقعت. طلبت مباشرة وكيلًا حيًا، وأُعيد توجيهي إلى Kodee مرتين، وكل مرة كان ذلك مبررًا بأنه أسرع من الانتظار:
أتفهم لماذا تريد ذلك. أستطيع مساعدتك في التحقق من البناء وأمر البدء وسجلات التشغيل هنا، وهو عادةً أسرع طريقة لتحديد المشكلة.
قبل أن نصعد الأمر إلى مختص. أستطيع حل المشكلة وتوفير الانتظار عليك.
| المحاولة | طلبي | رد Kodee |
|---|---|---|
| 1 | “Can you connect me with a live agent?” | عرض حل المشكلة بنفسه |
| 2 | “I’d still like to speak with a human agent. Please connect me.” | عرض مرة أخرى، وطلب النطاق وأمر البدء |
| 3 | Clicked “Go to human” / typed “I want to continue with a human” | صعّد الأمر |
استغرق الأمر طلبين مباشرين وصريحين قبل أن يتوقف Kodee عن إعادتي إلى نفسه. بالنسبة لسؤال يمكنني حله بنفسي، فذلك الاحتكاك بسيط. أما بالنسبة لشخص في خضم انقطاع ويريد إنسانًا، فذلك مصدر إحباط حقيقي.
ما حدث بعد ذلك لم يكن تسليمًا مباشرًا بالمعنى المعتاد لعبارة “connect me with a human”. شرح 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 الإجابة عندما تصل. هذا التفريق مهم للقراء الذين يقررون ما إذا كانوا سيصعّدون الأمر، لأن “وكيل بشري” هنا لا يعني أن شخصًا جديدًا ينضم إلى نافذة الدردشة بالطريقة المعتادة في أنظمة الدردشة الحية.
دفعت السلسلة التقنية نفسها أكثر بينما كنت أنتظر، وطلبت من Kodee تأكيد مسار السجل الدقيق وما إذا كان stderr.log يمتلئ دائمًا. قدّم إجابة سليمة بمفرده، ولاحظ بشكل صحيح أن السجل قد يكون فارغًا إذا لم يبدأ التطبيق بالكامل أو كتب خطأه في مكان آخر.
وصلت مراجعة المختص في نحو 3 دقائق، ونُسبت داخل الدردشة إلى زميلة تُدعى Mayas، وقد حسّنت الإجابة بدلًا من مجرد تكرارها:
domains/[your-domain]/nodejs/stderr.log هو الموقع الصحيح. لكنه ليس دائمًا منشأًا أو ممتلئًا. لن ترى إدخالات هناك إلا عندما يكتب التطبيق إلى stderr، مثل حالات الاستثناءات غير المعالجة أو الرفضات غير المعالجة. إذا كان أمر البدء خاطئًا وخرجت العملية بصمت، فقد يكون stderr.log فارغًا أو مفقودًا.
وأضافت Mayas أيضًا فحصين بديلين لم يذكرهما Kodee: التحقق من stdout.log لآخر إخراج قبل التعطل، والبحث عن غياب سطر تأكيد بدء التشغيل كعلامة على أن التطبيق لم يبدأ أبدًا.
| الفحص | النتيجة |
|---|---|
| الإجابة التقنية الأولى كانت دقيقة | نعم |
| التصعيد إلى بشر متاح | نعم، لكن بعد مقاومة مرتين قبل الموافقة |
| نموذج التصعيد | مراجعة غير متزامنة ثم نقل، وليس تحويلًا مباشرًا |
| اسم المراجع | Mayas |
| زمن الاستجابة للمراجعة البشرية | حوالي 3 دقائق |
| هل كانت إجابة الإنسان أدق من إجابة الذكاء الاصطناعي | نعم |
تنظم قاعدة معرفة 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.
البحث باستخدام الاسم التسويقي للمنتج عثر عليه، لكن القارئ الذي يتنقل بين الفئات أو يبحث عن “MCP” من دون أن يعرف تسمية Hostinger قد يفوته بسهولة، وعدم تطابق الاسم التسويقي مع الاسم الموثق يستحق المعرفة قبل أن تبدأ البحث.
المقال نفسه قوي بمجرد العثور عليه. وقد تم تحديثه آخر مرة قبل ستة أيام من اختباري، ويغطي:
تطابق ذلك مع شيء واجهته مباشرة أثناء الاختبار: Devin Desktop يُكتشف تلقائيًا، بينما يتطلب OpenAI Codex الطريقة اليدوية. المقال يصيب هذا التفريق بشكل صحيح.
كانت إجابة Kodee الأولى على سؤال تقني صعب دقيقة ومحددة، وهو ليس أمرًا ينجح فيه كل مساعد دعم ذكي اصطناعي. كما أن مقال قاعدة المعرفة الذي يدعمها حديث ومفصل بمجرد العثور عليه، رغم أن الاسم التسويقي للمنتج وعنوان التوثيق لا يتطابقان، لذا فالبحث أكثر موثوقية من التصفح بين الفئات.
النقطة الأضعف هي مسار التصعيد البشري. أعادني Kodee إليه مرتين قبل أن يستجيب لطلب صريح بالحصول على شخص، وحتى حينها، فإن “وكيلًا بشريًا” يعني مراجعة غير متزامنة تُنقل عبر نفس الدردشة بدلًا من تحويل مباشر. وبمجرد أن نظر إنسان إلى الأمر، كانت الإجابة أفضل من إجابة Kodee نفسه، وأكثر دقة، ومع خطوتين تشخيصيتين إضافيتين لم يقدمهما Kodee.
بالنسبة لمعظم الأسئلة، سيمنحك Kodee وحده إجابة دقيقة بسرعة. إذا كنت تريد فعلًا شخصًا يؤكد الإجابة، فتوقع أن تطلب أكثر من مرة، وتوقع انتظارًا قصيرًا لإجابة منقولة بدلًا من محادثة مباشرة.
نعم، للمطورين الذين يستضيفون بالفعل لدى Hostinger ويريدون تنفيذ عمليات النشر الروتينية من داخل المحرر. استغرق الإعداد دقائق، وأزال OAuth الحاجة إلى مفاتيح API، وبمجرد وجود موقع ويب بعنوان معروف، أنجز Connector تحديثًا مباشرًا في نحو دقيقة مع سجلات تدعمه. كانت إجابات Kodee الداعمة نفسها حادة بما يكفي لحل مشكلة تقنية حقيقية من أول محاولة.
المشكلة هنا هي الثقة، لا الراحة. عندما واجه هدفًا جديدًا لم يتمكن من العثور عليه، اخترع Connector نطاقًا وتصرف بناءً عليه قبل التحقق.
كما وضع علامة “completed” على نشر معطل بينما كان التطبيق متوقفًا فعليًا، من دون أي خطأ وقت تشغيل في سجلاته الخاصة. استخدمه لتسريع العمل على المواقع الموجودة بالفعل، وتحقق من أي شيء يفعله على هدف جديد تمامًا، وافحص الموقع الحي بنفسك بعد أي نشر مهم.
| اسم الخطة | مساحة | وحدة المعالجة المركزية | ذاكرة عشوائية | نظام تشغيل | السعر | |
|---|---|---|---|---|---|---|
| Free Trial | غير محدود | - | US$ 0,00 | التفاصيل | ||
| KVM 1 | 50 جيجابايت | 1 مراكز | 4 جيجابايت | US$ 5,52 | التفاصيل | |
| KVM 2 | 100 جيجابايت | 2 مراكز | 8 جيجابايت | US$ 7,47 | التفاصيل | |
| KVM 4 | 200 جيجابايت | 4 مراكز | 16 جيجابايت | US$ 11,04 | التفاصيل | |
| KVM 8 | 400 جيجابايت | 8 مراكز | 32 جيجابايت | US$ 22,09 | التفاصيل |
| Description | Expert Review |
|---|---|
| استضافة اقتصادية ذات أداء عالٍ وأدوات إدارة سه... | Read Shared Hosting Review |
| استضافة WordPress سريعة وآمنة مع تثبيت بنقرة واحدة ... | Read Wordpress Hosting Review |
| استضافة VPS قابلة للتوسع مع موارد مخصصة ووصول بص... | Read VPS Review |
| استضافة سحابية سريعة ومرنة مع وقت تشغيل ممتاز �... | Read Cloud Hosting Review |
| حلول استضافة آمنة وخاصة مع مواقع مراكز بيانات �... | Read Offshore Hosting Review |
| استضافة بريد إلكتروني آمنة وموثوقة مع ميزات من... | Read Email Hosting Review |
| استضافة بايثون موثوقة مع بيئات مرنة للمطورين. | 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 |
| استضافة سريعة وآمنة مُحسّنة لمواقع التجارة ال�... | Read Magento Hosting Review |
| استضافة عالية الأداء مبنية على لينكس لعمليات م... | Read Linux Hosting Review |
| حلول استضافة جافا قوية لتطبيقات ومشاريع الويب ... | 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 |
| استضافة غنية بالميزات مع تكامل 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 هو تكامل قائم على MCP يربط بيئات الترميز بالذكاء الاصطناعي المدعومة بخدمات Hostinger.
يتيح لمساعد الذكاء الاصطناعي استدعاء أدوات Hostinger المدعومة للمهام المتعلقة بالمواقع الإلكترونية، وعمليات النشر، والنطاقات، وDNS، وقواعد البيانات، والبريد الإلكتروني، وموارد VPS.
لا يُعد Connector منصة استضافة منفصلة ولا يحل محل hPanel. بل يوفر طريقة أخرى للتفاعل مع موارد Hostinger.
Hostinger يعرض حاليًا:
• VS Code
• Cursor
• Devin
• Antigravity
• Claude
• Codex
تذكر Hostinger أيضًا أن بعض عملاء MCP الآخرين المتوافقين قد تكون مدعومة. قد يختلف الإعداد وسلوك الأدوات بين العملاء.
مُوصّل Hostinger مجاني للتثبيت ومضمن مع باقات 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.
ليس بالضرورة. في اختباري المُتحكَّم به، أفاد Hostinger بأن عملية البناء اكتملت بعد أن غيّرت سكربت البدء ليرجع إلى ملف JavaScript مفقود. أظهرت سجلات البناء المسترجعة نجاح تثبيت الاعتمادات، لكنها لم تكشف فشل بدء التشغيل أثناء وقت التشغيل. تحقّق دائمًا من الموقع الحي أو استدعِ نقطة فحص الصحة بعد النشر.
ليس تمامًا. يمكن لـ Connector أن يقلل عدد المرات التي يحتاج فيها المطورون إلى مغادرة محررهم، خاصةً لعمليات النشر الروتينية وفحوصات الحسابات. يظل hPanel مفيدًا لإدارة الحسابات بصريًا، والإعداد الأولي، والتكوين التفصيلي، والحالات التي لا يستطيع فيها الذكاء الاصطناعي اكتشاف المورد المطلوب أو عرضه بشكل صحيح.
أجب على بعض الأسئلة البسيطة وابحث عن الحل المثالي لك!
بدء البحث في الاستضافة
يقدم HostAdvice.com مراجعات وتقييمات احترافية بخدمات استضافة مواقع الانترنت مستقلة تماما عن أي جهة أو كيان آخر. تقييماتنا عادلة وأمينة وتطبق نفس معايير التقييم على كل المراجعات التي تتم.
يتم استلام تعويض نقدي من الشركات التي نقوم بتقييمها. تعويض الخدمات والمنتجات ليس له تأثير على توجه أو استنتاجات تقييماتنا. ولا تؤثر هذه التعويضات على ترتيبنا لشركات استضافة المواقع المحددة.
تغطي هذه التعويضات تكاليف الإنفاق على المراجعين، شراء الحسابات، والاختبار.
