What 0.0.0.0 Means on a Mac Listener

A listener is a socket waiting for connections. Its local address describes where it is bound, rather than a remote destination that an app has contacted. That distinction matters when a local development server or an unfamiliar helper appears beside an asterisk.

Inspect the listener before acting

Open Activity Monitor, choose View → All Processes, and find the process you want to inspect. Use its current process ID, or PID. If a helper owns the socket, inspect that helper's PID; the main application's PID may show nothing relevant.

In Terminal, run /usr/sbin/lsof -nP -a -p PID -iTCP -sTCP:LISTEN, replacing PID with that number. This is a read-only query of the process's visible TCP listeners. It does not connect to the service, stop the app or change its firewall settings.

The options keep the output focused: -nP preserves numeric addresses and ports, -p selects the process, and -sTCP:LISTEN selects the listening state. The -a is important because it combines the selections with AND. The upstream lsof tutorial explains how its selection rules combine; man lsof shows the documentation for your installed version.

If you know only the port, /usr/sbin/lsof -nP -iTCP:8080 -sTCP:LISTEN can identify visible listeners on port 8080. Replace 8080 with the port you actually observed. Finding its owner is the next step, not a reason to terminate it automatically.

Read the address family with the address

Look at both the TYPE and NAME columns. An asterisk alone loses a useful distinction:

Python's official socket address documentation describes the IPv4 wildcard as binding to all interfaces and distinguishes IPv4 from IPv6 address forms. Here, “all interfaces” describes the socket's address selection. It does not promise that a packet from every possible network can reach it.

Do not assume an IPv6 wildcard also accepts IPv4 traffic. That needs evidence about the socket configuration and platform behavior. Similarly, a loopback row describes that socket, not every other listener the application might have. Another socket or a forwarding service could create a separate path.

This article's command and examples concern TCP. UDP does not use TCP's LISTEN state, so an empty result is not a complete inventory of an application's networking.

Four bindings, checked on one Mac

On October 6, 2026, we created four short-lived TCP listeners, one at a time, in a controlled local process on macOS 15.7.5. Each listener requested a different bind address. We then queried that process with the command above.

The ports were assigned for this test; they are not recommended settings. The useful comparison is that two different address families produced the same asterisk shorthand. Keeping TYPE in the record preserves the distinction.

We closed every test socket and confirmed that the final process-scoped listener query returned no matching rows. The experiment did not accept connections or test access from another device. It establishes how these bindings appeared in this Mac's local output, not whether a particular home router, firewall or internet path would allow access.

Separate binding from reachability

A wildcard listener is a reason to understand the service's intended audience. It is not proof that someone has connected, that data was uploaded or that the public internet can reach the port.

Reachability also depends on the path to the Mac and the filtering along that path. Apple's Mac firewall guide documents controls for incoming connections. A local socket listing cannot tell you how every router, network boundary or forwarding rule on a possible path behaves.

Service authentication is another question. An address does not show whether a reachable service requires a password or what an authenticated user could do. Avoid translating “listening” directly into either “unsafe” or “safe.”

If you need a reachability test, define the service, protocol, port and source device first, and test only systems you own or have permission to assess. A test from the same Mac answers a narrower question than one from another network. One failed test does not establish that every possible path is blocked.

The macOS Local Network permission is also a separate layer. See why Local Network access and internet access differ before interpreting a privacy switch as a complete network policy.

Decide whether the listener belongs there

Identify the app and the feature that needs the service. A sharing feature, development server or companion-device workflow can explain a listener, but the process name alone does not establish its purpose.

For a service you configure, consult its documentation. If it is intended for use only on this Mac, a documented loopback-only setting may be appropriate. Verify the resulting listener after changing that app's setting; do not assume a setting name proves the actual bind address.

For an ordinary app you recognize, saving work and quitting it normally is a simple way to see whether its listener disappears. A persistent helper may have a separate lifecycle. Do not disable an unknown system process just to remove a row, and remember that restarting an app can give it a new PID.

For a support request, record the app version, observation time, PID, address family, local address, port and feature in use. Review raw output for personal paths before sharing it. That record is more useful than “an asterisk appeared.”

If the question is instead where the app is connecting, use the process-scoped connection guide. If the concern is encryption, a port number such as 443 is another separate observation. None of those answers can be read from a wildcard listener alone.

Sources behind the checks

• Python socket documentation: address families and wildcard binding.
• lsof tutorial: combining process and socket selections.
• Apple's firewall guide: incoming-connection controls, distinct from binding.