0、前言

Cloudflare Tunnel（之前名为 Cloudflare Argo Tunnel）是 Cloudflare 的一款 新（？） 旧产品了，但是最早的几个版本使用体验极其糟糕，例如创建隧道只能获取一个随机的 UUID 作为隧道名，再加上能够找到的资料并不多而且漏洞百出，完全按照流程做一遍也无法成功配置，因此在折腾数次后果断放弃。

在经过很长时间的迭代后 Cloudflare Tunnel 终于好用起来了，并且看到有教程已成功实现使用 Cloudflare SaaS 域名接入 Cloudflare Tunnel，于是在踩坑后得出了快速配置的正确方法。

1、简介

Cloudflare Tunnel 是一款隧道软件，可以快速安全地加密应用程序到任何类型基础设施的流量，让您能够隐藏你的 Web 服务器 IP 地址，阻止直接攻击，从而专注于提供出色的应用程序。
——Cloudflare¹

简而言之，Cloudflare Tunnel 就是 Cloudflare 的免费内网穿透。目前免费版应该只支持 HTTP。

2、安装

Cloudflare Tunnel 分为云端管理型和本地管理型，本地管理型是自己写配置文件，因此难度更大，但是也更灵活，如果需求简单可以直接选择云端管理型。无论是哪种 Tunnel 都支持一键安装。

2.1、云端管理型

先在面板添加 Tunnel，然后复制安装指令：

等待安装完成即可。

2.2、本地管理型

安装指令区分架构，请注意：

# AMD
curl -o /usr/bin/cloudflared -L "https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64"

# ARM
curl -o /usr/bin/cloudflared -L "https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm64"

# 设置可执行权限：
chmod +x /usr/bin/cloudflared

如果之后启动的时候提示有新版本，可以执行：

#更新
cloudflared update

这里不得不吐槽一下，一开始找到的升级文档，使用的方法是通过 Tunnel Replica 启动一个备用 Tunnel 以实现无缝切换，太复杂了。不过好像是我找错了文档……

3、配置

如果是云端管理型，在面板中看到 Tunnel 状态为 Active 后点击配置，按照说明添加域名等即可。全过程均在控制面板完成，唯一不方便的就是添加的域名只能在你的账户域名中选取，SaaS 接入的域名无法添加（下文有解决方法）。

下文为本地管理型的配置方法。

先登录：

cloudflared login

打开登录 URL，选择一个域（随便哪一个，不影响后续接入）即可完成授权。

这点很重要以至于要单独拿出来说，因为免费计划 API Tokens 只能创建 50 个，也就是你只要授权 50 次，就会报错：Quota limit exceeded, you can create no more than 50 tokens.：

授权报错

因此虽然 Tunnel 限制数量为 1000²，但是按默认流程配置，创建 50 次就超过 API Tokens 的限制数量了。

然而经测试，仅在使用 Cloudflared Cli 操作账户，例如添加、删除 Tunnel 时需要使用到授权，因此添加完隧道、获得了隧道的 <uuid>.json后就可以在 Cloudflare 控制面板 中删除该 API Token。

根据进一步测试，授权下载的cert.pem事实上是可以共用的，因此登录一次，保留此次的 API，之后直接粘贴之前获取的cert.pem就可以了。

然后创建隧道：

cloudflared tunnel create <YOUR_TUNNEL_NAME>

会获得一个 Tunnel UUID，例如aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee，和 包含 Tunnel 密钥等信息的文件 /root/.cloudflared/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.json：

{"AccountTag":"YOUR_ACCOUNT_TAG","TunnelSecret":"TUNNEL_SECRET","TunnelID":"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"}

编写 Tunnel 配置文件 /root/.cloudflared/config.yml：

tunnel: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
credentials-file: /root/.cloudflared/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.json

ingress:
   - hostname: website.1.domain.com
     service: https://127.0.0.1:443
     originRequest:
        noTLSVerify: true  
   - hostname: website.2.domain.com
     service: http://127.0.0.1:8080
     originRequest:
        noTLSVerify: true
   - service: http://127.0.0.1:80
     originRequest:
        noTLSVerify: true

这里以三个ingress为例，含义分别是：

• website.1.domain.com 转发到本地的 443 端口，使用 HTTPS，跳过证书验证；
• website.2.domain.com 转发到本地的 8080 端口，使用 HTTP，跳过证书验证；
• 其他域名转发到本地的 80 端口，使用 HTTP，跳过证书验证。

其中noTLSVerify在使用 SaaS 域名时必须为true，因为验证的是回退源的证书，一定会返回错误。最后一项ingress必须写。

安装服务：

cloudflared service install

如果你修改了配置文件，需要执行：

cloudflared service uninstall
rm -f /etc/cloudflared/config.yml

卸载服务，然后再安装服务，配置文件才能生效。

然后，在面板中看到 Tunnel 状态为 Active：

启动成功

4、接入 SaaS 域名

4.1、本地管理型

在 DNS 记录中，把想要接入的域名指向 CNAME：aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.cfargotunnel.com，如果是 SaaS 域名，只能把回退源指向这个，此域下的所有 SaaS 域名都会走 Tunnel 回源。

4.2、云端管理型

参考：
Cloudflare SaaS 域名回源 Cloudflare Tunnel 的方法
https://www.nodeseek.com/post-98866-1

=======================================
1.正常接入SAAS,这块就不再赘述了。
2.tunnel绑定域名,在这个页面绑定域名的时候，打开浏览器F12进行抓包
内容正常写，域名选你SAAS绑定的那个域名。
点击提交后，在网络请求里找到 以 configurations 结尾的一个PUT请求。在请求上右键，复制为Curl命令，然后可以看到 –data-raw ” 这里面就是回源规则了

照着葫芦画瓢，新建一个ingress的子项，例如我的是这样
{
“service”: “http://umami:3000”,
“hostname”: “xxxx”
}
把外部cname到saas回源的主机名贴进去，其他的保证和原来的一致，保证JSON是正常的，然后执行这个curl命令，就可以了。现在外部cname那个域名也可以正常回源到tunnel了。
============================================

先F12打开 DevTools，然后随意添加一个域名：

添加域名

点击提交后，在网络请求里找到以 configurations 结尾的一个 PUT 请求，右键复制为 Curl 命令，复制出的--data-raw ''中就是前面的ingress配置，按照上文说明，对配置文件稍作修改并提交，就可以在面板中看到新增的域名。之后 CNAME 等步骤同本地管理型。

5、后记

普通请求经过 Cloudflare CDN 的路由如下：

客户端 -> 离客户端最近的 Cloudflare 节点 -> 服务端

如果你不是较高级计划，分配到的可能甚至不是最近的 Cloudflare 节点。例如中国大陆和台湾访问 Cloudflare Free 计划的域名，命中的都是美国节点。

Cloudflare 的 Argo Smart Routing 可以实现以下路由：

客户端 -> 离客户端最近的 Cloudflare 节点 -> 离服务端最近的 Cloudflare 节点 -> 服务端

这样相当于在回源过程中，国际互联部分由 Cloudflare 完成，客户端和服务端都只和最近的（甚至是本地的）Cloudflare 节点通信，对国际互联不好的节点而言有较大提升。

根据此原理，用香港入口转发日本、韩国、新加坡等地的服务器，延迟有略微提升（嗯，其实几乎没什么感觉）。另外，NAT 服务器用 Cloudflare 加速不再需要占用一条 Origin Rule，甚至服务器不开端口或者根本就没有公网 IP，也可以接入 Cloudflare，再也不用担心被 GFW 墙 攻击、扫描了。