Nginx

演示版中还有一个极其重要的环节没有交代：服务端（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 之后。 ...

在移动应用分发、文件共享等场景中，我们常常会遇到这样的困境：云存储平台（如阿里云OSS、腾讯云COS、蓝奏云等）上传的文件地址一旦生成就无法修改，但客户端版本频繁迭代时，每次更新都需要重新生成下载链接和二维码。用户端需要不断更新访问入口，体验极差。我就碰到了此类问题，在上一篇文章，我介绍了自己的客户端，并分享了下载地址。但我发现当我需要重新升级版本时，已经生成的地址将无法变更。在我的文章中，我直接使用了文件下载地址。这就让我急需解决如何实现"一次分发，永久可用"的优雅方案？Nginx反向代理配合301重定向，正是解决这一痛点的利器。 一、问题根源：云存储的地址锁定机制 大多数云存储服务采用"对象存储"模式，文件上传后生成固定URL，该地址包含存储桶名称、地域、文件路径等不可变信息。这种设计虽然保证了数据一致性，却带来了分发难题：每次版本更新，开发者必须重新上传文件、生成新地址、制作新二维码，用户需要重新扫描或获取新链接。对于频繁迭代的应用，这种重复劳动不仅效率低下，更可能因用户未及时更新而影响使用体验。 二、解决方案：Nginx重定向的架构设计 核心思路是地址解耦——将"物理存储地址"与"用户访问入口"分离。通过Nginx服务器作为中间层，用户始终访问固定域名，Nginx根据配置将请求重定向到实际的云存储地址。当文件更新时，只需修改Nginx配置中的目标地址，用户端的访问入口保持不变。 具体架构如下： 用户 → 固定域名/短链接 → Nginx服务器（301重定向） → 云存储实际地址 这种设计实现了三个关键目标： 入口稳定性：用户扫描的二维码或保存的链接永久有效 维护灵活性：后台地址变更只需修改Nginx配置，无需重新分发 成本可控性：Nginx只做重定向，流量消耗极低，普通云服务器即可承载 三、技术实现：从配置到部署 环境准备购买一台云服务器（1核1G配置即可），安装Nginx，将自有域名解析到服务器IP。推荐申请SSL证书启用HTTPS。 Nginx配置示例 server { listen 80; server_name your-domain.com; # 方案一：直接重定向 location /download/app.apk { return 301 https://bucket.oss-cn-region.aliyuncs.com/v2.0/app.apk; } # 方案二：通配符匹配（更灵活） location ~ ^/app/(.*)$ { rewrite ^/app/(.*)$ https://new-bucket.oss-cn-region.aliyuncs.com/$1 permanent; } } 重定向类型选择 301永久重定向：搜索引擎会更新索引，客户端会缓存重定向结果，适合生产环境 302临时重定向：每次请求都会重定向，适合测试阶段频繁变更的场景 二维码生成 将固定地址（如https://your-domain.com/app/v2.0.apk）生成二维码，用户扫描即可下载。后续版本更新时，只需修改Nginx配置中的目标地址，二维码无需重新制作。 四、方案优势与注意事项 核心优势 零用户感知：用户无需关心后台地址变化 维护成本低：修改配置即可，无需重新上传二维码 扩展性强：可支持多版本共存、灰度发布等复杂场景 兼容性好：支持各种客户端（浏览器、APP、微信等） 实施建议 测试先行：在测试环境验证重定向逻辑，确保目标地址正确 监控告警：配置Nginx日志监控，及时发现重定向失败问题 备份机制：保留旧版本配置一段时间，避免新配置问题影响用户 性能优化：虽然重定向开销小，但高并发时需确保服务器性能 五、总结 Nginx重定向方案将复杂的地址管理问题转化为简单的配置变更，实现了"一次分发，永久可用"的理想状态。这种解耦思维不仅适用于文件分发场景，在API网关、微服务路由等场景中同样具有借鉴意义。对于中小型项目而言，这是成本最低、效果最直接的解决方案，值得每一位开发者掌握。 最后推荐一下我的豆子域名管家客户端，这个客户端可以解决域名证书到期忘记更换证书的问题。我是为了解决这个问题而想出来的这个方案。这是我的新的下载地址：https://lab.91demo.top/b011 这样当我修改下载地址时，我不用再变更这个地址，比如我最近刚刚优化了域名扫描逻辑，上传了新的版本，它生成了一个新的下载地址。 当然这个方案还是有一点瑕疵，它需要每次更新都登录服务器修改nginx配置文件，这对于非技术人员非常不方便。后期我还有再次进行优化，我将使用小程序完成新地址的更换。大致思路如下：开发一个轻量的Go服务，提供接口给小程序提交新的地址，然后保存编号和新地址到数据库，例如上面的b011是编号，它对应新的下载URL地址。然后使用Nginx代理这个服务，当用户访问b011时查询它的URL地址，然后返回301和新的地址。这样就不用每次都登录服务器修改Nginx配置，在手机上也方便操作，提供了极大的便利性，也可以交给非技术人员进行维护。