設定速查

為什麼要有一份速查

n8n 的設定其實不多，但問題出在分了很多層——你以為改了個開關，結果那個開關只影響你自己一個人；又或者你在自己 Settings 找半天，其實那個東西只有 admin 或環境變數能改。真實遇過的狀況：

• 「幫我把介面切成中文」 —— 這其實不是 Personal 能改的，n8n community 沒有 UI 語言下拉；要靠 instance 的 N8N_DEFAULT_LOCALE env var，找 IT。
• 「幫我把 Schedule 節點改成台北時間」 —— 這是 workflow 級的 Settings tab，或者叫 IT 改 GENERIC_TIMEZONE。
• 「我上禮拜跑的 execution 不見了！」 —— 這是 instance 級的 EXECUTIONS_DATA_MAX_AGE，預設 336 小時（14 天）就 auto purge，你沒權限改，找 IT。
• 「我按了 Manual Execute 但 Executions 頁沒紀錄」 —— 這是 workflow Settings 的 Save manual executions；n8n 官方 instance 預設其實是開（EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true），但很多公司 IT 為了省 DB 會關掉，所以你這台看不到不代表壞掉，是被覆蓋。

這附錄按「你能不能改 / 影響誰」分兩大類——Personal（自己畫面，隨時改）跟 Workspace / Instance（全公司共用，只有 admin 或 env vars）。搞懂這層分工，之後遇到 90% 的設定問題都知道去哪找、找誰改。

兩層設定：Personal vs Workspace

先把心智模型立起來。n8n 的設定分成兩層——一層是你自己的畫面偏好，另一層是整個 instance 的行為。改錯層等於白改。

Personal 設定：只影響你自己的帳號

左下角三個點旁邊點頭像 → Settings，n8n 開啟 Personal settings 頁。這些設定綁在你的帳號上（存在 n8n DB），跟同事無關。

Workflow 級設定：打開 workflow 找 Settings tab

打開任何一個 workflow，畫面最頂端會看到 Editor / Executions / Evaluations / Settings 這幾個 tab。點 Settings 進去，就是這個 workflow 的專屬設定。這些選項只影響這一個 workflow，不會動到別的。

Instance 級設定：整台 n8n 的行為

這些設定寫在環境變數（.env 檔或 docker-compose 的 environment:）——你在 UI 上看不到、也改不了，要動就得請 IT 或 admin。看得懂它們在講什麼，你才不會拿一堆 UI 找不到的東西去問 IT。

Executions 保留天數：為什麼你的紀錄會消失

Community 版預設 14 天（336 小時）就會 auto purge，這是最多人踩的坑。每次 workflow 跑一次都會產生一筆 execution 紀錄——連同節點的 input / output 資料（Save 選項有開的話），塞在 PostgreSQL / SQLite 裡。時間久了 DB 會腫，n8n 官方預設就設了 14 天，不然新裝的 instance 跑三個月會發現 DB 20GB。

後果：

• 15 天前的 execution 不管成功失敗都直接消失——UI 看不到、DB 裡也沒了。
• 連帶 execution 的節點 input / output 資料也一併消失——想回頭看那天 API 回傳了什麼，沒了。
• 對外部系統的操作（Slack 訊息、Airtable 資料）當然還在——刪的只是 n8n 這邊的執行紀錄。

想留久一點，三條路：

1. 找 IT 改環境變數

   請 IT 把 EXECUTIONS_DATA_MAX_AGE 從 336 調到你要的數字（單位是小時，不是天）。想留 30 天就設 720、90 天設 2160。

2. 關鍵資料自己另存

   在 workflow 最後接一個 Google Sheets / Airtable / DB 節點，把每次執行的關鍵資料（input、時間、結果）寫進外部——這樣不管 n8n executions 保留多久，稽核紀錄都在。這是稽核合規最穩的做法。

3. 整台 DB 做定期 dump

   IT 對 n8n 的 PostgreSQL 每天做 pg_dump backup。這樣 executions 被 purge 掉之後，需要回溯還可以從 dump 檔還原。適合稽核嚴的公司。

Timezone 三層優先序：Schedule 為什麼跑錯時間

「我明明設早上 9 點，怎麼變下午 5 點跑」——十有八九是 Timezone 沒設。n8n 決定 workflow 的時區有三層，從高到低：

都沒設就是 America/New_York——這是 n8n 官方 GENERIC_TIMEZONE 的預設值（不是 UTC，很多人以為是 UTC）。所以「新裝的 n8n 跑 Schedule 時間對不上」在台灣是必然，差 12～13 小時（看紐約當時是不是夏令）。TZ（Node.js 進程時區）則吃 base image 預設，Docker 官方 image 是 UTC——兩個變數會有落差，log 時間跟 workflow 時間可能對不起來，所以實務上 GENERIC_TIMEZONE 跟 TZ 建議設成一樣。

推薦做法：

1. Instance 底線先設好

   請 IT 把 GENERIC_TIMEZONE=Asia/Taipei 跟 TZ=Asia/Taipei 都加進 .env，重啟。這樣新 workflow 預設就是台北時間，不用每個都手動設。

2. Workflow 保險再設一次

   任何用 Schedule / Cron 的 workflow，還是進 Settings tab 明確選 Asia/Taipei——這樣就算之後 IT 改 GENERIC_TIMEZONE、或搬到別台 n8n，你的排程時間都不會變。

3. 跨時區資料才在 Expression 明寫

   只有處理跨時區資料（例：把 UTC timestamp 轉台北時間顯示）才在 Expression 用 .setZone()——不要每個節點都寫，維護惡夢。

最常要改的設定清單

照身份分三份 checklist——照著跑一遍，90% 的日常問題都不會發生。

新使用者第一天（自己就能做）：

• Personal settings → 檢查 First name / Last name / Email 填對
• 如果會用 API：Personal settings → API Keys 產一個存好
• 密碼建議打開 2FA（如果 instance 有開啟這功能，見 第 2 章）
• 想要中文介面 → 這個自己改不了，找 IT 設 instance 級 N8N_DEFAULT_LOCALE

建新 workflow 每次都做（3 分鐘）：

• Settings tab → Timezone 選 Asia/Taipei（不然吃 America/New_York）
• Error Workflow 指定你的 handler workflow（沒有就先做一個，見 第 17 章）
• 開發階段確認 Save manual executions 是 Save（若 IT 把 instance 預設關了要在這裡強制打開）
• 會跑很久的開 Timeout Workflow（例：1 小時）
• 處理 PII / 金流的加 Redact production execution data

IT / Admin 部署前要決定（做一次）：

• GENERIC_TIMEZONE + TZ 設 Asia/Taipei
• WEBHOOK_URL 明確設成公開域名（反向代理架構必做）
• EXECUTIONS_DATA_MAX_AGE 依稽核需求決定（14 天 / 30 天 / 90 天）
• 認證憑證的加密 key N8N_ENCRYPTION_KEY 產一個強的、備份好（換了會讓所有現有 credentials 解不開）
• DB 從內建 SQLite 換成 PostgreSQL（正式環境必做）

常見卡關

1. Schedule / Cron 節點跑錯時間

   99% 是 workflow 的 Timezone 沒設，跑成 instance 預設（官方預設是 America/New_York，不是 UTC）。開這個 workflow → Settings tab → Timezone 選 Asia/Taipei → Save。Instance 若也沒設 GENERIC_TIMEZONE，順便請 IT 加。改完下次觸發才會用新時區，上一次已排定的還是舊時間。

2. Executions 頁上禮拜的紀錄不見了

   Community 版預設 14 天 auto purge——超過就被清了，n8n 端沒救。想留久要改 EXECUTIONS_DATA_MAX_AGE（找 IT）。長期解法：把關鍵資料另存到 Google Sheet / DB，不要靠 n8n executions 當稽核紀錄。

3. 我沒看到 Instance settings 頁 / Admin 頁

   Instance 設定在 UI 上本來就大部分沒得改，都在環境變數。你在 UI 找不到不是你權限問題，是它根本不在 UI。有些 admin 專用頁（例：Users 管理）只有 owner / admin 角色看得到——找 IT 或當初開這個 instance 的人。

4. 找不到「Personal → Language」下拉

   官方 n8n community Personal settings 沒有 UI 語言選擇下拉——你不是眼瞎，是它根本不存在。UI 語言由 instance 的 N8N_DEFAULT_LOCALE env var 決定（且只吃 en / zh 這種基本 tag，不吃 zh-TW / zh-Hant），改完得重啟整台 n8n，會影響全公司。網路上寫「切成简体中文」的教學多半是舊版截圖或第三方 fork。

5. 改了 workflow Settings 但 Executions 還是沒存資料

   三個檢查點：（a）workflow Settings 的 Save 選項有沒有真的按 Save（不是只切開關就走）；（b）你按的是 Execute Workflow（Manual）還是外部觸發？Manual 走 Save manual executions，Production 走 Save successful / failed production executions，是三個獨立開關；（c）workflow Settings 若選「Default」就是吃 instance 的 EXECUTIONS_DATA_SAVE_* env var，如果 IT 把 instance 預設關了，選 Default 就等於關。想強制存要在 workflow Settings 明確選 Save。

6. Webhook 節點給我的 URL 是 localhost，外部叫不到

   Instance 沒設 WEBHOOK_URL，n8n 只知道自己 host 是啥。找 IT 加 WEBHOOK_URL=https://n8n.你的公司.com（含 protocol、含 domain），重啟。之後 Webhook 節點顯示的 URL 就會是正確對外可訪問的。

7. Error Workflow 沒被觸發

   幾個常見原因：（a）Error Workflow 本身沒 Active 打開；（b）Error Workflow 的 trigger 不是 Error Trigger 節點；（c）出錯的 workflow 的 Settings 沒指定這個 Error Workflow。三個一起檢查，詳見 第 17 章。

8. 改了 env var 但看起來沒生效

   環境變數不會 hot reload——改完 .env 或 docker-compose 之後要 docker compose down && docker compose up -d（或系統服務 restart）才會讀新值。restart 有時不夠（尤其改 docker-compose.yml），要完整 down + up。

常見問題