本文以自己的 HTTP/HTTPS 服务为例，三种方法的前提和协议能力不同。
家庭宽带是否屏蔽入站 80/443 端口，要从外网实测，同时检查公网地址、光猫、路由器、防火墙和端口映射。非标准端口本身不决定搜索引擎是否收录；备案与运营商服务条款也不能从“能连通”直接推断。
如果已经有可从外网访问的 HTTPS 服务，例如 origin.example.com:8443，可以在入口层使用标准 HTTPS 地址。若没有公网地址或无法接收入站连接，直接换回源端口不会解决问题，可以考虑第三种隧道方式。
一、Cloudflare Origin Rules 修改回源端口
场景：用户访问 https://app.example.com，Cloudflare 回源到同一服务的 8443，地址栏仍使用标准 443。
- 将
app.example.com的 DNS 指向可达的源站地址并启用代理。 - 源站在
8443提供 HTTPS，证书覆盖入口域名；TLS 模式选择 Full (strict)。 - 在 Origin Rules 中仅匹配这个主机，例如表达式
http.host eq "app.example.com"，将 Destination port 改为8443。 - 从外网检查源站端口和 Cloudflare 入口。若源站也有 AAAA，确认它的 IPv6 地址同样可达，避免只修通 IPv4。
Origin Rules 的目的端口可设置为 1–65535，这描述的是回源端口，不是 Cloudflare 对用户开放了所有访问端口。修改 Host、DNS 目标或 SNI 是其他设置，是否可用应按当前套餐核对；只改端口时不要额外把 Host 改成无关域名。Cloudflare Origin Rules
普通网站与 WebSocket 仍需验证应用自身的代理配置。gRPC 还有 443、TLS、HTTP/2 与 ALPN 等要求，不能由“允许修改回源端口”推出任意 gRPC 服务都可用；按 Cloudflare gRPC 要求 单独核对。
二、Workers 转发到固定的自有源站
Workers 适合需要控制路径或响应的 HTTP 应用。旧版代码只复制了 method 和 headers，没有转发请求 body，导致上传和 POST 失败；307 重定向会让浏览器直接访问源站，并没有补齐反向代理。
下面使用 Modules 语法，固定转发到自己的源站，保留请求方法、body、路径、查询参数和应用安全响应头。origin.example.com 必须是与 Worker 入口分开的源站域名，不能再次命中同一个 Worker。
const ORIGIN = 'https://origin.example.com:8443';
export default {
async fetch(request) {
const incoming = new URL(request.url);
const target = new URL(ORIGIN);
target.pathname = incoming.pathname;
target.search = incoming.search;
const forwarded = new Request(target.toString(), request);
forwarded.headers.set('Host', target.host);
const response = await fetch(new Request(forwarded, {
redirect: 'manual',
cache: 'no-store'
}));
// WebSocket 升级响应含运行时 webSocket 属性，直接返回。
if (response.status === 101) return response;
const headers = new Headers(response.headers);
const location = headers.get('Location');
if (location) {
const redirectTo = new URL(location, target);
if (redirectTo.origin === target.origin) {
redirectTo.protocol = incoming.protocol;
redirectTo.hostname = incoming.hostname;
redirectTo.port = incoming.port;
headers.set('Location', redirectTo.toString());
}
}
headers.set('Cache-Control', 'private, no-store');
return new Response(response.body, {
status: response.status,
statusText: response.statusText,
headers
});
}
};
配置 Worker 的自定义域名，或使用覆盖完整路径的路由 app.example.com/*。源站自己的 HTTPS 证书需要被 Workers 信任；DNS only 源站不会经过 Cloudflare 橙云代理端口列表。Workers 自定义端口支持由兼容日期/flag 控制，allow_custom_ports 自 2024-09-02 起默认开启，旧兼容日期需要显式核对。Workers Request、兼容性 flags
redirect: manual 避免 Workers 自动把 Cookie、Authorization 等头带到跨域重定向目标。应用应把公开 URL 配置成 Worker 域名，否则绝对资源链接、Cookie 的 Domain、登录回调仍可能指向源站。这里不删除 CSP、不伪造 Referer/Origin，也不自动开放跨域凭据。
此示例不提供身份认证，需要在入口或源站按应用用途设置认证和访问控制。部署后分别验证 GET、带 body 的 POST/上传、重定向、登录 Cookie 和需要的 WebSocket；HTTP 请求转发代码的通过不等于所有流式协议均受支持。
三、Cloudflare Tunnel
如果家庭网络没有可用公网入站地址，可以在内网运行 cloudflared，由它主动连接 Cloudflare，将公开域名映射到自己的本地服务，例如 http://127.0.0.1:8080。这样不需要把家庭路由器的 80/443 端口映射到公网，但连接器所在网络仍要允许 Tunnel 所需的出站连接。
按 Cloudflare Tunnel 官方文档 创建 Tunnel、安装连接器、保存凭据并添加公开主机名。管理界面或仅供自己使用的应用应配置 Cloudflare Access 或应用本身的认证，再从外网核对实际访问权限。
以上三条路径分别解决回源端口、HTTP 转发逻辑和无公网入站的问题，应先确认自己的网络属于哪一种情况。
评论区