这两位的情况其实已经把线索给得很全了，我帮你们汇总一下“怎么刹车 + 怎么清理 + 怎么避免再次卡死”，都针对 1.11.4。
一、你们现在遇到的现象是什么情况？
从 Niklaus1028 的日志看，大致是：
- 不断轮询
/plugin/<plugin-id>/management/install/tasks、/dispatch/model/schema等接口； - 中间出现：
task xxx timed outrecord not found（SELECT * FROM "plugin_declarations" WHERE plugin_unique_identifier = 'alipay/alipay_plugin:0.1.0@...'）
结合 ao_zhang 的描述：
- UI 一直显示「正在安装插件」；
- 后台任务
Task timed out but not properly terminated； - 同一个插件（通义 / 支付宝等）被重复创建安装任务。
这说明：
- 某个安装任务已经超时，但状态没有被正确标记为“结束”，导致守护进程一直认为它在安装中；
- 有些插件的
plugin_unique_identifier在 DB 中查询不到（record not found），但安装流程又在继续调度，进一步把状态搞乱。
二、先“刹车”——别让守护进程继续刷任务
在你们的服务器上先停一下插件守护进程容器：
docker stop docker-plugin_daemon-1
作用：
- 立刻停止继续创建新的安装任务、停止继续刷
Task timed out...； - 方便你之后做清理（不然刚清完，又被新任务刷一遍）。
清理完后再启动：
docker start docker-plugin_daemon-1
三、怎么在本地部署环境拿到 Authorization（Bearer Token）
你们都是 1.11.4 的 docker-compose 自托管，即便是本地，前端访问后端也会自动带上一个 Bearer Token，只是平时看不到而已。
步骤（以 Chrome/Edge 为例）：
- 在浏览器访问你的 Dify 管理端（例如
http://服务器IP或http://localhost），正常登录管理员账号。 - 按
F12打开开发者工具 → 切到「Network / 网络」面板。 - 在页面里随便点一下别的菜单（例如进入「应用」「数据集」等），确保有接口请求被发出。
- 在 Network 列表里，找一个路径类似
/console/api/...的请求，点进去。 - 在「Headers / 请求头」里找到：
Authorization: Bearer xxxxxxxx... - 把
Bearer后面那一长串 token 复制出来（只留给自己用，别发到论坛）。
有了这个 token，就可以在服务器上用 curl 去调用清理接口，而不需要“云端特有”的 Authorization。
四、清理“卡住的安装任务”
在之前那篇「插件安装失败后，界面上永远显示 1 个插件安装中」的帖子里，已经有一个专门的「清理安装任务状态」的 POST 接口和 body 模板，你可以按那里的说明来。
调用方式的通用写法如下（把路径和 body 换成那篇帖子里给的实际内容）：
curl -X POST "http://<你的后端地址>/<那篇帖子里的接口路径>" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <上一步复制的token>" \
-d '{
... 这里填那篇帖子里的 JSON body ...
}'
注意：
<你的后端地址>：- 如果你用官方的 docker 目录直接起的，一般 Nginx 把前端和后端都暴露在 80 端口，你可以直接用
http://<服务器IP>或你现在能访问 Dify 的那个地址； - 如果你有自定义反向代理，请用你前端正常访问 Dify 的域名/端口。
- 如果你用官方的 docker 目录直接起的，一般 Nginx 把前端和后端都暴露在 80 端口，你可以直接用
- 路径、请求体请完全按那篇老帖子给的来，不要自己猜，以免误删其它插件或任务状态。
调用成功后：
- 刷新一下 Dify 页面，
- 右上角「正在安装插件」的提示应该会消失；
- 那个卡住的插件应变为「未安装」或者失败状态。
五、如果清理后仍然任何插件都超时，该往哪个方向排查？
你们都是 1.11.4，而且：
- 本地安装（上传 difypkg）也超时；
- 市场安装也超时；
- 日志中连续
timeout和record not found。
这通常说明不是单个插件的问题，而是插件运行环境本身不正常。几个重点方向：
1. 机器性能和 Docker 资源
插件安装会在插件容器里创建 Python 虚拟环境、下依赖，如果机器很“紧”：
- CPU/内存不足；
- Docker 给的资源太小；
都可能导致任务跑得很慢甚至超时。对应操作：
- 确认机器至少有：
- 2 核 CPU、4G+ 内存（官方最低要求建议 8G 更稳）；
- 在 Docker Desktop（如果是 Mac/Win）里适当调高 CPU / Memory；
- 服务器上用
top/htop观察安装时 CPU / MEM 是否打满。
2. 插件容器里访问外网 / Python 源是否通畅
从别的插件帖子来看，1.11.x 版本里很多安装失败都是因为：
- 默认 PyPI 源连不上或非常慢；
- 网络策略或代理挡住了插件容器访问外网。
排查：
- 进入插件 daemon 容器：
docker exec -it docker-plugin_daemon-1 /bin/bash - 在容器里试一下：
如果完全不通、或延迟极高，安装时就很容易超时。ping pypi.org curl -I https://pypi.org/simple
可以考虑：
- 在
.env里为插件设置国内 Python 源（如果官方在你版本支持）； - 或在宿主机层面配置网络代理，确保容器能正常访问外网。
3. record not found 说明什么？
你日志里类似：
SELECT * FROM "plugin_declarations" WHERE plugin_unique_identifier = 'alipay/alipay_plugin:0.1.0@...' ... record not found
这说明：
- 插件声明没有写入数据库成功；
- 但安装流程后续步骤还在根据这个
plugin_unique_identifier去查，得不到记录。
在你用 API 清理安装任务后：
- 建议重新打开插件市场/插件管理页；
- 为避免叠加旧垃圾状态，先只装一个简单插件测试（例如自带的官方演示插件）：
- 如果简单插件也超时，那就是“环境级问题”；
- 如果简单插件 OK，而某几个特定插件失败，就集中看这些插件的依赖和网络。
六、如果 API 清理还是搞不定，只剩下“重置状态”两条路（风险高）
只在你确认数据可备份、且对数据库操作有经验时考虑：
-
整栈停机 + 备份数据库
docker compose down假设 Postgres 容器叫
docker-db_postgres-1，备份：docker exec -t docker-db_postgres-1 \ pg_dump -U <db_user> <db_name> > dify_backup.sql -
进入数据库，把插件相关的“安装任务”和“安装中状态”删掉或改为失败。
这一步不同版本表名/字段略有差异，不建议你自己猜字段名，非常容易把别的东西删错。
如果一定要走这条路，建议你单独开一贴或在这里补充：docker-compose.yml里 Dify 版本和 Postgres 相关配置；\dt看一下插件相关表的名字和结构截图；
然后再一起推敲具体 SQL。
七、下一步你们可以这样继续反馈，方便精确定位
建议两位分别补充这些信息到本帖：
-
执行：
docker logs docker-plugin_daemon-1 -n 200把包含
Task timed out but not properly terminated和record not found的那几段日志，打码后贴上来。 -
按上面的步骤拿到
Authorization: Bearer ...，尝试一次“清理安装任务”的 POST 调用：- 调用用的是哪一个接口路径？
- 返回的 HTTP 状态码是多少（200 / 4xx / 5xx）？
- 调用后刷新 UI，“正在安装插件”的提示是否消失？
-
清理后，再尝试安装一个最简单的插件，看是否仍然统一报
Task timed out but not properly terminated。
只要我们能确认：
- 清理接口能正常把卡住的任务“归零”；
- 但新安装仍然超时；
那就基本可以判断是“环境/网络/资源”问题，而不是单纯的一次性脏数据，后面就可以针对性给环境优化的指导，或者建议考虑升级到较新版本（后续版本在插件安装超时与任务清理方面确实有持续修复）。
相关文档
- 自托管（docker-compose）部署与组件说明：
Deploy Dify with Docker Compose - Dify Docs
如果你们方便的话，可以先按上面的“刹车 + 拿 token + 调清理接口”这三步来走一遍，然后回帖说下执行结果，我们再一起把根因缩小到“环境问题还是版本 bug”。