之前服务器上部署的 dns 解锁失效了，尝试在hk机器上分流 gpt 流量，通过sg的doh dns进行解析。链路大体如下：
IOS(ChatGPT APP)->Router(Dnsmasq dns分流海外流量)->HK Server(Dnsmasq dns分流GPT流量)->HK Server(dnscryt-proxy)->SG DOH DNS不过事实上是 OPENAI 更改了地区检测策略，通过访问服务的 ip 进行地区判断，提高了绕过地区检测的门槛，dns 解锁不再可行，所以本次实践从解锁这个目标来看是失败的。
但 DNS解锁 依然是其他 APP 的主流解锁方案，依然有记录的意义。
最近aliyun 200M的香港轻量云要到期了，考虑到其限速比较频繁，打算整体迁移到 tencentcloud 的竞品上，后者目前为止没碰见过限速问题。
考虑到可预见的未来里，可能还会经历几次迁移，所以记录下迁移步骤。
目前来看整体可分为 4 部分：
certbot部署
最近重装软路由的系统，把openwrt从21升到了最新的23.05。很多脚本需要更新，例如iptables升级到了nftables。
同时最近阿里云和腾讯云不约而同的推出了200M不限流量的轻量云服务器，所以Server部分也需要重装。
重装过程发现很多细节都忘了，果然好记性不如烂笔头。还是搞文档体系的记录一下。
http://192.168.1.1/servmngr.html，开启telnet并设置登录账号密码(默认admin/admin)。/fhconf/backpresettings.conf，所有更改都基于这个配置文件，备份一下稳妥一些。gendefsettings，这个命令是将光猫当前配置写入到/fhconf/backpresettings.conf，宽带的账号密码都会写入进去。/fhconf/backpresettings.conf里面<WANConnectionDevice instance="2">元素下面的配置
<IdleDisconnectTime>120</IdleDisconnectTime><X_BROADCOM_COM_IfName>下面新增<X_CU_IPMode>3</X_CU_IPMode>，但如果已经有这个元素了就不需要新增了。<ConnectionType>PPPoE_Bridged</ConnectionType>
<Name>2_INTERNET_B_VID_3961</Name>
<X_BROADCOM_COM_IfName>veip0.2</X_BROADCOM_COM_IfName>
loaddefsettings /fhconf/backpresettings.conf，加载刚刚修改的配置，光猫会自动重启。| 配件 | 名称 | 价格 | 备注 |
|---|---|---|---|
| CPU | i7 8700t es | 899 | qn8j, 淘宝 |
| 主板 | Asrock z370m itx/ac | 869 | 京东 |
| 机箱 | Jonsbo c2 | 144 | 京东 |
| 散热 | Thermalright le grand macho rt rev.b | 320 | 咸鱼 |
| 硬盘 | 950pro 256g | 0 | 旧机淘汰件 |
| 内存 | 海盗船 ddr4 2400 8g x 2 | 0 | 旧机淘汰件 |
| DC-ATX | 联达DC-ATX250W | 113 | 淘宝 |
| 电源 | 台达 12v 20a 电源适配器 | 100 | 淘宝 |
| 其他 | ATX电源挡板 | 44.55 | 淘宝 |
长久以来，登录跳板机都要忍受二步验证，工作效率大打折扣。忍无可忍，爆发了。
在网上搜到一篇讲模拟二步验证的博文《两步验证的使用和TOTP在Python中的基本实现》，示例代码简单可用，比github上动辄几百行靠谱的多。此文是模拟二步验证的基础，在此感谢原作者。
公司线上项目一个库的cpu使用率总是偏高，经同事点拨，发现一处索引使用不当。
首先观察下面的表结构。
CREATE TABLE `live_calc_1b` ( `vid` varchar(100) NOT NULL, ... PRIMARY KEY (`vid`) )
再看下面的这个sql。
select * from live_calc_1b where vid = 14635808219671833713;
看似很普通的使用场景却暗藏隐患，发现了没？
今天在公司调试业务接口，发现一个会引发408的场景。记录一下。
起因是charles的一个bug，用edit功能编辑请求，会导致请求原文中丢失post body。
这样造成的后果就是content-length非0，但body为空，nginx对于该请求会一直处于阻塞状态，等待客户端发body，最终超时。