@NoOneNoBody #30
更像是个数据代理，把客户请求及爬取返回内容优化？
————————
对，是做的这个


如果内容有大量重复，建议按规则做缓存，减少爬取次数
————————
现在服务端只处理数据，不会主动存储，客户端做了数据落库的缓存，但是也提供了“刷新”缓存数据的功能，每天第一次打开 APP 的时候会执行登录逻辑然后获取数据，这样做的原因也是因为以前出现过显示错误数据的情况导致了一些问题

@NoOneNoBody 有成功的，甚至现在都有成功的，因为正方提供的是教务数据，也就是课表之类的东西，学生上课时间是固定的，所以几年来只要是上课的日子都会在固定的时间点前后产生大量的请求。

从几天的请求响应监控来看，基本是上课时间前 20 分钟左右达到请求峰值，然后出现大量失败的请求，失败率在 50%甚至更高，（业务服务 C 对每一个返回给客户端的请求都有响应码和错误码的监控），上课之后请求量减少，成功率增加，大概是 75%-80%的成功率。等到一天的课程结束，特别是凌晨的时候，请求量特别少，这个时候成功率几乎大于 90%。

正方教务系统它是部署在学校机房的，往外没有 CDN （因为不提供公网访问，仅在校园网访问）
登录正方的账号都是用户自己的，登录 Atrust 的账号是我找学生借的（只有一个）

@for1shot #23 这个情况是 10.17 那一天突然开始出现的，倘若真是这个原因的话，我倾向于认为是 负责管理 Atrust 的管理人员，在那一天发现了 Atrust 有这个功能，然后给打开了

@for1shot #23 第二种确实有可能，也正好能解释为什么返回 html ，我想想办法按这个思路验证一下

@tomatocici2333 #21 如果是深信服拦截并处理的，返回的就不是 html 了，因为深信服不知道正方的 html 有什么东西。因此，如果是深信服检测并拦截了，那也只能是将检测结果给业务系统也就是正方，让正方来报错返回正方的 html

@for1shot 这种封堵一般会和业务系统绑定吗？
我在浏览器上测试的时候，看到的报错信息并不是直接返回的文本，而是整个 html ，html 渲染完成之后会在登录对话框中显示错误信息
如果是深信服的封堵，应该直接中断连接或者直接返回 text/plain 的数据（就是网页上几个大字），不会返回 html 数据，除非深信服识别之后将情况告知了业务系统 A 也就是正方，然后正方针对深信服告知的结果做了专门的错误信息处理。

写出来这些感觉可能性不强……
正方确实是很多高校使用的教务系统，校园网对外访问也是使用深信服的产品（ easyconnect 、atrust 等），不过也说不好，也许上面有要求正方和深信服一起解决掉所有高校的爬虫问题？

@BenCoper https://i.imgur.com/agAJ0Rd.png https://i.imgur.com/agAJ0Rd.png 是不是就是你写的 https://i.imgur.com/rjR4rdr.png

@tomatocici2333 有账号，今晚我测试一下 A 的风控，看看是不是 A 的限制

@defunct9 #11 这算是一个可能的原因。如果是这样的话，我这爬虫的寿命相当于是终结了

不过业务系统 A 是个外包，应该不会专门做这种吧

明说了吧，业务系统 A 就是 正方教务系统 https://i.imgur.com/NIvxivj.png

@proxytoworld #8 这需要改一下代码，让来自用户的请求先临时停下来，然后再把 cookie 从 B 里面抓出来拿到 Windows 云服务器去访问测试

改动比较大，后面如果还是没有进展也只能试试了

不过说起来，我观察了浏览器上访问业务系统 A 时的请求，它的 Cookie 有刷新的情况，正常先加载 Html ，此时服务端 set 一个 cookie ，然后浏览器开始加载 js 、img 等资源，在这些加载过程中依旧会随机的 set 一个新的 cookie ，从观察情况来看，没有什么规律，也不确定为什么业务系统 A 要 set 一个新的 cookie

@zjsxwc 接触不到 A ，要爬它就是因为改不了动不了它呀 https://i.imgur.com/NIvxivj.png

@kkk9 参数应该是一样的，代理服务器 B 和业务服务 C 都是代码来发的请求，没有道理不一样
Windows 云服务器上的 Edge 浏览器在多次测试过程中使用的都是同一个账号和密码，也没有换浏览器，请求成功和失败的时候参数也应该是一样的

这个东西给我的感觉就像是：我用 Edge 刚刚获取到的 Cookie ，还没开始走到登录接口呢，就突然被什么东西给拿去用了（例如刷新验证码，或者登录其他账号了），等 Edge 走到登录接口了，Cookie 就有问题了

@proxytoworld 对，这也是我十分奇怪的点，按理说不管是不是深信服，VPN 都不应该会“篡改”请求的，但是除了 Atrust 之外，就没有地方可以怀疑了，除非是业务系统 A 改东西了。
因为我在服务器上单独测试过浏览器访问业务系统 A 了，问题依旧出现，说明问题应该不是出现在代理服务器 B 、业务服务器 C 甚至更加往下的服务器

这东西对我的冲击有点像“计算网络不存在了” https://i.imgur.com/NIvxivj.png

因为情况很复杂，所以写了很多的字配上图来说明情况，希望大佬们可以耐心看完 https://i.imgur.com/YGIx7lh.png

帖子不要沉了呀，求大家帮帮我

分子+1

dama ？

底半

@beneo 我这里的数据转换很简单，就是接收请求，然后调用新版本的服务，获取到返回数据之后再按照老版本的格式返回，请求量大是因为微信小程序端不升级了，一直在请求老接口