Cloudflare on 寻 Mi 处

家里那台小主机没有公网 IP，我用 Cloudflare Tunnel 把它挂上了网

Thu, 29 Feb 2024 19:44:00 +0800

搬进新租的房子之后，第一件让我难受的事就是宽带没有公网 IP。

装机师傅上门那天我特意问了，他说现在都这样，上面统一做的 NAT，想开端口得另外找客服申请，而且就算申请下来也是动态的，重启光猫就换一个。我试着在路由器上拨号看了一下，WAN 口拿到的是 100.64.x.x，运营商级 NAT 的内网地址，彻底没戏。

问题是我家里有台常年开着的小主机，跑着几个自己写的小服务。一个是用来看照片的相册，一个是给家里人用的备忘录，还有一个是给小孩做的手工课视频站。以前在旧房子那边有公网 IP，路由器上做个端口映射，出门在外随时能打开。现在全断了。

试过的几种方案

先说被排除的。

花生壳那类内网穿透我最早试过，免费版带宽小得可怜，而且域名是一长串随机字符，发给家里人他们根本记不住。付费版按年收费，我看了一眼价格，不如直接买台有公网 IP 的 VPS。

frp 我用了差不多一年。自己在香港买了台 1 核 1G 的小机器当跳板，家里跑 frpc，外面跑 frps。能用，但有几个麻烦。跳板机的带宽是个硬瓶颈，我买的那台是 30M 峰值，实际晚上跑起来经常掉到 5M 以下，看个视频就卡。而且这台机器我得自己维护，系统更新、证书续期、被扫了还得上去看看，一年下来也是一笔精力。

后来在 V2EX 上看到有人提 Cloudflare Tunnel，我一开始以为是那种要企业套餐的付费功能，点进去看了才知道，免费版也能用，而且不限流量。这个就值得试了。

它到底是怎么工作的

原理说起来很简单。

cloudflared 这个程序装在你的内网机器上，它主动往外连 Cloudflare 的边缘节点，建立一条长连接。这条连接是出站的，所以你不需要有公网 IP，也不需要动路由器上的任何设置。外面的人访问你的域名，请求先到 Cloudflare，Cloudflare 顺着这条已经建好的隧道把请求送进来，你的机器响应之后再原路返回。

因为隧道是 cloudflared 主动发起的，中间不存在任何入站端口，家里的防火墙和运营商的封禁都不受影响。

还有个好处是，你不需要在路由器上开任何端口。以前做端口映射的时候，我总担心哪天路由器固件有漏洞被人扫到，现在这条路直接堵死了。

装起来

我的小主机是 Debian 12，直接加官方源装最省事。

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared

装完 cloudflared --version 能出版本号就行。

接下来登录。这一步会给你一个很长的链接，你得复制到浏览器里打开：

`1`	`cloudflared tunnel login`

浏览器里会让你选一个域名授权。我的域名在 Cloudflare 上托管，选它，然后它会自动在你的 DNS 里加一条 cert.pem 用的授权。授权文件落在 ~/.cloudflared/cert.pem。

注意这个 cert 是按域名授权的，一个域名一个文件。如果你有多个域名都要用，得分别登录一次。

创建隧道和配置

`1`	`cloudflared tunnel create homelab`

它会生成一个 UUID，并且在 ~/.cloudflared/ 下面放一个同名的 json 文件，里面是隧道的凭据。这个文件是密钥，别传 GitHub 上去。

然后写配置文件，位置在 ~/.cloudflared/config.yml：

tunnel: homelab
credentials-file: /home/mingyue/.cloudflared/8f3c1a2b-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

ingress:
  - hostname: photo.mibase.top
    service: http://127.0.0.1:8081
  - hostname: note.mibase.top
    service: http://127.0.0.1:8082
  - hostname: craft.mibase.top
    service: http://127.0.0.1:8083
  - service: http_status:404

ingress 是从上往下匹配的，最后那条兜底必须写，不然配置检查会报错。

还有一个细节，如果你内网的服务绑的是 0.0.0.0，用 127.0.0.1 也没问题。但如果服务只监听 IPv6，就得写成 http://[::1]:8081。

把 DNS 指过去

1
2
3

cloudflared tunnel route dns homelab photo.mibase.top
cloudflared tunnel route dns homelab note.mibase.top
cloudflared tunnel route dns homelab craft.mibase.top

它会自动在 Cloudflare 里加 CNAME，指向 <UUID>.cfargotunnel.com，并且是橙云状态，也就是走代理。

这三条加完，DNS 那块就不用手动动了。

跑成服务

前台跑着测试没问题之后，换成 systemd 托管：

1
2

sudo cloudflared service install
sudo systemctl enable --now cloudflared

然后看状态：

1
2

sudo systemctl status cloudflared
sudo journalctl -u cloudflared -f

日志里能看到四条连接建起来的信息。Cloudflare 默认会建四条，冗余用的，一条断了另外几条顶上，切换的时候用户基本无感。

访问控制和登录验证

隧道跑通之后，第一个冒出来的念头是：这玩意儿是不是谁都能访问。

是的，默认就是公开的。所以我立刻去配了 Cloudflare Access。

在 Zero Trust 后台里，Access 下面的 Applications，新建一个 Self-hosted 应用。域名填 note.mibase.top，然后建一条策略，Action 选 Allow，Include 里选 Emails，把我自己和家里人的邮箱填进去。

配完之后再访问，会先跳到一个 Cloudflare 的登录页，输入邮箱收验证码，通过了才放行。免费版给五十个用户，够用了。

给小孩看的视频站我没加验证，那个本来就是想分享给亲戚的，加了反而麻烦。

顺手做的一件事

既然流量都过 Cloudflare 了，缓存规则也可以顺手配上。视频站的封面图我设了一年的 Edge TTL，这样重复访问基本不消耗回源带宽。

这个和博客那边是同一套思路，静态的东西缓存长一点，动态的别缓存。

和 frp 比到底差在哪

用了一个多月，我的感受是这样的。

带宽上 Cloudflare 明显强。它是全球任播，国内访问会落到就近的节点，实际测下来晚上也能跑满我家的上行。frp 那台跳板机受限于单机带宽，这点没法比。

省心程度上也是 Cloudflare 好。跳板机不用自己维护，证书它帮你签，系统补丁不用管，被打也不用管。这一点对我这种懒得折腾的人来说很重要。

但也不是没代价。

延迟会比直连高一些，毕竟多绕了一层。我在家用局域网访问，走的是本地地址，没影响；在外面访问大概多二十毫秒，日常用感觉不出来，但如果你要跑远程桌面，那点延迟是能感觉到的。

另外就是把一部分控制权交出去了。域名、证书、访问日志都在 Cloudflare 那边。真要哪天它改政策或者涨价，迁移的成本不算低。所以我一直保留着 frp 的配置没删，算是个备份方案。

还有一点，免费版对 WebSocket 的支持是有的，但长连接有时候会被掐。我那个相册里的实时同步功能就偶尔断，后来改成轮询才稳定下来。

遇到的两个坑

一个是 cloudflared 的内存占用。这东西跑久了会慢慢涨，我有一次看它吃了 400 多兆。后来加了个定时重启，每天凌晨重启一次，问题就没了。官方 issue 里也有人反馈过，看起来还没彻底修。

另一个是回源协议。我的服务是 http，如果 service 写成 https://127.0.0.1:8081，会报 TLS 握手失败。改成 http:// 就好。这个错我当时找了半天，因为日志里只写了个 502，没提 TLS。

现在的情况

三个服务稳定跑了一个多月，家里人也习惯了直接输域名访问，不再问我"那个链接是多少"。

回头看，这件事最舒服的地方不是技术多新，而是它把一件需要长期维护的事情变成了不用管的事情。以前跑 frp，我每个月至少要看一眼那台跳板机，现在这块彻底从我待办里消失了。

给 Cloudflare 配上缓存规则之后，博客的图片终于不用每次回源了

Mon, 05 Feb 2024 02:45:00 +0800

域名托管到 Cloudflare 有一段时间了，页面打开速度一直说不上好。白天在公司摸鱼的时候打开自己的博客，首屏的图片总是一块一块地往下蹦，像是网速被谁掐了一半。

打开 F12 看 Network，问题挺明显的。那些几十 KB 的封面图，每一张的响应时间都在三百毫秒往上，而且不管我刷新多少次，它都是这个速度。点开 Response Headers 一看，CF-Cache-Status 是 MISS，有时候干脆是 DYNAMIC。意思很清楚，Cloudflare 根本没帮我存，每次都是它跑回我的 VPS 拿一遍，再转手给我。

我这才认真去看了它的缓存逻辑。

默认只缓存一小撮东西

Cloudflare 的免费套餐对缓存是做了限制的。它只对一部分后缀名有默认缓存行为，比如 css、js、图片、字体这些。听起来好像我需要的都在里面，但实际上还有一个坑，就是缓存时长很短，而且第一次请求之后 Edge 节点上存不存、存多久，还要看源站给的 Cache-Control。

我的 Nginx 那时候配置得很随便，静态资源只写了 expires 7d，别的什么都没管。Cloudflare 拿到这个头，就按七天存。听着还行，可我博客的图换了之后，七天之内访客看到的还是旧图，这个体验很别扭。

后来我把思路理清楚了。图片、字体、css、js 这些东西带上内容指纹，改一次文件名就变一次，这种资源可以放心地缓存很久，甚至一年。HTML 不行，HTML 一改就得让用户立刻看到新的。

换成 Cache Rules

网上很多老教程还在教你用 Page Rules。这个功能 Cloudflare 从 2023 年就开始推着大家迁走了，免费套餐能建的条数也少，表达式写法也老旧。现在应该用的是 Rules 里的 Cache Rules，逻辑更清楚，条件可以写得很细。

我进控制台，左边找到 Rules，点 Cache Rules，Create rule。

名字随便起，我写的是 static-assets。下面 When incoming requests match 那里，选 Custom filter expression，然后填：

`1`	`(http.request.uri.path.extension in {"jpg" "jpeg" "png" "gif" "webp" "svg" "ico" "css" "js" "woff" "woff2" "ttf"})`

这个写法比老教程里那种一串 contains 拼起来要干净得多，它是直接判断路径后缀。

Then 那部分做这些设置：

1
2
3

Cache eligibility: Eligible for cache
Edge TTL: Ignore cache-control header and use this TTL -> 1 month
Browser TTL: Override origin -> 1 month

Edge TTL 是 Cloudflare 自己节点上存多久，Browser TTL 是告诉访客的浏览器存多久。两个都拉长，命中率才上得去。免费套餐的 Edge TTL 最长就是一个月，够用了。

这里有个细节值得说一下。如果你选的是 Use cache-control header if present，那 Cloudflare 就会听源站的，你 Nginx 里写 7 天它就是 7 天。想让 Cloudflare 说了算，就得选 ignore 那一项。我第一次没注意，改完发现一点变化都没有，白折腾了半小时。

HTML 也可以缓存，但要小心

纯静态博客有个好处，HTML 也是构建出来的静态文件，没有数据库查询，缓存起来毫无压力。我另外加了一条规则，只针对 HTML：

`1`	`(http.request.uri.path.extension eq "")`

然后 Edge TTL 设成 2 小时，Browser TTL 设成 30 分钟。

为什么留这么短。因为我一改文章就得让人看到新的。两小时对我来说是个能接受的窗口，写完文章去 Cloudflare 那边手动 Purge 一下就行。如果哪天忘了 Purge，最多两小时也会自己过期，不至于一直挂着旧内容。

Browser TTL 我压得更短，是因为浏览器缓存最难清。用户本地存着的 HTML，你在服务器上怎么改他都不知道，只能等他缓存过期。30 分钟是个折中。

源站那边也得配合

只改 Cloudflare 不管源站，效果会打折扣。我在 Nginx 里把静态资源的响应头重写了一遍：

location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2?)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

immutable 这个值挺有用。它告诉浏览器，这个文件在有效期内绝对不会变，用户按 F5 刷新的时候不用再发一次条件请求。少了这个 304 往返，刷新页面的感觉会明显快一截。

前提是你的文件名得带指纹。Hugo 生成的 css 和 js 默认是带 hash 的，图片是我自己命名的，没带。所以我给图片加了个小约定，文件名后面缀上内容的前八位哈希，改图就改名，这样缓存一年也不会出问题。

验证到底有没有生效

改完之后别急着高兴，得实际去看。

最直接的办法是 curl：

`1`	`curl -sI https://blog.mibase.top/images/cover.jpg \| grep -i cf-cache`

第一次大概率是 MISS，这是正常的，节点上还没有。再跑一次，应该就变成 HIT 了。如果跑了好几次还是 MISS，那就回去看看规则的条件是不是没匹配上，或者 Cache eligibility 是不是还停在 Bypass cache。

还有一个 DYNAMIC，这个值的意思是 Cloudflare 认为这个请求不该走缓存。通常出现在 HTML 上，或者规则没命中。

我还注意到有个 REVALIDATED，那是源站返回了 304，Cloudflare 拿旧的继续用。这个状态其实也挺好，至少没重新传一遍完整内容。

命中率从四成到九成

Cloudflare 控制台的 Caching 下面有个 Analytics，能看到缓存命中率。我改之前是 41% 左右，改完第二天稳定在 92% 上下。

这个数字带来的变化是很实在的。以前国内访问我的博客，图片要绕到我的 VPS 上拿，VPS 在洛杉矶，一个来回就是两百多毫秒。现在大部分请求落在 Cloudflare 离用户最近的节点上，二三十毫秒就回来了。

还有一个连带的好处，源站的带宽掉得很明显。Cloudflare 后台显示回源流量少了七成多，我那台按流量计费的机器，账单也跟着降了。

几个踩过的坑

规则是有优先级的，同一个请求命中多条规则时，只有最上面那条生效。我一开始把 HTML 的规则放在最前面，结果图片规则被它盖住了，因为 HTML 那条的条件写得太宽。顺序一定要捋一遍。

Purge Everything 别乱点。它会把你所有节点上的缓存全部清掉，清完之后的一段时间里，所有请求都会压到源站上。我手滑点过一次，那一分钟 VPS 的负载直接飙到 8。后来我都是按 URL 精确 Purge。

还有 Vary 头。如果你的源站返回了 Vary: Cookie 之类的东西，Cloudflare 基本就不会缓存这个响应了，因为同一个 URL 对应太多变体。静态博客一般没这个问题，但如果你在 Nginx 里加过什么奇怪的配置，值得检查一下。

写在最后

这件事的性价比确实高。不用升级套餐，不用换服务器，只是把规则写对，速度就上了一个台阶。

我现在给静态站做优化的顺序基本固定了。先看资源有没有带指纹，再看缓存头怎么写，最后才去考虑 Cloudflare 那层。前面两步做扎实，CDN 才帮得上忙。顺序反过来的话，你在 CDN 后台点半天，源站一个 no-cache 就把你打回原形。