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 阶段，但它宣传的特性完美契合我的所有需求： ...

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. 软件主界面 ...

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

随着“小程序激励演示版”的完成，我不仅验证了 Wails 3 的可靠性，也理清了内网穿透在实际应用中的边界。 今天，我决定开启 Mole 客户端的新阶段：开发一个完全去商业化的“公版”frp 管理工具。 这一次，不再有广告，不再有限制，只有极致的配置体验和对 frp 协议的深度支持。 一、 减法：去掉枷锁，回归纯粹 在之前的演示版中，为了跑通“看广告换带宽”的逻辑，我给工具加了很多业务代码。在新的公版计划中，我做的第一件事就是**“大扫除”**： 移除激励系统：彻底删掉小程序码弹窗、后端握手逻辑和广告状态监听。 轻量化内核： UI 界面将变得更加清爽，让用户专注于配置本身。 零服务依赖：不再强制连接我的私有服务器，用户可以自由添加任何公网 frps 节点。 二、 加法：全协议支持与配置进化 frp 的强大之处在于其灵活的协议转发。之前的版本为了简化演示只支持 HTTP，但在公版中，我将补齐这些核心拼图： 1. 从 HTTP 到 TCP/UDP 开发者不仅需要穿透网页，更多时候需要穿透 SSH (22)、数据库 (3306) 甚至 游戏服务器 (UDP)。 新特性：配置页面将新增协议切换选项，动态支持 TCP 和 UDP 端口映射。 交互优化：针对不同协议，UI 会自动切换配置项（如 HTTP 需要填写域名，而 TCP 只需填端口）。 2. HTTPS 的优雅实现 虽然 frpc 本身可以处理 SSL，但主流做法依然是在服务器端使用 Nginx/Caddy 进行反向代理。 方案升级：Mole 将内置一套“最佳实践文档”。在用户配置 HTTPS 映射时，客户端会引导用户如何在服务端配置 Nginx，并给出生成的示例配置代码。 3. 配置文件的“可视化”与“透明化” 公版将允许用户直接查看生成的 frpc.toml。 你可以在 UI 界面通过表单操作，也可以一键切换到代码模式手动微调。这种“双模运行”能同时满足新手和老鸟的需求。 三、 稳定性：我自己的“日用级”保障 在开发演示版的这段时间里，Mole 实际上已经成为了我工作流程的一部分。 ...

一、 项目设计核心思想 本项目的核心定位是内网穿透的一键化管理。参考 ngrok 的服务模式，通过自建 frp 服务器 提供稳定中转，将复杂的配置封装在 Wails 客户端中。 商业闭环：通过微信小程序激励视频获取连接权限（2小时有效期）。 用户体验：一键连接、自动分配二级域名、配置持久化。 二、 前端架构：原生 JS 的三维交互 为了保持轻量，前端放弃了重量级框架，采用原生 JS 与 Wails 运行时通信。 控制面板 (Dashboard)：状态驱动 UI。涉及扫码弹窗逻辑、广告验证状态机。 配置页面 (Settings)：表单处理。重点在于 Local Port 的保存与通过 Wails Bind 将数据下发给 Go 后端。 运行日志 (Logs)：虚拟黑屏终端。难点在于实时流式展示后端 frpc 吐出的日志。 三、 后端核心技术要点 将按照应用生命周期逻辑，对以下模块进行深度归纳： a. 应用原生窗口定义 结构化管理：AppManager 模式 // AppManager 统一管理应用和窗口 type AppManager struct { App *application.App MainWindow application.Window } var manager = &AppManager{} 采用了 AppManager 结构体来统一持有 App 实例和 MainWindow 实例。 知识点：在 Wails 3 中，不再像 v2 那样通过上下文（ctx）传递，而是鼓励通过对象持有的方式管理窗口引用。这方便了后续在任何 Service 中通过 manager.MainWindow 直接操控窗口（如置顶、隐藏、发送事件）。 ...

最近开发完 Mole-go，想给它做个网站用来展示和下载。但我这个后端糙汉子，样式真搞不定，求助 AI 调了半天还是差点意思。最头疼的是，手机端调试得一遍遍输 IP，给朋友演示也得发一串 IP 端口，太不专业了！于是我一顿折腾，搞出了这套方案…… 为了解决这些痛点，我摸索出了一套“黄金组合”：Dufs + Mole-go + FRP + Caddy。这套方案打通了从本地到公网域名的全链路，实现了自动 HTTPS、域名访问以及极致的访问体验。 第一步：构建本地内容基石（Dufs） 一切的起点是本地文件服务。我选择使用 Dufs 作为静态服务器。它极其轻量，支持上传、搜索、打包下载甚至 WebDAV，是我演示 Web 应用或分发安装包的首选。 通过简单的命令，我在本地 5000 端口启动了服务。虽然此时它还被“困”在局域网内，但它为后续的展示提供了稳固的基础。 第二步：突破局域网束缚（FRP 与 Mole-go） 为了让公网流量能精准触达内网，我采用了经典的 FRP 方案，但在客户端层面，我使用了自己开发的 Mole-go。 服务端 (FRP Server)：部署在具备公网 IP 的云服务器上，充当流量中转站。这个服务器配置可以很低，网站服务都在本地电脑，如果本地有数据库，也非常方便调试。 客户端 (Mole-go)：这是我为 FRP 打造的桌面管理客户端。它封装了 frpc 核心，不仅提供了直观的 UI，还通过系统托盘设计彻底解决了“关闭窗口即断连”的痛点。 使用 Mole-go，我可以将本地 5000 端口通过加密隧道安全地映射到云端。它出色的资源管理和连接稳定性，确保了演示过程中即便网络波动，链接依然稳固如初。 第三步：优雅的网关入口（Caddy） 即便流量已到达公网，我也不希望朋友们通过 http://IP:端口 这种生硬的方式访问。我追求的是“域名+HTTPS”的专业感，这不仅是为了美观，更是为了开发环境需求，下次开发公众号等必须 HTTPS 环境时可以拿来就直接使用。 我选择了 Caddy 担任“守门人”。Caddy 的魅力在于其近乎零配置的 自动 HTTPS 功能。看中了它的简单方便，非常符合我的场景。在 Caddyfile 中，我只需写下： example.com { reverse_proxy localhost:7000 # 指向 FRP 映射出的本地端口 } 仅需这一行配置，Caddy 就会自动搞定 SSL 证书的申请与续签。当访问者输入域名时，映入眼帘的是受信任的绿色小锁头，所有的复杂端口逻辑都被完美隐藏。 ...