Does nginx support atomic rollback of upstream configuration after reload

The goal is to change upstream definitions in nginx and be able to revert safely if the new configuration is not viable, without leaving stale backend references or interrupting in-flight requests.

Reload via SIGHUP is documented to replace worker processes while preserving existing connections and applying new configuration. A syntax error in the new configuration can cause workers to exit, requiring manual restoration of the previous configuration. The include directive enables modular configuration files, but inter-dependencies between included blocks can produce unexpected behavior when a new configuration references directives that are removed on rollback. Zero-downtime changes are discussed for log reopening, while core configuration changes are treated differently.

An unresolved design question remains around atomic configuration swaps without service interruption, a capability that has been requested in community discussions but is not present as a stable documented feature. Does nginx provide a built-in mechanism to revert to the previous configuration automatically if a reload fails? Which guarantees exist for existing connections when upstream groups are renamed or removed? When is a full restart required versus reload for changes to upstream definitions?