宝塔安装日志固定位于 /www/server/panel/install/install_*.log，是安装脚本实时写入的原始文件，比面板运行日志更底层可信；若不存在，说明安装脚本未执行完成。
安装日志在哪？直接定位到原始文件路径
宝塔安装过程的完整执行记录，就存在 /www/server/panel/install/ 这个目录下，不是临时缓存，也不是数据库生成的摘要，而是安装脚本实时写入的原始 .log 文件。它比面板运行后的任何日志都更底层、更可信——因为哪怕面板最终没起来，这个文件也已经写完了。
- 文件名固定以
install_开头，后面跟着日期时间戳，比如install_20260315.log - 只要安装命令执行过（无论成功失败），该文件就存在；如果目录为空，说明安装脚本根本没跑完或被中断
- 别去
/tmp/或/root/下翻，那些是旧版残留或执行中途的临时输出，不全也不可靠
面板打不开时，怎么拿到日志？绕过 Web 界面用命令行
很多人一发现面板进不去，第一反应是点「文件管理器」，结果页面加载失败，卡在登录页——这时候图形界面已经不可用了，必须切 SSH 操作。
- 连上服务器后，先确认日志文件是否存在：
ls -l /www/server/panel/install/install_*.log - 想快速看末尾报错：用
tail -n 50 /www/server/panel/install/install_*.log，重点关注以[ERROR]、Failed、command not found、Permission denied开头的行 - 如果提示 “No such file”，说明安装脚本压根没执行到写日志这步，要回溯前置动作：检查是否手动删过
/www/server/panel、是否用非 root 用户运行了安装命令、或者系统自带的python被卸载导致脚本退出
光看 install.log 不够？还得补系统级上下文日志
有些错误根本不会写进宝塔自己的日志里，比如 yum 源配置错误、SELinux 拦截了关键服务启动、内核模块缺失导致 Nginx 编译失败——这些都得查系统日志才能定位。
-
cat /var/log/yum.log能看到所有包安装/失败记录，尤其注意failure或Cannot find a valid baseurl -
journalctl -u systemd-yum --since "1 hour ago"可抓取最近 yum/dnf 相关的 systemd 单元日志，比纯文本日志更有时序和上下文 - 如果装完发现 MySQL 启不来，但
install_*.log里只写了 “Starting MySQL… OK”，那大概率是systemctl status mysqld和journalctl -u mysqld才有真实错误原因
常见误判：把面板运行日志当安装日志
很多人一急就去翻 /tmp/panelBoot.pl 或 /www/server/panel/logs/error.log，这些是面板启动后产生的日志，跟“安装失败”基本无关。它们记录的是“面板起来了但某个功能异常”，而你真正要找的是“面板为什么起不来”。
-
/tmp/panelBoot.pl只是启动脚本的简单状态标记（内容通常是端口号），不是执行日志 -
/www/server/panel/logs/request.log是用户操作日志，和安装完全无关 - 真正的安装过程日志，只存在于
/www/server/panel/install/，且仅此一处
最常被忽略的一点：安装脚本本身可能因网络中断、磁盘满、DNS 解析失败等基础问题提前退出，此时 install_*.log 文件可能只有前几十行，甚至为空。遇到这种情况，别只盯着日志看，先用 df -h、ping download.bt.cn、free -h 快速扫一遍系统基础状态。
