在开发完 Mole-go 之后，我想为它搭建一个展示和下载的网站。作为一个后端开发者，前端样式调试，尤其是在手机端的反复测试，成为了一个痛点。此外，每次向他人演示时，都需要提供一串 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 的核心功能，提供了图形化界面，并通过系统托盘常驻的设计，彻底解决了“关闭命令行窗口即断开连接”的常见问题。
通过 Mole-go，我可以轻松地将本地的 5000 端口，通过加密隧道稳定地映射到云服务器的指定端口。它的资源管理能力和连接稳定性，确保了即使在网络波动的情况下，演示链路也能保持可靠，这背后离不开对稳定 网络协议 连接的依赖。
第三步：优雅的网关入口（Caddy）
即便服务已经暴露到公网，我也不希望访问者通过 http://IP:端口 这种不友好的方式访问。我追求的是使用“域名+HTTPS”的专业访问体验，这不仅关乎美观，也为某些必须运行在 HTTPS 环境下的开发场景（如微信公众号开发）提前做好了准备。
我选择 Caddy 来担任这个“守门人”角色。Caddy 最大的亮点在于其开箱即用的 自动 HTTPS 功能，配置极其简单。针对我的场景，在 Caddyfile 中仅需配置如下内容：
example.com {
reverse_proxy localhost:7000 # 指向 FRP 服务端本地接收流量的端口
}
仅仅这一行配置，Caddy 便会自动完成 SSL 证书的申请与续期。当访问者输入域名时，浏览器地址栏会显示受信任的安全锁标志，所有复杂的端口映射逻辑都被优雅地隐藏在后端，这种自动化体验正是现代 运维 实践所推崇的。
第四步：最终的演示时刻
当所有配置生效后，我在手机 5G 网络下输入预设的域名——页面瞬间加载完成！
手机屏幕上清晰地展示出由 Dufs 托管的网站内容。得益于 Caddy 的高效反向代理和 Mole-go 维持的稳定隧道，整个访问过程丝滑流畅。现在，我不再需要反复将代码打包、上传到远程服务器；只需在本地进行修改，远端的同事或朋友刷新页面就能立即看到最新效果。
这套方案不仅节省了大量部署时间，更让整个演示过程充满了“专业感”。当网站内容经过充分打磨并获得认可后，我才会将其正式部署到生产环境，并使用 Nginx 替代 Caddy 进行代理。
总结
Dufs + Mole-go + FRP + Caddy 的组合，将本地开发的灵活性与公网访问的便捷性结合得恰到好处。对于需要频繁进行跨设备调试、远程演示或内网服务临时对外开放的开发者而言，这不仅是一套技术方案，更是一种提升工作效率的有效实践。
目前，我的 Mole-go 工具网站已经通过这套链路稳定运行。如果你对这类开发效率工具或搭建过程感兴趣，欢迎到 云栈社区 与其他开发者交流探讨。
网站演示地址：https://lab.91demo.top (使用 Tailwind CSS 开发，简洁实用，持续迭代中。)
发表于 昨天 11:19
|
查看: 8|
回复: 0
