This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.Table of Contents
迁移原因
为什么要迁移：
（后半篇）🔗 [2025-08-28草稿（未发表） - Truxton's blog] https://truxton2blog.com/?p=16940&preview=true
🔗 [本站服务器将走向何方？（写于2023年1月） - Truxton's blog] https://truxton2blog.com/this-blog-next-deploy-plan-2023_jan/
🔗 [2025-09 CDN的各种候选 - Truxton's blog] https://truxton2blog.com/?p=17037&preview=true
测速工具
各种工具：
🔗 [Performance Test - Check URL Speed From Different Global Locations | KeyCDN Tools] https://tools.keycdn.com/performance
🔗 [HTTP Connectivity Test - Bunny Tools] https://tools.bunny.net/http-test
🔗 [ITDOG - 在线ping_在线tcping_网站测速_HTTP测速_API测速_路由追踪_在线MTR_DNS查询_ITDOG-云邦畅想] https://www.itdog.cn/
🔗 [拨测-免费的域名检测工具网-网站测速-ping检测-域名污染-域名拦截-dns查询-IPv6网站测试-路由跟踪查询-劫持检测-站长工具] https://www.boce.com/
🔗 [网站测速工具 - 站长工具] https://tool.chinaz.com/sitespeed/
DNS和SSL相关
以下内容按照时间顺序记录，即使是后面看起来很容易解决的问题，一开始也是耗费了相当多的时间
搞了个临时域名开始试验（静态网站）
修改nameserver搬到bunnyDNS上面
然后卡在各种SSL、http 504、CDN pull zone、A记录/cname记录的错误里
后来搞清楚了正确流程：
1，不需要在bunnyCDN里面手动创建cdn pull zone；如果使用bunnyDNS，则不需要碰cname解析相关的东西
2，先在bunnyDNS里面添加一条A记录，指向origin server IP；然后在这条A记录里enable cdn acceleration以后会自动创建一个对应的cdn pull zone
3，因为已经在第2步自动创建了一个cdn pull zone，所以现在去这个pull zone里面配置SSL
4，Add a custom hostname这个不用理
5，参考了🔗 [手动挡模式申请Let's Encrypt通配符证书 - jingsam] https://jingsam.github.io/2018/10/12/lets-encrypt.html 去服务器通过dns01 challenge的方法获取ssl证书，然后在bunnyCDN里面上传这个证书并enforce SSL
6，bunnyCDN貌似也可以自动申请自动续let's encrypt SSL CA，试了下确实可以，但还是去手动申请了通配符的let's encrypt
如果用的是其他nameserver，比如cloudflare DNS + bunnyCDN，则只需要将nameserver修改成cloudflare NS以后，在cloudflare里面添加cname记录（DNS only），指向bunnyCDN pull zone对应的xxxxx.b-cdn.net. 但我为了图省事还是用了bunnyDNS.
CDN Cache
先看看一些cdn cache问题
首先看看avif/webp变体的cdn cache问题（之前Azure CDN遇到了这个问题一时没有解决就缩回cloudflare了）：先用一个支持avif的浏览器访问png图片（实际上获得avif，然后这个avif被缓存在了CDN里面），然后用一个不支持avif的浏览器访问相同的图片，这个浏览器会得到avif，还是webp/png？如果只能得到avif就会出现显示问题，如此一来所有的图片都不能缓存在CDN上面了，必须访问origin server才行，否则会出大问题
万幸，bunnyCDN支持avif和webp的变体：
现在是2025年，连edge也支持avif了，要找到一个不支持avif的浏览器还不容易，万幸chrome提供了这个调试选项：dev tools -> more tools -> rendering -> disable avif/webp support
这样的话avif/webp的问题也解决了：先用一个支持avif的浏览器访问png图片（实际上获得avif，然后这个avif被缓存在了CDN里面），然后用一个不支持avif但支持webp的浏览器访问相同的图片，CDN会意识到手里缓存的avif不能用，所以会向源站请求webp（源站有nginx rewrite规则），请求到的webp也会缓存在cdn里；最后如果有一个不支持avif和webp的浏览器访问相同的图片，CDN会意识到手里缓存的avif/webp都不能用，会向源站请求原图png. 最后在CDN cache里面会缓存3种图片：png, avif和webp，接下来（在缓存还没被挤下cdn cache之前）再有浏览器请求这张图片，就会自动获取cdn cache里面对应的avif/webp/png，不需要向源站请求，直到这张图片被挤出cdn cache.
如果开启了perma cache，会看到这张图片在perma cache里面有存储3个不同的版本（第一张是png，第二张是webp，第三张是avif）：
Perma Cache
接下来就是看perma cache
在🔗 [Cache WordPress HTML at BunnyCDN - Gulshan Kumar] https://www.gulshankumar.net/cache-wordpress-html-bunnycdn/ 看到了作者极力不推荐开启perma cache：
如果把这篇文章读完就会发现，不推荐perma cache的原因之一是“perma cache无法绕过”。但如果搜到了这篇文章：🔗 [How to Set Up Object Caching and Full Site Delivery with Bunny CDN | BoldGrid] https://www.boldgrid.com/support/w3-total-cache/bunny-cdn-setup/ 会发现perma cache是可以绕过的。大概是因为gulshankumar.net的那篇文章是2年前的了，当时可能perma cache刚刚推出，确实没有对应的规则绕过。但无论如何，现在已经可以了：
所以虽然没有上wordpress实测，但目前看来wp-admin那些动态的东西是完全可以绕过perma cache的，不用担心。所以现在又回到了测试perma cache使用方法的话题上（主要研究能在perma cache上面提前存储哪些东西，以及这些东西如何preload）
接下来就遇到了一堆perma cache的狗屎设计挡住了我的理想计划。
我理想中的使用方式是：把wp-content的所有文件（除了.php）都丢到perma cache上面去，每张图片也有原图/webp/avif三个版本，这样再加上html的缓存，本站应该是可以做到～100%内容由CDN缓存提供了。写个脚本，每次更新站点以后删除并preload所有perma cache里的html，然后用rsync把最新的wp-content/*也同步过去。
遇到的问题1：FTP服务器，配上感人的cache purge机制
- perma cache文件服务器并没有rsync只有FTP而且速度很慢
- 如果purge (all) cache，会同时清空cdn cache和perma cache，目前找不到绕过的方法，甚至先卸载perma cache再cache purge再挂载perma cache的方法也不行
- purge all cache以后perma cache的老文件夹不会被删除而是会产生一个新的，但目前找不到什么方法把老文件及里的wp-content/*里面的文件转移到新文件夹里去（不支持mv这样的操作）
- 按链接清理url cache的速度很慢，平均一个链接响应3～4秒，虽然这个过程可以异步，但感觉还是怪怪的
- 综上，就算好不容易在perma cache里面存放了整个wp-content/*，只要触发了purge all cache，一切都要从头再来
遇到的问题2：perma cache里存储的webp/avif图片的文件名无法直接计算。
就以这张图片为例，
那个variation以后的字符串我到现在都没能猜出是用什么方法计算的。根据官方文档，这个文件名可以是MD5，但我算出来的MD5怎么样都对不上。一问bunny的客服才知道这玩意大概率是变成了带salt的哈希，目的就是为了不让我们直接上传avif/webp文件而是通过用户https访问以后服务器生成（这个理由真的很烂）。
这样就断了我的另一个曲线救国的方法（单独制作一个perma cache的wp-content镜像里面存有正确文件名的各种静态资源，每次purge cache以后用freefilesync同步过去）
遇到的问题3：带有严重延迟的perma cache.
按照官方的说法，即使是第一次访问（cdn + perma cache MISS, origin server pull），perma cache的存储也是异步进行的，不会影响实际性能：
但实测下来发现并不是这样。比如一张图如果直接bypass perma cache从源站拉取，延迟可能是250ms；打开perma cache，首次访问的延迟就变成了1秒甚至更高，说明perma cache的加入让一张图片的首次访问延迟增加了大概600~1000ms，说白了就是恶心第一个访问的人。大流量站点可能不在意这个（高延迟比例大概是1比几千几万），但对于我这种个人博客来说，如果没有preload机制提前把这张图片放进perma cache，那么第一个访问的人就会吃到高延迟，还没访问几个人就遇上了我的博客更新导致perma cache全清，接下来访问的第一个人又会吃到高延迟，高延迟比例可能就是1比个位数。
所以说要想把图片提前塞进perma cache，只有1个方法：用curl https这个图片，而且要3次（分别获取原图，webp和avif）。但这个成本实在太高了，我有好几个G的图片而且一贯奉行原图不压缩准则，curl的时候这些图片都要走CDN流量的，一次preload就是0.05美元，太亏了（我平时真的很喜欢preload）。而且这么多图片要丢进perma cache目前看来整个preload过程可能要～10分钟，好不容易搞完了一次preload可能过一会又要删了重来，感觉太浪费资源了（而且这么算的话perma cache一个月要花1.5美元甚至更多）
线路
最重要的perma cache搞得差不多了（有些东西可能就是没法做得很完美），决定多观望几天看看还有没有别的问题，最后再来决定是否迁移主站。
这几天主要是看线路、延迟、绕路的一些问题
线路感觉也就那样，中国出口的线路就不提了都是普通的线路，值得注意的是经常有绕路欧洲的现象发生（中国->美国->欧洲->美国->LAX）。感觉要么是我当前的机房线路不行，要么是bunny PoPs的机房线路不行，经常涉及到AS1299这个绕路欧洲的BGP.
在各种速度测试网站里测试全球连接的速度，最后得出的结论就是：
（在html/css/js已经上了perma cache的情况下）除了中国大陆，其他地区访问都很快很快，大概率<=100ms
中国大陆地区的访问速度基本是和cloudflare免费版一个水平甚至还要更慢，如果解析到bunny日本机房则大概率被block. 至于cloudflare partner那确实是线路更优秀（同一个出口节点，目标都是LAX，到了美国以后bunnyCDN大概率去欧洲绕一圈再绕回美国LAX，而cloudflare到了美国就直接去LAX了）.
开始迁移本站
开始迁移本站！
很不幸还是踩了几个雷
由于之前在cloudflare的dns TTL时间是Auto而不是最短，所以修改bunny nameserver以后很长一段时间（大概一个小时）都没办法刷出正确的解析。偏偏我开局就急着用DNS01 challenge去拿证书，这下直接卡死在这一步了，无论怎么刷新1.1.1.1/8.8.8.8的dns缓存就是没法读到正确的acme-challenge.
其他的问题还有一堆nginx SSL配置的问题和cache bypass的问题，毕竟wordpress动态站点要比我测试用的临时静态站点更复杂，很多bunny edge rules之前也是没有准备仅仅脑补这么写能行
缓存策略和新的preload流程
接下来是preload的配置：
保留了之前的nginx fastcgi（这样在接下来的curl https这一步就能使用更多的线程，以尽可能快的速度preload到prema cache）
除了全站html以外，还挑选了大约60MB的wp-content目录下的静态资源文件（基本上就是css/js/woff2那些，排除了图片和多媒体文件），用多线程curl https的方法访问，把这些文件全部丢到perma cache（当然同时也会存放在cdn cache里面）。所以perma cache的空间消耗大概就是~100MB.
最后总结一下配置好的本站缓存策略：
html：cdn cache, perma cache，浏览器不缓存，提前preload到perma cache和cdn cache
js/css/woff2等少部分重要静态资源：cdn cache, perma cache，浏览器缓存，提前preload到perma cache和cdn cache
png/jpeg/webp/avif：cdn cache（随缘）, bypass perma cache，浏览器缓存
mp3/mp4/pdf/wav等不那么重要的静态资源文件：cdn cache, perma cache，浏览器缓存，但不提前preload到perma cache/cdn cache
