发布于 1 个月前
发布于 1 个月前
huangjt
更新于 1 个月前
0
0
我们使用场景如下:雷池前端部署有nginx,因为考虑到用户体验,前端的nginx有分流规则。指定的域名,特定的目录,当请求量超过一定的值后,超出的流量才会分流到雷池。目前的情况是,当访问量较大时,某个正常用户可能某一次访问刚好分流到雷池,于是触发了人机验证,跳出来人机验证界面,然后验证通过后会再次刷新该页面,但是刚好这次访问没有分流到雷池直接proxy到后端服务器。是不是雷池就认为是没有通过人机验证,导致下次再次分流到雷池后再次触发人机验证。。请问这种情况如何解决?
能否改变一下验证流程,提示通过验证后就在服务器保存该用户浏览器的cookie,而不是通过雷池跳转到正常页后才认为是验证通过?
或者是否增加一个自定义判断规则,例如某个站点每分钟请求量超过一个阀值后再触发人机验证。这样我可以在前端nginx设定指定目录的所有流量都经过雷池,然后由雷池去判断请求量,超过一定阀值后就触发人机验证,这样就能保证每次访问都能通过雷池,并且一样可以设定验证有效期,
齐天大圣孙悟空
更新于 1 个月前
0
0
这是典型的负载均衡算法的选择问题...你的分流设备改成 IP Hash 算法就没问题了
huangjt
更新于 1 个月前
不是这个意思。贴一下nginx大概配置你就明白
1…… 2limit_req_zone $server_name zone=limit:10m rate=100r/m; 3limit_req_status 429; #定义请求频率,1分钟超过100r,超出的请求就返回429错误码。 4…… 5server { 6…… 7server_name *.abc.com; 8location ~* \.html$ { 9limit_req zone=limit; 10error_page 429 = @anticaiji; 11proxy_pass http://upstream; 12…… 13location @anticaiji 14proxy_pass http://safeline; # 正常情况直接proxy到后端服务器组(服务器ABC轮询),429时proxy到雷池,雷 15 池也配置有*.abc.com域名,并设置后端代理服务器组upstream(服务器ABC轮询)。
这样配置目的主要是为了不影响用户体验,不会大批量出现人机验证界面。(正常访问量下都是直接proxy到后端服务器,雷池没有流量经过),但是当有大量的机器采集时(超过100r/m),超过的流量就会引流到雷池并做人机验证。那么就会有前面的问题,正常用户验证界面出现后并提示通过验证后会再次请求该页面,但是这次请求在limit内所以直接proxy到了后端服务器没有proxy到雷池,所以雷池会认为没有通过验证。导致下次流量经过雷池后又再次出现验证界面。。。
齐天大圣孙悟空
更新于 1 个月前
0
0
你想要的是不是这个功能
huangjt
更新于 1 个月前
不是,这个是限定某个IP的
huangjt
更新于 1 个月前
大批量机器采集过来,基本都是分散不同的IP,只能通过限定总的请求量,单个IP的访问频率,可能就个位数。
齐天大圣孙悟空
更新于 1 个月前
那你想要的应该是这个 - 等候室
huangjt
更新于 1 个月前
也不是,等候室是等候状态。适用于大量访问都是正常用户的前提,但是服务器又承受不了这种压力的情况。
我们使用雷池的只要目的就是人机验证。平时的访问量流量,一部分是正常用户,一部分是机器采集,但我不需要所有访问都经过雷池,这样会有大量用户出现验证界面(没办法,用户比较作,觉得体验度不好,市场也不希望用户来投诉),于是就有了前端nignx请求量限定的策略。只希望出现大量的机器采集时,超过的部分才经过雷池的人机验证。(这部分一样也是既有用户也有机器),但这时用户出现验证界面毕竟数量大大减少了,但是至少得保证该用户通过验证后,在设定的验证有效期内不会再次出现人机验证界面,否则用户体验度不是更差吗
雷池 - 小小
更新于 1 个月前
0
0
可以直接在 nginx 加个 if 条件。判断 header 有 sl-challenge-jwt
则跳转到 waf