Dapr边车调用失败时，应用侧经常只看到 timeout、connection refused 或 5xx，但真正断点可能在 sidecar 注入、app-id、端口映射、服务发现、mTLS 或 resiliency 策略。排查不要只看业务日志，要把应用容器、Dapr sidecar、目标服务和控制面事件串起来看。
如果你正在梳理微服务架构基础，可以先从服务治理的注册发现、重试和限流边界建立上下文；本文聚焦 Dapr 调用链路。
图1：从应用超时到 sidecar、服务发现和目标实例的 Da
先确认调用是否真正经过 Dapr sidecar
> 排查 Dapr service invocation 时，应先确认请求是否经过 sidecar、app-id 是否可解析、目标应用端口是否匹配。 > – Dapr Service Invocation 官方文档[1]
第一步要确认 Pod 是否注入了 Dapr sidecar，以及应用是否调用了正确的 sidecar 地址。Dapr Service Invocation 官方文档[1]说明，服务调用需要通过 Dapr sidecar 解析目标 app-id 并转发请求；下面的命令行检查也围绕这一链路展开[1]。
kubectl get pod -n app -l app=checkout -o jsonpath='{.items[*].spec.containers[*].name}'
kubectl logs deploy/checkout -n app -c daprd --tail=100
kubectl describe pod -n app -l app=checkout优先检查：
- Pod 中是否存在 `daprd` 容器。
- 应用调用端口是否为 sidecar HTTP/gRPC 端口。
- 目标服务是否设置了正确 `dapr.io/app-id`。
- 应用真实监听端口是否与 `dapr.io/app-port` 一致。
很多失败来自 app-id 拼写不一致或端口标注错误。此时重试策略不会解决问题，只会放大延迟。
超时与重试要看策略是否匹配业务
Dapr 支持 resiliency 策略，但策略不是越激进越好。Dapr Resiliency 官方文档[2]将重试、超时和熔断作为弹性策略能力；对非幂等写操作盲目重试，可能造成重复请求。
图2：Dapr sidecar、resiliency 策略、目
| 现象 | 可能原因 | 检查重点 |
|---|---|---|
| 立即 connection refused | 目标 app-port 错误或应用未监听 | Pod 端口、容器日志 |
| 调用长时间超时 | 目标服务慢或网络不通 | sidecar 日志、目标服务指标 |
| 大量重复请求 | retry 策略过强 | 幂等性、重试次数、退避 |
| 间歇失败 | 实例扩缩容或服务发现延迟 | endpoint、Pod 生命周期 |
命名空间与网络策略也要纳入链路判断
表格之外，还要看调用是否跨 namespace、是否启用 mTLS、是否存在网络策略拦截。
日志排查要同时看调用端和被调端
只看调用端 sidecar 日志容易误判。目标服务 sidecar 可能已经收到请求但应用处理慢，也可能完全没有收到请求。
建议按顺序查看：
- 调用方应用日志。
- 调用方 `daprd` 日志。
- 目标方 `daprd` 日志。
- 目标应用日志。
- Dapr control plane 组件事件。
如果你已接入链路追踪，可以继续把 Dapr 调用与业务 span 串起来，避免只靠日志对时间线。Dapr 在 Kubernetes 中运行时还涉及注入、控制面和 sidecar 生命周期，必要时再核对 Kubernetes hosting 相关说明。
修复后验证要覆盖成功率和副作用
图3：从修改 app-id、端口或策略到压测观察和回滚的验证时
上线前至少检查：
- app-id、app-port、namespace 与调用 URL 是否一致。
- 调用端和目标端 sidecar 均无持续错误。
- 超时和重试策略符合接口幂等性。
- 指标中错误率、延迟和重试次数回落。
- 修改策略有回滚方式。
不要只用一次 curl 成功作为恢复结论。Dapr 调用问题往往是间歇性的，至少要观察一段时间的错误率和 P95/P99 延迟。
小结
Dapr边车调用失败的排查重点是链路分段：应用是否经过 sidecar，app-id 与端口是否匹配，服务发现和 mTLS 是否正常，resiliency 策略是否放大问题，目标服务是否真正可处理请求。先定位断点，再调整策略，避免用重试掩盖配置错误。
参考资料
常见问题
1. Dapr边车调用失败时先看应用日志还是 daprd 日志？
两者都要看，但建议先确认请求是否进入 sidecar。应用日志能说明调用意图，daprd 日志能说明服务发现、连接和策略执行情况，两者时间线要对齐。
2. 增加重试次数能解决 Dapr 超时吗？
不一定。若目标服务已经过载，更多重试会加重压力。只有在短暂网络抖动或可恢复错误场景中，合理重试才有帮助，并且要确认接口幂等。
3. Dapr 和服务网格能同时使用吗？
可以，但要明确边界。Dapr 更偏应用能力抽象和 building blocks，服务网格更偏流量治理与代理层能力。两者叠加时要避免超时、重试和 mTLS 策略互相冲突。
4. 如何判断是 Dapr 问题还是目标服务问题？
看目标 sidecar 和目标应用是否收到请求。如果目标 sidecar 没有记录，优先查发现、网络和 mTLS；如果目标应用收到请求但处理慢，重点转向业务逻辑、依赖和容量。
