重定向流量到OpenBMCLAPI时使用HTTP CODE验证可用性

[Ghost-chu]

测试时一直出现被重定向到的OpenBMCLAPI服务器下线的情况，建议对流量进行重定向前由服务端先向OpenBMCLAPI服务器发起一次请求确认服务器在线且正常工作再重定向用户流量。

[bangbang93]

每次都验证这不现实，负担太大了

[bangbang93]

从节点被动失效到心跳超时，有5分钟延迟，再加上cdn，最坏情况下会有30分钟的延迟，这个我暂时还没想到什么好的解决方案

[Ghost-chu]

从节点被动失效到心跳超时，有5分钟延迟，再加上cdn，最坏情况下会有30分钟的延迟，这个我暂时还没想到什么好的解决方案

可以通过概率请求检查状态，也可以由客户端报告。客户端下载失败的时候可以请求API接口通知BMCLAPI对节点主动检测。
如果失效则降权停用直到恢复。若一切正常则将目标IP区域的用户引流至其他节点或者是忽略。
可以通过缓存机制减少上述步骤对性能造成的影响。

[zyxkad]

客户端检测是个好主意，但容易被攻击

可以考虑让启动器作者给启动器开自己的反馈API，然后启动器作者再开一个服务器，过滤请求后，用bangbang给的密钥反馈

可以降低BMCLAPI被攻击的可能性（）

[lihugang]

客户端检测是个好主意，但容易被攻击

可以考虑让启动器作者给启动器开自己的反馈API，然后启动器作者再开一个服务器，过滤请求后，用bangbang给的密钥反馈

可以降低BMCLAPI被攻击的可能性（）

（启动器作者的服务器被攻击了

[lihugang]

从节点被动失效到心跳超时，有5分钟延迟，再加上cdn，最坏情况下会有30分钟的延迟，这个我暂时还没想到什么好的解决方案

可以通过概率请求检查状态，也可以由客户端报告。客户端下载失败的时候可以请求API接口通知BMCLAPI对节点主动检测。 如果失效则降权停用直到恢复。若一切正常则将目标IP区域的用户引流至其他节点或者是忽略。 可以通过缓存机制减少上述步骤对性能造成的影响。

可以考虑限流，即无论收到多少客户端报告，都是每分钟检查一次，如果未收到报告就不检查

[SALTWOOD]

每次都验证这不现实，负担太大了

隔一段时间使用HEAD请求到状态码？但这可不就是巡检了（

[SALTWOOD]

可以考虑根据信任动态调整巡检，信任低的2分钟高的15分钟这样