各位好，想分享一个我最近开源的代理池项目：Resin。
它是一个高性能粘性代理池。最开始做它，其实是因为在日常开发里，反复被几个老问题折腾得很烦：比如接海外大模型 API、或者给团队搭一个相对稳定、统一的出口网络环境。
很多时候，我们手里会有不少节点订阅，但质量差异挺大。市面上一些代理池工具，调度方式还是比较基础，无非就是轮询或者随机。这样在实际使用里会带来一个很麻烦的问题：出口 IP 经常变。
这个问题在现在很多云服务上都挺敏感的。尤其是 LLM API、鉴权比较严格的平台，IP 一直跳，很容易触发异常登录告警，甚至直接把请求拦下来。
另外一个我一直不太能接受的点是：有些工具在后台刷新订阅时，会直接把底层核心重置掉，结果就是当前连接瞬间断开。对有状态连接、大文件传输，或者长时间跑着的请求来说，这种体验其实很差。
Resin 基本就是围绕这些问题重新设计的。
这个项目主要解决什么问题？
1）会话保持，尽量避免出口 IP 漂移
这是 Resin 里我投入精力最多的一块。
一般代理池采用随机节点分配。出口 IP 经常改变。Resin 这里做的是：你可以按业务账号或者某些特征，把请求尽量稳定地绑定到一个固定出口 IP 上。假设底层节点突然不可用了，系统会很快从节点池里找到相同出口 IP的备用节点接上去。
这样对上层业务来说，出口 IP 不会因为底层切换而频繁变化。像调用一些 IP 要求比较严格的 API 时，会稳定很多。
2）更实用的调度，而不是简单随机
Resin 使用了 P2C 做调度，同时结合 TD-EWMA 去计算延迟权重。
不过相比算法名字本身，我觉得更关键的是另一点：它会结合真实业务流量做被动健康检查。
比如通过 TLS 握手这类底层指标，直接判断节点当前质量，而不是单独起一堆额外探测任务去测试节点的健康。这样能少一些额外网络开销，也更贴近真实使用情况。再配合主动探测，节点的可用性判断会更稳一点。
3）节点池规模大，而且支持热重载
Resin 底层基于 sing-box，但是没有直接套现成路由层，而是自己实现了一套Outbound Manager。
基于这套结构，它比较适合管理大规模节点池，单机支撑到 1 万到 10 万+ 节点问题不大。
另一个比较重要的点是热重载。后台刷新、去重、合并订阅时，不会把正在跑的连接全部掀掉。也就是说，你正在请求的接口、下载的流、已经建立的连接，理论上都不应该因为这类更新动作被中断。
4）有 Web 面板，也尽量把可观测性做好了
我一直觉得网关配置如果只能盯着 YAML 改，排障成本还是挺高的，所以 Resin 内置了一个 React / TypeScript 做的 Web 面板。
在面板里可以直接看吞吐、延迟历史、请求日志这些信息。底层日志这块用了双 SQLite 做结构化存储，请求走了哪条路径、上游为什么报错（比如 timeout、connection refused）、路由决策过程是什么，基本都能查到。排网络问题的时候会方便不少。
快速上手
项目部署非常简单，单个二进制文件或者一个 Docker Compose 就能启动。
启动之后，既可以把它当作正向代理在本地开发环境里用，也可以作为反向代理挂在服务端，通过 Header 提取调用凭证。两种模式都已经兼容。
补充一点关于工程实现
这个项目目前大概有 4.5 万行 Go 代码，测试也写得比较多，测试代码量已经超过业务代码了。现在仓库里有 80 多个测试文件。
如果你对底层设计有兴趣，仓库里还有一份比较完整的 DESIGN.md，里面写了状态持久化、并发模型、调度设计这些实现细节。
总之，Resin 是一个很明确从实际痛点里长出来的项目。最初就是因为一直没找到一个在稳定性、会话保持、大规模节点管理、热更新这几个点上都比较顺手的方案，所以干脆自己做了一个。
如果你平时也会碰到类似问题，欢迎试试。
觉得项目还不错的话，也欢迎帮忙点个 Star。
如果你在使用里遇到 Bug、有什么功能建议，或者想直接提 PR 一起完善，也很欢迎交流。 
传送门：
万一将来用得着呢 
大佬太强了！