n8n定时触发器时间不对？自托管时区修复指南

问题现象：9am 触发的任务跑到了错误时间

如果你正在自托管 n8n，并且给 Schedule Trigger 节点设置了早上 9 点执行，但实际输出却显示它在完全不同的时间被触发——这不是你的 Cron 表达式写错了。

根本原因在于：自托管 n8n 的默认时区是 America/New York。当你没有主动配置时区时，n8n 会按纽约时间解释你的调度设置。也就是说，你以为在设置本地时间，实际配置的是美东时间。对于一个位于亚洲或欧洲的用户来说，这个偏差可能高达 8 到 13 个小时。

修复步骤：两步让调度回归本地时间

第一步：修改单个工作流的时区

打开出问题的工作流，进入右上角的工作流菜单，选择 Settings（设置）。在设置面板中找到 Timezone 选项，默认值显示为 America/New York。将其改为你所在的城市或对应的时区标识，保存后重新运行工作流。

工作流菜单入口

修改完成后，Schedule Trigger 中设置的 9am 才是你所在时区的早上 9 点。这是最直接的修复方式，适合只调整少量关键工作流的场景。

工作流 Settings 中填写的时区建议使用 IANA 时区数据库的标识符（如 Asia/Shanghai、Europe/Berlin、America/New_York），而不是 UTC+8 这类偏移量写法。原因是 IANA 标识符自带夏令时（DST）规则，能够在夏令时切换时自动调整偏移；而固定偏移量在实行夏令时的地区（如欧洲、北美）会导致一年两次的时间漂移。对纯粹位于无夏令时地区（如中国）的用户，两者结果相同，但统一使用 IANA 标识符是更稳妥的习惯。

第二步：设置全局时区变量

如果你有几十个工作流要逐一修改，第一步的做法显然不现实。n8n 支持通过通用时区变量来统一配置，让所有新建或未单独覆盖的工作流都继承同一个时区。

设置面板中的时区选项

在自托管环境（例如通过 Docker 部署）中，通常设置 GENERIC_TIMEZONE 环境变量即可完成全局配置。这样做的意义在于：不仅 Schedule Trigger 会跟随该时区，n8n 内部涉及时间戳、日志、表达式计算的部分也会保持一致，避免不同节点之间出现时间逻辑不一致的问题。

配置通用时区变量

完成设置后重启 n8n 实例。此后每个工作流默认使用你配置的本地时区，除非某个工作流在 Settings 中单独覆盖。

n8n 与环境时间相关的常用变量不止一个，理解它们的区别有助于避免配置遗漏：GENERIC_TIMEZONE 决定工作流层面（包括 Schedule Trigger、日志、表达式中的时间函数）使用的默认时区；TZ 则是操作系统/Linux 容器级别的时区变量，影响 Node.js 进程本身的系统时钟解读。在 Docker 部署中，只设置 GENERIC_TIMEZONE 而忽略 TZ，有时会导致运行日志的时间戳与调度触发时间仍然不一致。稳妥的做法是两者同时设置成同一个时区标识（如 Asia/Shanghai），并确保容器重启后通过 date 命令确认系统时间无误。

为什么这个坑很常见

n8n 自托管的默认 UTC-5 时区设定，对北美用户几乎没有感知差异，但对亚太和欧洲用户来说几乎是必然踩到的坑。更麻烦的是，Schedule Trigger 的执行日志会显示按本地时区换算后的时间，而你在节点里填写的又是另一个时区，两边对照时容易产生误判，以为是 Cron 表达式的问题。

解决思路其实只有一条：让配置时区和你的实际意图对齐。单工作流设置解决局部问题，通用变量解决系统性问题，两者配合使用效果最好。

n8n 工作流调试

对于团队协作场景，建议在项目文档中明确记录使用的时区变量，避免新成员部署时重复踩坑。如果工作流涉及跨时区的定时任务（例如定时抓取不同地区的 API），则需要按工作流粒度单独设置，而不是依赖全局变量。

Schedule Trigger 的 Cron 表达式本身并不携带时区信息，它只是一组「分时日月周」的字段。Cron 在哪个时区被解释，完全取决于执行它的运行环境默认时区。这与传统的系统 crontab 行为一致：同一个 0 9 * * *，在纽约服务器和上海服务器上触发的绝对时刻相差 12～13 小时。因此排查此类问题时，先确认「谁在解释这个 Cron」，再检查表达式本身，往往能更快定位。