Every device. Every domain. Your network.

Yes, and that is the expected deployment — Windows Server and Linux both. The desktop app has a window, so it needs a session to display in (a logged-in console, RDP, or a desktop environment on Linux). On a Linux server without one, use the headless mode below.

On a Linux server with no graphical session the desktop app prints Missing X server or $DISPLAY; nothing is wrong with the install. For that case the .deb (not the AppImage) includes a headless mode: it answers and records DNS the same way and serves the same screen to your browser. Run "/opt/Network TrafficWatch/trafficwatch-headless" — quote it, the path has a space; it prints the web UI address with a one-time token on 127.0.0.1 port 8053. Open it through an SSH tunnel — ssh -L 8053:127.0.0.1:8053 user@server — or an HTTPS reverse proxy, never as plain HTTP on an untrusted network. A systemd unit is installed next to it; it grants the service the right to open port 53, and you edit one line in it: --dns-host with the server’s LAN address, because systemd-resolved on Ubuntu already holds 127.0.0.53:53. Step by step: Run on a server without a desktop.

No, and that is deliberate. TrafficWatch records domain names only — that a device connected to youtube.com, not which video was played. Page contents travel inside HTTPS, and the only way to read them would be to install a root certificate on every device and decrypt their traffic. That is invasive, it breaks apps that pin certificates, and TrafficWatch does not do it.

Queries are logged and then forwarded to a real upstream resolver, so name resolution behaves normally. Two things are worth knowing. If the computer running TrafficWatch is switched off, devices pointed at it lose DNS — register a public resolver such as 8.8.8.8 as your router's secondary DNS so there is a fallback. And run it on a machine that stays on.

Mac App Store apps must run in Apple's sandbox as a normal user, and a sandboxed process cannot bind port 53. DNS has to be on port 53 because routers let you set a DNS server's IP address, not its port. An App Store build could be published, but it could not act as your network's DNS server — which is the entire product. So the macOS version is distributed directly as a notarised DMG signed with an Apple Developer ID, and Pro is licensed the same way as on Windows and Linux.

On macOS and Linux, yes — port 53 is a privileged port on both. On Windows, no: Windows does not reserve ports below 1024. On Linux you can avoid running the whole app as root by granting the binary CAP_NET_BIND_SERVICE instead; the headless service gets exactly that capability from its systemd unit.

On Linux this is almost always systemd-resolved: set DNSStubListener=no in /etc/systemd/resolved.conf and restart the service. On Windows, look for the DNS Server role, Internet Connection Sharing, or a local DNS proxy such as Pi-hole or AdGuard Home. On macOS, another resolver you installed yourself. TrafficWatch names the likely culprit for your platform when the bind fails. For the headless service on a server, you can leave systemd-resolved as it is and bind only the server’s LAN address with --dns-host — see the guide.

Find this computer's local IP address, open your router's admin page, and set the DHCP DNS server to that address. Devices pick it up when they reconnect or reboot. If your router does not allow changing DHCP DNS — some ISP-supplied units do not — you can set the DNS server manually on individual devices instead, though then you only see those devices.

Each distinct IP address that sends a DNS query. Free shows the first three it sees, in the order they were discovered, so the list does not shuffle around as devices get busy. Everything else is still recorded to disk — the sidebar tells you how many devices are being logged but hidden, and upgrading reveals them along with their past history.

A rule matches a domain in one of four ways: contains a string, is a domain or one of its subdomains, matches exactly, or matches a wildcard pattern. It can apply to every device or just one, and it can raise a desktop notification, send an email through your own SMTP server, or both.

There is deliberately no regular-expression option. Rules are evaluated on every DNS query, so one pattern with catastrophic backtracking would stall DNS forwarding and take your whole network's name resolution down with it. Suffix and wildcard matching covers domain watching without that risk.

One device can look up an ad domain dozens of times a second. Without limits that becomes thousands of emails, your mail provider throttles the account, and you learn to ignore the alerts entirely — which makes the feature worse than useless. Each rule can have a cooldown, an hourly cap, or a digest window that collects a burst into one message. Held-back queries are counted rather than discarded, and the count travels with the next message, so a quiet inbox never hides a busy network.

Only on your own computer, in a folder in your home directory. Nothing is sent to MeshWatch, to advertising networks, or to any cloud account. The exceptions are ones you set up yourself: alert email, which goes out through the SMTP server you configure, and — on Pro — a connection to your own MeshWatch Central server, which receives only the alerts your rules raise. Apart from those, TrafficWatch only checks meshwatch.app about once a day for a newer version, and that request carries none of your data.

After subscribing you receive a licence key by email. Paste it into the app and Pro unlocks on that computer. The key carries its own expiry date and is verified locally against a public key built into the app, so activation works offline and TrafficWatch never contacts a licensing server. When you renew, you receive a fresh key to activate.

Email support@meshwatch.app before the renewal date, or cancel from the receipt Stripe emailed you — the current key keeps working until its expiry date, and the free features continue after that.

Monitoring a network you own and administer is generally lawful. Monitoring other people's communications without their knowledge often is not, and the rules differ by country. Tell the people who share your network before you start, and on a company network follow whatever notice your jurisdiction requires. This is not legal advice; if the situation is at all delicate, get some.

Optionally, and on Pro. Connect TrafficWatch to your own MeshWatch Central server and its alerts join whatever ConfigWatch, CertWatch, DeviceWatch, SyslogWatch and TrapWatch are reporting into one shared inbox — a suspicious domain lookup from the same device that just triggered a SyslogWatch alert shows up as one incident, not two. This needs Pro because Central only ever hears about what an alert rule catches, and alert rules themselves are a Pro feature (see pricing above) — Free has nothing to report yet. TrafficWatch sends Central a one-line summary like “random-looking domain flagged on kitchen-tv” — never the DNS query log itself. Central is a separate product you run on your own server; TrafficWatch works exactly the same with or without it.