Frp 管理幕后功臣:frps 服务端的多用户鉴权与泛域名自动化

演示版中还有一个极其重要的环节没有交代:服务端(frps)的架构设计。 如果说 Mole 客户端是用户看到的“门脸”,那么服务端就是支撑多用户安全、有序运行的“大脑”。即便在未来的纯工具版中不再强制使用我的服务器,但这套多用户鉴权与动态域名的方案,依然值得每一位开发者备忘。 一、 fp-multiuser:实现多用户隔离的关键 在服务型工具中,不可能让所有用户共享一个 Token,否则无法追踪流量,也无法实现精准的权限控制。我选择了 frp 官方推荐的插件方案:fp-multiuser。 1. 核心逻辑:基于 OpLogin 事件的鉴权 fp-multiuser 实际上是一个基于 HTTP 协议的外部插件。它的精妙之处在于:当 frpc 尝试连接 frps 时,插件会拦截相关事件。 在我的实现中,我重点使用了 OpLogin 事件: 分配 Token:当用户通过 Mole 客户端(或小程序激励后)请求连接时,后端 API 会动态生成一个唯一的 Token 并下发给客户端。 校验映射:当 frpc 发起登录,fp-multiuser 插件会接收到这个 Token。插件通过查表或调用我的管理接口,确认该 Token 是否合法、对应哪个子域名。 唯一映射:这样就确保了 A 用户只能使用 A 子域名,彻底解决了多用户环境下域名冲突和越权访问的问题。 二、 泛域名证书:让每个子域名都拥有 HTTPS 演示版支持用户通过 HTTPS 访问本地服务。面对随时可能生成的成百上千个二级域名(如 user1.example.com, user2.example.com),手动配置证书显然是不现实的。 1. 泛域名证书(Wildcard Certificate) 我使用了 Let’s Encrypt 的泛域名证书。 申请方式:通过 DNS-01 验证方式(利用 Certbot 或 acme.sh)申请 *.example.com 的证书。 优势:一个 .pem 文件即可覆盖所有二级域名,无需为每个新用户重新申请。 2. Nginx 反向代理配置 在服务端,我并没有让 frps 直接监听 443 端口,而是将其置于 Nginx 之后。 ...

2025-12-06 · 1 min · Eagle

商业模式探索与反思:从“广告换带宽”到“技术留下印记”

开发 Mole 客户端的初衷之一,是希望探索一条个人开发者工具变现的路径。在技术实现之外,商业模式的探索同样占据了我大量精力。 一、 “广告换带宽”:一个看似完美的闭环 我最初的想法是利用自己的 3M 带宽服务器,结合微信小程序的广告生态,实现一个“共享经济”的模式: 用户痛点: 临时需要公网 IP 、域名和稳定带宽进行本地调试。 我的资源: 闲置的服务器和域名资源。 解决方案: 用户在 Mole 客户端点击“连接”时,触发小程序激励广告。看完广告后,后端 API 自动为用户分配一个临时的、随机的子域名,并下发 frp 配置 Token。 这种 “桌面工具 + 小程序广告” 的模式,避开了复杂的桌面端支付系统,利用了微信成熟的广告体系。 二、 巨大的合规风险:理想照进现实的冷水 当我准备将这个服务正式上线时,我意识到一个致命的风险:内容合规性。 frp 是一个中立的工具,但它提供的“内网穿透”能力具有双面性。如果用户利用我的服务器进行不法活动(如诈骗、传播违规内容),作为服务器的所有者,域名备案的所有者,我将承担直接的法律责任。服务器和域名随时可能被封,甚至可能面临法律风险。 对于个人开发者而言,这种风险是不可承受的。 第一次变通:服务降级 为了规避风险,我做出了一个艰难的决定:放弃动态配置。 我将客户端锁定为只能穿透由我指定的、本地启动的特定服务(例如一个我开发的本地 Web 服务器)。这样我能控制内容源,降低风险。 但这导致了项目核心吸引力的丧失。用户使用 frp 是为了灵活性,锁定端口后,这个工具对懂技术的开发者来说毫无吸引力。项目陷入僵局。 三、 模式转型:从“服务型”到“纯工具型”的转变 既然提供“带宽服务”行不通,我决定回归“纯工具”本质。但我依然希望能产生收益。赞赏功能(Donation)是一个选项,但在竞争激烈的 frp GUI 市场,我的优势不大。 第二次变通:价值输出与技术写作 我找到了一个新的平衡点:将开发过程本身作为内容输出。 我决定将项目坚持写完,并将整个开发过程、技术难点、踩坑经验整理成系列文章,发布到我的个人网站上。 为什么选择网站(Web)而不是小程序? 内容呈现: Markdown 在 Web 上的渲染效果和代码块展示能力远超小程序。 流量与受众: frp 是一个全球流行的项目。网站面向全球用户(不仅限于微信生态),潜在受众更广。 变现方式: 通过网站流量联盟(如 Google AdSense)可以实现广告收益,风险远低于“流量中转服务”。 四、 结语:留下我的印记 Mole 项目的商业化之路虽然坎坷,但其衍生的价值却超出了我的预期。我不仅熟练掌握了 Wails 3、Go 进程管理、跨端通信等技术栈,还找到了一个可持续发展的方向。 ...

2025-12-05 · 1 min · Eagle

技术深挖(二):Wails 3 跨端通信——前端如何优雅地“等待”扫码成功?

在完成了 Go 后端的硬核逻辑后,压力来到了前端。Mole 的前端并没有复杂的全家桶,而是回归本质,将精力集中在与 Wails 3 的运行时(Runtime)交互上。 本文将重点拆解:前端如何调用后端服务,以及如何处理“激励视频”这种跨端异步逻辑。 一、 桥梁:引入运行时与绑定 在 Wails 3 中,前端不再需要通过 HTTP 接口访问后端,而是通过自动生成的 Bindings。在 main.js 中,这几行代码是整个应用的灵魂: import { Events, Browser } from "@wailsio/runtime"; // 由 Wails 3 自动生成的绑定代码 import { HandleStopFrp, HandleStartFrp, GetDomainURL, } from "../bindings/mole/MoleService"; Events: 核心组件,用于监听后端的主动推送到前端的消息(如日志、状态变更)。 HandleStartFrp 等: 它们看起来是 JS 函数,但执行时会直接触发 Go 后端对应 Service 的方法。 二、 核心实战:扫码激励的异步闭环 Mole 的核心业务是“看广告换带宽”。这就带来一个挑战:用户点击“连接”后,由于没看广告,流程会中断并弹出小程序码。前端如何知道用户什么时候看完了广告? 拦截与判断 我们不能在前端写 if(adWatched),因为前端代码是透明的。逻辑必须在 Go 后端:如果后端判断该用户需要看广告,HandleStartFrp 会返回特定的状态码(如 2)。 状态机:从“连接中”到“等待验证” 看看这段核心的 connect 逻辑: async function connect() { const hint = document.getElementById("hint"); try { const res = await HandleStartFrp(); // 发起 Go 调用 if (res.code === 1) { // 情况 A: 验证通过,直接分配域名并连接 document.getElementById("subdomain-url").innerText = res.content; setUIConnected(true); addLog("成功连接到服务器", "system"); } else if (res.code === 2) { // 情况 B: 触发激励逻辑,弹出小程序码 showAdModal(res.content); // res.content 包含小程序码 Base64 或 URL addLog("请扫码完成验证后继续", "info"); // 【关键】注册一次性监听事件,等待后端“发令枪” const unsubscribe = Events.On("ad-status", (data) => { closeAdModal(); // 关闭弹窗 unsubscribe(); // 销毁监听,防止重复触发 if (data.status === "done") { addLog("验证成功,正在连接...", "system"); connect(); // 再次发起连接请求,此时后端将通过验证 } else { // 处理异常(如超时、未看完) hint.innerText = data.message; hint.classList.add("error-shake"); addLog(`验证未完成: ${data.message}`, "error"); setUIConnected(false); } }); } } catch (err) { setUIConnected(false); } } 三、 为什么这样设计?(经验总结) 安全性(Security First): 连接逻辑的“入场券”完全由 Go 后端控制。前端只是一个 UI 展示层,即便用户强行修改 JS 调用 connect(),如果后端没有收到广告系统的回调信号,依然不会分配 frp 配置。 订阅-发布模式(Events): 使用 Events.On 而不是轮询(Polling)。当用户在手机上看完广告,后端 API 收到微信的回调后,会通过 app.Emit(“ad-status”, …) 通知前端。这种实时性让用户体验非常丝滑——手机看完,电脑屏幕上的弹窗瞬间自动消失并连接。 UI 细节:单页面布局(Zero-Config UI): 由于 Mole 的界面追求极致精简,所有的 CSS 样式、HTML 布局和 JS 逻辑都高度集成在 index.html 和 main.js 中。对于这类工具软件,减少资源加载链比追求组件化更重要。 四、 结语 前端在 Wails 3 项目中扮演的是 “状态反馈器” 的角色。通过 Bindings 调用 Go 方法,通过 Events 监听实时动态。 ...

2025-12-04 · 2 min · Eagle

技术深挖(一):Wails 3 驱动 frp 客户端的核心实现与避坑指南

在上一篇文章中,我介绍了 Mole 客户端的业务闭环。今天,我们切入代码层面,聊聊基于 Wails 3 的 Go 后端是如何驱动 frp 核心并保证体验平滑的。 一、 Wails 3 项目启动架构 Wails 3 的启动逻辑高度模块化。在 main.go 中,一切从 application.New 开始。 1. 资产集成与服务绑定 首先,我们需要通过 embed.FS 将前端生成物(Vite 构建后的 dist 目录)打包进二进制文件: //go:embed all:frontend/dist var assets embed.FS func main() { app := application.New(application.Options{ Name: "Mole", Description: "Fast Reverse Proxy Manager", Services: []application.Service{ application.NewService(&FrpService{}), // 绑定核心服务 }, Assets: application.AssetOptions{ Handler: application.AssetFileServerFS(assets), }, }) // 创建窗口逻辑... } 关键点: Services 是 Wails 3 的精髓。它是一个切片,支持绑定多个服务实例。每个服务中定义的公开方法,前端都可以通过自动生成的 JS 绑定直接调用。 二、 核心经验总结:从“能跑”到“好用” 在开发 Mole 的原型过程中,我踩了不少坑,总结出以下 5 个核心经验: ...

2025-12-03 · 2 min · Eagle

Frp 管理客户端:基于 Wails 3 的 frp 智能管理实战

Mole 是一款基于 Wails 3 开发的跨平台 frp 管理客户端。它不仅解决了 frp 配置繁琐的痛点,更探索出了一种“桌面工具 + 小程序生态”的全新闭环模式。 🌟 核心业务流程 Mole 的核心逻辑在于其自动化配置流与激励机制的融合: 1. 智能激励连接 (One-Click Connect) 当用户点击“一键连接”时,客户端会启动一套自动验证逻辑: 广告触发:系统检查用户当前状态。若未满足条件,则弹出动态窗口显示专属小程序码。 多端协同:用户扫码后进入微信小程序观看激励视频。 自动握手:用户观看完毕后,小程序通过后端指令反馈给 Mole 客户端。 静默取消:客户端接收指令后自动关闭弹窗,进入连接阶段。 2. 云端配置自动下发 Mole 不再需要用户手动编辑复杂的 TOML 文件: 动态获取:从服务器端安全获取分配的随机子域名和 frp 配置 Token。 本地注入:Go 后端自动将配置写入内置的 frpc.toml。 二进制调用:自动调用内嵌的 frpc 核心组件启动服务。 3. 全链路事件反馈 利用 Wails 3 的高效事件机制,实现深度的 UI 反馈: 实时日志:Go 后端捕获 frpc 的标准输出,通过事件流(Events)实时推送到前端页面,用户可以清晰看到连接建立过程。 状态监控:实时反馈隧道运行状态,确保连接稳定性。 🛠️ 板块功能详情 连接控制台:一键启停,集成小程序激励流程。 端口配置页:灵活配置本地服务端口(如 8080, 3000 等),满足开发者调试需求。 实时日志页:直观展示 frp 运行日志,方便故障排查。 帮助中心:详尽的操作指南,降低内网穿透的使用门槛。 技术结缘 (About & Support): 集成优质云服务器推广(为用户提供可靠的 frp 服务端选择)。 扫码直达开发笔记,分享 Wails 3 与 Go 的底层实战。 👀 软件界面概览 1. 软件主界面 ...

2025-12-02 · 1 min · Eagle

系列开篇:告别命令行的束缚,我为何选择 Wails v3 打造 frp 管理客户端?

一、困境与契机:低配服务器、高性能需求与共享经济的思考 我的云服务器配置很“复古”:1 核 CPU、1G 内存、1M 带宽。它完美地满足了我个人博客的需求,直到我需要演示一套视频会议系统。该系统最低要求 2 核 4G。 我的服务器是包年做活动时购买,升级配置成本高昂,而我的本地电脑性能过剩,为了一次演示,我升级我的云服务器,我感觉不值。为了解决这个问题,frp(Fast Reverse Proxy) 成为了我的救星,它允许我将本地高性能服务安全地映射到公网。 新的痛点出现:命令行的局限性 在成功通过命令行 frpc 实现了内网穿透演示后,我发现了一系列生产力问题: 进程管理难题: 命令行窗口一旦关闭,frpc 进程随之终止,服务中断。这在日常使用中非常不便,因为会经常手误关闭窗口。 潜在的商业价值: 我有闲置资源服务器,公网 IP 以及域名。对于那些临时需要公网映射的用户来说,这是一个刚需。 流量变现与服务化: 我有一个小程序并集成了广告。如果能让用户通过看广告来获取临时的 frps 使用权(子域名分配),可以减少我的服务器支出,这将是一个双赢的模式。 为了解决这些问题并实现我的想法,我意识到可以做一个稳定、可后台运行、拥有友好 UI 的客户端,来替代原始的命令行操作。 二、技术选型坎坷路:Fyne、Tauri 的尝试与碰壁 我的技术栈主要集中在 Go、Rust 和 JavaScript,其中 Go 最擅长。我希望使用这些技术栈实现一个跨平台的客户端。 第一次尝试:Go & Fyne Fyne 是一款使用 Go 语言编写的跨平台 GUI 库。我首先尝试了它。 优点: 纯 Go 编写,上手快。 痛点: 在处理 frpc 实时打印的日志时,Fyne 对中文字符的支持不理想;复杂的列表和表格布局实现起来很痛苦。最终放弃。 第二次尝试:Rust & Tauri Tauri 是当时(也是现在)非常热门的跨平台框架,结合 Rust 的后端性能和 Web 前端技术。 优点: 性能强劲,打包体积小,前端界面开发体验好。 痛点: 我完成了界面设计,但在核心的 frp 控制模块上遇到了巨大的技术难题。Rust 的所有权(Ownership) 和生命周期管理让我头疼不已,始终无法优雅地实现 frp 进程的启动、停止和状态共享。项目卡壳。 三、柳暗花明:Wails v3 成为“天选之子” 在技术选型陷入僵局时,有读者告诉我可以尝试下 wails 3,我关注了 Wails 项目的 v3 版本。虽然现在它还处于 Alpha 阶段,但它宣传的特性完美契合我的所有需求: ...

2025-12-01 · 1 min · Eagle

Rust 实战进阶:深度复盘上传工具崩溃问题,优化报错提示

最近,更新了上传文章工具 rust 版本,这个版本使用的库为 nwg,即 native-windows-gui 库,该库支持老的 Windows GUI。 昨天,当我准备在另一台电脑上录制视频时,发现运行不起来,GUI 界面闪现一下,就退出了。我先升级了 Rust 版本到最新版本。 rustup update 升级完成后,cargo clean ,再 cargo run 重新运行。 郁闷,还是报错。 将 main.rs 文件中该行注释,#![windows_subsystem = "windows"],可以在命令行中查看报错信息,提示是找不到文件。我想了下,只有图片是文件,然后我将图片的路径修改,发现修改之后,编辑器提示错误,找不到文件。重新改回去后,编辑器提示错误消失。说明不是这里的错误。 我真的晕了。从网上查找问题原因,没有找到此类问题的解决方法,郁闷。在查找时,发现了另一个 Windows 官方支持的 rust 库,就叫 windows,打算有时间了用这个库重写一下。 今天,我又查看了下另一台电脑上的这个项目,发现可以正常运行,将 rust 升级到最新版本后,还是可以运行。在看到配置文件后,我才恍然大悟,原来是查找这个文件。我赶紧扒拉代码确认,发现确实是这个问题。 let conf = Ini::load_from_file("conf.ini").unwrap(); 上面是使用文件的地方,找不到文件 panic。我这里优化一下,让错误提醒的更明显一些。这样我就瞬间能知道问题原因了。 优化后的代码如下: let conf = Ini::load_from_file("conf.ini").expect("please config conf.ini file");

2025-01-01 · 1 min · Eagle

Rust 实战:构建高可靠 APK 上传工具,彻底终结网络超时与手误引发的生产事故

在自学 Rust 的那段日子里,我除了开发开源项目,还为日常工作量身定制了一些不公开的内部工具。其中最令我印象深刻的,是一个看似简单的 APK 文件上传小工具。 虽然它只是一个 Rust + native-windows-gui (NWG) 编写的单一界面应用,但它解决的两个核心生产问题,至今仍对我有着深远的影响。 一、 工具画像:极简与高效 这个工具的界面极其克制: 交互区:一个醒目的文件拖拽控件,文案提示“请把 APK 文件拖拽到这里”。 表单区:版本号、Version Code、更新描述、是否强制升级(开关)。 执行区:一个大大的“上传”按钮。 它的核心逻辑非常纯粹:校验必填项 -> 调用内部上传 API -> 上传文件 -> 返回成功或失败的对话框。 二、 故事一:消失的 60 秒与隐藏的超时限制 工具上线初期,一切运行平稳。由于办公室带宽充足,APK 的上传时间通常维持在 40 秒左右。 事故发生: APK 在集成广告后,经常会发生失败的情况,客户端弹出“超时”的报错。 排查过程: 我首先检查了后端服务,发现后端接口完全没有超时限制,服务器日志显示连接是被客户端主动断开的。 多次重复上传文件使用有线和无线对比,经排查是文件变大,由于公司无线网络波动,上传速度时好时坏,就会偶尔出现失败的情况。对比排查,发现失败的情况上传时间都超过了 60 秒。 回到 Rust 代码中,我发现当时为了追求简洁,直接使用了 HTTP 客户端的默认配置。而这个默认配置的 Timeout 为 60 秒。 解决方案: 在那个瞬间我意识到,工具不能只考虑“理想状态”。我手动将本地超时时间放宽至 5 分钟,并增加了状态提示。上传时不会再出现超时的情况了。 教训:永远不要依赖默认的超时设置,尤其是在处理文件上传这类长耗时操作时,本地的容错范围必须根据业务场景精细化配置。 三、 故事二:包名校验——把人为失误挡在门外 这是这个工具最有价值的一次功能进化。 事故发生: 有一次,同事不小心将应用 A 的打包产物当作应用 B 上传到了官网,导致用户下载后发现软件张冠李戴。这属于严重的生产事故。 排查过程: 这个客户端软件调用内部API后,会自动将上传的文件名修改为固定的软件下载文件名,显示在网站上。经测试,如果将应用A的打包产物使用应用B上传,在官网就会出现相同的情况。解决这个方法也非常简单,就是上传的时候小心细致一点,应用A使用A客户端软件,应用B使用B客户端软件。但是人总会犯错,尤其是在面对多个长相相似的 .apk 文件时。通过肉眼观察文件名来区分应用,是极其不可靠的。 ...

2020-01-02 · 1 min · Eagle