The congratulations page is not a celebration. It is NPM politely saying: 'a request arrived, but no proxy host you created matches the name it asked for.'
Few sights confuse like opening your domain and being congratulated by Nginx Proxy Manager — or worse, being shown a completely different service you also run. Nothing is hacked and nothing is possessed: NPM routes purely by the name in the request, and when no host matches that name it falls back to a default page. This page works through the mismatch causes in the order they actually occur, from the one-letter typo to the router quietly sending your traffic somewhere else.
Open the proxy host and read its Domain Names field character by character against what you typed in the browser. NPM matches literally: app.yourdomain.com does not cover apps.yourdomain.com, and the bare domain yourdomain.com is a separate name from www.yourdomain.com — add both to the host if both should work. Also confirm the host itself is enabled; a host toggled off for testing keeps its settings and silently stops answering, which has embarrassed many careful people.
A name can resolve perfectly and still go to the wrong place. Run nslookup app.yourdomain.com 1.1.1.1 and compare the answer with the public IP of the machine running NPM. The classic version of this fault: an old A record, a second server from an earlier experiment, or a wildcard record sending the name somewhere you forgot. Also test from your phone on mobile data — inside your own network, your router may hand you the internal answer while the whole outside world goes elsewhere, which is how a site 'works for everyone except me' and the reverse are both born.
If the page shown is another real service, two hosts are claiming overlapping names or one host lists the other's name in its Domain Names. Read the whole proxy host list top to bottom — NPM evaluates matches by name, and a stray name typed into the wrong host weeks ago will outrank your memory of the setup. Remove the name from the wrong host, keep one name on exactly one host, and the confusion ends. While you are there, delete test hosts you no longer use; yesterday's experiments are tomorrow's wrong-site bugs.
Two impostors remain. If your router forwards 80/443 to a different internal machine — an old server still plugged in — NPM never sees the traffic at all; the router's forwarding table, not NPM, decides whose door the internet knocks on. And once everything is fixed, browsers themselves can keep showing the old result from cache, especially where HSTS was enabled during testing. Prove the repair from a private window and from your phone on mobile data before declaring victory.
Read the symptom like a table. Congratulations page: NPM reached, no host matched — names or host status. A different own service: a name collision between hosts. Router or ISP page: the request never left for your server — DNS or forwarding. 502 Bad Gateway: the host matched, the internal service did not answer — that is the forward hostname/port guide in this series, a different and simpler fault. Four wrong pages, four different addresses for the fix. Naming which one you see is half the repair.
Wrong-page faults make instant sense once you have watched traffic flow through a working setup — the video shows the matching names doing their job.
▶️ Watch Full VideoThat is correct behaviour. An IP address carries no name, so no proxy host matches and NPM serves its default page. Hosts are matched by domain name, never by IP.
They should not. NPM will match one of them and the result looks random from outside. Keep every name on exactly one host; use that host's settings to reach the right service.
Almost certainly local DNS or browser cache on the PC. Your router or PC resolver is serving a stale answer. Test with a public resolver and a private window; time and a cache flush finish the job.