这种情况非常典型，被称为**“幽灵端口”占用**。既然 lsof 和 netstat 都查不到，说明并没有常规进程在监听这个端口，问题通常出在 Docker 的网络残留 或者 系统内核的端口保留 上。

请按顺序尝试以下 3 种方法，通常能解决问题：

方法一：清理残留的容器网络（最常用）

从你的日志来看，容器 subtitle 已经处于 Created（已创建但未启动）状态。有时候旧的容器虽然停止了，但它的网络端点（endpoint）没有被 Docker 守护进程正确清理，导致 Docker 误以为端口还在用。

1. 强制删除容器：

1docker rm -f subtitle

2. 清理网络断点（可选，如果上面不行）：

1docker network prune -f

3. 再次尝试启动：

1docker compose up -d

方法二：重启 Docker 服务（暴力但有效）

如果方法一无效，说明 Docker 的内部网络表（iptables 规则或内部数据库）和实际系统状态不同步了。重启 Docker 服务会强制刷新网络映射。

1sudo systemctl restart docker
2# 然后再次启动
3docker compose up -d

方法三：检查是否被内核保留（如果是 WSL2 用户必看）

看你的终端是 eleven@eleven，如果你是在 Windows 的 WSL2 环境下运行 Docker，这是一个极高频的坑。Windows 的 Hyper-V 有时会随机保留一大段端口供内部使用，导致 Docker 无法绑定这些端口，而这些端口在 netstat 里是看不到的。

验证方法（在 Windows PowerShell 中运行，不是 WSL 里）：

1netsh int ip show excludedportrange protocol=tcp

如果你在输出的列表里发现 8002 被包含在某个“开始端口”和“结束端口”的范围内，那就是被 Windows 系统保留了。

解决办法：

1. 临时方案：修改 docker-compose.yml，把 8002 换成一个不在该列表里的端口（比如 8005）。
2. 彻底解决（需要重启 Windows）： 在管理员权限的 PowerShell 中运行：

1net stop winnat
2net start winnat

这通常会重置保留的端口范围。

总结

绝大多数情况下，执行 方法二（重启 Docker 服务） 就能解决这种“查不到占用”的端口冲突问题。