事情的起因
2024.10.19,OpenAI ChatGPT 突然将 CR 的 Token 长度变长,并且长的超出我的想象。由于业务需求,镜像站的 Response 回显为 400 Bad Request。
查看了一下日志,发现中间出现了几条 Arkose 的请求日志,我心想,丸辣,怎么 Arkose 回来了。
由于 2024.10.18 也就是昨天,基本上手上的号全部被封了,目前没有可以直接登录的 ChatGPT 账号,看不到官网具体的请求。(按原计划是今天再升级一批普通账号的,手上现成的都是 outlook 账号,登录很麻烦,需要绑定手机)
于是,我开始了氪金(,此时的用户基本上开始发现了问题。
在官网查看请求
氪金大概花了10几分钟,终于登录到了 ChatGPT 里面,然后我一瞅,“诶我去,没有Arkose啊”。心想,这下傻了😧。然后,我尝试看看 CR 是不是出现了什么问题,结果一看不知道,才发现 CR 长的离谱,逆天的一批。我在本地运行代理程序,发现稳定的 80% 请求成功,20% 请求失败。此时将问题定位到 CR 算法的更改。
大概花了 10几分钟,我发现 CR 的算法似乎没有任何改变,突然感觉不对劲,这好像除了 Token 变长,没有任何因素影响?同时,由于镜像站过滤了 Response 真实的 Error 原因,我在本地才发现,真正的原因是因为 Request Header Too Large。但是这个时候我还是将问题放在 ChatGPT 身上。
切备用服务
得益于服务习惯,我一般有三套不同的核心代理组件,一套是上古时期的,比较繁琐的组件;一套是集群里面正在用的;还有一套是开发服的。PS:上古时期的组件在集群外,是ip:port 形式的。另外扯一下,这个组件就是比较繁琐,但是核心功能走的是集群不同服务,还算能用。当然切到上古组件的时候,突然整个网站好了。但是输出比较卡顿,因为没有做 Buff 优化,但是好歹能用就行。(这个地方我没发现,这个服务能用的原因是因为走了 ip:port,没有经过 Nginx Ingress)
调查问题
回到问题,我在想,是不是压缩选项不一样?因为我知道问题是请求头的问题,我怀疑是不是和那几个 gzip 有关系。于是我将请求强制降级为 HTTP/1.1,突然好了?(原本的请求都是走 HTTP/2)这下给我整不会了,但是能用就行,于是紧急 PUSH Commit,k8s 部署。
好的,恭喜,又炸了
我直接人傻了,我在想,不会吧,为什么本地没问题,线上有问题呢?结果没想到多久,我突然发现,我开发服的代理程序好了,但是正式环境的代理程序没好。我对比了一下代码,我发现我把一个比较长的 Token 用 hashToken 来代替了,原意是准备解决 Token 长怕传输需要时间,结果没想到误打误撞地解决了这个问题。后面就终于定位到了问题,开始一波 Ingress 的 header 大小修改
解决方法
添加下面的注解:
nginx.ingress.kubernetes.io/proxy-buffer-size: 128k
nginx.ingress.kubernetes.io/proxy-buffering: 'on'
nginx.ingress.kubernetes.io/server-snippet: |
large_client_header_buffers 16 128K;
client_header_buffer_size 128k;