如何停止运行在本地3000端口的Supabase？移除相关文件夹后仍运行的原因及解决办法

这种情况我之前也碰到过，大概率是Supabase的后台组件没彻底清理干净，毕竟本地Supabase是靠Docker托管各类服务的，哪怕你删了本地项目文件夹，底层的容器或进程可能还在默默运行。常见原因有这几个：

• Docker容器残留：本地Supabase的数据库、认证、存储等服务都是跑在Docker容器里的，你删除的只是项目文件夹，但容器本身没被停止删除，依然占用3000端口。
• 后台进程未终止：如果之前用supabase start --detach这类后台启动命令开启服务，进程会在后台挂起，删除文件夹不会影响进程的存活状态。
• 系统守护进程残留：少数情况下，若你曾把Supabase配置成系统服务（比如Linux的systemd），它会脱离项目文件夹独立运行，删文件夹自然无法终止服务。

按以下顺序排查操作，基本能彻底解决问题：

第一步：清理Docker容器（最常见场景） #

1. 先查看当前运行的Docker容器，定位Supabase相关实例：

   docker ps
   

   你会看到名字带supabase的容器，比如supabase_db、supabase_auth等。
2. 停止所有Supabase容器：

   docker stop $(docker ps -q -f "name=supabase")
   

3. 删除已停止的Supabase容器：

   docker rm $(docker ps -aq -f "name=supabase")
   

4. （可选）清理Supabase关联的Docker卷，避免残留数据占用空间：

   docker volume rm $(docker volume ls -q -f "name=supabase")
   

第二步：终止Supabase后台进程 #

如果Docker容器已清理，但端口仍被占用，就检查系统进程：

1. 查找所有和Supabase相关的进程：

   ps aux | grep supabase
   

2. 找到进程的PID（输出第二列的数字），强制终止：

   kill -9 <你的PID>
   

   或者直接批量终止所有Supabase进程：

   pkill -9 supabase
   

第三步：检查系统守护进程（Linux用户） #

如果前两步无效，可能是Supabase被配置成了系统服务：

1. 查找是否存在Supabase相关的系统服务：

   systemctl list-unit-files | grep supabase
   

2. 若存在，停止服务并禁用开机自启：

   sudo systemctl stop supabase
   sudo systemctl disable supabase
   

3. （可选）删除服务配置文件，一般在/etc/systemd/system/或~/.config/systemd/user/目录下，找到supabase.service文件删除后，重新加载systemd配置：

   sudo systemctl daemon-reload
   

备选方案：用Supabase CLI直接停止（如果CLI未删除） #

如果你还保留着Supabase CLI，直接运行这条命令就能一键停止所有关联服务：

supabase stop

完成以上操作后，再检查3000端口，Supabase的进程应该就彻底停止了。

内容的提问来源于stack exchange，提问作者Karna04