n8n bị timeout: 6 nguyên nhân thật và cách sửa

Workflow chạy vài phút rồi dừng, báo lỗi hoặc treo vô hạn, mà bạn không biết nên sửa ở đâu. Thực tế n8n bị timeout có sáu dạng triệu chứng khác nhau, mỗi dạng nằm ở một tầng riêng: proxy, instance, node hay phía client. Bài này tách từng triệu chứng kèm lệnh kiểm tra.

n8n bị timeout là gì: ba nhóm lỗi hay bị gọi chung

n8n bị timeout không phải một lỗi duy nhất mà là tên gọi chung cho ba nhóm sự cố ở các tầng khác nhau. Nhóm một là hết thời gian chờ ở tầng mạng: Nginx hoặc Cloudflare ngắt kết nối trong khi n8n vẫn xử lý. Nhóm hai nằm trong instance: tiến trình bị giết vì hết RAM hoặc container restart. Nhóm ba là giới hạn riêng của node và của client gọi webhook. Chẩn đoán đúng nhóm là việc quan trọng nhất.

Điều cần chuẩn bị

Bạn cần ba thứ trước khi sửa: quyền truy cập editor n8n, terminal trên host đang chạy n8n bằng Docker Compose, và thông tin của workflow lỗi gồm tên workflow, execution ID, thời điểm xảy ra. Nếu n8n nằm sau reverse proxy, hãy xác định trước lớp đó là Nginx, Cloudflare hay load balancer, vì mỗi lớp có thời gian chờ riêng.

Chẩn đoán n8n bị timeout theo sáu triệu chứng thật

Đừng vội tăng giá trị timeout, hãy đọc triệu chứng trước rồi mới đụng cấu hình. Mỗi mục dưới đây nêu dấu hiệu quan sát được, nguyên nhân thường gặp, cách sửa và cách kiểm tra lại. Nếu nhiều triệu chứng xuất hiện cùng lúc, hãy xử lý từ tầng ngoài vào trong: proxy, instance, node, rồi tới client.

Triệu chứng 1 — 504 Gateway Timeout hoặc 524 từ tầng trên

n8n bị timeout ở dạng này thường chỉ là hậu quả phụ: client báo 504 Gateway Timeout, Cloudflare báo 524, trong khi execution bên trong vẫn kết thúc thành công. Nginx có proxy_read_timeout mặc định 60 giây, Cloudflare mặc định khoảng 100 giây. Cách sửa: tăng proxy_read_timeout trong site proxy, hoặc tốt hơn là đổi thiết kế. Kiểm tra: access log của Nginx và trạng thái cuối của execution.

Triệu chứng 2 — Execution chạy nhưng không có kết quả

Mở giao diện n8n, thanh bên trái có mục Executions: lọc theo trạng thái Running hoặc Waiting, bấm vào một execution rồi xem node nào dừng và dữ liệu đầu vào ra sao. Execution kẹt ở Waiting là dấu hiệu chạy queue: job đã vào hàng đợi nhưng không có worker nào nhận. Nếu execution vẫn Running ở một node HTTP, hãy đọc log container để biết lỗi thật.

docker compose logs --tail=200 n8n

Chạy lệnh này trên host có Docker Compose, đúng thư mục chứa file compose đang quản lý container n8n. Nó in 200 dòng log gần nhất; bạn tìm các từ khoá timed out, ECONNRESET, ENOTFOUND hoặc Killed để biết lỗi nằm ở mạng hay tiến trình bị hệ điều hành giết, thường là do hết RAM. Đọc log theo thứ tự thời gian, từ dòng gần nhất ngược lại, sẽ thấy ngay node nào ngừng im lặng.

Triệu chứng 3 — Node HTTP Request có timeout mặc định

Nếu n8n bị timeout ngay tại một node cụ thể và node đó là HTTP Request, hãy mở Parameters: trường Timeout tính bằng mili giây, mặc định 300000 tức 5 phút, kèm tùy chọn Never Timeout. Trường này chỉ áp dụng cho node đó, còn cả lần chạy vẫn bị giới hạn bởi EXECUTIONS_TIMEOUT nếu bạn có đặt. Với API chậm, cách đúng là giảm số lần gọi: lọc sớm, gộp dữ liệu, bật phân trang rồi mới tăng giá trị.

Triệu chứng 4 — Container chết giữa chừng vì hết RAM

Khi instance bị giết, log thường cụt đột ngột mà không có stack trace, còn execution đứng ở node đang xử lý tập dữ liệu lớn. Docker trả exit code 137 khi tiến trình bị SIGKILL, đây là dấu hiệu kinh điển của OOM. Kiểm tra bằng lệnh sau, chạy đúng lúc workflow đang ở node nặng nhất và để terminal chạy song song:

docker stats

docker stats hiển thị mức dùng CPU và RAM theo thời gian thực cho từng container, gồm cột MEM USAGE và MEM LIMIT. Nếu RAM chạm trần, hãy tăng giới hạn bộ nhớ cho container, đặt NODE_OPTIONS=--max-old-space-size=2048, giảm số bản ghi mỗi lần chạy hoặc tách job nặng sang workflow khác. Kiểm tra: RAM nên dưới khoảng 80% trần.

Triệu chứng 5 — Vòng lặp khiến quy trình chạy mãi không dừng

n8n bị timeout vì vòng lặp là trường hợp dễ nhận ra: execution chạy rất lâu, dữ liệu đầu vào ngày càng dày mà node phía sau không bao giờ chạy. Node Loop Over Items có giới hạn số vòng lặp qua N8N_MAX_ITERATIONS_CALCULATED, mặc định 100000, và log sẽ báo khi chạm giới hạn. Cách sửa bền vững: thêm điều kiện dừng bằng node IF cùng Filter, tách workflow dài thành các bước nhỏ chạy nối tiếp.

Triệu chứng 6 — Webhook và client chờ cùng nhau

Trường hợp cuối cùng là client đã hết thời gian chờ trong khi n8n vẫn xử lý tiếp: hai bên cùng treo, dữ liệu cuối cùng vẫn được ghi xong. Mở node Webhook và xem Response Mode; nếu đang chờ Last Node Response, hãy đổi sang Using ‘Respond When Webhook Is Called’ (bản cũ gọi là Respond Immediately) để trả 202 ngay rồi xử lý sau. Với client cứng nhắc, polling trạng thái sẽ hợp lý hơn.

Cách kiểm tra n8n đã hết lỗi timeout

Chạy lại workflow một lần thủ công, mở execution và so thời gian từng node với trước đây; chạy docker stats khi workflow đang ở node nặng để xem RAM còn dưới 80% trần. Gọi endpoint /healthz trên chính instance: nội dung trả về có trường status bằng ok nghĩa là instance vẫn sống và chưa bị giết. Hãy xác nhận bằng bằng chứng, đừng xác nhận bằng cảm giác.

n8n bị timeout trong thực tế: ba tình huống thường gặp

Tình huống phổ biến nhất là workflow chạy theo lịch cron sáng sớm: nó gọi API bên thứ ba cho vài nghìn bản ghi, mất tám phút, trong khi Cloudflare đã ngắt ở phút thứ hai. Ở đây nút thắt là thời gian chạy chứ không phải hạ tầng, nên cách xử lý đúng là chia nhỏ lô và chạy nối tiếp từng lô, thay vì nhảy thời gian chờ lên vô hạn.

Tình huống thứ hai là một node xử lý 50.000 dòng dữ liệu: RAM tăng vọt, container bị giết, dữ liệu dở dang. Dấu hiệu nhận biết là docker stats cho thấy MEM USAGE chạm trần đúng lúc workflow bắt đầu chạy. Cách sửa là đọc theo lô nhỏ, đẩy phần nặng sang worker riêng hoặc giảm tải cho instance.

Tình huống thứ ba là webhook n8n nằm sau reverse proxy có thời gian chờ thấp: phía client báo lỗi, phía bạn mở Executions thấy Success. Hai bên cùng đúng, chỉ là hợp đồng thời gian chờ không khớp. Sửa ở tầng proxy hoặc chuyển sang trả lời bất đồng bộ là xong, không cần đụng vào workflow, và đây cũng là lý do đừng vội kết luận n8n hỏng khi chỉ thấy một lỗi ở phía client.

Câu hỏi thường gặp về n8n bị timeout

Tăng timeout lên bao nhiêu là hợp lý?

Hãy đặt giới hạn theo thời gian thực tế của workflow cộng thêm vài chục giây, thay vì tăng đến hàng giờ. Biến EXECUTIONS_TIMEOUT tính bằng giây, mặc định là -1 tức không giới hạn, còn EXECUTIONS_TIMEOUT_MAX chặn giá trị bạn đặt trong giao diện, mặc định 3600 giây. Giới hạn chặt giúp bạn phát hiện workflow hỏng sớm thay vì để nó chạy suốt đêm.

EXECUTIONS_TIMEOUT khác Timeout của node HTTP Request thế nào?

Đây là hai tầng khác nhau: EXECUTIONS_TIMEOUT áp dụng cho cả lần chạy của workflow, còn trường Timeout trong node HTTP Request chỉ áp dụng cho một lệnh gọi. Khi bật task runner, còn có tầng thứ ba với N8N_RUNNERS_TIMEOUT, mặc định 300 giây. Vì vậy chỉnh node xong vẫn có thể gặp timeout ở tầng ngoài, nhất là khi bạn bật queue mode với nhiều worker.

Tại sao tôi tăng timeout rồi mà workflow vẫn treo?

Vì giới hạn thật không nằm ở nơi bạn đang sửa. Nếu tầng proxy ngắt kết nối, tăng giá trị trong n8n không có tác dụng. Nếu node không bao giờ trả dữ liệu, tăng số giây chỉ khiến bạn chờ lâu hơn. Nếu RAM cạn hoặc vòng lặp vô hạn, timeout tăng bao nhiêu cũng vô nghĩa. Hãy quay lại sáu triệu chứng ở trên và xác định tầng đúng trước đã.

Container bị giết giữa chừng có phải do hết RAM không?

Chưa chắc, hãy kiểm tra theo thứ tự: đọc docker compose logs --tail=200 n8n xem dòng cuối có bị cắt giữa chừng không, rồi chạy docker stats xem MEM USAGE có chạm MEM LIMIT không. Nếu đúng, bạn sẽ thấy exit code 137. Cách xử lý là tăng RAM cho container, giới hạn kích thước dữ liệu mỗi lần chạy và cân nhắc NODE_OPTIONS=--max-old-space-size=2048 khi Node.js bị giết vì vùng nhớ heap.

Kết luận

Nếu n8n bị timeout thì phần lớn trường hợp không cần tăng bất kỳ giá trị nào. Bạn chỉ cần đi theo thứ tự sau:

Chẩn đoán theo tầng trước: proxy, instance, node, rồi mới tới client.
Gặp 504 hoặc 524 trong khi execution vẫn Success thì sửa ở reverse proxy.
Execution dừng không stack trace thì xem RAM bằng docker stats; exit code 137 là dấu hiệu OOM.
Node HTTP Request mặc định 5 phút: tối ưu số lần gọi thay vì chỉ tăng giá trị Timeout.
Vòng lặp vô hạn gây treo: thêm điều kiện dừng, chia lô, gọi workflow con.
Muốn cảnh báo lỗi tái diễn lúc nửa đêm, đọc bài giám sát uptime cho n8n kèm cảnh báo Telegram.
Lỗi timeout ở tầng proxy thì đọc tiếp bài tinh chỉnh Nginx cache, gzip và HTTP/2, hoặc nâng cấp hosting cho n8n.

Muốn hiểu sâu phần hàng đợi, worker và cách mở rộng instance, hãy đọc tài liệu chính thức Scaling in n8n. Nếu cần tái hiện lỗi, hãy dựng một bản n8n riêng trên môi trường thử nghiệm thay vì sửa trực tiếp trên production đang chạy, rồi áp dụng đúng thứ tự ở trên từng tầng một.