notice级别日志仅记录Nginx配置重载完成（如“starting worker processes”），不包含路由匹配、proxy_pass跳转等动态行为，不能用于捕捉路由变更，仅可作为配置已加载的旁证信号。
notice 级别不能直接“捕捉路由变更”，它只记录配置重载完成这一动作，是变更已生效的旁证信号，不是路由匹配过程的日志。
notice 日志里实际能看到什么
当你执行 nginx -s reload 或 systemd 触发重载后，error_log 中 notice 级别只会输出进程级事件，例如：
2026/04/21 04:58:12 [notice] 12345#0: signal process started 2026/04/21 04:58:12 [notice] 12346#0: starting worker processes
这些日志不包含任何 location 匹配、proxy_pass 路由跳转、正则路径解析等网关层动态行为。它们只说明：Nginx 已加载新配置文件，所有定义的动态路由规则（如 location ~ ^/api/v\d+/）此刻已进入运行时。
- notice 不区分 reload 来源：可能是人工操作，也可能是 logrotate 发送 USR1、Ansible 部署脚本触发，日志本身无标识
- notice 不反映配置是否真正生效：如果新配置语法错误但
nginx -t漏检，reload 可能静默失败，而 notice 行仍会照常输出 - 同一行日志无法关联到具体变更内容：你无法从
starting worker processes推断出这次改了哪个upstream或新增了哪条rewrite
如何把 notice 行变成可用的变更观测点
关键不是“看日志”，而是把 notice 当作一个轻量级 hook 信号来消费：
- 用
tail -f /var/log/nginx/error.log | grep "\[notice\].*starting worker"实时监听，配合awk '{print $1,$2}'提取时间戳，写入监控系统或 Redis 计数器 - 避免重复触发：在监听脚本中加
flock或检查上一次处理时间戳，防止高频率 reload 导致告警风暴 - 与部署系统对齐：若用 Ansible 更新配置，应在
shell: nginx -t && nginx -s reload后追加lineinfile写入本次部署 ID 到临时文件，再让监听脚本比对时间戳 + ID，确认是“预期中的变更” - 注意 syslog 场景：若
error_log指向syslog:server=...，需确保远程日志服务支持按 facility/tag 过滤，且网络延迟不影响实时性
真要验证某次请求是否走了新路由，该怎么做
notice 完全无用，必须换路子：
- 临时开启 debug 日志：确认 Nginx 编译含
--with-debug，在对应server块中设error_log /var/log/nginx/route-debug.log debug;，然后grep "http.*phase.*location" /var/log/nginx/route-debug.log - 用
access_log辅助：自定义格式加入$request_uri、$host、$upstream_addr，再结合log_format中的$time_iso8601与 notice 时间对齐，反推哪些请求发生在重载之后 - 不要依赖全局
error_log ... info：info 级别在非 debug 编译版本中不输出 location 匹配细节，仅增加连接建立/关闭类日志，信息密度低
notice 的价值在于低成本确认“配置已加载”，但它本身不携带路由语义；一旦需要定位某次请求的真实路径选择，就必须切换到 access_log 分析或 debug 日志捕获——这两者成本、权限、编译依赖都不同，得提前规划好。
