The fix offered in the writeup is to list `127.0.0.1:3000` twice inside one `upstream` block, with `max_fails=0` on both lines, then `proxy_pass http://app` [15]. (The source's own comment on that second line reads: yes, the same address twice.) The duplication is the whole mechanism, because `proxy_next_upstream` only retries the next peer in an upstream group, and a `proxy_pass` aimed at a literal host and port is a group of one [14].
`max_fails=0` is doing real work there too. The nginx default is `max_fails=1 fail_timeout=10s`, and the two entries are one process, so a single refused connect marks both peers down [16]. Without that override the retry path arms itself and then disarms itself on the first failure.
Now the arithmetic the config has to beat. The recorded timeline closes the port at t+0.01 and gets its first 200 at t+2.9 [8], which is 2.89 seconds of refused connects [1]. The quoted retry stanza allows three tries and a two-second connect timeout, and nothing in it delays or spreads those tries across a boot [2]. A refused connect is not a hanging connect, so the tries can be spent long before the process is back. The writeup does not publish a second curl loop after the change [2], so the residual 502 count is unknown. For the twice-listed peer to close a gap this wide, either the retry attempts have to be spread over the boot or the socket has to come back inside the budget. Neither is established by the config as printed.
The PHP-FPM variant is the one worth stealing regardless of the retry question. nginx serves the docroot itself and only `.php` reaches the app socket [11], so during a unit restart the static assets keep returning 200 while every dynamic request gets `ENOENT` from `fastcgi_pass` [12]. That is a deploy fault wearing an application fault's symptoms, and it is caused by a packaging decision most people make for good reasons: put the fpm master in the app's own systemd unit and logs, resource limits and lifecycle become per-app instead of pooled system-wide [13]. The bill for that arrives as an unlinked socket on every restart [12].
The symlink discipline itself is good craft and worth keeping. Two of the three obvious ways to move the pointer are broken, and the working form creates the link beside the target and renames over it, so an in-flight request finishes against the old tree while the next one gets the new one [5][6]. What that buys you is file consistency. It does not buy you a listener, because `restart` is stop then start [7]. Any deploy that ends with a single unit going down and coming up has a hole the width of your boot time, and the honest options run through overlapping processes rather than through retry directives.
