一个之前案例，仅供参考
背景：
域名
a.com 10.0.0.2 （前端）,
b.com 10.0.0.3 （接口）, ab 同内网
a 本机绑定 host：10.0.0.3
b.api.coma 反向到当前 a 二级目录或者二级域名,nginx 拦截处理，也就是你们说的什么负载
请求是直接转发还是中间再加个什么代理或通信端口层自己看
例如我是直接 开了个转发端口
b.api.com:998b 机器绑定 a 机器的指向域名（如果没有用 ip ）
这样也就是你所说的隐藏后台业务服务器
梳理下就是
a.com/login --拦截或处理-->>
a.com/api/login --数据转发-->>
b.api.com:998/login效果大概如上
然后，对于如上方案，后面被 pass 了，从安全角度来说，确实做到了隐藏后端
只是我感觉吧，好麻烦，中间好几层消耗，太恶心了，没啥必要，纯粹增加时间和资源没什么意义
然后目前采用的做法是
前端-》中间处理层 -》后端
中间处理层与后端采用 rsa 通信，每 10 分钟更换通信 token
前端和中间层肯定有个基本的加密，例如你们常说的 jwt? 我是自己实现个内部算法
前端和中间处理层是一台服务器，后端是独立另外一台服务器
中间和后端的数据库不同
中间层放的是一些基础数据，后端放的是敏感数据
中间层往往是一个前端接口对应后端 n 个接口，最高的有 8 个接口对应一个前端接口
然后和楼上说的，你前端域名再走次 cdn
嗯，某种意义上来说，基本做到了完全隐藏你后端业务（大概，嗯是的）
当然，这套方案落下来，个人还是感觉好恶心，还在考虑其他优化方案，望大佬指点（递阔洛）