Docker Compose 使用自定义配置后，logs 报 no configuration file provided

用指定的 Compose 文件启动服务后，换一个终端查看日志，命令却停在配置文件错误上：

docker compose logs

no configuration file provided: not found

容器已经启动，不代表后续每次 Compose 命令都能自动找到启动时使用的文件。尤其是文件名为 compose.prod.yaml、docker-compose.custom.yml，或者终端当前目录已经改变时，应重新指定实际配置路径。

本文针对 Docker Compose 的配置发现问题，示例采用 docker compose 插件命令。下面的 /srv/demo/compose.prod.yaml 是文件路径占位值，demo 是项目名示例，web 是服务名示例；请替换为原部署的值。Linux、macOS 和 WSL 可使用示例中的路径格式，Windows 原生终端应使用其可访问的 Windows 路径。

先用实际文件验证配置

找到部署时保存的 Compose 文件，优先从部署脚本、项目目录或原启动命令确认，不要看到报错就新建一份空文件。对已有配置指定完整路径并验证：

docker compose -f /srv/demo/compose.prod.yaml config -q

config -q 只验证配置，不打印完整配置内容，也不会启动或重建服务。若这一步通过，说明此次调用已经找到文件并完成配置校验，可以继续查看日志：

docker compose -f /srv/demo/compose.prod.yaml logs --tail 100

这是对读取日志命令的修正，无须先运行 down、删除容器或重装 Docker。若第二条命令仍没有预期日志，再检查项目和服务是否与原部署一致。

如果 config -q 已经变成 YAML 语法、变量缺失或服务定义错误，说明排查进入了下一层：文件找到了，但内容还不能正确解析。不要继续把所有错误都按“找不到 Compose 文件”处理。错误信息也可能包含本地路径或配置片段，分享前应检查敏感内容。

自定义文件名不会自动成为默认文件

不指定 -f 时，Compose 会按默认规则在当前目录及父目录寻找配置。默认文件名包括 compose.yaml、compose.yml，以及兼容的 docker-compose.yaml、docker-compose.yml；其中优先推荐使用 compose.yaml。

compose.prod.yaml 这样的名字可以使用，但需要通过 -f 或相应配置明确指定。曾经执行过一次带 -f 的启动命令，并不会让所有新终端永久记住这个选择。仅仅把终端切到文件所在目录，也不足以让任意自定义文件名变成默认文件。

检查时还应看真实文件名，而不只是编辑器标签或文件图标。实际文件若叫 compose.yaml.txt，就不是名为 compose.yaml 的文件。已有自定义文件不必为了排错改名；保留原名并明确指定路径，通常更容易维持部署脚本的一致性。

-f 在 logs 前后，含义不同

这里有两个容易混淆的短选项：Compose 的 -f 用于选择文件，而 logs 的 -f 用于持续跟随日志。把文件选项放在子命令前面，跟随日志则使用完整写法：

docker compose -f /srv/demo/compose.prod.yaml logs --follow --tail 100 web

web 必须是配置中实际的服务名。可以先查看解析出来的服务清单：

docker compose -f /srv/demo/compose.prod.yaml config --services

不要把 docker compose logs -f /srv/demo/compose.prod.yaml 当作等价写法。在 logs 后面，-f 对应的是 --follow，后面的路径可能被当成服务参数，无法承担选择配置文件的作用。

--follow 会持续等待新日志。退出跟随不会要求重建服务；日常排错可以先用有限的 --tail 100 查看末尾内容，确认项目正确后再持续跟随。

文件路径和项目名要同时对齐

-p 设置项目名，不是 Compose 文件路径。若启动时明确使用过项目名，后续查询也应沿用。下面仅以原项目确实叫 demo 为前提：

docker compose -f /srv/demo/compose.prod.yaml -p demo ps -a
docker compose -f /srv/demo/compose.prod.yaml -p demo logs --tail 100

用 ps -a 列出项目中的容器，包括已经停止的容器；核对名称和状态后，再读取日志。如果清单不是目标项目，不要立即执行 up 来“补齐”；应回头核对原来的项目名、文件和 Docker 连接环境。

不同命令及 Compose 版本可能有不同的项目发现行为。某个不带文件参数的查看命令能够工作，不代表当前报错的调用已经取得相同配置。这里通过显式路径和已确认的项目名缩小范围，不假定所有版本的 logs 都必须依赖本地文件，也不把这个错误当作容器已被删除的证据。

没有显式指定项目名时，它可能来自环境变量、配置中的顶层名称或项目目录。不要随意新增一个不同的 -p 值；这会改变命令面向的项目，而不是修复原项目。

原来用了多份配置，要保留同样的组合

如果部署时把基础配置与生产覆盖文件合并，查看日志和验证时也应保留文件顺序。例如：

docker compose -f /srv/demo/compose.yaml -f /srv/demo/compose.prod.yaml config -q
docker compose -f /srv/demo/compose.yaml -f /srv/demo/compose.prod.yaml logs --tail 100

后面的文件会补充或覆盖前面的配置。只拿其中一份验证，可能得到不完整的服务定义，也可能与原部署不同。多文件配置中的相对路径以第一份文件所在位置为基准；原命令若还用了 --project-directory，也要保留这个路径基准。不要为了消除文件错误重新排列文件，或顺手更改构建目录和挂载路径。

原部署若依赖 --env-file、特定环境变量或其他项目选项，也应从原命令中恢复这些条件。完整的 config 输出会展开配置中的变量，不宜未经检查直接贴到公开渠道；只判断是否能解析时，优先用前面的 config -q。

COMPOSE_FILE 也能指定 Compose 文件，其作用对应 -f。命令行明确传入 -f 时，会覆盖这个环境变量的文件选择，因此绝对路径适合用作一次对照。确认原因后再修正脚本中的实际设置，不必先清空整个 Shell 环境，也不要把项目文件位置误当成某个固定的系统目录。

显式路径仍然找不到时

如果明确传入正确路径仍报文件不存在，检查运行 Docker CLI 的终端是否真的能访问该路径。Windows 与 WSL 的路径写法不同；受文件访问隔离约束的安装方式也可能让 CLI 看到的路径与普通终端不同。这已经超出“遗漏自定义文件名”的范围，不能保证换成绝对路径就一定解决。

此时保留完整报错、Compose 版本、CLI 的安装方式以及实际路径，继续核对文件可见性。不要将权限扩大到所有用户，更不要直接卸载 Docker 来试错，以免影响正在运行的其他服务。

修复完成后，配置验证应通过，项目清单应对应原部署，日志查询应不再报告找不到配置。如果应用本来没有输出日志，结果仍可能为空；空输出本身不能证明定位失败。把核实后的文件路径、文件顺序和项目参数写回运维脚本，并保留修改前版本，出现指向错误项目的情况时即可恢复。