nginx可通过try_files检查maintenance.html文件存在性实现维护页自动切换：若文件存在则返回（200或503），否则走正常流程；需确保root路径正确、文件可读，且避免在if中使用try_files。
要让 Nginx 在服务异常或维护期间自动返回维护页面（如 503.html），不能直接靠 try_files 检查“服务是否可用”，因为它只检查**文件或目录是否存在**，不探测后端健康状态。但可以结合 try_files + error_page + 命名 location 实现“有维护文件就显示，否则走正常流程”的静态兜底逻辑。
核心思路：用 try_files 优先检查维护页是否存在
把维护页面（如 /maintenance.html）当作一个可被主动放置的“开关”——只要该文件存在且可读，Nginx 就立即返回它，屏蔽所有正常请求；删除文件即自动恢复服务。
典型配置如下：
location / {
root /var/www/myapp;
index index.html;
try_files /maintenance.html $uri $uri/ /index.html;
}
说明：
-
/maintenance.html：以/开头，表示相对于root路径查找，即检查/var/www/myapp/maintenance.html是否存在 - 如果存在 → 直接返回该文件（状态码 200），后续参数全部跳过
- 如果不存在 → 继续尝试
$uri（静态资源）、$uri/（目录）、/index.html（SPA 兜底）
配合 error_page 实现真正的 503 维护页
若需返回标准 503 Service Unavailable 状态码（更符合运维规范），则需改用 error_page 机制，try_files 仅负责“触发”错误：
location / {
root /var/www/myapp;
try_files /maintenance.html @normal;
}
location @normal {
try_files $uri $uri/ /index.html;
}
error_page 418 = /maintenance.html;
if (-f $document_root/maintenance.html) {
return 418;
}
说明：
- 用自定义状态码
418（I'm a teapot）作内部标记，避免和真实错误混淆 -
if (-f ...)判断维护文件是否存在，存在则返回418 -
error_page 418 = /maintenance.html将其映射为返回该静态页，状态码可设为=503（加等号表示不改写状态码）
子路径部署时的注意事项
若应用在子路径（如 /admin/），维护页路径需与 alias 或 root 结构对齐：
- 用
alias：location /admin/ { alias /var/www/admin-dist/; try_files /maintenance.html $uri $uri/ /admin/index.html; }→ 此时/maintenance.html查的是/var/www/admin-dist/maintenance.html - 用
root：location /admin/ { root /var/www; try_files /admin/maintenance.html $uri $uri/ /admin/index.html; }→ 注意 fallback 中的路径要匹配物理结构
上线前必须确认的几件事
维护页能生效，依赖以下基础配置已就位：
-
root指向正确的构建输出目录，且maintenance.html已放入该目录 - 确保 Nginx 进程对维护页有读取权限（
ls -l /var/www/myapp/maintenance.html） - 不要在
if块中直接使用try_files（Nginx 明确禁止） - 测试方式：临时创建
maintenance.html，刷新任意前端路由，应看到该页面且状态码为 200 或 503
