Why are Mac apps connecting to the internet in the background?

Does your Mac keep talking to the internet even when you’re AFK? Good news is most of that traffic is routine: update checks, signature checks, cloud sync, and crash reports. Yet a small share of it might be worth a second look. This guide explains what each kind of background connection is for, how to watch it, and how to cut off the ones you do not want.

Inside: a plain map of inbound and outbound traffic, and a reference table of the reasons apps go online. Then, the three native ways to see live connections, what the built-in firewall actually covers, and a four-step check for judging any single connection.

Where to start

This guide covers several jobs. Pick the one that brought you here.

What a background connection actually is

Only four words here define the topic.

Outbound means your Mac starts the conversation: an app opens a socket and reaches a server. Inbound means a machine on the network reaches toward your Mac. Foreground is the app you are looking at right now. Background is every process running without a window: daemons, agents, and helpers that start at login and keep going after you close the app that installed them.

The top-right cell is what this article is about. Background outbound traffic is the awkward case because macOS gives you solid tools to monitor it but no built-in way to stop it.

Those background processes are ordinary files on disk. macOS starts them from property lists in three folders:

~/Library/LaunchAgents

/Library/LaunchAgents

/Library/LaunchDaemons

launchctl list

The mechanism has worked this way since macOS 10.14 Mojave, so the folders above are worth knowing on any Mac still in use.

Why Mac apps phone home

Six reasons account for nearly every connection you will see. See the table below to figure the processes behind each one, the expected host, and the fastest way to confirm it.

trustd

syspolicyd

Updates are the second big source. Apps sold outside the App Store usually rely on the Sparkle framework, which fetches a small feed from the developer’s server on a timer. The check runs whether or not the app is open, because Sparkle installs its own scheduler.

The pattern to remember: these processes have no Dock icon and no window, and quitting the app they belong to often leaves them running.

When a background connection is a red flag

Four signals separate genuine trouble from routine noise. Check them in this order.

• An unsigned binary. Every app from a known developer carries a Developer ID signature, and macOS staples a notarization ticket to it. A process with no signature, an ad-hoc signature, or a signature that fails verification has skipped the one check Apple applies to the whole platform.
• An odd location on disk. Legitimate software lives in /Applications, /System or /usr. A process running from /tmp, /var/tmp, or a randomly named folder inside

  ~/Library/Application Support

  Copy

  is behaving like malware.
• A launch item you didn’t install. Open System Settings → General → Login Items & Extensions and read the background list. Apple labels entries it cannot trace back to a known developer as Item from unidentified developer, which is the fastest visual cue across the whole pane. Cross-check anything unfamiliar against the contents of

  ~/Library/LaunchAgents

  Copy

  ,

  /Library/LaunchAgents

  Copy

  , and

  /Library/LaunchDaemons

  Copy

  .
• A destination that is a bare IP address. Steady outbound traffic to a numeric address with no reverse DNS record, or to a port with no obvious purpose, is the shape of a command-and-control channel. Objective-See, the maker of the free LuLu firewall, explains that an outbound firewall exists precisely to catch the unauthorized outgoing connection malware needs to reach its server.

One signal on its own is usually explainable. A developer tool may be unsigned; a game may use an unusual port. Two or three together is when to act, which is what the four-step check further down is for.

How to see what your Mac is connecting to

macOS ships three ways to watch connections. They answer different questions, so it is worth knowing all three.

Activity Monitor: the readable view

1. Open Activity Monitor from Applications → Utilities.
2. Click the Network tab.
3. Click the Sent Bytes column header to sort by outgoing traffic.

Note:

Warning: The Sent Bytes and Rcvd Bytes columns count from the moment each process started, not from the start of the day or the month. Restart an app, and its figure drops back to zero. A browser open since Monday will always look worse than a sync agent that restarted an hour ago. The sync agent may still move more data over a week.

lsof: which process owns which socket

Terminal answers a narrower question. This command lists every open network socket together with the process that holds it:

lsof -i -P -n

Copy

Here is the explanation for each column. COMMAND names the process, PID is its process number, and the NAME column holds the local address, the remote address and the state. A row ending in (ESTABLISHED) is a live conversation; (LISTEN) means the process is waiting for an incoming connection instead.

When you run it without

sudo

Copy

, you see only processes owned by your account, which hides system daemons such as

trustd

Copy

and

syspolicyd

Copy

. The -P flag prints port numbers instead of service names. The -n flag skips the reverse DNS lookup, which otherwise stalls the command for several seconds per address. The result is a single snapshot, so short-lived sessions such as DNS queries often slip between two runs.

nettop: live traffic per process

Where

lsof

Copy

takes a photograph,

nettop

Copy

shows a moving picture, refreshing like Activity Monitor:

nettop -m tcp

Copy

Each process gets a heading with its PID, and the rows underneath are its current connections. Some destinations resolve to a hostname, others stay numeric, and both are normal. For a single snapshot that prints and exits, useful when you want to save the output rather than watch it, run

nettop -P -L 1

Copy

.

Read more:Task Manager for Mac: How to monitor and manage apps

Per-app data totals

System Settings → Network lists your Wi-Fi connection, Filters, and the Firewall, and stops there. macOS keeps no per-app data usage panel anywhere in System Settings, on Tahoe 26.6.2 or on macOS 27 Golden Gate.

Activity Monitor’s per-process counters are the closest native equivalent, with the reset behavior described above. For totals that survive a restart, you need a third-party monitor.

What the built-in firewall covers

macOS ships an Application Firewall, and it governs exactly one direction: incoming connections. Turning it on does nothing to stop an app from sending data out.

1. Open System Settings → Network → Firewall.
2. Read the description under the switch.

macOS states the scope in its own words: the firewall prevents unauthorized applications, programs, and services from accepting incoming connections. Every control behind Options… follows the same line: block all incoming connections, automatically allow built-in software to receive incoming connections, automatically allow downloaded signed software to receive incoming connections, and stealth mode. Apple’s support page confirms that this is the whole remit.

/Library/Preferences/com.apple.alf

sudo /usr/libexec/ApplicationFirewall/socketfilterfw –getglobalstate

macOS also carries pf, the BSD packet filter that replaced ipfw in 10.7 Lion. pf can filter outgoing traffic, and three things keep it out of reach for most people. Its rules are written by IP address and port rather than by app, so it cannot tell Chrome from a malicious helper. Apple ships no interface for it. And a ruleset does not survive a restart unless you write a launch daemon to reload it.

So the gap is a deliberate design choice rather than an oversight. Apple has never offered a simple way to block outbound traffic per app, and that is the space Little Snitch, LuLu, and FireWally fill.

How to control outbound connections

You have two levers. You can stop the background agent from starting, or you can filter the traffic it produces.

Stop the agent from launching

1. Open System Settings → General → Login Items & Extensions.
2. Select an entry under Open at Login and click the – button to remove it.
3. Switch off any entry under Background App Activity that you do not want running.

Note:

Note: Switching off a login item stops the agent from starting next time. An app already running keeps its connections until you quit it, so this is a way to reduce background traffic rather than to block it. Apple’s deployment guide covers how apps register these items and where users control them.

Filter the traffic with a network monitor

Since macOS 11 Big Sur, Apple requires these tools to run on the Network Extension framework as a System Extension rather than a kernel extension. Little Snitch 5 and later, LuLu, and FireWally all work this way. You approve the extension once, in System Settings → General → Login Items & Extensions → Extensions → Network Extensions.

macOS describes the category in that same sheet: network extensions run in the background and can monitor the network traffic on your Mac. The approval dialog is standard for every tool built this way, so it is not specific to any one product.

The move to System Extensions also settled an old split between Intel and Apple silicon. Kernel-extension tools needed Reduced Security, set from Startup Security Utility in Recovery, before macOS would load them on Apple silicon. Current tools load the same way on both architectures, with no trip to Recovery.

Where FireWally fits

FireWally is Nektony’s free network monitor, and it covers the gap the native tools leave. Activity Monitor,

lsof

Copy

and

nettop

Copy

show you traffic without stopping it. The macOS firewall stops traffic in the wrong direction. FireWally names the app behind each connection and gives you a switch for it.

The window groups traffic by app in real time, for the last hour, or for the day, with totals for data in and out at the bottom. Each row carries a switch, so cutting an app off from the network is one click rather than a rule you have to write.

The mode menu at the top sets what happens when an app you have never seen tries to connect. Pass lets new apps through, Ask prompts you each time, and Block denies them by default. Ask turns background traffic into an auditable list, so for each new app you will have an opportunity to decide if you want it to go online or not.

Clicking an app opens a short description of what it does and why it uses the network. That answers the question that stalls most people at a firewall prompt: allow or deny, when you don’t recognize the app’s name.

Read more:Little Snitch vs FireWally vs macOS firewall: Pros, Cons, and Use Cases

Normal or suspicious: a four-step check

Use the table to get a first reading, then walk the four steps for anything that looks off.

spctl

spctl

Step 1. Is it signed and notarized?

codesign

codesign -dv –verbose=4 /path/to/App.app

Two lines matter. Authority should name a Developer ID belonging to the company you expect, and Notarization Ticket=stapled confirms Apple has checked the app. Then ask Gatekeeper for its verdict directly:

spctl -a -vv /path/to/App.app

A result of accepted with source=Notarized Developer ID clears the app. A rejected result ends the check here: treat the app as one to investigate or remove, and skip the remaining steps.

Step 2. Can you name the host?

lsof -i -P -n

nettop -P -L 1

dig -x

whois

Step 3. Does the traffic match the app’s job?

Compare what you see against the reference table earlier in this guide. Dropbox holding an open connection to dropbox.com is exactly what cloud sync looks like. A note-taking app that reaches an advertising domain while minimized is not, and a valid signature does not explain it away.

Step 4. The verdict.

• Normal. Signed and notarized, a host you can name, a behavior that fits the app. Leave it alone.
• Investigate. One signal out of place. Keep watching it, search the process name, and hold off on blocking.
• Block. An unsigned or unnotarized binary, plus an unknown host, plus behaviour the app’s purpose does not explain. Cut it off with a network monitor and consider removing the app.

The bottom line

Background outbound traffic is the normal condition of a working Mac. Updates, signature checks, cloud sync, and crash reports account for the bulk of it, and macOS generates a fair share on its own before any third-party app joins in. The goal is to recognize that traffic, not to eliminate it.

lsof

nettop

That leaves one gap worth filling: a monitor that names the app behind each connection and lets you switch it off. FireWally does that for free, and Little Snitch, LuLu and Radio Silence cover the same ground with different trade-offs. Whichever you pick, run the four-step check before you block anything, and leave the four system processes that keep Gatekeeper and iCloud working untouched.