Cloudflare Tunnel + Lucky 反向代理教程：实现 HTTPS 无端口访问

在搭建 NAS、Docker、家庭服务器或个人网站时，很多 Web 服务默认需要通过端口号访问，例如 http://192.168.1.100:8080。这种方式不仅不够简洁，还可能受到公网 IP、路由器端口映射等因素的限制。

通过 Cloudflare Tunnel + Lucky 反向代理，可以将内网应用绑定到自己的域名，实现 HTTPS 无端口访问。用户只需访问 https://app.example.com，无需在浏览器地址栏输入非标准端口号，也通常不需要开放路由器的公网入站端口。

本文将从工作原理、环境准备、配置步骤到故障排查，完整介绍这套方案的部署方法。

一、Cloudflare + Lucky 的工作原理#

Cloudflare 和 Lucky 在整个访问链路中承担不同的职责：

Cloudflare：提供域名接入、HTTPS 和公网访问入口。
Cloudflare Tunnel：通过 cloudflared 建立服务器到 Cloudflare 的出站连接，将公网请求转发到内网。
Lucky：根据访问域名匹配反向代理规则，并将请求转发到对应的后端应用。
后端应用：运行在 NAS、服务器或 Docker 容器中，例如网站、文件管理系统和其他 Web 服务。

整体架构如下：

纯文本

用户浏览器
    |
    | https://app.example.com
    v
Cloudflare DNS / HTTPS
    |
    v
Cloudflare Tunnel
    |
    v
Lucky 反向代理（HTTP :80）
    |
    v
内网应用（192.168.1.100:8080）

例如，后端应用运行在 192.168.1.100:8080，Lucky 负责接收请求并将流量转发给后端，Cloudflare Tunnel 则把外部请求安全地送到 Lucky。

需要注意，Cloudflare Tunnel 也支持直接代理后端应用。如果希望统一管理多个内网应用的域名和反向代理规则，可以将 Lucky 放在 Tunnel 后面。

二、准备工作#

开始配置前，需要准备以下内容：

一个已经注册的域名，例如 example.com。
一个 Cloudflare 账号，并将域名接入 Cloudflare。
一台已经安装 Lucky 的 NAS 或服务器。
一个正常运行的 Web 应用，例如 192.168.1.100:8080。
一台用于运行 cloudflared 的设备，可以与 Lucky 安装在同一台服务器上。

本文统一使用以下示例配置：

配置项目	示例值
主域名	`example.com`
应用域名	`app.example.com`
Lucky 内网地址	`192.168.1.10`
Lucky 监听端口	`80`
后端应用地址	`192.168.1.100:8080`
最终访问地址	`https://app.example.com`

以上 IP 地址仅用于示例，实际部署时需要替换成自己的设备地址。

在开始之前，先确认后端应用可以正常访问，例如：

纯文本

http://192.168.1.100:8080

如果后端应用本身无法访问，应先解决应用启动、监听地址或网络问题，再进行反向代理配置。

三、第一步：将域名接入 Cloudflare#

等待 Cloudflare 确认域名接入成功后，就可以继续配置 Tunnel。

建议为不同应用使用独立的子域名，例如：

应用用途	域名示例
个人网站	`blog.example.com`
NAS 服务	`nas.example.com`
Docker 应用	`app.example.com`
其他 Web 服务	`service.example.com`

使用独立子域名可以让每个应用拥有单独的访问入口，后续维护和配置访问权限也更加方便。

四、第二步：配置 Lucky 反向代理#

1. 创建反向代理规则#

新增一条规则，并设置前端匹配域名：

纯文本

app.example.com

然后设置后端目标地址：

纯文本

http://192.168.1.100:8080

这里的地址是实际提供 Web 服务的应用，而不是 Cloudflare Tunnel 的地址。

2. 配置 Lucky 的监听端口#

假设 Lucky 监听 HTTP 的 80 端口，且该端口没有被其他服务占用，就可以将其作为 Cloudflare Tunnel 的内网访问入口。

此时请求的流向为：

纯文本

cloudflared
    |
    v
http://192.168.1.10:80
    |
    v
Lucky
    |
    v
http://192.168.1.100:8080

如果 Lucky 安装在其他设备上，或者运行于 Docker 容器中，需要根据实际网络环境修改监听地址。

3. 保存并检查规则#

保存配置并启用反向代理规则，确认：

域名匹配规则正确。
后端地址和端口正确。
Lucky 能够访问后端应用。
没有其他服务占用需要使用的监听端口。

建议先通过局域网访问 Lucky 的代理入口，确认反向代理能够正常工作，再继续配置 Cloudflare Tunnel。

如果使用域名匹配规则，还要确认请求中的 Host 与规则要求一致。

五、第三步：配置 Cloudflare Tunnel#

Cloudflare Tunnel 可以在不直接开放公网入站端口的情况下，将外部请求转发到内网服务。

1. 创建 Tunnel#

根据服务器操作系统选择对应的 cloudflared 安装和运行方式，并使用控制台提供的命令完成连接。

等待 Tunnel 显示连接正常。

官方文档：

https://developers.cloudflare.com/cloudflare-one/networks/connect-networks/cloudflare-tunnel/

2. 添加公共主机名#

进入 Tunnel 的路由配置，添加一个公共主机名：

纯文本

Hostname: app.example.com
Service:  http://192.168.1.10:80

这里的 192.168.1.10:80 是 Lucky 的实际监听地址。

关键点：Tunnel 的 Service URL 应指向 Lucky，而不是直接指向后端应用。 如果直接填写 http://192.168.1.100:8080，请求就会绕过 Lucky。

如果 cloudflared 与 Lucky 在同一台宿主机上，也可以根据实际监听情况使用：

纯文本

http://127.0.0.1:80

但前提是 127.0.0.1:80 确实能够访问 Lucky。若它们运行在不同 Docker 容器中，不能默认使用 127.0.0.1，因为该地址通常指向当前容器自身。

3. 配置 DNS 路由#

按照 Cloudflare Tunnel 的主机名配置流程，将 app.example.com 关联到对应的 Tunnel。

确认域名路由已经建立，并且 Tunnel 有可用连接。

需要区分两件事：DNS 配置正确，只能说明域名路由已设置；Tunnel 正常，也不代表 Lucky 和后端应用一定能够正常响应。

六、第四步：测试 HTTPS 无端口访问#

完成配置后，在浏览器中打开：

纯文本

https://app.example.com

如果页面正常显示，说明基本访问链路已经打通。

此时用户访问的是标准 HTTPS 地址，不需要输入后端应用的 8080 端口。

建议按照以下顺序测试：

测试后端应用：确认 192.168.1.100:8080 可以正常访问。
测试 Lucky：确认 Lucky 能根据 app.example.com 将请求转发到后端。
测试 Tunnel：确认 cloudflared 已连接，并能访问 Lucky 的监听地址。
测试公网域名：通过 https://app.example.com 访问应用。
测试应用功能：检查登录、文件上传、WebSocket 和其他需要长连接的功能。

如果某一步失败，应优先排查该层，而不是反复修改 DNS 或重装服务。

七、Docker 环境下的注意事项#

如果 Lucky、cloudflared 和后端应用都运行在 Docker 中，网络配置尤其重要。

1. 不要盲目使用 127.0.0.1#

在 Docker Bridge 网络中，每个容器通常拥有独立的网络命名空间。

例如：

纯文本

cloudflared 容器
    |
    | 访问 Lucky 的容器地址
    v
Lucky 容器
    |
    | 访问后端应用
    v
后端应用容器

如果 cloudflared 和 Lucky 位于不同容器，127.0.0.1:80 通常指向 cloudflared 容器自身，而不是 Lucky。

可以根据部署方式使用共享 Docker 网络、容器服务名称、宿主机地址或其他实际可达的地址。

2. 确认容器之间可以通信#

需要检查：

容器是否位于可互相访问的网络。
Lucky 是否监听正确的地址和端口。
防火墙是否阻止容器间通信。
后端应用是否只监听 127.0.0.1，导致其他容器无法访问。

如果 Lucky 运行在宿主机，而后端应用位于容器中，也需要确保宿主机能够访问后端映射端口。

3. 优先验证网络，再修改代理配置#

遇到连接失败时，应先确认 cloudflared 能否访问 Lucky，再确认 Lucky 能否访问后端。

明确请求在哪一层中断，可以避免无效地修改 DNS、SSL 或反向代理规则。

八、常见问题与解决方法#

1. Cloudflare Error 1033#

该错误通常表示 Cloudflare 没有可用的 Tunnel 连接。

建议检查：

cloudflared 是否正常运行。
Tunnel 是否在线。
Tunnel 的连接日志是否存在认证或网络错误。
公共主机名是否关联到正确的 Tunnel。

2. Cloudflare Error 502#

502 表示请求未能正常到达或获得源站服务的有效响应，具体原因需要结合错误页面和日志判断。

优先检查：

Tunnel 的 Service URL 是否填写正确。
cloudflared 是否能够访问 Lucky。
Lucky 是否监听指定端口。
Lucky 的代理规则是否已启用。

如果 Tunnel 指向 Lucky 的地址错误，即使 Tunnel 显示在线，也可能无法正常访问应用。

3. Lucky 返回 502 Bad Gateway#

如果请求已经到达 Lucky，但 Lucky 无法正常访问后端，应检查后端 IP、端口、服务状态以及容器网络。

例如，确认以下地址在 Lucky 所在的网络环境中确实可达：

纯文本

http://192.168.1.100:8080

4. HTTPS 出现重定向循环#

如果 Cloudflare、Lucky 和后端应用都设置了 HTTP 到 HTTPS 的跳转，可能产生循环重定向。

建议明确 HTTPS 在哪一层终止，并检查后端应用对代理协议和请求头的识别方式。

如果应用支持配置外部访问地址，应确保其使用正确的 HTTPS 域名。

5. 页面正常，但登录或 WebSocket 异常#

部分应用依赖 Cookie、WebSocket、特定请求头或长时间连接。

建议检查：

应用的外部 URL 是否设置正确。
Host、协议相关请求头是否符合应用要求。
WebSocket 是否受到代理规则限制。
Cookie 的域名和 Secure 属性是否正确。
相关超时配置是否适合应用场景。

九、安全建议#

通过 Cloudflare Tunnel 实现无端口访问，可以减少公网入站端口暴露，但不能替代应用本身的安全措施。

建议遵循以下原则：

保护管理后台：不要将 NAS、路由器或服务器管理界面无保护地公开到互联网。
启用身份验证：对于私人应用，可以考虑使用 Cloudflare Access 或应用自身的可靠认证机制。
保护 Lucky 管理入口：使用强密码，并限制管理页面的访问范围。
避免不必要的端口暴露：只开放业务实际需要的网络入口。
妥善保管 Tunnel 凭据：不要将 Token、凭据文件或登录密码提交到公开代码仓库。
定期更新组件：及时更新 Lucky、cloudflared、Docker 镜像和后端应用。

如果服务涉及个人文件、账户数据或管理权限，建议先完成身份验证和访问控制，再开放公网域名。

十、常见问题 FAQ#

Q1：使用 Cloudflare Tunnel 还需要公网 IP 吗？#

通常不需要公网 IPv4，也不需要在家用路由器上配置公网入站端口映射。服务器需要能够主动连接 Cloudflare 的网络服务。

Q2：无端口访问是否意味着后端不再使用端口？#

不是。后端应用仍然可以使用 8080、3000 等端口。无端口访问是指用户不需要在浏览器地址中输入这些非标准端口。

Q3：Cloudflare Tunnel 和 Lucky 必须安装在同一台设备上吗？#

不必。两者可以运行在不同设备上，只要 cloudflared 能够访问 Lucky 的监听地址，Lucky 也能够访问后端应用即可。

Q4：可以为多个应用配置不同的域名吗？#

可以。例如，为不同应用配置 nas.example.com、blog.example.com 和 app.example.com，再在 Lucky 中分别创建对应的代理规则。

Q5：Cloudflare Tunnel 和 Lucky 能否互相替代？#

它们的职责不同。Tunnel 负责建立从 Cloudflare 到内网服务的连接，Lucky 负责按照域名等规则分发请求。Tunnel 也可以直接连接后端应用，因此是否需要 Lucky，取决于是否需要额外的反向代理管理功能。

十一、总结#

通过 Cloudflare Tunnel + Lucky，可以将 NAS、Docker 和家庭服务器中的 Web 应用统一到域名入口，实现 HTTPS 无端口访问。

整套方案的核心流程是：

Cloudflare 提供公网入口，Tunnel 建立内网连接，Lucky 负责反向代理，后端应用提供实际服务。

部署时最重要的是确保三段链路全部正常：

Cloudflare Tunnel 能够访问 Lucky。
Lucky 能够访问后端应用。
域名与 HTTPS 配置正确。

如果你计划为多个内网服务配置公网访问，建议为不同应用分配独立子域名，并根据服务的敏感程度设置访问控制。

参考资料#

Cloudflare Tunnel 官方文档：https://developers.cloudflare.com/cloudflare-one/networks/connect-networks/cloudflare-tunnel/
Cloudflare Tunnel 公共主机名路由：https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/
Lucky 官方文档：https://lucky666.cn/docs/modules/web/
Lucky 安装文档：https://lucky666.cn/docs/install/