宝塔下Xunsearch搜索失败主因是user.ini拦截跨目录加载，需清空其内容；权限不足致启动失败，须chmod 777 data/sdk/tmp并手动建索引目录；索引为空需检查ini配置与SQL查询；Nginx 403可能是location劫持，应排查proxy_pass规则。
搜索全站挂掉？先清空 user.ini
宝塔面板下启用 Xunsearch 全文检索后搜索失败、甚至整个网站打不开，八成是因为 user.ini 文件没清理。这个文件默认由宝塔自动生成，用于限制 PHP 的 open_basedir 范围，但它会严格拦截跨目录引入——而 Xunsearch 的 SDK 必须从 /usr/local/xunsearch/sdk/php/ 动态加载类，一旦被 user.ini 拦住，require_once 直接报错或白屏。
- 登录宝塔【文件】管理器，进入网站根目录（如
/www/wwwroot/example.com） - 找到并打开
user.ini，把它内容全部清空，保存 - 如果站点启用了多PHP版本，每个绑定该站点的 PHP 版本都要检查对应目录下的
user.ini - 别只删文件——留空比删除更稳妥，因为某些程序会依赖该文件存在
xs-ctl.sh restart 不生效？检查三个关键目录权限
Xunsearch 启动失败或索引写入报错，常见原因是数据目录权限不对。它不是“能读就行”，而是要求进程（通常是 www 用户）对 data、sdk、tmp 有完整写入权，否则初始化失败、增量索引卡死、甚至后台服务静默退出。
- 确认路径：Xunsearch 默认安装在
/usr/local/xunsearch/，必须确保/usr/local/xunsearch/data下已手动建好question和topic两个空文件夹（不能靠程序自动创建） - 执行命令设权限：
chmod -R 777 /usr/local/xunsearch/data /usr/local/xunsearch/sdk /usr/local/xunsearch/tmp - 运行
/usr/local/xunsearch/bin/xs-ctl.sh restart后，立刻用ps aux | grep xs看进程是否起来；若无输出，说明启动失败，需查/usr/local/xunsearch/log/xs.log
搜索返回空结果？验证索引是否真正建立
前端搜不到内容，不等于没配通，很可能是索引根本没跑成功。Xunsearch 的索引是离线构建的，不会随数据更新自动刷新，且对中文分词、字段映射极其敏感——哪怕配置里一个字段名拼错，整张表的索引就无效。
- 进网站后台或用命令行触发索引重建：
/usr/local/xunsearch/bin/indexer.php --rebuild --source=mysql://user:pass@127.0.0.1:3306/dbname --target=question /path/to/project/app/config/question.ini - 注意
--target=question必须和/usr/local/xunsearch/data/下的文件夹名完全一致，大小写敏感 - 查看输出末尾是否有
indexed N documents，若为0，重点检查.ini配置里的sql查询是否能手动在 phpMyAdmin 里跑通，以及fields中定义的字段是否真实存在于查询结果中
Nginx 返回 403 却不是权限问题？排查 location 代理劫持
搜索请求发出去，Nginx 直接返回 403，但文件权限、user.ini、目录所有者都正常——这时候要怀疑配置文件是否被篡改。攻击者常在 /www/server/panel/vhost/nginx/域名.conf 里注入恶意 location 块，把所有含 search、api、question 的请求偷偷代理到黑产 CDN，而你根本不知道请求压根没进 PHP。
- 用
grep -n "location.*search\|proxy_pass" /www/server/panel/vhost/nginx/yourdomain.com.conf快速扫描异常规则 - 特别留意
location ~* /.*search.*或location /api/search这类匹配，后面跟着proxy_pass http://xxx.xxx就是典型劫持 - 删掉整段非法
location，然后点宝塔【网站】→【设置】→【重载配置】，别只点重启
最麻烦的不是配不配得通，而是你以为配通了，其实请求早被劫走——务必先确认流量真的进了你的 PHP 脚本再调索引。
