Most reverse proxies like Nginx or Traefik handle domain rules in the order you write them or by using those annoying "priority" tags. If you have overlapping wildcards, like `*.myapp.test` and `api.myapp.test`, you usally have to play "Priority Tetris" to make sure the right rule wins.

I wanted something more deterministic and intuitive. I wanted a system where the most specific match always wins without me having to tinker with config weights every time I add a subdomain.

I ended up building a Reverse Radix Tree. The basic idea is that domain hierarchy is actualy right to left: `test` \-> `myapp` \-> `api`. By splitting the domain by the dots and reversing the segments before putting them in the tree, the data structure finaly matches the way DNS actually works.

To handle cases where multiple patterns might match (like `api-*` vs `*`), I added a "Literal Density" score. The resolver counts how many non-wildcard characters are in a segment and tries the "densest" (most specific) ones first. This happens naturaly as you walk down the tree, so the hierarchy itself acts as a filter.

I wrote a post about the logic, how the scoring works, and how I use named parameters to hydrate dynamic upstreams:

[https://getlode.app/blog/2026-01-25-stop-playing-priority-tetris](https://getlode.app/blog/2026-01-25-stop-playing-priority-tetris)

How do you guys handle complex wildcard routing? Do you find manual weights a necesary evil or would you prefer a hierarchical approach like this?

I got tired of manual priority weights in proxies so I used a Reverse Radix Tree instead