因为换机场需要给 Clash 加 VLESS 支持,折腾了一下用重写一切的 Rust 重写了 subconverter 。
过程中试了用 AI (Cursor) 辅助 C++ 转 Rust ,感觉不太行,生成的代码错误不少,还是要自己动手改。感觉 AI 对 Rust 这种 native 语言的帮助远不如 JS/Web ,效率差距可能更大了。
看原版 C++ 代码时,发现里面功能巨多,很多我根本没用过,感觉不完全是写来自用的,有点像给机场用的,但又很全能,要完全测试都很复杂。
最大的疑惑是,为啥这套功能要做成 Web API 而不是 CLI ?转换订阅文件这种事,感觉 CLI 更自然。 结果就是,为了兼容这些功能,项目比我一开始只想加个 VLESS 时搞得复杂多了。
目前自用中,核心接口/sub 对齐功能了。
GitHub: https://github.com/lonelam/subconverter-rs
欢迎老哥们试用、吐槽。
1
joh 13 天前 via Android
这套做成 Web API 是为了机场使用方便更新订阅吧。
|
![]() |
2
tokuwaka 13 天前
有 demo 可以看看吗
|
3
tinytoadd 13 天前
感谢 op 的工作。感觉可以把 lib 编成 wasm ,然后写一个静态页面挂着。这样比原版 subconverter 更容易自建一点。
|
![]() |
5
oneisall8955 13 天前
|
![]() |
6
oneisall8955 13 天前
@tinytoadd #3 这样可以挂在 cloudflare 里面,灰常不错的想法
|
7
w568w 12 天前
> 最大的疑惑是,为啥这套功能要做成 Web API 而不是 CLI ?转换订阅文件这种事,感觉 CLI 更自然。
因为大部分代理前端 App ( Mihomo party 、FlClash )都只支持设置一个订阅 URL ,如果要做转换,自然也应该提供一个 URL 。 > 感觉可以把 lib 编成 wasm ,然后写一个静态页面挂着 > 这样可以挂在 cloudflare 里面 @tinytoadd @oneisall8955 原版有后端需要部署,主要是为了解决跨域问题吧。这种需求应该没法纯前端来做的。 至于部署 cloudflare worker/pages 的,这种项目也有了: https://github.com/jwyGithub/sub-convert |
![]() |
8
oneisall8955 12 天前
|
![]() |
9
laizenan OP @w568w @oneisall8955 感谢建议,做成 webapp 是可能的,但 CORS 必须有服务端转发,否则限制太大,拉取第三方订阅有困难,让 gemini 帮我调研了一下,有几个选择:1. cloudflare worker 2. vercel 3. render
其中 1 、2 只能跑 wasm ,3 可以执行原生应用,但应用 0 流量 15min 以后就需要冷启动,可能需要忍受一点延迟。目前看编译到 wasm 比较顺利,但限于原来 cpp 版本的架构,还需要做几个改造:1. tokio 改成单线程模型,2. 文件读取,3. 网络请求转发。 |
![]() |
10
oneisall8955 12 天前
@laizenan #9 灰常期待,毕竟 all in cloudflare ,白嫖赛博菩萨,少了很多机器及运维负担。
曾经搭建 https://github.com/7Sageer/sublink-worker 来转换,但是不太好用 |
11
sanquan 12 天前
sub-store 不行吗?
|
![]() |
12
laizenan OP @sanquan 感谢分享,原项目的部署地址 sub.store 已经废弃了,我写之前没调研到这个项目,subconverter 功能上比 sub-store 多了 ruleset 写入,模板能力,js 脚本执行,更多的控制项,如果我先前看到这个项目的话我可能会考虑从这个项目开始进一步开发。
但既然现在已经 pure rust 了,就一条道走到黑吧,至少从自部署效率来看,rust 代码和 subconverter 一样,可以快速迁移到路由器、wasm 等环境,而且后续要改新的协议和接口时,rust 会比 js 稳定性强一点,sub.store 和 subconverter 的痛点完全一致:需要一个服务器才能长期部署。 |