Why People Start Asking

The question usually arrives attached to something small. The fan spins up while nothing is open. A metered connection burns through data overnight. An article about app telemetry lands in your feed and you realize you have never actually checked your own machine. macOS does not answer any of it out of the box: there is a great deal of software on a Mac, and almost none of it tells you where it goes.

• •

  Background noise: an app you are not using is clearly doing something, and you would like to know what

• •

  Bandwidth: a tethered or metered connection empties faster than the work you did explains

• •

  Curiosity after a headline: you read that some app collects more than you assumed, and you would rather check than take the article's word for it

• •

  A specific suspicion: one app feels chatty, and you want to find out whether that is true before doing anything about it

All four are the same request wearing different clothes. You want a list of destinations, attributed to the software that wanted them.

What You Can See

SplitTunnel answers it in one place. The Activity panel shows which app looked up which domain and where its connections are going, updating as connections happen. A row carries the time, the app that made the connection, the domain it reached, and whether that traffic went through your VPN or connected directly. Repeat visits to the same destination collapse into a single row with a count, so a chatty endpoint stands out instead of scrolling past.

It is worth being precise about what that is. This is a map of destinations, not a readout of contents. You see who your Mac is talking to, which app is doing the talking, and how often. What travels inside those connections is not part of the picture: SplitTunnel does not read the contents of your traffic, and almost all of it is encrypted in transit in any case. For most versions of this question the destination list is the answer anyway, because the interesting fact is usually that a particular app contacts a particular analytics company every couple of minutes, not what is in the message.

Most of What You Find Is Boring

The first look is busier than people expect, and that is normal rather than sinister. A modern Mac runs dozens of pieces of software with a perfectly good reason to reach the network.

• •

  Platform services: system components checking in, certificate and time services, push notifications

• •

  Update checks: apps, browsers, and their background helpers asking whether a newer version exists

• •

  Content delivery: the anonymous-looking hostnames that serve images, fonts, and video for the sites and apps you are actively using

• •

  Sync: cloud storage, notes, photos, and password managers doing the job you installed them for

• •

  Telemetry: analytics, crash reporting, and usage measurement, which is the category most people are actually looking for

An unfamiliar domain is a question, not a verdict. Plenty of legitimate services use names that mean nothing out of context, and plenty of tracking hides behind a name that sounds like infrastructure. The useful move is to search the name, notice which app is attached to it, and see how often it comes back.

Four Questions Worth Asking About a Row

1. Which app made it? Attribution is the difference between a domain and a decision

2. Does that app need it for the job you keep it for? Sign-in, sync, and downloads are worth leaving alone

3. How often does it repeat? Something contacted constantly while the app sits idle is a different animal from one check at launch

4. What would blocking it cost? A rule applies to the whole Mac, so if a shared service sits behind that name, other software loses it too

Turning a Decision Into a Rule

The point of looking is that you can act in the same window, calmly, on something you have actually seen. There are two ways to add a rule, and they suit different moments.

When you already know the name and have no need to go hunting for it, the other route is quicker: open Domain Rules, click Add Domain, type the hostname, and click Block. Both routes write to the same list, and Unblock in that list reverses either one.

When the App Is the Answer, Not the Domain

Sometimes the honest conclusion is not one destination but one program. Domain rules are machine-wide by design: a blocked name stops resolving for everything on the Mac, and there is no version that blocks it for one app while allowing it elsewhere.

So when the thought is closer to "this app should stop talking to the internet", the tool is the app-level block in the Apps panel, which cuts that app's network access entirely. Domain rules and app blocks are separate controls on separate axes, and most setups end up using both: a short list of names you decided against, plus a couple of apps you keep installed and offline.

What This View Does Not Show

• •

  Contents: destinations, attribution, and frequency, not what is inside a connection

• •

  Every curated-list block: with the curated blocklists switched on, not every domain they catch appears as its own row in this version, and those lists do not take per-domain exceptions

• •

  Names that were never looked up: software connecting straight to an IP address involves no name, so there is nothing there for a domain rule to act on

• •

  Lookups a browser sends over its own encrypted DNS: those go around the system resolver, so rules do not reach them until you turn on Block Encrypted DNS in the Strict Mode section of Settings, and software that pins its own resolver by IP address stays out of reach even then

Answering the question once changes how the machine feels. Most people look, find that four fifths of it is exactly what it should be, block the two or three things they are confident about, and go back to work with a clearer picture than they had that morning. That is a quieter outcome than the question tends to imply, and it is the usual one.