本质是include路径不存在或权限不足：一、确认主配置中include的绝对路径是否真实存在且非空；二、检查目录及文件权限，确保Nginx用户具备r-x访问权；三、用nginx -T查看完整展开配置并定位具体失败项。
当执行 nginx -t 报错提示“配置文件找不到目录”（例如 open() "/etc/nginx/conf.d/default.conf" failed (2: No such file or directory)），本质是 Nginx 在加载配置时，试图 读取 include 指令中声明的子配置文件路径，但该路径不存在或权限不足。这不是主配置文件（如 nginx.conf）丢失，而是它 引用的某个文件或目录不存在。
检查 include 指令中的路径是否真实存在
Nginx 主配置里常用 include 加载外部配置，比如：
include /etc/nginx/conf.d/*.conf;
此时需确认：
• /etc/nginx/conf.d/ 这个目录是否存在？
• 该目录下是否有至少一个以 .conf 结尾的文件？
• 如果写的是 include /etc/nginx/sites-enabled/default;，就要检查 sites-enabled 目录是否存在、是否为空、是否有名为 default 的文件（不带 .conf 后缀也合法）
注意路径是否为绝对路径，避免当前工作目录干扰
nginx -t 默认以主配置文件所在位置为基准解析相对路径，但实践中强烈建议所有 include 使用 绝对路径。如果误写成：
include conf.d/*.conf;
而当前执行命令的目录不是 /etc/nginx/，Nginx 就会去错误路径下找 conf.d/，自然报错。解决方法：统一补全为完整路径，例如 /etc/nginx/conf.d/*.conf。
验证用户是否有权限访问目标目录和文件
即使路径存在，Nginx 主进程（通常由 root 启动）需要能 进入目录 + 读取文件。常见问题包括：
• /etc/nginx/conf.d/ 目录权限为 700 且属主不是 root
• 文件被创建时 umask 设置异常，导致权限为 600 且 group/other 不可读
• SELinux 或 AppArmor 启用时拦截了读取（可通过 ausearch -m avc -ts recent | grep nginx 查看）
快速验证：用 Nginx 运行用户（通常是 root 或 nginx）手动尝试访问：
sudo -u root ls -l /etc/nginx/conf.d/
利用 nginx -T 查看实际展开的完整配置
nginx -t 只校验语法和路径，不输出详情；而 nginx -T（大写 T）会把所有 include 合并后打印出来，并在出错位置给出明确提示。运行：
nginx -T 2>&1 | head -n 20
如果某处 include 失败，-T 通常会在报错前直接显示 “cannot open include file …”，比 -t 更易定位具体哪一行、哪个路径出了问题。
