无负载均衡器时，WebView内嵌Web应用的高可用冗余部署方案咨询

嘿，我来给你几个针对这个场景的可行思路，都是绕开负载均衡器、同时保住IndexedDB数据的方案：

方案一：App层探活+IP直连+自定义Host头 #

• 先给你的Web应用绑定一个固定主域名（比如app.example.com），但App不直接用域名加载
• 把三台服务器的公网IP提前硬编码到App里，或者通过App的配置中心动态下发
• App启动/后台定期对这三个IP做可用性探测（比如发个HEAD请求到http://[IP]/health接口），筛选出可用IP列表
• 让WebView直接加载可用的服务器IP，同时强制设置WebView的请求Host头为你的主域名（比如Host: app.example.com）
• 核心优势：IndexedDB是绑定主域名的，切换IP不会丢失数据；而且App提前筛掉了故障服务器，用户不会碰到加载失败的情况

方案二：App内置轻量本地代理 #

• 在你的移动App里实现一个极简的本地代理服务，监听本地端口（比如http://localhost:8080）
• App先探活三台服务器，选出可用的目标IP
• WebView只需要加载本地代理地址，代理服务负责把请求转发到可用的服务器IP，同时带上正确的主域名Host头
• 优势：WebView完全不用关心后端服务器的IP，对Web应用代码零侵入；代理层还能额外做请求重试、失败自动切换服务器的逻辑

方案三：服务器同步+单域名多IP+App层故障重试 #

• 给三台服务器配置相同的SSL证书（对应你的主域名），并让它们实时同步Web应用的所有静态资源和后端数据（比如用定时同步脚本或者分布式存储）
• App里还是用主域名加载，但在WebView加载失败时（比如捕获到net::ERR_CONNECTION_REFUSED错误），App主动切换到备用IP加载（同样设置Host头）
• 注意：这种方式需要App监听WebView的加载错误事件，触发时手动切换IP，比前两种方案的可靠性稍弱，但实现起来更简单

最后再提几个小tips：

• 探活接口要尽量轻量，比如只返回200状态码，不要带冗余数据，减少网络消耗
• 如果用HTTPS，务必确保所有服务器的证书都包含你的主域名，不然WebView会弹出证书错误
• 可以在App里缓存最近可用的IP列表，避免每次启动都要探活

备注：内容来源于stack exchange，提问作者Kukulkan