Azure容器应用启用Dapr gRPC后服务调用报503错误排查

503服务不可用的核心原因是配置不完整，只设置了Dapr侧的gRPC协议参数，缺失了Azure容器应用平台层和Dapr端口映射的必要配置，导致Dapr sidecar无法和应用实例建立gRPC连接：

• Azure容器应用入站默认使用HTTP/1.1传输协议，gRPC依赖HTTP/2作为底层传输，协议不匹配会直接导致连接握手失败
• 执行dapr enable命令时未指定--dapr-app-port参数，Dapr sidecar默认使用HTTP规则探测、请求应用端口，和应用实际的gRPC监听端口不匹配
• 如果是ASP.NET Core应用，未配置Kestrel对应端口启用HTTP/2、或者应用只绑定127.0.0.1回环地址，也会触发同类连接失败

按顺序执行以下配置调整即可恢复：

1. 更新容器应用入站传输规则，开启HTTP/2支持：

az containerapp ingress update --name <替换为你的应用名>
                                --resource-group <替换为你的资源组名>
                                --transport http2

如果应用需要同时兼容HTTP/1.1和gRPC流量，将--transport参数值改为auto即可，无需强制锁定为http2

2. 重新更新Dapr配置，补全gRPC端口映射，端口值必须和应用实际监听的gRPC端口一致（比如多数.NET gRPC应用默认监听5001端口）：

az containerapp dapr enable --name <替换为你的应用名>
                            --resource-group <替换为你的资源组名>
                            --dapr-app-protocol grpc
                            --dapr-app-port <替换为应用实际gRPC监听端口>

无需提前执行dapr disable，直接执行enable命令即可覆盖原有Dapr配置

3. 校验应用本身的监听配置：
   • ASP.NET Core场景确认Kestrel已为对应gRPC监听端口开启HTTP/2支持
   • 确认应用监听地址绑定为0.0.0.0，不要绑定127.0.0.1，否则Dapr sidecar无法跨进程访问应用端口
4. 所有配置更新完成后，重启容器应用实例，待实例状态变为就绪后再验证服务调用功能即可。

内容的提问来源于stack exchange，提问作者spottedmahn