分类： 技术技巧

之前了解到一个项目 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 插件，可在点击后再加载完整播放器。

其它

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