Why Node Crashes With EADDRINUSE After Restart and How to Fix It

You stop your Node server, fix a small line of code, and start it again. Instead of the friendly ready message, the terminal shows an error: EADDRINUSE: address already in use. The port you were using only seconds ago now refuses to let your server start.

This error is extremely common in daily development, especially when a server is stopped with a keyboard shortcut, a terminal window is closed without a clean shutdown, or a tool restarts the server automatically. The good news is that the cause is simple and the fix takes less than a minute once you know how to find the process holding the port.

Quick Answer

The EADDRINUSE error means another process is already using the port your Node server wants, usually an older copy of your own server that never fully stopped. Find that process, stop it, and start your server again. On Windows use netstat -ano and Task Manager or taskkill, on macOS and Linux use lsof -i :3000 and kill. As a quick workaround, you can also start your server on a different port.

What EADDRINUSE Actually Means

When a server starts, it binds to an address and a port, such as port 3000. Only one process can listen on the same address and port at a time. That rule protects programs from stepping on each other. When your new server tries to bind and finds the port taken, Node reports the error code EADDRINUSE and the server exits.

Restarting triggers it so often because the old process does not always die when you expect it to. Pressing close on a terminal window, a crashed watcher, a parent process that spawned the server as a child, or a development tool that restarts in the background can all leave a hidden listener behind. The port also stays briefly in a waiting state after some shutdowns, though a lingering old process is by far the most common reason.

Fix It on Windows

1. Open Command Prompt or PowerShell.
2. Find the process using your port. For port 3000, run netstat -ano | findstr :3000.
3. Note the number in the last column. That is the process ID, or PID.
4. Stop it with taskkill /PID 1234 /F, replacing 1234 with your PID. You can also open Task Manager, find the Node process with that PID, and end it there.
5. Start your server again with your normal command.

Fix It on macOS and Linux

1. Open the terminal.
2. Find the listener on your port with lsof -i :3000. Change 3000 to your actual port if it is different.
3. Note the PID shown for the Node process.
4. Stop it with kill 1234, using your PID. If it refuses to stop, use kill -9 1234 as a last resort.
5. Run your server again and confirm it starts cleanly.

The official Node documentation and its error reference are collected on the Node.js documentation site, which is a useful bookmark when other runtime errors appear.

The Quick Workaround: Use Another Port

When you are in a hurry, changing the port is a valid short-term fix. Many projects read the port from an environment variable, for example const port = process.env.PORT || 3000. Starting the server with a different value, such as 3001, lets you keep working immediately. Just remember that this leaves the mystery process running, and it can confuse you later when an old version of your app answers requests on the original port while you test the new one. Cleaning up the old process is always the better habit.

If you are setting up a project for the first time, our guide on how to create your first Node.js server step by step shows a clean project layout that includes sensible port handling.

Prevent the Error From Coming Back

Stop Servers Gracefully

Stop your development server with Ctrl + C in the terminal where it is running and wait for it to exit before closing the window. This gives Node a chance to release the port properly. Avoid closing the whole terminal or killing the editor as your normal way of stopping a server.

Be Careful With Auto-Restart Tools

Tools that watch files and restart the server are wonderful, but running two watchers at once, or a watcher plus a manually started server, means two processes fighting for one port. Keep a single start command per project and check for forgotten terminal tabs when the error appears.

Handle the Error in Code for Real Servers

For scripts and production-style servers, you can listen for the error event on the server object and print a friendly message that names the port, instead of a raw stack trace. Some teams also retry on the next port automatically in development. At minimum, a clear message saves the next developer on the team from guessing what happened.

Check for Other Programs Using the Port

Sometimes the other process is not Node at all. Another local server, a database tool, or a completely unrelated application may already use your chosen port. The same lookup commands reveal its name. If it is a program you need, simply choose a different port for your Node project and update your notes or environment file so the choice sticks.

Common Mistakes and Useful Tips

• Killing the wrong PID: Double-check the process name before ending it, especially on a shared machine. The lookup tools show which program owns the port.
• Starting the server twice: Two terminal tabs running the same project is the number one cause in busy development sessions.
• Assuming a reboot is required: It is not. Finding and stopping the one process is faster and just as effective.
• Forgetting Docker or virtual machines: A container can publish the same port and block your local server. Stop the container or change its published port.
• Tip: After stopping a process, run the lookup command once more to confirm the port is free before restarting.
• Tip: Keep a note of which ports your local projects use, such as 3000, 3001, and 5173, so projects never collide with each other.
• Tip: If the error appears right after a crash, wait a few seconds and try once more. Ports in a closing state clear quickly on their own.

Conclusion

EADDRINUSE simply means the port is busy, and after a restart the busy process is almost always an older copy of your own server that did not shut down. Look up the process by port, stop it, and start again. Use a different port only as a short-term workaround, and build the habit of stopping servers with Ctrl + C so the problem rarely returns. With the lookup commands for Windows, macOS, and Linux in your toolbox, this once-annoying error becomes a thirty-second fix.

Frequently Asked Questions

What does EADDRINUSE mean in simple words?

It means address already in use. Your server tried to listen on a port that another running process already owns, so Node stopped it instead of letting two programs share one port.

Why does it happen only when I restart quickly?

The old server process may still be shutting down, or it may not have stopped at all when its terminal closed. Restarting while that process still holds the port produces the error immediately.

How do I find what is using port 3000 on Windows?

Run netstat -ano | findstr :3000 to get the process ID, then use Task Manager or taskkill /PID <id> /F to stop it. Replace 3000 with your port if it differs.

Is changing the port a real fix?

It is a valid workaround and the right long-term choice if another program you need owns the port. If the owner is just a leftover copy of your own server, stopping that process is the cleaner fix.

Can I make my server choose a free port automatically?

Yes. You can listen for the error event and retry with the next port number, or ask the system for any free port by listening on port zero in tools and tests. For normal development, a fixed port with a clear error message is usually better.