B2C中用户名字段含Email/UPN时出现Internal Server Error

碰到这个AADB2C90161内部服务器错误确实头疼，我来给你一步步拆解怎么排查：

第一步：精准定位App Insights里的错误细节 #

你说App Insights信息杂乱，那关键是用Correlation ID过滤日志，直接抓和这次失败相关的内容：

• 打开App Insights的「Logs」界面，用Kusto查询语句过滤：
  先查追踪日志：

  traces
  | where operation_Id == "cb299c64-219b-4870-9b4e-7c85fbbd2ae3"
  | order by timestamp desc
  

  再查异常堆栈：

  exceptions
  | where operation_Id == "cb299c64-219b-4870-9b4e-7c85fbbd2ae3"
  | project timestamp, message, stack
  

  这样就能看到真正导致内部错误的原因——比如自定义策略里的拼写错误、API调用失败、属性映射不匹配等，而不是只看到模糊的「Internal Server Error」。

第二步：针对常见原因逐一排查 #

这个错误是自我断言流程（self-asserted）发送响应失败，大概率和自定义策略或用户属性有关，重点查这几个方向：

• 检查属性映射是否正确：看看你在SelfAsserted-LocalAccountSignup或相关技术配置文件里，所有需要的属性有没有拼写错误、类型不匹配（比如把字符串属性映射到数字字段），或者遗漏了必填属性。
• 验证自定义表达式的合法性：如果用了Claims Transformations（比如AssertStringClaimsAreEqual、CreateStringClaim）或者条件表达式，检查语法是否正确，引用的声明是否存在。比如邮箱格式的正则表达式写错，就会导致验证失败触发内部错误。
• 排查自定义API调用（如果有）：如果注册流程里调用了后端API，确认API返回的是200状态码，没有抛出异常。在App Insights里搜API相关的日志，看有没有超时、权限问题或者返回格式错误。
• 确认用户名格式规则：虽然你用邮箱当用户名，但要检查策略里的用户名验证规则是否允许这种格式。默认策略是支持的，但如果自定义了验证规则，可能不小心限制了格式。可以看LocalAccountSignUpWithLogonEmail技术配置文件里的验证逻辑。
• 查看B2C门户的操作日志：去Azure门户的B2C资源里，进入「监控 > 日志」，用同样的Correlation ID搜索，这里有时候会给出更直白的提示，比如「属性XXX不能为空」或者「API调用超时」。

第三步：快速验证的小技巧 #

• 先用B2C默认的本地账户注册策略测试，如果能正常创建用户，那问题肯定出在你的自定义策略里。把自定义策略和默认策略对比，逐步排查你修改过的部分。
• 简化自定义策略：先去掉所有自定义的Claims Transformations和API集成，只保留最基础的注册流程，测试是否能成功。如果成功了，再一点点加回自定义模块，每次加完测试，就能定位到具体哪部分出问题。

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