关键是从配置语法检查、路径权限、缓存区初始化日志三方面主动验证：nginx -t -v确认proxy_cache_path被解析；ls -ld验证目录存在及www-data等属主权限；error.log中查找mkdir()失败等提示；nginx -T比对实际生效路径。
排查 Nginx proxy_cache 路径拼写错误导致的加载失败，关键不是等服务启动后“出问题”，而是从配置语法检查、路径权限、缓存区初始化日志三个层面主动验证。Nginx 不会在 proxy_cache_path 路径不存在时直接报错退出，而是静默跳过缓存初始化——这正是拼写错误最难察觉的原因。
用 nginx -t 检查语法并确认路径是否被识别
nginx -t 只校验配置语法，不校验路径是否存在或可写，但它会输出实际加载的配置文件路径和包含关系。重点看输出中是否列出了你写有 proxy_cache_path 的配置块（比如 http 块）。如果该配置被注释、放在了未被 include 的文件里，或因条件指令（如 if）被跳过，nginx -t 就不会把它当作有效缓存路径处理。
- 运行
nginx -t -v（加-v显示详细解析过程），观察是否打印出你的proxy_cache_path行 - 检查是否有拼写混淆：比如
/var/cache/nginx/proxy写成/var/cache/nginx/proy，或大小写错误（Linux 下路径区分大小写） - 确认路径中没有多余空格或不可见字符（尤其从文档复制粘贴时）
手动验证 proxy_cache_path 中的目录是否存在且权限正确
Nginx worker 进程需要对 proxy_cache_path 指定的根目录有读、写、执行（rwx）权限，且父目录也需有执行权限（用于进入）。路径拼写错一个字母，目录就不存在；即使存在，若属主/权限不对，Nginx 启动时也不会报错，但后续无法创建缓存子目录。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 执行
ls -ld /your/cache/path，确认目录真实存在（不要只信配置文件里的写法） - 检查属主是否为运行 Nginx worker 的用户（通常是
www-data或nginx），例如：sudo chown -R www-data:www-data /var/cache/nginx/proxy - 确保目录权限至少为
700或755（不推荐 777）
查看 error 日志中 cache 初始化阶段的关键提示
Nginx 在 master 进程启动后、worker 进程初始化缓存时，会尝试创建缓存层级目录（如 tmp、levels 子目录）。此时若路径无效或无权限，会在 error_log 中留下明确线索，但只在首次启动或重载时出现，之后不再重复打印。
- 重启前清空或备份当前 error 日志：
sudo truncate -s 0 /var/log/nginx/error.log - 执行
sudo nginx -s reload或重启 - 立即查看日志：
sudo tail -n 20 /var/log/nginx/error.log - 重点关注含
cache manager process、mkdir()、open() failed、invalid cache path的行。例如：
2024/05/10 14:22:03 [emerg] 12345#12345: mkdir() "/var/cache/nginx/proy" failed (2: No such file or directory)
用 nginx -T 输出完整生效配置，定位实际生效的 proxy_cache_path
nginx -T（大写 T）会输出所有被加载并展开后的最终配置，包括所有 include 文件内容。这是确认你写的那行 proxy_cache_path 是否真被读取、有没有被其他同名指令覆盖的最可靠方式。
- 运行
sudo nginx -T 2>/dev/null | grep "proxy_cache_path" - 比对输出中的路径与你配置文件中写的是否完全一致（含空格、引号、斜杠方向）
- 注意：如果多个
proxy_cache_path使用相同keys_zone名，后加载的会覆盖前面的，也可能导致“配置写了却没生效”
