使用REST API发送消息至Azure Service Bus Topic，消息进入死信队列

1. 检查主题/订阅的死信规则配置 #

• 确认目标订阅是否设置了自动死信触发规则：比如消息TTL（过期时间）过短，消息未被处理就过期；或是最大传递次数阈值过低，消息被退回几次后直接进入死信队列。
• 排查订阅的过滤规则是否存在错误，若规则逻辑导致消息被判定为不符合订阅要求，也可能触发死信（虽这类场景通常不会返回201，但仍需验证）。

2. 直接在Azure门户查看死信消息详情 #

登录Azure门户，进入对应Service Bus命名空间，找到目标主题的订阅，切换到「死信队列」标签，选中异常消息后查看系统属性里的DeadLetterReason和DeadLetterErrorDescription字段——这两个字段由Service Bus自动记录，哪怕是REST API发送的消息也能直接在门户查看，无需依赖SDK。

3. 校验REST API请求的格式与头部参数 #

• 确认请求头部Content-Type已正确设置为application/atom+xml;type=entry;charset=utf-8，Service Bus的REST API要求消息体必须是Atom格式的XML。
• 检查消息体<content>节点内容：是否有未转义的特殊字符、消息大小是否超出主题的最大限制（默认256KB，可调整）。
• 若订阅是会话感知类型，REST API也可通过请求头部传递会话ID：添加BrokerProperties: {"SessionId": "your-custom-session-id"}即可，并非只能通过SDK实现。

4. 验证权限配置 #

• 确认调用API使用的SAS令牌或托管身份拥有目标主题的Send权限，且权限范围覆盖该主题（SAS令牌需确保签名的资源URI是主题的完整路径）。
• 即便返回201状态码，若权限存在部分限制（比如仅允许发送但订阅有特殊权限约束），也可能导致消息进入死信队列。

5. 启用Service Bus诊断日志 #

在Azure门户开启Service Bus的诊断日志，选择记录「OperationalLogs」和「MessagingLogs」，日志中会包含消息从发送到进入死信队列的完整流程细节，可定位是过期、规则匹配失败还是系统层面的问题。

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