가이드

작성자 Matt Connor 2026-08-15

n8n 서버가 계속 오프라인 상태가 되는 이유와 해결 방법

Q: 컨테이너가 실행 중인데 n8n 에디터에 연결 끊김 배너가 뜨는 이유는 무엇입니까?

에디터는 실행 진행 상황을 스트리밍하기 위해 WebSocket 연결을 유지합니다. 리버스 프록시가 Connection: Upgrade 및 Upgrade: websocket 헤더를 전달하지 않거나 업스트림에서 HTTP/1.1을 사용하지 않으면 업그레이드가 완료되지 않습니다. 이 경우 n8n은 정상 상태임에도 브라우저는 계속해서 재연결을 시도합니다. Nginx를 사용한다면 proxy_http_version 1.1 설정과 두 줄의 proxy_set_header 설정이 필요하며, 유휴 상태인 탭이 끊기지 않도록 proxy_read_timeout 값을 기본값인 60초보다 길게 설정해야 합니다. 수정된 파일이 아닌 sudo nginx -T 명령어로 현재 적용된 설정을 확인하십시오.

Q: 실행 데이터를 정리하면 즉시 디스크 공간이 확보됩니까?

아니요. EXECUTIONS_DATA_PRUNE은 오래된 실행 데이터를 삭제 대상으로 표시하며, EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL에 설정된 일정에 따라 이후 단계에서 실제로 삭제됩니다. SQLite의 경우 삭제된 행의 공간을 파일 시스템에 반환하지 않고 내부적으로 재사용하므로, 행이 삭제된 직후에는 디스크 사용량이 즉시 줄어들지 않습니다. EXECUTIONS_DATA_MAX_AGE 및 EXECUTIONS_DATA_PRUNE_MAX_COUNT를 서버 환경에 맞게 설정한 뒤, 즉시 확인하지 말고 다음 날 다시 확인하십시오.

n8n이 오프라인으로 표시되는 4가지 원인을 분석합니다. websocket 연결 오류, 컨테이너 재시작 루프, OOM Kill, 스케줄러 중단 문제를 구분하는 진단법과 Docker 상태 확인 명령어를 통해 정확한 해결책을 제시합니다.

n8n이 계속 오프라인 상태가 되는 이유: 4가지 장애와 1가지 증상

"n8n이 계속 오프라인 상태가 됩니다"라는 문장은 서로 다른 4가지 장애를 포괄하며, 각각 다른 해결책이 필요합니다. 컨테이너는 정상적으로 실행 중인데 편집기에 연결 끊김 배너가 표시될 수 있습니다. 컨테이너가 스스로 재시작될 수도 있습니다. 커널이 메모리 과다 사용을 이유로 Node.js 프로세스를 강제 종료할 수도 있습니다. 혹은 프로세스에는 아무런 문제가 없는데 활성화된 워크플로우가 단순히 실행되지 않는 경우도 있습니다. 잘못된 설정을 변경하면 겪지도 않은 문제를 해결하느라 주말을 허비하게 됩니다.

따라서 설정을 건드리기 전에 어떤 장애가 발생했는지 먼저 파악해야 합니다. n8n은 일반적으로 하나의 Docker 컨테이너 안에서 단일 Node.js 프로세스로 실행되며, TLS(전송 계층 보안)를 종료하는 리버스 프록시 뒤에 위치합니다. 이 계층들은 각각 다른 방식으로 고장이 나지만, 브라우저는 모두 동일한 메시지로 보고합니다.

다음 순서로 진단하십시오

VPS(virtual private 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 열은 컨테이너가 현재 상태로 유지된 시간을 나타냅니다. 이 시간을 문제가 발생한 시점과 비교하십시오. 배너가 나타나기 훨씬 전부터 컨테이너가 실행 중이었다면 n8n은 오프라인 상태가 된 적이 없는 것입니다. 문제가 발생한 지점은 브라우저와 백엔드 사이의 연결이며, 이는 다음 섹션에서 다루는 websocket 경로와 관련이 있습니다.

RestartCount은 Docker가 해당 컨테이너를 재시작한 횟수입니다. 숫자를 기록한 뒤 1분 정도 기다렸다가 다시 확인하십시오. 지켜보는 동안 숫자가 계속 올라간다면 재시작 루프(restart loop)가 발생한 것이며, 각 재시작 직전의 로그 줄에 그 원인이 기록되어 있습니다.

OOMKilled는 참 또는 거짓을 나타내는 플래그입니다. 참(True)은 컨테이너 자체의 제한이나 시스템 전체의 메모리 제한을 초과하여 Linux 커널이 프로세스를 강제 종료했음을 의미합니다. 이 단일 필드만으로도 메모리 부족으로 인한 종료와 다른 모든 종료 유형을 구분할 수 있으므로, 추측하기 전에 반드시 먼저 확인해야 합니다.

ExitCode는 컨테이너가 마지막으로 종료될 때 반환한 코드입니다. 각 코드의 의미를 모두 외울 필요는 없습니다. 본인의 코드를 확인한 뒤, 동일한 타임스탬프의 docker logs 끝부분을 읽어보십시오. 로그의 마지막 부분과 메모리 부족 플래그를 함께 확인해야 정확한 원인을 파악할 수 있으며, 하나만 보면 잘못된 판단을 할 수 있습니다.

docker stats은 현재 적용된 제한과 함께 실시간 메모리 사용량을 보여줍니다. 두 번째 터미널에서 이 명령어를 실행해 둔 상태로 오류를 유발하는 워크플로우를 트리거하여, 장애가 발생하는 동안 숫자가 어떻게 변하는지 관찰하십시오.

연결 끊김 배너는 대개 리버스 프록시 문제입니다

n8n 에디터는 실행 진행 상황을 캔버스에 스트리밍하기 위해 백엔드와 하나의 장기 연결을 유지합니다. 기본적으로 이 연결은 N8N_PUSH_BACKEND이 선택하는 WebSocket이며, 기본값은 websocket입니다. WebSocket은 Connection: Upgrade 및 Upgrade: websocket 헤더를 포함한 일반적인 HTTP 요청으로 시작됩니다. 서버가 101 Switching Protocols로 응답하면, 이후부터 양측은 동일한 TCP 소켓을 양방향으로 사용합니다.

이 연결을 끊는 원인은 두 가지이며, 모두 n8n이 아닌 프록시 설정에 있습니다. 프록시가 업스트림으로 HTTP/1.0을 사용하거나 업그레이드 헤더를 제거하면 업그레이드가 발생하지 않아 에디터가 계속해서 재연결을 시도합니다. 또는 업그레이드는 성공했으나 프록시가 유휴 연결로 판단하여 소켓을 닫아버리는 경우도 있습니다. 메시지가 없는 WebSocket은 유휴 연결과 동일하게 보이기 때문입니다. 두 경우 모두 컨테이너는 정상 상태입니다. 배너는 브라우저가 채널을 잃었다고 사용자에게 알리는 메시지입니다.

설정을 변경하기 전에 브라우저에서 이를 확인하십시오. 개발자 도구를 열고 Network 탭으로 이동한 뒤 WS로 필터링하고 에디터를 새로고침하십시오. 푸시 요청은 101 Switching Protocols에 도달하여 연결이 유지되어야 합니다. 일반적인 상태 코드를 반환하거나 몇 초마다 다시 나타나는 푸시 요청은 프록시 설정에 문제가 있음을 나타냅니다.

편집기 연결을 유지하는 nginx 설정

nginx는 명시적으로 요청하지 않으면 upgrade 헤더를 전달하지 않습니다. proxy_pass는 기본적으로 백엔드와 HTTP/1.0으로 통신하며, Connection와 Upgrade은 nginx가 전달 과정에서 제거하는 hop-by-hop 헤더입니다. 따라서 이 두 헤더를 다시 추가해야 합니다. map 블록은 server 내부가 아닌 http 컨텍스트에 작성해야 합니다.

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 연결에도 적용됩니다. 따라서 사용자가 편집기 탭을 열어둔 채로 방치하면 마지막 메시지 송수신 후 1분 뒤 연결이 끊어집니다. 이 값을 높이면 탭을 다시 열었을 때 나타나는 연결 끊김 배너 문제를 해결할 수 있습니다.

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

nginx -T은 특정 파일 하나가 아닌 전체 실행 중인 설정을 출력하므로, 수정 사항이 실제로 적용되었는지 확인하는 데 유용합니다. include 지시어로 불러오지 않는 파일에 설정을 작성하면, 올바른 수정안을 적용하고도 아무런 변화가 없는 것처럼 보일 수 있습니다.

그런 다음 n8n이 프록시 뒤에 있음을 알려야 합니다. n8n은 이 값들을 기반으로 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를 무시함을 의미합니다. 이 값을 컨테이너 앞단에 있는 프록시 개수로 설정하십시오. 2026년 8월 기준으로 N8N_WEBHOOK_URL가 현재 사용되는 이름이며, 이전 명칭인 WEBHOOK_URL도 여전히 작동하지만 시작 시 경고 메시지가 출력됩니다.

Traefik이 WebSocket을 전달한 뒤 타임아웃이 발생하는 경우

Traefik은 미들웨어나 추가 레이블 없이도 WebSocket 업그레이드 요청을 전달합니다. 따라서 이 배너가 표시되는 Traefik 사용자는 헤더 누락이 아닌 타임아웃 문제를 겪고 있을 가능성이 높습니다. 관련 설정은 entryPoint에서 조정할 수 있습니다. 2026년 8월 기준 Traefik v3에서는 idleTimeout의 기본값이 180초, readTimeout의 기본값이 60초로 설정되어 있습니다.

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

Caddy는 reverse_proxy에서 업그레이드를 자동으로 처리하므로 별도의 지시어가 필요하지 않습니다. 만약 프록시를 직접 관리할 수 없어 설정을 변경할 수 없는 상황이라면, N8N_PUSH_BACKEND=sse을 사용하여 푸시 채널을 전환하십시오. SSE(server-sent events)는 연결을 유지하는 일반적인 HTTP 응답 방식이므로 업그레이드를 거부하는 프록시 환경에서도 동작합니다. 다만, 유휴 타임아웃 설정이 엄격할 경우 연결이 끊길 수 있습니다. 프록시 선택은 별개의 문제이며, Nginx, Caddy, Traefik 비교 문서에서 각 도구의 운영 비용과 특징을 확인할 수 있습니다.

컨테이너가 계속 재시작되는 경우

RestartCount 수치가 상승한다면 컨테이너가 실패하고 있으며 Docker가 이를 복구하고 있는 상태입니다. 로그의 타임스탬프를 각 재시작 시점과 대조하여 직전에 기록된 내용을 확인하십시오. 거의 모든 문제는 다음 네 가지 원인으로 귀결됩니다: 시작을 방해하는 설정 오류, n8n이 접근할 수 없는 데이터베이스, 실행 중 발생하는 크래시, 그리고 메모리 부족으로 인한 강제 종료입니다.

권한 문제는 조용히 발생하므로 볼륨부터 확인하십시오. 공식 이미지는 권한이 없는 사용자 node로 실행되며 데이터를 /home/node/.n8n에 저장합니다. root 권한으로 생성된 bind mount는 해당 사용자가 쓸 수 없으므로 프로세스가 매번 시작 시점에 종료되며, restart policy로 인해 이 과정이 반복됩니다.

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가 반드시 필요하다면, 첫 번째 명령어가 출력한 숫자 형태의 사용자 ID로 호스트 디렉터리를 chown하십시오. 호스트와 컨테이너 간의 소유권 매핑은 한 번 이해해 둘 가치가 있으며, PUID 및 PGID 설명 문서에서 해당 이미지들이 파일 작성자를 결정하는 방식을 다룹니다.

충돌처럼 보이는 메모리 부족(OOM) 종료

n8n 프로세스 위에는 두 개의 독립적인 메모리 상한선이 존재하며, 각각 실패 방식이 다릅니다. 컨테이너 컨트롤 그룹(cgroup) 제한은 커널에 의해 강제됩니다. 이 한계를 넘어서면 프로세스는 즉시 종료되며, 아무것도 기록할 기회 없이 OOMKilled 값이 참(true)으로 읽힙니다. V8 힙 제한은 Node.js 내부에서 강제됩니다. 이 한계를 넘어서면 Node는 스택 트레이스와 함께 힙 오류를 발생시키고 스스로 종료하므로, OOMKilled 값은 거짓(false)으로 읽힙니다. 브라우저에서 보면 이 두 현상은 동일해 보입니다. docker inspect에서 확인하면 두 값은 한 필드 차이로 구분됩니다.

Node 힙 상한선을 컨테이너 제한보다 낮게 설정하십시오. 힙 상한선이 더 높게 설정되어 있으면, V8은 커널이 개입하는 지점을 넘어 계속 메모리를 할당합니다. 이 경우 가비지 컬렉터가 자체 제한에 도달하지 못하므로, 읽을 수 있는 로그가 남지 않는 더 가혹한 종료 현상을 항상 겪게 됩니다.

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의 실제 가용 자원을 고려하여 두 수치를 모두 선택하십시오. 이때 데이터베이스, 프록시, 운영체제를 위한 여유 공간을 남겨두어야 합니다. docker stats --no-stream은 현재 사용량과 적용된 제한을 함께 출력하므로, 작성한 제한값이 Docker에 의해 실제로 적용되었는지 확인할 수 있습니다. Compose 메모리 제한이 적용되는 방식에서 여러 설정이 충돌할 때 어떤 키가 우선하는지 다룹니다.

실행 데이터는 사용자의 기반에서 증가합니다

단일 실행은 워크플로가 진행되는 동안 모든 노드의 출력을 보유하며, n8n은 이 데이터를 저장합니다. 여기에는 두 가지 결과가 따릅니다. 한 번의 실행에서 발생하는 최대 메모리 사용량은 해당 워크플로를 통과하는 가장 큰 데이터 배치에 의해 결정됩니다. 따라서 1만 개의 행을 한 번에 처리하는 워크플로는 200개씩 처리하는 동일한 워크플로와는 다른 프로그램으로 간주됩니다. 또한 저장된 복사본은 누군가 삭제하기 전까지 계속 증가합니다.

정리(Pruning) 기능은 두 번째 문제를 해결합니다. 2026년 8월 기준으로 기본 설정은 정리가 활성화되어 있으며, EXECUTIONS_DATA_MAX_AGE는 336시간(14일), EXECUTIONS_DATA_PRUNE_MAX_COUNT은 10000으로 설정되어 있습니다. 이는 SQLite를 실행하는 소규모 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은 공격적인 설정입니다. 이 설정은 실패한 실행 기록은 디버깅을 위해 보관하고 성공한 실행 기록은 삭제합니다. 이 설정은 신중하게 결정해야 합니다. 오류를 발생시키지 않고 잘못된 출력을 생성한 워크플로를 조사할 방법이 사라지기 때문입니다. 또한 정리는 행을 먼저 삭제된 것으로 표시한 뒤 나중에 제거하며, SQLite는 해제된 페이지를 반환하는 대신 재사용하므로 설정을 변경한다고 해서 디스크상의 파일 크기가 즉시 줄어들지는 않습니다.

저장된 총량이 아닌 최대 메모리 사용량을 줄이려면 실행당 처리하는 데이터 양을 줄여야 합니다. 대규모 작업은 작은 결과를 부모 워크플로로 반환하는 하위 워크플로로 분할하고, 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은 들어오는 웹훅 페이로드의 최대 크기를 MiB(메비바이트) 단위로 설정하며 기본값은 16입니다. 이 값을 높이면 더 큰 요청을 처리할 수 있지만, 그만큼 메모리 사용량 증가를 감수해야 합니다.

동일한 서버에서 실행 중인 다른 모든 프로세스는 RAM을 공유합니다. 데이터베이스 컨테이너를 추가한 후 OOM(Out of Memory) 킬러가 작동하기 시작했다면, 데이터베이스를 Docker에서 실행할지 호스트에서 실행할지에 대한 선택이 현재 직면한 트레이드오프입니다.

재시작 정책 및 재부팅 후 서비스 복구

재시작 정책이 없는 컨테이너는 종료되거나 호스트가 재부팅되면 다시 실행되지 않습니다. restart: unless-stopped은 두 경우 모두 컨테이너를 다시 시작하지만, 사용자가 수동으로 중지한 컨테이너는 그대로 유지합니다. restart: always은 사용자가 의도적으로 중지한 컨테이너라도 Docker가 다음에 시작될 때 다시 실행합니다.

n8n은 N8N_ENDPOINT_HEALTH라는 이름의 상태 확인(health) 엔드포인트를 제공하며, 기본값은 healthz입니다. 호스트에서 먼저 이 경로를 확인하여 해당 인스턴스에서 올바른 경로인지 검증하십시오.

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

상태 확인(healthcheck) 자체만으로는 아무것도 재시작하지 않습니다. Compose는 컨테이너를 비정상(unhealthy) 상태로 표시하고 멈출 뿐이므로, 상태 확인이 실제로 효과를 보려면 재시작 정책이나 외부 감시 도구가 함께 필요합니다. 실제로 동작하는 상태 확인 작성하기와 재부팅 후 스택이 다시 시작되도록 설정하기에서 이 두 가지 측면을 모두 다룹니다.

n8n은 정상인데 워크플로우가 실행되지 않는 경우

이 경우 배너가 표시되지 않으며 재시작도 발생하지 않습니다. 컨테이너는 정상적으로 실행 중이고 에디터도 작동하지만, 실행 목록에 예상했던 실행 기록이 나타나지 않습니다. 대부분 다음 4가지 원인 중 하나에 해당합니다.

워크플로우가 활성화되지 않았습니다. Schedule Trigger는 프로덕션 경로에서만 실행되므로, 캔버스에서 테스트하는 것만으로는 아무것도 예약되지 않습니다.
시간대가 일치하지 않습니다. GENERIC_TIMEZONE은 기본적으로 America/New_York로 설정되어 있습니다. 따라서 GENERIC_TIMEZONE 및 TZ를 본인의 시간대로 설정하지 않으면, 09:00로 설정한 예약은 해당 시간대 기준으로 09:00에 실행됩니다.
다운타임 동안 누락된 실행은 보충되지 않습니다. 트리거는 n8n이 시작될 때 등록되므로, 컨테이너가 재시작되는 동안 예약 시간이 지난 워크플로우는 지연 실행되지 않습니다. 다음 실행은 시작 이후 도래하는 첫 번째 예약 시간에 이루어집니다.
워크플로우가 자동으로 비활성화되었습니다. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED는 기본적으로 꺼져 있습니다. 이 옵션이 켜져 있으면 계속해서 충돌하는 워크플로우는 게시가 취소되며, 이후에는 아무도 활성화한 적이 없는 워크플로우처럼 보입니다.

실행 목록을 열고 해당 워크플로우로 필터링하십시오. 실패한 항목이 있다면 워크플로우 자체의 문제입니다. 항목이 전혀 없다면 트리거 문제입니다. 이 경우 위에서 언급한 4가지 원인을 확인해야 합니다.

가장 먼저 변경해야 할 사항

파일을 수정하기 전에 먼저 자신의 컨테이너에서 STATUS, RestartCount 및 OOMKilled을 읽어 보십시오.
컨테이너가 중단된 적이 없다면, 프록시 업그레이드 헤더와 유휴 시간 제한(idle timeout)을 수정하십시오.
OOMKilled가 true로 설정되어 있다면, 의도적으로 선택한 컨테이너 제한을 설정하고, Node 힙 상한선을 그보다 낮게 지정한 뒤, 바이너리 데이터를 filesystem으로 전환하십시오.
아무런 문제가 발생하지 않았다면, 워크플로우가 활성화되어 있는지와 인스턴스 시간대가 본인의 시간대와 일치하는지 확인하십시오.

이 설정 대부분은 정상적으로 설치된 환경 위에 한 번만 설정하고 잊어버려도 되는 항목들입니다. 아직 설치를 진행 중이라면, HTTPS를 적용한 Docker 기반 n8n 가이드가 이 설정들이 적용될 기본 환경입니다.

FAQ

컨테이너가 실행 중인데 n8n 에디터에 연결 끊김 배너가 뜨는 이유는 무엇입니까?

에디터는 실행 진행 상황을 스트리밍하기 위해 WebSocket 연결을 유지합니다. 리버스 프록시가 Connection: Upgrade 및 Upgrade: websocket 헤더를 전달하지 않거나 업스트림에서 HTTP/1.1을 사용하지 않으면 업그레이드가 완료되지 않습니다. 이 경우 n8n은 정상 상태임에도 브라우저는 계속해서 재연결을 시도합니다. Nginx를 사용한다면 proxy_http_version 1.1 설정과 두 줄의 proxy_set_header 설정이 필요하며, 유휴 상태인 탭이 끊기지 않도록 proxy_read_timeout 값을 기본값인 60초보다 길게 설정해야 합니다. 수정된 파일이 아닌 sudo nginx -T 명령어로 현재 적용된 설정을 확인하십시오.

OOM(Out of Memory)으로 인한 종료와 일반적인 크래시를 어떻게 구분합니까?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' 명령어를 실행하여 OOMKilled 플래그 값을 확인하십시오. True라면 커널이 메모리 제한을 초과한 프로세스를 강제 종료한 것이며, 프로세스가 기록할 기회를 얻지 못했기 때문에 컨테이너 로그에는 유용한 정보가 남지 않습니다. False이면서 docker logs 끝에 힙 오류와 스택 트레이스가 있다면, Node.js가 자체 V8 힙 제한에 도달하여 스스로 종료된 것입니다. 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은 프로세스가 시작될 때 트리거를 등록하며, 다운타임 동안 지나간 예약 실행을 다시 수행하지 않습니다. 따라서 재시작이 반복되면 실행이 누락되며, 다음 실행은 시작 후 예정된 다음 시간에 이루어집니다. 반드시 실행되어야 하는 작업이라면 외부 호출자가 웹훅을 호출하도록 구성하여 재시도 로직을 n8n 외부에서 관리하십시오.

헬스체크가 응답하지 않는 n8n을 재시작합니까?

그렇지 않습니다. Compose 헬스체크는 컨테이너의 상태를 정상 또는 비정상으로 표시할 뿐입니다. 재시작은 재시작 정책의 역할이므로, restart: unless-stopped 설정이 프로세스 종료 후 컨테이너를 다시 살리며 호스트 재부팅 시에도 Docker 서비스가 활성화되어 있다면 컨테이너를 복구합니다. sudo systemctl is-enabled docker 명령어로 이를 확인하십시오. 비정상 상태에 대해 즉각 대응하려면 상태를 읽고 서비스를 재시작하는 별도의 감시 도구가 Docker 외부에 필요합니다.

#n8n #troubleshooting #docker #websockets #memory #reverse-proxy