10｜流程失败时，先找到坏掉的那一步

如果想获取全套课程资料，请关注微信公众号 「AI面包君」，回复 「课程资料」 即可领取。

同样一句“运行失败”，可能是输入没传到、模型不可用、接口连不上，也可能是服务明确拒绝请求。这一节主动调用一个始终返回 503 的教学接口，观察失败与有限重试，再用一张排查表区分不同问题。

目的不是把红色节点都变绿，而是让错误可以解释、次数可以控制、下游不会把失败当成功。

1. 先确认你确实打到了教学接口

保持模拟服务运行。新建 Bread-10-观察重试，输入保留必填 query，后接 HTTP 请求。环境变量 api_base 使用已经验证可达的地址，mock_api_key 使用教学 token。

HTTP 方法 GET，地址为 api_base 加 /demo/unavailable，请求头设置 Authorization 为 Bearer 加 token。连接超时设 5 秒，读取与写入设 15 秒，先关闭自动重试。

输出节点暂将 answer 绑定 HTTP 的 body。运行一次，然后同时查看 Dify 节点详情与模拟服务终端。必须确认收到 HTTP 503，才能继续做下面的重试对照；DNS、连接超时或 401 都不是同一个实验结果。

实际接口记录：这个路由故意一直不可用，用来稳定触发失败。它不会因为多试几次就变成成功。

先判断有没有真正收到服务端回答

想象打电话询问一件事：号码拨不通，和对方接起来说“现在无法办理”，不是同一种结果。前者连通信都没有建立，后者已经有明确回应。

503 属于服务端明确返回的状态；连接超时、域名解析失败等发生在不同位置。你如果连到了错误地址，即使页面也显示失败，就没有完成本节的 503 实验。

因此先检查状态码、节点错误和模拟接口日志三项。能够对应同一次请求，才能说自己确实在测试这条路线，而不是把所有红色图标当成相同故障。

2. 开启有限重试，比较请求次数

打开 HTTP 节点“失败时重试”，最多重试设 2 次，间隔设 1 秒；界面若用毫秒，填 1000。异常处理保持默认失败终止，避免额外兜底路线干扰观察。

再次运行，记下开始时间。在课程基线行为下，应出现首次尝试加两次重试，最终仍失败。用接口终端中这次新增的 GET 记录核对次数，别把上一次关闭重试的请求一起数进去。