لماذا ينقطع اتصال n8n على خادم VPS؟

لماذا يبقى n8n غير متصل: أربعة أعطال وعَرَض واحد

عبارة "يبقى n8n غير متصل" تصف أربعة أعطال مختلفة، ولكل عطل منها إصلاح مختلف. يعرض المحرر إشعاراً يفيد بفقدان الاتصال بينما تعمل الحاوية بشكل طبيعي. أو تعيد الحاوية التشغيل تلقائياً. أو تنهي النواة عملية Node.js بسبب استخدامها مقداراً كبيراً من الذاكرة. أو لا توجد مشكلة في العملية أصلاً، لكن سير عمل مفعّلاً لا يُشغَّل مطلقاً. إذا غيّرت الإعداد الخطأ، فستقضي عطلة نهاية أسبوع في معالجة مشكلة غير موجودة لديك.

لذلك حدّد العطل الذي تواجهه قبل تعديل أي إعداد. يعمل n8n كعملية Node.js واحدة، عادةً داخل حاوية Docker واحدة، خلف reverse proxy ينهي TLS (أمان طبقة النقل). يمكن أن تتعطل كل طبقة من هذه الطبقات بطريقة مختلفة، لكن المتصفح يعرض الرسالة نفسها في جميع الحالات.

شخّص المشكلة بهذا الترتيب

نفّذ هذه الأوامر على الـVPS (الخادم الافتراضي الخاص)، واقرأ القيم التي يعرضها جهازك أنت. لا تقارنها بأرقام واردة في منشور بمنتدى. القيم المهمة هنا تصف خادمك، لا خادم شخص آخر.

docker ps -a --filter name=n8n
docker logs --tail 200 --timestamps n8n
docker inspect n8n | grep -iE 'Status|Running|RestartCount|OOMKilled|ExitCode'
docker stats --no-stream

يبيّن العمود STATUS من docker ps -a المدة التي بقيت فيها الحاوية في حالتها الحالية. قارن هذه المدة بوقت بدء المشكلة. إذا كانت الحاوية تعمل منذ وقت يسبق ظهور الشريط بمدة طويلة، فهذا يعني أن n8n لم يتوقف عن العمل. الذي تعطل هو الاتصال بين متصفحك والواجهة الخلفية، وهو مسار websocket المشروح في القسم التالي.

RestartCount هو عدد المرات التي أعاد فيها Docker تشغيل هذه الحاوية. دوّن الرقم، وانتظر دقيقة، ثم اقرأه مرة أخرى. إذا ازداد الرقم أثناء المراقبة، فهذه حلقة إعادة تشغيل. وتحمل أسطر السجل التي تسبق كل إعادة تشغيل مباشرة سبب المشكلة.

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

ExitCode هو رمز الخروج الأخير لحاويتك. لا تحتاج إلى حفظ معنى كل رمز. اقرأ الرمز لديك، ثم اقرأ نهاية docker logs من الطابع الزمني نفسه. يوضّح ذيل السجل ومؤشر نفاد الذاكرة معاً ما حدث، لكن الاعتماد على أي منهما وحده قد يضللك.

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

رسالة فقدان الاتصال سببها عادةً الـreverse proxy

يبقي محرر n8n اتصال push واحداً طويل الأمد مفتوحاً مع الواجهة الخلفية، حتى يتمكن من بث تقدّم التنفيذ إلى اللوحة. يكون هذا الاتصال افتراضياً من نوع WebSocket، وهو ما يحدده N8N_PUSH_BACKEND، وقيمته الافتراضية هي websocket. يبدأ WebSocket كطلب HTTP عادي يحمل الترويستين Connection: Upgrade وUpgrade: websocket. يجيب الخادم بـ101 Switching Protocols، ومن ثم يستخدم الطرفان مقبس TCP نفسه في الاتجاهين.

هناك سببان يؤديان إلى تعطل ذلك، وكلاهما يقع في الـproxy وليس في n8n. قد يستخدم الـproxy HTTP/1.0 عند الاتصال بالواجهة الخلفية، أو يزيل ترويسات الترقية، فلا تحدث الترقية ويستمر المحرر في إعادة الاتصال بلا نهاية. وقد تنجح الترقية، ثم يغلق الـproxy المقبس لاحقاً لأنه ظل هادئاً؛ إذ يبدو WebSocket الذي لا يرسل رسائل تماماً كاتصال خامل. في كلتا الحالتين تكون الحاوية سليمة. وتخبرك الرسالة بأن المتصفح فقد قناته.

أكّد ذلك في المتصفح قبل تعديل أي شيء. افتح أدوات المطور، وانتقل إلى علامة التبويب Network، وطبّق التصفية على WS، ثم أعد تحميل المحرر. يجب أن يصل طلب push إلى 101 Switching Protocols وأن يبقى مفتوحاً. يشير طلب push الذي يعيد رمز حالة عادياً، أو الذي يظهر مجدداً كل بضع ثوانٍ، إلى وجود المشكلة في الـproxy.

إعدادات nginx التي تُبقي المحرر متصلاً

لا يمرّر nginx طلب الترقية ما لم تطلب منه ذلك. يتحدث proxy_pass مع الواجهة الخلفية باستخدام HTTP/1.0 افتراضياً، أما Connection وUpgrade فهما رأسا HTTP من نوع hop-by-hop يزيلهما nginx أثناء التمرير. يجب إعادة ضبطهما معاً. يجب وضع كتلة map ضمن سياق http، وليس داخل server.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    http2 on;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

proxy_read_timeout هو السطر الذي يغفل عنه الناس. قيمته الافتراضية 60 ثانية، وينطبق ذلك أيضاً على WebSocket بعد ترقيته. لذلك تفقد علامة تبويب محرر تُركت مفتوحة على مثيل هادئ اتصالها بعد نحو دقيقة من مرور آخر رسالة عبرها. رفع هذه القيمة هو ما يصلح الشريط الذي يظهر عند العودة إلى علامة تبويب تركتها مفتوحة.

sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | grep -iE 'proxy_http_version|upgrade|proxy_read_timeout'

يطبع nginx -T إعدادات التشغيل الكاملة بدلاً من ملف واحد، ولذلك يثبت أن تعديلك محمّل فعلياً. إذا بقي الإعداد في ملف لا يلتقطه أي سطر include، فسيبدو الإصلاح الصحيح وكأنه لا يفعل شيئاً.

بعد ذلك، أخبر n8n بأنه يعمل خلف وكيل، لأنه ينشئ عناوين URL من هذه القيم.

environment:
  - N8N_HOST=n8n.example.com
  - N8N_PROTOCOL=https
  - N8N_PORT=5678
  - N8N_PROXY_HOPS=1
  - N8N_WEBHOOK_URL=https://n8n.example.com/

القيمة الافتراضية لـN8N_PROXY_HOPS هي 0. وهذا يعني أن n8n يتعامل مع العنوان المتصل باعتباره عنوان العميل ويتجاهل X-Forwarded-For. اضبطها على عدد الوكلاء الموجودين أمام الحاوية. اعتباراً من August 2026، أصبح N8N_WEBHOOK_URL هو الاسم الحالي، وما زال WEBHOOK_URL الأقدم يعمل، مع طباعة تحذير إيقاف استخدام عند بدء التشغيل.

يمرّر Traefik ترقية WebSocket ثم يقطع الاتصال عند انتهاء المهلة

يمرّر Traefik ترقية WebSocket من دون middleware ومن دون labels إضافية، لذلك فإن مستخدم Traefik الذي يرى هذه الرسالة يواجه عادةً انتهاء مهلة، لا فقدان رأس. توجد إعدادات التحكم في entryPoint. اعتباراً من August 2026 في Traefik v3، تكون القيمة الافتراضية لـ idleTimeout هي 180 seconds، والقيمة الافتراضية لـ readTimeout هي 60 seconds.

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        idleTimeout: 3600s

يتعامل Caddy مع الترقية تلقائياً في reverse_proxy ولا يحتاج إلى directive لها. إذا لم تتمكن من تغيير الـproxy إطلاقاً لأن جهة أخرى تملكه، فبدّل قناة الدفع باستخدام N8N_PUSH_BACKEND=sse. تُعد SSE (server-sent events) استجابة HTTP عادية تبقى مفتوحة، لذلك تستمر مع proxy يرفض الترقيات، لكن مهلة الخمول القصيرة بشدة تقطعها أيضاً. اختيار الـproxy نفسه قرار منفصل، وتوضح مقارنة nginx وCaddy وTraefik تكلفة تشغيل كل خيار.

عندما تعيد الحاوية التشغيل فعلياً

إذا ارتفع RestartCount، فهذا يعني أن الحاوية تفشل وأن Docker يعيد تشغيلها. طابق الطوابع الزمنية في السجل مع كل عملية إعادة تشغيل، واقرأ ما حدث مباشرة قبلها. تغطي أربعة أسباب معظم الحالات: خطأ في الإعدادات يمنع بدء التشغيل، أو قاعدة بيانات يتعذر على n8n الوصول إليها، أو انهيار بعد بدء التشغيل، أو إنهاء بسبب نفاد الذاكرة.

ابدأ بالـvolume، لأن الصلاحيات هي السبب غير الظاهر. تعمل الصورة الرسمية بالمستخدم غير المميّز node، وتخزّن بياناتها في /home/node/.n8n. لا يستطيع هذا المستخدم الكتابة إلى bind mount أنشأه root، لذلك تنتهي العملية عند بدء التشغيل في كل مرة، وتخفي سياسة إعادة التشغيل المشكلة داخل حلقة متكررة.

docker compose config
docker run --rm -it --entrypoint sh docker.n8n.io/n8nio/n8n -c 'id'
docker exec n8n ls -ld /home/node/.n8n

يتجنب named volume المشكلة بالكامل، لأن Docker ينشئه بالملكية الصحيحة. إذا احتجت إلى bind mount، chown دليل المضيف إلى معرّف المستخدم الرقمي الذي طبعه الأمر الأول. من المفيد فهم تعيين الملكية بين المضيف والحاوية مرة واحدة، ويشرح دليل PUID وPGID كيف تحدد هذه الصور المستخدم الذي يكتب الملفات.

حالة قتل العملية بسبب نفاد الذاكرة التي تبدو كأنها تعطل

يوجد حدّان منفصلان للذاكرة فوق عملية n8n، ويتصرف كل منهما بطريقة مختلفة عند تجاوزه. يفرض kernel حد مجموعة التحكم الخاصة بـcontainer: عند تجاوزه، تُقتل العملية فوراً من دون فرصة لكتابة أي شيء، وتصبح قيمة OOMKilled هي true. يفرض Node.js حد V8 heap من داخله: عند تجاوزه، يطرح Node خطأ heap مع stack trace ثم يخرج من تلقاء نفسه، لذلك تصبح قيمة OOMKilled هي false. تبدو الحالتان متطابقتين من المتصفح. لكن من docker inspect تفصل بينهما خانة واحدة.

اضبط حد Node heap على قيمة أقل من حد container. إذا كان حد heap هو الأعلى بين الحدين، فسيواصل V8 تخصيص الذاكرة بعد النقطة التي يتدخل فيها kernel. لذلك لن يصل garbage collector إلى حده الخاص، وستحصل دائماً على الفشل الأشد من دون سجل يمكن قراءته.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - NODE_OPTIONS=--max-old-space-size=<MiB, below the container limit>
    deploy:
      resources:
        limits:
          memory: <your container limit>

اختر الرقمين استناداً إلى الموارد الفعلية المتاحة على VPS، واترك مساحة لقاعدة البيانات وproxy ونظام التشغيل. يطبع docker stats --no-stream الاستخدام الحالي بجانب الحد المطبّق، حتى تتحقق من أن الحد الذي كتبته هو الحد الذي طبّقه Docker. يشرح كيفية تطبيق حدود الذاكرة في Compose أي مفتاح تكون له الأولوية عند ضبط عدة حدود.

بيانات التنفيذ هي ما يتراكم في الخلفية

يحتوي تنفيذ واحد على مخرجات كل عقدة طوال فترة التشغيل، ثم يخزّن n8n هذه البيانات. وينتج عن ذلك أمران. تحدد أكبر دفعة بيانات تمررها عبر التنفيذ ذروة الذاكرة لتشغيل واحد، لذلك يختلف سير العمل الذي يعالج عشرة آلاف صف دفعة واحدة عن سير العمل نفسه عندما يعالج مئتي صف في كل مرة. كما تستمر النسخة المخزنة في النمو إلى أن يحذفها شيء ما.

تعالج عملية التنظيف المشكلة الثانية. اعتباراً من August 2026، تكون الإعدادات الافتراضية هي تفعيل التنظيف، وضبط EXECUTIONS_DATA_MAX_AGE على 336 hours (14 days)، وضبط EXECUTIONS_DATA_PRUNE_MAX_COUNT على 10000. وتُعد هذه القيم كبيرة بالنسبة إلى VPS صغير يشغّل SQLite، حيث يحتفظ ملف واحد بكل البيانات، وتضطر العملية نفسها التي تعرض المحرر إلى قراءتها وكتابتها.

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=72
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

يُعد EXECUTIONS_DATA_SAVE_ON_SUCCESS=none الإعداد الأكثر تشدداً. فهو يحتفظ بالتنفيذات الفاشلة لأغراض تصحيح الأخطاء ويحذف التنفيذات الناجحة. اتخذ هذا القرار عمداً، لأن سير العمل الذي ينتج مخرجات خاطئة من دون تسجيل خطأ لن يترك لك شيئاً تفحصه. كما تضع عملية التنظيف علامة الحذف على الصفوف أولاً، ثم تزيلها في عملية لاحقة. ويعيد SQLite استخدام الصفحات المحررة بدلاً من إعادتها إلى النظام، لذلك لا يتقلص حجم الملف على القرص فور تغيير الإعداد.

لتقليل الذروة بدلاً من إجمالي البيانات المخزنة، انقل بيانات أقل في كل تنفيذ. قسّم المهام الكبيرة إلى سير عمل فرعي يعيد نتائج صغيرة إلى سير العمل الأصل، واستخدم العقدة Loop Over Items لمعالجة البيانات على دفعات، وتجنب تمرير مجموعات البيانات الكاملة إلى عقدة Code.

يجب ألا تمر الملفات الثنائية عبر الذاكرة

تكون N8N_DEFAULT_BINARY_DATA_MODE مضبوطة افتراضياً على default، ما يؤدي إلى إبقاء البيانات الثنائية في ذاكرة التنفيذ الجاري. يبقى كل ملف تنزّله عقدة، وكل نسخة تُمرَّر إلى العقدة التالية، في الذاكرة حتى ينتهي التشغيل. يمكن لسير عمل واحد يجلب عدداً قليلاً من المرفقات الكبيرة أن يتجاوز حدّاً لا تقترب منه عمليات JSON العادية، ولذلك يتبع التعطل سير عمل محدداً بدلاً من حدوثه وفق مدة زمنية ثابتة.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

عند استخدام filesystem، تُكتب البيانات الثنائية ضمن N8N_BINARY_DATA_STORAGE_PATH، وهو موجود افتراضياً داخل مجلد مستخدم n8n، ولذلك يقع على وحدة التخزين نفسها التي تضم بقية البيانات. تحقّق من توفر مساحة كافية على وحدة التخزين قبل التبديل. تحدد N8N_PAYLOAD_SIZE_MAX أكبر حمولة واردة عبر webhook بوحدة MiB (ميبيبايت)، وتكون قيمتها الافتراضية 16. يؤدي رفعها إلى السماح بطلبات أكبر، وهذا يضيف تكلفة على الذاكرة تختار تحمّلها.

تتنافس كل المكونات الأخرى التي تشارك الخادم على ذاكرة RAM نفسها. إذا بدأت عمليات OOM kills بعد إضافة حاوية قاعدة بيانات، فإن تشغيل قاعدة البيانات في Docker أو على المضيف هو المفاضلة التي تتخذها الآن.

سياسة إعادة التشغيل والعودة بعد إعادة التشغيل

تبقى الحاوية التي لا تملك سياسة إعادة تشغيل متوقفة بعد خروجها، وكذلك بعد إعادة تشغيل المضيف. يعيدها restart: unless-stopped في كلتا الحالتين، مع احترام الحاوية التي أوقفتها يدوياً. يعيد restart: always أيضاً تشغيل الحاوية التي أوقفتها عمداً عند بدء Docker مرة أخرى.

يوفّر n8n نقطة نهاية لفحص الصحة، ويحدّدها N8N_ENDPOINT_HEALTH، وتكون قيمتها الافتراضية healthz. افحصها من المضيف أولاً للتأكد من صحة المسار في مثيلك.

curl -fsS http://127.0.0.1:5678/healthz
docker exec n8n which wget curl
sudo systemctl is-enabled docker

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

سير العمل الذي لا يعمل مطلقاً رغم أن n8n يعمل

لا ينتج هذا أي شريط إشعار ولا تحدث إعادة تشغيل. الحاوية قيد التشغيل، ويعمل المحرر، لكن التشغيل الذي توقعته غير موجود في قائمة التنفيذات. تفسّر أربعة أسباب معظم هذه الحالات.

• سير العمل غير نشط. يعمل Schedule Trigger في مسار الإنتاج فقط، لذلك لا يؤدي اختباره في اللوحة إلى جدولة أي شيء.
• المنطقة الزمنية ليست منطقتك. تكون GENERIC_TIMEZONE مضبوطةً افتراضياً على America/New_York، لذلك يعمل الجدول المحدد عند 09:00 في تلك المنطقة حتى تضبط GENERIC_TIMEZONE وTZ على منطقتك.
• لا تُعوَّض فترة التوقف لاحقاً. تُسجَّل المشغلات عند بدء n8n، لذلك لا يعمل الجدول الذي حان موعده أثناء إعادة تشغيل الحاوية متأخراً. يكون التشغيل التالي في الموعد المستحق التالي بعد بدء التشغيل.
• أُوقف سير العمل تلقائياً. تكون N8N_WORKFLOW_AUTODEACTIVATION_ENABLED معطّلةً افتراضياً، وعند تفعيلها يُلغى نشر سير العمل الذي يستمر في التعطل، وبعد ذلك يبدو تماماً مثل سير عمل لم يفعّله أحد قط.

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

ما الذي يجب تغييره أولاً

1. اقرأ STATUS وRestartCount وOOMKilled في حاويتك بنفسك قبل تعديل أي ملف.
2. إذا لم تتوقف الحاوية قط، فأصلح رؤوس ترقية الـproxy والمهلة الزمنية للخمول.
3. إذا كان OOMKilled صحيحاً، فعيّن حداً للحاوية بعد اختياره عمداً، واجعل الحد الأقصى لذاكرة Node أقل منه، وانقل البيانات الثنائية إلى filesystem.
4. إذا لم يحدث شيء، فتحقق من أن سير العمل نشط، وأن المنطقة الزمنية للمثيل هي منطقتك.

معظم هذه الإعدادات تُضبط مرة واحدة ثم تُترك، بشرط أن يكون التثبيت الأساسي عاملاً. إذا كنت لا تزال تجهّز ذلك التثبيت، فراجع دليل تشغيل n8n على Docker مع HTTPS، فهو الأساس الذي تنتمي إليه هذه الإعدادات.

FAQ

لماذا يعرض محرر n8n شريط فقدان الاتصال مع أن الحاوية قيد التشغيل؟

يبقي المحرر اتصال WebSocket مفتوحاً لبث تقدم التنفيذ. إذا لم يمرر الـreverse proxy الرأسي Connection: Upgrade وUpgrade: websocket، أو لم يستخدم HTTP/1.1 مع الخادم اللاحق، فلن تكتمل الترقية، وسيعيد المتصفح الاتصال باستمرار بينما تبقى n8n سليمة. في nginx، تحتاج إلى proxy_http_version 1.1 بالإضافة إلى سطري proxy_set_header، وإلى proxy_read_timeout أطول من القيمة الافتراضية البالغة 60 ثانية حتى لا تُقطع علامة تبويب ساكنة. تحقّق من الإعدادات العاملة باستخدام sudo nginx -T، وليس من الملف الذي عدّلته.

كيف أميّز بين إيقاف العملية بسبب نفاد الذاكرة والتعطل العادي؟

شغّل docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' واقرأ العلامة OOMKilled. تعني القيمة True أن النواة أوقفت العملية لأنها تجاوزت حد الذاكرة، ولن تجد معلومات مفيدة في سجل الحاوية لأن العملية لم تحصل على فرصة للكتابة. أما القيمة False، مع ظهور خطأ heap وstack trace في نهاية docker logs، فتعني أن Node.js بلغ حد V8 heap الخاص به وخرج من تلقاء نفسه. اضبط NODE_OPTIONS=--max-old-space-size على قيمة أقل من حد الحاوية، حتى تحصل على الفشل الثاني، لأنه يترك أدلة يمكن فحصها.

هل يؤدي حذف بيانات التنفيذ القديمة إلى تحرير مساحة القرص فوراً؟

لا. يعلّم EXECUTIONS_DATA_PRUNE عمليات التنفيذ القديمة للحذف، ثم تزيلها عملية لاحقة وفق الجدول المحدد بواسطة EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL. مع SQLite، يعيد الملف أيضاً استخدام الصفحات المحررة بدلاً من إعادتها إلى نظام الملفات، لذلك يظل حجمه على القرص ثابتاً لبعض الوقت بعد حذف الصفوف. اضبط EXECUTIONS_DATA_MAX_AGE وEXECUTIONS_DATA_PRUNE_MAX_COUNT على قيم مناسبة لخادمك، ثم تحقّق مرة أخرى في اليوم التالي بدلاً من التحقق فوراً.

لماذا لم تُشغَّل مهمة سير العمل المجدولة أثناء إعادة تشغيل n8n؟

يسجّل n8n المشغّلات عند بدء العملية، ولا يعيد تشغيل الجداول التي حان موعدها أثناء توقفه. لذلك تنتج حلقة إعادة التشغيل صمتاً بدلاً من دفعة من عمليات التشغيل المتأخرة، ويكون التنفيذ التالي هو الموعد المستحق التالي بعد بدء التشغيل. إذا كنت تحتاج إلى عمليات تشغيل لا يجوز فقدانها، فشغّل سير العمل من مستدعٍ خارجي يرسل طلباً إلى webhook، بحيث يبقى منطق إعادة المحاولة خارج n8n.

هل تعيد healthcheck تشغيل n8n عندما تتوقف عن الاستجابة؟

ليس بمفرده. يحدد healthcheck في Compose حالة الحاوية فقط: سليمة أو غير سليمة. تتولى سياسة إعادة التشغيل مهمة إعادة التشغيل، ولذلك فإن restart: unless-stopped يعيد الحاوية بعد خروجها، ويعيدها أيضاً بعد إعادة تشغيل المضيف، ما دام Docker مفعّلاً للعمل. أكّد ذلك باستخدام sudo systemctl is-enabled docker. ولتنفيذ إجراء عند كون الحالة غير سليمة تحديداً، تحتاج إلى watcher خارج Docker يقرأ الحالة ويعيد تشغيل الخدمة.