躺平.赢

火星救援，刚刚知道 WordPress 支持 SQLite，花了一点时间研究，但不是很成功。

最终，基本是靠手工迁移的，故经验十分有限。

首先，有前人尝试成功 ，大体而言和我的步骤差不多：

1. 禁用所有插件，设置主题到系统默认，以防出问题
2. 安装插件 SQLite Database Integration，并激活
3. 激活后会开始一次全新安装

这时，wp-content 下应该已经生成 .ht.sqlite 文件了。用 Navicat Premium 中的数据传输功能，直接对拷两边的数据。或者是生成到新的 SQLite 文件，再覆盖服务器上的 .ht.sqlite。如果后台无限循环不可登录，很有可能是数据库文件权限不对，检查可写和拥有者属性。

至此，理论上就已经搬迁完毕，但实际还有问题。

前人的文章提到，数据库日期不对，需要额外修正，这一步在 Navicat Premium 转换的过程中就可以修正好。我的问题是 New Post 会触发 Warning，老文章编辑却正常，没找到原因。最后，我通过 WordPress 自带的导入导出功能恢复了文章，但后台设置和部分插件要重新设置一遍，等同于手工迁移。

MySQL 也卸载了，给只有 10G 的小鸡腾出不少空间。真不明白为什么服务器版本那么大，我的 Windows 本地开发版才 100M 不到。

最后删除了一些插件（例如 数据库备份，现在只要同步文件就行了），开启缓存。转换后，网站速度明显快了很多。

之前了解到一个项目 ip-scanner/cloudflare，提供了大量 CF 非官方节点，不过命中率大概只有 15%，又因为是公开的，失效比较快。因为我的 HostDare 的 VPS 本身线路就比较好，后来就很少用到。

直到有一天…… HostDare 跑路了，虽然机器还活着，但也说不准哪天就连不上了，我就换到了另一台 VPS。那台机器没有 GIA 线路，所以速度比较慢，我又重新套起了 CF。原来套的是官方节点，虽然也测过速的，但不知道是 WARP 还是 IPV6 的原因，速度明显不如以往。

几天前，在 B 站看到一个视频： 《Alist的“流氓”用法，挂载无尽资源》 。其中提到了 ZoomEye，突然意识到可以自己挖掘一下第三方 proxy server。原本我只听说过这类搜索引擎，直到昨天，才知道这叫“网络空间测绘”。

挖掘过后颇有成效，几个搜索引擎都可以筛选 Cloudflare 服务，通过限定端口、响应值、ISP、地区，配合 glider，可以很快从几百几千个结果中筛选出可用 IP。从结果上看，速度好的 IP 主要集中在某几个 ISP 和地区，具体就不透露了。这些结论可以沿用至其他测绘搜索，实现更快速精准的过滤。有兴趣的可以自行收集测试。

测试过程中，主要锁定了日本、韩国、香港、大陆、新加坡等响应较快的地区，初步收集了 200 余个资产，和 ip-scanner 的重叠度很低。ip-scanner 包含了一些不仅限 CF，而是任意转发的服务器，这也佐证了扫描方式不同。

部分在尝试过程中用到的服务：
FOFA、ZoomEye、Quake、Shodan、censys、CriminalIP
FOFA-Hack：通过限定时间（基本可以）无限抓取的爬虫
ZoomEye 爬虫：key 要 urlencode 两次，改改即可用
棱角社区资产提取小助手：结果比较少的就不用爬了，直接复制提取

最后，有一个叫 cf2dns 的项目。该作者免费提供了一组定时更新的 测速结果，用于即时更新 dns 给网站提速，而这个站点本身也使用了该功能。也就是说直接使用域名：stock.hostmonit.com 即可解析到当前速度还不错的官方线路上。

最近需要对 Android 抓包，正好电脑上装了 Bluestacks，就尝试对其抓包。

根据以往的经验，就是在系统里安装证书，然后将代理设置到 App 的指定端口。
但是，突然发现行不通了。Bluestacks 不知何时砍掉了 Wi-Fi 设置，这也不是大问题，通过 Proxifier 可以强制代理。然后尝试安装证书，同样安装不上，无限循环卡在设置密码 / Pin 环节。

经过一番搜索。在 Stackoverflow 是上找到 解决方案。答案是针对 HttpCanary 的。简单来说就是要先获得 root，再通过手工导入证书。

最简单的 root 方案是使用 BS Tweaker 工具，一键 unlock

接着手动导入证书

adb shell
su
mount -o rw,remount /
cp -f /data/data/com.guoshi.httpcanary/cache/HttpCanary.pem /system/etc/security/cacerts/87bc3517.0
chmod 644 /system/etc/security/cacerts/87bc3517.0
touch /data/data/com.guoshi.httpcanary/cache/HttpCanary.jks
chmod 600 /data/data/com.guoshi.httpcanary/cache/HttpCanary.jks

解释一下：

1. HttpCanary 以前是可以导出证书的，不知为何现在不行了，但可以从 cache 目录里提取到。
2. 87bc3517 这个值是 pem 证书的 hash，可以通过 openssl x509 -inform PEM -subject_hash_old -in pemfile.pem 获得。
3. 正常流程中 HttpCanary 会在证书安装成功后建立 HttpCanary.jks 文件，没有该文件 App 会提示证书不正确。

至此，HttpCanary 已经可以正常抓包。既然知道了导入证书的过程，相信 Charles、Fiddler 也可以顺利安装，不过我已经顺利抓到包，就没有再进一步尝试。

在 Reddit 上有 一个帖子 提到可以使用 Root Certificate Manager 安装证书，原理应该和上方脚本差不多。

我发现，HttpCanary 类的软件，比如 Packet Capture、抓包精灵，都有文中提到的问题，有些 App 提供导出证书，但又不知道导到哪去了。
这些 App 面向的大多是开发者，测试环境是很复杂的，除了提供开箱即用的方案，最好留有一些手动配置空间，例如写明检测机制、提供忽略/跳过选项、提供导出证书，而不是在傻瓜操作失败后让使用者束手无策。

之前用 time.cloudflare.com 作为固定 CF 加速节点，已经获得了比较稳定的连接，现在又发现了更有意思的玩法。

最近发现有个名为 ip-scanner/cloudflare 的项目，收集了许多非官方 CF IP。除非是做公益，这些节点无非就是配置不严谨的反代（或者蜜罐）

这些 IP 能用的并不多（比例上），不过通过 glider 的 check，10 秒不到即可在上千个 IP 中快速筛选出所有能用的 IP。我测试了一下能连通的比例大概是 15%。

真正有趣的地方不在这里，我很好奇这些 IP 的来源，于是翻了下 issue。有一条回复提到：有一些 ip 是对所有的域名都进行代理。

我跑了一遍所有的 IP，没想到这样的万能 IP 还不少，大约有几十个，有些甚至是整个段都可以用（包括 bot 漏扫的）。把代理的 IP 直接换掉即可加速线路，这样连 Cloudeflare 中转都省掉了。当然，443 端口 + websocket 是必须的。

具体流程是：

1. 抓取所有项目内的 IP

可以直接下载，也可以通过另一个 dogefy/CloudflareIP-AutoCollector 项目来抓取，需在同目录下自建 key.txt 并写入关键字才能顺利抓取（写 - 即可抓取全部）。

2. 测试所选的 IP

可先通过 glider 排除不可用的 IP，测试会快一些。
以下是一段批量测试 demo，这里用百度下拉关键字接口作为目标。ip_result.txt 是上一步默认生成的。

import subprocess

ip = open("ip.txt", "w")

for line in open("ip_result.txt"):
    try:
        result = subprocess.check_output('curl -m 5 "https://www.baidu.com/sugrec" --resolve www.baidu.com:443:'+line, shell=True)
        if "queryid" in str(result):
            ip.write(line)
    except:
        pass

ip.close()

3. 测速

用 CloudflareSpeedTest 测速。上一步默认生成到 ip.txt，直接运行 CloudflareST -dn 999 。

4. 安全

尽管蜜罐的可能性很低，但毕竟这些 IP 来历不明，最好不要用 Trojan-Go 和 VLESS，SS AEAD 和 VMESS 是比较好的选择。

至此，关于代理和加速已经没什么可探究了，再烂的线路都能起飞。

后话：这些 IP 还有个用途，可以写入 HOSTS 实现部分裸连。当然，这种做法不太安全，适用面窄，也容易被封。

issue 中似乎有人担心这个项目会被滥用，我觉得大可不必。这些 IP 轮换非常快，想用来建站是不可能的。作为代理加速，也必须是自建线路，同时筛选测试有一定门槛，即使知道原理，愿意用的人也不多。对于小白和白嫖用户来说，使用现成的工具订阅免费源依然最便捷的方式。

g最近换了联通宽带，所以把 Cloudflare 段重新测了一遍，测试过程中发现有个 IP 被自动反解成了域名，并且是之前扫描没见过的：time.cloudflare.com，并且支持套 cdn。

搜了一下得知，这个是 Cloudflare 的时间校对服务，还有个 roughtime.cloudflare.com，这两个域名被分配到同一个段的两个固定 IP 上，于是跑了一下对比测试。

可以看到，这条线路相比其他 Cloudflare 自动分配的域名要好出很多，ping 丢包率即使在最差的情况下也在 3% 以内。

之后又 tcping 了整个段。

从筛选结果上看，0~20 区段最稳定，之后的情况比较随机。因为软件本身的问题，有时候会整体卡壳，实际 Failed 没那么高。

我用 Excel 选取了其中 tcping 和丢包最低的几十个 IP，交给 glider 自己 lha 模式匹配。手机上就用 time 子域名，比较好记。

更新：

要获得大量可用 IP，最好的办法还是让 CloudFlare 自己挑选，例如使用这份 sites-using-cloudflare。在里面二次筛选低延迟的 IP 将更加省力，偶尔还能获得非 172/104 开头的宝藏 IP。

最近B站冒出来一堆“建站教程”类视频，还提供免费 CDN，不禁感叹阿猫阿狗都能做 IDC 了。

后来发现，这些 IDC 都是智简魔方 + easypanel 模板，甚至是对接的其他 IDC 做代理，自己网站连 ssl 都没有，令人惊叹。

不过这也不影响白嫖，因为之前研究过梯子套 CDN，正好就拿来试试。
这里有两个不错的上游 IDC，开设时间都很短，没跑路就先用着。

1. 小鹿云
   主机商自营一个博客也叫小鹿云，CDN 的 cname 也是这个域名的子域。
   一条美国免费线路，5 台服务器，0.1 元 / 100G / 月。
   需绑手机，不过通过代理开就不需要，而且免费，例如：景云
2. 幻话云
   美日韩港线路都有，6 台服务器，可自选 IP，0.01 元 / 10G / 月。
   CDN 服务不需要手机。

这套系统不支持域名回源，只能 IP 回源，所以需要落地机有公网 IPv4。至于域名可以随意填写，不过要打开跳过证书验证。也正因为如此，梯子协议应该选用有 AEAD 加密的方案。

速度上比 CloudFlare 快多了，希望能活得久。

设想

在《利用CDN对单条私有线路负载均衡》中提到，我试图用 Glider 作分流，但没能实现多路复用。最近又研究了一下 Glider 的配置，发现还是有解的。

最终，配出了一条自认为还算不错的方案： tls+ws+mux+ss

Glider 完整支持 TCP / UDP 且同时支持 Server / Client 的有 SOCKS5 / SS / Trojan(c) / Unix，考虑到过 CDN 的安全性，能支持 AEAD 加密的只有 SS，所以我使用 SS 作为基础协议，加密采用 AEAD_AES_128_GCM。

具体实施

Server 安装与启动，以 ubuntu 为例：

dpkg -i glider_x.x.x_linux_amd64.deb
systemctl enable glider@glider
systemctl start glider@glider
# systemctl restart glider@glider

默认配置文件 /etc/glider/glider.conf，加入 listen=ws://127.0.0.1:[port]/[path],smux://,ss://AEAD_AES_128_GCM:[pass]@。重启服务。

因为 443 端口还有其他业务，所以我把 tls 的部分交给 nginx 处理

location /[path] {
    proxy_redirect off;
    proxy_pass http://127.0.0.1:[port];
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
}

Client 配置：

直连：forward=wss://[host]/[path],smux://,ss://AEAD_AES_128_GCM:[path]@

CDN：forward=wss://[CDN_SERVER]/[path]?serverName=[YOUR_HOST]&host=[YOUR_HOST],smux://,ss://AEAD_AES_128_GCM:c2059aef-6ffb-44d1-a2ee-d9a379826cf1@

其中 CDN_SERVER 可以是 Cloudflare 自选 IP、CDN 提供的 CNAME 等，YOUR_HOST 就是回源服务器。其中，serverName 参数不是必须的，这取决于 CDN，比如：Cloudflare 要求指定，Asians.Group 可以不写。

一点技巧

如果使用 Asians.Group 的服务，host 将作为流量统计依据，这个域名无需真实存在。

例如：在后台填入自编域名 sam.ple，回源到真实的 domain.com:443，配置 Glider 客户端时将 host 指定为 sam.ple 即可。

如果流量不够，可以注册多个账户实现流量叠加，只要加入的域名不同即可，无需（也不可能）为其配置 ssl。

一点问题

以上方案并不能在手机上使用，因为手机没有 Glider，也没有客户端支持 smux 套 SS，更没有什么现成的叠速方案。

如何找到合适的线路

Cloudflare 可以用测速工具，其实就是抽签，速度只能保持一小段时间，个人感觉参考价值不大。我完整测试了全部 ip 段后得出的结论是，系统分配的基本接近最佳，建议用一批 Cloudflare 子域替代 ip，例如 h3.speed.cloudflare.com 、rpki.cloudflare.com 等。

子域挖掘工具：DNS Dumperster 和 Whois XML API剔除掉 NS 子域、固定 ip 子域后，用 Glider 批量验证：

glider 2>&1 | grep --line-buffered Elapsed | awk -F "[: ]" "{print $11}"

去重后填入配置形如：

forward=wss://migp.cloudflare.com/██?serverName=█.██.███&host=█.██.███,smux://,ss://AEAD_AES_128_GCM:████@
forward=wss://blog.cloudflare.com/██?serverName=█.██.███&host=█.██.███,smux://,ss://AEAD_AES_128_GCM:████@
forward=wss://rpki.cloudflare.com/██?serverName=█.██.███&host=█.██.███,smux://,ss://AEAD_AES_128_GCM:████@
#... 适合用 ha 策略

Asians.Group 也可以通过这个方式挖掘出 yk1.net （其 CNAME 主域）下的线路，有香港、美国、台湾、日本等，分别对应到各个 cluster-xxx 子域上。不过意义不大，因为都很快，直接用 asians.group 就行。

forward=wss://asians.group/██?host=1.██.███,smux://,ss://AEAD_AES_128_GCM:████@
forward=wss://asians.group/██?host=2.██.███,smux://,ss://AEAD_AES_128_GCM:████@
#... 适合用 rr 分流

CloudFront 等其他付费 CDN 请随意。

时隔很多年，装回了 WordPress，看到后台惊呆了，根本不是我以前认识的 WordPress。新的编辑器实在适应不来，索性换成 Markdown。

安装了 WP Githuber MD，默认是 Prism 高亮代码，但样式不太喜欢。找了下有个叫 Enlighter 的热门插件，但是安装后怎么都不起效，开启了兼容模式代码还是 Plain Text。查了官方文档，最终发现兼容模式只是兼容后台 Editor，跟前台没关系。

继续搜索后发现，最近正好有人解决了这个问题。

原文：解决Githuber MD插件代码高亮不能正常工作的问题

修改外观 - 主题文件编辑器 - inc/template-functions.php（原文是 core.php），插入以下转换代码。

/**
 * Use EnlighterJS in Markdown
 * 
 * Source: http://cppdebug.com/archives/438
 * 
 * Author: 大脸猫
 */
function getPar($par,$str){
    $pieces = preg_split($par, $str,-1,PREG_SPLIT_DELIM_CAPTURE);
    $result ='';
    foreach($pieces as $piece){
        $result.=$piece;
    }
    return $result;
}

//转换代码高亮器
function bTagFilter($content) {
        $pattern_full = '{(<pre><code class="language-[\s\S]*?">[\s\S]*?<\/code><\/pre>)}';
        $pattern_full1 ='{<pre><code class="language-[\s\S]*?">([\s\S]*?)<\/code><\/pre>}';
        $pattern_full2 ='{<pre><code class="language-([\s\S]*?)">[\s\S]*?<\/code><\/pre>}';
        //使用短代码的正则分割字符串
        $pieces = preg_split($pattern_full, $content,-1,PREG_SPLIT_DELIM_CAPTURE);
        $new_content = '';
        //遍历所有的字符串 含有段代码的字符串不做自动处理
        foreach($pieces as $piece) {
            if (preg_match($pattern_full, $piece, $matches)) {
                $code = $matches[0];
                $lug = getPar($pattern_full2,$piece);
                $code = getPar($pattern_full1,$piece);
                $code = '<pre class="EnlighterJSRAW" data-enlighter-language="'.$lug.'">'.$code.'</pre>';
                $new_content .= $code;
            } else {
            $new_content .= $piece; }
        }
    return $new_content;
}

之后 Enlighter 就实时生效了，应该不局限于 Markdown，其他编辑器也可以试试。

需求

自有线路，服务器有业务在跑，顺带做个自用机场。在特殊时期希望隐匿服务器 IP，所以考虑挂 CDN 使用。

免费的方案一般是套 CloudFlare 减速云，少部分使用 Asians.Group。瓶颈主要在单服限速（CloudFlare 的测速工具只能保证连通，很难稳定维持）。所以我希望本地可以做负载均衡。我预期的传输方式是，客户端 - 多台 CDN - 落地机。因为出口是同一台服务器，所以 url hash 不合适，最好是轮询。

寻找解决方案

v2ray 本身支持 轮询 和随机两种调度方式，问题在于 Gui 管理。v2rayN 只能通过导入 .json 文件的方式使用复杂配置，因为 ip 不稳定，配置格式使得频繁修改 ip 比较麻烦。而 Clash for Windows 默认是高可用模式，除非自己修改源码 才能支持轮询，所以也只能放弃。

最终找到 nadoo/glider，本身是代理链工具，它正好拥有以下特性：

1. 支持 vmess / vless / trojan 等协议
2. 配置结构简单，一行一条线路
3. 支持 round robin 策略

具体配置

协议方式：vm(l)ess + lts + websocket
客户端： glider + v2rayN / Clash for Windows

glider 说明中有很多示例，以下是针对 CDN 的具体配置。

以 vless 为例，服务器配置如下：

  "inbounds": [
    {
      "port": local-port,
      "listen": "127.0.0.1",
      "protocol": "vless",
      "settings": {
        "decryption": "none",
        "clients": [
          {
            "id": "put-your-uuid-here",
            "level": 0
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/ws"
        }
      }
    }
...

glider 本地配置：

code>forward=wss://{CDN_IP}/ws?serverName={YOUR-DOMAIN}&host={YOUR-DOMAIN},vless://{put-your-uuid-here}@

"inbounds": [
    {
      "port": local-port,
      "listen": "127.0.0.1",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "put-your-uuid-here",
            "alterId": 0
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/wss"
        }
      }
    }
...

code>forward=wss://{CDN_IP}/wss?serverName={YOUR-DOMAIN}&host={YOUR-DOMAIN},vmess://chacha20-poly1305:{put-your-uuid-here}@?alterID=0

code>forward=tls://{CDN_IP}:443?serverName={YOUR-DOMAIN},ws://@/wss?host={YOUR-DOMAIN},vmess://chacha20-poly1305:{put-your-uuid-here}@?alterID=0

将 glider 中的监听改为 code>listen=ss://aes-128-gcm:p@:8443，然后在 Clash 订阅工具中填入 code>ss://[email protected]:8443#Local。这会损失一部分性能，因为客户端不支持 ss 协议 none 加密，不过总体而言，PC 也不差这点性能。

parsers: # array
  - url: your-sub-url
    yaml:
      prepend-proxies:
        - name: "Local"
          type: socks5
          server: 127.0.0.1
          port: 8443

clash 不是一个合法地址，所以转换时会被丢弃，同时 parser 会在导入时加入一个 socks5 服务器。具体可以参考 配置文件预处理。

小结

以上方案仍然不能突破单服务器带宽限制，个人体验，打开一般网站已经很流畅，多线程下载也很顺畅，4K 视频比较吃力。另外，glider 不支持 v2ray 的 mux，算是一点遗憾。

至于如何测速和寻找稳定的 CDN IP，又是一个麻烦的问题。

今天测试了一下文章内嵌视频，包括哔哩哔哩和Youtube，做个总结。

哔哩哔哩

直接使用官网的内嵌代码，视频会挤成豆腐块大小。网上的解决方案主要来自文章 《typecho文章挂载Bilibili视频响应式代码》 。

文章发布于 2019 年，采用的是固定 em，并做了好几种适配。到了 2021 年初，Chrome 88 新增支持 css 的 aspect-ratio 自适应比例，很快 Firefox、Safari 也支持该写法，所以可以改进为：

.iframe_video {
    width: 100%;
    height: auto;
    aspect-ratio: 4/3;
}

内嵌视频代码稍作修改：

<iframe class="iframe_video" src="//player.bilibili.com/player.html?aid={AID}&page=1&danmaku=0&high_quality=1" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true" sandbox="allow-top-navigation allow-same-origin allow-forms allow-scripts"></iframe>

添加 class="iframe_video" 。
酌情添加 danmaku、 high_quality 、sandbox 等。

Youtube

同样也可以使用 class="iframe_video" 调整。

Youtube 主要是官方播放器臃肿，使用 WP YouTube Lyte 插件，可在点击后再加载完整播放器。

其它

以上代码可以用于任何宽度撑满的模块，不局限于挂件类型。