Mengapa n8n kerap terputus di VPS anda?

Mengapa n8n kerap terputus: empat kegagalan, satu simptom

"n8n kerap terputus" ialah satu ayat yang merangkumi empat kegagalan berbeza, dan setiap satunya memerlukan penyelesaian yang berlainan. Editor memaparkan sepanduk sambungan terputus (connection lost) walaupun kontena sedang 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 tidak kena dengan proses tersebut, namun aliran kerja (workflow) yang aktif langsung tidak 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 belakang 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-perintah ini pada VPS (virtual private server) dan baca nilai yang dipaparkan oleh mesin anda sendiri. Jangan bandingkan nilai tersebut dengan angka daripada utas 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 menyatakan tempoh masa kontena berada dalam status semasanya. Bandingkan tempoh tersebut dengan saat masalah anda bermula. Jika kontena telah berjalan sejak sebelum banner muncul, maka 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 mula semula (restart loop), dan baris log tepat sebelum setiap permulaan semula mengandungi puncanya.

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

ExitCode ialah kod penamatan 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 kehabisan memori (out of memory) secara bersama 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 sedang berkuat kuasa. Biarkan ia berjalan dalam terminal kedua, cetuskan aliran kerja (workflow) yang menyebabkan kegagalan, dan perhatikan perubahan angka tersebut semasa kegagalan berlaku.

Banner sambungan terputus biasanya berpunca daripada reverse proxy anda

Editor n8n mengekalkan satu sambungan push yang tahan lama 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 untuk 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 secara berterusan. 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 berada dalam keadaan sihat. Banner tersebut adalah cara pelayar memberitahu anda bahawa ia telah kehilangan salurannya.

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 sepatutnya mencapai 101 Switching Protocols dan kekal terbuka. Permintaan push yang mengembalikan kod status biasa, atau yang muncul semula setiap beberapa saat, menunjukkan masalah pada proksi.

Tetapan nginx yang mengekalkan sambungan editor

nginx tidak akan memajukan naik taraf (upgrade) melainkan anda memintanya. proxy_pass berkomunikasi menggunakan HTTP/1.0 dengan backend secara lalai, manakala Connection dan Upgrade merupakan hop-by-hop headers yang dibuang oleh nginx semasa proses penghantaran. Anda perlu memasukkan kedua-duanya semula. Blok map diletakkan dalam konteks http, bukan di dalam 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 ialah baris yang sering ditinggalkan oleh pengguna. Nilai lalaiannya 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 menyelesaikan masalah sepanduk ralat 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 memaparkan keseluruhan konfigurasi yang sedang berjalan dan bukannya satu fail sahaja, jadi ia membuktikan bahawa suntingan anda telah dimuatkan. Konfigurasi yang tersimpan dalam fail tetapi tidak diambil oleh mana-mana baris include adalah punca mengapa pembetulan yang betul kelihatan tidak memberikan 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 nilai ini mengikut 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 kehilangan pengepala (header). Tetapan ini berada 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 menukar proksi sama sekali kerana ia dikendalikan oleh pihak lain, tukar saluran tolak (push channel) dengan N8N_PUSH_BACKEND=sse. SSE (server-sent events) ialah 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. Memilih proksi itu sendiri adalah keputusan yang berasingan, dan perbandingan nginx, Caddy dan Traefik merangkumi kos operasi bagi setiap satu.

Apabila kontena sentiasa 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 menghalang permulaan, pangkalan data yang tidak dapat dicapai oleh n8n, kegagalan sistem (crash) semasa berjalan, dan penamatan akibat kehabisan memori (memory kill).

Mulakan dengan volume, kerana isu kebenaran (permissions) sering tidak disedari. Imej rasmi dijalankan 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 setiap kali ia dimulakan 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

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, dan penjelasan PUID dan PGID merangkumi cara imej ini menentukan siapa yang menulis fail tersebut.

Kegagalan out of memory 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 dibaca 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 dibaca sebagai palsu (false). Dari pelayar, kedua-dua 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 kedua-duanya, V8 akan terus membuat peruntukan melepasi titik di mana kernel bertindak, jadi pengumpul sampah (garbage collector) tidak akan 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 apa yang dimiliki oleh VPS anda, dengan meninggalkan 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 menerangkan kunci mana yang diguna pakai 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 pelaksanaan ditetapkan oleh kelompok data terbesar yang anda tolak melaluinya, jadi aliran kerja yang mengendalikan sepuluh ribu baris sekaligus adalah program yang berbeza daripada aliran kerja yang sama yang mengendalikan dua ratus baris pada satu masa. Dan salinan yang disimpan akan terus berkembang sehingga sesuatu memadamkannya.

Pruning menangani masalah kedua. Setakat Ogos 2026, tetapan lalai adalah pruning didayakan, EXECUTIONS_DATA_MAX_AGE pada 336 jam (14 hari) dan EXECUTIONS_DATA_PRUNE_MAX_COUNT pada 10000. Ini adalah tetapan yang luas untuk VPS kecil yang menjalankan SQLite, di mana satu fail menyimpan segala-galanya dan proses yang sama yang melayani 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 yang agresif. Ia menyimpan pelaksanaan yang gagal untuk penyahpepijatan dan membuang pelaksanaan yang berjaya. Tentukan perkara ini dengan sengaja, kerana aliran kerja yang menghasilkan output yang salah tanpa mencetuskan ralat tidak akan meninggalkan apa-apa untuk anda periksa. Pruning juga menandakan baris sebagai dipadam terlebih dahulu dan mengalih keluarnya pada pas seterusnya, dan SQLite menggunakan semula halaman yang dikosongkan dan bukannya memulangkannya, jadi fail pada cakera tidak mengecil serta-merta apabila anda menukar tetapan tersebut.

Untuk mengurangkan puncak dan bukannya jumlah keseluruhan yang disimpan, pindahkan kurang data bagi setiap pelaksanaan. Pecahkan kerja yang besar kepada sub-aliran kerja yang mengembalikan hasil kecil kepada induk, lakukan kelompok dengan nod Loop Over Items, dan jauhkan keseluruhan set data daripada 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 diserahkan 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 menukar tetapan. N8N_PAYLOAD_SIZE_MAX menetapkan muatan webhook masuk terbesar dalam MiB (mebibytes) dan ditetapkan kepada 16 secara lalai. Meningkatkan nilai ini membolehkan permintaan yang lebih besar masuk, dan itu merupakan kos memori yang anda pilih untuk tanggung.

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

Dasar mulakan semula, dan kembali selepas but semula

Kontena tanpa dasar mulakan semula akan kekal mati selepas ia keluar, 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 ialah 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

Pemeriksaan kesihatan (healthcheck) dengan sendirinya tidak memulakan semula apa-apa. Compose menandakan kontena sebagai tidak sihat dan berhenti di situ, jadi pemeriksaan kesihatan memerlukan dasar mulakan semula atau pemerhati luaran di sampingnya untuk memberikan sebarang kesan. Menulis pemeriksaan kesihatan yang benar-benar bertindak dan membuat tindanan (stack) bermula semula selepas but semula merangkumi kedua-dua bahagian tersebut.

Aliran kerja yang tidak pernah dicetuskan walaupun 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 masalah ini.

• Aliran kerja tidak aktif. Pencetus Jadual (Schedule Trigger) hanya berjalan pada laluan pengeluaran, 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 dicetuskan pada 09:00 dalam zon tersebut sehingga anda menetapkan GENERIC_TIMEZONE dan TZ kepada zon waktu anda sendiri.
• Masa henti tidak diganti selepas itu. Pencetus 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 telah dinyahaktifkan untuk anda. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED dimatikan secara lalai, dan apabila ia dihidupkan, aliran kerja yang terus terhempas akan dinyahterbitkan, yang kemudiannya kelihatan sama seperti aliran kerja yang tidak pernah diaktifkan oleh sesiapa.

Buka senarai pelaksanaan dan tapis mengikut aliran kerja tersebut. Entri yang gagal bermakna masalah pada aliran kerja. Tiada entri langsung bermakna masalah pada pencetus, dan empat punca di atas adalah perkara yang perlu diperiksa.

Perkara yang perlu diubah dahulu

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

Kebanyakan perkara ini merupakan 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 sambungan terputus sedangkan kontena sedang berjalan?

Editor mengekalkan WebSocket terbuka untuk menstrim kemajuan pelaksanaan. Jika reverse proxy anda tidak memajukan header Connection: Upgrade dan Upgrade: websocket, atau tidak menggunakan HTTP/1.1 upstream, naik taraf tidak akan selesai dan pelayar akan menyambung semula secara berterusan walaupun n8n berada dalam keadaan 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 saya membezakan antara "out of memory kill" dengan kegagalan biasa?

Jalankan docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' dan baca flag 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 kedua, iaitu kegagalan yang meninggalkan bukti.

Adakah pembersihan data pelaksanaan membebaskan ruang cakera serta-merta?

Tidak. EXECUTIONS_DATA_PRUNE menandakan pelaksanaan lama untuk dipadamkan 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 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 menghasilkan tempoh senyap 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 berada di luar n8n.

Adakah healthcheck akan memulakan semula n8n apabila ia berhenti bertindak balas?

Tidak secara automatik. Healthcheck Compose hanya menandakan kontena sebagai sihat atau tidak sihat. Memulakan semula adalah tugas polisi restart, 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.