Here is what actually happens when nginx reads `proxy_pass https://example-backend.tld/api/lead-capture`: it resolves that name during config parsing and treats a lookup failure as a fatal configuration error [7]. The parse that matters here is the one the packaged unit runs as `ExecStartPre=/usr/sbin/nginx -t`, so a name that does not resolve for one second means the process never reaches the point of binding port 80 [8]. The request path was never involved at all; the site had no traffic to that backend at 06:49, only a config test [5].
The window came from the upgrade itself. `apt-daily-upgrade.service` started at 06:49:44, systemd requested re-execution nine seconds later because it had just upgraded itself, and `certbot.timer` fired in the same second [10]. According to the author, the re-exec took the local resolver with it momentarily, and anything restarted inside that gap had to survive without DNS [11]. This was the default upgrade timer on a default Ubuntu install against a default nginx package; the only odd thing was the hour [14]. Which is a poor hour for a nightly job, mostly on the grounds that it is not night.
The arithmetic is where the story stops being about DNS. The lookup failed for about a second and the outage ran seven hours and forty minutes [19], roughly 27,600 seconds of downtime for one second of unavailable name service [4]. A watchdog on another site alerted 9 minutes 26 seconds after nginx stopped [2]. The human start came 7 hours 30 minutes 12 seconds after that alert [3], which is about 98 percent of the total [6]. For the seven hours to transfer to your box you need two properties, not one: a literal upstream inside an enabled site file, and nobody acting on the page between 07:00 and 14:30.
The config fix is documented and cheap. Put the upstream in a variable and nginx defers resolution to request time, which requires a `resolver` directive; the author uses `resolver 127.0.0.53 valid=30s ipv6=off` with `set $backend` [15]. The trade is the point: a startup DNS failure takes every page on the server, a request-time DNS failure takes one endpoint [16]. An upstream written as an IP or a unix socket carries no DNS lookup at startup at all, so it never becomes a startup dependency [18]. Auditing for this is a `grep -rn "proxy_pass"` across both `sites-available` and `sites-enabled`, and the author notes his first grep returned nothing because it had not followed the symlinks [17].
Above that sits the packaging default. nginx ships with `Restart=no`, so a failed start stands until a person intervenes [20]. The drop-in sets `Restart=on-failure`, `RestartSec=15`, `StartLimitBurst=40` and `StartLimitIntervalSec=600` [21]. Note the numbers: 40 attempts at 15 seconds is exactly 600 seconds [5], so the retry budget and the rate-limit window coincide at the boundary, which is a thing to reason about before an incident rather than during one. The author's stated reason for capping it is that an unbounded restart on a genuinely broken config is a service lying about its state [23]. He also says the policy has so far been verified only by reading `systemctl show` [24]. Until someone breaks resolution deliberately and watches the unit come back, that drop-in is a claim about documented behaviour, not a tested recovery path.
