Reference
Classification
How Heimnull names the application behind each flow, with weighted rules, built-in rules, colors, and re-classifying stored history.
Heimnull labels every flow with an application (for example “YouTube”, “Microsoft 365”, “WireGuard”) and a category (Streaming, Productivity, VPN…), as it arrives. Configure → Classification is where you see and change how.
Everything that names traffic is a rule: conditions, a label, and a weight from 1 to 100. Of the rules whose conditions all hold, the highest weight wins. Ties go to the more specific match (a longer address prefix, then a narrower port range, then more conditions), then to your own rule over a built-in one.
Conditions
Section titled “Conditions”All are optional; every one you set must hold, and several values in one condition are alternatives.
- Addresses, or a live list (a service’s published ranges, or a cloud provider’s), on either side, the remote end, your end, the source or the destination.
- AS numbers and reverse DNS patterns (for example
*.1e100.net). - Protocols and ports: on the service side, either side, the matching address’s side, the remote end, your end, the source or the destination.
- Directions, interfaces, exporters and DSCP.
- Traffic shape: for flow records, the average packet size, a minimum volume or rate, a maximum rate and a minimum duration; for packet samples, their size.
- Refines: only when the other rules label the traffic as something else first, such as “Google” becoming “YouTube” for video-shaped downloads.
Built-in rules
Section titled “Built-in rules”Heimnull ships with rules for hundreds of services, each with the evidence behind it. Their weights keep this order:
| Evidence | Weight |
|---|---|
| Published service addresses (Microsoft 365, Zoom, Steam, Telegram, Tailscale, public DNS resolvers…) | 92–95 |
| Cloud provider ranges (AWS, Google Cloud, Azure, Cloudflare, Fastly, Oracle, GitHub, DigitalOcean) | 90 |
| AS numbers of known services, each checked against its registry record | 75 |
| Well-known ports and protocols (QUIC, HTTPS, DNS, WireGuard, SIP, game ports…) | 40–74 |
| Traffic shape refinements (YouTube and Meta video, Steam downloads) | 50 |
| Reverse DNS patterns | 35 |
| Voice-shaped UDP that nothing else named | 10 |
Built-in rules update with new Heimnull releases. Editing one marks it edited, and later releases leave it alone; Reset restores it. Built-in rules can be disabled, not deleted.
The service under a label
Section titled “The service under a label”Each flow also keeps the protocol underneath its label, from the built-in port rules: “YouTube” traffic is “QUIC (YouTube)” or “HTTPS (YouTube)”. The filter app QUIC finds QUIC traffic of every application, app YouTube YouTube over every protocol, and service QUIC the protocol alone.
The tabs
Section titled “The tabs”- Applications: each application with its category, company and every rule that sets or refines it.
- Rules: every rule, searchable and filterable, with the weight editable in place and each label’s traffic in the last hour. The rule editor’s preview runs the conditions over the last 1 to 24 hours of stored flows and shows what share of traffic it would take, from which labels, and what stays with higher weights. (Rules that use live lists or reverse DNS can’t be previewed, since those aren’t stored with flows.)
- Colors: the color of each application and category in every chart.
- Re-classify: apply the current rules to stored history.
Re-classify
Section titled “Re-classify”New rules apply to new flows at once. Re-classify rewrites stored history with the current rules, one day at a time, at low priority:
- only within the raw flow retention (30 days by default), since older data survives only in rollups;
- not for today, or for yesterday before 03:00 UTC, while late flows still arrive;
- at most the speed set under Settings → Ingest and lookups (200,000 rows a second by default).
Rollups older than the raw retention keep their old labels.
Unidentified shows the traffic no rule named, and starts a rule from any row.