LeadaxeLxBox / sing-box-lx 开发者

值得推荐作者发言

GitHub·2026.10.23 07:27:48（UTC+8）

Leadaxe：sing-box-lx 不新增 Thrift 接口，暂不实现 Mieru 和 Sudoku

Leadaxe 在 NekoBox 兼容接口请求中表示，不会为 sing-box-lx 核心增加 Thrift 接口：现有控制入口为 lxd 守护进程（同端口提供 gRPC 和管理 REST）与带 lx 扩展的 libbox CommandClient；为保持分支精简，第三层 RPC 及其依赖不在范围内。他建议 NekoBox 在自身侧用一层适配将 LibcoreService 映射到 lxd gRPC；若缺少对应方法，可单独开议题。他同时表示，目前决定不实现 Mieru 和 Sudoku；新协议需有可见需求，并保持较低的上游合并成本，这两种协议目前尚不符合。该议题已关闭。

作者原文@Leadaxe

Thanks for the detailed request, and for the TrustTunnel work on the NekoBox side.

Thrift API. I won't add a Thrift interface to the core. sing-box-lx already has two control surfaces and I keep the fork thin, so a third RPC layer with its own dependency is out of scope:

• the lxd daemon: gRPC plus admin REST on one port, schema in daemon/managed_service.proto and daemon/started_service.proto, docs in docs-lx/lxd-grpc-api.md and docs-lx/lxd-daemon.md;
• libbox CommandClient with the lx extensions for UI clients.

If NekoBox wants to drive this core, a thin shim on its side that maps LibcoreService onto the lxd gRPC API is the way I'd go. If a method you need has no counterpart there, open a separate issue for that method and I'll look at it.

Mieru and Sudoku. I've decided not to implement these two protocols for now. The fork takes a new protocol only when there is demand I can see and the merge cost against upstream stays low, and neither is the case here yet.

Closing. Contribution rules are in CONTRIBUTING.md.