notice级别不记录路由变更事件，仅记录Nginx配置重载完成等进程生命周期动作，表明新配置（含location、proxy_pass等）已生效，是“变更已生效”的信号而非请求级路由追踪器。
notice 级别本身不记录路由变更事件，Nginx 的 error_log 在 notice 级别下只记录进程生命周期动作（如 master 启动、worker 生成/退出、配置重载完成），不包含 location 匹配或路由跳转过程。所谓“捕捉动态路由变更”，实际要捕获的是配置重载行为本身，而非每次请求的路由选择。
notice 级别能告诉你什么
当使用 nginx -s reload 或 systemd 触发配置热更新时，全局 error_log ... notice 会输出类似以下两行：
2026/04/14 13:10:22 [notice] 12345#0: signal process started2026/04/14 13:10:22 [notice] 12346#0: starting worker processes
这些日志表明 Nginx 已成功加载新配置——包括所有 location、proxy_pass、正则匹配规则等动态路由定义。也就是说，notice 是“变更已生效”的信号，不是“某次请求走了哪条 route”的追踪器。
如何把 notice 日志变成可监控的变更信号
单纯看日志文件不够实时，需配合轻量级监听与告警逻辑：
- 用
tail -f /var/log/nginx/error.log | grep "\[notice\].*starting worker"持续监听重载事件 - 将该命令封装为 systemd service 或 cron + lockfile，避免重复触发
- 搭配简单脚本提取时间戳和 PID，写入 Redis 或发送 webhook 到运维看板
- 若使用 Ansible/Terraform 更新配置，可在 play 结尾加
shell: nginx -t && nginx -s reload并记录部署 ID，再与 notice 时间对齐验证
真正需要观察路由行为时该怎么做
如果目标是确认某次请求是否命中了预期的动态 location（例如 location ~ ^/api/v\d+/(.*)$），notice 级别完全无能为力。此时应：
- 临时提升日志级别到
info（需确保编译含--with-debug）并配合grep "http.*phase.*location"过滤 - 在对应
server或location块中单独设置error_log /var/log/nginx/route-debug.log info，缩小范围 - 结合
access_log自定义格式，加入$request_uri和$host，再用日志分析工具（如 Filebeat + Elasticsearch）按前缀聚合统计
注意几个常见误区
有人误以为开启 notice 就能看到 “/v2/user → proxy_pass http://backend_v2” 这类映射日志，其实不会。Nginx 不在 error_log 中记录每次请求的匹配路径；它只在 debug 模式下极少量输出匹配过程，且仅用于开发排查。
另外，error_log 的 notice 输出无法区分是手动 reload 还是自动 reload（如 logrotate 触发的 USR1），建议在 reload 前写入标记：echo "[RELOAD $(date)]" >> /var/log/nginx/deploy.log，再与 notice 时间比对。
