VPS पर n8n बार-बार ऑफलाइन क्यों हो जाता है?

n8n के ऑफलाइन होने के चार कारण और एक लक्षण

"n8n ऑफलाइन हो रहा है" एक ऐसा वाक्य है जो चार अलग-अलग विफलताओं को दर्शाता है, और प्रत्येक के लिए अलग समाधान की आवश्यकता होती है। एडिटर में connection lost का बैनर दिखाई देता है जबकि कंटेनर सामान्य रूप से चल रहा होता है। कंटेनर अपने आप रीस्टार्ट हो जाता है। कर्नल बहुत अधिक मेमोरी उपयोग करने के कारण Node.js प्रोसेस को समाप्त (kill) कर देता है। या फिर प्रोसेस में कोई समस्या नहीं होती, लेकिन एक सक्रिय वर्कफ़्लो कभी ट्रिगर ही नहीं होता। गलत सेटिंग बदलने पर आप उस समस्या पर पूरा सप्ताहांत बर्बाद कर देंगे जो वास्तव में थी ही नहीं।

इसलिए किसी भी कॉन्फ़िगरेशन को बदलने से पहले यह पता लगाएँ कि आपको कौन सी विफलता का सामना करना पड़ रहा है। n8n एक सिंगल Node.js प्रोसेस के रूप में चलता है, आमतौर पर एक Docker कंटेनर के अंदर, जो TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) को समाप्त करने वाले रिवर्स प्रॉक्सी के पीछे होता है। इनमें से प्रत्येक लेयर अपने तरीके से विफल हो सकती है, और ब्राउज़र उन सभी के लिए एक ही संदेश दिखाता है।

इस क्रम में निदान करें

VPS (virtual private server) पर ये commands चलाएं और अपनी मशीन द्वारा प्रिंट किए गए मानों को पढ़ें। उनकी तुलना किसी फ़ोरम थ्रेड के नंबरों से न करें। यहाँ जो मान मायने रखते हैं, वे आपके सिस्टम के हैं, किसी और के नहीं।

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

docker ps -a का STATUS कॉलम बताता है कि container अपनी वर्तमान स्थिति में कितनी देर से है। इसकी तुलना उस समय से करें जब आपकी समस्या शुरू हुई थी। यदि banner दिखाई देने से काफी पहले से container चल रहा है, तो n8n कभी offline नहीं हुआ। जो टूटा है वह आपके browser और backend के बीच का connection है, जो कि websocket path है और इसे अगले section में कवर किया गया है।

RestartCount यह दर्शाता है कि Docker ने इस container को कितनी बार restart किया है। नंबर नोट करें, एक मिनट प्रतीक्षा करें, फिर इसे दोबारा पढ़ें। यदि आपके देखते ही नंबर बढ़ रहा है, तो यह एक restart loop है, और प्रत्येक restart से ठीक पहले की log lines में इसका कारण मौजूद होता है।

OOMKilled एक true या false flag है। True का अर्थ है कि Linux kernel ने process को समाप्त कर दिया है क्योंकि यह memory limit से बाहर चली गई थी, चाहे वह container की अपनी limit हो या पूरी मशीन की। यह एक field memory kill को बाकी सभी प्रकार के exit से अलग करती है, इसीलिए अनुमान लगाने से पहले आप इसे पढ़ते हैं।

ExitCode वह कोड है जिसके साथ आपका container आखिरी बार exit हुआ था। आपको यह याद रखने की आवश्यकता नहीं है कि प्रत्येक कोड का क्या अर्थ है। अपना कोड पढ़ें, फिर उसी timestamp से docker logs का अंत पढ़ें। log tail और out of memory flag मिलकर बताते हैं कि क्या हुआ था, और इनमें से कोई भी एक आपको गुमराह कर सकता है।

docker stats लागू limit के साथ-साथ live memory उपयोग दिखाता है। इसे एक दूसरे terminal में चलते रहने दें, वह workflow trigger करें जो चीजों को खराब करता है, और देखें कि विफलता के दौरान नंबर क्या व्यवहार करता है।

Connection lost बैनर आमतौर पर आपके reverse proxy के कारण होता है

n8n editor backend के साथ एक long-lived push connection खुला रखता है ताकि वह execution progress को canvas पर stream कर सके। डिफ़ॉल्ट रूप से वह connection एक WebSocket होता है, जिसे N8N_PUSH_BACKEND चुनता है, और इसका डिफ़ॉल्ट मान websocket है। एक WebSocket की शुरुआत एक सामान्य HTTP request से होती है जिसमें Connection: Upgrade और Upgrade: websocket headers होते हैं। सर्वर 101 Switching Protocols के साथ उत्तर देता है, और उसके बाद दोनों पक्ष एक ही TCP socket का उपयोग दोनों दिशाओं में करते हैं।

दो चीजें इसे बाधित करती हैं, और वे दोनों n8n के बजाय proxy में होती हैं। या तो proxy upstream पर HTTP/1.0 का उपयोग करता है या upgrade headers को हटा देता है, जिससे upgrade कभी नहीं हो पाता और editor बार-बार reconnect करता रहता है। या फिर upgrade सफल हो जाता है और proxy बाद में socket को बंद कर देता है क्योंकि वह शांत रहा है, क्योंकि बिना किसी message वाला WebSocket बिल्कुल idle connection जैसा दिखता है। दोनों ही स्थितियों में container healthy होता है। बैनर का मतलब है कि browser आपको बता रहा है कि उसने अपना channel खो दिया है।

कुछ भी edit करने से पहले browser में इसकी पुष्टि करें। Developer tools खोलें, Network tab पर जाएं, WS के लिए filter करें, और editor को reload करें। Push request को 101 Switching Protocols तक पहुंचना चाहिए और खुला रहना चाहिए। एक push request जो सामान्य status code लौटाती है, या जो हर कुछ सेकंड में फिर से दिखाई देती है, वह proxy की ओर इशारा करती है।

nginx सेटिंग्स जो एडिटर को कनेक्टेड रखती हैं

nginx तब तक upgrade request को आगे नहीं भेजता जब तक आप ऐसा करने के लिए न कहें। proxy_pass डिफ़ॉल्ट रूप से backend के साथ HTTP/1.0 का उपयोग करता है, और Connection तथा Upgrade hop-by-hop हेडर हैं जिन्हें nginx आगे भेजते समय हटा देता है। आपको इन दोनों को वापस जोड़ना होगा। map ब्लॉक को server के अंदर नहीं, बल्कि http कॉन्टेक्स्ट में रखा जाना चाहिए। यदि नीचे दिया गया बाकी सर्वर ब्लॉक आपके लिए नया है, तो nginx सर्वर ब्लॉक का पंक्ति-दर-पंक्ति विवरण यह बताता है कि प्रत्येक directive क्या काम कर रही है।

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 पर भी लागू होता है। इसलिए, यदि कोई एडिटर टैब किसी शांत instance पर खुला रह जाए, तो अंतिम संदेश के एक मिनट बाद उसका कनेक्शन टूट जाता है। इसे बढ़ाने से वह बैनर हट जाता है जो टैब पर वापस लौटने पर दिखाई देता है।

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 को अनदेखा कर देता है। इसे कंटेनर के सामने मौजूद proxies की संख्या पर सेट करें। अगस्त 2026 तक, N8N_WEBHOOK_URL वर्तमान नाम है और पुराना WEBHOOK_URL अभी भी काम करता है, हालांकि स्टार्टअप पर यह एक deprecation चेतावनी प्रिंट करता है।

Traefik WebSocket को forward करता है, फिर उसे timeout कर देता है

Traefik बिना किसी middleware और बिना किसी अतिरिक्त label के WebSocket upgrade को forward करता है। इसलिए, जो Traefik उपयोगकर्ता यह banner देखते हैं, वे आमतौर पर missing header के बजाय timeout का सामना कर रहे होते हैं। इसके नियंत्रण entryPoint पर होते हैं। अगस्त 2026 तक Traefik v3 में, idleTimeout का default मान 180 सेकंड और readTimeout का default मान 60 सेकंड है।

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

Caddy reverse_proxy में upgrade को स्वचालित रूप से संभालता है और इसके लिए किसी directive की आवश्यकता नहीं होती है। यदि आप proxy को बिल्कुल भी नहीं बदल सकते, क्योंकि इसका स्वामित्व किसी और के पास है, तो N8N_PUSH_BACKEND=sse के साथ push channel को बदलें। SSE (server-sent events) एक सामान्य HTTP response है जिसे खुला रखा जाता है, इसलिए यह ऐसे proxy के साथ भी काम करता है जो upgrade को अस्वीकार करता है, हालांकि एक aggressive idle timeout इसे फिर भी काट सकता है। proxy का चयन करना एक अलग निर्णय है, और nginx, Caddy और Traefik की तुलना इस बात को कवर करती है कि प्रत्येक को संचालित करने में आपकी क्या लागत आती है।

जब कंटेनर वास्तव में बार-बार रीस्टार्ट हो रहा हो

यदि RestartCount बढ़ता है, तो इसका मतलब है कि कंटेनर विफल हो रहा है और Docker उसे बार-बार चालू करने का प्रयास कर रहा है। लॉग के टाइमस्टैम्प को प्रत्येक रीस्टार्ट के साथ मिलाएं और देखें कि ठीक उससे पहले क्या हुआ था। लगभग सभी समस्याएं इन चार कारणों से होती हैं: स्टार्टअप को रोकने वाली कॉन्फ़िगरेशन त्रुटि, ऐसा डेटाबेस जिससे n8n कनेक्ट नहीं हो पा रहा है, चलने के दौरान क्रैश होना, और मेमोरी लिमिट के कारण प्रोसेस का बंद होना।

शुरुआत वॉल्यूम से करें, क्योंकि अनुमतियों (permissions) से जुड़ी समस्याएं अक्सर छिपी रहती हैं। आधिकारिक इमेज एक अनप्रिविलेज्ड यूजर node के रूप में चलती है और अपना डेटा /home/node/.n8n में रखती है। root द्वारा बनाया गया bind mount उस यूजर के लिए लिखने योग्य नहीं होता है, इसलिए प्रोसेस हर बार स्टार्टअप पर ही बंद हो जाती है और रीस्टार्ट पॉलिसी इसे एक लूप के पीछे छिपा देती है।

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 की व्याख्या में यह बताया गया है कि ये इमेज कैसे तय करती हैं कि फाइलें कौन लिखेगा।

Out of memory kill जो क्रैश जैसा दिखता है

n8n process के ऊपर दो अलग-अलग memory ceilings होती हैं, और वे अलग-अलग तरह से विफल (fail) होती हैं। Container control group limit को kernel द्वारा लागू किया जाता है: यदि आप इसे पार करते हैं, तो process तुरंत kill हो जाती है, जिसमें कुछ भी लिखने का मौका नहीं मिलता, और OOMKilled true पढ़ा जाता है। V8 heap limit को Node.js के भीतर लागू किया जाता है: यदि आप इसे पार करते हैं, तो Node एक heap error और stack trace के साथ बाहर निकल जाता है, इसलिए OOMKilled false पढ़ा जाता है। Browser से ये दोनों एक जैसे दिखते हैं। docker inspect से देखने पर इनमें केवल एक field का अंतर होता है।

Node heap ceiling को container limit से नीचे सेट करें। यदि heap ceiling दोनों में से अधिक है, तो V8 उस बिंदु से आगे भी allocate करना जारी रखता है जहाँ kernel हस्तक्षेप करता है, इसलिए इसका garbage collector अपनी सीमा तक कभी नहीं पहुँच पाता और आपको हमेशा बिना किसी log के कठोर विफलता (harsher failure) मिलती है।

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 की वास्तविक क्षमता के अनुसार चुनें, और database, proxy तथा operating system के लिए जगह छोड़ें। docker stats --no-stream लागू सीमा के साथ वर्तमान उपयोग को print करता है, ताकि आप जाँच सकें कि जो सीमा आपने लिखी है, वही Docker द्वारा लागू की गई है। Compose memory limits कैसे लागू होते हैं इस बारे में विस्तार से बताता है कि जब कई सीमाएँ सेट की जाती हैं, तो कौन सी key प्रभावी होती है।

Execution data वह है जो आपके नीचे बढ़ता रहता है

एक execution के दौरान हर node का output सुरक्षित रहता है और n8n उस डेटा को store करता है। इसके दो परिणाम होते हैं। एक run की peak memory उस डेटा के सबसे बड़े batch से तय होती है जिसे आप उसमें भेजते हैं, इसलिए जो workflow एक साथ दस हजार rows को handle करता है, वह दो सौ rows को handle करने वाले उसी workflow से बिल्कुल अलग program है। और stored copy तब तक बढ़ती रहती है जब तक कोई उसे delete न कर दे।

Pruning इस दूसरी समस्या को संभालती है। अगस्त 2026 तक, default settings में pruning enabled है, EXECUTIONS_DATA_MAX_AGE 336 घंटों (14 दिन) पर और EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000 पर सेट है। SQLite चलाने वाले एक छोटे VPS के लिए ये काफी उदार सीमाएं हैं, जहाँ एक ही file में सब कुछ होता है और वही process editor को serve करती है जो उसे read और write भी करती है।

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 एक aggressive setting है। यह debugging के लिए failed executions को रखती है और सफल executions को हटा देती है। इसे सोच-समझकर चुनें, क्योंकि यदि कोई workflow बिना error दिए गलत output देता है, तो आपके पास जांचने के लिए कुछ नहीं बचेगा। Pruning पहले rows को deleted के रूप में mark करती है और बाद में उन्हें हटाती है, और SQLite खाली हुए pages को वापस करने के बजाय उनका पुनः उपयोग करता है, इसलिए setting बदलने के तुरंत बाद disk पर file का आकार कम नहीं होता।

Stored total के बजाय peak को कम करने के लिए, प्रति run कम डेटा भेजें। बड़े jobs को ऐसे sub-workflows में विभाजित करें जो parent को छोटे results लौटाते हों, Loop Over Items node के साथ batching करें, और पूरे datasets को Code node से बाहर रखें।

Binary files को memory के माध्यम से प्रोसेस नहीं किया जाना चाहिए

N8N_DEFAULT_BINARY_DATA_MODE डिफ़ॉल्ट रूप से default पर सेट होता है, जो बाइनरी डेटा को रनिंग execution की memory में रखता है। एक node जो भी फ़ाइल डाउनलोड करता है, और उसकी जो भी कॉपी अगले node को दी जाती है, वह रन खत्म होने तक वहीं रहती है। एक workflow जिसमें कुछ बड़ी attachments फेच की जाती हैं, वह process को उस सीमा से आगे धकेल सकता है जहाँ सामान्य JSON कार्य कभी नहीं पहुँचते। यही कारण है कि क्रैश समय के बजाय किसी विशिष्ट workflow के कारण होता है।

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem के साथ, बाइनरी डेटा को N8N_BINARY_DATA_STORAGE_PATH के अंतर्गत लिखा जाता है, जो डिफ़ॉल्ट रूप से n8n user फ़ोल्डर के अंदर रहता है और इसलिए अन्य सभी चीज़ों के समान volume पर ही स्टोर होता है। स्विच करने से पहले जाँच लें कि volume में पर्याप्त जगह है या नहीं। N8N_PAYLOAD_SIZE_MAX सबसे बड़े incoming webhook payload को MiB (mebibytes) में सेट करता है और इसका डिफ़ॉल्ट मान 16 है। इसे बढ़ाने से बड़ी requests अंदर आ सकती हैं, और यह एक ऐसा memory खर्च है जिसे आप स्वीकार करने का विकल्प चुन रहे हैं।

सर्वर पर चल रही अन्य कोई भी चीज़ समान RAM के लिए प्रतिस्पर्धा करती है। यदि OOM kills तब शुरू हुए जब आपने एक database container जोड़ा, तो database को Docker में या host पर चलाना वह समझौता है जो आप अब कर रहे हैं।

Restart policy और reboot के बाद वापसी

बिना restart policy वाला container exit होने के बाद और host के reboot होने के बाद बंद ही रहता है। restart: unless-stopped इसे दोनों स्थितियों में वापस ले आता है, जबकि आपके द्वारा मैन्युअल रूप से रोके गए container का भी सम्मान करता है। restart: always आपके द्वारा जानबूझकर रोके गए container को भी Docker के अगली बार start होने पर restart कर देता है।

n8n एक health endpoint प्रदान करता है, जिसे N8N_ENDPOINT_HEALTH द्वारा नामित किया गया है, जो डिफ़ॉल्ट रूप से healthz पर होता है। इसे पहले host से जांचें ताकि आप सुनिश्चित हो सकें कि आपकी instance पर path सही है।

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

Healthcheck अपने आप में कुछ भी restart नहीं करता है। Compose container को unhealthy के रूप में चिह्नित करता है और वहीं रुक जाता है, इसलिए healthcheck का कोई प्रभाव होने के लिए इसके साथ एक restart policy या बाहरी watcher की आवश्यकता होती है। ऐसा healthcheck लिखना जो वास्तव में कार्य करे और reboot के बाद stack को फिर से start करना इन दोनों पहलुओं को कवर करते हैं।

वह वर्कफ़्लो जो कभी ट्रिगर नहीं होता जबकि n8n ठीक चल रहा है

इसमें न तो कोई बैनर दिखता है और न ही कोई रीस्टार्ट होता है। कंटेनर चालू है, एडिटर काम कर रहा है, लेकिन जिस रन की आपको उम्मीद थी वह निष्पादन सूची (executions list) में नहीं है। इसके अधिकांश मामलों के लिए चार कारण जिम्मेदार होते हैं।

• वर्कफ़्लो सक्रिय (active) नहीं है। एक Schedule Trigger केवल प्रोडक्शन पाथ पर चलता है, इसलिए कैनवास में इसका परीक्षण करने पर कुछ भी शेड्यूल नहीं होता।
• टाइमज़ोन आपका नहीं है। GENERIC_TIMEZONE डिफ़ॉल्ट रूप से America/New_York पर सेट होता है, इसलिए 09:00 के लिए सेट किया गया शेड्यूल तब तक उसी ज़ोन में 09:00 बजे ही चलेगा जब तक आप GENERIC_TIMEZONE और TZ को अपने अनुसार सेट नहीं कर लेते।
• डाउनटाइम के बाद रन की भरपाई नहीं होती। ट्रिगर तब रजिस्टर होते हैं जब n8n शुरू होता है, इसलिए कंटेनर के रीस्टार्ट होने के दौरान जो शेड्यूल समय निकल गया, वह बाद में नहीं चलता। अगला रन स्टार्टअप के बाद आने वाला अगला निर्धारित समय होता है।
• वर्कफ़्लो आपके लिए डीएक्टिवेट कर दिया गया था। N8N_WORKFLOW_AUTODEACTIVATION_ENABLED डिफ़ॉल्ट रूप से बंद रहता है, और जब यह चालू होता है, तो बार-बार क्रैश होने वाला वर्कफ़्लो अनपब्लिश हो जाता है, जिसके बाद यह बिल्कुल वैसा ही दिखता है जैसे इसे किसी ने कभी सक्रिय ही नहीं किया था।

निष्पादन सूची खोलें और उस वर्कफ़्लो के लिए फ़िल्टर करें। यदि कोई एंट्री विफल (failed) दिखती है, तो यह वर्कफ़्लो की समस्या है। यदि यह उसी बॉक्स पर होस्ट की गई किसी अन्य सर्विस के विरुद्ध 429 एरर के साथ विफल हुआ है, तो यह सीमा उस सर्विस की है न कि n8n की, और the SearXNG 429 walkthrough दिखाता है कि कैसे इसके स्वयं के रेट लिमिटर को उन इंजनों से अलग पहचानें जो आपके सर्वर IP को ब्लॉक कर रहे हैं। यदि कोई एंट्री ही नहीं है, तो यह ट्रिगर की समस्या है, और ऊपर दिए गए चार कारणों की जाँच करें।

सबसे पहले क्या बदलें

1. किसी भी फाइल को एडिट करने से पहले अपने कंटेनर पर STATUS, RestartCount और OOMKilled को पढ़ें।
2. यदि कंटेनर कभी बंद नहीं हुआ है, तो प्रॉक्सी अपग्रेड हेडर और आइडल टाइमआउट को ठीक करें।
3. यदि OOMKilled 'true' है, तो अपनी इच्छा अनुसार एक कंटेनर लिमिट सेट करें, Node हीप सीलिंग को उससे नीचे रखें, और बाइनरी डेटा को filesystem पर स्विच करें।
4. यदि कुछ भी काम नहीं कर रहा है, तो जांचें कि वर्कफ़्लो सक्रिय है और इंस्टेंस का टाइमज़ोन वही है जो आपका है।

इसमें से अधिकांश कॉन्फ़िगरेशन ऐसे हैं जिन्हें आप एक बार सेट करते हैं और भूल जाते हैं, जो कि एक वर्किंग इंस्टॉलेशन के ऊपर होते हैं। यदि आप अभी भी उस इंस्टॉलेशन को तैयार कर रहे हैं, तो HTTPS के साथ Docker पर n8n का वॉकथ्रू वह आधार है जिसमें ये सेटिंग्स शामिल होनी चाहिए।

FAQ

n8n editor में container चलने के बावजूद 'connection lost' banner क्यों दिखता है?

Editor execution progress को stream करने के लिए एक WebSocket खुला रखता है। यदि आपका reverse proxy Connection: Upgrade और Upgrade: websocket headers को forward नहीं करता है, या upstream में HTTP/1.1 का उपयोग नहीं करता है, तो upgrade कभी पूरा नहीं होता है। इस स्थिति में browser बार-बार reconnect करता रहता है जबकि n8n सही ढंग से चल रहा होता है। Nginx में आपको proxy_http_version 1.1 के साथ-साथ दोनों proxy_set_header lines की आवश्यकता होती है, और एक ऐसा proxy_read_timeout चाहिए जो default 60 seconds से अधिक हो ताकि inactive tab disconnect न हो। चल रही configuration को जांचने के लिए sudo nginx -T का उपयोग करें, न कि उस file का जिसे आपने edit किया है।

मैं 'out of memory' kill और सामान्य crash के बीच अंतर कैसे करूँ?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' चलाएं और OOMKilled flag को पढ़ें। 'True' का अर्थ है कि kernel ने memory limit पार होने के कारण process को kill कर दिया है, और container log में कुछ भी उपयोगी नहीं मिलेगा क्योंकि process को लिखने का मौका ही नहीं मिला। 'False' के साथ, यदि docker logs के अंत में heap error और stack trace है, तो इसका मतलब है कि Node.js अपनी V8 heap सीमा तक पहुँच गया और खुद ही exit हो गया। NODE_OPTIONS=--max-old-space-size को अपनी container limit से नीचे सेट करें ताकि आपको दूसरा वाला failure मिले, जिसमें सबूत मौजूद रहते हैं।

क्या execution data को prune करने से disk space तुरंत खाली हो जाता है?

नहीं। EXECUTIONS_DATA_PRUNE पुरानी executions को deletion के लिए mark करता है और बाद में एक pass उन्हें हटाता है, जो EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL द्वारा निर्धारित schedule पर होता है। SQLite के मामले में, file खाली हुए pages को filesystem को वापस करने के बजाय उनका पुन: उपयोग करती है, इसलिए rows हटने के बाद भी disk पर size कुछ समय तक स्थिर रहता है। EXECUTIONS_DATA_MAX_AGE और EXECUTIONS_DATA_PRUNE_MAX_COUNT को अपनी आवश्यकतानुसार सेट करें, और तुरंत जांचने के बजाय अगले दिन देखें।

n8n के restart होने के दौरान मेरा scheduled workflow क्यों नहीं चला?

n8n process शुरू होने पर triggers को register करता है, और यह उन schedules को replay नहीं करता जो down time के दौरान due हो गए थे। इसलिए, restart loop के कारण catch-up runs के बजाय silence रहती है, और अगली execution startup के बाद के अगले निर्धारित समय पर होती है। यदि आपको ऐसी runs चाहिए जिन्हें miss नहीं किया जा सकता, तो workflow को एक external caller के माध्यम से webhook पर चलाएं, ताकि retry logic n8n के बाहर रहे।

क्या healthcheck के कारण n8n प्रतिक्रिया न देने पर restart हो जाएगा?

अपने आप नहीं। Compose healthcheck केवल container को healthy या unhealthy के रूप में mark करता है। Restart करना restart policy का काम है, इसलिए restart: unless-stopped वह है जो container के exit होने के बाद उसे वापस लाता है, और यह host reboot के बाद भी उसे वापस लाता है यदि Docker service enabled है। इसे sudo systemctl is-enabled docker के साथ confirm करें। विशेष रूप से unhealthy status पर कार्रवाई करने के लिए, आपको Docker के बाहर एक watcher की आवश्यकता होगी जो status को पढ़े और service को restart करे।