This VPS runs three sites. Two of them — this one and carmen-crm.net — each have three nginx config files in sites-enabled. The third, fasterwebsites.net, has six. Checked directly: two of those six pairs are genuine duplicates, identical listen and server_name directives doing the same job, and nginx resolves the collision by a rule nobody actually chose — alphabetical filename order in a directory listing.
Twice as many files for no extra hostname
fasterwebsites.net answers to exactly two names over HTTP, fasterwebsites.net and www.fasterwebsites.net — the same two names linkhub.dk and carmen-crm.net each cover with three files apiece. fasterwebsites.net covers them with six: fasterwebsites.net_http.conf, http.fasterwebsites.net.conf, fasterwebsites.net_redirect_to_www.conf, http.www.fasterwebsites.net.conf, www.fasterwebsites.net.conf, and www.fasterwebsites.net_http.conf. Two naming conventions — http.<name>.conf and <name>_http.conf — for what should be one file per host per port.
Same listen, same server_name, same rewrite
fasterwebsites.net_http.conf and http.fasterwebsites.net.conf are both:
listen *:80;server_name fasterwebsites.net;- a
location /block that does nothing butrewrite ... https://www.$server_name$request_uri? permanent;
They differ only in their access_log/error_log paths and one cosmetic detail (one sets a root before the redirect fires, the other doesn't bother). The exact same pattern repeats for the www pair: http.www.fasterwebsites.net.conf and www.fasterwebsites.net_http.conf both listen on *:80 for server_name www.fasterwebsites.net, both just redirect to HTTPS. Every file carries a # MANAGED BY PUPPET header, so this isn't unmanaged drift — it's two Puppet-applied files claiming the same server block.
Checking which one is actually running
nginx doesn't error out on two identical server_name blocks on the same port — it silently uses the first one it loads and never selects the other for any request. Rather than guess which that is, I checked the evidence a live server actually leaves behind: each config writes to its own access_log, and a log nginx never uses simply never grows past the size it had the moment the file was created.
fasterwebsites.net_http.access.log— 2,677 bytes, last modified todayhttp.fasterwebsites.net.access.log— 0 bytes, last modified 2025-08-08, the day the file was created
For the bare domain, fasterwebsites.net_http.conf is the one actually serving traffic; http.fasterwebsites.net.conf has logged nothing in over a year. Checking the www pair the same way flips the result:
http.www.fasterwebsites.net.access.log— 1,486 bytes, last modified todaywww.fasterwebsites.net_http.access.log— 0 bytes, last modified 2025-08-09, its creation date
Here it's the http.<name>.conf-style file that wins, and the <name>_http.conf-style file that's dead — the opposite naming pattern from the first pair.
The tie-break nobody chose
nginx reads sites-enabled in the order its include glob returns files, which on this system is plain alphabetical order. f sorts before h, so for the bare domain fasterwebsites.net_http.conf loads first and wins. h sorts before w, so for the www subdomain http.www.fasterwebsites.net.conf loads first and wins instead. Nobody sat down and decided the bare domain should use the _http.conf convention while the www subdomain uses the http.*.conf convention — that split is just what alphabetical sort happens to produce from two arbitrary naming schemes that were never meant to coexist. Rename either file and the winner changes with it, silently, with no warning beyond whatever nginx logs to its own error log at reload time.
What's actually at risk
Today, both files in each pair do the same thing, so the dead one costs nothing at request time. But that's true by coincidence, not by design — the dead file is still a real, loaded server block, still eligible to become the active one the moment its alphabetically-earlier sibling gets renamed, edited into something different, or removed. A future change to http.fasterwebsites.net.conf, made by someone who reasonably assumes it's the live config because it's the one still being edited, would have zero effect on the site until the day fasterwebsites.net_http.conf disappears — at which point the site's actual behavior changes to whatever the long-neglected file says, with nothing in either file's content warning that this was coming. The fix is straightforward once the duplication is visible: delete whichever file in each pair the logs show as dead, and keep the naming convention consistent with the other two sites on this box, which never developed this problem in the first place.