原文：https://blog.csdn.net/weixin_44050791/article/details/132095710

关于微信公众号-网页授权域名，域名配置个数不够用的情况梳理

1. 网页授权机制

如果用户在微信客户端中访问第三方网页，公众号可以通过微信网页授权机制，来获取用户基本信息，进而实现业务逻辑

2. 去微信后台配置域名

在网页授权机制里面 redirect_uri是我们的项目地址，这个项目地址的域名是需要到公众号平台配置的， 否则会提示redirect_uri域名与后台配置不一致。

配置域名：登录微信公众平台–设置–公众号设置–功能设置–网页授权域名

3. 域名不够用怎么办

在微信公众号管理后台，我们可以看到网页授权域名，只能配置2个。对于正规业务和比较少的业务来说比较简单，配置一个域名就可以。

但是我们公司比较混乱，经常会出现：在一个公众号项目塞入3个产品线的项目，各个产品线又都有自己的独立二级域名 。
比如A产品线的独立域名是a.baidu.com
B产品线的项目域名是b.baidu.com
C产品线的项目域名是c.baidu.com

更槽糕的是此时域名已经被占用了一个，一个同事已经配置了一个域名2 （吐槽：他甚至配置的还是一个深层次目录），所以只剩下域名1可以用：

4. 解决方案

首先要明确，微信的网页授权域名和公众号项目代码的访问域名，是要一致的。

4.1 不新增配置域名1，会怎么样

如果不新增域名1的配置，大家一起共用当前这个域名2的话，那么以后该公众号下面的所有产品线的项目代码都要塞到这个域名2下面。

首先这是不太合理的，从域名上来看，比如公用域名设置的是news.baidu.com/list/，但是其中一个项目的业务是考试（exam）。如果把考试项目因为业务需要要链接发给用户使用，那么域名里面的news和list就对于考试业务来说就显的不太正规。

其次上线也不太方便，如果有运维统一上线还好说，如果是各项目独立负责上线就很麻烦了，你的项目塞在别人的目录下面，每次上线还要拉人别人，上线次数多了怎么办，深夜上线怎么办。而且有的部门喜欢碰瓷。。。。

4.2 如何新增配置域名1

配置一个比较通用的域名，比如yth.baidu.com 。
然后在这个通用域名的机器上，配置nginx 代理转发（proxy_pass），转发到专门的项目就可以 ：

比如A项目的实际域名是a.baidu.com。使用这种方案以后，在微信公众号里面的访问路径则是yth.baidu.com/a
比如B项目的实际域名是b.baidu.com。使用这种方案以后，在微信公众号里面的访问路径则是yth.baidu.com/b

这样的做的原因有以下几点：
① 多条业务线，可以不用塞在一个目录下面。大家独立管理部署自己的业务线项目代码就可以。yth.baidu.com则统一负责微信配置文件的验证和nginx转发

  # yth.baidu.com机器的nginx配置文件

  # 微信验证文件
  location /MP_verify_666.txt {
    add_header  Content-Type  "text/plain";
    alias /data/servers/gateway/MP_verify_666.txt;
  }

  location /a/  {
    proxy_pass https://a.baidu.com/;
  }


  location /b/  {
    proxy_pass https://b.baidu.com/;
  }

1234567891011121314151617

② 域名友好型，各项目业务线可以在yth.baidu.com下面设置符合自己业务需求的目录名。比如新闻业务可以设置为yth.baidu.com/news/ , 考试业务可以设置为 yth.baidu.com/exam/

③ 具备可扩展性，后期再在当前公众号增加其他业务线的项目，只需要在yth.baidu.com 的nginx配置文件 增加一条proxy_pass配置即可

④ 就我们公司而言，负责转发的这台机器，还配有阿里云的slb（负载均衡）。可以在一定程度上缓解访问量过大造成的压力

⑤ 还有一点特殊情况是：除了使用域名+服务器，当然也可以直接使用oss来处理当前的情况。

但是这里要注意一点，oss不支持前端那种history 路由，它会把这种形式当做真实目录去查找。比如b.baidu.com/news/details 对应的是一个前端页面，但是oss会真实去找news目录和details，从而导致访问失败。

当然也可以把项目改成hash路由，但是不方便，而且直接把项目改成hash以后会不会有什么其它潜在的问题，再者说，如果项目不在自己手里，你想让别人改，别人还不一定愿意改。

基于这种情况考虑和后续扩展性的考虑，最终没有使用oss的方案

4.3 抛砖引玉

大家有什么更好的方案，可以提出来