先把当时的情况摆出来。Dify 0.15 自托管，Agent 节点调外部接口，60 秒就返回 Agent 节点执行超时，把节点上的 timeout 改成 300 仍然 60 秒断开。
把日志和配置对完，能解释这个现象的基本就这几处。工作流节点的执行时间有独立上限。少数情况下是Nginx 的 proxy_read_timeout 还是默认 60 秒。
不容易想到的是，celery 任务的软超时没有同步调整。还有一种情况，插件自身的请求超时优先级更高。
先改 Nginx 的读超时并 reload
python -c "print('proxy_read_timeout 300s;')"调整环境变量里的最大执行时间
python -c "print('APP_MAX_EXECUTION_TIME=600')"接着重启 api 和 worker 让配置生效
docker compose restart api worker等前面都确认过，再用 curl 直接打 Agent 接口测实际耗时
curl -s -o /dev/null -w '%{time_total}' -X POST http://localhost/v1/chat-messages -H "Authorization: Bearer $APP_KEY" -H 'Content-Type: application/json' -d @req.json同事提醒我看一下最近一次发布，时间点确实对得上。
恢复的判定其实很直接。耗时 90 秒的请求能正常返回，Nginx 日志里状态码是 200，不再出现 504 或节点超时。
这里还有个坑。Dify 的超时分散在 Nginx、应用和队列三层，只改页面上那个数字通常不够，改完要确认 worker 真的重启过。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。