ForestFireFox's Blog

【开源项目】Cloudflare大陆反代优选脚本

Thu, 01 Oct 2026 00:00:00 GMT

这是一个面向中国大陆用户测试CF SNI代理的python脚本，适配Windows&ubuntu。该项目使用了生成式AI。

前言：

众所周知，CF对大陆访问不友好，但某些神奇的服务又将带有优质线路的cf反代暴露在公网，可能又由于某些原因没有配置好，于是被扫了，我们便可以利用这些ip提速访问cf网站时的速度。该项目会对输入的反代ip进行多方位测试以确保实际场景可用性。

本项目没有针对80、2xxx端口的反代做支持。

本人因为自身原因没法管这个项目，故不接受任何PR。你可以fork这个项目，改完把仓库地址发在issue中。

⚠本条道路属于见光死类型，如果你想让这条路活得得久一点，就不要滥用本项目和优质反代ip！

请你把反代ip想象成某种程度上的公共资源：你在用，别人也在用。

人多不光导致拥挤；用得多了服务提供商也可能会注意到异常。

所以不要长时间、大流量滥用单个反代ip，比如拿去开机场。

环境要求

OS: Windows or Ubuntu（未测试） With Python & tracepath/tracert/traceroute & curl & ping

测试环境：Windows 11 with Python & tracert & curl & ping，只保证Windows环境下的可用性。

工作流程

导入ip csv -> 提取ip并去重 -> 检查可用性 -> 测试延迟、速度 -> 筛选优质ip -> 使用ipinfo查询ip本身对应国家 -> traceroute分析线路 -> 生成 bestips-{date}.csv 以及 ip.txt

参数（覆盖config.ini）

优先级：命令行给予 > config.ini > 脚本内置默认配置

-threads “测试延迟、速度”的线程数，默认2，填max时就取config.ini中的max值。
-i 输入文件，没填默认./ip.csv
-o csv输出，没填从config.ini中获取。#这里不支持{date}{num}等映射。 #该工具本为自动化场景而设计，ip.txt输出是不支持关闭的。
-d 测速文件大小，计数单位：MB。
-skiptr 跳过traceroute测试（针对导入ip为中国内地ip的情况自行开启）
-config 后面跟配置文件路径，例如config.ini（代表./config.ini）
-log 输出日志文件
-debug 调试模式

功能实现解析

检查可用性

curl -sS -k --connect-timeout {timeout} --max-time {timeout} --resolve {cf-host}:443:{your-ip} https://{cf-host}/cdn-cgi/trace 有正确输出即为可用。当然，存在特殊情况。

测试延迟、速度

ping ... {your-ip} 解析返回延迟 curl -w %{speed_download} ... {large-file-url}

去程线路分析

如您需要使用该功能，请在config.ini中填入你的ipinfo token，默认使用lite版进行ip信息的拉取。不填token也有几率匹配到内置规则。

traceroute/tracert/tracepath {your-ip}

带去程绕路标注(过HK线路也算绕)，但是实测有些路由器的ip没有被拉到对应的位置，这部分用了置信度辅助判断。该功能不是特别准，仅供参考。

主要分析：163、CN2、Anet、4837、CMI、CMIN2

csv输入示例

ip	port	protocol	title	country	city	link	org
167.179.113.223	443	https	403 Forbidden	JP	Tokyo	https://167.179.113.223	The Constant Company, LLC
108.102.223.154	443	https	403 Forbidden	US	Seattle	https://108.102.223.154	Amazon.com, Inc.
（ip列必须存在，存在其他输入也无所谓。）

ip.txt 输出结果示例

1.2.3.4#JP (CN2) Tokyo 1 //电信示例1 5.6.7.8#JP (163绕HK、US) Tokyo 2 //电信示例2

csv输出示例

route	ip	cfcountry	tour	country	city	speed	latency
CN2	1.2.3.4	JP	None	JP	Tokyo	12.8MB/s	50ms
163	5.6.7.8	JP	HK→JP	JP	Tokyo	9.7MB/s	120ms
CN2	12.3.4.5	JP	HK→JP	JP	Tokyo	8.3MB/s	52ms
CN2	12.34.56.78	HK→US		US	Califonia	20.0MB/s	200ms
163	123.4.56.78	NL→US		US	Califonia	2.3MB/s	600ms

排列优先级：previousCountry对应的国家 -> 速度降序；把cfcountry一致的ip归类到了一块排序

表头字段注释： route：判断的线路类型 ip：ip cfcountry：访问/cdn-cgi/trace对应的国家/地区代码，该字段可以填充HK。 tour：绕路情况，没绕填充None，绕路按照上述格式填充，例：HK→JP country：这个ip本身对应的国家 city：这个ip对应的城市 speed：这个ip的速度 delay：这个ip的延迟

记一次服务器迁移 —— 从0开始配环境、迁数据...

Sun, 20 Sep 2026 00:00:00 GMT

这篇文章只是记录，不是教程向，虽然有贴出小白可用的命令。

之前我的网站和服务都是部署在日本的VPS上的，但是由于服务商IIJ到软银的线路变动，现在三网都很卡。忍受不了一个200多KB的静态背景图要加载超过一分钟的我，选择了更换VPS。🚚

原VPS：ACCK JPIIJ-One 周年庆 （现在实为软银线）参数：广播ip、500Mbps+500M+10G、Cloudinnovation、大陆SoftBank直连、国内带宽实测最高100Mbps、99.99年付

新VPS：云悠 HK-Kawloon TCVM-Mini NodeQuality 参数：原生ip、100Mbps+512M+30G、Cloudie、去程CN2+4837+CMI，回程4837+CMI、15.99月付（有手续费）

因为之前那个vps不是被拿去挖矿了嘛，我担心有后门残留，面板废资源的同时不能满足我某个必须使用caddy的需求，所以这次我根据已有经验，借助AI从0开始手配环境。🔧

我部署的服务为 Caddy+PHP-FPM+Komari，以及一些例如frp、git的小东西，是一套很轻量的方案；推荐使用的SSH软件为FinalShell，与个人使用Windows的习惯非常贴合。💻

👤 用户配置

web -> web服务（caddy & php-fpm）
komari -> komari面板
frp -> frp
...

📁 目录配置

本人有强迫症，所以这么配：

/
├── ...
├── server(root)
│   ├── bin(root 755)
│   │   ├── caddy(web:web 755)
│   │   ├── komari(komari:komari 755)
│   │   ├── frp(frp:frp 755)
│   │   └── ...
│   ├── logs(root 700) #systemctl日志全记录
│   ├── web-conf(web:web 500) #这里也可以root:web 750
│   └── ...
├── www(web 755)
│   └── ...
└── swapfile(root 600)

只展示大概配置，不展示SSL证书位置等敏感信息，免得又有黑客通过php搞我。。。🔒

⚙️ 系统配置

本人偏好Ubuntu，以下命令均支持直接在ssh命令行中输入。

更改默认主机名

sudo hostnamectl set-hostname NEW-HOST-NAME

💾 配置虚拟内存（/swapfile可替换）

free -m #查看 Linux 当前分区情况
swapoff -a #如果是增加 swap 分区，则先把当前所有分区都关闭了，没有swap分区不用这一步
dd if=/dev/zero of=/swapfile bs=1M count=2560 #创建要作为 Swap 分区的文件
mkswap /swapfile #建立 Swap 的文件系统
chmod 600 /swapfile #设置权限
swapon /swapfile #启用 Swap 分区
free -m #查看 Linux 当前分区
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab #永久化，重启不掉

🚀 开启 BBR

sudo sh -c 'echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf'
sudo sh -c 'echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf'
sudo sysctl -p

📦 软件配置

🟢 Caddy

为了避免被诸如crt.sh的网站通过证书的方式扫二级域名，我决定使用泛域名证书，所以我需要安装cloudflare-dns插件，使用的方式为编译安装。此处不做详解。快捷安装指令： sudo apt update && sudo apt install caddy Caddyfile参考配置：

{
    admin off
    email abc@example.com
    http_port 80 #其实建议把这行删了禁用http
    https_port 443
}
*.example.com {
    header / Strict-Transport-Security "max-age=63072000"
    encode gzip
    tls {
        dns cloudflare {env.CF_API_TOKEN} #这个api建议配在环境变量
        protocols tls1.2 tls1.3
        ciphers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    }
}
example.com {
    header / Strict-Transport-Security "max-age=63072000"
    encode gzip
    tls {
        dns cloudflare {env.CF_API_TOKEN} #这个api建议配在环境变量
        protocols tls1.2 tls1.3
        ciphers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    }
    redir https://www.example.com #重定向
}
www.example.com {
    #上面的证书配置会自动应用
    root * /path
    encode gzip zstd
    file_server
}
#导入配置；后缀随意；支持通配符；注意权限
#import /path/*.conf

🐘 PHP-FPM

为了目录配置的一致性，借助AI完成了编译安装，此处不做讲解。快捷安装指令（以8.1版本为例）： sudo apt update && sudo apt install php8.1-fpm

📊 Komari & Agent

使用wget下载二进制文件安装，需要配置权限。 ::github{repo="komari-monitor/komari"}

🔀 frp

使用wget下载二进制文件安装，需要配置权限。 ::github{repo="fatedier/frp"}

测试了网站访问，流畅度不错；流式传输也非常不错。✨ 由于cloudie的原因无法进行tcp测速，提供全国延迟图片。

到这里主力的机器就变成了这台HK线路机了，不过原来那台vps我打算留着继续用。一来是这个vps上还有挂着cf的服务，如果使用我珍藏的反代ip来访问的话速度优异；⚡ 二来这台机器的性能、到HK的互联都不错，以后有需要mysql的话可以挂在这台机器上；🗄️ 再说挂在komari上拿来展示也挺不错。📊

文章为本人撰写；让gpt帮我加了emoji；封面为gpt生成。

记一次小鸡被偷偷拿去挖矿的经历——该博客的来历

Mon, 14 Sep 2026 00:00:00 GMT

从配好环境开始，vps的内存一直是爆满的。起初我是认为我在上面挂了mysql+xray+caddy+php+frp，本来内存占用就大，所以正常。后来发现这个异常的内存占用似乎影响到我其他服务的性能了，于是把php和mysql关了。但是故障依旧，然后使用top命令发现了一个奇怪的进程。

该程序使用web用户启动，我当时还以为是caddy的子进程，因为mysql和php都被我关掉了。因为cpu的占用很低我没往挖矿方面想。不过我在好奇心的驱使下，顶着黑眼圈跟gpt畅聊发现这就是挖矿软件，然后畅聊了2个小时的样本保存、解决方案等。居然就这么被白嫖了1个月。

有意思的东西：

在wp的根目录下发现了一个编辑于8/12的权限为644的0x.txt文件，内容为"chinafans"（纪实），这说明为人工攻击，非脚本自动攻击。

然后我按照gpt的指示查了一下目录，发现这个攻击者把每一个修改过的文件都留下了.bak后缀的原始文件备份。

种种反常现象感觉这人像是来玩的，因为这种小鸡配置这么低我个人认为是没多少收益的，而且作案痕迹也太多了。。。

攻击者分别在08/12、08/17和09/02攻击了4次

8/12 生成了1个0x.txt 8/13 更改wp套件 8/17 第一次上传挖矿木马，币种：门罗币，XMRig套件+保活 9/02 第二次上传挖矿木马，似乎把性能占用调高导致我的xray以及caddy等正常程序卡顿。

因为时间太久了我这里的日志只记录到09/07，再之前的就没有了。

攻击链条梳理：

WordPress漏洞 -> 将木马套件上传到wp-plugins目录 -> 通过php修改文件，留下信息，启动木马。

wp内部的四个文件夹权限都是默认的，都有x权限，其他php文件没有，似乎是通过这个来操作的。万幸的是php是使用的web用户来启动的，如果是root用户那只能重装了。

大家如果有挂wordpress的话可以检查一下有无类似情况，我这边已经换astro了。如果你的wordpress文件夹权限为777那就非常危险了，我这里的的日志监测到一堆脚本在扫wp目录。如果你还没中招，赶紧自查文件夹权限，或者换一套架构；更新版本。

为防止意外情况发生，不提供木马样本。