读了 https://linux.do/t/topic/2207396 的帖子
研究了一下各种codex类似与cpa 的工具是如何管理refresh_token，基本上都用如图的请求包刷新access_token。
刷新access_token的同时，大概率会有新的refresh_token生成，同时老的refresh_token也不会立即失效。和论坛里的佬探讨了一下得出结论 老的refresh_token会过一段时间后（大概15min？）失效，拿老的refresh_token再去刷新就会报错：
所以大家使用相同的codex账号配置文件在不同的工具上使用，由于发包刷新token的时间不同获得的refresh_token也不同（较老的会失效），可能会造成掉号的情况！！！猜测在不同的工具上使用同一套配置文件会造成拥有最新的refresh_token依然正常，即一个工具正常一个掉号的情况，不知道推测的对不对？
同时要是及时发现了被人拖配置文件，一直跑refresh token，拿到比黑客新的refresh token可以抢一批账号回来
是这样的，我的free号cpa json转sub2api json后 cpa中就401了 sub2api就可以用了
使用rt获取到了新的rt后旧的rt没失效，又可以用旧的那个rt获取到新rt
更正一下，不是十五分钟。
昨天测试十五分钟那次是出了问题的，具体时间应该是一小时。接下来贴出完整实验
| 0s | 0 秒 | 成功 | 无 | 旧 RT 可立即再次使用 |
| 30s | 30 秒 | 成功 | 无 | 返回新 AT/RT |
| 120s | 2 分钟 | 成功 | 无 | 返回新 AT/RT |
| 825s | 13 分 45 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 862s | 14 分 22 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 881s | 14 分 41 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 895s | 14 分 55 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 897s | 14 分 57 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 898s | 14 分 58 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 899s | 14 分 59 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 900s | 15 分钟 | 成功 | 无 | 干净实验中成功 |
| 901s | 15 分 1 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 910s | 15 分 10 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 960s | 16 分钟 | 成功 | 无 | 旧 RT 仍可用 |
| 1200s | 20 分钟 | 成功 | 无 | 旧 RT 仍可用 |
| 1800s | 30 分钟 | 成功 | 无 | 旧 RT 仍可用 |
| 2700s | 45 分钟 | 成功 | 无 | 旧 RT 仍可用 |
| 3150s | 52 分 30 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 3375s | 56 分 15 秒 | 成功 | 无 | 旧 RT 仍可用 |
| 3600s | 60 分钟 | 失败 | refresh_token_reused | 旧 RT 被判定为复用 |
这也解释通通了为什么偷我号的人下载我认证文件的频率是1h一次了
这下我就清楚我买的free号，回来之后我明明都刷新过RT，结果还是丢了。
