WARNING: This article may be obsoleteThis post was published in 2021-11-28. Obviously, expired content is less useful to users if it has already pasted its expiration date.
Table of Contents
2021
从2021-08的网站迁移结束后开始记录：
把mariaDB的连接方式设置为unix socket：
$ lsof -U | grep mysql然后修改配置文件
// wp-config.php
define( 'DB_HOST', 'localhost:/path/to/mysql.sock' );对速度的提升可能肉眼看不出来，但无论如何，从理论上来看这都是稳赚不赔的设置。
似乎和MySQLTuner-perl给出的建议不同，MariaDB建议用户加大对 table_open_cache 的资源投入（见：https://mariadb.com/kb/en/optimizing-table_open_cache/）。按照MariaDB的建议，我把 table_open_cache 设定为2000，观察一段时间后发现这个数值设定的还不错。所以目前我的设置仍然为： table_open_cache=2000 .
效仿NGINX FastCGI，我把Autoptimize的缓存目录（默认为/wp-content/cache/Autoptimize）也挂载为tmpfs RamDisk了。
$ sudo mount -t tmpfs -o size=100M tmpfs /path/wp-content/cache后续更新：由于新服务器内存吃紧+Autoptimize缓存目录占用空间不可控，决定还是回归普通的磁盘存放文件。
由于使用了CloudFlare作为CDN，现在需要使用NGINX Module ngx_http_realip_module获取真实IP（否则只能获取到CloudFlare节点的IP）：
首先要确定NGINX安装了ngx_http_realip_module模块：
$ nginx -V 2>&1 | tr ' ' '\n' | grep --color realip然后添加这段配置文件（添加在http{...}里面）：
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
#use any of the following two
real_ip_header CF-Connecting-IP;
#real_ip_header X-Forwarded-For;参考：https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs
尝试从MathJax 2.7.9换到Katex 。得益于我显著区分了4个delimiters，仅仅对.sql使用简单的 sed 命令就完成了全站切换。Katex总的来说还算满意，能兼容MathJax 2的 \\ 换行写法，但我最后还是换回了MathJax——我喜欢SVG。
LightBox插件的更换：我曾经抱怨过WP官方插件市场没有100%让我满意的LightBox插件。之前我一直在用Lightbox with PhotoSwipe，但现在突然找到了更好的选择：
ARI Fancy Lightbox – WordPress Popup
太好了！
后续更新：我还是用自己写的代码换下了这个插件，使用fancybox 3.5.7，具体原因见：2021-12-12
尝试从MathJax 2.7.9换到MathJax 3.2.0 . 只需要修改一些配置文件就可以迁移了，但是——非常遗憾，MathJax 3至今都没有搞定 \\ 作为line breaking的功能，见：https://github.com/mathjax/MathJax/issues/2312 . 所以我又回退到了2.7.9 。
我发现我一直在使用的codemirror插件体验很差（主要体现在横向滑动条上：横向滑动条会乱动），只能把warp long lines设置为yes .
如果codemirror的问题一直没有解决，我就需要继续寻找能够全屏、能够复制代码、最好使用（prismjs或highlight.js或codemirror）渲染库的插件。目前只找到一个比较满意的，但可惜它和theme绑定了：https://github.com/mashirozx/sakura
自从发现了https://github.com/mashirozx/sakura有关全屏显示的代码也“不算太难模仿”以后，我越来越无法忍受codemirror糟糕的设计了，终于我还是花了一大堆时间进行了一次整站迁移，包括修改Prisma的代码以及迁移所有的文章内容。
出于合并http请求、合并JS文件的强迫症（虽然这些东西在HTTP/2时代已经没有用了），我还是从MathJax 2.7.9换到了MathJax 3.2.0 ，花了一些时间迁移MathJax的换行符，把所有 \\ 改为 \displaylines{} 或 \begin{gathered}...\end{gathered} ，见：
在MathJax 3里，原本需要逐个http请求的一大堆JS文件现在合并成了一个tex-svg.js（1.6M）.
添加了对SVG的支持，使用插件：https://wordpress.org/plugins/svg-support/
尝试使用nginx配置： gzip_static on; ，但一直没有想出很好的后续方案（因为Cloudflare的自动gzip和brotli，以及自动缓存js, css文件），所以思考到最后我干脆把nginx gzip关了：
gzip off;这样可以进一步降低cpu负荷：反正无论我怎么改，Cloudflare都会给我的结果蒙上一层gzip/br压缩传输。不如不压缩，全部丢给Cloudflare来处理。
花了很多时间（又一次）去搞Critical CSS：这一次因为有root权限，打算直接在服务器上跑nodejs critical，但搞了很久最终还是放弃了：
1，Nodejs critical真的很慢，如果要对每个页面都跑critical那恐怕到了下一次purge and preload的时候都未必能跑完...
2，FastCGI生成的缓存html文件并不是100% html：文件的开头有一段FastCGI自己标示的数据块。所以critical CSS生成的html是没办法直接替代FastCGI的 .
出于好奇心，再次尝试了一次Redis/Memcached相关的东西，效果依旧：尽管查询次数降了大概2/3，但preload的总体时间并没有降低（反而升高了一些）。
关于url trailing slash，见：https://searchfacts.com/url-trailing-slash/
尽管Google一视同仁地对待两种url写法，但作为个人，总是想跟着大公司/集体潮流/大众用户偏好...来设置。
因为 Yoast, RankMath, ahrefs 等SEO网站也都使用了trailing slash风格，所以本站将保持原有trailing slash习惯不变。
关于Mysql/Mariadb query_cache
很多（年代久远的）Wordpress优化相关的中文博客会建议开启 query_cache_size ；
但是，我似乎看到近几年很多stackexchnage社区问答建议不开启 query_cache_size ，所以我也一直设置 query_cache_size=0 。今天偶然又想到了这个问题并且去尝试了一下，发现开启 query_cache_size 能缩短整站preload的时间，这可能和本站的缓存习惯有关（局部修改、全体清除、集中资源一次性preload所有缓存：就像hexo/hugo等博客框架的 编译全站markdown 一样）。所以决定使用以下设置：
query_cache_size = 64M
query_cache_limit=3M在开启了 query_cache_size 以后，本站的平均页面生成时间（cpu负载100%）分布如下：
代码基于WordPress cache preload code (python3)，默认为2个线程。
但是对比一年前的记录来看，似乎还远远达不到一年前在腾讯云服务器上的水平，不知道到底是自然现象还是某个优化细节没注意到。
一年前的记录：（单线程）不同环境下的wordpress页面生成时间测试，如果使用litespeed server，大多数页面都是0.05~0.06秒生成的；即使使用apache/nginx，大多数页面生成时间也能在0.2秒左右。
2021-10-08：时隔接近一年，我再次用New Relic检查了一遍我的Wordpress环境，但没有发现什么特别异常的地方。想来想去总是觉得不太对，所以我把我的PHP彻底卸载并重装了一遍（和过去使用几乎一模一样的配置文件），突然之间页面的生成时间就降了一半：
懒得分析原因了，总之回到了原有速度。
2021-10-09：昨天无意中让PHP速度回到了正常水平，今天出于强迫症我还是选择重装系统，把NGINX, MariaDB和PHP换成了自己编译的版本（之前用的是编译好的安装包）。
2021-10-10：了解了一下HTTP/3和QUIC，所以希望本站也能支持这个新协议。Cloudflare提供了选项让我决定是否开启HTTP/3：
但这还不太够，我希望我的源站到Cloudflare edge server也能走HTTP/3协议。我开始学习并编译quiche:
GitHub - cloudflare/quiche: 🥧 Savoury implementation of the QUIC transport protocol and HTTP/3
同时在本地编译支持HTTP/3协议的 curl .
编译总体挺顺利，只是可惜目前官方只放出了Nginx 1.16.1的版本，有点落后进度了。但是到了套CF的时候，我发现无论我怎么努力，Cloudflare就是套不进我的HTTP/3 Nginx服务。后来我终于发现了不对：
看来努力是白费了。但这也让我发现了新的好处：因为从Cloudflare Edge到源站只支持 HTTP/1.1 ，所以（可能）传统的合并JS、CSS文件的优化方法还能继续使用。
2021-10-11：把MariaDB升级到 10.6.4 ，然后跑了3遍preload.py，平均页面生成时间又降了 0.01~0.02 。（当然这有可能是vps cpu频率浮动导致的）
2021-10-11：参考这篇文章：python - Making an executable in Cython - Stack Overflow，我把之前写的一个preload.py用cython和gcc编译成了可执行文件：
编译方法：（注：需要python3-devel；如果cython版本不为3.x，可能还需要把 --3str 参数去掉）
$ cython --embed --3str -o preload.c preload.py
或者
$ cython --embed -o preload.c preload.py
$ gcc -Os -I /usr/include/python3.6m preload.c -lpython3.6m -o preload运行时间提升如下（同一站点）：
修改前：preload.py运行时间大约为29~30s
修改后：preload运行时间大约为22~23s
实际情况：使用了一个月，并没有发现明显的性能提升
2021-10-15，有关我部署本博客的VPS：
3天前由于一时手贱，我不慎删掉了centos系统里的 site-packages 文件夹，后来干脆决定重装系统，试试其他的发行版。我决定使用 debian 11 作为新的OS，但却遇到了最为麻烦的事情：明明我的软件版本、各项设置都和之前的centos一致，但我的 平均页面生成时间 莫名其妙变高了：之前好不容易降到 0.21~0.22(s) ，现在却变成了 0.25~0.28(s) ，多次重装系统、重新编译都没有改善。最终我换回了centos，（尽管还是用相同的配置文件）指标又重新回到了之前的 0.21~0.22(s) 水平。
原因还没有搞明白，但不想再搞多次试验了（重装系统+重新编译等步骤通常要好几个小时），先这样吧==
后续更新：搞明白了，是编译pycurl惹的问题。见：🔗 [PycURL的性能取决于安装方法和编译依赖 - Truxton's blog] https://truxton2blog.com/pycurl-performance-differs/
2021-11-09：给mariadb升级到10.6.5（还是不敢尝试10.7.1 RC），nginx版本升到1.21.4
2021-11-15：用flask, fastapi和gofiber三种不同的框架编写同一个rest api后端服务，用loader.io测试了一下：gofiber的性能确实非常优越（高压力测试下的平均响应时间大概是fastapi的1/3）。尝到了golang的性能甜头以后我开始尝试使用golang重写一些之前用python写过的工具，比如 preload.py 。可惜短时间内没能学会goroutine的并发控制和golang屎一样的regex（不支持pcre！！！），这个计划暂时搁置了。
尽管golang重写的计划流产了，但还是对原来的代码进行了一些性能提升：比如对一串很长很长的字符串执行regex查找之前，可以用 str in text 这样的代码先判断是否存在。🔗 [python - What's a faster operation, re.match/search or str.find? - Stack Overflow] https://stackoverflow.com/questions/4901523/whats-a-faster-operation-re-match-search-or-str-find
11.23~11.26：在Vultr上面开了台机器，针对“本站在不同Linux发行版上的性能”做了几天娱乐测试，见：
2021-12-01：给preload.py换了一套执行逻辑：
修改前：
删除整个NGINX FastCGI缓存文件夹->执行preload.py
修改后：
删除单个url对应的FastCGI缓存文件->重新生成FastCGI缓存文件->操作下一个url ...
url和FastCGI文件的换算方法见：【半成品】NGINX FastCGI purge and preload for single URL .
2021-12-12：
我用代码换下了https://wordpress.org/plugins/ari-fancy-lightbox/，主要原因：
原插件的Fancybox 3版本略低；原插件加密了部分代码，导致很难在其基础上进行修改。
现在我把Fancybox升级到了3.5.7，并且对SVG的透明背景、thumbnail的排列位置等参数进行了调整。
2021-12-14：给pagination和每篇文章添加了←和→按键翻页的功能。
2021-12-15：效仿prism.js，给PDF.js嵌入页面添加了全屏按钮。
2022
2022-02-07：给nginx添加了pcre2和cloudflare-zlib的支持。pcre2可以下载官方release直接使用，cloudflare-zlib则需要git拉取并进行一点处理：
$ git clone https://github.com/cloudflare/zlib cf-zlib
$ cd cf-zlib
$ make -f Makefile.in distclean
# nginx编译参数里使用--with-zlib=/PATH/TO/cf-zlib2022-02-09：发现MariaDB发布了10.6.6，赶紧去编译更新了一份，结果今天就发现MariaDB把10.6.6临时取消回炉重做了（具体可见：🔗 [[MDEV-27789] mysql_upgrade / mariadb-upgrade in 10.6.6 is putting password in host argument - Jira] https://jira.mariadb.org/browse/MDEV-27789）
2022-02-14：升级到（修复了[MDEV-27789] bug的）MariaDB 10.6.7
2022-02-26：对本站数据库的压缩策略进行了调整：
调整前：有几个压缩率比较高的表使用了 PAGE_COMPRESSED = 1 ，但这些声明语句是MariaDB专有。
调整后：把上面提到的 PAGE_COMPRESSED = 1 全部去掉，但对 整个Wordpress数据库 采用了lz4算法的 InnoDB Page Compression 压缩：
[mariadb]
innodb_compression_default=ON
innodb_file_format='Barracuda'
innodb_default_row_format='dynamic'
innodb_compression_algorithm='lz4'具体可见：🔗 [InnoDB Page Compression - MariaDB Knowledge Base] https://mariadb.com/kb/en/innodb-page-compression/
现在整个数据库占用的存储空间大幅度降低（仅仅是原来的23.3%），但preload.py运行时间基本没有变化。
2021-02-28更新：经过几天的测试，我发现preload.py的运行时间稳定多了，比之前的表现（多次运行preload.py运行时间有30%~40%的差异）优秀太多。
2022-07-11更新：开启数据库全局压缩以后，所有表都会自动挂上PAGE_COMPRESSED=ON的表定义，这会导致mariadb mysqldump出来的数据库文件无法导入mysql（mysql不支持这个写法）。需要替换表定义里的特殊字段。见：🔗 [2022-07-12 - Truxton's blog] https://truxton2blog.com/2022-07-12/#有关MariaDB的page_compressed设置
2022-02-28：
更新了 JetBrains-Mono 字体，从v6更新到了v11
2022-03-01：
偶然发现pdf.js放出了更新，所以把本站使用的pdf.js升级到了 2.13.216 .
2022-03-03：
给网站添加了一个加载条：🔗 [PACE — Automatic page load progress bars] https://codebyzach.github.io/pace/
我使用了Cloudflare提供的pace app（替代了Wordpress代码加载），这样可以把pace.min.js推到html header的最顶端。
2022-03-16：
NGINX编译使用的openssl升级到了1.1.1n .
2022-04 ~ 2022-05：
NGINX编译使用的openssl升级到了1.1.1o；
MathJax升级到了3.2.1；
pdf.js升级到了v2.14.305；
mariadb升级到了10.6.8；
本博客开始对chrome和firefox浏览器优先提供avif格式的图片，对safari和edge浏览器优先提供webp格式的图片。见：🔗 [制作avifenc-butteraugli docker镜像 - Truxton's blog] https://truxton2blog.com/create-avifenc-butteraugli-docker-image/
2022-05-24：
第一时间升级到了Wordpress 6.0；
本站不再使用插件 webp converter for media .
2022-05-25:
意外发现nginx更新了1.22.0版本，现在本站使用openssl 3和nginx 1.22.0.
2022-05-26:
揪出了PycURL的严重性能损失：PycURL的性能取决于安装方法和编译依赖 - Truxton's blog (truxton2blog.com)
2022-05-27:
从php 7.4.29迁移到php 8.0.19，除了一个不兼容的插件（search regex）以外，其他的功能都正常运作。
开启了opcache-JIT，再加上昨天揪出的PycURL性能问题，现在FastCGI的预加载速度大幅度提升。
唯一需要注意的是：开启JIT以后，给opcache分配的内存大概需要提升0.5~1.5倍。
2022-06-06:
开启了全站 scroll-behavior: smooth .
（这个smooth scroll于2025-12-07由于性能不佳、影响TOC跳转而被关闭）
对本站JS/CSS进行减肥：不需要加载TOC、Popup Maker的一律dequeue，就像以前对 tex-svg.js 进行的操作一样。
2022-06-08:
MathJax升级到3.2.2.
2022-06-10:
php升级到8.0.20.
2022-06-22:
nginx openssl升级到3.0.4；
prismJS主题换成了coldark-cold；顺便修复了lang-css.js版本过老的问题。
2022-06-23:
本站之前部署在RHEL系linux上，imagemagick缺少对pdf的支持，上传的PDF没有preview thumbnail；
现在部署在Debian系linux上，可以生成pdf预览图了，重建了所有pdf preview thumbnail.
2022-06-29:
Nginx升级到 1.23.0 .
2022-07-06:
nginx openssl升级到 3.0.5 .
2022-07-07:
php升级到 8.0.21 .
2022-07-10:
认真考虑了一下本站到底该用什么方法来渲染嵌入PDF（目前有2种方法：浏览器原生支持，或者使用PDF.js）：
PDF.js / Firefox：目前使用的方法，但对部分重口味PDF的渲染效果不如chromium；
chromium原生：什么都好，就是不支持双指缩放；
Safari原生：锯齿过重，明显不如preview.app；
对比了不同PDF嵌入方案和渲染效果，还是决定继续使用PDF.js。具体对比内容见：🔗 [不同PDF查看器对PDF文件的渲染细节对比 - Truxton's blog] https://truxton2blog.com/different-pdf-viewers-render-effect/
2022-07-15:
libwebp升级到1.23
2022-07-19:
nginx升级到1.23.1
2022-07-28:
贼心不死，又一次向memcached和redis发起了preload.py时间测试。之前已经试过不止一次了，不知道为什么又要再来一次。
结果还是一如既往的失败，没有任何配置能打败sql query cache。具体结果见：🔗 [Memcached和Redis测试（preload.py） - Truxton's blog] https://truxton2blog.com/preload-py-memcached-redis-benchmark/
2022-07-31:
pdf.js升级到v2.15.349
2022-08-01:
preload.py新增逻辑：每次程序启动时都会先RESET query cache，然后再开始preload：这样也许能够提高一点sql让preload任务更加稳定。
同时，我把php-fpm的进程管理方式变成了on-demand.
2022-08-04:
php升级到8.0.22
* 更新：我注意到：（相同的配置文件）8.0.22的opcache缓存占用要比8.0.21小一些。（大概小6%左右）
* 更新2：我注意到：preload.py的速度要比以前快大约8% . 我猜测具体原因可能是：升级了php；RESET query cahce；php-fpm on-demand.
2022-08-06:
libwebp升级到1.24
2022-08-16:
Mairadb升级到10.6.9
2022-08-23:
prismJS升级到1.29.0
2022-08-28:
pdf.js升级到v2.16.105
2022-09-01:
php升级到8.0.23
2022-09-22:
Docker-avif使用的aom升级到3.5.0
升级了编译nginx使用的cloudflare-zlib
2022-09-30:
php升级到8.0.24
2022-10-11:
nginx-openssl依赖升级到3.0.6
2022-10-14:
Docker-avif使用的libavif升级到0.11.0
2022-10-20:
nginx升级到1.23.2
2022-10-21:
Docker-avif使用的libavif升级到0.11.1
2022-10-28:
php升级到8.0.25
2022-10-31:
pdf.js升级到3.0.279
2022-11-01:
编译nginx使用的openssl升级到3.0.7
2022-11-02:
本站升级到Wordpress 6.1，但升级后发现YARPP – Yet Another Related Posts Plugin直接罢工了。
解决方法是直接卸载这个插件了事。
其他功能似乎保持正常运作。
2022-11-04:
为了让nginx尽可能快速地随机读取硬盘小文件（主要是那些avif图片），我把 my.cnf 各项参数的数值基本上都砍了一半甚至更多（唯独保持了 query_cache_size = 40M 不变，因为这个太重要了），这样调整以后mariadb进程只占用了10%的RAM .
iowait是否真的改善了还有待查证，但很明确的一点是：preload.py性能完全没受影响，可见query cache的重要性。在此我又忍不住想要痛骂mysql 8.0移除了query cache的弱智决策。
2022-11-09:
mariadb升级到10.6.11
2022年11月：
陆陆续续折腾了一个月的nginx配置优化。 其实绝大部分“优化”工作都是在增大各种配置参数 ，我只是想让avif图片随机读取的速度更快一点！
2022-11-26:
pdf.js升级到3.1.81
2022-12-06:
nginx编译所使用的 PCRE2 升级到10.41
2022-12-03:
nginx编译所使用的 PCRE2 升级到10.42
2022-12-15:
nginx升级到1.23.3
2023
2023-01-01:
pdf.js升级到3.2.146
2023-01-05:
php升级到8.0.27
2023-01-13:
Docker-avif使用的libwebp升级到1.3.0
2023-01-24:
给PrismJS换了一个主题：🔗 [从零开始修改Dracula-PrismJS - Truxton's blog] https://truxton2blog.com/modify-dracula-prismjs/
根据highlightjs的git repo记录，highlightjs在2018年前后经历过一段断档，和现在PrismJS的处境极其类似...但好在后来highlightjs又找到了新的人接手，盘活了。现在PrismJS已经断气半年了，包括宣称“尚在开发中”的PrismJS v2也基本没动静...我再给半年的时间看看情况吧。如果真的死透了就切换到highlightjs那边去。
2023-01-29:
pdf.js升级到3.3.122，另外pdf.js的base64工具改成了postcss-url，详见：🔗 [pdf.js图标转换为base64格式 - Truxton's blog] https://truxton2blog.com/pdfjs-icon-to-base64/
2023-02-03:
从cloudflare-zlib切换回了普通的zlib .
2023-02-06:
mariadb升级到10.6.12
2023-02-07:
nginx编译使用的openssl升级到3.0.8
2023-02-08:
Docker-avif使用的aom升级到3.6.0
2023-02-14:
php升级到8.0.28
2023-02-20:
php 8.0寿命差不多到头了，准备考虑升级到php 8.1了，正在准备下一次全站测试
备注：2023-03-07测试完毕，应该是没有问题
备注2：后来又发现虽然没有error的问题，但有一堆warning的问题（都是wordpress core带来的），看着很不舒服，又降回来了。
2023-02-26:
pdf.js升级到3.4.120
2023-03-04:
好像是从去年开始，为了给avif/webp的硬盘读取速度让路（事实上这个思路似乎是有问题的），我把mariadb innodb buffer pool size 设置为一个很小很小的数值（32MB），但最近我发现我的wp-admin页面（包括那些登陆状态下的普通页面）打开得越来越慢。今天我把 innodb buffer pool size 重新设置成稍大一些的数值（128MB）：
解决了wp-admin页面打开速度过慢的问题；
avif/webp的小文件读取问题暂时丢在一边不管。事实上，Linux file cache应该不可能照顾到那些读取频率极低的非系统文件，升级服务器的硬盘配置才是硬道理。
2023-03-07：
本博客成功在php 8.1环境下运行，准备找个好时机迁移过去。
2023-03-07：
刚迁移到php 8.1就发现一堆warning，迁回php 8.0.28去了。
下次做迁移测试的时候还要多留个心眼注意一下debug.log .
2023-03-11：
使用WordPress-docker测试php 8.1环境下的Wordpress 6.2 RC1，这次没有Warning log了，所以不出意外的话本博客会在2023年3月底的时候迁移到php 8.1环境下的Wordpress 6.2 .
2023-03-14:
nginx编译使用的openssl升级到3.1.0
2023-03-19：
经过docker测试，Wordpress 6.2 beta在php 8.2环境下也能无error、无warning正常运行。但我目前计划的下一个php版本仍然是8.1 .
2023-03-28：
nginx升级到1.23.4
新的nginx有一个改动影响了我的配置文件：
*) Change: now nginx issues a warning if protocol parameters of a
http://nginx.org/en/CHANGES
listening socket are redefined.
所以我删掉了配置文件里重复定义的HTTPS配置项。
2023-03-29：
WordPress升级到了6.2，没有遇到什么问题。
过了3天后补充：我发现自从升级到6.2以后，运行preload.py所需要的mariadb query cache减少了整整4MB. 暂时不清楚这4MB是从哪里节约出来的。
2023-03-29：
WordPress升级6.2以后，我马上开始把PHP的环境从8.0.28升级到8.1.17，但最终还是没有成功。
使用的插件[Lazy Loader]在PHP 8.1环境下会出现deprecated warning.
还是要等一等，以后再考虑迁移吧。
2023-04-04：
pdf.js升级到3.5.141 有个恶心的报错，赶紧回滚到3.4.120去了
后续：
2023-04-06：这个恶心的报错确实是个bug，相关issue已经被解决但还没有放出下一个release，所以我简单修改了一下3.5.141的代码并开始使用这个版本。
2023-05-07：下一个release v3.6.172解决了这个问题。
2023-04-08：
过去1个星期我都在和fastcgi/tmpfs的一些机制周旋，试图优化当前的fastcgi访问速度。
如果问题能解决就写篇笔记回顾一下完整的过程以及尝试过的方案。
更新：最新的进度应该是：从tmpfs迁移到ramfs，并让nginx conf里的 keys_zone; max_size 管理fastcgi缓存文件夹的大小。
回顾笔记有待后续整理。
2023-04-11：
nginx 升级* 到1.24.0
*v1.24.0和v1.23.4的核心代码应该是一样的，只是从Mainline分支（1.23.x）变成了Stable分支（1.24.x）。
2023-04-14：
看到别人的Hexo博客有2个导航栏，我也想搞一个：
但是我在Wordpress插件市场找了一圈都没有找到一个特别适合自己的，所以干脆自己硬写一个好了：
在chatgpt的帮助下，本博客加入了一个新的导航栏：文章聚合！（没有文章聚合的时候会显示默认模版）
目前这些聚合在一起的文章id是手动一个一个 hard coding 到PHP代码里面去的，因为我实在是想不出什么特别好的方法省时省力，优化什么的以后再说吧。
2023-05-07：
pdf.js升级到3.6.172，之前的那个浮点数精度的问题解决了。
2023-05-12：
Docker-avif使用的aom升级到3.6.1
mariadb升级到10.6.13
2023-05-30：
pdf.js升级到3.7.107
2023-05-31：
nginx升级到1.25.0，编译nginx使用的openssl升级到3.1.1
2023-06-08：
mariadb升级到10.6.14
php升级到8.0.29
2023-06-13：
nginx升级到1.25.1
注意changelog提到了语法更变：" Feature: the "http2" directive, which enables HTTP/2 on a per-server basis; the "http2" parameter of the "listen" directive is now deprecated.".
所以需要修改配置语句：
listen (...) http2 (...) ;为
listen (...);
# 去掉listen里面的http2，单独拿出来作为http2 on
http2 on;在修改配置的过程中我还遇到了奇怪的 HTTP 421 Misdirected Request 问题，最后参考🔗 [amazon web services - 421 Misdirected Request using HTTP/2 and SAN SSL - Server Fault] https://serverfault.com/questions/772901/421-misdirected-request-using-http-2-and-san-ssl 解决了问题（在每个共享ssl证书的server里面都要写上 http2 on ; .
2023-06-30：
Docker-avif使用的libwebp升级到1.3.1，Docker镜像从Debian 11升级到Debian 12（Bookworm）
2023-07-02:
pdf.js升级到v3.8.162
2023-07-16：
本站从Debian 11升级到Debian 12
没有原地升级，老老实实开了个新的Debian 12服务器然后全站迁移过去的。
2023-07-16：
PHP 8.0系列EOF越来越近了，真的要考虑升级成php 8.1了
2023-07-22：
好久没用pdf-embed了，突然发现上传进去的pdf不给做缩略图了，赶紧到处乱回退版本试来试去（imagemagick支持的格式里面包含了PDF的，但不知道为什么pdf就是不给处理）
后来发现安装ghostscript就能用了： $ apt install ghostscript
但在去年的环境下（imagick 3.7.0，imagemagick 7.1.0-xx，Debian 11）我是不需要刻意安装ghostscript的，不知道为什么现在就需要了。
总之，当前（2023-07-22）图片处理那一套软件的版本为：imagick 3.7.0，imagemagick 7.1.1-13，Debian 12，ghostsciprt 10.0.0
2023-07-30:
pdf.js升级到3.9.179
2023-08-01:
nginx编译使用的openssl升级到3.1.2
2023-08-05:
php升级到8.0.30
2023-08-09：
升级到Wordpress 6.3
升级前后的nginx fastcgi数据对比：文章总数没有变化，但整体cache少了接近2MB，同时preload的时间少了2秒
暂时不知道是哪里减少的网页体积
2023-08-16：
nginx升级到1.25.2
2023-08-18：
nginx编译使用的zlib升级到1.3
2023-08-27:
pdf.js升级到3.10.111
2023-08-29：
发现libavif放出v1.0.0了，和aom v3.7.0-rc3一起编译通过了（原来的编译脚本和avifenc参数都能继续用）
等待aom v3.7.0正式版的放出
2023-09-01：
avif/webp Docker 版本升级：aom升级到3.7.0，libavif升级到1.0.1
2023-09-14：
avif/webp Docker 版本升级：libwebp升级到1.3.2
2023-09-19：
nginx编译使用的openssl升级到3.1.3
2023-09-27：
pdf.js升级到v3.11.174
2023-10-09：
之前遇到的「使用的插件[Lazy Loader]在PHP 8.1环境下会出现deprecated warning.」一直没有解决，考虑到php 8.0即将结束支持，升级是必须的了，所以我手动替换了html5-php的版本（之前出现warning的原因是插件[Lazy Loader]使用了较老的html5-php库，所以只需要把新的html5-php文件下载并覆盖即可），然后把php升级到了8.1.24
升级到php 8.1以后，preload.py的运行时间从php 8.0的57秒降到了50秒.
2023-10-24：
nginx升级到1.25.3；编译nginx使用的openssl升级到3.1.4
2023-10-29：
php升级到8.1.25
2023-11-05:
pdf.js升级到4.0.189 . 升级以后出现了类似 Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec. 的错误，解决方法是修改nginx的MIME配置文件：
application/javascript js;
# 修改为
application/javascript js mjs;2023-11-09:
wordpress-core升级到6.4.1 . 升级后出现了类似 PHP Deprecated: Function print_emoji_styles is deprecated since version 6.4.0! Use wp_enqueue_emoji_styles instead. 的报错，但考虑到这部分报错是由 wp-includes/functions.php 造成的，所以预计很快就会修复。
2023-11-13:
mariadb从10.6.5升级到10.11.6，尽管升级前在docker虚拟机里演练了很多次，但实战的时候还是出了意想不到的问题，lz4一直搞不定。后来终于解决了，见：🔗 [Mariadb 10.11 compression plugin的配置问题 - Truxton's blog] https://truxton2blog.com/mariadb-10-11-compression-plugin/
和之前的10.6.5看不出什么preload.py性能上的差别，两者运行的时间几乎一样，占用的query cache memory也几乎一样。
2023-11-18：
avif/webp Docker 版本升级：libavif升级到1.0.2
2023-11-21：
avif/webp Docker 版本升级：aom升级到3.7.1
2023-11-23：
NGINX编译使用的openssl升级到了3.2.0
2023-11-23：
php升级到8.1.26
写在2023-11-25：
不知道从什么时候开始，opcache占用的内存多了一点（明明我的插件数量很久没变化了），现在（在全站preload.py以及多数wp-admin页面访问以后）128MB的opcache内存已经占用107MB了（过去一般只有103MB到头）
后续：2024-01-03，把opcache分配内存增加到150MB.
2023-11-26：
pdf.js升级到4.0.269
2023-12-05：
avif/webp Docker 版本升级：libavif升级到1.0.3
2023-12-07：
avif/webp Docker 版本升级：aom升级到3.8.0
2023-12-22：
php升级到8.1.27
2023-12-31：
pdf.js升级到4.0.379
2024
2024-01-03：
发现opcache已经占用114/128 MB，是时候扩容了：现在给opcache分配了150MB内存。
（本站的wordpress插件已经差不多一两年没增加新的了，删插件倒是删了几个，只能说可能是全站.php代码量都有所增加导致的）
2024-01-23：
nginx编译使用的zlib升级到1.3.1
avif/webp Docker 版本升级：aom升级到3.8.1
2024-01-30:
nginx编译使用的openssl升级到3.2.1
2024-02-08：
mariadb升级到10.11.7
2024-02-08：
avif/webp Docker 版本升级：libavif升级到1.0.4
2024-02-14：
nginx升级到1.25.4
（2025-08-30：搞定了）和cloudflare origin server brotli（🔗 [All the way up to 11: Serve Brotli from origin and Introducing Compression Rules] https://blog.cloudflare.com/this-is-brotli-from-origin）战斗了几个小时，依然没搞定，但还是把nginx的brotli打开来放在那里了（在此之前我都是编译不含brotli的nginx程序）
2024-02-16：
nginx编译使用的PCRE2升级到10.43（终于出了）
2024-03-13：
avif/webp Docker 版本升级：aom升级到3.8.2
2024-04-04：
wordpress-core升级到6.5
一切正常，暂时没有发现什么问题
2024-04-09：
nginx编译使用的openssl升级到3.3.0
2024-04-12：
pdf.js升级到4.1.392
2024-04-13：
php升级到8.1.28
正在考虑7月份之前把本站迁移到php 8.2
现在不是最优先的任务了。因为最近php修改了EOL政策，使得php 8.1的security support延长了一年。
具体可以见reddit的讨论：🔗 [PHP 8.1 EOL has changed? : r/PHP] https://www.reddit.com/r/PHP/comments/1cgw0r2/php_81_eol_has_changed/
2024-04-16：
nginx升级到1.25.5
2024-04-23：
在nginx的日志里检查出了 Accept-Encoding: gzip, br ，说明edge-to-origin brotli已经开始逐步推广使用了，以后默认编译带有brotli的nginx.
avif/webp Docker 版本升级：aom升级到3.9.0，libwebp升级到1.4.0
2024-04-24：
nginx升级到1.26.0
2024-04-29：
pdf.js升级到4.2.67
2024-05-29：
pdf.js升级到4.3.136
nginx升级到1.27.0
2024-06-04：
编译nginx使用的openssl升级到3.3.1
2024-06-06：
php升级到8.1.29
2024-06-08：
nginx编译使用的PCRE2升级到10.44
2024-06-10：
avif/webp Docker 版本升级：aom升级到3.9.1
2024-07-02：
pdf.js升级到4.4.168
2024-07-17：
wordpress-core升级到6.6
2024-07-31：
avif/webp Docker 版本升级：libavif升级到1.1.1
2024-08-09：
pdf.js升级到4.5.136
2024-08-16：
nginx升级到1.27.1
2024-08-30：
avif/webp Docker 版本升级：aom升级到3.10.0
2024-09-03：
pdf.js升级到4.6.82
编译nginx使用的openssl升级到3.3.2
2024-09-29：
php升级到8.1.30
2024-10-03：
nginx升级到1.27.2
把maraidb query cache从40M增加到了50M.
2024-10-07：
pdf.js升级到4.7.76
mariadb my.cnf的max_allowed_packet从原本的1M提升到256M（我也不知道原本为什么会设置成这么小的一个数字）
mariadb从10.11.7升级到11.4.3，迁移过程中没有遇到什么问题，原本的mariadb编译指令以及my.cnf配置文件都可以直接用。
2024-10-13：
服务器的python环境从python 3.11升级到3.12（本站很多后台功能都是用python写的，比如这个基于python3的多线程WordPress缓存预加载代码
）
2024-10-17：
先是直接把mariadb query cache size从50M降到了10M（然后还尝试了1M和0M），具体原因和性能测试结果写在🔗 [Memcached和Redis测试（preload.py） - Truxton's blog] https://truxton2blog.com/preload-py-memcached-redis-benchmark/：
但是最后还是把query cache size设置回了50M，原因是：目前，服务器分配的内存完全没必要在这几十MB上面纠结。
可能等到以后query cache开销大了再考虑降低分配量吧。
2024-10-23：
nginx编译使用的openssl升级到3.4.0（过了几天降级回去了，见下面一条）
2024-10-27：
由于突然出现图片懒加载http 522错误（每一页笔记都会有随机几张图片中招），怀疑是最近升级的openssl 3.4.0搞的鬼，所以把nginx编译使用的openssl降级到3.3.2再观察一段时间试试。
2024-11-03：
pdf.js升级到4.8.69
2024-11-10：
关于前几天对nginx openssl版本的降级：今天又把openssl重新升级为了3.4.0 . 编译好了以后测试了几个页面发现貌似没有出现http 522错误了，准备再用几天看看是不是稳定。
2024-11-13：
wordpress-core升级到6.7.0
升级前后的fastcgi缓存大小完全一致，所以我认为前端方面应该是没什么变化
2024-11-18:
avif/webp Docker 版本升级：aom升级到3.11.0
2024-11-20：
nginx openssl 3.4.0用着还是怪怪的（没有出明显的问题，但体感一些页面响应时间增加），还是降级回openssl 3.3.2了
2024-11-21：
wordpress升级到6.7.1
2024-11-22：
php升级到8.1.31
2024-11-28：
nginx升级到1.27.3（openssl还是保持3.3.2不变）
2024-12-02：
pdf.js升级到4.9.124
2024-12-06：
pdf.js升级到4.9.155
2024-12-20:
avif/webp Docker 版本升级：libwebp升级到1.5.0
2025
2025-01-16:
pdf.js升级到4.10.38
2025-02-06：
nginx升级到1.27.4，编译nginx使用的PCRE2升级到10.45
2025-02-11：
编译nginx使用的openssl升级到3.4.1（没错，又一次尝试3.4.x的openssl）
avif/webp Docker 版本升级：libaom升级到3.12.0
2025-02-25:
avif/webp Docker 版本升级：libavif升级到1.2.0
2025-03-19：
php升级到8.1.32
pdf.js升级到5.0.375
2025-03-21:
avif/webp Docker 版本升级：libavif升级到1.2.1
2025-03-31：
pdf.js升级到5.1.91
2025-04-02：
nginx fastcgi缓存上限从50M增加到60M
2025-04-11：
编译nginx使用的openssl升级到3.5.0
2025-04-18：
wordpress-core升级到6.8
nginx升级到1.27.5
2025-04-24：
imagick升级到3.8.0（居然更新了）
imagemagick升级到7.1.1-47
nginx升级到1.28.0
2025-04-28：
pdf.js升级到5.2.133
2025-05-20：
avif/webp Docker 版本升级：libavif升级到1.3.0，libaom升级到3.12.1
2025-06-26：
nginx升级到1.29.0
2025-06-28：
pdf.js升级到5.3.31
2025-07-02：
编译nginx使用的openssl升级到3.5.1
2025-07-03：
php从原来的8.1.32升级到8.2.29
但imagick的3.8.0不知道为什么就是没办法识别版本号，只能暂时先退回3.7.0
2025-07-07：
pdf.js升级到5.3.93
2025-07-10：
avif/webp Docker 版本升级：libwebp升级到1.6.0
2025-08-05：
编译nginx使用的openssl升级到3.5.2
编译完了以后上线preload突然蹦出个122秒（之前一直稳定80秒左右）吓了一跳。反复排查各种可能原因都没找到什么异常，fastcgi cache size也没有变，该重启的都重启了，最近几天也没有动过服务器/wordpress的任何配置。最后发现是这个vps的性能下降了（比如最近几次mysqldump的用时从之前的一分半增加到现在的2分钟），判定为Hetzner母鸡出了问题（多半是有臭邻居在乱搞服务器），不知道什么时候才能恢复正常。
过了8小时补充：preload时间降到了102~108秒，看来还是有在一点点改善。
2025-08-18补充：直到我迁移到新服务器（Debian 13）的时候都没有恢复正常，新服务器运行preload立马恢复了之前的水平，看来就是之前的机器有问题。
把MathJax从3.2.2升级到4.0.0，还是使用svg渲染。之前的配置原封不动搬过来就能用，但这次额外多加了2个配置参数：
// 之前没有这个功能，所以只能用css实现，现在mathjax自带这个功能了！
displayOverflow: 'scroll'
// 这个辅助功能暂时用不上
enrich: false目前暂时没发现什么问题
2025-08-13：
nginx升级到1.29.1
2025-08-18：
服务器升级到Debian 13（没有原地升级，而是新开了一台Debian 13的服务器，完全重新编译安装，然后把本站迁移过去），preload.py终于恢复了我这个配置应该有的水平。
mariadb升级到11.4.8
imagemagick升级到7.1.2-1
因为wp site health的提醒，跑去清理一下 wp_options 表看看对preload的性能有没有提升，大概清理了20%，但preload还是老样子，所以又把表回滚了（保留了本站几年前安装的各种插件留下的痕迹也不错）
2025-08-27：
编译nginx使用的PCRE2升级到10.46
2025-08-30：
才发现我的garbage posts的meta tag里面没有 noimageindex ，赶紧给补上了。
pdf.js升级到5.4.149，重新换回了legacy build（而不是modern build）.
有关gzip和brotli：
❌ 虽然cloudflare origin pull早就支持brotli了，但本站又去掉了nginx的brotli支持：发现有速度测试结果表明brotli的速度比gzip普遍要慢（在不考虑压缩比例的情况下）。由于本站的内容都要经过cloudflare重新打包为zstd，只考虑origin server到cloudflare edge server的情况下gzip (level=1) 似乎是更优的选择。
✅ 终于搞定了cloudflare end-to-end brotli，现在终于不需要经过cloudflare的二次解压缩-重新压缩了，而是源站的brotli传到底。之前（2024-02-14）没有成功应该是忘了关email obfuscation（一直以为这是一个配置了域名邮箱才有的设置所以就没仔细看，没想到是一个多年前开启以后就忘记了的邮箱保护小功能）。试了下end-to-end gzip和brotli都成功了（因为cloudflare默认给免费用户开了zstd，所以只要浏览器返回的是gzip和brotli就说明没有被重新压缩）.
又用🔗 [有关Cloudflare, NGINX, gzip, gzip_static, brotli, brotli_static, QUIC的一系列问题（2021） - Truxton's blog] https://truxton2blog.com/cloudflare-nginx-gzip-gzip_static-brotli-brotli_static/ 的curl命令测了一下：
- 首先：无论你发送了什么accept-encoding，origin server接收的永远是gzip, br
- 如果发送gzip, deflate, br, zstd（chrome 139的行为）：虽然zstd的优先级最高，但会返回brotli，而且cloudflare不会修改（大概是cloudflare认出了这次的end-to-end-brotli的需求；换成以前是会返回zstd的）
- 去掉nginx的brotli配置，发送gzip, deflate, br, zstd（chrome 139的行为）：会返回gzip，而且cloudflare不会修改
- 综合2+3：如果cloudflare发现能够做到end-to-end gzip/brotli，就会忽略zstd等优先级，然后根据brotli->gzip的顺序开始end-to-end transfer.
- 如果服务器本地向127.0.0.1:443发送gzip, deflate, br, zstd（chrome 139的行为），那么会返回br（因为没有编译带zstd的nginx）
- 如果发送gzip：origin server压缩并发送br -> cloudflare解压br并压缩zip -> 发送到client（这是因为origin server仍然收到了gzip, br）
- 如果发送deflate：origin server压缩并发送br -> cloudflare解压br变成deflate -> 发送到client（这是因为origin server仍然收到了gzip, br）
- 如果发送zstd：origin server压缩并发送br -> cloudflare解压br并压缩zstd -> 发送到client（这是因为origin server仍然收到了gzip, br且cloudflare支持压缩zstd）
- 如果服务器本地向127.0.0.1:443发送zstd：返回deflate（因为没有编译带zstd的nginx）
- 如果什么都不发（curl默认行为）：origin server压缩并发送br -> cloudflare解压br变成deflate -> 发送到client（这是因为origin server仍然收到了gzip, br）
考虑到brotli的普及范围很广：
所以可以认为绝大部分情况下本站访客都能收到没有被cloudflare二次打包的brotli. 虽然brotli的压缩速度不佳，但避免了cloudflare的二次压缩，主动权把握在自己手里而不是看cloudflare服务器负载的脸色。
坐等cloudflare支持end-to-end zstd（估计要好几年）.
2025-09-01 ~ 2025-09-08
CDN配置的这些知识真的容易忘，虽然我频繁维护这个博客，但主体架构（cloudflare + nginx）已经好几年没变过了。这次不知道为什么又想试一试cloudflare之外的东西，结果还真试出来了 -> 本站迁移到了bunnyCDN.
花了大约一周的时间买了一个临时域名去试试bunnyCDN怎么用。之前吃了Azure CDN不会用的亏（毕竟cloudflare不算很纯粹的CDN，更偏向于proxy，而且我也没依赖cloudflare缓存的各种规则）。bunnyCDN毕竟是小公司，有些设计其实考虑得不是很完善，试了好几天，终于找到了一些规律，搞定了perma cache的用法。
所以现在本站所有html，所有js/css/woff2等静态资源都缓存在perma cache，图片暂时搞不定（perma cache有性能损失，想了想还是算了）。
现在的preload策略是：先搞fastcgi preload在本地生成html cache，再开一个50线程的python程序去疯狂下载html+css+js+除了图片以外的大部分静态资源，这样就可以用1分钟左右的时间把重要的静态资源扔到perma cache上面去。
perma cache确实很难处理，用临时域名去试的这几天基本上都在考虑如何使用这个perma cache（如果不用perma cache，那就基本可以考虑搬回cloudflare了）。
准备另开一篇笔记详细记录下（就像这篇一样：🔗 [本站服务器将走向何方？（写于2023年1月） - Truxton's blog] https://truxton2blog.com/this-blog-next-deploy-plan-2023_jan/ ），这样过了几年如果又忘记CDN这些东西了也能快速回忆起来。
2025-09-10
avif/webp Docker 版本升级：libaom升级到3.13.1，debian环境也变成了13.1 Trixie
2025-09-16
发现在某些时候页面居然会加载来自jsdelivr的文件比如https://cdn.jsdelivr.net/npm/@mathjax/mathjax-newcm-font/svg/dynamic/calligraphic.js
藏得很深，mathjax 4是lazy rendering，所以只有访问特定公式的时候才会触发，比如2022-03-20笔记中间部分的某些公式。
看了这个链接才知道，mathjax @4把之前的tex-svg-full.js取消了，各种可选的字体默认用jsdelivr提供：🔗 [Hosting Your Own Copy of MathJax — MathJax 4.0 documentation] https://docs.mathjax.org/en/latest/web/hosting.html
所以要改成本站提供：先运行 npm install @mathjax/mathjax-newcm-font 下载字体，然后把mathjax配置改成：
output: {
displayOverflow: 'scroll',
font: 'mathjax-newcm',
fontPath: '/wp-content/uploads/mathjax/MathJax-4.0.0/mathjax-newcm-font'
}这样就行了。实际上还有个地方应该也会触发jsdelivr，就是speech-rule-engine相关的功能，但我怎么操作mathjax的菜单都没法触发这个js文件从jsdelivr服务器里下载，mathjax配置里也没有启用speech这个功能，所以就暂时不管了（应该没人会用这个功能吧？）
在手动部署mathjax-newcm-font资源以后，我的bunnyCDN perma cache又多了一大笔账：这个文件夹里面有足足1124个文件！虽然真正用到的可能就那么几十个甚至两三个（更确切地说，我目前就发现了一个calligraphic.js），但目前还是懒得节省这一步，全丢上去得了
2025-09-17
我就修改了一篇文章里面的几个字，为什么非要全站preload一遍呢？以前可能是图个新鲜而且preload代价很低，但现在全站preload脚本还默认绑定了bunny perma cache preload（三千多个文件），太浪费了。最近频繁修改我那篇Tahoe升级记录，preload的消耗都影响我正常修改了。
所以写了个新程序，每次自动reload最近修改的10篇文章（10篇应该就够了）。但只能作用于【文章的内容有修改】，不能作用于：修改文章excerpt，发表新文章，删除文章，修改文章类别，修改文章标题，修改文章url，修改文章发表日期...（因为会影响其他页面的内容）
2025-09-22
鬼知道是什么原因，这些年我一直没有给pdf.js和html的iframe添加lazy loading属性...（我还特意去翻了下以前的老代码，以前也没有加过这个）
现在加上了
2025-09-30
编译nginx使用的openssl升级到3.5.4
2025-10-08
nginx升级到1.29.2
2025-10-21
对nginx编译代码进行大改：除了brotli以外其他的依赖都直接用系统的就行，不想每次都费时间编译nginx了（或者说是退烧了）。最近正在筹划搬服务器，以后连mariadb的编译也很有可能被取消，所以nginx这边先节省点空间和cpu时间。
2025-10-23
pdf.js更新到5.4.296
2025-10-28：
nginx更新到1.29.3
2025-11-03：
从bunnyCDN迁出，这次选了个优质线路的dmit
找个时间归档一下过去2个月和bunnyCDN各种bug斗争的零碎笔记
归档完了，做了一个合集，见：🔗 [2025年9月 从CloudFlare迁移到bunnyCDN的一些记录 - Truxton's blog] https://truxton2blog.com/2025-sept-migrate-from-cloudflare-to-bunnycdn/
nameserver一开始从bunny切换到cloudflare，然后又切换到ibm ns1
imagemagick升级到7.1.2-8
但第二天莫名其妙在重启php的时候遇到了 liblqr-1.so.0: cannot open shared object file: No such file or directory 的问题，重新编译imagick也没有用，所以只能又降级回了7.1.2-1然后再次编译imagemagick + imagick
mariadb query cache从60M缩减到10M
2025-11-04：
一些失败的尝试：
nginx zstd：能提供zstd，但不知道为什么chrome访问的时候返回br，貌似是zstd插件优先级的问题（Link1, Link2），需要打补丁，但懒得打了
OCSP stapling：折腾了一会发现不对劲：我的let's encrypt证书里面没有OCSP url，后来我才发现🔗 [Ending OCSP Support in 2025 - Let's Encrypt] https://letsencrypt.org/2024/12/05/ending-ocsp
顺便学习了下OCSP和CRLSet
JA3/JA4 TLS FingerPrint：成功用nginx-ssl-ja3 配合nginx 1.27.2编译出了一版，但发现这玩意甚至对浏览器隐私页面都不管用（重开一个隐私窗口=新的FingerPrint，作用有限）
另见🔗 [在线测试浏览器指纹 | IPPurity] https://ippurity.com/fingerprint.html
目前仍然没有找到好用的JA4实现
2025-11-07
avif/webp Docker 更新构建脚本：系统从Debian换成Debian-slim，增加了一些文件清理步骤，让docker tar文件从原本的201MB减少到了71MB
但事后发现（不知道为什么，明明构建的aom/libavif版本号都一样）相同的测试jpg文件出来的avif比原先少了2kb（161kb->159kb），原因未知
排查了老半天，最终发现即使是同一个docker镜像，在不同的Linux平台跑出来的avifenc结果都略有区别（可能是cpu指令集不一样）...在另一台ubuntu服务器里就能复现出之前的161kb（同之前的Hetzner），而新搬的dmit服务器就只有159kb...看来并不是我精简镜像出了问题。
2025-11-08
把文章过期提醒的时间从>730天缩短到>=365天
pdf.js升级到5.4.394
2025-11-09
添加了一个自定义的图片div，使用flex box，效果如下：
但还是搞不定wp gallery
2025-11-16
又发现一个好看的主题：🔗 [catppuccin/prismjs: 🌈 Soothing pastel theme for Prism.js] https://github.com/catppuccin/prismjs ，在浏览nuqs文档的时候发现的
迁移完毕，备份在这里：catppuccin-latte.css
效果：
2025-11-28
读了nginx官方的一篇fastcgi配置博客以后才发现之前对nginx fastcgi keys_zone的理解一直有误：
补充在 🔗 [使用tmpfs存储nginx FastCGI缓存文件时要注意的配置问题 - Truxton's blog] https://truxton2blog.com/set-fastcgi-dir-in-tmpfs-disk/
所以就把本博客的fastcgi设置从之前的keys_zone 60m修改为keys_zone 10m；max_size目前还是60m不变。
2025-12-01
pdf.js升级到5.4.449
2025-12-02
WordPress升级到6.9
没遇到什么问题
fastcgi稍微大了一点点
但Autoptimize cache从原来的16M猛增到85M，具体原因未知
发现很多原本应当使用同一个autoptimize js/css的页面现在用了不一样的js/css，对性能略有负面影响（打开多个页面时js/css缓存的复用率降低了）
想了想，把Autoptimize的这个选项去掉了：
所以现在我写的那几十个小型修补css（微调样式的）都会直接放在html里面（而且是一个一个放的，不聚合）
nginx fastcgi马上从38M涨到62M
Autoptimize cache从之前的16M掉到了6.7M
印象里已经好几年没调整过autoptimize设置了，fastcgi的大小也一直很稳定，所以推测本次事件的原因来自：wordpress 6.9官方引入的一些前端性能优化：
（推测）这个改动会让很多页面（在autoptimize处理前）拥有很多不同的inline CSS，从而导致生成了很多文件大小非常接近、内容几乎一样的autoptimize css文件。
2025-12-05
发现有些网站仍然使用RSA let's encrypt（指用支持ecdsa的现代浏览器访问仍然得到rsa cert）：
blog.gslin.org（amazon cloudfront给的），gnu.org，eff.org，等等
但又不想直接使用RSA证书（贪一点ECDSA的速度）
按照let's encrypt的指南，最好的方法是在服务器上安装2个证书：rsa和ecdsa：
（这样就需要多申请一次let's encrypt，因为ecdsa和rsa会各自走独立的申请流程）
配置nginx的时候又遇到了问题，因为没有正确理解rsa ciphe和rsa证书的区别，用了这样一条错误命令去测试rsa证书：
openssl s_client -connect truxton2blog.com:443 -tls1_2 -cipher 'RSA'结果发现tls 1.2 + RSA永远无法建立连接，而tls 1.3+RSA又能连了...
实际上这条命令是要求用AES128-GCM-SHA256这样的cipher连接，而不是检查服务器是否支持rsa证书
这条命令才是对的：
echo | openssl s_client -connect truxton2blog.com:443 -servername truxton2blog.com -tls1_2 -cipher 'aRSA' -showcerts
echo | openssl s_client -connect truxton2blog.com:443 -servername truxton2blog.com -tls1_2 -cipher 'aECDSA' -showcerts上面的AES128-GCM-SHA256这样的老协议是不支持Forward Secrecy的：
这样就会导致ssl labs评分降到B
最后的做法是，在ssl-config.mozilla.org的Intermediate配置的基础上，专门为那些老设备（比如ios 6, windows xp - chrome 49）增加ECDHE相关的cipher
这样就可以满足以下条件：
- 对一些特定的老设备，支持RSA证书
- 对绝大多数设备都默认使用ECDSA证书
- 对所有的设备都使用ECDHE/DHE cipher，不使用RSA cipher（用于规避Forward Secrecy问题）
搞了半天原来是没有搞明白RSA证书和RSA cipher的区别...
2025-12-07 ~ 2025-12-08
终于修好了长期以来一直存在的fancybox和TOC anchor的滑动问题（从fancybox图片通过回退键返回的时候可能会触发怪异的滑动以试图返回上一个toc anchor的位置）。过程并不顺利，虽然gpt/gemini每次都会信心满满给我一个看起来可行的程序，但只要稍微多测试几个用例马上就会发现这是个ai耍小聪明的代码伎俩。大概反复对话/修改了10轮，直到现在（12-08）我也不知道这个代码到底算不算完美运行。
去掉了全局html smooth scroll（效果不好，toc anchor有的时候滑动不到正确位置）
在GPT的帮助下改进了TOC auto scroll middle代码的问题（之前的老代码内存泄漏，滑动效果不佳）
2025-12-10
nginx升级到1.29.4
现在可以使用encrypted ClientHello功能，但openssl还没有正式发布ECH功能，所以决定等到明年openssl 4.0.0推出了再搞
2025-12-18
php从8.2系列（8.2.29）升级到8.3系列（8.3.29），预计8.3.29是进入security support之前的最后一个修bug的版本，所以现在升级应该是比较稳定的。
WordPress没有问题，但编译php遇到了一些麻烦，和swap有关。详见2025-12-18 swap issue.
2025-12-22
注册了一个新的shortcode：效果. shortcode.
2025-12-29
pdf.js升级到5.4.530
2026
2026-01-16
php升级到8.1.30
