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

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

عبارة «يتوقف n8n عن الاتصال» تصف أربعة أعطال مختلفة، ولكل عطل إصلاح مختلف. يعرض المحرر إشعاراً بانقطاع الاتصال بينما تعمل الحاوية بصورة طبيعية. أو تعيد الحاوية التشغيل من تلقاء نفسها. أو يقتل kernel عملية 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 ترويسات hop-by-hop يزيلها nginx أثناء تمرير الطلب. يجب إعادة الترويسـتين. يجب وضع كتلة map ضمن سياق http، وليس داخل server. إذا لم تكن بقية كتلة الخادم أدناه مألوفة لك، يشرح الشرح التفصيلي سطراً بسطر لكتلة خادم nginx وظيفة كل توجيه.

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 بأنه يعمل خلف proxy، لأنه ينشئ عناوين 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. اضبطها على عدد الـproxy الموجودة أمام الحاوية. اعتباراً من 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 حدّ cgroup الخاص بالحاوية. عند تجاوزه، تُقتل العملية فوراً من دون فرصة لكتابة أي شيء، وتكون قيمة OOMKilled هي true. يفرض Node.js حدّ V8 heap من داخله. عند تجاوزه، يطرح Node خطأ في heap مع stack trace ثم يخرج من تلقاء نفسه، ولذلك تكون قيمة OOMKilled هي false. من المتصفح، تبدو الحالتان متطابقتين. ومن خلال docker inspect، يفصل بينهما حقل واحد.

اضبط حد Node للـheap على قيمة أقل من حد الحاوية. إذا كان حد الـ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 هذه البيانات. وينتج عن ذلك أمران. تتحدد ذروة الذاكرة لتنفيذ واحد بأكبر دفعة بيانات تمرّرها عبره. لذلك يختلف workflow الذي يعالج عشرة آلاف صف دفعة واحدة عن workflow نفسه عندما يعالج مئتي صف في كل مرة. كما تستمر النسخة المخزّنة في النمو إلى أن يحذفها شيء ما.

تعالج عملية التنظيف المشكلة الثانية. اعتباراً من 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 الإعداد الأكثر تشدداً. فهي تحتفظ بالتنفيذات الفاشلة لأغراض تصحيح الأخطاء، وتحذف التنفيذات الناجحة. اتخذ هذا القرار عن قصد، لأن workflow الذي أنتج مخرجات خاطئة من دون إصدار خطأ لن يترك لك شيئاً تفحصه. كما تضع عملية التنظيف علامة الحذف على الصفوف أولاً، ثم تزيلها في مرور لاحق. ويعيد SQLite استخدام الصفحات المحررة بدلاً من إعادتها إلى نظام التشغيل، لذلك لا يتقلص حجم الملف على القرص فور تغيير الإعداد.

لتقليل الذروة بدلاً من إجمالي البيانات المخزّنة، انقل بيانات أقل في كل تنفيذ. قسّم المهام الكبيرة إلى sub-workflows تعيد نتائج صغيرة إلى workflow الأب، ونفّذ المعالجة على دفعات باستخدام عقدة 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 kill بعد إضافة حاوية قاعدة بيانات، فإن تشغيل قاعدة البيانات في 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 معطّلة افتراضياً، وعند تفعيلها يُلغى نشر سير العمل الذي يستمر في التعطل، وبعد ذلك يبدو تماماً كسير عمل لم يفعّله أحد من قبل.

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

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

1. اقرأ STATUS وRestartCount وOOMKilled في حاويتك بنفسك قبل تعديل أي ملف.
2. إذا لم تتوقف الحاوية مطلقاً، فأصلح رؤوس ترقية الوكيل والمهلة الزمنية للخمول.
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 أن kernel أوقف العملية لأنها تجاوزت حد الذاكرة، ولن تجد شيئًا مفيدًا في سجل الحاوية لأن العملية لم تحصل على فرصة للكتابة. أما القيمة 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 service مفعّلًا. أكّد ذلك باستخدام sudo systemctl is-enabled docker. وللتصرف عند انتقال الحاوية إلى حالة غير سليمة تحديدًا، تحتاج إلى watcher خارج Docker يقرأ الحالة ويعيد تشغيل الخدمة.