几个快速获得到Cloudflare反代IP的方法
此处反代主要用于爬墙
方案一:
ip-scanner/cloudflare 的继任 cloudflare-better-ip
方案二:
用多地点 ping 工具 ping 以下域名
- aGV4c2VuLmNvbQ==
- YWxpLnNnLjEzMzM1MC54eXo=
对获得的 ip 验证或测速
此处反代主要用于爬墙
方案一:
ip-scanner/cloudflare 的继任 cloudflare-better-ip
方案二:
用多地点 ping 工具 ping 以下域名
对获得的 ip 验证或测速
需切换至列表模式使用,只导出 IP、端口、协议
function downloadTextFile(text, fileName) { var element = document.createElement('a'); element.setAttribute('href', 'data:text/plain;charset=utf-8,' + encodeURIComponent(text)); element.setAttribute('download', fileName); element.style.display = 'none'; document.body.appendChild(element); element.click(); document.body.removeChild(element); } var row = document.querySelectorAll("tr.el-table__row"); var links = [],ports = [],protocols = []; for (var i = 0 ; i < row.length; i++) { var link = row[i].querySelector("span.table-link").innerText.trim(); if (link.length != 0){links.push(link);} var port = row[i].querySelectorAll("span.cursor-pointer")[0].innerText.trim().split(' ')[0]; if (port.length != 0){ports.push(port);} var protocol = row[i].querySelectorAll("span.cursor-pointer")[1].innerText.trim().replace('http/ssl','https'); if (protocol.length != 0){protocols.push(protocol);} } var text = ''; for (var i = 0;i <links.length; i++){ text = text + links[i]+ '\t' + ports[i] + '\t' + protocols[i] + '\n'; console.log(text); } var fileName = 'data.txt'; downloadTextFile(text, fileName);
之前了解到一个项目 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
解释一下:
87bc3517
这个值是 pem 证书的 hash,可以通过 openssl x509 -inform PEM -subject_hash_old -in pemfile.pem
获得。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 是必须的。
具体流程是:
可以直接下载,也可以通过另一个 dogefy/CloudflareIP-AutoCollector 项目来抓取,需在同目录下自建 key.txt 并写入关键字才能顺利抓取(写 -
即可抓取全部)。
可先通过 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()
用 CloudflareSpeedTest 测速。上一步默认生成到 ip.txt
,直接运行 CloudflareST -dn 999
。
尽管蜜罐的可能性很低,但毕竟这些 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,开设时间都很短,没跑路就先用着。
这套系统不支持域名回源,只能 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,本身是代理链工具,它正好拥有以下特性:
协议方式: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 本地配置:
以 vmess 为例,服务器配置如下:
"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" } } } ...
glider 本地配置:
wss 是后来增加的,也可以用最原始的写法,以 vmess 为例:
复制多行,策略选择 rr,以后只修改 CDN_IP 部分即可。
没有特殊需求,就已经可以通过默认 http / socks 端口 8443 使用,之后在 v2rayN 中加入一个 127.0.0.1:8443 的 socks 线路即可。
Clash for windows 的分流策略还是挺好用的,但是加入 socks5 有点麻烦。问题来自 subconverter 的 Bug,无法直接导入 socks5,所以需要手工改配置。有两个办法解决。
将 glider 中的监听改为 code>listen=ss://aes-128-gcm:p@:8443,然后在 Clash 订阅工具中填入 code>ss://[email protected]:8443#Local。这会损失一部分性能,因为客户端不支持 ss 协议 none 加密,不过总体而言,PC 也不差这点性能。
转换订阅链接填写 clash
,然后修改本地的 parser。
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,又是一个麻烦的问题。