没有问题，我的 k3s 基于 tailscale 跨区域组网，上面跑着服务运行了好几年了，活动机都满 3 年换过一批了

和 ide 整合呗，比如 jb ai 就和 ib ide 整合之后，只要开了 ai 订阅，在提交的时候有一个按钮可以根据提交的变更代码生成 commit message ，提示词也可以改

@yufeng0681 #121 兼职的水平吧，如果可以找到正经工作肯定去正经工作，我老婆做这个只是看重它时间自由，想做就做，不想做就不做

@leeleelee #62
@blackbookbj277
@yanwu
我看我老婆做的过程，感觉就是给 AI 训练做标注，他们有人做标注，有人来审核，就是那些刷题的教材，带答案的，然后让标注的人把题、答案、解析对应起来


这个东西应该是有招聘老师的，我不知道我老婆在哪里找的，平台就是猿辅导

@yanwu https://xyzb.yuanfudao.com/word/issue_aboutus

@leeleelee #62
@blackbookbj277
https://xyzb.yuanfudao.com/word/issue_aboutus

@Mystery0 如果做饭做的好也可以做点点心零食什么的在小区卖

做数据标注，我老婆这学期开始在家里做，虽然没多少钱，但是能 cover 买菜的钱

@Rinndy #55 手持 Pixel 6 Pro 刚刚试了试，可以

@ofnh 看来又是被搜索引擎收录了导致的😂😂😂

@jqknono #14 昨天我看到这个回复了，我也想知道是怎么拉的，我自己搭了两个 derp ，因为 client 验证有问题就关掉验证使用的，域名和 ip 的映射关系在 headscale 配置里面，公网没有解析，我也想知道会不会把我的给“拉”出来

@defunct9 #34 打算按收编来谈了

唉，已经离不开了，结果来一波这个事情，现在想换都找不到平替了 https://i.imgur.com/NIvxivj.png

@defunct9 #11 @tomatocici2333 #14 昨天下午我针对 A 做了多次账号登录的测试，使用 docker-atrust 提供 vpn 环境，然后在 Mac 上使用不同浏览器登录不同的账号，没有发现 A 系统有踢出的相关逻辑，应该和 A 关系不大


@for1shot #23 我今天（ 26 号）下午做了很久的测试，用了 Reqable 抓包仔细对比了浏览器发送的请求头信息和程序设置的请求头，浏览器发送的头没有发现非常明显的针对风控的标识，但是程序的请求头有些过于死板了（从打开页面到最终请求登录接口，都十分的“标准”，时间戳参数要么都有，要么都没有，部分在浏览器端通过 js 发起的请求 [带有 X-Requested-With 头] 没有带上相对应的头），虽然这些“特征”不一定被 A 系统识别并检测了，我还是依次对比之后补上了一些请求头参数，现在从 Reqable 抓包来看，请求更“像”浏览器发起的了。

最后说一下关于 Atrust 部分，从我下午的测试情况来看，感觉出现问题的地方是和 Atrust 有关系，但是不知道是如何实现的：刚开始的时候我在通过浏览器和程序依次发送不同账号的登录请求，以此来对比两种请求方式的不同点并针对性的进行修改（具体差异见上一段）。持续了比较长的一段时间之后，就出现了一个明显异常的情况：这个时候在浏览器上我直接访问页面能够显示登录页面，但是输入任何账号（我本地测试用的是 3 个不同的账号）进行登录均无法登录，并且 [ [不再显示错误原因] ] ！！！我保证测试账号的密码没有输错，验证码也没有输错，并且我试了很多次，都是这样的现象。
跟踪了一下这一种新的现象，具体表现为：
1.通过浏览器加载登录页面 GET /login.html （仅作说明，具体路径不是这个），无论是直接访问域名（未登录情况下会 302 到登录页面）还是直接访问登录页面
2.浏览器打开页面会正常显示，同时自动获取公钥（ GET /public.html ），自动加载验证码（ GET /kcaptcha ）
3.在浏览器上输入账号、密码、验证码之后，页面正常发起登录请求（ POST /login.html ）
4.POST 请求返回 302 重定向状态码，但是 Location=/ （以前登录失败时返回的是 200 状态码，并且响应体内容位 html ，html 中带有错误原因）
5.因为 302 到了/，然后又走了一次第一步的流程，页面再自动 302 到/login.html ，因为是 302 过去的，所以是正常 GET /login.html ，也就没有错误信息了

今晚在家里的 windows 机器上，装了个 windows11 的虚拟机，登录上 Atrust 之后将代理服务器 B 部署进去，然后本地启动业务服务 C ，跑了三个账号的登录，没有发现什么问题（没有问题可能是特征暂时未识别出来，也可能是请求量太少没有达到并发的量），至少没有出现下午那种“不显示原因的直接失败”的情况了。

说说最终的结论吧，现在呢大概是能确定应该和 Atrust 有点关系，可能是 Atrust 检测到访问 A 系统的请求经过了代理（ docker-atrust 里面用的 tinyproxy ，可能带了某些特征 [例如请求头] ），也可能是请求参数过于“标准”触发了 Atrust 的什么网络策略，然后 Atrust 对应该正常发送给 A 的数据包做了一些修改（不知道具体的修改内容）导致 A 接收数据不完整从而登录失败。
斗智斗勇了几天呢，今晚最后再上一次代码修改看看有没有什么改善，如果还是不行的话，就只能想办法绕过 Atrust 直接请求 A 了（想办法在大内网环境里面弄一台机器通过 tailscale 组网来直接提供接口代理），或者和 A 谈一下，被官方收编了算了……

@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