How to Fix a Reverse Proxy That Sends One Domain to the Wrong App After Adding a Catch-All Rule
A reverse proxy can send one domain to the wrong app when a new catch-all route matches more broadly or outranks the intended host rule.
This is narrower than a generic wrong-domain redirect or DNS problem. The key test is whether the correct domain still reaches the expected proxy IP and certificate but the proxy selects the wrong backend only after the new default route exists. Compare route matches and priorities before changing DNS, application base URLs, or certificates.
Prove the Catch-All Rule Changed the Backend Selection
Send the same domain request before and after disabling only the new catch-all or default route. Record the proxy access log, selected router or server block, backend address, response marker, and certificate.
A practical Nginx default-server guide warns that catch-all rules can capture traffic even when several explicit virtual hosts already exist.
If disabling the fallback immediately restores the intended app, keep DNS and the backend application unchanged. The next task is to make the specific route win without removing safe fallback behavior for unknown hostnames.
Check Whether the Specific Host Rule Still Matches Exactly
Compare the requested hostname with the intended route rule character for character, including subdomain, wildcard boundaries, trailing dots in test tools, and whether the rule listens on the same HTTP or HTTPS entry point as the catch-all.
A multi-app reverse-proxy guide shows that hostname rules select different backends only when the incoming host matches the rule the proxy actually loaded.
Fix an incomplete or mistyped host matcher before adjusting priority. Raising the priority of a rule that never matches only makes the configuration harder to reason about.
Compare Route Priority With the Catch-All
For proxies that support explicit or derived priority, inspect which rule wins when both the specific host and the broad fallback can match the same request. Record the evaluated rule, not just the configuration file order.
A Traefik catch-all example deliberately gives the fallback lower priority than real routes so specific services are evaluated first.
Set the fallback beneath every intended application route and retest. Do not solve the problem by assigning arbitrary huge numbers to every router; keep a simple documented priority scheme that survives future app additions.
Inspect the Default Server on Nginx-Style Proxies
On Nginx and similar configurations, determine which server block becomes the default for that listen address and port when no hostname match is found. The first loaded block can become the fallback if no explicit default is defined.
A focused Nginx troubleshooting article explains why unmatched hosts reach default servers instead of being silently rejected.
Use a neutral default response or error service rather than making a real application the fallback. That way an unknown or mistyped hostname cannot accidentally expose another self-hosted app.
Check HTTP and HTTPS Fallbacks Separately
A catch-all added for port 80 does not automatically behave the same way on port 443. TLS routing, SNI, separate entry points, or a second catch-all can cause only HTTPS requests to reach the wrong app.
A Caddy troubleshooting case describes a catch-all behaving differently by scheme and shows why the scheme-specific route needs to be tested directly.
Request both HTTP and HTTPS with the same hostname and record the selected handler. Fix the fallback on the affected entry point instead of changing the working protocol path.
Keep the Fallback Neutral and Re-Test Every Known Domain
After correcting match scope or priority, make the fallback return a neutral 404, 421, or controlled error page rather than proxying every unknown hostname into one production app. Then test each known self-hosted domain once.
A reverse-proxy architecture overview emphasizes that the proxy decides the backend after the request reaches the proxy, which is why DNS correctness alone cannot prove routing correctness.
The fix is complete when every known hostname reaches its intended app and an unknown hostname reaches only the neutral fallback. The related ZimaSpace article on a reverse proxy redirecting to another domain is the next branch when the proxy selects the right backend but the application later changes domains.
Frequently Asked Questions
Can DNS cause a catch-all route to win?
DNS can send the request to the wrong proxy IP, but once the correct proxy receives the intended hostname, route matching is a proxy decision. Verify both layers separately.
Should the catch-all proxy to a dashboard app?
Usually no. A neutral error target is safer because typos and unknown hostnames cannot accidentally expose a real administration or media application.
Why does only HTTPS reach the wrong app?
HTTPS can use a different listener, SNI path, certificate site, or fallback rule from HTTP. Test both entry points independently before changing global routing.
Recommended products
Support & Tips
More to Read
Can Plex Share a GPU With Another Docker Container?
Plex and another container can often access the same GPU, but you must test driver support, device mapping, video-engine load, memory, and recovery behavior.
How to Tell Whether a Plex Error Comes From the Client or Server
Reproduce the same item on another client, compare the session path, then collect server evidence only after scope tells you where the failure actually...
How to Configure Plex Cache and Transcode Temporary Storage
Protect persistent Plex state while placing transcode temp files on suitable local storage, then verify cleanup, free space, and restart behavior.
