Releases: debbide/ProxyBridge
Releases · debbide/ProxyBridge
Release list
v2.1.6
v2.1.5
v2.1.3
v2.1.2: feat: 原生 VLESS+WS+TLS 支持，直连 Cloudflare CDN 节点
用纯 Node.js 实现 VLESS over WebSocket over TLS 客户端，让面板能直接 使用 CF 中转的 vless:// 节点，无需任何第三方二进制或额外 npm 依赖。 背景：现有 http/socks 上游走 proxy-chain，无法表达 CDN 中转的 VLESS 节点；而 proxy-chain 的 SOCKS 路径显式绕过 HTTP agent 连接池，每次请求 新建连接，边缘 IP 被钉死，高峰期抖动明显。 新增 backend/vless/： - uuid.js / vless-header.js 协议编解码（IPv4/IPv6/域名地址） - websocket.js 手写 RFC 6455 客户端：握手/掩码/分片/控制帧 - link.js vless:// 解析与能力校验 - cf-edges.js CF 边缘池、延迟探测、失败冷却 - dialer.js TLS+WS+VLESS 隧道、跨边缘重试、保活 - http-proxy.js 自建 HTTP 代理监听，CONNECT 与明文 HTTP 都走隧道 面板集成： - parseProxyUri 放行 vless，start()/testProxy() 对 vless 分流到自建监听器 - parseProxyInput 识别 vless://，节点名默认取链接的 #fragment - 前端提示文案补充 VLESS 关键设计： - 明文 HTTP 必须经隧道转发。proxy-chain 只对 CONNECT 建隧道，明文请求 会直连出去造成真实 IP 泄漏；对 vless:// 上游更是直接返回 500。 - 明文 HTTP 走 http.Agent 连接池复用隧道（实测 6 次请求只拨号 1 次， 复用后延迟降至 1/4），这是 SOCKS 路径缺失的能力。 - WebSocket 保活：CF 会掐断空闲连接（实测空闲 150s 失效，每 30s ping 则保持可用）。 - 不支持的能力在解析阶段明确报错，不静默降级：Reality、XTLS Vision、 gRPC、XHTTP、mKCP、UDP，以及多路复用（服务端未开启）。 已知限制： - fp=chrome 无法实现：Node tls 不暴露 ClientHello 字节，无法伪装 TLS 指纹，链接会记录 fingerprintApplied=false。 - 服务端若开启 multiplex 仍可工作，但不复用连接。 测试：新增 15 项集成测试（无需网络），项目测试 67/67 通过。另有可选的 真实链路探针脚本（check/stress/keepalive-probe/reuse-probe/leak-proof/ proxy-e2e/panel-e2e/api-e2e）。
v2.1.1: fix: reject an upstream that points at a managed local port
A node whose upstream resolves to one of our own managed ports forwards into itself. A self-reference, a two-node A<->B cycle and a three-node cycle all spin at roughly 1700 connections per second, pinning the CPU until the request times out, and the port stays saturated for a while afterwards. start() only validated the URI format, so nothing stopped this. Restore the check that was dropped in b4688d7, this time reporting it as a 400 with a readable reason instead of a generic error, so the panel can show why the node refused to start. Only local addresses (localhost, 127.0.0.0/8, ::1) that land on a managed port are refused. Remote upstreams and unrelated local ports such as a separate proxy on 1080 are unaffected. Because the check lives in start(), restore() applies it on boot too, so an already-broken row cannot restart the loop.