أعتقد أن هذا يتسبب في تعطيل نسخة من منصة Discourse. لا يمكنها تجاوز رسالة “عذرًا…” التي تشير إلى وجود حمل زائد.
Create new order error. Le_OrderFinalize not found. {
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ....
أرى أن أشخاصًا آخرين واجهوا هذه المشكلة لسبب ما، ولكن هل هناك حل لها؟
أعتقد أنك ستحتاج فقط إلى الانتظار بضع ساعات ثم المحاولة مرة أخرى. إن لم أكن مخطئًا، فإن حد المعدل يُعاد ضبطه كل ساعة. يمكنك أيضًا طلب إضافة بادئة www إلى النطاق للحصول على شهادة جديدة وإعادة ضبط العداد.
شكرًا لك على التلميح. سأحاول إعادة البناء الآن، فقد مرّت ساعات قليلة.
تبيّن أن الانتظار يستغرق 7 أيام وفقًا لـ @Ed_S هنا!
لم تنجح عملية إعادة البناء.
أعدت تشغيل معالج الإعداد لإضافة www للحصول على شهادة جديدة. بدا أن الأمر نجح، لكنني اضطررت لاتباع اقتراح @pfaffman لتعطيل فحص الاتصال لتجاوز خطأ عدم إمكانية الوصول إلى المنفذ 443.
الآن، يفشل النظام في تحميل الشهادة، وذلك وفقًا للسجلات:
...PEM_read_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expecting: TRUSTED CERTIFICATE)
قد يكون هذا مرتبطًا بمشكلة إغلاق المنفذين 443/80، وهو مشكلة أخرى أراها شائعة.
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 72556/docker-proxy
tcp6 0 0 :::443 :::* LISTEN 72564/docker-proxy
عند فحص المنافذ عبر أداة فحص خارجية، تظهر مغلقة 
حسنًا، لقد أعدت إلى خادم آخر يحتوي على نسخة مُستعادة من قاعدة البيانات، حيث كانت المنفذا 80/443 مفتوحة. قمت بالتحقق من ذلك باستخدام ماسح منافذ خارجي قبل المتابعة.
عندما شغّلت الأمر ./launcher discourse-setup، ظهرت لي رسالة خطأ تفيد بأن منفذ 443 غير قابل للوصول.
لذلك قمت بمسح الخادم مرة أخرى للتحقق من المنفذين 80 و443، والآن تظهر كمنفذين مغلقتين.
يبدو وكأن مجرد تشغيل المعالج يغلق المنافذ!
لا أعتقد أن المعالج يدعم أسماء نطاقات متعددة، لكنني لم أستخدمه منذ فترة طويلة.
هذا على الأرجح هو مشكلتك. على الأرجح لم تقم بإعداد DNS أو أن هناك شيئًا يحجب حركة المرور الواردة.
مرحبًا، شكرًا لك. نعم، تمكنت من حل خطأ PEM_red… المذكور أعلاه عن طريق التراجع عن “السحب الرمادية” (grey clouds)، وقد وجدت هذه النصيحة في موضوع آخر.
عند تشغيل المعالج (wizard)، قمت بإدخال نطاق www. فقط، ربما كان هذا خطأً؟ كان الغرض من ذلك هو تجاوز حد المعدل (rate limit).
على أي حال، بعد تجاوز خطأ PEM، واجهت هذا الخطأ:
fail: nginx: runsv not running
[Wed Sep .... UTC 2026] Reload error for :
C=US, O=Let's Encrypt, CN=YR1
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
C=US, O=Let's Encrypt, CN=YE2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
ومع ذلك، يبدو الأمر خفيفًا نوعًا ما، حيث تظهر في السجل سلسلة من مخرجات نجاح الشهادات لم تكن تحدث من قبل حتى قمت بتفعيل “السحب الرمادية”.
كذلك، يظهر أن المنفذين 80 و443 مفتوحان.
أرى أيضًا هذه الرسالة مطبوعة عدة مرات في نهاية السجلات:
X-Accel-Mapping header missing
دعني أضيف مزيدًا من السياق: الخادم (instance) يحل النطاق ويسمح بتسجيل الدخول، فتظهر شاشة تسجيل الدخول (المضبوطة على تسجيل الدخول فقط) وتقبل بيانات الاعتماد والتحقق الثنائي، وبعد نجاح ذلك، يعود الأمر إلى شاشة “عذرًا…” (Oops…) من جديد.
وهذا يعني أنني عدت إلى النقطة التي بدأت منها.
لم يتم تغيير أي شيء في الخادم الأصلي في البداية. فجأة، كانت هناك أيام قليلة من السلوك غير الفعال، وأثناء ذلك كانت المقاييس (metrics) تُظهر حملًا دوريًا غريبًا على الخادم يتجاوز المستويات الطبيعية. كان الأمر يبدو وكأنه يعمل بكامل طاقته دون أن يذهب إلى أي مكان، حتى انهار أخيرًا في حالة دائمة من “عذرًا” (Oops).
لذا بدأت في العمل على إصلاحه. كان أحد الحلول هو أخذ نسخة احتياطية واستعادتها إلى نسخة Discourse جديدة، وهذا هو الوضع الحالي لدي، أي أنني أستطيع تسجيل الدخول لكنني عائد إلى شاشة “عذرًا”.
ملاحظة تاريخية أيضًا: واجهت مشاكل مع خيار “كامل” (Full) أو “كامل (صارم)” (Full strict) في الماضي، فلم يعمل خيار “كامل (صارم)” دائمًا وكان لا بد من التراجع إلى “كامل”. قد يكون هذا الأمر ثانويًا.
يا إلهي 
حسنًا، أستطيع تأكيد النجاح. استخدمت مستخدمًا أقدم غير مسؤول، وتمكنت من تسجيل الدخول.
كنت أدور في حلقات مغلقة بينما كان هذا هو المشكلة طوال الوقت!