Lucky反向代理的工作原理

在实际部署中，Lucky 的反向代理并不是单纯的端口映射，它把外部 HTTPS 请求先交给内部的代理引擎，再根据预设的子规则把流量透明地转发到对应的内网服务，这一层“桥接”让用户只需记住二级域名和统一端口即可访问多种内部应用。

请求的内部路径

当浏览器发起 https://emby.example.com:8888 时，Lucky 首先在监听端口 8888 上接受 TLS 握手，随后解密得到原始的 HTTP 报文。此时，代理引擎会匹配 Host 头部的 emby.example.com，查找对应的子规则——通常是“前端地址 = emby.example.com，后端地址 = http://192.168.1.100:8096”。匹配成功后，请求被重新封装并直接发送至内网的 192.168.1.100:8096，返回的响应再经同一路径回到客户端，整个过程对用户透明。

关键技术点

• 基于 SNI（Server Name Indication）实现同一 IP 多域名的区分。
• 采用 ACME 自动申请的 Let’s Encrypt 证书，30 天内自动续签，保证 HTTPS 持久可用。
• 内部转发使用 HTTP/1.1 Keep-Alive，降低握手次数，提升吞吐。
• 端口映射只需在路由器上开放 Lucky 监听端口，省去每个服务单独映射的繁杂。

如果把整个链路抽象成数学模型，它相当于在 4 层网络协议之间插入了一个“可编程的 NAT”。在 NAT 表中，外部 1:1 的域名映射对应内部 1:n 的服务集合，这种映射关系可以在 Lucky 的 UI 中即时增删，几乎不需要重启服务。

实际使用时，常见的误区是把反向代理当成普通的端口转发。端口转发只负责把外部流量搬运到内部端口，而不做任何协议层面的解析或重写；Lucky 则在流量到达内网前就已经完成了域名解析、TLS 解密、Header 重写等操作，等于是把“访问入口”和“服务实现”彻底解耦。