Kill Port on Mac: lsof -ti Returns the Clients Too

The most common one-liner for killing a port on a Mac also killed a process that wasn't using the port the way I meant. On the Mac mini that runs this business, I started a Python web server on port 3000, opened one client connection to it from a second Python process, and ran kill -9 $(lsof -ti:3000), the answer with 1,255 votes on the main Stack Overflow thread. Both processes died. lsof -ti :3000 had returned two PIDs: the server that owned the port, and the client that was only talking to it.

That's the first of four things that went wrong in about 20 minutes of testing on macOS 26.4.1. The second: two servers held port 3000 at the same time, and killing one left localhost:3000 answering. "kill port mac" returned 124 Google autocomplete completions in our own collection today, led by "kill port mac command", "kill port in use mac" and "macos kill port", with 3000, 8080 and 8081 the most-named ports. Below is the command I'd use, what each popular variant actually selects, and what the 40 answers on that thread recommend.

The command that kills only the port's owner

# who is listening on 3000 (no DNS, no port names)
lsof -nP -iTCP:3000 -sTCP:LISTEN

# ask it to stop, then force only if it ignores you
kill $(lsof -t -iTCP:3000 -sTCP:LISTEN)
sleep 2
lsof -t -iTCP:3000 -sTCP:LISTEN | xargs kill -9

The part that matters is -sTCP:LISTEN. Without it, -i :3000 matches every TCP socket whose local or remote end is port 3000, which includes every client connected to your dev server. With it, lsof returns only the process that owns the listening socket. All of this ran without sudo, which is fine for a server you started yourself.

What lsof -ti :3000 returns when a client is connected

Here is the first probe. One Python http.server bound to 127.0.0.1:3000, one nc holding a connection to it:

$ lsof -i :3000
COMMAND   PID    USER   FD   TYPE  ...  NAME
Python  83546 sg-mini    3u  IPv4  ...  TCP localhost:hbci (LISTEN)
Python  83546 sg-mini    4u  IPv4  ...  TCP localhost:hbci->localhost:53544 (ESTABLISHED)
nc      83562 sg-mini    3u  IPv4  ...  TCP localhost:53544->localhost:hbci (ESTABLISHED)

$ lsof -ti :3000
83546
83562

$ lsof -ti tcp:3000 -sTCP:LISTEN
83546

nc turned out to be a poor test client, because it exits on its own when the server goes away. So I repeated the kill with a Python client that just holds a socket open and sleeps. kill -9 $(lsof -ti:3000) killed both the server and that client. In real use, the client is whatever has the page open. One answer on the same thread, with 4 votes, shows exactly that case: a Node server on 3000 and a process named Google holding two connections to it. I didn't reproduce the browser case myself, but lsof has no way to tell that process apart from the one you meant to stop.

Two servers on port 3000 at once

The second probe started the same Python server on 127.0.0.1:3000 and then a Node server (v26.8.1) with listen(3000) and no host. I expected Node to fail with EADDRINUSE. It didn't:

$ lsof -nP -iTCP:3000 -sTCP:LISTEN
COMMAND   PID    USER   FD   TYPE  ...  NAME
Python  84518 sg-mini    3u  IPv4  ...  TCP 127.0.0.1:3000 (LISTEN)
node    84532 sg-mini   12u  IPv6  ...  TCP *:3000 (LISTEN)

Node's documentation says that with the host omitted, it listens on the unspecified IPv6 address :: when IPv6 is available, and server.address() confirmed "::". That socket and Python's IPv4 loopback socket don't collide, so both bound. Then curl http://127.0.0.1:3000/ got Python's directory listing, while curl http://localhost:3000/ and http://[::1]:3000/ got Node. After I killed only Python, localhost:3000 kept answering, from Node.

So if you kill "the process on port 3000" by PID from a list you read earlier, and the page still loads, check whether there were two listeners all along. A third server did fail: a second Node listen(3000) got EADDRINUSE: address already in use :::3000, and a plain Python socket binding 127.0.0.1:3000 got [Errno 48] Address already in use. The -sTCP:LISTEN form lists every listener, so kill $(lsof -t -iTCP:3000 -sTCP:LISTEN) takes out both.

Why lsof -i | grep 3000 finds nothing

With both servers running, lsof -i | grep -c 3000 printed 0. Without -P, lsof replaces port numbers with names from /etc/services, and on macOS port 3000 is hbci. lsof -i | grep -c hbci printed 2. Most of the usual dev ports have names in that file:

Port	Shown by lsof without -P
3000	hbci
3001	redwood-broker
5000	commplex-main
8000	irdmi
8080	http-alt
8081	sunproxyadmin
8888	ddi-tcp-1
9000	cslistener
4200, 5173, 6379, 27017	the number (no entry)

Of the 16 ports I looked up, 12 have names, including 5432 (postgresql), 3306 (mysql), 8443 and 7000. Asking for the port directly with -i :3000 works either way, because lsof matches the number. Only the grep pattern breaks. -P keeps numbers and -n skips reverse DNS; neither changed the run time on a single local port here (0.02 s against 0.01 s).

Empty results and exit codes

When nothing is on the port, the variants fail differently. In zsh, kill $(lsof -t -iTCP:3000 -sTCP:LISTEN) becomes a bare kill and prints kill: not enough arguments, exit 1. The xargs kill form exits 0 and runs nothing, because macOS xargs already skips empty input (xargs on macOS covers why -r does nothing there). npx kill-port 3000 on a free port printed Could not kill process on port 3000. No process running on port. and also exited 0. In a script, check with lsof first rather than reading the exit code of the kill.

If lsof shows nothing but the port is still taken, the owner may be another user. Port 22 on this Mac answered nc -z 127.0.0.1 22, yet lsof -nP -iTCP:22 -sTCP:LISTEN without sudo printed nothing and exited 1. netstat -anv -p tcp showed the owner as launchd:1; netstat on Mac has the full comparison, where lsof without sudo saw 6 of 16 listening sockets.

What the 40 Stack Overflow answers recommend

I pulled every answer on "Find (and kill) processes listening to port 3000 on Mac" through the Stack Exchange API today. The question is from October 2010 and shows 5,219,258 views. Its 40 answers carry 11,137 votes between them.

• 24 answers combine lsof with a kill. 4 of them filter for LISTEN, and those 4 have 12 votes in total, one of them negative.
• 18 answers write kill -9 literally, with 9,941 votes between them. That includes the accepted answer (5,054 votes: lsof -i tcp:3000, then kill -9 <PID>) and the 3,387-vote answer that adds sudo.
• The 1,255-vote kill -9 $(lsof -ti:3000) and the 197-vote lsof -ti:3000 | xargs kill both send the signal to clients as well, as in my probe.
• 2 answers (215 and 63 votes) suggest npx kill-port.

The accepted answer is fine when you read the lsof output and pick the LISTEN line by eye. The danger starts when the PID list goes straight into kill. The npm package does better than most of the thread: the published kill-port 2.0.1 (June 2022, 2,550,702 downloads in the week to October 4) runs lsof -i tcp:PORT | grep LISTEN | awk '{print $2}' | xargs kill -9. In my run it killed the server and left the connected client alive. That client still showed up in lsof -nP -i :3000 afterwards, in CLOSE_WAIT, which can look like the port is still taken when it isn't; the listening filter ignores it. It still sends SIGKILL by default, which skips the server's shutdown handlers.

That's why I start with a plain kill. SIGTERM gave the Python server time to exit cleanly; it was gone within half a second. kill -9 is for a process that ignores SIGTERM, and when a shell reports zsh: killed it's because something sent exactly that signal (zsh: killed on Mac traces where that line comes from).

A function to keep in .zshrc

killport() {
  local port=$1 pids
  pids=$(lsof -t -iTCP:"$port" -sTCP:LISTEN) || { echo "nothing listening on $port"; return 1; }
  ps -o pid=,comm= -p "${pids//$'\n'/,}"
  echo "$pids" | xargs kill
  sleep 2
  lsof -t -iTCP:"$port" -sTCP:LISTEN | xargs kill -9
  return 0
}

It lists what it's about to stop, so you see the second listener if there is one, then sends SIGKILL only to whatever still holds the port after two seconds. The PIDs go through xargs because zsh doesn't split an unquoted variable on newlines, so kill $pids with two PIDs would fail. I tested it against the Python and Node pair plus a connected client: both listeners stopped and the client survived. Against a listener that ignores SIGTERM, the second pass killed it. It returns 1 when nothing was listening, unlike kill-port. Don't use it on a process that launchd started with KeepAlive, which will be restarted under a new PID; stop that with launchctl bootout instead.

FAQ

How do I kill a process on a port on Mac?

Run lsof -nP -iTCP:3000 -sTCP:LISTEN to see which process is listening on port 3000, then kill $(lsof -t -iTCP:3000 -sTCP:LISTEN) to stop it. Use kill -9 only if it's still there a few seconds later. The -sTCP:LISTEN filter matters: without it, lsof -ti :3000 also returns clients connected to the port, such as a browser, and kill stops them too.

Why does lsof -i | grep 3000 show nothing on Mac?

Without the -P flag, lsof prints port names from /etc/services instead of numbers, and macOS names port 3000 "hbci" (8080 is "http-alt", 5000 is "commplex-main"). Grep for the number fails while the process is listening. Add -nP to see numbers, or ask lsof for the port directly with -iTCP:3000.

Why is port 3000 still answering after I killed the process?

Two servers can listen on port 3000 at once on macOS when one binds the IPv4 address 127.0.0.1 and the other binds the IPv6 address ::, which is what Node does when no host is given. Requests to localhost reach the IPv6 one. lsof -nP -iTCP:3000 -sTCP:LISTEN lists both; kill every PID it shows.

Method: every command ran on 2026-10-07 between 10:35 and 10:55 KST on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253) as a normal user without sudo, with lsof 4.91, Python 3.14.7 and Node v26.8.1. The servers were python3 -m http.server and a minimal Node http server; the clients were nc and a Python socket that sleeps, not a browser. The browser case is from the cited Stack Overflow answer. The answer counts come from the Stack Exchange API (all 40 answers on question 3855127, classified by the commands in their code blocks), the kill-port command from the published 2.0.1 tarball on the npm registry (the GitHub main branch has since been rewritten, but no release has followed), and the download count from api.npmjs.org. The 124 autocomplete count is from our own Google suggest collection on the same day.