FAQ

الأسئلة المتداولة

أدلة قصيرة عملية لإعداد الخدمة والوصول إليها وإجراءات العملاء الشائعة.

> إنشاء مفتاح SSH عام من الطرفية

أنشئ مفتاح SSH عاما للوصول وشارك الجزء العام فقط.
faq/generate-public-ssh-key-ar

استخدم المفتاح العام فقط

يعتمد SSH على زوج مفاتيح. الصق في إعدادات الخدمة المفتاح العام فقط، وغالبا يكون ملف .pub. يبقى المفتاح الخاص على جهازك.

خطوات الطرفية

  1. افتح Terminal أو Windows Terminal أو PowerShell.
  2. نفذ: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. اقبل المسار الافتراضي أو اختر مسارا آمنا.
  4. اعرض المفتاح العام باستخدام: cat ~/.ssh/id_ed25519.pub.
  5. في Windows PowerShell استخدم: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. انسخ سطر ssh-ed25519 كاملا إلى حقل SSH public key.

راجع قبل اللصق

لا تنسخ المفتاح الخاص. إذا ضبطت passphrase فاحتفظ بها بأمان لاستخدامها لاحقا.

> إنشاء مفتاح SSH في Windows عبر الواجهة الرسومية

استخدم PuTTYgen في Windows وانسخ المفتاح العام فقط.
faq/create-ssh-key-windows-gui-ar

يكفي الجزء العام

ينشئ PuTTYgen مفتاحا عاما وآخر خاصا. أضف إلى Cli>_ المفتاح العام فقط واحتفظ بالمفتاح الخاص محليا.

خطوات Windows

  1. افتح PuTTYgen.
  2. اختر EdDSA / Ed25519 إن كان متاحا.
  3. استخدم RSA 4096 كخيار احتياطي فقط.
  4. اضغط Generate وحرك الفأرة حتى يتم إنشاء المفتاح.
  5. احفظ المفتاح الخاص على حاسوبك.
  6. انسخ نص المفتاح العام إلى حقل SSH public key.

لا تشارك بيانات سرية

لا ترسل ملفات .ppk أو المفاتيح الخاصة أو passphrase أو كلمات المرور أو token إلى الدعم أو النماذج.

> ربط نطاقك الخاص

تأكد من المسجل أو خوادم الأسماء، والاسم الدقيق، ونوع apex أو subdomain، ودعم CNAME أو A/AAAA أو ALIAS أو ANAME دون تعارضات.
faq/rabt-nitaqak-alkhas

الدومين يجب أن يشير إلى هدف الخدمة

قبل الاختبار النهائي يجب أن يشير الدومين إلى الهدف المعروض في الخدمة. تختلف الطريقة حسب كون الاسم apex مثل example.com أو subdomain مثل app.example.com وحسب دعم مزود DNS.

تحقق DNS

  1. اختر hostname الدقيق الذي ستستخدمه.
  2. تأكد أن المسجل أو authoritative nameservers هي المكان الصحيح للتعديل.
  3. احذف السجلات المتعارضة لنفس الاسم.
  4. استخدم CNAME أو A/AAAA أو ALIAS أو ANAME فقط عندما يدعمها المزود ونوع الاسم.

اختبر الاسم الكامل

اختبر hostname الكامل الذي سيستخدمه الزوار، وليس الدومين العام فقط. اختلاف apex عن subdomain يغير نوع السجل وطريقة التحقق.

> نقل إدارة منطقة DNS

تستخدم الخدمات عادة A/AAAA وCNAME وMX وTXT وCAA، بينما تستخدم البريد SPF وDKIM selector وDMARC على _dmarc.
faq/naql-idarat-mintaqat-dns

كل نوع سجل له وظيفة

A وAAAA يوجهان إلى عناوين، CNAME يوجه اسما فرعيا إلى hostname آخر، MX للبريد، TXT للتحقق وSPF وDKIM وDMARC، وCAA يحدد جهات إصدار الشهادات.

تجنب تعارض السجلات

  1. انسخ النوع والهدف من صفحة الخدمة بدقة.
  2. لا تضع CNAME مع سجلات أخرى على نفس hostname.
  3. ضع DKIM تحت selector الذي يحدده المزود وDMARC تحت _dmarc.
  4. عدّل CAA بحذر لأن قيمة خاطئة قد تمنع إصدار الشهادة.

غيّر سجلا واحدا بوضوح

عند التصحيح، وثق القيمة القديمة والجديدة ووقت التغيير. هذا يسهل فهم نتائج DNS المختلطة أثناء انتهاء الكاش.

> تسجيل الحساب وتسجيل الدخول

أنشئ حساب عميل واحدا لإدارة الطلبات والفوترة والخدمات باستخدام بريد إلكتروني يبقى متاحا لفريقك.
faq/account-registration-and-login

حساب واحد لكل إدارة الخدمة

يستخدم حساب العميل للطلبات وبيانات الفوترة وإدارة الخدمات والدومينات. اختر بريدا يمكن للفريق الوصول إليه على المدى الطويل.

قبل أول طلب مدفوع

  1. سجل باستخدام بريد عمل موثوق.
  2. أكمل تأكيد البريد إذا ظهر طلب التأكيد.
  3. أدخل بيانات الفوترة قبل الدفع.
  4. فعّل التحقق الثنائي عندما يكون متاحا.

حافظ على ملكية الحساب

استخدم بريدا يملكه العمل وليس موظفا واحدا فقط، وراجع الوصول عند تغيير أعضاء الفريق حتى لا تضيع الطلبات أو الفواتير أو إشعارات الخدمة.

> الرصيد المدفوع مسبقا وتكلفة الخدمة اليومية

يعرض الرصيد المدفوع مسبقا المبلغ المتاح، مدة التشغيل المقدرة، التكلفة اليومية، وموعد الإيقاف أو الحذف الظاهر.
faq/prepaid-credit-how-it-works

الرصيد ينقص مع وقت تشغيل الخدمة

الخدمات المؤهلة تستهلك الرصيد أثناء التشغيل. يساعدك الرصيد الظاهر، تقدير مدة التشغيل، تكلفة كل خدمة يوميا، وتنبيه موعد الحذف الظاهر عند التعليق على إعادة الشحن قبل فقدان الخدمة.

متى تعيد الشحن

  1. أضف الرصيد من منطقة العميل.
  2. راجع السعر المعروض والتكلفة اليومية قبل تأكيد طلب أو تغيير.
  3. راقب تحذيرات انخفاض الرصيد ومدة التشغيل المتبقية وموعد الحذف الظاهر.
  4. أعد الشحن قبل نفاد الرصيد لتجنب التعليق ثم الحذف.

لا تنتظر آخر يوم

إذا أظهر الحساب مدة تشغيل قصيرة، اشحن الرصيد قبل الموعد. التعليق يحمي الإنفاق لكنه قد يوقف الخدمة، وبعد فترة الاحتفاظ قد يبدأ حذف البيانات.

> فترات الفوترة واستهلاك الرصيد

التقدير الشهري يستخدم 31 يوما والسنوي 372 يوما، بينما يستهلك الرصيد يوميا بعد تأكيد التغيير ودفعه عند الحاجة وتطبيقه.
faq/billing-periods-and-credit-burn

الأرقام الشهرية والسنوية للمقارنة

تستخدم التقديرات الشهرية 31 يوما والسنوية 372 يوما. الاستهلاك الفعلي للرصيد يعتمد على وقت التشغيل والـ CPU والـ RAM والتخزين والخيارات المدفوعة.

قراءة السعر قبل الموافقة

  1. قارن التقدير الشهري أو السنوي مع الاستهلاك اليومي.
  2. تحقق إن كان تغيير الموارد يزيد أو يخفض التكلفة اليومية.
  3. أكد وادفع عند الحاجة ثم انتظر تطبيق التغيير.
  4. احتفظ بالفواتير وتأكيدات الطلب وسجل الرصيد للمحاسبة.

متى يتغير الاستهلاك

لا يعتمد السعر الجديد على اختيار غير مؤكد فقط. يتغير الاستهلاك عندما يصبح الطلب أو التغيير مؤكدا ومدفوعا عند الحاجة ومطبقا على الخدمة.

> حالة الطلب وتأكيد الدفع

قد ينتظر الطلب تأكيد مزود الدفع قبل بدء تفعيل الخدمة، لذلك لا تنشئ طلبا مكررا بسرعة.
faq/order-status-and-payment-confirmation

الطلب المعلق ليس فشلا دائما

بعد الدفع قد يحتاج الطلب إلى وقت حتى يصل تأكيد مزود الدفع. انتظر قبل إنشاء طلب جديد إلا إذا كان الطلب الأول منتهيا أو ملغى بوضوح.

متابعة الدفع

  1. ارجع من صفحة مزود الدفع إلى Cli>_ بعد اكتمال الدفع.
  2. راجع حالة الطلب في حسابك.
  3. إذا بقي الطلب معلقا فانتظر تأكيد المزود.
  4. عند التواصل مع الدعم أرسل رقم الطلب ومرجع مزود الدفع إن وجد.

تجنب الطلبات المكررة

إذا أغلقت صفحة الدفع أو عاد المتصفح متأخرا، تحقق من الطلب الحالي أولا. إنشاء طلب جديد بسرعة قد يربك المتابعة والفوترة.

> المعلومات المطلوبة لإعداد الخدمة

جهز اسم الخدمة والدومين وخطة DNS والتخزين والموارد وبريد المدير ومفتاح SSH العام، ولا ترسل أسرارا.
faq/service-setup-information-needed

القيم العامة تسرع التفعيل

تحتاج معظم الخدمات إلى اختيارات من العميل مثل اسم الخدمة، الدومين، جاهزية DNS، حجم التخزين، CPU أو RAM، بريد الوصول أو الإدارة، ومفتاح SSH العام. لا تدخل كلمات مرور أو مفاتيح خاصة أو رموز وصول في حقول الإعداد.

قائمة التحضير

  1. اقرأ نموذج المنتج قبل الدفع.
  2. جهز الدومين ومهام DNS ومفتاح SSH العام مسبقا.
  3. استخدم أسماء خدمات واضحة يعرفها فريقك.
  4. اترك الأسرار خارج حقول القيم العامة.

المفتاح العام فقط

عند طلب SSH أرسل المفتاح العام فقط، مثل القيمة التي تبدأ غالبا بـ ssh-ed25519 أو ssh-rsa. المفتاح الخاص يبقى على جهازك ولا يلزم للتفعيل.

> تغيير موارد الخدمة بعد الطلب

غيّر CPU أو RAM أو التخزين أو الاحتفاظ فقط بعد مراجعة السعر الجديد والاستهلاك اليومي واحتمال إعادة التشغيل أو التوقف.
faq/change-service-resources-after-order

عدّل الخدمة الحالية لا تنشئ نسخة مكررة

تغييرات الموارد تتم من الخدمة الحالية. السعر الجديد والاستهلاك اليومي لا يصبحان فعليين إلا بعد التأكيد والدفع عند الحاجة والتطبيق. بعض التغييرات تتطلب إعادة تشغيل أو نافذة صيانة.

خطوات تغيير آمن

  1. افتح الخدمة الحالية وراجع CPU وRAM والتخزين والاحتفاظ بالنسخ.
  2. اختر التغيير وافحص السعر الجديد والاستهلاك اليومي.
  3. أكد وادفع عند الحاجة ثم انتظر التطبيق.
  4. صدّر البيانات المهمة قبل أي تغيير قد يسبب توقفا.

خطط لتوقيت التغيير

نفذ التغييرات التي قد تعيد التشغيل في وقت مناسب للمستخدمين. إذا كان التطبيق حساسا للتوقف، حضر تصديرا أو خطة رجوع قبل التأكيد.

> إلغاء الخدمة والاحتفاظ بالبيانات

إلغاء خدمة مفعلة يعلقها أولا ويعرض موعد حذف قابل للضبط، ثم يحدث الحذف النهائي بعد انتهاء دورة الحياة.
faq/cancel-service-and-data-retention

الإلغاء ليس تصديرا تلقائيا

عند إلغاء خدمة مفعلة يتم تعليقها أولا ويظهر موعد حذف قابل للضبط. بعد انتهاء الفترة يحدث تنظيف دائم. الطلبات المعلقة غير المدفوعة وغير المفعلة قد لا تمر بنفس دورة بيانات التشغيل. النسخ الاحتياطية وOffsite Archive لهما احتفاظ منفصل.

قبل الحذف النهائي

  1. أنشئ تصديرا خاصا قبل الإلغاء أو نفاد الرصيد الطويل.
  2. اقرأ إشعار التعليق وموعد الحذف الظاهر.
  3. تذكر أن احتفاظ النسخ وOffsite Archive منفصل عن حذف الخدمة.
  4. تواصل مع الدعم قبل الموعد إذا كنت غير متأكد.

راجع التاريخ الظاهر

تعامل مع موعد الحذف المعروض كتاريخ عملي نهائي. إذا احتجت البيانات، صدّرها أو تواصل مع الدعم قبل ذلك الموعد وليس بعده.

> النسخ الاحتياطية وطلبات الاستعادة

يعتمد احتفاظ النسخ على خيارات المنتج، والاستعادة قد تستبدل بيانات أحدث، لذلك أرسل سياقا واضحا بلا أسرار.
faq/backups-and-restore-requests

النسخ للتعافي التشغيلي

النسخ الاحتياطية تساعد على التعافي التشغيلي وليست بديلا عن تصديراتك الخاصة أو الأرشفة الطويلة. قد تؤدي الاستعادة إلى استبدال بيانات أحدث.

طلب استعادة مفيد

  1. تحقق من خيار احتفاظ النسخ في المنتج أو الخدمة.
  2. احتفظ بتصديرات منفصلة للبيانات الحرجة.
  3. أرسل اسم الخدمة ورقم الطلب ووقت الاستعادة التقريبي والخطأ الظاهر أو السياق.
  4. لا ترسل كلمات مرور أو مفاتيح خاصة أو رموز وصول.

حدد نقطة الاستعادة

أفضل طلب استعادة يذكر الوقت التقريبي قبل حدوث المشكلة وما الذي يجب التحقق منه بعدها. هذا يقلل خطر استعادة نقطة غير مناسبة.

> الغرض من Offsite Archive

يحفظ Offsite Archive نسخا أرشيفية بعيدة في مركز بيانات آخر، وهو منفصل عن النسخ القصيرة وعن حذف الخدمة.
faq/offsite-archive-purpose

أرشيف بعيد وليس تخزينا حيا

Offsite Archive مخصص لنسخ أرشيفية بعيدة وليس لتخزين التطبيق المباشر. وهو منفصل عن النسخ التشغيلية القصيرة وعن توقيت حذف الخدمة.

تقدير الاحتفاظ والتكلفة

  1. اختر عدد أيام الاحتفاظ حسب متطلبات الاستعادة أو الامتثال.
  2. قدّر MB-days كحجم MB المخزن مضروبا في أيام التخزين.
  3. راجع السعر عندما يكبر حجم البيانات أو تزيد مدة الاحتفاظ.
  4. لا تعتبر Offsite Archive بديلا عن نسخ التشغيل اليومية أو موعد حذف الخدمة.

استخدمه كطبقة إضافية

Offsite Archive مناسب كطبقة احتفاظ بعيدة لحوادث كبيرة أو متطلبات امتثال، وليس بديلا عن النسخ التشغيلية أو مراقبة صحة التطبيق.

> اختيار CPU وRAM وحجم القرص للـ VPS

اختر حجم VPS حسب عبء العمل وقاعدة البيانات والكاش والسجلات والنمو المتوقع، وراقب OOM أو out of memory.
faq/vps-cpu-ram-and-disk-sizing

الحجم يتبع أعراض التطبيق

قواعد البيانات والحاويات والبحث وتطبيقات Java تحتاج غالبا RAM وقرصا أكبر من موقع ثابت صغير. رسائل OOM أو out of memory أو process killed تعني أن الذاكرة قد تكون قليلة.

متى توسع الموارد

  1. ابدأ بأصغر حجم يفي بمتطلبات التطبيق.
  2. زد RAM عند OOM أو swap كثيف أو process killed.
  3. زد CPU عند حمل حسابي مستمر أو عمليات بناء كثيرة.
  4. وسع القرص قبل امتلاء نظام الملفات.

راقب قبل التوسعة

إذا لم يكن سبب البطء واضحا، اجمع رسائل الخطأ واستخدام الموارد أولا. زيادة مورد واحد لا تصلح دائما مشكلة في التطبيق أو قاعدة البيانات.

> خيارات IP عام للـ VPS

استخدم IP عاما مخصصا عندما يحتاج مزود خارجي أو جدار ناري إلى allowlist ثابت أو وصول مباشر أو مصدر outbound ثابت.
faq/vps-public-ip-options

متى يفيد IP المخصص

الـ IP العام المخصص مفيد عندما يطلب شريك أو مزود خارجي عنوانا ثابتا للـ inbound أو outbound أو كليهما. استخدم أسماء DNS حيث يمكن وافتح فقط المنافذ المطلوبة.

أسئلة قبل طلب IP

  1. اسأل الطرف الخارجي هل يحتاج inbound أم outbound source أم الاثنين.
  2. حدد المنافذ اللازمة فقط في الجدار الناري.
  3. استخدم DNS names بدلا من أرقام IP عندما يكون ذلك مقبولا.
  4. شارك متطلبات allowlist مع الدعم قبل تغيير تصميم الوصول.

DNS وSSH المباشر أو المشترك

مع IP عام مخصص يمكن استخدام DNS يشير إلى ذلك العنوان، وقد يتوفر SSH مباشر على عنوان الخدمة إذا كان المنفذ مسموحا. بدون IP مخصص يستخدم SSH المشترك مضيفا عاما ومنفذا عاليا مخصصا لكل خدمة، مثل ssh -p @.

> وصول SSH مشترك للـ VPS

في SSH المشترك استخدم اسم المستخدم والمضيف والمنفذ العالي المعروض للخدمة بالأمر ssh -p <port> <username>@<public-host>.
faq/shared-ssh-access-for-vps

المنفذ العالي جزء من بيانات الدخول

يعرض حساب العميل SSH username ومضيفا عاما عادة بصيغة DNS تحت vps.cliopen.cloud ومنفذا مخصصا. في SSH المشترك لا تفترض أن المنفذ 22 مفتوح؛ استخدم المنفذ العالي المعروض بالضبط. إذا كان للخدمة IP عام مخصص، فقد يتوفر مسار SSH مباشر إضافي عبر ذلك الـ IP أو اسم DNS المرتبط به.

صيغة الاتصال

  1. انسخ SSH username وpublic host وport من صفحة الخدمة.
  2. اتصل بالأمر ssh -p <port> <username>@<public-host>.
  3. استخدم مفتاحك الخاص محليا ولا تلصقه في التذاكر أو الدردشة.
  4. عند الفشل أرسل اسم الخدمة والمضيف والمنفذ واسم المستخدم والخطأ الظاهر.

احتفظ بالمفتاح الخاص محليا

يجب أن يبقى المفتاح الخاص على جهازك فقط. لا ترسله في التذاكر أو الدردشة، وشارك مع الدعم بيانات الاتصال الظاهرة والخطأ فقط.

> قائمة جاهزية الدومين المخصص

تأكد من المسجل أو خوادم الأسماء، والاسم الدقيق، ونوع apex أو subdomain، ودعم CNAME أو A/AAAA أو ALIAS أو ANAME دون تعارضات.
faq/custom-domain-readiness-checklist

الدومين يجب أن يشير إلى هدف الخدمة

قبل الاختبار النهائي يجب أن يشير الدومين إلى الهدف المعروض في الخدمة. تختلف الطريقة حسب كون الاسم apex مثل example.com أو subdomain مثل app.example.com وحسب دعم مزود DNS.

تحقق DNS

  1. اختر hostname الدقيق الذي ستستخدمه.
  2. تأكد أن المسجل أو authoritative nameservers هي المكان الصحيح للتعديل.
  3. احذف السجلات المتعارضة لنفس الاسم.
  4. استخدم CNAME أو A/AAAA أو ALIAS أو ANAME فقط عندما يدعمها المزود ونوع الاسم.

اختبر الاسم الكامل

اختبر hostname الكامل الذي سيستخدمه الزوار، وليس الدومين العام فقط. اختلاف apex عن subdomain يغير نوع السجل وطريقة التحقق.

> أنواع سجلات DNS للخدمات

تستخدم الخدمات عادة A/AAAA وCNAME وMX وTXT وCAA، بينما تستخدم البريد SPF وDKIM selector وDMARC على _dmarc.
faq/dns-record-types-for-services

كل نوع سجل له وظيفة

A وAAAA يوجهان إلى عناوين، CNAME يوجه اسما فرعيا إلى hostname آخر، MX للبريد، TXT للتحقق وSPF وDKIM وDMARC، وCAA يحدد جهات إصدار الشهادات.

تجنب تعارض السجلات

  1. انسخ النوع والهدف من صفحة الخدمة بدقة.
  2. لا تضع CNAME مع سجلات أخرى على نفس hostname.
  3. ضع DKIM تحت selector الذي يحدده المزود وDMARC تحت _dmarc.
  4. عدّل CAA بحذر لأن قيمة خاطئة قد تمنع إصدار الشهادة.

غيّر سجلا واحدا بوضوح

عند التصحيح، وثق القيمة القديمة والجديدة ووقت التغيير. هذا يسهل فهم نتائج DNS المختلطة أثناء انتهاء الكاش.

> انتشار DNS وTTL

لا يوجد وعد ثابت لوقت انتشار DNS، لأن TTL والكاش يسمحان بوجود إجابات قديمة وجديدة في الوقت نفسه.
faq/dns-propagation-and-ttl

الكاش يفسر اختلاف النتائج

بعد تغيير السجل قد يرى بعض المستخدمين الإجابة الجديدة بينما يرى آخرون القديمة حتى تنتهي صلاحية الكاش. لذلك لا يوجد وقت انتشار مضمون بدقة.

تغيير DNS بهدوء

  1. اخفض TTL قبل التغيير المخطط إن أمكن.
  2. نفذ التغيير مرة واحدة ولا تعدل باستمرار أثناء الانتظار.
  3. اختبر من أكثر من resolver أو شبكة عند اختلاف النتائج.
  4. أرسل للدعم hostname والنتيجة القديمة والمتوقعة وTTL ووقت التغيير.

لا تطارد الكاش

تكرار التعديل أثناء الانتظار قد يطيل التشخيص. انتظر مدة TTL المتوقعة ثم اختبر من resolver موثوق أو شبكة مختلفة.

> تخطيط تخزين Nextcloud

خطط لتخزين ملفات المستخدمين والمجلدات المشتركة والمهملات والإصدارات وpreviews وthumbnails والنمو المتوقع.
faq/nextcloud-storage-planning

الاستخدام أكبر من حجم الملفات الخام

Nextcloud يحتاج مساحة للملفات والمجلدات المشتركة والملفات المحذوفة وتاريخ الإصدارات وpreviews وthumbnails ونشاط المزامنة. العمل قرب الحد قد يعطل الرفع والمزامنة.

هامش نمو التخزين

  1. قدّر حجم الملفات الحالية قبل الطلب.
  2. أضف هامشا للمهملات والإصدارات وpreviews وthumbnails.
  3. راجع الاستخدام مع الفريق قبل الاستيراد الكبير.
  4. زد التخزين قبل وصول المستخدمين إلى الحد.

اترك مساحة عمل

المزامنة والمعاينات وتاريخ الإصدارات تحتاج مساحة مؤقتة ودائمة. لا تخطط لاستخدام 100% من التخزين المخصص.

> ترحيل المستودعات إلى Gitea

خطط لترحيل Gitea حول Git LFS وsubmodules والفروع والوسوم المحمية وdeploy keys وtokens وwebhooks وCI/CD.
faq/gitea-repository-migration

الترحيل أكثر من نسخ history

قبل النقل احصر المالكين والفرق وGit LFS وsubmodules والفروع والوسوم المحمية وremote URLs وwebhooks وCI/CD وdeploy keys وtokens القديمة. لا تكشف قيم tokens؛ دوّرها أو أنشئها من جديد بعد النقل.

اختبارات بعد النقل

  1. صدّر أو mirror المستودعات من المزود القديم.
  2. تحقق من الفروع والوسوم وملفات Git LFS.
  3. حدّث remote URLs وwebhooks وCI/CD وdeploy keys.
  4. اختبر clone وpush وGit LFS وsubmodules وCI قبل إلغاء الوصول القديم.

اختبر قبل إغلاق المصدر

بعد النقل، اختبر clone وpush وCI وحسابات الفريق قبل إلغاء الوصول إلى المزود القديم أو حذف النسخ الأصلية.

> أساسيات دومين الإرسال في Listmonk

يحتاج Listmonk إلى sender domain أو subdomain وهوية From وسجلات SPF وDKIM وDMARC واختبار قبل الحملة.
faq/listmonk-sender-domain-basics

الهوية والسجلات تحسن التسليم

تعمل النشرات بشكل أفضل عندما تكون هوية From واضحة وسجلات DNS صحيحة. ينشر SPF في موقع مزود البريد، وDKIM باستخدام selector، وDMARC على _dmarc.

قبل أول حملة

  1. اختر دومين أو subdomain مخصصا للإرسال.
  2. أضف سجلات التحقق وSPF وDKIM وDMARC المطلوبة.
  3. اختبر الرسائل وbounce وReturn-Path والروابط قبل الإرسال الحقيقي.
  4. حافظ على unsubscribe وList-Unsubscribe وهوية المرسل دون مشاركة أسرار.

ابدأ بإرسال تجريبي

أرسل حملة صغيرة أو رسالة اختبار قبل القائمة الكاملة. راقب الارتداد والروابط ونتائج المصادقة قبل زيادة الحجم.

> إعدادات Runtime في Classic Hosting

يدعم Classic Hosting الوضع التلقائي واليدوي مع PHP وNode.js وJava وPython و. NET وGo وRuby وNginx وApache وFrankenPHP.
faq/classic-hosting-runtime-settings

الوضع التلقائي أو اليدوي

يمكن للوضع التلقائي اكتشاف وبناء تطبيقات PHP وNode.js وJava وPython و. NET وGo وRuby. الوضع اليدوي مناسب للتحكم في Nginx أو Apache أو FrankenPHP. PHP selector ينطبق فقط حيث يدعمه Runtime المختار.

موارد التشغيل

  1. اختر auto أو manual حسب التطبيق والإطار.
  2. حدد PHP 8.2 أو 8.3 أو 8.4 فقط عند دعمها.
  3. اضبط CPU وRAM والتخزين وbackup retention وOffsite Archive retention.
  4. اختبر الرفع والكاش والسجلات والأخطاء الظاهرة بعد النشر.

طابق runtime مع التطبيق

اختر الوضع التلقائي عندما تريد اكتشاف البناء، واختر اليدوي عندما تعرف الخادم أو إصدار PHP المطلوب. راجع السجلات بعد أول نشر.

> معلومات آمنة لمشاركتها مع الدعم

شارك أرقام الطلبات وأسماء الخدمات والدومينات والأوقات والأخطاء الظاهرة وإعدادات الاستضافة، ولا ترسل أسرارا.
faq/support-safe-information-to-share

السياق المرئي يكفي غالبا

المعلومات الآمنة تشمل رقم الطلب، اسم الخدمة الظاهر، الدومين، public host أو port، Runtime، إصدار PHP، CPU، RAM، التخزين، backup retention، Offsite Archive retention، uploads، cache، logs، وقت المشكلة، screenshot بعد إخفاء الأسرار، ونص الخطأ الظاهر.

ما لا ترسله

  1. لا ترسل كلمات مرور أو مفاتيح خاصة أو tokens أو seed phrases.
  2. لا ترسل logs كاملة تحتوي أسرارا أو exports لقواعد البيانات.
  3. أخف البيانات الشخصية والجلسات قبل إرفاق screenshots.
  4. تجنب مشاركة ملفات إعداد غير محجوبة أو أسماء وعناوين بنية خاصة.

احجب ما لا يلزم

قبل إرسال لقطة شاشة أو سجل، احجب الجلسات والرموز والبريد الشخصي. شارك فقط ما يساعد على تحديد الخدمة والخطأ.