يفشل تسجيل الدخول إلى Immich بعد إعادة تشغيل الخادم الوكيل العكسي
إذا فشل تسجيل الدخول إلى Immich فقط بعد إعادة تشغيل الوكيل العكسي، فتحقق أولًا مما إذا كان مسار الوكيل قد تعطل بينما لا يزال تطبيق Immich والحساب يعملان مباشرةً.
قد تكشف إعادة التشغيل عن عناوين خلفية قديمة، أو فقدان العضوية في الشبكة المشتركة، أو تغيّر الرؤوس، أو سلوك ملفات تعريف الارتباط، أو عودة عملية الوكيل قبل أن تصبح تبعياتها متاحة. اختبر الحساب نفسه عبر نقطة نهاية Immich المحلية واسم المضيف العام المعتاد، ثم تتبّع أول طبقة يختلف عندها المساران.
استخدم الوصول المباشر للفصل بين فشل المصادقة وفشل الوكيل
اختبر حسابًا معروفًا على خادم Immich عبر مسار محلي موثوق يتجاوز الوكيل العكسي. إذا نجح تسجيل الدخول المباشر بينما ظل اسم المضيف العام في حالة تحميل، أو أعاد التوجيه، أو أرجع خطأً من الخادم الخلفي، فمن المرجح أن سجل المستخدم ومسار المصادقة الأساسي سليمين. ركّز التحقيق على الوكيل وTLS والتوجيه وحالة المتصفح.
توضح حالة مجتمعية نجح فيها الوصول المباشر بينما فشل تسجيل الدخول عبر الوكيل أسلوب العزل هذا. الحالة مرتبطة بإصدار محدد، لذا استخدمها لتبرير مقارنة المسارين، لا لافتراض السبب الجذري نفسه.
إذا فشل تسجيل الدخول المباشر وعبر الوكيل معًا، فتوقف عن تغيير إعدادات الوكيل. افحص صحة خدمة Immich واتصال قاعدة البيانات وحالة الحساب وسجلات الخادم بدلًا من ذلك. قد تكون إعادة تشغيل الوكيل التي حدثت قرب وقت الفشل مجرد مصادفة؛ إذ يمنع اختبار التجاوز تحويل هذا التزامن إلى تشخيص غير مدعوم.
تحقق من قدرة الوكيل على الوصول إلى الخادم الخلفي الحالي لـ Immich
بعد إعادة تشغيل الوكيل، تأكد من قدرته على حل اسم الخادم الخلفي لـ Immich والاتصال به من مساحة أسماء الشبكة الخاصة به. في Docker، يكون استخدام اسم الخدمة كخادم خلفي على شبكة مشتركة يعرّفها المستخدم أكثر استقرارًا عمومًا من نسخ عنوان IP للحاوية يدويًا، إذ يتغير العنوان عند إعادة إنشاء الحاوية.
توضح مناقشة حول انقطاع وكيل عكسي تتضمن الاتصال بين الوكيل وImmich سبب ضرورة فحص إمكانية الوصول إلى الخادم الخلفي ودعم الوكيل لـWebSocket قبل استعادة الحساب. تعامل مع الإعداد المحدد كدليل استرشادي، لا كقالب لكل وكيل.
أعد تشغيل الوكيل وحده مرتين وراقب ما إذا كان الخادم الخلفي يُحل إلى الخدمة نفسها في كل مرة. يُعد الاتصال الفوري الناجح من دون تعديل العناوين نتيجة ناجحة. إذا تغيّر حل الاسم أو عضوية الشبكة أو المنفذ المستهدف بعد إعادة الإنشاء، فأصلح تعريف شبكة Compose بدلًا من إعادة تشغيل المكدس مرارًا.
افحص الرؤوس المُمرَّرة وTLS وسلوك ملفات تعريف الارتباط
قد يفشل تسجيل الدخول حتى عندما يعرض الوكيل صفحة Immich، لأن المصادقة تعتمد على مسار HTTP الكامل. قارن إعداد الوكيل قبل إعادة التشغيل وبعدها، بما في ذلك تمرير المضيف والمخطط، وإنهاء HTTPS، وعمليات إعادة التوجيه، وأي إعادة كتابة لملفات تعريف الارتباط، وما إذا كان وكيل ثانٍ أو نفق يعدّل الاستجابة أيضًا.
توثق إحدى مناقشات مجتمع Immich حالة تسجيل دخول بسبب ملف تعريف ارتباط مكرر، حيث تسبب تعامل الوكيل مع ملفات تعريف الارتباط في تعليق تسجيل الدخول. هذه حالة محددة، لكنها تذكير مفيد بفحص استجابة المتصفح وملفات تعريف الارتباط بدلًا من افتراض أن صحة بيانات الاعتماد تضمن نجاح الجلسة عبر الوكيل.
لا تحذف جميع الحسابات أو تعِد ضبط قاعدة البيانات لأن جلسة المتصفح تبدو عالقة. استخدم نافذة خاصة أو متصفحًا ثانيًا بعد تسجيل ملفات تعريف الارتباط والاستجابة الأصلية. إذا عمل عميل نظيف، فامسح حالة الموقع المتأثر فقط وأصلح قاعدة الوكيل التي أنشأت ملف تعريف الارتباط أو إعادة التوجيه غير الصحيحة.
اقرأ سجلات الوصول والأخطاء للوكيل عند الطابع الزمني للطلب الفاشل
أعد تنفيذ محاولة تسجيل دخول واحدة وسجّل الوقت الدقيق واسم المضيف العام والعميل والحالة المُعادة. ثم افحص سجلات الوصول والأخطاء للوكيل حول ذلك الطلب. ميّز بين طلب لم يصل إلى الوكيل مطلقًا، أو خطأ 4xx أو 5xx أنشأه الوكيل، أو فشل اتصال بالخادم الخلفي، أو طلب وصل إلى Immich لكنه تلقى استجابة من التطبيق.
يوضح مسار استكشاف أخطاء سجلات NGINX وإصلاحها كيف توفر الحالة وأخطاء الخادم الخلفي وتوقيت الطلب والتسجيل الموجّه إشارة أقوى بكثير من تحديث صفحة تسجيل الدخول مرارًا. طبّق المبدأ نفسه على Caddy أو Traefik أو أي وكيل آخر.
إذا أظهر سجل الوكيل استجابة ناجحة من الخادم الخلفي بينما يفشل المتصفح في إكمال تسجيل الدخول، فافحص عمليات إعادة التوجيه وملفات تعريف الارتباط وTLS وحالة العميل. إذا تعذر على الوكيل الاتصال بالخادم الخلفي، فأصلح التوجيه أو جاهزية الخدمة. وإذا أعاد Immich نفسه الخطأ، فاتبع سجل الخادم المقابل بدلًا من اعتبار الوكيل السبب.
أثبت أن الإصلاح يصمد أمام إعادة التشغيل التي تسببت في المشكلة أصلًا
بعد تصحيح السبب المؤكد، كرر المحفز نفسه تمامًا: أعد تشغيل الوكيل العكسي فقط، وانتظر فحص صحته، ثم سجّل الدخول عبر اسم المضيف العام. بعد ذلك افتح عنصرًا موجودًا، وحمّل ملفًا صغيرًا، وأبقِ الجلسة نشطة مدة كافية للتحقق من حركة API المعتادة.
يوفر دليل ZimaSpace حول مسارات الوصول البعيد المنضبطة الإطار الأوسع: الوكيل مجرد طبقة واحدة في الوصول عن بُعد، لذا يجب أن تظل DNS وTLS والمصادقة والخادم الخلفي الخاص مقصودة وقابلة للرصد.
لا تعتبر الإصلاح ناجحًا إلا عندما يصمد تسجيل الدخول أمام إعادة تشغيل الوكيل مرتين، ويبدأ الإعداد نفسه بنجاح بعد إعادة تشغيل المكدس بالكامل. تراجع عن تغييرات الوكيل الأخيرة إذا تسببت قاعدة جديدة للرؤوس أو ملفات تعريف الارتباط في الفشل. صعّد المشكلة مع الفروقات في إعداد الوكيل، وحالة الطلب، وخطأ الخادم الخلفي، والطابع الزمني لسجل الخادم، ونتيجة الاختبار المباشر مقابل الاختبار عبر الوكيل.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
كيفية تحسين اتصالات قاعدة بيانات Immich للحاويات المتزامنة
لا ترفع max_connections أولًا. قِس جلسات Immich، واجمع إجمالي طلبات كل حاوية، وحافظ على هامش احتياطي للمسؤول، واضبط الاختناق المثبت فقط.
كيفية منع تكرار المهام أو عمليات الاستيراد في Immich
افصل المهام المتكررة عن الأصول المكررة. استخدم مسارًا أساسيًا واحدًا للإدخال، وتحكّم في عمليات إعادة المحاولة وتغييرات المسارات، ثم اختبر إعادة الإدخال على مجموعة...
كيفية إصلاح Immich بعد امتلاء وحدة تخزين قاعدة البيانات الخاصة به
لا تحذف سجلات WAL الخاصة بـ PostgreSQL لتحرير المساحة مطلقًا. أوقف عمليات الكتابة في Immich، وحافظ على حالة قاعدة البيانات، وأضف سعة تخزين آمنة،...
