OAuth redirect_uri_mismatch、OAuth回调地址不匹配、OAuth生产环境登录失败怎么查？先提取实际redirect_uri，再按Google、Microsoft Entra与GitHub的应用类型、登记值和失败阶段分流。
先看这组故障信号。
本地能登录，生产环境却停在提供方错误页；或者浏览器已回到业务域名，又被送回登录入口。表面都像“回调坏了”，证据链却不在同一层。排查OAuth redirect_uri_mismatch、OAuth回调地址不匹配、OAuth生产环境登录失败，先保留请求现场。
先看结论： OAuth redirect_uri_mismatch、OAuth回调地址不匹配、OAuth生产环境登录失败应先分成两类失败阶段；提取实际请求值后，再按三家平台、应用类型与登记字段核对，回到应用后才转查会话链。
先定失败阶段：错误发生在授权端点，还是应用回调之后
OAuth故障的高维分界，是浏览器停在哪里。授权端点直接拒绝请求时，重点证据是错误码、当前App ID和实际redirect_uri。浏览器已经回到应用，再出现重复跳转或重新登录，排查对象便从地址登记扩展到回调处理与会话承接。
真实情况是——同一个“登录失败”提示，可能覆盖两条链路。redirect URI是“授权后送回应用的地址”；state像登录往返的校验票据；session保存应用登录状态。
先做以下动作，且只观察自有或获授权环境：
记录错误发生前后的页面域名，判断浏览器是否到达应用回调路径。阶段记错，后续修改就会跑偏。
保存提供方返回的错误码与当前App ID。若看到AADSTS50011，把它和本次请求一起留存，不要只抄页面文案。
从浏览器授权请求或应用日志提取实际redirect_uri，原样保留scheme、host、port、path及可见参数，不凭记忆重写。
另存同一时间段的回调日志。若授权端点没有把浏览器送回应用，回调日志为空本身就是阶段证据。
业界存在多种框架与代理实现，错误页、参数生成位置和日志字段并不固定。此处只建立取证入口，不把某个框架的表现写成平台规则。
先定位拒绝发生在哪一侧，再讨论改哪一侧。
还原redirect_uri：从浏览器请求倒查公开地址生成链
生产环境多了一层网关，也多了一层地址转换逻辑。应用眼中的请求也许来自内部HTTP和容器主机名，用户看到的却是外部HTTPS域名。若框架据此生成回调地址，实际值就可能偏离登记值。反向代理OAuth回调要把公开地址和应用拼接URL的基址放在同一条证据链上。
按以下顺序倒查，不先改值：
浏览器请求层：复制授权请求中的redirect_uri。这是提供方实际收到的候选值，也是后续对比基准。
公开入口层：核对用户访问的scheme、host、port和回调路径；若经过CDN或反向代理，再查看获授权范围内的代理配置与转发头。
应用生成层：确认回调地址来自固定配置、环境变量、请求推导，还是托管认证组件。多租户场景还要记录当时进入的是哪个租户域名。
平台登记层：进入对应App ID和应用类型的当前控制台，逐项对照登记值。不要拿测试应用的登记项解释生产请求。
这里的“公开基址”可以理解为应用对外报出的门牌。门牌由谁生成，决定应修应用配置、代理传递还是托管组件设置。若使用Firebase，并且命中特定代理条件，官方资料支持把新的authDomain加入OAuth提供方授权重定向URI列表；这个动作不能外推到其他代理或身份框架。
核查只限获授权的浏览器工具、日志、代理配置和平台控制台。修改前保留当前值，修改后发起新请求，不接触或复用旧请求中的凭据。
当团队连“哪次发布改变了公开基址”都答不上来，地址对比仍会退化成猜测。问题导入句是：怎样让回调故障与环境变更落到同一时间线上？
三平台条件化速查：先对请求值，再看应用类型
三家平台放在一张表里，只为确定诊断分支，不用于评价平台。菜单名称、字段位置和未被证据覆盖的限制，应以当前控制台为准。OAuth redirect_uri_mismatch、OAuth回调地址不匹配、OAuth生产环境登录失败在这一阶段要回答的是：实际值发给了谁、登记在什么应用类型下、官方已证实的边界到哪里。
| 平台与应用类型 | 实际请求值 | 登记字段 | 已证实匹配边界 | 错误证据 | 判断依据 | 下一动作 |
|---|---|---|---|---|---|---|
| Google Web应用 | 浏览器授权请求中的redirect_uri | 已授权的重定向URI | Web应用要求精确匹配已授权登记值 | redirect_uri_mismatch相关现场 | 实际值与当前Web应用登记值逐字对照，且App ID属于本次请求 | 值不一致时判断应修登记项还是公开基址；一致仍报错则保留现场并查当前官方路径 |
| Microsoft Entra Web | 本次请求的redirect URI | 对应应用注册中的Web重定向URI | 请求值未匹配登记值时可返回AADSTS50011 | AADSTS50011、App ID与请求现场 | 错误发生在授权端点，实际值与该应用注册记录不一致 | 核对生产应用注册、当前应用类型与租户上下文；开发和生产宜分开注册 |
| Microsoft Entra SPA | 本次请求的redirect URI | 对应应用注册中的SPA重定向URI | 类型边界按当前官方规则与控制台字段复核 | 错误码、App ID、应用类型 | 请求落在SPA类型，登记却位于另一应用类型或另一注册 | 把请求与正确类型、正确环境的注册对齐，不照搬Web项 |
| Microsoft Entra native | 本次请求的redirect URI | 对应应用注册中的native相关字段 | 未证实细节为N/A | 错误码、App ID、应用类型 | 当前客户端属于native，而团队拿Web或SPA登记项作对照 | 停止跨类型套规则，转查当前官方文档与控制台 |
| GitHub OAuth App | 授权请求中的redirect_uri | 当前OAuth App的callback相关登记 | redirect_uri用于授权后把用户送回应用；匹配细节N/A | 请求现场与应用标识 | 先确认实际值、应用归属和登记字段；路径、端口等细节不自行推断 | 依据当前官方规则核查；证据仍不足时标N/A并升级官方支持 |
| GitHub App | 授权请求中的redirect_uri | 当前GitHub App的callback相关登记 | 已证实匹配细节N/A | 请求现场与应用标识 | 实际使用GitHub App，却误用OAuth App的登记位置解释故障 | 回到正确应用类型核对当前控制台，保留差异证据 |
这张表也是决策速查表。授权端点报错且实际值偏离登记值，判断登记或公开基址；应用类型错位，回到正确注册；浏览器已回到应用，转查state、cookie与存储。低风险信号是请求值、登记值、应用类型和环境归属清楚；中风险信号是差异能定位到公开基址或注册项；高风险信号是App ID、应用类型或环境归属混用，配置来源不明。
执行时保留原始请求与登记截图，任何变更都以新请求验证。Google Web的精确匹配结论只用于Google Web；Microsoft的分环境注册建议只用于Microsoft；GitHub未获支持的细节继续写N/A。
第一组FAQ：登记值与应用类型快答
Q：Web和SPA看起来都回到同一域名，能共用同一类登记吗？
A：先看发起授权的客户端类型，而不是只看域名外观。Microsoft Entra会区分应用类型字段；若请求来自SPA，登记却放在Web项下，应先纠正类型归属。反例是：即使两个地址文本相同，类型错位仍不能靠“看起来一样”排除。
Q：实际redirect_uri和代码配置相同，为什么仍会报错？
A：新增的判断维度是“运行时到底读取了哪份配置”。构建产物、环境变量、托管认证组件或租户域名都可能让运行值偏离代码仓库。应以浏览器实际请求为准，再追配置来源；仓库文本不是请求证据。
真的是地址不匹配吗？未必：登录循环要换证据
授权端点已经接受请求，浏览器也回到应用，此时继续反复修改redirect_uri，往往是在错误层面用力。反共识点就在这里：能回到回调地址，不等于应用已经建立登录状态；回调后循环也不等于登记地址仍然错误。
先按阶段分流：
仍停在提供方错误页：继续对照实际URL、App ID、应用类型、环境与租户上下文。Google Web看精确匹配证据；Microsoft Entra结合AADSTS50011和注册项；GitHub未证实的匹配细节保持N/A。
已经到达应用回调：检查回调日志是否收到预期请求，随后查看state是否能对应当前浏览器发起的流程、cookie是否在当前公开域名与HTTPS条件下被浏览器接受、session是否成功写入与读取、共享存储是否让不同实例看到同一状态。
回调成功后又跳回登录页：把跳转前后的会话标识、实例路由和存储读取结果串起来。旁白式地说，授权提供方已经把人送到门口，接下来是应用自己能否认出访客。
这些方向属于行业通识诊断对象，不是Google、Microsoft或GitHub的原生根因清单。检查范围仍限于获授权的日志、浏览器存储视图和应用配置，不提取、复制或重放敏感凭据。
真正的分水岭，是浏览器有没有回到应用。
OAuth授权回调解决“授权后把浏览器送回哪里”；Webhook则是服务端事件通知的接收入口。两者都可能叫callback，但参与方、触发方式与证据面不同。问题导入句是：如果业务更新失败，眼前这个地址究竟属于浏览器登录，还是服务端事件通知？
别把浏览器登录回调与服务端Webhook接收地址混成同一类故障
第二组FAQ：别让环境与责任边界继续制造错配
Q：OAuth回调地址和Webhook有什么区别？
A：一个实用的新视角是看“谁主动发起、谁承接状态”。OAuth/OIDC登录回调承接浏览器授权流程；Webhook承接服务端事件通知。反例是把Webhook接收地址填进登录应用注册：名称里都有callback，也不会因此变成同一种入口。
Q：什么情况下应该改平台后台，什么情况下改公开基址？
A：看哪一侧偏离了团队认可的生产公开地址。实际请求值生成正确、但当前应用登记仍是旧环境时，候选动作是修登记；登记值正确、应用却生成内部协议或错误主机名时，候选动作是修公开基址生成链。若两边都缺少变更依据，先恢复证据，不同时改动。
Q：AADSTS50011怎么解决，是否只要添加当前地址？
A：先确认错误对应的App ID、应用类型、环境与租户上下文。Microsoft建议开发与生产分开使用应用注册；若请求落到了测试注册，直接往测试项追加生产地址会扩大环境混用。地址对齐后仍有回调后循环，则进入会话链，而不是继续堆登记项。
Q：GitHub callback URL该怎样比较路径、端口或尾部字符？
A：本安全事实边界没有支持这些匹配细节，结论记为N/A。可执行动作是保留实际redirect_uri、应用类型、当前登记值和错误现场，再查当前官方规则或升级官方支持；不要套用Google Web的精确匹配结论。
管理坑往往是归属不清：生产与测试共用注册；公开入口变更后无人同步身份配置；托管组件与业务应用各存一份基址；多租户域名缺少登记项负责人。每项都应落到配置来源与变更记录。
如果故障反复出现，下一步问题就不是“再填一次地址”，而是接入前有没有划清环境与维护责任。
生产环境频繁出现身份集成错配，要回看接入前是否划清环境与维护责任
带着材料升级，而不是带着一句“线上登不上”
登录入口在生产环境失效时，注册页可能停住，运营后台进不去，合作方访问也可能被同一处配置挡在门外。此时先保留错误证据，再改配置。否则页面恢复与否都难以解释，后续发布还会重新踩中同一条链路。
升级材料包应包含：
错误码、发生阶段、时间顺序与复现入口；
当前App ID、平台、应用类型、环境和租户上下文；
浏览器实际redirect_uri与控制台登记URI，差异处原样标明；
用户公开基址、代理转发头、托管组件配置来源与最近变更记录；
回调日志、state校验结果、cookie接收情况、session写入读取和共享存储证据；
未获确认的规则统一标N/A，并附当前官方支持所需的现场材料。
尤其在出海游戏与SaaS的多域名、多环境、第三方集成并行场景里，登录回调排障会同时牵动网关、应用注册和会话状态。WG官网公开展示智能包网、游戏API与官方商务入口；如需沟通第三方API/SaaS集成中的环境、日志、回调和维护职责，可通过WG官方商务入口联系。沟通范围不替代平台官方支持，也不预设修复结果。
联系WG.com，可先完成一次第三方登录集成排障与OAuth身份集成维护的材料对照，重点核查：环境与App ID归属、实际URI与登记URI差异、公开基址生成链、回调后的会话证据。提交前再用OAuth redirect_uri_mismatch、OAuth回调地址不匹配、OAuth生产环境登录失败这条主线检查材料：先定阶段，再对实际值，最后才决定改后台、改公开基址或转查会话。