宝塔面板自身故障（如按钮失灵、接口500、任务不执行）应优先查看/www/server/panel/logs/error.log，该文件记录python进程崩溃、模块导入失败、数据库连接超时等底层异常，是定位问题的第一手证据。
直接看 /www/server/panel/logs/error.log 是最准的起点
宝塔面板自身出问题（比如点不动按钮、接口返回 500、定时任务不执行），error.log 是第一手证据。它不记录你改了什么配置，只忠实输出 Python 进程崩溃、模块导入失败、数据库连接超时这类底层异常——和 request.log 完全不是一回事。
常见错误现象包括：ImportError: No module named 'gevent'、sqlite3.OperationalError: database is locked、Connection refused（连不上本地 MySQL 或 Redis）、Permission denied（写日志或读配置失败）。
用 tail -n 100 /www/server/panel/logs/error.log 查最近 100 行；如果刚重启过面板，加 -f 实时盯住：tail -f /www/server/panel/logs/error.log，再点几下界面，看哪条报错紧跟操作之后出现。
error.log 里没报错，但面板明显卡顿或响应慢
这时候别只盯着 error 级别日志。宝塔的 Python 后端在启动、重载、执行计划任务时，会把关键路径和耗时打到 error.log 的 info 级别（注意：它叫 error.log，但实际混着 info 和 warning）。所以空日志 ≠ 没问题。
检查方式是用 grep 扫描关键词：
-
grep "start" /www/server/panel/logs/error.log | tail -n 20—— 看面板是否完整启动 -
grep "reload" /www/server/panel/logs/error.log | tail -n 10—— 看 Nginx/Apache 重载有没有卡住 -
grep "task" /www/server/panel/logs/error.log | tail -n 10—— 看计划任务调度是否被阻塞
如果这些关键词完全没出现，说明面板主进程可能已僵死，得先 systemctl restart bt 或 service bt restart。
日志轮转后找不到最新 error.log，或者文件为空
宝塔默认每天按时间切分 error.log，旧文件会变成 error.log-2026-04-16、error.log-2026-04-15 这样的格式，但不会自动压缩或清理。所以当前正在写的那个，永远是 error.log（无后缀）。
但如果发现它为空，先确认两件事：
- 文件权限是否被改过：
ls -l /www/server/panel/logs/error.log，确保属主是root且可写（-rw-r--r--或更宽松） - 磁盘是否写满：
df -h /www，error.log写不进去时，面板不会报错，只会静默丢弃日志 - 是否有人手动清空过：
stat /www/server/panel/logs/error.log看Modify时间，比预期晚很多就可疑
真丢了，去同目录下找带日期后缀的归档文件，它们才是历史真相。
看到 UnicodeDecodeError 或中文乱码报错行
这是宝塔日志模块在读取含中文路径、网站名或用户输入的配置时，Python 2/3 字符串处理不一致导致的典型问题。它本身不致命，但会掩盖真实错误——因为后续日志可能因编码崩掉而截断。
临时缓解办法是重定向日志编码（需重启面板）：
echo 'export PYTHONIOENCODING=utf-8' >> /etc/profile source /etc/profile
但根本解法是避免在网站名、路径、计划任务命令里用中文。宝塔对中文支持始终是“能跑”，不是“稳跑”。尤其当报错行里夹着 \xe4\xb8\xad\xe6\x96\x87 这种字节序列时，基本可以判定是这个原因。
真正要命的不是乱码本身，而是它常出现在日志开头几行——意味着你看到的“最后一条报错”，很可能根本不是最后一次异常。
