Lucky 反向代理快速上手一条规则把内网服务转发到公网域名【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/lucky家里或机柜里有台闲置主机上面跑着不少 Web 服务你想这样用它们把内网的 FileBrowser、NAS 管理页安全地暴露到公网只让特定 IP 访问一个固定入口端口按域名把请求分发到不同服务比如 a.com 进文件服务、b.com 进后台多台同构机器组成后端组由入口统一分发请求避免单点压力。Lucky 反向代理就是干这个的它在本机起一个 HTTP 监听口根据请求头里的 Host域名把流量转到你指定的内网后端途中顺手做认证、IP 过滤、日志记录让你不用碰 Nginx 配置也能把服务搬出来。五分钟建出第一条转发规则这一节的目标花最少时间让一条规则真正通起来。打开 Lucky 管理页进入「反向代理」新建一条规则核心字段就这四个其余保持默认即可{ RuleName: file-srv, Enable: true, Network: tcp4, ListenPort: 80, DefaultProxy: { Locations: [http://192.168.0.50:8088] } }中文注释ListenPort是对外监听端口DefaultProxy.Locations是默认后端所有没被域名匹配走的请求都落到这里。保存后点右侧「开」开关用域名或直接 IP:8088 对端访问http://你的出口地址能看到 FileBrowser 页面就算通了。界面里「负载均衡」开关打开后目标地址就能填多个这是下一节的伏笔。规则拆解主规则与子规则怎么配这一节讲清请求进来后Lucky 先拿什么去匹配、匹配上又转去哪。一条主规则 一个监听端口 一个「默认规则」 N 条「自定义子规则」。处理顺序是先看请求的 Host 能否在子规则里精确命中某个域名命中就用那条子规则的后端没命中就落到默认规则的后端。域名精确匹配{ Domains: [file.my-home.net], Enable: true, Locations: [http://192.168.0.50:8088] }注释只有 Host 与Domains里某项完全一致才算命中file.my-home.net:80这种带端口的写法不会命中file.my-home.net。路径前缀匹配{ Domains: [api.my-home.net], Locations: [http://192.168.0.51:3200] }注释子规则本身不做路径切割/v2/orders会原样转给后端想只代理某个前缀要靠后端服务自己按路径分流或者再配一条域名规则指向另一台机器。匹配谁、转去哪在规则列表页的日志里能逐条看到比如[file.my-home.net] 指向后端地址[http://192.168.0.50:8088]排查为什么流量走错了就看这一行。四种负载均衡怎么选后端只有一台跳过这节。多台同构服务要一起扛流量时先按下面选策略策略典型场景在 Lucky 里怎么落地轮询各节点性能一致请求轻重差不多子规则填多个后端地址默认行为最少连接请求耗时差异大短请求多长请求少后端加健康探针配合监控手动摘除慢节点IP 哈希同用户要落同一台会话粘滞用不同域名/端口做入口按客户端分组加权轮询节点规格不一大机器多扛些用多条规则按权重拆端口入口再分发多后端示例三个地址轮着接流量{ Domains: [shop.my-home.net], Locations: [ http://192.168.0.61:8080, http://192.168.0.62:8080, http://192.168.0.63:8080 ] }注释Lucky 内建的分发方式是按下标轮询取下一个地址源码里就是取模自增所以表格里轮询是它的原生能力其余三种需要组合技巧实现。一个细节节点挂了时轮询不会自动跳过请求打过去就是 502/超时。建议给后端配存活探测比如 cron 探活后告警比指望代理自动摘除更实际。安全加固三步走端口一旦开出去就要想谁来、怎么来。这一步只做三件事每件都写在子规则上作用范围就是这条子规则。第一步Basic 认证应用层浏览器弹框要账密{ EnableBasicAuth: true, BasicAuthUser: ops, BasicAuthPasswd: s3cret }注释账密对了才放行未认证请求直接回 401只护单条子规则默认规则不受影响。第二步IP 黑白名单网络层在转发前拦Lucky 的全局黑白名单页统一管理条目子规则里选模式即可{ SafeIPMode: whitelist }注释whitelist模式下不在名单里的 IP 一律拒绝记得把办公网段和家里宽带出口 IP 都加进去否则自己先被挡。黑名单模式则是列了才拒适合封已知的扫描 IP。第三步UA 过滤应用层按浏览器指纹拦脚本{ SafeUserAgentMode: blacklist, UserAgentfilter: [masscan, sqlmap] }注释User-Agent 里包含任意一项就拒绝专治各类扫描器改成whitelist则变成只放行带指定特征的客户端慎用很多正常客户端 UA 也会变。请求进来后的实际检查顺序是先 IP、再 UA、最后认证任何一步不过就断开并写一条 Warn 日志。提速技巧缓存参数与连接参数不堆参数只说对体感影响最大的几个。EnableAccessLogLogLevelAccessLogMaxNum日志开关、级别、内存里保留的条数。日志开着几乎无感但AccessLogMaxNum调到几万条以上时内存里的环形缓冲会明显变大常规几十到一两条规则给 1000 条足够。ForwardedByClientIPRemoteIPHeadersTrustedCIDRsStrList当 Lucky 前面还挂着运营商光猫、CDN 或另一层反代时把可信代理网段填进 CIDR 列表再声明从X-Forwarded-For这类头里读真实客户端 IP否则日志和白名单一直看到的都是上一跳代理的 IP规则形同虚设。AddRemoteIPToHeaderAddRemoteIPHeaderKey把识别到的客户端 IP 写进自定义请求头发给后端后端应用日志才能落到真实访客。两个不需要你操心的点Lucky 不做页面级缓存静态资源的Cache-Control交给后端或 CDN 自己设到后端的连接复用由 Go 标准库的传输层自动管理日常没有暴露可调项真到瓶颈时先看后端的单连接处理速度而不是在代理层找旋钮。出问题了先看这里访问日志是每条转发请求一行 JSON关键字段速查字段含义常见异常信号Host客户端带的域名和子规则域名对不上说明被兜到默认规则URL完整请求路径路径被吃掉或多了前缀多半是后端路由问题ClientIP识别到的客户端 IP全显示成同一台内网 IP说明可信代理没配UserAgent客户端指纹大量异常 UA配合黑名单封禁level / msg级别与消息禁止访问、认证不通过、没有对应后端地址三步排查法先看Host和URL——请求有没有进对规则再看msg——是IP禁止访问名单问题、认证不通过账密问题还是没有对应后端地址子规则忘填 Locations都不是直接在后端机器上curl后端地址确认服务本身活着、端口对内网可达。备份与回滚Lucky 的全部规则就存在一个配置 JSON 文件里改动批量规则前把整个文件复制一份改坏直接覆盖回去比逐条排查快一个数量级。建议再给自己定个规矩每次动规则记一行改动说明出问题能定位是哪一步引入的。三个最易踩的坑坑域名加了端口就匹配不上。原因Lucky 对 Host 做精确匹配file.x.com和file.x.com:8080是两回事。规避客户端访问不带端口或者在Domains里把带端口的写法也列进去。坑子规则没配后端流量悄悄走了默认规则。原因Lucky 允许子规则不填Locations此时回落到默认规则现象是改了子规则没用。规避给子规则都填上后端或在默认规则留个兜底地址并打日志。坑前面挂了代理后IP 过滤全部失灵。原因Lucky 默认只认直连 IP不解析X-Forwarded-For白名单里加什么真实 IP 都没用。规避按「提速技巧」配好可信代理网段和请求头再重新过一遍名单。一句话收个尾先用五分钟跑通一条规则再按域名拆子规则最后把认证、名单和日志补上——Lucky 反向代理要的就这三件事。规则字段的更多细节可以翻 反向代理模块源码 对照着看字段名和界面上是一一对应的。【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/lucky创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Lucky 反向代理快速上手：一条规则把内网服务转发到公网域名
Lucky 反向代理快速上手一条规则把内网服务转发到公网域名【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/lucky家里或机柜里有台闲置主机上面跑着不少 Web 服务你想这样用它们把内网的 FileBrowser、NAS 管理页安全地暴露到公网只让特定 IP 访问一个固定入口端口按域名把请求分发到不同服务比如 a.com 进文件服务、b.com 进后台多台同构机器组成后端组由入口统一分发请求避免单点压力。Lucky 反向代理就是干这个的它在本机起一个 HTTP 监听口根据请求头里的 Host域名把流量转到你指定的内网后端途中顺手做认证、IP 过滤、日志记录让你不用碰 Nginx 配置也能把服务搬出来。五分钟建出第一条转发规则这一节的目标花最少时间让一条规则真正通起来。打开 Lucky 管理页进入「反向代理」新建一条规则核心字段就这四个其余保持默认即可{ RuleName: file-srv, Enable: true, Network: tcp4, ListenPort: 80, DefaultProxy: { Locations: [http://192.168.0.50:8088] } }中文注释ListenPort是对外监听端口DefaultProxy.Locations是默认后端所有没被域名匹配走的请求都落到这里。保存后点右侧「开」开关用域名或直接 IP:8088 对端访问http://你的出口地址能看到 FileBrowser 页面就算通了。界面里「负载均衡」开关打开后目标地址就能填多个这是下一节的伏笔。规则拆解主规则与子规则怎么配这一节讲清请求进来后Lucky 先拿什么去匹配、匹配上又转去哪。一条主规则 一个监听端口 一个「默认规则」 N 条「自定义子规则」。处理顺序是先看请求的 Host 能否在子规则里精确命中某个域名命中就用那条子规则的后端没命中就落到默认规则的后端。域名精确匹配{ Domains: [file.my-home.net], Enable: true, Locations: [http://192.168.0.50:8088] }注释只有 Host 与Domains里某项完全一致才算命中file.my-home.net:80这种带端口的写法不会命中file.my-home.net。路径前缀匹配{ Domains: [api.my-home.net], Locations: [http://192.168.0.51:3200] }注释子规则本身不做路径切割/v2/orders会原样转给后端想只代理某个前缀要靠后端服务自己按路径分流或者再配一条域名规则指向另一台机器。匹配谁、转去哪在规则列表页的日志里能逐条看到比如[file.my-home.net] 指向后端地址[http://192.168.0.50:8088]排查为什么流量走错了就看这一行。四种负载均衡怎么选后端只有一台跳过这节。多台同构服务要一起扛流量时先按下面选策略策略典型场景在 Lucky 里怎么落地轮询各节点性能一致请求轻重差不多子规则填多个后端地址默认行为最少连接请求耗时差异大短请求多长请求少后端加健康探针配合监控手动摘除慢节点IP 哈希同用户要落同一台会话粘滞用不同域名/端口做入口按客户端分组加权轮询节点规格不一大机器多扛些用多条规则按权重拆端口入口再分发多后端示例三个地址轮着接流量{ Domains: [shop.my-home.net], Locations: [ http://192.168.0.61:8080, http://192.168.0.62:8080, http://192.168.0.63:8080 ] }注释Lucky 内建的分发方式是按下标轮询取下一个地址源码里就是取模自增所以表格里轮询是它的原生能力其余三种需要组合技巧实现。一个细节节点挂了时轮询不会自动跳过请求打过去就是 502/超时。建议给后端配存活探测比如 cron 探活后告警比指望代理自动摘除更实际。安全加固三步走端口一旦开出去就要想谁来、怎么来。这一步只做三件事每件都写在子规则上作用范围就是这条子规则。第一步Basic 认证应用层浏览器弹框要账密{ EnableBasicAuth: true, BasicAuthUser: ops, BasicAuthPasswd: s3cret }注释账密对了才放行未认证请求直接回 401只护单条子规则默认规则不受影响。第二步IP 黑白名单网络层在转发前拦Lucky 的全局黑白名单页统一管理条目子规则里选模式即可{ SafeIPMode: whitelist }注释whitelist模式下不在名单里的 IP 一律拒绝记得把办公网段和家里宽带出口 IP 都加进去否则自己先被挡。黑名单模式则是列了才拒适合封已知的扫描 IP。第三步UA 过滤应用层按浏览器指纹拦脚本{ SafeUserAgentMode: blacklist, UserAgentfilter: [masscan, sqlmap] }注释User-Agent 里包含任意一项就拒绝专治各类扫描器改成whitelist则变成只放行带指定特征的客户端慎用很多正常客户端 UA 也会变。请求进来后的实际检查顺序是先 IP、再 UA、最后认证任何一步不过就断开并写一条 Warn 日志。提速技巧缓存参数与连接参数不堆参数只说对体感影响最大的几个。EnableAccessLogLogLevelAccessLogMaxNum日志开关、级别、内存里保留的条数。日志开着几乎无感但AccessLogMaxNum调到几万条以上时内存里的环形缓冲会明显变大常规几十到一两条规则给 1000 条足够。ForwardedByClientIPRemoteIPHeadersTrustedCIDRsStrList当 Lucky 前面还挂着运营商光猫、CDN 或另一层反代时把可信代理网段填进 CIDR 列表再声明从X-Forwarded-For这类头里读真实客户端 IP否则日志和白名单一直看到的都是上一跳代理的 IP规则形同虚设。AddRemoteIPToHeaderAddRemoteIPHeaderKey把识别到的客户端 IP 写进自定义请求头发给后端后端应用日志才能落到真实访客。两个不需要你操心的点Lucky 不做页面级缓存静态资源的Cache-Control交给后端或 CDN 自己设到后端的连接复用由 Go 标准库的传输层自动管理日常没有暴露可调项真到瓶颈时先看后端的单连接处理速度而不是在代理层找旋钮。出问题了先看这里访问日志是每条转发请求一行 JSON关键字段速查字段含义常见异常信号Host客户端带的域名和子规则域名对不上说明被兜到默认规则URL完整请求路径路径被吃掉或多了前缀多半是后端路由问题ClientIP识别到的客户端 IP全显示成同一台内网 IP说明可信代理没配UserAgent客户端指纹大量异常 UA配合黑名单封禁level / msg级别与消息禁止访问、认证不通过、没有对应后端地址三步排查法先看Host和URL——请求有没有进对规则再看msg——是IP禁止访问名单问题、认证不通过账密问题还是没有对应后端地址子规则忘填 Locations都不是直接在后端机器上curl后端地址确认服务本身活着、端口对内网可达。备份与回滚Lucky 的全部规则就存在一个配置 JSON 文件里改动批量规则前把整个文件复制一份改坏直接覆盖回去比逐条排查快一个数量级。建议再给自己定个规矩每次动规则记一行改动说明出问题能定位是哪一步引入的。三个最易踩的坑坑域名加了端口就匹配不上。原因Lucky 对 Host 做精确匹配file.x.com和file.x.com:8080是两回事。规避客户端访问不带端口或者在Domains里把带端口的写法也列进去。坑子规则没配后端流量悄悄走了默认规则。原因Lucky 允许子规则不填Locations此时回落到默认规则现象是改了子规则没用。规避给子规则都填上后端或在默认规则留个兜底地址并打日志。坑前面挂了代理后IP 过滤全部失灵。原因Lucky 默认只认直连 IP不解析X-Forwarded-For白名单里加什么真实 IP 都没用。规避按「提速技巧」配好可信代理网段和请求头再重新过一遍名单。一句话收个尾先用五分钟跑通一条规则再按域名拆子规则最后把认证、名单和日志补上——Lucky 反向代理要的就这三件事。规则字段的更多细节可以翻 反向代理模块源码 对照着看字段名和界面上是一一对应的。【免费下载链接】lucky软硬路由公网神器,ipv6/ipv4 端口转发,反向代理,DDNS,WOL,ipv4 stun内网穿透,cron,acme,rclone,ftp,webdav,filebrowser项目地址: https://gitcode.com/GitHub_Trending/luc/lucky创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考