本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

引言

之前一直在用 Sub2API 和 CPA 等反代理工具，但是由于各种原因，总觉得现成的服务不够完善，多多少少都有一些不太舒服的地方。于是我就根据我个人的使用习惯、需求以及社区上的一些潜在需求，在 Sub2API 的基础上编制了这一款新的反代理平台，LightBridge。

开发进度及贡献

因为个人不是全职开发，是在工作剩余时间开发，进度较慢，基本上1-3天才能完成一个模块，而且面临 Token 不足的境地，也会拖慢工作效率。

如果有佬愿意帮忙贡献，那么万分感谢。

另外声明一下，目前正式上线的为基于 Sub2API 重置的模块化版本，有很多核心功能是直接在 Sub2API 的基础上做的，并不适配 LightBridge 模块化重制版，因此还在分阶段重做、测试上线，需要等待一下。

核心功能介绍

LightBridge Connect

本功能可以在两个 LightBridge 实例之间建立连接。假设说一个是进行分发的服务端，另一个是用户个人拥有的私人端。

在开启本功能后，服务端会生成一个链接和连接密钥。私人端可以将这些信息导入到自己的 LightBridge 当中，随后私人端的 LightBridge 会使用密钥向服务端的 LightBridge 发起一次探测连接。

如果连接校验与握手完成，系统就会建立 LightBridge Connect。在 LightBridge Connect 下，两端机器之间不仅可以使用正常的 API 分发，还可以实现直接从私人端 LightBridge 控制面板查看该用户在服务端 LightBridge 上的账户详情、控制余额、查看使用记录和仪表盘等。

这直接免去了二次跳转的困难，而且还可以共享更详细的错误信息。

注册机（自动维护）& Outlook 号池

我找到了几个开源的注册机源码，准备将其与 Outlook 号池直接作为插件嵌入服务，用户可以直接使用自带注册机一键注册并导入，还可以联动 Outlook 号池查看邮箱使用状况并接受邮件。

但考虑到注册机的前景不明，我个人正在着手开发自动维护机，即做到可以使用协议或无头浏览器自动登录 ChatGPT 账户获取 DC、开启 2FA 等等操作。

智能托管

看到站内许多佬的公益都因为有人违规操作而不得不由管理员进行封禁，便想到了这个功能。

开启后会内置一个 AI 驱动的智能助手，采用了一个接口极为简单的 OpenAI responses 协议的 agent。这个 agent 具备 thinking 和 tool calling 功能。

当系统根据规则检测到异常情况时，会自动唤醒这个 agent，将数据发送给它，并赋予其调用权限。Agent 会根据信息进行推断，最后做出操作。它可以自动封禁违规者，也可以做其他的自动维护（例如自动删除账号之类的）。

也考虑过让 agent 像 OpenClaw 那样全量运行，但由于可能有点消耗 token，不知道后期还会不会开启这个功能。

Clash 代理

不过多赘述了，在原有的 HTTPS/SOCK5 代理的基础上外挂了一个精简版的 Clash Core，实现绝大多数协议的代理，方便佬用自己的订阅。

实时仪表盘和桌面

这个仪表盘是一个实时仪表盘，不同于之前的仪表盘和运行监测，它是用户的一个 API 控制层。

例如，我要是将一个 API 应用在 Codex 里面，由于 Codex 做自定义模型很麻烦，而我现在用的是 GPT 5.5 模型，想换成 DeepSeek V4 模型，我原本需要去本地做很麻烦的配置切换。

但是有了仪表盘，我只需要在仪表盘上把 GPT 5.5 映射成 DeepSeek V4，就可以实现直接切换。这相当于把之前类似于 CCS 中的本地路由搬到了线上，而且更加灵活。而且，你还支持指定某一个渠道来承载你的请求。

Desktop 则是将 Realtime Dashboard 和以上所有控制面板中的功能打包成了一个 CLI 到了本地。

主要是支持让 AI 直接调用、直接管理自己的 Lightbridge 控制台和服务，功能会更加全面。

计划功能：LightBridge 串联

这个功能目前确实还没有完成，还处于计划阶段。

但我个人认为这是一个相当核心的功能，主要就是为了解决服务器负载的问题。其核心架构是由一台主路由和几台服务器集群组成，每一台服务器上都装有 LightBridge 实例。

通过 LightBridge 串联器将其他服务器连接到一起，具体实现如下：

1. 数据库管理：每一台服务器都可以选择进行数据库自动同步或者集中数据库管理。


2. 资源动态分布：将所有的并发处理请求进行资源动态分布，实现多台服务器组成一个高可用集群。


3. 统一控制：用户只需要把所有的请求和压力都打在一个域名上，通过一个控制面板即可同时调度三台设备的算力。

这大大提升了效率，解决了之前单台设备算力不足以及升级设备资金成本太高的问题，让几台低价设备能够同时运行。

开发重点

在结构上，相较于原项目 LightBridge 升级了模块式结构，分为三个实现层：

1. Control 实现层


2. Provider 实现层


3. Core 模块实现层

当用户安装了 LightBridge 之后，默认带有这三个实现层。它们具备了 UI 界面、控制器等基础功能，包含 Provider 核心、Proxy 核心和分发核心，但不具备具体的 反代 和 API 功能。

用户如果需要特定的 Provider，可以在模块市场中下载对应的模块进行安装，从而获取完整功能，实现本地服务的轻量化。像上面提到的 Passkey、LightBridge Connect 之类的模块，大部分功能都是独立于主实现层而实现的，可以根据需要随意安装和自我升级。

在 UI 方面，LightBridge 使用一套公用的 CSS 元素进行了界面重写。

从整体视觉效果上来说，我个人认为是减少了一些 AI 味。当然，可能会觉得棱角太重了，需要的话可以自己上传更改 CSS。

在操作逻辑和 UI 界面方面也有一些小调整，但由于其调整过于细碎，因此不在功能介绍和开发计划中详细赘述。

对于反代核心

相较于以上所说的各种功能来说，我认为是一个比较核心的功能。

像 Sub2API、CPA 之类的项目都多次对这个核心进行修改，以确保不被 OpenAI 之类厂商的风控识别。我个人认为这项工作对我的能力来说有点艰巨，目前正在着手对原有 Sub2API 反代理模块进行优化，以确保减少被风控和被识别的几率。

但这仍然是个艰巨的任务，因此反代理模块在彻底完成并确认效果更好之前，会一直同步更新 Sub2API 的反代理核心。而 Sub2API 所提供的升级，以及与 LightBridge 现有功能不冲突的核心升级，都会被同步进 LightBridge 中。

最后

感谢各位大佬的支持。

目前本服务再次强调一下，关于上述所说的所有核心功能和开发计划——之所以说是计划，不是因为还没有开发，而是因为这些功能之前完全是基于 Lightbridge 服务开发的。

在完成后，我发现了一个很严重的问题：整个服务变得十分臃肿，几乎拖慢了运行进度。于是在重构时，我决定对整个架构进行重置，采用模块化的形式。

每一个核心功能现在都是一个独立的模块，用户可以自由安装，这样只需运行必要的项目即可，大大缩减了运行时的资源消耗。

但也正因如此，以上所说的全部功能必须按照最新的模块 endpoint 结构进行重置，无法直接上线，因此会分批发布。

服务内置了自动升级器和版本控制器：

(a) 如果不喜欢某个版本，可以直接退回到上一个指定的版本。

(b) 在收到新模块后，系统支持自动升级。

目前我正在开发 Sub2API 的回退脚本，方便佬们在不大喜欢时进行回退。

这是最新的迁移脚本。目前迁移脚本支持将 Sub2API 直接迁入到最新模块化的 LightBridge 服务当中。自带自动回退功能，会在迁移之前先建立一个完整备份。若迁移失败，支持自动回滚

curl -fsSL https://raw.githubusercontent.com/WilliamWang1721/LightBridge/main/deploy/sub2api-full-migrate.sh | sudo bash -s -- migrate -v v0.0.1 -y

但是请注意，本迁移仅适用于标准的 Sub2API 服务。如果你的 Sub2API 服务经过魔改，或者自己增加了页面，建议拓展使用，或者可以私信我来进行咨询。

建议直接安装最新服务，体验最佳。

希望各位大佬能够试用一下，多多指教，帮忙 Star 一下，谢谢！

最后声明：正文都是我个人一点一点敲出来的，只有开发计划中 Markdown 语法的 detiles 是我一个一个复制粘贴的，不知道怎么老是别识别成 AI 内容。也有可能是工作老写些正式文书给同化了，完整开发计划后续再发吧 ^-^