Dify 1.17.0 上线第一天，生产环境全炸了

发布日期：2026-08-26 21:40:01 浏览次数： 2100

作者：AI4SE

微信搜一搜，关注“AI4SE”

昨天 Dify 1.17.0 正式发布，E2B 云沙箱、Skill 管理、工作流变量复用，功能确实很香。

但如果你正准备升级，先别急——GitHub Issues 已经炸了。

这篇文章不讲新功能，专门聊 1.17.0 生产部署的真实踩坑，帮你省掉排查时间。

坑一：升级后模型全挂了，一个都加载不出来

这是目前最严重的生产问题，Issue #41294 昨天刚报出来，评论区一片哀嚎。

症状：升级到 1.17.0 后，「集成管理」里的模型插件全部无法加载，默认模型配置页面直接崩掉。

根因：从 1.14.x 开始，Dify 内部把 model_type 的枚举值改了——text-generation 改成 llm，embeddings 改成 text-embedding，reranking 改成 rerank。问题是，数据库里已经存好的旧值没有自动迁移。

API 启动时读到旧的枚举值，直接抛 ValueError: 'text-generation' is not a valid ModelType，模型列表页面一片空白。

社区原话：「是谁闲的没事把旧的枚举值改了，能兼容就兼容啊」「不测试的吗？」

修复方案：

先备份数据库，然后手动跑 SQL：

-- provider_models 表
UPDATE provider_models SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE provider_models SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE provider_models SET model_type = 'rerank' WHERE model_type = 'reranking';

-- provider_model_credentials 表
UPDATE provider_model_credentials SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE provider_model_credentials SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE provider_model_credentials SET model_type = 'rerank' WHERE model_type = 'reranking';

-- tenant_default_models 表（可能有唯一约束冲突）
DELETE FROM tenant_default_models WHERE model_type IN ('text-generation', 'embeddings', 'reranking');

-- provider_model_settings 表
UPDATE provider_model_settings SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE provider_model_settings SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE provider_model_settings SET model_type = 'rerank' WHERE model_type = 'reranking';

-- load_balancing_model_configs 表
UPDATE load_balancing_model_configs SET model_type = 'llm' WHERE model_type = 'text-generation';
UPDATE load_balancing_model_configs SET model_type = 'text-embedding' WHERE model_type = 'embeddings';
UPDATE load_balancing_model_configs SET model_type = 'rerank' WHERE model_type = 'reranking';

跑完重启 API 容器。目前已经有人提交了 PR #41303 来修复这个兼容性问题，但还没合入。

建议：如果你是从 1.13.x 或更早的版本跨版本升级，这个问题几乎必中。升级前先跑上面那段 SQL，别等服务挂了再查。

坑二：Plugin Daemon 版本不匹配，插件页面 404

1.17.0 的 API 调用了 Plugin Daemon 的新端点（management/model/list、management/models/bindings），这些端点在旧版 Daemon 镜像里根本不存在。

如果你升级了 Dify 主镜像但忘了同步更新 dify-plugin-daemon，插件页面直接白屏，日志里全是 404。

正确的 Daemon 版本：langgenius/dify-plugin-daemon:0.6.10-local（从 0.6.3 升上来的）。

# 检查当前版本
docker compose images plugin_daemon

# 如果不是 0.6.10-local，更新 docker-compose.yaml 然后：
docker compose pull plugin_daemon
docker compose up -d plugin_daemon

另外，确认 PLUGIN_DAEMON_KEY 和 PLUGIN_DIFY_INNER_API_KEY 在 api 和 plugin_daemon 两个容器里是一致的——key 不匹配也会产生类似的白屏症状。

如果版本对了但还是报错，清一下 Redis 里的旧插件状态：

docker compose down
docker compose up redis -d
docker compose exec redis redis-cli FLUSHALL
docker compose up -d

等 60 秒让所有插件完成初始化再访问。

坑三：TTS 浏览器播放失败

Issue #35880 被标记到了 1.17.0 里程碑——TTS 生成的音频在浏览器里无法正常播放。

原因是 1.17.0 切换到了新版 Graphon TTSChunk 协议（Issue #40012），但前端播放器还没完全适配。

如果你的应用重度依赖语音合成，这个版本先观望一下，等热修复。

坑四：那些升级前就该知道的「老坑」

除了 1.17.0 特有的问题，Docker 部署还有一些反复出现的经典坑：

环境变量拼写错误占部署失败的 68%。POSTGRESQL_URL 写成 POSTGRES_URL，大小写不一致，这种低级错误在生产 .env 文件里屡见不鲜。建议用 CI 流水线注入 SHA256 校验。

内存不够，服务被静默杀死。 机器能跑起来不代表能灌知识库。内存不足时，系统 OOM Killer 会直接干掉 Worker 进程，Docker 自动重启，列表显示「运行中」，应用日志干干净净——因为进程是从外面被打死的，自己来不及写日志。遇到这种什么都不报的故障，去 dmesg 里翻内存击杀记录。

Redis 必须共享同一个 DB。 API 服务和 Worker 必须连同一个 Redis 数据库（推荐 DB 0），否则任务队列隔离失效，异步任务直接丢。

生产环境不要开 DEBUG。DEBUG=True 和 ENABLE_CORS=True 在开发环境无所谓，生产环境开这些等于裸奔。