nginx 本身不提供定时任务功能，需依赖外部工具实现：推荐用系统 cron 调用 curl 触发后端接口；lua 定时器因多 worker 不一致且不可靠，不适用于业务级定时任务；集群环境下应使用 redis+celery 等集中调度平台，nginx 仅作流量入口。
Nginx 本身不提供定时任务功能，它是一个高性能的 HTTP 服务器和反向代理，没有内置的 cron 或调度器。所谓“Nginx 的定时任务”，实际是通过外部工具配合 Nginx 实现的间接方案。
下面介绍几种常用、可靠且生产环境验证过的实现方式：
用系统 cron 驱动 curl 或 wget 触发接口
这是最常见也最推荐的方式：把定时逻辑放在后端应用（如 PHP/Python/Node.js），Nginx 只负责将请求转发过去；用系统的 cron 定时调用该接口。
- 在你的 Web 应用中写一个无需登录、带简单校验（如 token）的管理接口，例如
/api/cron/cleanup - 配置 Nginx 允许该路径被访问（注意限制来源 IP 或加 header 校验）
- 在服务器上添加 cron 任务：
0 2 * * * curl -s "https://your-site.com/api/cron/cleanup?token=abc123" > /dev/null
用 Nginx 的 stub_status + 自定义模块（不推荐）
Nginx 官方模块不支持定时执行代码。虽然有第三方模块（如 nginx-module-lua）可通过 ngx.timer.at 实现延迟/周期性回调，但它运行在 worker 进程内，不具备全局唯一性和持久性，不适合做真正意义上的定时任务（比如每天只执行一次清理）。
- Lua 定时器是每个 worker 独立运行的，5 个 worker 就可能触发 5 次
- 进程重启后定时器丢失，无法保证准时或仅执行一次
- 适合做毫秒级轻量轮询（如健康检查），不适合业务级定时任务
用外部服务统一调度（适合集群环境）
当有多台 Nginx + 后端服务器时，应避免每台机器都跑一套 cron，改用集中式任务调度：
- 部署 Redis + Celery 或 XXL-JOB、Apache DolphinScheduler 等调度平台
- 所有节点监听同一任务队列，由调度中心决定何时、在哪台机器上执行
- Nginx 仅作为流量入口，把调度平台的回调请求路由到对应服务
别把 Nginx 当作任务调度器来用
有人尝试用 log_format + 日志轮转、或用 access_log 配合定时切割模拟“定时行为”，但这只是日志管理，不是真正的任务执行。Nginx 的设计哲学是“专注请求处理”，定时任务属于业务层或运维层职责。
- 强行在 Nginx 层做调度会增加维护复杂度，降低可观察性
- 出问题时难以调试（比如 Lua 定时器没触发，你得查每个 worker 日志）
- 升级、reload、扩容都会影响定时逻辑稳定性
不复杂但容易忽略：定时任务的本质是“谁来触发”和“在哪执行”。Nginx 可以参与其中（作为网关或反向代理），但不该承担调度角色。
