拓冰网站定制 
Lucky 反向代理实战指南1 个端口搞定多域名转发与多后端负载均衡【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/luckyLucky 是一款面向软路由和家用主机的网关工具其反向代理模块能把多个内网 Web 服务挂到同一个监听端口上按域名分发请求并支持子规则层面的多后端轮询负载均衡。读完本文你可以不碰 Nginx用图形界面配出一条能直接上线的转发规则。先从一个真实场景说起家里有一台 NAS、一台跑着面板的 Docker 主机还有一台开发机。想让外网用域名直接访问它们传统做法是逐台配 Nginx每个域名一张 vhost证书、认证、日志各管各的端口还可能打架。Lucky 的思路是把这几件事收进一个 Web 界面建一条反向代理规则指定监听端口再往下面挂若干个子规则做域名到后端的映射认证、黑白名单、访问日志都挂在子规则上。规则保存后立即生效不用重启任何服务。核心机制速览5 个要点看懂转发链路把反向代理想象成酒店前台客人只认前台这一个入口报上房号域名前台就把人领到对应的房间后端服务客人全程不用知道房间的具体位置。规则主规则定义监听 IP、端口和是否启用 TLS一个端口对应一条规则。子规则挂在规则下按前端域名精确匹配域名只按 Host 头里的域名部分判断不含端口。默认后端没有子规则命中的请求都落到这里起兜底作用建议留一个明确的后端而不是空着。多后端轮询子规则的 Locations 里填多个后端地址时请求按顺序轮流分发这就是它的负载均衡实现。转发前过滤链IP 黑白名单 → UserAgent 名单 → Basic 认证 → 自定义 robots.txt全部通过才真正转发。快速上手一条最小可用规则新建规则后你只需要改 4 处监听端口、默认后端地址、子规则的前端域名、子规则的后端地址。对应到配置文件里就是下面这份 JSONconfig/下的规则列表字段以仓库实际结构为准{ RuleName: home-gateway, ListenIP: , ListenPort: 8080, Enable: true, EnableTLS: false, DefaultProxy: { Locations: [http://10.0.0.2:8080] }, ProxyList: [ { Enable: true, Domains: [files.your-domain.com], Locations: [http://10.0.0.3:8080] } ] }保存后规则立即重启监听。访问http://你的公网地址:8080Host 为files.your-domain.com的请求会落到10.0.0.3:8080其余全部落到默认后端。子规则的转发日志会记录域名 → 后端地址的对应关系第一次验证时看一眼就能确认路由对了。功能深挖域名精确路由与默认后端兜底每个请求进来Lucky 先取 Host 头里的域名在规则内的域名表里查子规则命中且子规则开启 → 用该子规则的后端与过滤配置命中但子规则关闭 → 回落到默认后端未命中 → 同样走默认后端。也就是说默认后端是任何陌生域名的落点。如果你把默认后端的 Locations 留空未匹配的域名会被直接掐断并打一条没有对应后端地址的日志适合做严格的白名单式入口。多后端轮询负载均衡这样开子规则的 Locations 填 1 个地址就是普通转发填 2 个以上Lucky 会按顺序轮流把请求分给每个后端。看 反向代理模块源码 里的GetLocation()实现每次分发取当前序号对应的地址并自增带锁保证并发安全是标准的轮询round robin。适合同规格节点扩容、单台性能吃紧时的横向分摊。注意它没有加权、最少连接或 IP 哈希选项节点之间建议保持同等规格否则慢节点会成为瓶颈。三层访问控制按顺序生效转发之前有一道固定的检查链任何一层不过请求就中止并写入该子规则的日志级别为 Warn顺序检查项配置字段说明1IP 黑白名单SafeIPMode名单可全局管理支持单 IP 与 CIDR 网段2UserAgent 名单SafeUserAgentMode、UserAgentfilter按包含某字符串匹配适合拦掉默认扫描器3Basic 认证EnableBasicAuth等用户名 密码未通过返回 401IP 名单支持白名单与黑名单两种模式白名单模式下只有列表内地址能访问适合把面板类服务锁在自家固定出口 IP 或 DDNS 客户端 IP 上。让后端看到真实客户端 IP反向代理转发时后端应用看到的连接来源通常是 Lucky 所在主机真实访客 IP 会丢失。Lucky 提供两个相关能力字段作用ForwardedByClientIP、RemoteIPHeaders开启后从指定请求头如X-Forwarded-For解析真实客户端 IPTrustedCIDRsStrList可信代理网段。仅当连接方在该网段内才信任转发头且从右向左解析跳过可信代理的 IP取第一个非可信 IP 作为真实客户端如果 Lucky 前面还挂了一层运营商或 CDN 代理记得把这层代理的网段填进可信代理列表否则解析结果会是代理地址。避坑指南现象 → 原因 → 解法现象启用了 HTTPS浏览器却仍按 HTTP 处理。原因规则开启了EnableTLS但证书列表里没有覆盖该域名的有效证书Lucky 会记录可用证书列表为空,未能启用TLS并静默降级为 HTTP 监听。解法先在 SSL 模块导入证书可用 ACME 自动签发并确认证书域名覆盖访问域名再开 TLS 开关。现象子规则配了域名请求却总走默认后端。原因域名是精确匹配且不带端口Host 与配置值差一个www前缀都会失配。解法以日志里的 Host 原值为准修正域名多个别名就各建一条子规则。现象同一域名在两条规则里都配了其中一条监听起不来。原因规则初始化时会检查域名冲突重复域名的规则直接报错退出监听。解法一个前端域名只归属一条规则跨规则复用请改用不同域名或路径规划。现象改了规则日志区却是空的。原因访问日志保存在内存环形缓冲里条目数受AccessLogMaxNum限制重启即清零。解法把EnableAccessLog打开并给足上限需要长期留存就配计划任务定期导出日志。现象请求返回 502日志出现后端地址转换出错。原因Locations 里的地址缺少协议头或端口无法解析成合法 URL。解法统一写成http://IP:端口或https://IP:端口的完整形式。进阶把真实 IP 传给后端并控制日志量后端应用需要按真实访客做统计或限流时开启追加客户端 IP 到指定 Header即可把解析出的真实 IP 写进自定义请求头再转发日志侧建议给AccessLogMaxNum一个上限如 1000 条因为日志缓冲常驻内存条目越多占用越大{ AddRemoteIPToHeader: true, AddRemoteIPHeaderKey: X-Real-Client-IP, EnableAccessLog: true, AccessLogMaxNum: 1000 }检查清单上线前逐项过一遍关键项推荐配置漏配后果监听地址端口与路由器映射一致且不与其它规则重复规则起不来或新规则顶掉旧监听前端域名精确值、不带端口同规则内唯一流量全部掉进默认后端默认后端 Locations至少 1 个完整地址或刻意留空做拦截陌生域名请求无处理结果多后端负载均衡各地址规格接近地址均为完整 URL轮询被慢节点拖住启用 TLS 前证书已导入且覆盖访问域名静默降级为 HTTPBasic 认证 / IP 名单面板类服务建议开 Basic 认证 IP 白名单服务裸奔在公网访问日志EnableAccessLog开上限 500~1000出问题无迹可查下一步建议先按最小规则跑通转发在子规则日志里确认域名指向了正确后端再依次叠加 Basic 认证、IP 名单和 HTTPS每加一层验证一次最后用计划任务定期导出配置方便回滚。【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/lucky创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Lucky 反向代理实战指南：1 个端口搞定多域名转发与多后端负载均衡
Lucky 反向代理实战指南1 个端口搞定多域名转发与多后端负载均衡【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/luckyLucky 是一款面向软路由和家用主机的网关工具其反向代理模块能把多个内网 Web 服务挂到同一个监听端口上按域名分发请求并支持子规则层面的多后端轮询负载均衡。读完本文你可以不碰 Nginx用图形界面配出一条能直接上线的转发规则。先从一个真实场景说起家里有一台 NAS、一台跑着面板的 Docker 主机还有一台开发机。想让外网用域名直接访问它们传统做法是逐台配 Nginx每个域名一张 vhost证书、认证、日志各管各的端口还可能打架。Lucky 的思路是把这几件事收进一个 Web 界面建一条反向代理规则指定监听端口再往下面挂若干个子规则做域名到后端的映射认证、黑白名单、访问日志都挂在子规则上。规则保存后立即生效不用重启任何服务。核心机制速览5 个要点看懂转发链路把反向代理想象成酒店前台客人只认前台这一个入口报上房号域名前台就把人领到对应的房间后端服务客人全程不用知道房间的具体位置。规则主规则定义监听 IP、端口和是否启用 TLS一个端口对应一条规则。子规则挂在规则下按前端域名精确匹配域名只按 Host 头里的域名部分判断不含端口。默认后端没有子规则命中的请求都落到这里起兜底作用建议留一个明确的后端而不是空着。多后端轮询子规则的 Locations 里填多个后端地址时请求按顺序轮流分发这就是它的负载均衡实现。转发前过滤链IP 黑白名单 → UserAgent 名单 → Basic 认证 → 自定义 robots.txt全部通过才真正转发。快速上手一条最小可用规则新建规则后你只需要改 4 处监听端口、默认后端地址、子规则的前端域名、子规则的后端地址。对应到配置文件里就是下面这份 JSONconfig/下的规则列表字段以仓库实际结构为准{ RuleName: home-gateway, ListenIP: , ListenPort: 8080, Enable: true, EnableTLS: false, DefaultProxy: { Locations: [http://10.0.0.2:8080] }, ProxyList: [ { Enable: true, Domains: [files.your-domain.com], Locations: [http://10.0.0.3:8080] } ] }保存后规则立即重启监听。访问http://你的公网地址:8080Host 为files.your-domain.com的请求会落到10.0.0.3:8080其余全部落到默认后端。子规则的转发日志会记录域名 → 后端地址的对应关系第一次验证时看一眼就能确认路由对了。功能深挖域名精确路由与默认后端兜底每个请求进来Lucky 先取 Host 头里的域名在规则内的域名表里查子规则命中且子规则开启 → 用该子规则的后端与过滤配置命中但子规则关闭 → 回落到默认后端未命中 → 同样走默认后端。也就是说默认后端是任何陌生域名的落点。如果你把默认后端的 Locations 留空未匹配的域名会被直接掐断并打一条没有对应后端地址的日志适合做严格的白名单式入口。多后端轮询负载均衡这样开子规则的 Locations 填 1 个地址就是普通转发填 2 个以上Lucky 会按顺序轮流把请求分给每个后端。看 反向代理模块源码 里的GetLocation()实现每次分发取当前序号对应的地址并自增带锁保证并发安全是标准的轮询round robin。适合同规格节点扩容、单台性能吃紧时的横向分摊。注意它没有加权、最少连接或 IP 哈希选项节点之间建议保持同等规格否则慢节点会成为瓶颈。三层访问控制按顺序生效转发之前有一道固定的检查链任何一层不过请求就中止并写入该子规则的日志级别为 Warn顺序检查项配置字段说明1IP 黑白名单SafeIPMode名单可全局管理支持单 IP 与 CIDR 网段2UserAgent 名单SafeUserAgentMode、UserAgentfilter按包含某字符串匹配适合拦掉默认扫描器3Basic 认证EnableBasicAuth等用户名 密码未通过返回 401IP 名单支持白名单与黑名单两种模式白名单模式下只有列表内地址能访问适合把面板类服务锁在自家固定出口 IP 或 DDNS 客户端 IP 上。让后端看到真实客户端 IP反向代理转发时后端应用看到的连接来源通常是 Lucky 所在主机真实访客 IP 会丢失。Lucky 提供两个相关能力字段作用ForwardedByClientIP、RemoteIPHeaders开启后从指定请求头如X-Forwarded-For解析真实客户端 IPTrustedCIDRsStrList可信代理网段。仅当连接方在该网段内才信任转发头且从右向左解析跳过可信代理的 IP取第一个非可信 IP 作为真实客户端如果 Lucky 前面还挂了一层运营商或 CDN 代理记得把这层代理的网段填进可信代理列表否则解析结果会是代理地址。避坑指南现象 → 原因 → 解法现象启用了 HTTPS浏览器却仍按 HTTP 处理。原因规则开启了EnableTLS但证书列表里没有覆盖该域名的有效证书Lucky 会记录可用证书列表为空,未能启用TLS并静默降级为 HTTP 监听。解法先在 SSL 模块导入证书可用 ACME 自动签发并确认证书域名覆盖访问域名再开 TLS 开关。现象子规则配了域名请求却总走默认后端。原因域名是精确匹配且不带端口Host 与配置值差一个www前缀都会失配。解法以日志里的 Host 原值为准修正域名多个别名就各建一条子规则。现象同一域名在两条规则里都配了其中一条监听起不来。原因规则初始化时会检查域名冲突重复域名的规则直接报错退出监听。解法一个前端域名只归属一条规则跨规则复用请改用不同域名或路径规划。现象改了规则日志区却是空的。原因访问日志保存在内存环形缓冲里条目数受AccessLogMaxNum限制重启即清零。解法把EnableAccessLog打开并给足上限需要长期留存就配计划任务定期导出日志。现象请求返回 502日志出现后端地址转换出错。原因Locations 里的地址缺少协议头或端口无法解析成合法 URL。解法统一写成http://IP:端口或https://IP:端口的完整形式。进阶把真实 IP 传给后端并控制日志量后端应用需要按真实访客做统计或限流时开启追加客户端 IP 到指定 Header即可把解析出的真实 IP 写进自定义请求头再转发日志侧建议给AccessLogMaxNum一个上限如 1000 条因为日志缓冲常驻内存条目越多占用越大{ AddRemoteIPToHeader: true, AddRemoteIPHeaderKey: X-Real-Client-IP, EnableAccessLog: true, AccessLogMaxNum: 1000 }检查清单上线前逐项过一遍关键项推荐配置漏配后果监听地址端口与路由器映射一致且不与其它规则重复规则起不来或新规则顶掉旧监听前端域名精确值、不带端口同规则内唯一流量全部掉进默认后端默认后端 Locations至少 1 个完整地址或刻意留空做拦截陌生域名请求无处理结果多后端负载均衡各地址规格接近地址均为完整 URL轮询被慢节点拖住启用 TLS 前证书已导入且覆盖访问域名静默降级为 HTTPBasic 认证 / IP 名单面板类服务建议开 Basic 认证 IP 白名单服务裸奔在公网访问日志EnableAccessLog开上限 500~1000出问题无迹可查下一步建议先按最小规则跑通转发在子规则日志里确认域名指向了正确后端再依次叠加 Basic 认证、IP 名单和 HTTPS每加一层验证一次最后用计划任务定期导出配置方便回滚。【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/lucky创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考