【Server Geek】为什么我会选择 Lucky 而不是 Nginx
我自己在用的自部署服务大概有二十几个，有一些也需要通过公网访问，自然反向代理工具则是必不可少。之前就是用 Lucky 来代理的，但提起反代其实 Nginx 是更权威的，所以有打算趁着这次迁移，想从 Lucky 切换到 Nginx，但是实际折腾一下午之后，还是选择了 Lucky。本文记录一下我更换的动机，以及没有切换到 Nginx 的原因。
我的需求其实很简单，我需要一个服务来做反向代理。
举例说明：我有一个服务监听 12345 端口，现在我已经把服务器 ip 绑定了域名，例如 ehnap.com。如果想访问这个服务，我有几种做法：
- 通过访问 https://ehnap.com:12345 来使用服务，这样我需要放通服务器的 12345 端口，如果我有一百个服务，我就要在服务器上放通一百个端口，而且我自己还要记住这些没什么规律的端口号
- 通过反向代理，访问 https://xx.ehnap.com ，并在反向代理工具上配置 xx.ehnap.com -> 12345 端口的映射，这样我只需要记住 xx ，并且在服务器放通 80 端口。
因此对于我来说反向代理是必不可少的。
其实之前我是一直使用 Lucky 的，但毕竟提起反代，第一时间应该想到的是 Nginx。所以这次将服务迁移到 mini 主机上的服务器，我是打算将 Lucky 替换成 Nginx 的。
原因主要有 3 点：
- Lucky 闭源，如果开源和闭源都满足需求，肯定是优先使用开源
- Lucky 批量填写配置比较麻烦，我二十多个服务要改一些东西，要一个一个手动在 web 上去改
- 想着是如果用 Nginx ，这一套东西研究下来，也比较通用
所以找了一个周六的下午，就开始了我的尝试。
我是客户端出身，所以不是很习惯直接在终端命令行上去编辑 nginx 的 config，或者说至少需要有 UI 让我看些东西，在我需要直接批量更改配置的时候使用 config 文件，平时的时候能在 UI 上看一些配置以及日志，所以我第一时间想到的还是看 nginx 有没有配套的 UI 工具。
于是我找到了 Nginx UI、Nginx Proxy Manager(NPM)。
经过一下午漫长的折腾，最终……，我……，还是用回了 Lucky ……
先说我的场景，我需要 Docker 部署这个反向代理服务，便于管理。这一点上这三个都是满足的，并且 Nginx UI 和 NPM 都在 Docker 镜像内置了 Nginx 不需要自己额外部署 Nginx。
然后就是 Docker 模式的选择，这里有个关键点：我的这个反代服务一定要能访问通其它容器，那对于我来说有两种选择：
- 直接 Host 模式部署
- 桥接模式部署，然后将其它容器都要放到同一个 Docker Network 下边
第二种对我部署其它容器的网络模式有依赖，而且我的其它容器有一些网络还比较复杂，比如 qBittorrent，用了 macvlan (此处伏笔，后边有时间专门搞一篇来说)，所以让我因为一个反代服务去改变其它容器的网络，不现实。所以我就只能选择 Host 模式 部署。
基于这些前提，说说为什么我没有迁移到 Nginx 体系下。
Nginx Proxy Manager
- Host 模式部署不支持修改监听端口，看了项目的 issue，有人 24 年很早就提出了这个问题，而且当时就有人提了代码，但是一直到现在没有进入主线，不是很清楚原因。(家用宽带公网(v4/v6)默认就是封 80 和 443 的，不能修改监听端口，等于直接不能用，估计老外也没想到某些地方网络环境是这样的)
- UI 上看似做了一些交互，但又好像没做，只要添加自定义字段，就要重写整个
location /
Nginx UI
- 我部署成功之后，启动报错 stream 目录找不到，具体的有点忘了，没有使用成功。
- (我在我的另一台云服务器部署成功过)编辑器错位，光标和编辑位置对不上，在上边改 config 跟盲打一样
来来回回搞这俩服务，查解决方案，然后反复安装 nginx ，一折腾就是一下午，后来想想，就算把这套折腾通了，我还得单独去做 ddns，证书管理，所以最终决定还是用回 Lucky。折腾这些方案的时候，还搜到了，lucky 作者在 v 站评论关于 lucky 的帖子。如帖子里所说，选择 Lucky ，唯一的缺点就是，闭源代理服务，一是不确定会不会有信息收集；二是安全漏洞不一定能比开源服务修复更快。
结论
个人、家用、NAS 场景。无脑选择 Lucky。人生苦短，省下来的时间，多折腾点其它服务，它不香吗？
Lucky，能在这个圈子铺开，主要还是切中了细分赛道。其一，在 NAS 圈子，易用性第一，这块没啥对手，配套 Nginx 的开源 UI 没有一个能打的；其二，家用服务器代理场景，Nginx 或者 Caddy 的性能不是最看重的。
所以 Nginx 就不是第一选择。
当然 Nginx 配套的 UI 没什么人做，大抵是企业场景虽然用的多，但一般都使用纯配置管理；或者内部自己写了工具。诚如 Lucky 的作者说：Lucky 这种应用类软件更多只是体力活，毫无技术含量。可能开源圈子也不屑于搞这个。
说句题外话，Nginx UI 看着挺好看的，但可能只有这一个优点了……
最后，如果问我，用个闭源的代理服务，还有证书防火墙那些，不怕有问题吗？我只能说，真有问题，我主机那点东西也不值当人家费劲去搞~~