In this article
The distinction is useful when an app transfers data but the Network tab does not answer where the connection goes. Keep three questions separate: which process moved data, which endpoint is visible now, and what that activity means. Each needs different evidence.
Start with the native view
Open Activity Monitor from Applications → Utilities or Spotlight, then choose Network. Compare the relevant process's sent and received data while performing one ordinary action in the app. Apple's network activity guide explains the data, packet and throughput views.
Use the process name and PID to keep your next check specific. Apple's process-view guide also explains searching, adding columns and showing processes hierarchically. An application may use helpers, so the visible window's main process is not necessarily the one opening a connection.
| Tool or observation | Useful for | Does not establish |
|---|---|---|
| Activity Monitor network counters | Finding activity and comparing data movement | The contents of an encrypted request |
A PID-filtered lsof snapshot | Sockets visible for one process now | Every earlier or future connection |
TCP LISTEN state | A socket waiting for connections | An active transfer to an internet server |
TCP ESTABLISHED state | A currently established TCP connection | Whether useful data is moving at that instant |
| A destination IP and port | An endpoint to investigate | The user's document, exact company or purpose |
If the question is only which process is busy, the native view may be enough. Use the next step when you need endpoint details.
Filter one process correctly
In Terminal, run /usr/sbin/lsof -nP -a -p PID -i, replacing PID with the current numeric process ID from Activity Monitor. Do not type the letters PID literally.
The command combines four choices:
-nPkeeps network addresses and ports numeric instead of resolving names.-p PIDselects the process ID.-iselects internet-family network files, including TCP and UDP sockets.-acombines those selections with AND, keeping the network results tied to that PID.
That last option matters. The upstream lsof tutorial describes how selection options combine. Leaving out -a can broaden a command beyond the process-and-network intersection you intended. Check man lsof on your Mac for its installed version's details.
Read the process identity and the NAME column together. An established TCP row commonly contains a local address and port, an arrow, a peer address and port, and a state. Numeric output avoids a hostname lookup adding another layer of interpretation.
This is a read-only inspection. There is no need to quit an unknown process or change a firewall rule to see the listing. If an app restarts, find its new PID before repeating the query.
What a controlled local test showed
We tested the PID-filtered TCP form on macOS 15.7.5 on September 24, 2026. A small test process created a listener on the loopback address, connected a client to it, then closed its own sockets. We inspected only that process; no unrelated app traffic was collected.
The observations were:
| Test stage | Visible result | Interpretation |
|---|---|---|
| Listener created | 127.0.0.1:54921 (LISTEN) | Waiting locally; no connected peer in this row |
| Client connected | 127.0.0.1:54922 → 127.0.0.1:54921 (ESTABLISHED) | The client side of a connection on the same Mac |
| Connection accepted | 127.0.0.1:54921 → 127.0.0.1:54922 (ESTABLISHED) | The server side, in the same test process |
| All test sockets closed | No matching rows | Nothing matching remained at the next observation |
The port numbers are the actual ephemeral ports from this test; yours will differ. The experiment did not connect to an external server. It demonstrates an important limit: even an ESTABLISHED row can describe local communication, and two rows can represent the two ends of one local connection.
Do not treat every listed socket as a separate upload to the internet. Protocol, address and state belong in the interpretation together.
An empty result is only an empty snapshot
A quick connection can open and close between checks. A helper may own the socket instead of the process you selected. Your account may not be able to inspect every process. These are reasons to narrow the investigation, rather than conclude that an app never connects.
Repeat the same ordinary app action while checking the current PID. Record the observation time and what you did. A command restricted to TCP, such as adding -iTCP instead of -i, will not show UDP; do not use that narrower result to make an all-protocol claim.
Similarly, a high byte count in Activity Monitor and an empty current socket listing are not necessarily contradictory. A counter and a momentary list describe different aspects of activity. Neither alone provides a complete history before monitoring started.
If the process runs after its main window closes, investigate background operation separately from login behavior. If an inspection tool merely lists a network capability, remember that an entitlement is a declaration with its own meaning, not a record of a particular transfer.
Interpret destinations cautiously
An unfamiliar IP can belong to shared infrastructure. A port commonly associated with HTTPS does not by itself verify encryption, identify the ultimate service or reveal the payload. A connection list cannot tell you which document or message was sent.
Write down the process, endpoint, protocol, state, time and app action before looking for explanations in the vendor's documentation. Share only the details necessary for a support request; endpoint lists can reveal private services or local infrastructure.
Keep observations with the app
VaultDog's Network Watch records visible destination metadata and associates it with installed applications when possible. It keeps a rolling 30-day history locally, which helps compare observations across separate sessions without manually preserving every command output.
The getting started guide explains the workflow, and the privacy page covers local data handling. Network Watch does not read HTTPS content, block connections or reconstruct a complete history from before observation began. An app association and a destination are starting points for review, not a verdict that the software is safe or malicious.
For a useful final note, keep the question narrow: “This process had this endpoint at this time during this action.” That statement is testable and gives you a clear next step without claiming more than the observation supports.
