用户从微信打开页面，点击登录后没有回到网站，而是看到“redirect_uri域名与后台配置不一致，错误码10003”。这类报错发生在微信网页授权环节：授权链接里的 redirect_uri 指向一个回调地址，微信会核对该地址的域名与相应后台配置。

此时先保留出错的完整授权链接。只看业务页面的网址，容易漏掉真正提交给微信的回调地址。

打开授权链接，核对回调地址

在授权链接中找到 redirect_uri 参数，对其进行一次 URL 解码，再看解码后地址的主机名。比如用户正在访问 www.example.com，回调地址却是 login.example.com；两个地址看起来属于同一个网站，主机名并不相同。带不带 www 也要按实际地址核对。

假设一个公众号原先用 www.example.com 承接网页授权。网站改版后，登录程序把回调地址改成了 account.example.com，但公众号后台仍保留旧的网页授权域名。用户进入新页面后持续遇到10003。开发者从失败请求中解码 redirect_uri，发现它确实指向新域名，于是核对公众号后台配置，并将网页授权域名调整为当前回调使用的域名。

这次修改还没有覆盖所有入口：旧菜单仍可能生成旧授权链接，测试页面也可能沿用之前的地址。维护人员保留两条实际请求，分别从菜单和测试页面发起授权，再核对各自的 redirect_uri，避免只测通一个入口就结束排查。

配置已改，页面仍报10003

先确认修改发生在发起这次授权的公众号后台，并且改的是“网页授权域名”。JS接口安全域名、业务域名以及其他产品里的域名配置各有用途，不能因为它们已经填好，就认定网页授权也已匹配。若使用的是微信开放平台的网站应用登录，还要回到该应用对应的授权配置中核对，不要照搬公众号的配置位置。

另一个容易混淆的地方是参数编码。redirect_uri 放进授权链接时需要编码；排查时则要看解码后的完整地址。复制日志里的一串编码字符，与后台填写的域名直接比较，往往找不到差异。若项目有多个环境，也别只查看配置文件：重新发起一次请求，确认线上实际发出的地址，尤其留意旧链接、缓存页面或环境变量仍指向原域名的情况。

网页授权域名改动后，按后台提示完成验证和保存，再用新的授权请求测试。若报错还在，记录出错时间、使用的公众号或应用、完整授权链接，以及解码后的回调地址，交给有后台权限的维护人员对照。不要为了消除报错随意把回调地址改到陌生域名；授权完成后，浏览器会访问这个地址。

授权恢复后检查回跳

10003消失，只代表这一步的域名核对已经通过，页面能否正常登录还取决于回调接口的处理。测试时从用户原本的入口重新打开，观察微信授权后是否回到预期页面；若进入了回调地址却提示登录失败，就保留这次请求的地址和接口日志，转向回调处理排查，不再反复改网页授权域名。