VPS پر n8n بار بار آف لائن کیوں ہوتا ہے؟

n8n آف لائن کیوں ہوتا رہتا ہے: چار خرابیاں، ایک علامت

"n8n آف لائن ہوتا رہتا ہے" ایک ایسا جملہ ہے جو چار مختلف خرابیوں کو بیان کر سکتا ہے، اور ہر خرابی کے لیے الگ اصلاح درکار ہوتی ہے۔ کنٹینر معمول کے مطابق چل رہا ہوتا ہے، لیکن editor میں connection lost کا banner دکھائی دیتا ہے۔ کنٹینر خود بخود restart ہو جاتا ہے۔ kernel زیادہ memory استعمال کرنے پر Node.js process کو ختم کر دیتا ہے۔ یا process میں کوئی خرابی نہیں ہوتی، لیکن فعال workflow کبھی trigger ہی نہیں ہوتا۔ غلط setting تبدیل کرنے سے آپ پورا ہفتہ ایسے مسئلے پر صرف کر سکتے ہیں جو حقیقت میں موجود ہی نہیں تھا۔

اس لیے کسی بھی configuration کو تبدیل کرنے سے پہلے معلوم کریں کہ آپ کو کون سی خرابی درپیش ہے۔ n8n ایک واحد Node.js process کے طور پر چلتا ہے، جو عموماً ایک Docker container کے اندر ہوتا ہے، اور اس کے سامنے ایک reverse proxy ہوتا ہے جو TLS (transport layer security) کو terminate کرتا ہے۔ ان میں سے ہر layer اپنے مخصوص طریقے سے ناکام ہو سکتی ہے، لیکن browser ان سب کے لیے ایک ہی message دکھاتا ہے۔

اس ترتیب سے تشخیص کریں

VPS (virtual private server) پر یہ commands چلائیں اور اپنی مشین سے ظاہر ہونے والی values پڑھیں۔ ان کا کسی forum thread میں موجود numbers سے موازنہ نہ کریں۔ یہاں اہم values آپ کے اپنے server کی ہیں، کسی اور کے server کی نہیں۔

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 column بتاتا ہے کہ container اپنی موجودہ حالت میں کتنے عرصے سے ہے۔ اس کا موازنہ مسئلہ شروع ہونے کے وقت سے کریں۔ اگر container banner ظاہر ہونے سے کافی پہلے سے چل رہا ہے تو n8n کبھی offline نہیں ہوا۔ خرابی آپ کے browser اور backend کے درمیان connection میں ہے۔ یہ websocket path ہے، جس کا احاطہ اگلے section میں کیا گیا ہے۔

RestartCount بتاتا ہے کہ Docker نے اس container کو کتنی بار restart کیا ہے۔ یہ number لکھ لیں، ایک منٹ انتظار کریں، پھر اسے دوبارہ پڑھیں۔ اگر آپ کے دیکھتے ہوئے number بڑھتا رہے تو یہ restart loop ہے۔ ہر restart سے فوراً پہلے کی log lines وجہ بتاتی ہیں۔

OOMKilled ایک true یا false flag ہے۔ True کا مطلب ہے کہ Linux kernel نے process کو ختم کر دیا کیونکہ وہ memory limit سے تجاوز کر گیا تھا۔ یہ limit container کی اپنی یا پوری مشین کی ہو سکتی ہے۔ یہ واحد field memory kill کو ہر دوسری قسم کے exit سے الگ کرتی ہے۔ اسی لیے اندازہ لگانے سے پہلے اسے پڑھیں۔

ExitCode وہ value ہے جس کے ساتھ آپ کا container آخری بار exit ہوا تھا۔ آپ کو ہر code کا مطلب یاد رکھنے کی ضرورت نہیں۔ اپنی value پڑھیں، پھر اسی timestamp سے docker logs کا آخری حصہ پڑھیں۔ Log tail اور out of memory flag مل کر بتاتے ہیں کہ کیا ہوا۔ ان میں سے صرف ایک پر انحصار کرنے سے غلط نتیجہ نکل سکتا ہے۔

docker stats موجودہ memory usage کو نافذ limit کے ساتھ دکھاتا ہے۔ اسے دوسرے terminal میں چلتا رہنے دیں، وہ workflow trigger کریں جس سے مسئلہ پیدا ہوتا ہے، اور failure کے دوران number کی تبدیلی دیکھیں۔

کنکشن کے ختم ہونے کا بینر عموماً آپ کے reverse proxy کی وجہ سے ظاہر ہوتا ہے

n8n editor، backend کے ساتھ ایک طویل مدت تک کھلا رہنے والا push connection برقرار رکھتا ہے تاکہ execution کی پیش رفت canvas پر stream کی جا سکے۔ پہلے سے یہ connection WebSocket ہوتا ہے، جسے N8N_PUSH_BACKEND منتخب کرتا ہے، اور اس کی default value websocket ہے۔ WebSocket کا آغاز ایک عام HTTP request سے ہوتا ہے، جس میں Connection: Upgrade اور Upgrade: websocket headers شامل ہوتے ہیں۔ server، 101 Switching Protocols کے ساتھ جواب دیتا ہے۔ اس کے بعد دونوں فریق ایک ہی TCP socket کو دونوں سمتوں میں استعمال کرتے ہیں۔

دو مسائل اس عمل کو متاثر کرتے ہیں، اور دونوں n8n کے بجائے proxy میں ہوتے ہیں۔ proxy upstream کے لیے HTTP/1.0 استعمال کرتا ہے یا upgrade headers ہٹا دیتا ہے۔ اس طرح upgrade کبھی مکمل نہیں ہوتا اور editor مسلسل reconnect کرتا رہتا ہے۔ یا upgrade کامیاب ہو جاتا ہے، لیکن بعد میں proxy socket بند کر دیتا ہے کیونکہ اس پر کچھ دیر سے کوئی traffic نہیں آیا ہوتا۔ WebSocket پر کوئی message نہ ہو تو وہ بالکل idle connection جیسا دکھائی دیتا ہے۔ دونوں صورتوں میں container صحت مند ہوتا ہے۔ بینر صرف یہ بتاتا ہے کہ browser کا channel ختم ہو گیا ہے۔

کسی چیز میں ترمیم سے پہلے browser میں اس کی تصدیق کریں۔ developer tools کھولیں، Network tab پر جائیں، WS تک filter کریں، اور editor کو reload کریں۔ push request کو 101 Switching Protocols تک پہنچ کر کھلا رہنا چاہیے۔ اگر push request عام status code واپس کرے یا ہر چند سیکنڈ بعد دوبارہ ظاہر ہو، تو مسئلہ proxy میں ہے۔

ایڈیٹر کو connected رکھنے والی nginx settings

nginx خود سے upgrade forward نہیں کرتا، جب تک آپ اسے ایسا کرنے کی ہدایت نہ دیں۔ proxy_pass default طور پر backend کے ساتھ HTTP/1.0 میں بات کرتا ہے، جبکہ Connection اور Upgrade hop-by-hop headers ہیں جنہیں nginx آگے بھیجتے وقت ہٹا دیتا ہے۔ آپ کو دونوں headers دوبارہ شامل کرنے ہوں گے۔ map block کو http context میں رکھیں، server کے اندر نہیں۔ اگر نیچے موجود server block کا باقی حصہ آپ کے لیے نیا ہے تو nginx server block کی سطر بہ سطر وضاحت میں بتایا گیا ہے کہ ہر 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 وہ line ہے جسے لوگ اکثر چھوڑ دیتے ہیں۔ اس کی default value 60 seconds ہے اور یہ upgraded WebSocket پر بھی لاگو ہوتی ہے۔ اس لیے خاموش instance میں کھلا چھوڑا گیا editor tab، آخری message گزرنے کے تقریباً ایک منٹ بعد connection کھو دیتا ہے۔ اسے بڑھانے سے وہ banner ختم ہو جاتا ہے جو کھلے چھوڑے گئے tab پر واپس آنے کے وقت دکھائی دیتا ہے۔

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

nginx -T صرف ایک file کے بجائے مکمل running configuration دکھاتا ہے، اس لیے اس سے ثابت ہو جاتا ہے کہ آپ کی edit واقعی load ہو چکی ہے۔ اگر configuration ایسی file میں موجود ہو جسے کوئی include line شامل نہیں کرتی، تو درست fix بھی بے اثر دکھائی دے گا۔

اس کے بعد n8n کو بتائیں کہ وہ proxy کے پیچھے چل رہا ہے، کیونکہ یہ انہی values سے URLs بناتا ہے۔

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 کی default value 0 ہے۔ اس کا مطلب ہے کہ n8n connecting address کو client address سمجھتا ہے اور X-Forwarded-For کو نظر انداز کرتا ہے۔ اسے container کے سامنے موجود proxies کی تعداد پر set کریں۔ August 2026 تک N8N_WEBHOOK_URL موجودہ نام ہے، جبکہ پرانا WEBHOOK_URL اب بھی کام کرتا ہے، لیکن startup کے وقت deprecation warning دکھاتا ہے۔

Traefik WebSocket کو forward کرتا ہے، پھر timeout کر دیتا ہے

Traefik، WebSocket upgrade کو کسی middleware اور اضافی labels کے بغیر forward کرتا ہے۔ اس لیے Traefik کا وہ صارف جو یہ banner دیکھتا ہے، عموماً missing header کے بجائے timeout کا سامنا کر رہا ہوتا ہے۔ متعلقہ settings entryPoint میں موجود ہیں۔ August 2026 تک Traefik v3 میں idleTimeout کی default قدر 180 seconds اور readTimeout کی default قدر 60 seconds ہے۔

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

Caddy، reverse_proxy میں upgrade خودکار طور پر handle کرتا ہے اور اس کے لیے کسی directive کی ضرورت نہیں ہوتی۔ اگر آپ proxy میں بالکل تبدیلی نہیں کر سکتے، کیونکہ اس کا انتظام کسی دوسرے شخص کے پاس ہے، تو N8N_PUSH_BACKEND=sse کے ذریعے push channel تبدیل کریں۔ SSE (server-sent events) ایک معمول کا HTTP response ہے جسے کھلا رکھا جاتا ہے۔ اس لیے یہ ایسے proxy کے ذریعے بھی جاری رہتا ہے جو upgrades مسترد کرتا ہے، تاہم بہت کم idle timeout اسے پھر بھی منقطع کر دیتا ہے۔ Proxy کا انتخاب خود ایک الگ فیصلہ ہے، اور nginx، Caddy اور Traefik کا تقابلی جائزہ میں بتایا گیا ہے کہ ہر proxy کو operate کرنے کی کیا لاگت ہوتی ہے۔

جب container واقعی طور پر restart ہو رہا ہو

اگر RestartCount بڑھ رہا ہے تو container ناکام ہو رہا ہے اور Docker اسے دوبارہ شروع کر رہا ہے۔ ہر restart کے مقابل log timestamps رکھیں اور دیکھیں کہ اس سے فوراً پہلے کیا ہوا تھا۔ تقریباً تمام صورتوں کی 4 وجوہات ہوتی ہیں: startup روک دینے والی configuration error، ایسا database جس تک n8n رسائی نہیں کر سکتا، چلتے ہوئے process کا crash، یا memory kill۔

سب سے پہلے volume دیکھیں، کیونکہ permissions کی خرابی خاموشی سے مسئلہ پیدا کرتی ہے۔ official image unprivileged user node کے طور پر چلتی ہے اور اپنا data /home/node/.n8n میں رکھتی ہے۔ root کے ذریعے بنایا گیا bind mount اس user کے لیے writable نہیں ہوتا۔ اس لیے process ہر بار startup پر ختم ہو جاتا ہے، اور restart policy اسے loop کے پیچھے چھپا دیتی ہے۔

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 اسے درست ownership کے ساتھ بناتا ہے۔ اگر bind mount درکار ہو تو chown host directory کو اس numeric user id کے مطابق set کریں جو پہلے command نے دکھائی تھی۔ host اور container کے درمیان ownership mapping کو ایک بار سمجھ لینا مفید ہے، اور PUID اور PGID کی وضاحت میں بتایا گیا ہے کہ یہ images فائلیں لکھنے والے user کا تعین کیسے کرتی ہیں۔

وہ Out of Memory kill جو crash جیسا دکھائی دیتا ہے

ایک n8n process کے اوپر memory کی دو الگ حدیں ہوتی ہیں، اور دونوں مختلف طریقے سے fail ہوتی ہیں۔ Container control group کی limit kernel نافذ کرتا ہے: اسے عبور کرتے ہی process فوراً kill ہو جاتا ہے، کچھ بھی لکھنے کا موقع نہیں ملتا، اور OOMKilled کی قدر true ہوتی ہے۔ V8 heap limit Node.js کے اندر نافذ ہوتی ہے: اسے عبور کرنے پر Node ایک heap error اور stack trace کے ساتھ خود exit ہو جاتا ہے، اس لیے OOMKilled کی قدر false ہوتی ہے۔ Browser سے دونوں صورتیں یکساں دکھائی دیتی ہیں۔ docker inspect میں یہ دونوں صرف ایک field کے فرق پر ہوتی ہیں۔

Node heap کی ceiling کو container limit سے کم رکھیں۔ اگر heap ceiling دونوں میں زیادہ ہو تو V8 اس مقام سے آگے بھی allocation جاری رکھتا ہے جہاں kernel مداخلت کرتا ہے۔ اس طرح اس کا garbage collector اپنی limit تک نہیں پہنچتا، اور آپ کو ہمیشہ زیادہ سخت failure ملتی ہے جسے پڑھنے کے لیے کوئی log موجود نہیں ہوتا۔

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 میں دستیاب اصل memory کے مطابق منتخب کریں، اور database، proxy اور operating system کے لیے گنجائش باقی رکھیں۔ docker stats --no-stream موجودہ استعمال کو نافذ limit کے ساتھ دکھاتا ہے، اس لیے آپ تصدیق کر سکتے ہیں کہ آپ کی لکھی ہوئی limit وہی ہے جو Docker نے apply کی ہے۔ Compose memory limits کیسے apply ہوتی ہیں میں بتایا گیا ہے کہ متعدد limits set ہونے پر کون سی key مؤثر ہوتی ہے۔

Execution data is what grows underneath you

ایک execution جاری رہنے کے دوران ہر node کا output اپنے اندر رکھتا ہے، اور پھر n8n یہ data محفوظ کرتا ہے۔ اس کے دو نتائج نکلتے ہیں۔ ایک run کی peak memory اس data کے سب سے بڑے batch سے متعین ہوتی ہے جسے آپ اس میں سے گزارتے ہیں۔ اس لیے ایک workflow جو بیک وقت دس ہزار rows handle کرتا ہے، اسی workflow سے مختلف program ہے جو ایک وقت میں دو سو rows handle کرتا ہے۔ محفوظ شدہ copy اس وقت تک بڑھتی رہتی ہے جب تک کوئی اسے delete نہ کر دے۔

Pruning دوسرے مسئلے کو حل کرتی ہے۔ August 2026 تک defaults یہ ہیں: pruning enabled ہے، EXECUTIONS_DATA_MAX_AGE کی قدر 336 hours (14 days) ہے، اور EXECUTIONS_DATA_PRUNE_MAX_COUNT کی قدر 10000 ہے۔ SQLite استعمال کرنے والے چھوٹے VPS کے لیے یہ قدریں کافی فراخ ہیں، کیونکہ ہر چیز ایک ہی file میں محفوظ ہوتی ہے اور editor فراہم کرنے والے اسی process کو اسے 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 ہے۔ یہ failed executions کو debugging کے لیے محفوظ رکھتی ہے اور successful executions کو حذف کر دیتی ہے۔ یہ فیصلہ جان بوجھ کر کریں، کیونکہ اگر کسی workflow نے error ظاہر کیے بغیر غلط output پیدا کیا تو پھر آپ کے پاس معائنے کے لیے کچھ نہیں بچے گا۔ Pruning پہلے rows کو deleted نشان زد کرتی ہے اور بعد کے pass میں انہیں حذف کرتی ہے۔ SQLite خالی ہونے والے pages کو واپس کرنے کے بجائے دوبارہ استعمال کرتا ہے، اس لیے setting تبدیل کرتے ہی disk پر موجود file کا حجم کم نہیں ہوتا۔

محفوظ شدہ total کے بجائے peak کم کرنے کے لیے ہر run میں کم data منتقل کریں۔ بڑے jobs کو ایسے sub-workflows میں تقسیم کریں جو parent کو چھوٹے results واپس کریں، Loop Over Items node کے ذریعے batch بنائیں، اور مکمل datasets کو Code node سے باہر رکھیں۔

بائنری فائلیں میموری کے ذریعے منتقل نہیں ہونی چاہییں

N8N_DEFAULT_BINARY_DATA_MODE کی default قدر default ہے، جس سے بائنری ڈیٹا چلنے والی execution کی memory میں رکھا جاتا ہے۔ node کی download کی ہوئی ہر فائل، اور اگلے node کو دی جانے والی ہر copy، run ختم ہونے تک وہیں رہتی ہے۔ چند بڑی attachments حاصل کرنے والا ایک workflow process کو اس حد سے آگے لے جا سکتا ہے جس کے قریب عام JSON کام بھی نہیں پہنچتا۔ اسی لیے crash مخصوص workflow کے بعد ہوتا ہے، نہ کہ کسی مقررہ وقت کے بعد۔

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem کے ساتھ بائنری ڈیٹا N8N_BINARY_DATA_STORAGE_PATH کے تحت لکھا جاتا ہے۔ یہ default طور پر n8n user folder کے اندر ہوتا ہے، اس لیے ڈیٹا اسی volume پر محفوظ ہوتا ہے جس پر باقی سب کچھ موجود ہے۔ تبدیل کرنے سے پہلے تصدیق کریں کہ volume میں کافی جگہ موجود ہے۔ N8N_PAYLOAD_SIZE_MAX آنے والے webhook payload کی زیادہ سے زیادہ حد MiB (mebibytes) میں مقرر کرتا ہے اور اس کی default قدر 16 ہے۔ اسے بڑھانے سے بڑی requests موصول ہو سکتی ہیں، لیکن اس کے نتیجے میں memory کا جو اضافی استعمال ہوگا، اسے آپ قبول کر رہے ہوں گے۔

جو کچھ بھی اسی host پر دیگر وسائل استعمال کر رہا ہے، وہ اسی RAM کے لیے مقابلہ کرتا ہے۔ اگر OOM kills اس وقت شروع ہوئے جب آپ نے database container شامل کیا، تو database کو Docker میں یا host پر چلانا وہ trade-off ہے جو اب آپ کر رہے ہیں۔

ری اسٹارٹ پالیسی اور reboot کے بعد دوبارہ شروع ہونا

جس container کے لیے restart policy مقرر نہ ہو، وہ exit ہونے کے بعد بند رہتا ہے، اور host کے reboot ہونے کے بعد بھی دوبارہ شروع نہیں ہوتا۔ restart: unless-stopped دونوں صورتوں میں اسے دوبارہ شروع کرتا ہے، لیکن آپ کے ہاتھ سے روکے گئے container کا احترام برقرار رکھتا ہے۔ restart: always جان بوجھ کر روکے گئے container کو بھی اس وقت دوبارہ شروع کرتا ہے جب Docker اگلی بار شروع ہو۔

n8n ایک health endpoint فراہم کرتا ہے، جس کا نام N8N_ENDPOINT_HEALTH ہے اور جو default طور پر healthz ہوتا ہے۔ پہلے اسے host سے check کریں تاکہ تصدیق ہو جائے کہ آپ کے instance پر path درست ہے۔

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

healthcheck اکیلے کسی چیز کو دوبارہ شروع نہیں کرتا۔ Compose container کو unhealthy قرار دے کر وہیں رک جاتا ہے۔ اس لیے healthcheck کے مؤثر ہونے کے لیے اس کے ساتھ restart policy یا کوئی external watcher درکار ہوتا ہے۔ ایسا healthcheck لکھنا جو واقعی کارروائی کرے اور reboot کے بعد stack کو دوبارہ شروع کرنا اس عمل کے دونوں حصوں کی وضاحت کرتے ہیں۔

ایسا workflow جو n8n کے درست ہونے کے باوجود کبھی چلتا ہی نہیں

اس صورت میں کوئی banner ظاہر نہیں ہوتا اور نہ ہی restart ہوتا ہے۔ container چل رہا ہوتا ہے، editor کام کرتا ہے، لیکن جس run کی آپ توقع کر رہے تھے وہ executions list میں موجود نہیں ہوتا۔ اس کی زیادہ تر وجوہات یہ چار ہیں۔

• workflow active نہیں ہے۔ Schedule Trigger صرف production path پر چلتا ہے، اس لیے canvas میں اس کی testing کرنے سے کوئی schedule نہیں بنتا۔
• timezone آپ کے مقامی timezone کے مطابق نہیں ہے۔ GENERIC_TIMEZONE کی default قدر America/New_York ہے، اس لیے 09:00 کے لیے مقرر schedule اسی zone کے مطابق 09:00 پر چلتا ہے، جب تک آپ GENERIC_TIMEZONE اور TZ کو اپنی timezone پر set نہ کر دیں۔
• downtime کے دوران رہ جانے والے runs بعد میں خودکار طور پر نہیں چلتے۔ n8n شروع ہوتے وقت triggers register کرتا ہے، اس لیے container restart ہونے کے دوران due ہونے والا schedule تاخیر سے نہیں چلتا۔ startup کے بعد اگلا run اگلے مقررہ وقت پر ہوتا ہے۔
• workflow آپ کی طرف سے deactivate ہو گیا ہے۔ N8N_WORKFLOW_AUTODEACTIVATION_ENABLED default طور پر بند ہوتا ہے۔ فعال ہونے کی صورت میں مسلسل crash ہونے والا workflow unpublished ہو جاتا ہے، جس کے بعد یہ بالکل ایسا دکھائی دیتا ہے جیسے اسے کبھی activate ہی نہ کیا گیا ہو۔

executions list کھولیں اور اسے اسی workflow کے مطابق filter کریں۔ اگر failed entry موجود ہے تو مسئلہ workflow میں ہے۔ اگر یہ اسی machine پر host کی گئی کسی دوسری service کو بھیجے گئے request پر 429 کے ساتھ failed ہوئی ہے تو limit n8n کے بجائے اسی service کی ہے۔ SearXNG کے 429 walkthrough میں بتایا گیا ہے کہ اس کے اپنے rate limiter اور آپ کے server IP کو block کرنے والے engines میں فرق کیسے کیا جائے۔ اگر کوئی entry موجود ہی نہیں تو مسئلہ trigger میں ہے، اور اوپر دی گئی چار وجوہات سے تلاش شروع کریں۔

پہلے کیا تبدیل کریں

1. کسی بھی فائل میں ترمیم کرنے سے پہلے اپنے container پر STATUS، RestartCount اور OOMKilled پڑھیں۔
2. اگر container کبھی بند نہیں ہوا تو proxy upgrade headers اور idle timeout درست کریں۔
3. اگر OOMKilled درست ہے تو اپنی ضرورت کے مطابق container limit مقرر کریں، Node heap ceiling اس سے کم رکھیں، اور binary data کو filesystem میں منتقل کریں۔
4. اگر کچھ بھی trigger نہیں ہوا تو تصدیق کریں کہ workflow فعال ہے اور instance کا timezone آپ کے timezone کے مطابق ہے۔

اس کا زیادہ تر حصہ ایسی configuration پر مشتمل ہے جسے working install کے اوپر ایک مرتبہ مقرر کرنے کے بعد دوبارہ تبدیل کرنے کی ضرورت نہیں پڑتی۔ اگر آپ ابھی وہ install تیار کر رہے ہیں تو HTTPS کے ساتھ Docker پر n8n چلانے کی رہنمائی وہ بنیادی مرحلہ ہے جس سے یہ settings متعلق ہیں۔

FAQ

n8n کا container چلنے کے باوجود editor میں 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 سے زیادہ ہونی چاہیے، تاکہ خاموش tab کا connection بند نہ ہو۔ چل رہی configuration کو sudo nginx -T سے check کریں، نہ کہ اس file سے جس میں آپ نے ترمیم کی تھی۔

memory ختم ہونے سے ہونے والے kill اور عام crash میں فرق کیسے معلوم کیا جائے؟

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' چلائیں اور OOMKilled flag پڑھیں۔ True کا مطلب ہے کہ kernel نے memory limit سے تجاوز کرنے پر process کو kill کیا۔ ایسی صورت میں container log میں مفید معلومات نہیں ہوں گی، کیونکہ process کو log لکھنے کا موقع ہی نہیں ملا۔ اگر False ہو، اور docker logs کے آخر میں heap error اور stack trace موجود ہو، تو اس کا مطلب ہے کہ Node.js اپنی V8 heap ceiling تک پہنچ گیا اور خود exit ہو گیا۔ NODE_OPTIONS=--max-old-space-size کو اپنے container limit سے کم set کریں، تاکہ دوسری قسم کی failure سامنے آئے۔ یہی وہ failure ہے جو evidence چھوڑتی ہے۔

کیا execution data کو prune کرنے سے disk space فوراً خالی ہو جاتی ہے؟

نہیں۔ EXECUTIONS_DATA_PRUNE پرانی executions کو deletion کے لیے mark کرتا ہے، اور بعد کا pass انہیں حذف کرتا ہے۔ یہ pass EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL کے مقرر کردہ schedule کے مطابق چلتا ہے۔ SQLite میں file freed pages کو filesystem کو واپس کرنے کے بجائے دوبارہ استعمال بھی کرتی ہے۔ اس لیے rows حذف ہونے کے بعد کچھ وقت تک disk پر file کا size تبدیل نہیں ہوتا۔ EXECUTIONS_DATA_MAX_AGE اور EXECUTIONS_DATA_PRUNE_MAX_COUNT کو اپنے server کے مطابق values پر set کریں، پھر فوراً دوبارہ check کرنے کے بجائے اگلے دن check کریں۔

n8n کے restart ہونے کے دوران میرا scheduled workflow کیوں نہیں چلا؟

n8n process start ہونے پر triggers register کرتا ہے۔ یہ ان schedules کو دوبارہ run نہیں کرتا جو process کے down ہونے کے دوران due ہو گئے تھے۔ اس لیے restart loop کے نتیجے میں catch-up runs کا ایک ساتھ سلسلہ شروع نہیں ہوتا، بلکہ startup کے بعد اگلا execution اگلی due time پر ہوتا ہے۔ اگر ایسے runs ضروری ہیں جنہیں miss نہیں کیا جا سکتا، تو workflow کو webhook hit کرنے والے external caller سے چلائیں۔ اس طرح retry logic n8n کے باہر رہتی ہے۔

کیا healthcheck، n8n کے response دینا بند کرنے پر اسے 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 سے اس کی تصدیق کریں۔ صرف unhealthy status پر کارروائی کرنے کے لیے Docker کے باہر ایک watcher درکار ہے، جو status پڑھ کر service کو restart کرے۔