Guide · 6 novembre 2026 · 6 min de lecture

Port déjà utilisé sur Mac : trouver et libérer

« Port déjà utilisé » (« address already in use ») sur un Mac veut dire qu’un autre processus écoute déjà sur le port que votre app demande. La solution tient en deux commandes : trouver le processus avec lsof, puis arrêter le processus qui occupe ce port. Ce guide donne les commandes exactes, l’erreur que font la plupart des commandes toutes faites qu’on copie-colle, les deux cas où kill ne marche pas (AirPlay et Docker), et comment éviter que l’erreur revienne.

À quoi ressemble l’erreur

Le texte dépend de l’outil, la cause est la même :

Error: listen EADDRINUSE: address already in use :::3000
OSError: [Errno 48] Address already in use

La première vient de Node.js (Express, Next.js, Nuxt, Vite…), la seconde de Python (Flask, Django, FastAPI avec uvicorn). Certains serveurs de dev n’échouent pas : ils passent discrètement au port libre suivant, et vous vous retrouvez sur localhost:3001 sans comprendre pourquoi votre URL de retour ne marche plus.

Étape 1 : trouver le processus sur le port

lsof -nP -iTCP:3000 -sTCP:LISTEN

-iTCP:3000 sélectionne les connexions TCP du port 3000, -sTCP:LISTEN ne garde que le processus qui écoute (le serveur), -n et -P évitent les résolutions de noms pour une réponse immédiate. Vous obtenez par exemple :

COMMAND   PID   USER   FD   TYPE  DEVICE  SIZE/OFF NODE NAME
node    48213  sam    23u  IPv6  0x...       0t0  TCP *:3000 (LISTEN)

Le nombre de la colonne PID est celui qu’il vous faut. Avant de l’arrêter, vérifiez ce que c’est :

ps -p 48213 -o command

Si c’est un serveur de dev oublié, continuez. Si vous ne le reconnaissez pas, regardez de plus près : ce peut être une base de données, un conteneur ou un service du système.

Pour voir tous les ports sur lesquels votre Mac écoute, retirez le numéro :

lsof -nP -iTCP -sTCP:LISTEN

Étape 2 : arrêter le processus sur ce port

kill 48213

kill envoie un signal d’arrêt poli (SIGTERM), qui laisse le serveur fermer ses fichiers et ses connexions. Si le processus est toujours là quelques secondes plus tard :

kill -9 48213

-9 (SIGKILL) ne peut pas être ignoré, mais le processus n’a aucune chance de faire le ménage. À utiliser en second, pas en premier.

La commande en une ligne, bien faite

Beaucoup de tutoriels proposent lsof -ti :3000 | xargs kill. Le problème : sans -sTCP:LISTEN, lsof renvoie aussi les processus simplement connectés au port 3000, comme votre navigateur ouvert sur l’app. Cette commande peut fermer Chrome en même temps que le serveur. Celle-ci ne vise que le processus qui écoute :

kill $(lsof -t -iTCP:3000 -sTCP:LISTEN)

-t n’affiche que les PID, ce qu’attend kill.

Quand kill ne suffit pas

Port 5000 ou 7000, occupé par ControlCenter. lsof l’affiche sous le nom ControlCe, car il tronque les noms de commande. Depuis macOS Monterey, le récepteur AirPlay écoute sur les ports 5000 et 7000, et 5000 est le port par défaut de Flask. Inutile d’arrêter ControlCenter : macOS le relance. Désactivez le récepteur dans Réglages Système → Général → AirDrop et Handoff → Récepteur AirPlay, ou lancez votre app sur un autre port :

flask run --port 5001

Un port occupé par Docker. Si lsof affiche un processus com.docke (le moteur de Docker), le port est publié par un conteneur, et arrêter le processus de Docker les arrêterait tous. Trouvez le conteneur et arrêtez-le :

docker ps --format '{{.Names}}\t{{.Ports}}'
docker stop <nom-du-conteneur>

Même chose avec OrbStack et Colima. Un Supabase local, par exemple, publie une série de ports à partir de 54321 ; supabase stop les libère tous.

Le processus revient. Un processus relancé par un superviseur (launchd, pm2, nodemon, une politique de redémarrage de docker compose) réapparaîtra. Arrêtez-le par l’outil qui le fait tourner.

Sous Windows

Dans PowerShell, netstat -ano | findstr :3000 affiche le PID dans la dernière colonne, et taskkill /PID <PID> /F l’arrête. Dans WSL 2, les commandes Linux ci-dessus marchent comme sur Mac.

Éviter que ça revienne

Arrêter des processus soigne le symptôme. La cause : plusieurs projets veulent les mêmes ports (3000, 5173, 8000) et rien ne retient qui tourne où. Deux remèdes :

1. Un port par projet, écrit dans le projet : PORT=3001 dans .env pour Next.js ou Express, server.port avec strictPort: true dans vite.config.ts pour Vite, pour qu’il échoue franchement au lieu de glisser vers un autre port.
2. Un outil qui distribue les ports. C’est ce que fait Tarmac.

Comment Tarmac gère les ports

Tarmac est un tableau de bord local gratuit et open source pour macOS et Windows (WSL 2) qui trouve les projets de vos dossiers de code et les lance pour vous :

• Un port libre par app, gardé d’une fois sur l’autre. Les apps lancées par Tarmac reçoivent un port entre 4100 et 4999, une plage qui évite les habituels 3000, 5173 et les ports de Supabase. L’app sur 4123 aujourd’hui sera sur 4123 demain.
• Les apps lancées ailleurs sont repérées. Un serveur qui tourne déjà sur le port d’une app, lancé depuis un terminal ou un script, s’affiche En cours · hors Tarmac au lieu d’échouer sur EADDRINUSE, et Tarmac l’adopte.
• Libérer les ports après un plantage. Un bouton arrête ce qu’une app a laissé derrière elle sur ses ports.
• Les logs et l’état à côté, avec les conteneurs Docker groupés par projet et les instances Supabase locales avec leurs ports.

Le contexte est dans Faire tourner dix projets locaux sans un seul conflit de port.

Pour aller plus loin

Gardez les deux commandes sous la main (lsof -nP -iTCP:<port> -sTCP:LISTEN, puis kill <PID>), et si vous jonglez entre plusieurs projets, installez Tarmac pour que la question ne se pose plus.

Sources : page de manuel de lsof ; le récepteur AirPlay sur le port 5000 depuis macOS Monterey (Stack Overflow) ; référence de docker ps. Vérifiées le 6 novembre 2026.