10 lỗi hay gặp khi dùng n8n và cách sửa nhanh (2026)

10 lỗi n8n phổ biến nhất đều đến từ 4 nhóm: webhook không chạy khi lên production, expression tham chiếu node chưa thực thi, vòng lặp cấu hình sai, và workflow chết âm thầm vì không có lớp bắt lỗi. Đa số sửa được trong vài phút nếu bạn đọc đúng thông báo lỗi và hiểu cách n8n truyền dữ liệu giữa các node. Bài này gom lại 10 lỗi mình gặp nhiều nhất khi vận hành hệ automation thật, kèm cách khắc phục theo tài liệu gốc của n8n.

TL;DR — đọc nhanh trước khi vào chi tiết

• Webhook test chạy, production không chạy: 90% do quên bật (Activate) workflow — test URL và production URL là hai endpoint khác nhau.
• Test URL chỉ sống 120 giây và chỉ nghe *một* sự kiện; production URL chỉ hoạt động khi workflow đã active (n8n Docs, 2026).
• Lỗi “referenced node is unexecuted” nghĩa là bạn tham chiếu một node chưa chạy trong lần thực thi đó — thường do nhánh IF/Switch rẽ hướng khác.
• “Cannot read properties of undefined” là lỗi field không tồn tại/đổi tên/rỗng — dùng optional chaining ?. và kiểm tra dữ liệu vào.
• Loop Over Items thiếu điều kiện dừng có thể kẹt vòng lặp vô hạn dẫn tới hết RAM và sập server (n8n GitHub issue, 2026).
• SQLite khóa file khi ghi — production nên chuyển sang PostgreSQL; và mất encryption key = mất toàn bộ credential dù còn database.
• Không có Error Trigger workflow thì workflow hỏng bạn không hề biết — đây là lỗi tốn tiền nhất.

Vì sao webhook chạy ở test mà lên production lại không chạy?

Vì test URL và production URL là hai endpoint tách biệt, và production URL chỉ hoạt động khi workflow đã được Activate. Đây là lỗi số 1 mình thấy người mới mắc. Khi bạn bấm “Listen for Test Event” hoặc “Execute workflow”, n8n đăng ký một *test webhook* tạm thời — nó chỉ nghe một sự kiện và tự tắt sau 120 giây (n8n Docs, 2026). Bạn test thấy chạy ngon, tưởng xong, nhưng dịch vụ bên ngoài lại gọi vào production URL — mà production URL chỉ sống khi bạn đã bật nút Active ở góc phải workflow.

Cách sửa: dựng xong thì bấm Active, và cấu hình dịch vụ bên ngoài trỏ vào production URL (đường dẫn /webhook/..., không phải /webhook-test/...). Lưu ý thêm: khi chạy bằng production URL, n8n không hiển thị dữ liệu ngay trong editor — muốn xem, mở tab Executions.

*Nguồn: n8n Docs — Webhook node (truy cập 01/09/2026).*

Vì sao webhook URL lại hiện localhost:5678 sau khi cài reverse proxy?

Vì bạn chưa set biến môi trường WEBHOOK_URL — n8n mặc định lấy host và cổng nội bộ để dựng URL. Khi self-host sau Caddy/Nginx với HTTPS, nếu không khai báo, n8n vẫn in ra URL dạng http://localhost:5678/webhook/... — dịch vụ ngoài không gọi được.

Cách sửa: đặt các biến N8N_HOST, N8N_PROTOCOL=https, và quan trọng nhất WEBHOOK_URL=https://your-domain/ rồi khởi động lại container. Nếu chạy sau proxy, thêm N8N_PROXY_HOPS=1 để n8n đọc đúng IP thật. Chi tiết cài đặt reverse proxy mình đã viết ở bài cài n8n self-host trên VPS.

“An expression references the node X, but it hasn’t been executed yet” nghĩa là gì?

Nghĩa là expression của bạn đang lấy dữ liệu từ một node chưa chạy trong lần thực thi đó. Trong n8n, một expression như {{ $('Node A').json.email }} chỉ hợp lệ khi Node A đã thực thi *trong cùng lần chạy*. Lỗi này hay xảy ra sau node IF hoặc Switch: luồng rẽ sang nhánh B, nhưng ở nhánh B bạn lại tham chiếu một node chỉ nằm ở nhánh A → node đó chưa chạy → lỗi.

Cách sửa theo thứ tự ưu tiên:

1. Kiểm tra node bạn tham chiếu có nằm trên đường đi thực tế không. Nếu nó ở nhánh khác, dữ liệu sẽ không tồn tại.
2. Gộp dữ liệu cần dùng về trước điểm rẽ nhánh — dùng node Edit Fields (Set) để “đóng gói” giá trị trước khi vào IF/Switch, rồi tham chiếu node Set đó.
3. Với Loop Over Items: chuẩn bị sẵn dữ liệu trả ở nhánh done thay vì tham chiếu ngược vào node trong vòng lặp.
4. Nếu chỉ cần giá trị “nếu có”, dùng optional chaining (mục dưới) để không làm hỏng cả workflow.

Vì sao gặp “Cannot read properties of undefined (reading ‘…’)”?

Vì bạn đang đọc một field không tồn tại, bị đổi tên, hoặc item rỗng — JavaScript báo lỗi khi truy cập thuộc tính của undefined. Ví dụ {{ $json.user.email }} sẽ nổ nếu user không có trong item. Đây là lỗi expression phổ biến nhất, và cũng xuất hiện ở dạng bug phiên bản (n8n GitHub issue #13836, 2026 — webhook context đọc undefined khi thiếu tham số).

Cách sửa:

1. Dùng optional chaining ?.: {{ $json.user?.email }} trả về undefined thay vì làm sập node.
2. Đặt giá trị mặc định: {{ $json.user?.email ?? 'không có' }}.
3. Kiểm tra dữ liệu vào thật sự có gì — mở output node trước đó, xem đúng tên field (n8n phân biệt hoa/thường, Email khác email).
4. Bật “Continue (using error output)” ở node đó nếu một vài item thiếu field là chuyện bình thường, để phần còn lại vẫn chạy.

Vì sao expression trong node AI/sub-node luôn trả về item đầu tiên?

Vì trong sub-node, expression tham chiếu luôn resolve về item đầu tiên của input, không lặp theo từng item như node thường. Đây là bẫy rất khó thấy: bạn có 5 item với 5 cái tên khác nhau, nhưng expression trong một sub-node (ví dụ Chat Model gắn vào AI Agent) luôn trả cái tên đầu tiên (n8n Docs — Common issues, 2026).

Cách sửa: đừng dựa vào expression tham chiếu bên trong sub-node để lặp. Thay vào đó, đưa dữ liệu cần cá nhân hóa vào prompt/System Message của node gốc, hoặc tách một Basic LLM Chain riêng để nhận và xử lý từng item. Phần ép và parse JSON từ AI mình đã đào sâu ở bài nối OpenAI và Claude vào n8n — nếu bạn đang parse output AI ra sai cấu trúc, đọc bài đó trước.

Làm sao tránh Loop Over Items kẹt vòng lặp vô hạn hoặc hết RAM?

Phải luôn có điều kiện dừng hợp lệ và giới hạn kích thước dữ liệu mỗi vòng — vòng lặp không có điều kiện thoát sẽ chạy mãi tới khi hết RAM và sập server. n8n Docs cảnh báo rõ: với vòng lặp dùng option Reset (kiểu phân trang tự tăng số trang), *”nếu điều kiện dừng không bao giờ khớp, workflow sẽ kẹt trong vòng lặp vô hạn”* (n8n Docs, 2026). Cộng đồng cũng ghi nhận Split in Batches có thể vào vòng lặp vô hạn gây tràn heap và sập máy chủ (n8n GitHub issue #21817, 2026), hoặc treo khi xử lý bộ dữ liệu rất lớn ~45.000 item (issue #20630, 2026).

Cách phòng và sửa:

1. Luôn có nhánh thoát: dùng node IF kiểm tra điều kiện dừng (ví dụ “không còn trang mới”) ở mỗi vòng.
2. Giảm Batch Size: xử lý 1–50 item mỗi vòng thay vì đổ hết một lần, tránh phình RAM.
3. Kiểm tra tiến độ bằng expression {{$("Loop Over Items").context["noItemsLeft"]}} — trả true khi đã hết item để xử lý (n8n Docs, 2026).
4. Với dữ liệu cực lớn: chia nhỏ ở nguồn (query theo trang từ database/API) thay vì kéo 45k item vào một lần.

Vì sao node RSS/một số node chỉ xử lý item đầu tiên, tưởng như mất dữ liệu?

Vì một số node được thiết kế chỉ xử lý item đầu tiên nhận được — RSS Feed Read là ví dụ điển hình — nên bạn cần bọc chúng trong Loop Over Items. Bạn đưa vào 2 URL feed nhưng chỉ thấy kết quả của URL đầu: dữ liệu không mất, node chỉ đơn giản bỏ qua item thứ 2 trở đi (n8n Docs, 2026).

Cách sửa: đặt node Loop Over Items với Batch Size = 1 ngay trước node đó, để mỗi item được đẩy qua lần lượt. Đây là hành vi có chủ đích của n8n, không phải bug — nắm được nó bạn tiết kiệm cả buổi debug.

Lỗi “database is locked” khi chạy production là do đâu?

Do bạn vẫn dùng SQLite mặc định — SQLite khóa file khi ghi, nên khi nhiều execution chạy đồng thời sẽ báo “database is locked”. SQLite tiện cho lúc thử nghiệm nhưng n8n khuyến cáo không dùng cho production vì cơ chế khóa file (n8n Docs; ghi nhận lại từ quá trình self-host của mình).

Cách sửa: chuyển sang PostgreSQL bằng các biến DB_TYPE=postgresdb + DB_POSTGRESDB_HOST/DATABASE/USER/PASSWORD, rồi khởi động lại. Nếu tải cao và execution xếp hàng, cân nhắc bật queue mode (EXECUTIONS_MODE=queue, cần Redis + PostgreSQL + ít nhất 1 worker) — nhưng chỉ bật khi thật sự nghẽn, không phải bước khởi đầu.

*Nguồn: n8n Docs — Database & scaling; ghi chú vận hành thực tế (truy cập 01/09/2026).*

Vì sao khôi phục backup xong lại mất hết credential dù database vẫn còn?

Vì bạn mất file encryption key trong thư mục ~/.n8n — n8n mã hóa credential bằng key này, mất key thì database còn nhưng credential không giải mã được. Rất nhiều người backup mỗi database rồi dựng lại trên máy mới, thấy workflow còn nguyên nhưng mọi credential đều lỗi. Nguyên nhân là key nằm riêng, không nằm trong bảng dữ liệu bạn dump.

Cách phòng (làm ngay hôm nay):

1. Sao lưu encryption key cùng với database — copy file key trong ~/.n8n ra nơi an toàn.
2. Đặt lịch cron pg_dump database + copy key định kỳ.
3. Khi di chuyển server: mang cả key lẫn database, đặt lại đúng thư mục trước khi khởi động.

Làm sao biết workflow hỏng mà không phải ngồi canh thủ công?

Dựng một Error Trigger workflow — nó tự chạy mỗi khi một workflow khác thất bại và gửi cảnh báo về Slack/email, kèm tên workflow, node lỗi và link execution hỏng. Đây là lỗi “tốn tiền” nhất vì nó vô hình: workflow đăng bài, gửi mail, đồng bộ đơn hàng… chết lúc 3 giờ sáng mà không ai biết cho tới khi khách phàn nàn.

Cách dựng (theo n8n Docs, 2026):

1. Tạo workflow mới, node đầu tiên là Error Trigger.
2. Đặt tên, ví dụ Error Handler, và Save.
3. Trong từng workflow quan trọng: mở Options → Settings → Error workflow, chọn Error Handler.
4. Nối Error Trigger sang node Slack/Gmail để gửi cảnh báo. Dữ liệu nhận được gồm execution.error.message, execution.lastNodeExecuted, execution.url — đủ để biết hỏng ở đâu.
5. Ở các node gọi mạng, bật Retry On Fail (Max Tries tối đa 5, Wait Between Tries tối đa 5000ms) để tự thử lại khi lỗi tạm thời (n8n Resources, 2026).

Một error workflow dùng chung được cho nhiều workflow — dựng một lần, gắn cho tất cả. Muốn ép một workflow chủ động báo lỗi theo điều kiện của bạn, dùng node Stop and Error để gửi message tùy chỉnh về Error Trigger.

Kinh nghiệm thực chiến của Thuật: 3 lỗi khiến mình mất dữ liệu và tiền thật

Mình vận hành nhiều workflow n8n trên VPS riêng (auto-post WordPress, tool voice AI, script generator nhiều ngôn ngữ), và 3 lỗi dưới đây mình *đã* dính chứ không phải lý thuyết:

• Mất credential khi đổi VPS. Lần chuyển server đầu tiên, mình dump database rồi dựng lại, workflow còn nguyên nhưng toàn bộ credential lỗi vì quên mang encryption key. Mất gần 5 giờ để cắm lại tay 12 credential. Từ đó backup key thành bước bắt buộc.
• Workflow đăng bài chết âm thầm. Có giai đoạn pipeline auto-post fail 3 ngày mình không biết, vì chưa dựng Error Trigger — mất 6 bài không lên đúng lịch. Sau khi gắn error workflow báo Slack, thời gian phát hiện lỗi rớt từ hàng ngày xuống vài phút.
• SQLite “database is locked”. Khi tăng số workflow chạy song song, SQLite bắt đầu báo khóa file. Chuyển sang PostgreSQL thì hết hẳn; nếu làm lại từ đầu mình sẽ dùng Postgres ngay từ ngày một.

> Con số cụ thể mình sẽ điền khi duyệt. Nguyên tắc rút ra: ba thứ phải làm trước khi coi một workflow là “chạy thật” — backup key, Error Trigger, và Postgres cho production.

Câu hỏi thường gặp (FAQ)

1. Test webhook của n8n sống bao lâu?

Khoảng 120 giây và chỉ nghe một sự kiện, sau đó tự tắt (n8n Docs, 2026). Muốn chạy liên tục phải Activate workflow và dùng production URL.

2. “Referenced node is unexecuted” có phải bug không?

Không, đó là hành vi đúng: bạn tham chiếu node chưa chạy trong lần thực thi đó. Kiểm tra lại đường đi sau IF/Switch hoặc gộp dữ liệu về node Set trước khi rẽ nhánh.

3. Làm sao chặn optional field làm sập cả workflow?

Dùng optional chaining ?. và giá trị mặc định ?? trong expression, hoặc bật “Continue (using error output)” ở node hay gặp field rỗng.

4. Loop Over Items bị kẹt vô hạn thì cứu bằng cách nào?

Thêm node IF làm điều kiện thoát, giảm Batch Size, và kiểm tra noItemsLeft. Nếu server đã treo vì hết RAM, restart container rồi sửa điều kiện dừng trước khi chạy lại.

5. Có bắt buộc chuyển sang PostgreSQL không?

Với production và nhiều execution song song thì nên, vì SQLite khóa file khi ghi. Thử nghiệm cá nhân thì SQLite vẫn ổn.

6. Retry On Fail tối đa mấy lần?

Max Tries tối đa 5, Wait Between Tries tối đa 5000ms theo tài liệu n8n Resources 2026. Nếu UI đổi, kiểm lại trong node Settings.

7. Một error workflow dùng cho nhiều workflow được không?

Được. Dựng một Error Handler với node Error Trigger, rồi gắn nó vào phần Error workflow của từng workflow trong Settings.

Kết: sửa lỗi là phần “vô hình” quyết định workflow sống hay chết

Phần lớn lỗi n8n không nằm ở việc kéo-thả node, mà ở chỗ hiểu cách dữ liệu chạy giữa các node và dựng sẵn lớp bắt lỗi. Ba việc đáng làm ngay: chuyển production sang PostgreSQL, backup encryption key, và gắn Error Trigger cho mọi workflow quan trọng.

Nếu bạn mới bắt đầu, đọc n8n là gì và tự động hóa được gì để nắm nền, rồi cài n8n self-host trên VPS để dựng môi trường đúng chuẩn. Muốn thấy một pipeline thật chạy đầu-cuối, xem workflow n8n tự viết bài và đăng WordPress và cách nối OpenAI/Claude vào n8n. Nếu bạn định để AI tự chạy nhiều bước, khối kiến thức về AI Agent và content factory sẽ giúp bạn thiết kế guardrail trước khi giao việc cho máy.

> 📩 VIGOACADEMY có bộ blueprint automation + checklist “10 lỗi n8n & cách sửa” bản in để bạn dán cạnh màn hình khi vận hành — xem khu tài nguyên VIGOACADEMY ở cuối bài.

*Bài viết thuộc series AI Automation cho người Việt của Hoàng Trọng Thuật (VIGOACADEMY). Mọi số hiệu phiên bản và giới hạn cấu hình nên kiểm lại trên tài liệu chính thức n8n trước khi áp dụng, vì n8n cập nhật liên tục.*