Phase order is the mechanism under three of these findings, and it is invisible in the file. nginx does not walk a location block top to bottom when a request arrives. Directives belong to modules, modules are bound to phases, and the phase sequence is fixed. Moving `return` below `deny all` therefore changes nothing [15]. The author points at the older "if is evil" advice as the same root cause: directives from different modules run in an order that has nothing to do with the order you typed them [16].
The repair for the `/health` case is worth reading closely, because it is a phase trick and not a reordering. `try_files /nonexistent @health` pushes the canned response behind an internal redirect, and `try_files` runs in the content phase, after access has been evaluated, so a client outside the allow list collects its 403 before the redirect is considered [17]. The post pairs it with `open_file_cache max=10000 inactive=60s` and `open_file_cache_errors on`, because a bare `try_files` pays a filesystem lookup per candidate on every request, which gixy flags on its own [18].
On the stapling side the suggested lines are `resolver 127.0.0.1 valid=300s ipv6=off` and `resolver_timeout 5s`, aimed at a local resolver or a cloud provider's internal DNS [6]. That `valid=300s` is a five minute cache on the answer [19]. Pointing the same directive at 8.8.8.8 also works, and sends every internal lookup off your network in cleartext [7].
Verification does not come from nginx. `echo | openssl s_client -connect example.com:443 -servername example.com -status` prints `OCSP Response Status: successful` when stapling works, and `no response sent` when it does not [8]. The condition on reading that output: the first handshake after a reload usually goes out unstapled while nginx fetches in the background, so a single failing probe is a timing artefact until the second one agrees [9]. If the certificate came from Let's Encrypt, no resolver will move the result either way [10].
The general claim is the maintainer's, and it is the load-bearing one: static analysis is the only practical way to catch a failure that produces no signal at runtime, and a growing share of gixy-ng's checks exist for that category [2]. I think that is right, with a qualification. A linter only catches shapes somebody has already encoded. The inheritance rule is the good example of what makes this hard: access rules pass down from an outer context only when the inner context defines none of its own, so one `allow 172.16.0.1` inside a location silently discards the server's `allow` plus its `deny all` [13]. Seeing that requires holding two contexts in view at once, which is what a reviewer skims and a parser does not.
The post promises four of these [20]. The copy available to me works through three and breaks off mid-sentence as the author introduces the fourth as his favourite [21]. I would like to know what it is.
