Mengapa n8n Sering Terputus di VPS Anda?

Mengapa n8n sering terputus: empat kegagalan, satu simptom

"n8n sering terputus" ialah satu ayat yang merangkumi empat kegagalan berbeza, dan setiap satunya memerlukan penyelesaian yang berlainan. Editor memaparkan sepanduk sambungan terputus (connection lost) sedangkan kontena berjalan seperti biasa. Kontena tersebut dimulakan semula dengan sendiri. Kernel menamatkan proses Node.js kerana penggunaan memori yang terlalu tinggi. Atau, tiada apa-apa yang salah dengan proses tersebut, namun aliran kerja (workflow) yang aktif tidak pernah dicetuskan. Jika anda menukar tetapan yang salah, anda akan menghabiskan hujung minggu untuk masalah yang sebenarnya tidak wujud.

Oleh itu, kenal pasti kegagalan yang anda hadapi sebelum mengubah sebarang konfigurasi. n8n berjalan sebagai satu proses Node.js tunggal, biasanya di dalam satu kontena Docker, di sebalik reverse proxy yang melakukan TLS (transport layer security) termination. Setiap lapisan tersebut boleh gagal dengan cara tersendiri, namun pelayar web melaporkan kesemuanya dengan mesej yang sama.

Diagnosis mengikut urutan

Jalankan perintah ini pada VPS (virtual private server) dan baca nilai yang dipaparkan oleh mesin anda sendiri. Jangan bandingkan nilai tersebut dengan angka daripada perbincangan forum. Nilai yang penting di sini ialah nilai yang menerangkan pelayan anda, bukan pelayan orang lain.

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

Lajur STATUS daripada docker ps -a menunjukkan tempoh masa kontena berada dalam status semasanya. Bandingkan tempoh tersebut dengan saat masalah anda bermula. Jika kontena telah berjalan sejak sebelum banner ralat muncul, bermakna n8n tidak pernah terhenti. Perkara yang terputus ialah sambungan antara pelayar anda dengan backend, iaitu laluan websocket yang dibincangkan dalam bahagian seterusnya.

RestartCount ialah bilangan kali Docker telah memulakan semula kontena ini. Catatkan angka tersebut, tunggu seminit, kemudian baca semula. Angka yang meningkat semasa anda memerhati menunjukkan gelung mulakan semula (restart loop), dan baris log sejurus sebelum setiap mulakan semula mengandungi puncanya.

OOMKilled ialah flag benar atau palsu (true atau false). True bermaksud kernel Linux telah mematikan proses tersebut kerana ia melebihi had memori, sama ada had kontena itu sendiri atau had keseluruhan mesin. Medan tunggal itu membezakan antara penamatan akibat memori dengan jenis penamatan lain, itulah sebabnya anda perlu membacanya sebelum membuat andaian.

ExitCode ialah kod keluar terakhir kontena anda. Anda tidak perlu menghafal maksud setiap kod. Baca kod anda, kemudian baca bahagian akhir docker logs daripada cap masa yang sama. Bahagian akhir log dan flag memori bersama-sama memberitahu anda apa yang berlaku, dan mana-mana satu daripadanya secara berasingan boleh mengelirukan anda.

docker stats menunjukkan penggunaan memori secara langsung di samping had yang dikuatkuasakan. Biarkan ia berjalan dalam terminal kedua, cetuskan aliran kerja (workflow) yang menyebabkan masalah, dan perhatikan perubahan angka tersebut semasa kegagalan berlaku.

Banner sambungan terputus biasanya berpunca daripada reverse proxy anda

Editor n8n mengekalkan satu sambungan push jangka hayat panjang ke backend supaya ia boleh menstrim kemajuan pelaksanaan ke kanvas. Secara lalai, sambungan tersebut ialah WebSocket, iaitu apa yang dipilih oleh N8N_PUSH_BACKEND, dan nilai lalaiannya ialah websocket. WebSocket bermula sebagai permintaan HTTP biasa yang membawa header Connection: Upgrade dan Upgrade: websocket. Pelayan menjawab 101 Switching Protocols, dan mulai saat itu kedua-dua pihak menggunakan soket TCP yang sama dalam kedua-dua arah.

Dua perkara menyebabkan perkara ini gagal, dan kedua-duanya berlaku pada proksi dan bukannya dalam n8n. Proksi berkomunikasi menggunakan HTTP/1.0 ke arah upstream atau membuang header upgrade, jadi proses naik taraf tidak pernah berlaku dan editor akan cuba menyambung semula selama-lamanya. Atau, proses naik taraf berjaya tetapi proksi kemudian menutup soket kerana ia tidak aktif, memandangkan WebSocket tanpa sebarang mesej kelihatan sama seperti sambungan melahu. Dalam kedua-dua kes, kontena tersebut berada dalam keadaan sihat. Banner tersebut adalah cara pelayar memberitahu anda bahawa ia telah kehilangan saluran komunikasinya.

Sahkan perkara ini dalam pelayar sebelum mengubah apa-apa. Buka alat pembangun (developer tools), pergi ke tab Network, tapis kepada WS, dan muat semula editor. Permintaan push tersebut sepatutnya mencapai 101 Switching Protocols dan kekal terbuka. Permintaan push yang mengembalikan kod status biasa, atau permintaan yang muncul semula setiap beberapa saat, menunjukkan masalah pada proksi.

Tetapan nginx yang mengekalkan sambungan editor

nginx tidak memajukan naik taraf (upgrade) melainkan anda memintanya. proxy_pass bercakap menggunakan HTTP/1.0 kepada backend secara lalai, manakala Connection dan Upgrade ialah header hop-by-hop yang dibuang oleh nginx semasa proses penghantaran. Anda perlu memasukkan kedua-duanya semula. Blok map diletakkan dalam konteks http, bukan di dalam server. Jika bahagian blok pelayan di bawah tidak biasa bagi anda, panduan baris demi baris blok pelayan nginx menerangkan fungsi setiap direktif tersebut.

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 ialah baris yang sering ditinggalkan oleh pengguna. Nilai lalainya ialah 60 saat dan ia juga terpakai pada WebSocket yang telah dinaik taraf, jadi tab editor yang dibiarkan terbuka pada instans yang tidak aktif akan terputus sambungan kira-kira seminit selepas mesej terakhir dihantar. Meningkatkan nilai ini akan membetulkan sepanduk yang muncul apabila anda kembali ke tab yang dibiarkan terbuka.

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

nginx -T mencetak keseluruhan konfigurasi yang sedang berjalan dan bukannya satu fail sahaja, jadi ia membuktikan suntingan anda benar-benar telah dimuatkan. Konfigurasi yang berada dalam fail tetapi tidak diambil oleh mana-mana baris include adalah sebab mengapa pembetulan yang betul kelihatan tidak memberikan sebarang kesan.

Kemudian, maklumkan kepada n8n bahawa ia berada di belakang proksi, kerana ia membina URL berdasarkan nilai-nilai ini.

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 ditetapkan kepada 0 secara lalai, yang bermaksud n8n menganggap alamat penyambung sebagai alamat klien dan mengabaikan X-Forwarded-For. Tetapkan ia kepada bilangan proksi yang berada di hadapan kontena. Sehingga Ogos 2026, N8N_WEBHOOK_URL ialah nama semasa dan WEBHOOK_URL yang lebih lama masih berfungsi walaupun memaparkan amaran penamatan (deprecation warning) semasa permulaan.

Traefik memajukan WebSocket, kemudian menamatkan sambungannya

Traefik memajukan naik taraf WebSocket tanpa middleware dan tanpa label tambahan, jadi pengguna Traefik yang melihat sepanduk ini biasanya mengalami tamat masa (timeout) dan bukannya pengepala yang hilang. Pelarasan tetapan dilakukan pada entryPoint. Setakat Ogos 2026 dalam Traefik v3, idleTimeout ditetapkan secara lalai kepada 180 saat dan readTimeout ditetapkan secara lalai kepada 60 saat.

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

Caddy mengendalikan naik taraf secara automatik dalam reverse_proxy dan tidak memerlukan arahan khusus untuknya. Jika anda tidak boleh mengubah proksi langsung kerana ia dikendalikan oleh pihak lain, tukar saluran tolak (push channel) dengan N8N_PUSH_BACKEND=sse. SSE (server-sent events) merupakan respons HTTP biasa yang dibiarkan terbuka, jadi ia boleh bertahan melalui proksi yang menolak naik taraf, walaupun tamat masa melahu (idle timeout) yang agresif masih boleh memutuskannya. Pemilihan proksi itu sendiri adalah keputusan yang berasingan, dan perbandingan antara nginx, Caddy dan Traefik merangkumi kos operasi bagi setiap satu.

Apabila kontena benar-benar dimulakan semula

Jika RestartCount meningkat, kontena tersebut gagal dan Docker cuba memulakannya semula. Selaraskan cap masa log dengan setiap permulaan semula dan baca mesej yang muncul serta-merta sebelumnya. Empat punca merangkumi hampir semua kes: ralat konfigurasi yang menghentikan permulaan, pangkalan data yang tidak dapat dicapai oleh n8n, kegagalan sistem (crash) semasa berjalan, dan penamatan akibat kehabisan memori (memory kill).

Mulakan dengan volum, kerana isu keizinan (permissions) sering tidak disedari. Imej rasmi berjalan sebagai pengguna tanpa keistimewaan node dan menyimpan datanya dalam /home/node/.n8n. Bind mount yang dicipta oleh root tidak boleh ditulis oleh pengguna tersebut, jadi proses itu mati pada setiap permulaan dan polisi restart menyembunyikannya di sebalik gelung.

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

Volum bernama (named volume) mengelakkan masalah ini sepenuhnya, kerana Docker menciptanya dengan pemilikan yang betul. Jika anda memerlukan bind mount, chown direktori hos kepada ID pengguna berangka yang dicetak oleh arahan pertama. Pemetaan pemilikan antara hos dan kontena perlu difahami sekali sahaja, dan penjelasan PUID dan PGID merangkumi cara imej-imej ini menentukan siapa yang menulis fail tersebut.

OOM kill yang kelihatan seperti ranap

Terdapat dua had memori berasingan di atas proses n8n, dan kedua-duanya gagal dengan cara yang berbeza. Had kumpulan kawalan (control group) kontena dikuatkuasakan oleh kernel: jika had ini dilampaui, proses akan dimatikan serta-merta tanpa peluang untuk menulis apa-apa, dan OOMKilled akan terbaca sebagai benar (true). Had heap V8 dikuatkuasakan di dalam Node.js: jika had ini dilampaui, Node akan mengeluarkan ralat heap berserta stack trace dan keluar dengan sendirinya, maka OOMKilled akan terbaca sebagai palsu (false). Dari pelayar web, kedua-dua ralat ini kelihatan sama. Dari docker inspect, kedua-duanya hanya dipisahkan oleh satu medan.

Tetapkan had heap Node di bawah had kontena. Jika had heap lebih tinggi daripada had kontena, V8 akan terus membuat peruntukan memori melepasi titik di mana kernel bertindak, menyebabkan pengutip sampah (garbage collector) tidak pernah mencapai hadnya sendiri dan anda akan sentiasa mendapat kegagalan yang lebih drastik tanpa log untuk dibaca.

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>

Pilih kedua-dua nombor berdasarkan kapasiti sebenar VPS anda, dengan memberi ruang untuk pangkalan data, proksi, dan sistem pengendalian. docker stats --no-stream mencetak penggunaan semasa di sebelah had yang berkuat kuasa, supaya anda boleh menyemak sama ada had yang anda tulis adalah had yang digunakan oleh Docker. Bagaimana had memori Compose digunakan menjelaskan kunci mana yang diutamakan apabila beberapa had ditetapkan.

Data pelaksanaan adalah perkara yang berkembang di bawah anda

Satu pelaksanaan menyimpan output setiap nod semasa proses berjalan, dan n8n kemudian menyimpan data tersebut. Dua akibat akan berlaku. Memori puncak bagi satu larian ditentukan oleh kelompok data terbesar yang anda hantar melaluinya, jadi aliran kerja yang mengendalikan sepuluh ribu baris sekaligus adalah program yang berbeza daripada aliran kerja sama yang mengendalikan dua ratus baris pada satu masa. Salinan yang disimpan pula akan terus berkembang sehingga sesuatu memadamkannya.

Pruning menangani masalah kedua. Setakat Ogos 2026, tetapan lalai adalah pruning diaktifkan, EXECUTIONS_DATA_MAX_AGE pada 336 jam (14 hari) dan EXECUTIONS_DATA_PRUNE_MAX_COUNT pada 10000. Ini adalah nilai yang mencukupi untuk VPS kecil yang menjalankan SQLite, di mana satu fail menyimpan segala-galanya dan proses yang sama yang menyajikan editor perlu membaca serta menulisnya.

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 ialah tetapan agresif. Ia menyimpan pelaksanaan yang gagal untuk tujuan penyahpepijatan dan membuang pelaksanaan yang berjaya. Tentukan perkara ini dengan sengaja, kerana aliran kerja yang menghasilkan output salah tanpa mencetuskan ralat tidak akan meninggalkan apa-apa untuk anda periksa. Pruning juga menandakan baris sebagai dipadam terlebih dahulu dan mengeluarkannya pada laluan kemudian, dan SQLite menggunakan semula halaman yang dikosongkan dan bukannya memulangkannya, jadi fail pada cakera tidak mengecil sebaik sahaja anda menukar tetapan tersebut.

Untuk mengurangkan puncak dan bukannya jumlah keseluruhan yang disimpan, pindahkan data yang lebih sedikit bagi setiap larian. Pecahkan tugasan besar kepada sub-aliran kerja yang mengembalikan hasil kecil kepada induk, lakukan kelompok dengan nod Loop Over Items, dan elakkan menyimpan keseluruhan set data di dalam nod Code.

Fail binari tidak sepatutnya melalui memori

N8N_DEFAULT_BINARY_DATA_MODE ditetapkan secara lalai kepada default, yang menyimpan data binari dalam memori pelaksanaan yang sedang berjalan. Setiap fail yang dimuat turun oleh nod, dan setiap salinan yang diberikan kepada nod seterusnya, kekal di situ sehingga proses tamat. Satu aliran kerja yang mengambil beberapa lampiran besar boleh menolak proses melepasi had yang tidak pernah dicapai oleh kerja JSON biasa, itulah sebabnya kegagalan berlaku selepas aliran kerja tertentu dan bukannya berdasarkan masa.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

Dengan filesystem, data binari ditulis di bawah N8N_BINARY_DATA_STORAGE_PATH, yang secara lalai berada di dalam folder pengguna n8n dan oleh itu ditempatkan pada volum yang sama dengan segala-galanya. Pastikan volum tersebut mempunyai ruang sebelum anda bertukar. N8N_PAYLOAD_SIZE_MAX menetapkan muatan webhook masuk terbesar dalam MiB (mebibytes) dan ditetapkan kepada 16 secara lalai. Meningkatkannya membolehkan permintaan yang lebih besar masuk, dan itu merupakan kos memori yang anda pilih untuk terima.

Apa sahaja yang berkongsi pelayan tersebut akan bersaing untuk RAM yang sama. Jika pembunuhan OOM bermula apabila anda menambah kontena pangkalan data, menjalankan pangkalan data dalam Docker atau pada hos ialah pertukaran yang anda lakukan sekarang.

Dasar mulakan semula, dan kembali selepas but semula

Kontena tanpa dasar mulakan semula akan kekal mati selepas ia berhenti, dan selepas hos but semula. restart: unless-stopped akan memulakannya semula dalam kedua-dua keadaan sambil tetap menghormati kontena yang anda hentikan secara manual. restart: always juga akan memulakan semula kontena yang anda hentikan dengan sengaja, sebaik sahaja Docker bermula semula.

n8n menyediakan titik akhir kesihatan, yang dinamakan oleh N8N_ENDPOINT_HEALTH, yang secara lalai adalah healthz. Semak titik akhir ini daripada hos terlebih dahulu supaya anda tahu laluan tersebut adalah betul pada instans anda.

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

Healthcheck sahaja tidak akan memulakan semula apa-apa. Compose menandakan kontena sebagai tidak sihat dan berhenti di situ, jadi healthcheck memerlukan dasar mulakan semula atau pemerhati luaran di sampingnya untuk memberikan sebarang kesan. Menulis healthcheck yang benar-benar bertindak dan memastikan stack bermula semula selepas but semula merangkumi kedua-dua bahagian tersebut.

Aliran kerja yang tidak pernah berjalan sedangkan n8n berfungsi dengan baik

Keadaan ini tidak menghasilkan sebarang sepanduk atau mulakan semula. Kontena sedang berjalan, editor berfungsi, dan pelaksanaan yang anda jangkakan tiada dalam senarai pelaksanaan. Empat punca menyumbang kepada kebanyakan kes ini.

• Aliran kerja tidak aktif. Schedule Trigger hanya berjalan pada laluan pengeluaran (production), jadi mengujinya dalam kanvas tidak menjadualkan apa-apa.
• Zon waktu bukan milik anda. GENERIC_TIMEZONE menggunakan America/New_York sebagai lalai, jadi jadual yang ditetapkan untuk 09:00 akan berjalan pada 09:00 dalam zon waktu tersebut sehingga anda menetapkan GENERIC_TIMEZONE dan TZ kepada zon waktu anda sendiri.
• Waktu henti tidak diganti kemudian. Pencetus (trigger) didaftarkan apabila n8n bermula, jadi jadual yang sepatutnya berjalan semasa kontena sedang dimulakan semula tidak akan berjalan lewat. Pelaksanaan seterusnya adalah pada waktu yang dijadualkan selepas permulaan sistem.
• Aliran kerja dinyahaktifkan untuk anda. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED dimatikan secara lalai, dan apabila ia dihidupkan, aliran kerja yang kerap terhenti (crash) akan dinyahterbitkan, yang kemudiannya kelihatan sama seperti aliran kerja yang tidak pernah diaktifkan oleh sesiapa pun.

Buka senarai pelaksanaan dan tapis mengikut aliran kerja tersebut. Entri yang gagal bermakna terdapat masalah pada aliran kerja. Jika ia gagal dengan ralat 429 terhadap servis lain yang anda hoskan pada mesin yang sama, had tersebut adalah milik servis itu dan bukannya n8n, dan panduan SearXNG 429 menunjukkan cara untuk membezakan pengehad kadar (rate limiter) servis tersebut daripada enjin yang menyekat IP pelayan anda. Jika tiada entri langsung, ia adalah masalah pencetus, dan empat punca di atas adalah perkara yang perlu diperiksa.

Perkara pertama yang perlu diubah

1. Baca STATUS, RestartCount dan OOMKilled pada kontena anda sendiri sebelum menyunting sebarang fail.
2. Jika kontena tidak pernah terhenti, baiki pengepala naik taraf proksi (proxy upgrade headers) dan tamat masa melahu (idle timeout).
3. Jika OOMKilled adalah benar (true), tetapkan had kontena yang anda pilih secara sengaja, letakkan had atas heap Node di bawahnya, dan tukarkan data binari kepada filesystem.
4. Jika tiada apa-apa yang tercetus, semak sama ada aliran kerja (workflow) aktif dan zon waktu tika (instance timezone) adalah milik anda.

Kebanyakan ini adalah konfigurasi yang anda tetapkan sekali sahaja dan tidak perlu diubah lagi, di atas pemasangan yang berfungsi. Jika anda masih dalam proses melakukan pemasangan tersebut, panduan n8n pada Docker dengan HTTPS adalah asas bagi tetapan ini.

FAQ

Mengapakah editor n8n memaparkan sepanduk "connection lost" sedangkan kontena sedang berjalan?

Editor mengekalkan sambungan WebSocket untuk menstrim kemajuan pelaksanaan. Jika proksi terbalik anda tidak memajukan pengepala Connection: Upgrade dan Upgrade: websocket, atau tidak menggunakan HTTP/1.1 untuk upstream, proses naik taraf (upgrade) tidak akan selesai dan pelayar akan terus menyambung semula sementara n8n kekal sihat. Dalam nginx, anda memerlukan proxy_http_version 1.1 berserta kedua-dua baris proxy_set_header, dan proxy_read_timeout yang lebih lama daripada 60 saat (nilai lalai) supaya tab yang tidak aktif tidak diputuskan. Semak konfigurasi yang sedang berjalan dengan sudo nginx -T, bukan fail yang anda sunting.

Bagaimanakah cara membezakan antara "out of memory kill" dengan kerosakan (crash) biasa?

Jalankan docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' dan baca bendera OOMKilled. Nilai "True" bermakna kernel telah mematikan proses kerana melebihi had memori, dan tiada maklumat berguna dalam log kontena kerana proses tersebut tidak sempat menulis apa-apa. Nilai "False", dengan ralat "heap" dan "stack trace" pada penghujung docker logs, bermakna Node.js telah mencapai had "V8 heap" sendiri dan keluar secara automatik. Tetapkan NODE_OPTIONS=--max-old-space-size di bawah had kontena anda supaya anda mendapat kegagalan jenis kedua, yang mana ia meninggalkan bukti.

Adakah pembersihan data pelaksanaan (pruning) membebaskan ruang cakera serta-merta?

Tidak. EXECUTIONS_DATA_PRUNE menandakan pelaksanaan lama untuk dipadam dan proses seterusnya akan membuangnya, mengikut jadual yang ditetapkan oleh EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL. Dengan SQLite, fail tersebut juga menggunakan semula halaman yang telah dibebaskan dan bukannya memulangkannya kepada sistem fail, jadi saiz pada cakera kekal sama untuk seketika selepas baris data dipadamkan. Tetapkan EXECUTIONS_DATA_MAX_AGE dan EXECUTIONS_DATA_PRUNE_MAX_COUNT kepada nilai yang sesuai dengan pelayan anda, kemudian semak semula pada keesokan harinya dan bukannya serta-merta.

Mengapakah aliran kerja (workflow) berjadual saya tidak berjalan semasa n8n dimulakan semula?

n8n mendaftarkan pencetus (trigger) apabila proses bermula, dan ia tidak memainkan semula jadual yang sepatutnya berlaku semasa ia tidak aktif. Oleh itu, gelung mulakan semula (restart loop) akan menyebabkan ketiadaan aktiviti dan bukannya lonjakan pelaksanaan tertunda, dan pelaksanaan seterusnya adalah pada waktu yang dijadualkan selepas permulaan. Jika anda memerlukan pelaksanaan yang tidak boleh terlepas, jalankan aliran kerja daripada pemanggil luaran yang mengakses webhook, supaya logik cuba semula (retry logic) berada di luar n8n.

Adakah pemeriksaan kesihatan (healthcheck) akan memulakan semula n8n apabila ia berhenti bertindak balas?

Tidak secara automatik. Pemeriksaan kesihatan Compose hanya menandakan kontena sebagai sihat atau tidak sihat. Memulakan semula adalah tugas dasar "restart policy", jadi restart: unless-stopped adalah perkara yang membawa kontena kembali selepas ia keluar, dan ia juga membawanya kembali selepas but semula hos selagi perkhidmatan Docker diaktifkan. Sahkan perkara itu dengan sudo systemctl is-enabled docker. Untuk bertindak secara khusus terhadap status tidak sihat, anda memerlukan pemerhati di luar Docker yang membaca status tersebut dan memulakan semula perkhidmatan.