凌晨两点,群里还在闪消息,这种节奏做久了,慢慢就摸清了一些规律——宝塔面板的故障看起来五花八门,其实翻来覆去就是那几类,与其每次都从头查起,不如把最常见的几个坑和对应的处置办法整理出来,手边有个参照。
宝塔面板运维群实战手记,四类高频故障的排查与处置
PHP扩展安装失败
排查思路
扩展装不上,先看编译日志,再看依赖,宝塔的扩展安装走的是sh脚本编译,失败原因八九成集中在三处:系统缺少开发库、PHP版本与扩展版本不匹配、源码下载被墙。
先确认当前PHP版本:
php -v ls /www/server/php/
再看编译日志尾部:
tail -n 50 /tmp/php_ext.log # 或 tail -n 50 /www/server/php/74/src/ext/xxx/config.log
日志里如果有configure: error: xxx not found,就是缺依赖,常见缺的是libcurl-devel、libxml2-devel、oniguruma-devel。
解决命令
以CentOS为例补齐基础依赖:
yum install -y libcurl-devel libxml2-devel oniguruma-devel \ openssl-devel bzip2-devel libjpeg-devel libpng-devel \ freetype-devel gmp-devel readline-devel
Debian系换成:
apt install -y libcurl4-openssl-dev libxml2-dev libonig-dev \ libssl-dev libbz2-dev libjpeg-dev libpng-dev libfreetype6-dev \ libgmp-dev libreadline-dev
如果是下载超时,手动指定国内源再装,实在不行,用pecl直接编译:
cd /www/server/php/74/src/ext/redis /www/server/php/74/bin/phpize ./configure --with-php-config=/www/server/php/74/bin/php-config make && make install
编译完成后,在/www/server/php/74/etc/php.ini里加一行extension=redis.so,或者通过面板的php.ini编辑入口追加。
验证方法
/www/server/php/74/bin/php -m | grep redis /www/server/php/74/bin/php -i | grep -i "redis support"
面板的PHP扩展页面刷新后能看到状态为“已安装”,且php -m输出里出现扩展名,才算真正成功。
数据库远程连接失败
排查思路
远程连不上MySQL,按“网络→端口→用户权限→bind-address”的顺序逐层排查,不要一上来就改配置。
先看端口是否监听在0.0.0.0:
netstat -tlnp | grep 3306 # 或 ss -tlnp | grep 3306
如果只监听0.0.1,那就是bind-address没放开,再看防火墙和云厂商安全组,3306是否放行,最后查用户授权:
SELECT user, host FROM mysql.user WHERE user='your_user';
如果host是localhost,远程自然连不上。
解决命令
修改/etc/my.cnf或/www/server/mysql/etc/my.cnf:
[mysqld] bind-address = 0.0.0.0
放行防火墙:
firewall-cmd --permanent --add-port=3306/tcp firewall-cmd --reload
授权远程用户:
CREATE USER 'your_user'@'%' IDENTIFIED BY 'StrongPass!'; GRANT ALL PRIVILEGES ON your_db.* TO 'your_user'@'%'; FLUSH PRIVILEGES;
云服务器记得在控制台安全组同步放行,这一步经常被漏掉。
验证方法
从远程机器上执行:
mysql -h your_server_ip -P 3306 -u your_user -p
能进就是通了,如果还不行,用telnet your_server_ip 3306看端口通不通,端口不通就是网络层问题,跟MySQL本身无关。
Nginx/Apache规则冲突
排查思路
宝塔里同时装了Nginx和Apache,或者一个站点同时启用了伪静态和反代规则,很容易出现rewrite循环、404、502,核心是看谁在前面接请求。
ps aux | grep -E "nginx|httpd"
如果Nginx在前、Apache在后,Nginx负责静态和转发,Apache处理PHP,这时候两边的rewrite规则会打架,看错误日志最直接:
tail -f /www/wwwlogs/your_domain.error.log
出现rewrite or internal redirection cycle就是循环了。
解决命令
理清哪个是前端服务器,规则只在前端写,如果Nginx做前端,Apache的httpd.conf里不要重复写rewrite,只保留PHP处理,检查站点的伪静态文件:
cat /www/server/panel/vhost/rewrite/your_domain.conf
如果是WordPress这类程序,确保rewrite规则只有一份,反代和伪静态同时存在时,用location优先级控制:
location ^~ /api/ {
proxy_pass http://127.0.0.1:8080;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
验证方法
nginx -t apachectl configtest
两条命令都返回syntax is ok,再重启服务,然后用curl -I访问几个关键路径,看返回码是否正常,特别是有没有301循环。
Redis/Memcached启动异常
排查思路
启动不了先看日志,再查端口占用和权限。
tail -n 50 /www/server/redis/redis.log tail -n 50 /var/log/memcached.log
Redis常见的是RDB文件损坏、端口被占、requirepass配置后连不上,Memcached常见的是-l绑定地址不对、内存参数过大。
解决命令
端口占用:
lsof -i:6379 kill -9 <PID>
Redis的RDB损坏时,可以用redis-check-rdb修复:
redis-check-rdb /www/server/redis/dump.rdb
配置里protected-mode和bind要配合好,本机用就绑0.0.1,远程访问改成0.0.0并设密码:
bind 0.0.0.0 protected-mode yes requirepass YourStrongPass
Memcached启动参数调整:
memcached -d -m 512 -u www -l 127.0.0.1 -p 11211
内存别超过物理内存的1/4,用户权限也要对。
验证方法
redis-cli -a YourStrongPass ping # 返回 PONG 即正常 echo stats | nc 127.0.0.1 11211
能返回STAT开头的统计信息,说明Memcached在工作。



发表评论