Cloudflare 规则 + Lucky 反向代理教程：实现 HTTPS 无端口访问
摘要
详细介绍 Cloudflare Origin Rules 与 Lucky 反向代理配置，通过源站端口改写实现 HTTPS 无端口访问，涵盖 DNS 代理、证书配置、端口转发、安全防护及 502、525、526 等常见问题。
在搭建个人网站、NAS、家庭服务器或 Docker 应用时，我们经常会遇到一个问题：服务已经正常运行，但访问时必须在域名后面输入端口号，例如 https://example.com:18443。
这种访问方式不够简洁，也不利于统一管理多个 Web 服务。
通过 Cloudflare Origin Rules + Lucky 反向代理，可以将访问域名与后端端口分离。用户只需要访问 https://app.example.com，Cloudflare 就会根据规则将请求转发到 Lucky 监听的实际端口，从而实现 HTTPS 无端口访问。
本文将从工作原理、DNS 配置、源站规则创建、Lucky 反向代理设置，到 HTTPS 配置和故障排查，完整介绍这套方案。
一、Cloudflare + Lucky 的工作原理#
这套方案主要依靠两个组件协同工作。
Cloudflare Origin Rules（源站规则）
Cloudflare 源站规则可以修改请求发往源站时使用的目标端口。即使用户通过标准 HTTPS 地址访问，Cloudflare 也可以按照规则将请求发送到源站的非标准端口。
Lucky 反向代理
Lucky 负责接收请求，根据访问域名匹配对应的 Web 服务规则，再将请求转发到实际运行的应用。
整体架构如下：
例如，Lucky 监听 HTTPS 端口 18443，而实际应用运行在 192.168.1.100:8080。
Cloudflare 接收到访问 app.example.com 的请求后，会根据源站规则将请求发送到源站的 18443 端口。Lucky 接收请求并将其转发到后端应用。
最终，用户只需要输入：
https://app.example.com
而不需要输入 :18443。
需要注意：这种方案隐藏的是用户访问 URL 中的非标准端口，并不意味着源站端口不需要开放。 Cloudflare 必须能够通过公网访问配置的源站端口。
二、准备工作#
开始配置前，需要准备以下内容：
一个已经注册的域名，例如
example.com。一个 Cloudflare 账号，并将域名接入 Cloudflare。
一台已经安装 Lucky 的服务器或 NAS。
一个拥有公网可达 IP 的网络环境。
一个正常运行的后端 Web 应用。
为了方便演示，本文统一使用以下示例参数：
配置项目 | 示例值 |
|---|---|
主域名 |
|
应用域名 |
|
服务器公网 IP |
|
Lucky 内网 IP |
|
Lucky HTTPS 监听端口 |
|
后端应用地址 |
|
最终访问地址 |
|
其中，203.0.113.10 是文档示例 IP，并不是可以直接使用的真实服务器地址。实际配置时，应替换成自己的公网 IP。
此外，Lucky 需要配置 HTTPS 监听，并安装与访问域名匹配的证书。
如果你的网络处于运营商级 NAT（CGNAT）环境中，没有可用的公网入站连接条件，那么这套方案通常无法直接使用。此时可以考虑使用 Cloudflare Tunnel。
三、第一步：配置 Cloudflare DNS 解析#
首先登录 Cloudflare 控制台，选择已经接入的域名。
进入 DNS 管理页面，添加一条记录。
示例配置如下：
字段 | 配置 |
|---|---|
类型 | A |
名称 |
|
IPv4 地址 | 自己的服务器公网 IP |
TTL | Auto |
代理状态 | 已代理（橙色云朵） |
保存后，app.example.com 就会通过 Cloudflare 代理访问源站。
如果服务器没有固定公网 IP，需要配置动态 DNS 更新机制，确保公网 IP 变化后，Cloudflare DNS 记录能够同步更新。
注意： DNS 记录必须启用 Cloudflare 代理，源站规则才能作用于经过 Cloudflare 网络的请求。
四、第二步：配置 Lucky HTTPS 反向代理#
接下来配置 Lucky，让它监听指定的 HTTPS 端口，并把请求转发给实际的 Web 应用。
1. 配置 HTTPS 监听端口#
登录 Lucky 管理页面，找到 Web 服务或相关监听配置。
将 HTTPS 监听端口设置为：
这里的端口只是示例，也可以根据实际情况改成其他端口，但必须确保服务器网络、Lucky 配置和 Cloudflare 规则使用同一个端口。
2. 配置 SSL/TLS 证书#
为 app.example.com 配置有效的 HTTPS 证书。
可以选择受信任的公开证书，也可以使用 Cloudflare Origin CA 证书。使用 Origin CA 证书时，需要将对应的证书和私钥配置到 Lucky，并确认 Cloudflare 的 SSL/TLS 模式为 Full (strict)。
注意，Cloudflare Origin CA 证书主要用于 Cloudflare 到源站的连接，通常不被普通浏览器直接信任。
3. 创建 Web 服务规则#
在 Lucky 中创建对应的 Web 服务或反向代理规则。
前端域名填写：
后端应用地址填写：
保存并启用规则。
此时，Lucky 的工作流程为：
如果后端应用使用 WebSocket、长连接或特殊请求头，还需要根据应用要求调整对应的反向代理参数。
五、第三步：创建 Cloudflare Origin Rules#
这是整套方案最关键的一步。
Cloudflare 源站规则用于修改 Cloudflare 向源站发送请求时的目标端口。配置后，用户访问的域名和 Lucky 实际监听的端口就可以分离。
1. 进入源站规则页面#
登录 Cloudflare 控制台，选择对应域名，然后进入：
Rules → Overview → Create rule → Origin Rule
不同版本的控制台可能会有界面名称或布局调整。
2. 创建规则并设置匹配条件#
规则名称可以填写：
在请求匹配条件中，设置：
如果控制台使用表达式编辑器，可以使用：
这样，这条规则就只作用于访问 app.example.com 的请求。
3. 修改目标端口#
在源站参数中，找到 Destination Port（目标端口）设置，并选择改写目标端口。
填写：
完整规则逻辑如下：
配置项 | 值 |
|---|---|
规则名称 | Lucky Reverse Proxy Port |
匹配字段 | Hostname |
匹配条件 | equals |
匹配值 |
|
修改参数 | Destination Port |
改写端口 |
|
确认无误后，保存并部署规则。
Cloudflare 官方创建规则说明：
https://developers.cloudflare.com/rules/origin-rules/create-dashboard/
Cloudflare 官方端口改写示例：
https://developers.cloudflare.com/rules/origin-rules/examples/change-port/
根据 Cloudflare 当前官方文档，Origin Rules 的目标端口改写功能可用于 Free、Pro、Business 和 Enterprise 计划，但规则数量及其他可改写参数存在计划差异。Free 计划支持目标端口改写。
六、第四步：配置 SSL/TLS 加密模式#
为了确保浏览器到 Cloudflare、以及 Cloudflare 到 Lucky 的连接都使用 HTTPS，需要正确配置 SSL/TLS。
建议进入：
Cloudflare → SSL/TLS → Overview
选择：
使用该模式时，Cloudflare 会通过 HTTPS 连接源站，并验证源站证书是否有效、是否匹配目标域名。
因此，需要确保以下条件成立：
Lucky 的
18443端口确实提供 HTTPS 服务。Lucky 安装了有效的源站证书。
证书包含
app.example.com。证书未过期，并且受到 Cloudflare 支持的证书颁发机构信任，或使用符合要求的 Cloudflare Origin CA 证书。
源站防火墙允许 Cloudflare 访问目标端口。
如果 Lucky 的 18443 端口实际上只提供普通 HTTP 服务，那么在 Full (strict) 模式下，Cloudflare 无法正常建立 HTTPS 源站连接。
不要仅为了消除错误而直接切换到 Flexible 模式。对于包含登录、个人数据等内容的应用，建议使用 Full (strict)，并正确配置源站 HTTPS。
七、第五步：配置端口转发与防火墙#
Cloudflare Origin Rules 负责修改请求的目标端口，但并不会自动创建服务器防火墙规则或路由器端口映射。
如果 Lucky 安装在家庭网络或内网服务器上，需要确认公网流量能够到达 Lucky 的 HTTPS 监听端口。
例如：
如果 Lucky 安装在具有公网 IP 的云服务器上，则需要在服务器防火墙和云平台安全组中允许相应连接。
为了降低攻击面，建议将源站 18443 端口限制为仅接受 Cloudflare 官方 IP 地址范围的入站连接，并定期更新防火墙白名单。
需要注意，端口改写不是安全隔离措施。如果源站端口对所有互联网地址开放，攻击者仍可能绕过 Cloudflare，直接尝试访问源站。
八、第六步：测试 HTTPS 无端口访问#
完成所有配置后，就可以开始测试。
首先，直接检查 Lucky 的 HTTPS 服务是否运行正常，确保从 Cloudflare 可达的网络能够连接源站端口。
然后在浏览器中访问：
如果配置正确，页面应正常显示，而且浏览器地址栏中不需要出现 :18443。
建议检查以下项目：
DNS 记录是否已经启用 Cloudflare 代理。
Origin Rules 是否已部署，匹配条件是否正确。
Lucky 是否监听
18443，并正确启用 HTTPS。源站证书是否有效且匹配域名。
路由器端口转发、防火墙和安全组是否允许 Cloudflare 访问源站。
Lucky 是否能够访问后端应用。
如果访问失败，应按照请求链路逐层排查，而不是反复修改 DNS 或 SSL/TLS 配置。
九、常见问题与解决方法#
1. Cloudflare 返回 502 Bad Gateway#
502 表示 Cloudflare 无法正常获得源站响应。
优先检查：
Origin Rules 是否将目标端口改写为正确的值。
Lucky 是否正在监听该端口。
该端口提供的是 HTTPS，而不是普通 HTTP。
源站防火墙是否允许 Cloudflare 访问。
Lucky 到后端应用的连接是否正常。
2. 出现 525 SSL Handshake Failed#
这通常与 Cloudflare 和源站之间的 TLS 握手失败有关。
检查 Lucky 是否在目标端口提供 HTTPS 服务、证书是否正确安装，以及 TLS 配置是否正常。
如果源站仅提供 HTTP 服务，Cloudflare 却尝试使用 HTTPS 连接，也可能出现连接失败。
3. 浏览器出现 526 Invalid SSL Certificate#
这通常表示在 Full (strict) 模式下，Cloudflare 无法验证源站证书。
检查证书有效期、域名匹配情况及证书颁发机构是否符合要求。若使用 Cloudflare Origin CA 证书，应确认其正确安装在 Lucky 的 HTTPS 服务中。
4. 规则已经创建，但访问仍然使用错误端口#
检查规则是否已部署，Hostname 匹配条件是否正确，以及是否有其他规则影响请求处理。
可以使用 Cloudflare Trace 等诊断功能检查特定请求是否匹配源站规则。
5. 页面可以打开，但登录或 WebSocket 无法使用#
部分应用依赖 Host、协议请求头、Cookie、WebSocket 或长连接。
此时需要检查 Lucky 的反向代理参数，以及后端应用对外部访问域名和 HTTPS 协议的识别方式。
十、Cloudflare 规则 + Lucky 与 Cloudflare Tunnel 有什么区别？#
这两种方案都能实现域名访问，但网络架构不同。
对比项目 | Origin Rules + Lucky | Cloudflare Tunnel + Lucky |
|---|---|---|
工作方式 | 修改源站目标端口 | 通过出站隧道转发请求 |
是否需要公网 IP | 通常需要 | 通常不需要公网 IPv4 |
是否需要公网入站端口 | 需要开放源站监听端口 | 通常不需要 |
是否需要 | 不需要 | 需要 |
适用场景 | 已具备公网入站条件的服务器 | 家庭网络、无公网 IPv4 或不方便开放端口的环境 |
如果你的服务器已经拥有公网 IP，并且能够开放源站端口，Origin Rules + Lucky 是一种简单直接的方案。
如果你的网络处于 CGNAT 环境，或者不希望开放任何公网入站端口，则更适合使用 Cloudflare Tunnel。
十一、总结#
通过 Cloudflare Origin Rules + Lucky 反向代理，可以为内网或公网服务器上的 Web 应用配置简洁的 HTTPS 域名访问地址。
这套方案的核心流程是：
Cloudflare DNS 代理 → Origin Rules 改写目标端口 → Lucky HTTPS 监听 → 反向代理至后端应用。
用户最终可以通过 https://app.example.com 访问服务，而不需要输入 Lucky 的非标准端口。
部署过程中需要重点关注三个方面：源站端口的公网可达性、Cloudflare 与 Lucky 之间的 HTTPS 配置，以及源站端口的访问控制。
完成这些配置后，就可以将不同 Web 服务分配到独立子域名，实现更加清晰、易维护的反向代理架构。