K8S 调整请求头大小限制：一次debug灾难的随手记录

事情的起因

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;

吐槽

还是喜欢我的 Caddy，省事（