用户从公众号菜单或分享链接进入网页，页面尚未完成微信授权，就看到“redirect_uri域名与后台配置不一致”，错误码10003。此时改页面里的登录按钮，往往不会改变结果：微信在跳回业务页面之前，已经检查了授权请求中的回调地址。

排查时先保留报错页面或发起跳转前的链接。链接中的 redirect_uri 是微信授权完成后准备返回的地址，检查它的主机名，再与对应公众号配置的网页授权域名核对。这里要核对的是实际发出的请求，不能只看项目文档里写了什么。

链接里写的域名，和后台填的是两个地址

授权链接经过多次跳转后，浏览器地址栏里最显眼的可能是微信的地址，而业务回调地址藏在 redirect_uri 参数中。将该参数解码后，可能看到 https://h5.example.com/callback。如果公众号后台登记的是 www.example.com，两个地址就不一致；即使它们都指向同一套服务，也不能据此认定微信会放行。

域名切换时，这类差异尤其常见。例如，一项公众号活动原先从 www.example.com 进入，改版后页面迁到了 h5.example.com。页面本身能打开，菜单也已更新，但授权链接仍由旧服务生成，或者新服务已把回调地址改为 h5.example.com、后台却保留旧域名。用户看到的都是10003，处理位置却不同。

这时先取一条失败请求，确认其中的回调域名。如果请求发出的仍是旧地址，检查生成授权链接的配置和实际运行版本；如果已发往新地址，就核对公众号的网页授权域名配置。团队决定把授权回调迁到新域名后，还要确认该域名能接收回调，按后台要求完成域名校验。旧活动链接可能仍在传播，不能只测试新版菜单：旧入口若继续发起授权，也要有对应的处理安排。

配置已修改，报错却还在

后台保存成功后，先重新发起一次授权，不要反复刷新停留在报错页的旧链接。旧链接里的 redirect_uri 不会因后台修改而自动变化。测试时记录新请求的完整回调地址，并确认它使用的是刚修改的那个公众号；多个公众号共用页面时，改错账号的配置也会让排查停在原地。

如果域名已吻合，再检查链接是怎样拼接的。回调地址包含路径或查询参数时，应作为整体正确编码；编码混乱可能让实际传出的地址偏离预期。核对时把解码后的完整地址与服务端生成的原始地址放在一起看，留意子域名、端口以及多余字符，而不是继续凭印象修改后台域名。

不要把所有“域名设置”当成同一项

公众号后台可能还有 JS 接口安全域名、业务域名等配置，它们对应不同用途。遇到微信网页授权的10003，应围绕网页授权域名和授权链接中的 redirect_uri 排查；仅修改 JS 接口安全域名，通常解决不了这条报错。若故障发生在微信开放平台的网站扫码登录，则应去核对该应用的授权回调域，而不是反复查公众号设置。

排查结束前，用发生故障的入口重新走一遍跳转，保留失败链接和修改后的测试链接。若只有旧菜单或旧分享链接报错，就继续追查那些入口生成的授权地址；若所有入口都报错，再确认当前请求所属账号及其回调域名配置。