在VPS上的服务被封了,是整个IP都被墙了。
问了一下前同事,如果自己写协议有多难?他建议基于PCI的标准来写(彻底防中间人攻击)
就是用TLS1.3了。
于是让AI给建议,AI说,你就别折腾框架的事情了,Client直接用现成的,把基于TLS1.3的私有协议封装在sing_box中。
于是让AI开工,另外通知VPS厂商帮我换IP
可能是轻车熟路,AI很快就弄好了,加上大量的压力测试。
然后我一键部署……
跑起来比商用的效果还差不了多少。
看看PCI标准是不是真的可以对抗哈。
上面的工作用了kimi Moderato 1/3的月额度,大概就是30块钱左右。今天(周二)想起要在Android上也跑个客户端。
还是让Kimi继续吧,但挺不顺利,毕竟是跨设备调试。途中出去了一趟,用UU远程指挥kimi修改,然后远程下配置到本地(我没让他再改二进制,因为用的是sing box+私有协议,不存在特别的bug),再验证,如是过了几个红绿灯都还没好。
算了,还是等回家好好给它看log吧。
于是kimi终于找到了问题:
这次是源码级的实锤根因,完整证据链如下:
根因:我们的配置没开 route.auto_detect_interface。sing-box 的拨号器只有在这个开关为 true 时才会给每个出站连接挂上 VPNService.protect()(回环保护)。没挂保护 → 核心自己发往服务器的连接被路由进自己的 tun → 死循环。日志里的铁证:拨号失败的源地址是 172.18.0.1(tun 自己的地址)、所有连接 15 秒后报 mux: tunnel not connected。Wi-Fi 和蜂窝症状一样,因为都卡在这一步——之前看到的”运营商 RST”只是隧道还没建好时的次要现象。
为什么官方 SFA 没这问题:订阅/图形界面生成的配置会带上这个开关,而我们是手写 JSON,漏了。源码里 Android 被算作 Linux(constant/os.go:23),所以这个”仅桌面”的选项在 Android 上合法且必需。
于是改配置项就好了。
又用了大概1/3月额度。
个人感觉,近三十年的技术经验,不过就是清晰地表达问题,收集log,以及恰当提出一些建议——不让它质疑一个开源已久的项目。
Kimi moderato 月费99,1/3就是一杯咖啡的价格,相当的划算了。我是相信Kimi蒸馏A\很到位,所以它技术能力挺强的。
