Self-hosted Umami still gets blocked by adblockers if your subdomain is named umami

The Problem

I self-host Umami for my SaaS, ParserBee. The main reason I picked it: privacy-friendly, cookie-less, first-party analytics that adblockers supposedly leave alone because the script comes from your own domain. That last assumption turned out to be wrong, and the reason is the subdomain name itself. Writing it up because the fix is small and the failure mode is silent.

My Umami instance ran at umami.parserbee.com, so the tracker was loaded like this:

<script defer src="https://umami.parserbee.com/script.js" data-website-id="..."></script>

The EasyPrivacy filter list (used by uBlock Origin, Brave Shields, AdGuard, and most other blockers) contains a rule that matches the Umami tracker by hostname pattern, along the lines of:

||umami.*/script.js

It doesn’t target a specific company’s server. It targets any host whose subdomain is literally named umami serving a file called script.js. Which is exactly how most of us name things when self-hosting: umami.mydomain.com, plausible.mydomain.com, matomo.mydomain.com. The filter lists know this convention, and they have rules for it.

The result: every visitor with an adblocker never loads the script. No errors on your side, no console noise, nothing in the Umami logs. The traffic just quietly never shows up. I only caught it because signups were arriving from campaigns that Umami claimed nobody clicked; the server logs and Stripe disagreed with the analytics, and the server logs were right.

The Fix

Serve the same Umami instance from a second hostname that no filter list matches. No proxying, no renaming files, no changes to the Umami install itself. I added u.parserbee.com as an alias for the same service:

1. DNS record. A CNAME (or A record) for u.parserbee.com pointing at the same server as the existing umami.parserbee.com.
2. Reverse proxy. Add the new hostname to the existing Umami site config so both route to the same instance. I run Umami in Docker behind Coolify, where this is just adding a second domain to the service; on Nginx, Caddy or Traefik it’s one extra hostname in the site block. TLS certs get issued automatically in all of these.
3. Script tag. Change only the src. The website id stays the same, so historical data and new data land in the same place with no migration:

<script defer src="https://u.parserbee.com/script.js" data-website-id="YOUR-WEBSITE-ID" data-domains="app.parserbee.com"></script>

The dashboard can keep living at umami.parserbee.com. Blocklists only affect the tracker request in visitors’ browsers; visiting your own dashboard is unaffected. (data-domains is unrelated to the blocking issue, but set it anyway: it stops localhost and preview deployments from writing into production stats.)

After deploying, tracked page views immediately lined up with what the server logs had been showing.

Is Working Around a Filter List Okay?

Worth addressing directly. EasyPrivacy exists to block cross-site tracking, fingerprinting, and ad networks. Self-hosted Umami is none of those: first-party, no cookies, no cross-site anything, data stays on my own server. The rule catches it because of a naming convention, not because of what the software does. I see renaming a subdomain for first-party privacy-respecting analytics as fixing a false positive. If you’re proxying an actual ad-tech tracker through your domain to defeat blockers, that’s a different thing, and the lists tend to catch popular patterns for that eventually anyway.

Takeaways

• Self-hosting alone no longer hides analytics from filter lists. EasyPrivacy has hostname-pattern rules for Umami, Plausible, Matomo, and others.
• Don’t name the tracking subdomain after the tool. u., stats., data., anything generic is fine; umami., plausible., and analytics. are all matched or will be.
• The fix is an alias hostname on the same service plus a one-line script change. No data migration, since the website id never changes.
• If your analytics look low, check with uBlock Origin enabled before doubting your marketing. I doubted my campaigns for longer than the fix took.

I hit this while building ParserBee, an AI document parser that turns PDFs, images, and Office documents into structured JSON. If you ever need to pull clean data out of invoices or resumes without writing parsing code, take a look.