👤 定制规范命名: 所有订阅节点均重命名为
国旗 地区 序号 (家宽) - xiaohe
⚡ 真实可用保障: 所有节点由Xray-core建立实际代理隧道并完成真实 HTTPS 双向传输握手，拒绝虚假通畅与死节点。无论是通过免翻 CDN 直链还是官方原生 Raw 直链拉取，节点命名格式完全一致。
客户端 / 格式类型 |
节点总数 |
免翻 CDN 订阅直链 (国内直连) | 官方原生 Raw 直链 (开启代理) |
|---|---|---|---|
| 🚀 Clash (YAML 格式) | 1091 |
🚀 免翻 CDN 直链 | 🌐 官方 Raw 直链 |
| ⚡ V2RayN (Base64 格式) | 1091 |
⚡ 免翻 CDN 直链 | 🌐 官方 Raw 直链 |
| 📦 sing-box (JSON 格式) | 1091 |
📦 免翻 CDN 直链 | 🌐 官方 Raw 直链 |
经 MaxMind ASN 数据库与核心运营商白名单严格探测，排除所有云主机/数据中心及 CDN 任播，保留真实民用宽带。
| 家宽地区 | 节点数 | V2RayN 专属订阅 | Clash 专属订阅 | sing-box 专属订阅 |
|---|---|---|---|---|
| 🇰🇷 韩国 (South Korea) | 8 | CDN 直链 · Raw 直链 | CDN 直链 · Raw 直链 | CDN 直链 · Raw 直链 |
| 🇹🇼 中国台湾 (Taiwan) | 4 | CDN 直链 · Raw 直链 | CDN 直链 · Raw 直链 | CDN 直链 · Raw 直链 |
| 🇭🇰 中国香港 (Hong Kong) | 1 | CDN 直链 · Raw 直链 | CDN 直链 · Raw 直链 | CDN 直链 · Raw 直链 |
如果你希望将本 GitHub 仓库设置为 Private (私有仓库) 保护节点资产，外部客户端无法直接拉取原生 Raw 或公共 CDN 链接，可以通过以下 Cloudflare Worker 搭建轻量级私密网关反代：
- 进入 GitHub -> Settings -> Developer Settings -> Personal access tokens (classic)。
- 点击 Generate new token (classic)，勾选
repo权限，有效期设为No expiration（永不过期）。 - 复制保存生成的以
ghp_开头的 Token。
登录 Cloudflare Dashboard，创建一个新的 Worker，复制以下脚本粘贴并部署：
export default {
async fetch(request) {
const GITHUB_TOKEN = "ghp_你的GitHub永久访问令牌";
const OWNER = "hezhanleiok";
const REPO = "freesub";
const BRANCH = "main";
const url = new URL(request.url);
const filePath = "output" + url.pathname;
const ghUrl = "[https://raw.githubusercontent.com/](https://raw.githubusercontent.com/)" + OWNER + "/" + REPO + "/" + BRANCH + "/" + filePath;
const res = await fetch(ghUrl, {
headers: {
"Authorization": "token " + GITHUB_TOKEN,
"User-Agent": "Cloudflare-Worker"
}
});
if (!res.ok) {
return new Response("Not Found", { status: 404 });
}
return new Response(await res.text(), {
headers: {
"Content-Type": "text/plain; charset=utf-8",
"Cache-Control": "no-cache"
}
});
}
}部署后 Worker 会分配一个专属域名（例如 my-sub.yourname.workers.dev），你的客户端可以直接无感订阅：
- 总 V2RayN 订阅:
https://你的域名.workers.dev/v2ray.txt - 总 Clash 订阅:
https://你的域名.workers.dev/clash.yaml - 总 sing-box 订阅:
https://你的域名.workers.dev/singbox.json - 台湾家宽 V2RayN:
https://你的域名.workers.dev/residential-by-country/TW.txt - 香港家宽 Clash:
https://你的域名.workers.dev/residential-by-country/clash-HK.yaml - 日本家宽 sing-box:
https://你的域名.workers.dev/residential-by-country/singbox-JP.json
- 自动更新机制：GitHub Actions 每 6 小时全自动运行并刷新上述全部订阅与数据。
- 多客户端兼容：
- Clash / Clash Verge / Mihomo Party：直接复制上方表格中的 Clash 专属订阅 链接。
- v2rayN / v2rayNG：直接复制上方表格中的 V2RayN 专属订阅 链接。
- sing-box：直接使用上方 sing-box 专属订阅 链接。
from https://github.com/hezhanleiok/freesub
------------------------------------------------------------
免费订阅freesub2.0更新获取包含家宽住宅IP原生IP一键部署自己的专属订阅
网上免费节点订阅池很多，但几乎都有一个通病：节点数量看着很可观，导入客户端后真正能连上的没几个。这篇文章记录了我对免费订阅池的一次彻底重构 —— 从测活引擎、国家归类、家宽识别到导出格式全部重写，并用真实测量数据对比新旧两版的准确率。文末还整理了几个很有意思的"特殊情况"，比如同一个 IP 在不同风险检测网站上判定完全相反、机房伪装家宽的识别等，都是实际踩坑的记录。
测量方法说明：文中所有数字均来自 GitHub Actions 真实运行日志与本地对照实验（样本量 4000-5000 节点/轮），不是估算值。📑 目录一、旧版到底有多不准二、新版架构全景三、节点有效性检测对比四、国家归类准确率五、家宽识别：四道闸门六、导出保真：最隐蔽的坑七、速度：快了 80%八、特殊情况合集（重点）一、旧版到底有多不准：逐环节体检
旧版用 Xray-core 1.8.24（2023 年的老内核）做测活，整条链路是"抓取 → 字符串解析 → 测活 → 按入口 IP 归类 → 原样转发 URI"。重构前我先做了一次全面审计，每个环节的问题都拿到了实测证据：
环节 旧版实现 实测问题 协议支持 仅 vless/vmess/trojan/ss 四协议 Hysteria2/TUIC/AnyTLS 全部解析失败直接丢弃 —— 而这三类恰是近年新节点的主力 存活判定 sleep(0.35)固定等待 + 单次 6.5s 探测慢启动节点 6.5 秒内没完成握手就被误杀；死节点又烧满 6.5 秒才放弃 断流/MITM 检测 完全没有 "连得上但带宽趋零"的断流节点、TLS 证书被劫持的中间人节点照常入库 国家归类 查入口服务器 IP 的归属地 中转/隧道节点的入口国 ≠ 出口国，归类必然错误，还制造出大量"其他地区" 家宽识别 硬编码 ASN 列表 + ISP 关键词 机房收购的老家宽 IP 段 rDNS 带 .dsl关键词 → 机房被当成家宽重复节点 不去重 同一节点被 10+ 个订阅源重复收录，每个都测一遍，CI 跑 40+ 分钟 导出格式 原样转发上游 URI 实测 262 个节点里 145 个（55%）字段损坏 —— 客户端"解析失败"的元凶 💡 最意外的发现：导出环节。我写了一个"保真度回归测试"（URI → 解析 → 测活 → 导出 → 再解析 → 逐字段对比），结果 55% 的节点在导出后丢了参数 —— trojan 的 WebSocket path/host、vless 的 0-RTT/指纹/h2 host、vmess 的 grpc serviceName 全部静默丢失。这些节点测活时是活的，到了用户手里就是死的。二、新版架构全景
新引擎换成 sing-box v1.14.0（官方最新版），每个节点起独立进程 + 临时 SOCKS 入站，走完整代理隧道做真实请求。核心链路变成：
抓取订阅源 ──→ 解析校验 ──→ ★测前去重 ──→ sing-box 真隧道测活
│
├─ check 预校验 → 分层探测 (首探12s/重试4s) → 真实出口IP
├─ 断流检测 (70KB/s 阈值) + MITM 证书校验
├─ 六信号家宽识别 → ★链式双跳复测
└─ ★roundtrip 保真导出 → 三格式 + 分国家 + 家宽专区 + CDN 缓存刷新标 ★ 的环节为全新增加。下面逐项对比数据。
三、节点有效性检测：从"单次盲测"到"五重裁决"
✕ 旧版判定方式固定sleep(0.35)等进程起来，单次 6.5s 请求 generate_204，通了就算活。一个探测点、一次机会、一种视角。✓ 新版判定方式SOCKS 端口主动轮询就绪（替代盲等）→ 首探 12s 容慢启动 + 多探测点重试（各 4s）→ 断流检测（5MB 限时下载，<70KB/s 判死）→ MITM 证书校验 → 链式双跳复测。指标 旧版 新版 提升 协议覆盖率 4/8（50%） 8/8（100%） hy2/tuic/anytls 从全部丢失到全支持 慢节点误杀率 常见（6.5s 硬限） ≈0（12s 首探+多端点） 慢启动节点不再被冤杀 断流节点拦截 0（无此检测） 实测单轮拦截 188 个 "连得上但没带宽"的节点绝不再入库 MITM 劫持拦截 0（无此检测） 实测单轮拦截 36 个 证书被劫持的高危节点直接剔除 链式代理可用性 不检测（实测约 50%） 双跳复测（7 候选筛掉 1） 家宽区节点全部经过链式验证 🔗 关于"链式双跳复测"（本版核心创新）：很多用户像我一样在 v2rayN 里开前置代理（链式代理）用节点。实测发现"单跳测活通过"不等于"套上前置还能用"—— 部分服务端拒绝"已被代理的流量"再入站。新版在测活后，用当轮延迟最低的存活节点做前置，把家宽候选全部双跳复测一遍（前置 → 家宽节点 → 204），双跳失败的降级到普通区。这精确模拟了真实链式使用场景。四、国家归类：从"看门牌"到"看落地"
旧版查入口服务器 IP 的归属地 —— 这就像看"你要进的那扇门在哪个小区"来判断你到了哪个国家。但中转/隧道节点的入口和出口根本不在一个国家，归类必然错误。
新版改为在节点隧道内部请求 IP 识别服务，拿到真实出口 IP 再归类 —— 你从节点出来落地在哪，就归哪个国家。三级兜底：在线识别（ip.sb/ipinfo/ip-api 三源）→ MaxMind 离线库 → 入口 IP 回退（仅当出口是云内网地址查不到时）。
✕ 旧版归类误差来源- 中转节点：入口国 ≠ 出口国 → 100% 归错
- 套 WARP 的节点：出口被 Cloudflare 掩盖
- 查不到就丢进"其他地区"（实测一轮 40KB 的 OTHER 文件）
✓ 新版归类精度- 出口 IP 直查：中转节点归类正确率从 0 → 100%
- WARP 套壳检测：trace 里 warp=on 的节点单独标记
- "其他地区"只保留真正无法定位的节点，命名统一国旗+中文国名+英文缩写
五、家宽识别：四道闸门，专打"伪装家宽"
这是整个重构里最有意思的部分。免费池里标榜"家宽/住宅 IP"的节点，大多数是伪装的。最典型的伪装手法：机房收购倒闭运营商的 legacy 家宽 IP 段 —— IP 数据库里它还显示为宽带运营商，rDNS 还带
.dsl / .pppoe后缀， ASN 却早已转手给云商。真实案例：一个骗过了旧版的"美国家宽"
节点名称：🇺🇸 美国 02 (家宽)
出口 IP：66.93.128.123
rDNS：dsl093-128-123.sfo4.dsl.speakeasy.net ← 看起来是 DSL 家宽
ASN：AS62610 Zenlayer Inc ← 实际是云边网络商
ip-api 判定：hosting=false，proxy=true（代理/VPN 出口标志）
ipapi.is：company = "Bunny Communications"（CDN 公司！）
ping 测试：落地荷兰阿姆斯特丹 ← 和"美国家宽"毫无关系
▸ 旧版判定：residential（被 rDNS 的 "dsl" 关键词骗了）
▸ 新版判定：四道闸门全部否决，降级为普通机房节点新版四道闸门
1ip-api 在线字段硬判：hosting=true → 机房；proxy=true → 硬否决家宽（本案例的关键 —— 旧版根本没检查 proxy 字段）。实测该字段对"机房收购家宽段"的伪装识别率极高。2ASN 黑白名单：60+ 主流云商 ASN 黑名单（含实测漏网的 Zenlayer AS62610 等 12 个云边网络）+ 300+ 各国主流民用宽带运营商 ASN 白名单。3ipapi.is 交叉源否决：独立数据源二次核验，company/ASN 里含云商关键词（Bunny/Zenlayer/Cloudflare/GCore 等 20+ 个）直接否决。防止单一数据源被"洗白"。4Scamalytics 欺诈分 + 链式双跳复测：欺诈分 ≥75 降级出普通区、≥90 整体剔除（fraud 池滥用 IP）；家宽候选最后过链式双跳复测。宁缺毋滥。四道闸门过完，家宽专区里每个节点都同时满足：真住宅 IP（四源验证）+ 无欺诈记录 + 链式场景实测可用。代价是数量少了 —— 免费池里真家宽本来就是稀缺资源，但留下来的每一个都是真金。旧版那种"8 个家宽里 1 个是荷兰机房"的情况不会再有。
六、导出保真：最隐蔽的 55% 损坏率是怎么修的
测活再准，导出时把参数弄丢，用户手里还是死节点。旧版实测 262 个节点里 145 个（55%）导出后字段损坏。新版的做法是在 CI 里内置"保真度回归"：每轮导出后，抽样把 URI 再解析回来和原始字段逐项对比，任何丢失直接在流水线内拦截。
典型损坏（旧版） 后果 trojan 导出丢 ws 的 path/host trojan-ws 节点 100% 不可用 ss 导出砍掉 base64 padding（ rstrip("=")）v2rayN 直接"解析失败"（韩国家宽节点事件的元凶） hy2 密码含 ://时正则断裂整个节点被丢弃 vless 导出丢 0-RTT/alpn/指纹/h2 host 复杂传输节点大面积不可用 vmess grpc 的 serviceName 不写入 grpc 节点全部废掉 修复后实测：24/24 样本（19 标准 + 5 边界样本）roundtrip 零字段丢失；真实节点端到端复测导出 URI 5/5 无损。损坏率 55% → 0%。七、速度：40 分钟 → 8.4 分钟
指标 旧版 新版 变化 单轮 CI 总耗时 40+ 分钟 502 秒 ↓ 约 80% 实测节点数 4811 全量（大量重复） 2787（凭据指纹去重） ↓ 42% 测活并发 24 48 ×2 死节点耗时 6.5s × 3 次重试烧满 首探 12s / 重试 4s 分层 快慢两不误 测前去重是提速关键：同一节点被多源重复收录时（免费池常态，最多见 30+ 份"不同名字"的同款节点），按服务器+端口+协议+凭据指纹只测一次，其余克隆继承测活结果。同凭据+同目标的服务端行为必然一致，这是数学不是赌运气。
八、特殊情况合集：那些"检测网站互相打架"的坑
重构过程中遇到的几个非典型问题，单独列出来 —— 如果你也在做类似的池子或纠结节点质量，这些坑大概率会撞上。
坑 1：ping0.cc 说"高风险"，Scamalytics 却打 2 分 —— 听谁的？
实测一个 GCP 台湾机房的节点：我们管道的 Scamalytics 欺诈分只有 2/100（极低危），正常入库；用户拿到后在 ping0.cc 一查，显示"高风险"。两个网站对同一个 IP 给出完全相反的结论。
原因：不同厂商用不同的风控数据库和评分模型。机房 IP（尤其 GCP/AWS/Azure 这种大厂段）在免费代理池里被滥用得极其严重，在一些厂商的库里早就是"惯犯画像"；在另一些厂商的库里则只看实时行为评分。结论：单一检测网站的判定不能当真理，交叉验证才有意义。这也是家宽识别为什么要用四道闸门而不是单一数据源。
坑 2：ping 显示荷兰、IP 网站显示美国 —— 节点到底在哪国？
还是上面那个 Zenlayer 节点：Windows ping 显示落地荷兰北荷兰省阿姆斯特丹，另一个 IP 查询网站显示美国，两个网站显示的 IP 地址却完全相同。
原因：这类云边网络用 anycast 或收购多国 IP 段，不同地理库的登记滞后且互相打架。解法：多家交叉 —— 我最终接入了 ipapi.is 作为仲裁源之一（它正确给出了 Bunny Communications/Zenlayer 的公司归属），国家归类以出口实测为准而不是任何单一网站的库。
坑 3：CDN 订阅比 RAW 订阅少节点 —— 不是 bug 是缓存
用户反馈：台湾家宽订阅走 CDN 链接只更新出 2 个节点，RAW 链接却有 4 个。第一反应以为是导出 bug，排查后发现两个文件内容完全一致 —— 是 jsDelivr CDN 边缘节点缓存滞后，拿到的是几小时前的旧文件。
解法：CI 每轮跑完调用
purge.jsdelivr.net主动刷新全部订阅文件的 CDN 缓存。实测刷新后 CDN 立即与 RAW 一致。做订阅池的记住这条：**内容对但 CDN 旧，用户永远先怀疑你**。坑 4：Hysteria2 节点开前置代理基本不能用 —— 架构性限制
用户在 v2rayN 里开链式前置后，hy2 节点几乎全军覆没，一度怀疑测活有问题。
原因：Hysteria2 基于 QUIC/UDP，而 SOCKS5 前置链对 UDP-over-TCP 的转发支持天然残缺 —— 这不是节点死了，是协议形态不适合套链。直连或单层使用时这些节点完全正常（测活数据可以证明）。启示：按使用场景分流 —— 链式用户少碰 hy2，追求低延迟直连用户优选 hy2。
坑 5：CI 在海外跑，用户在国内用 —— 视角差异是物理鸿沟
有人问：CI（GitHub Actions，美国 Azure 出口）测活通过率挺高，为什么我国内不开前置只有 10% 能用？是不是把国内能用的都排除了？
实测结论：对 1364 个去重节点逐一查入口归属 —— 0 个入口在中国大陆。免费池节点全部是海外入口，不存在"国内中转被误杀"的形态；差异纯粹来自 GFW 对链路的干扰（IP 封锁/SNI 阻断/协议指纹识别），这是物理位置决定的视角差异，任何海外 CI 都测不到"从中国直连是否被墙"。要测这个视角只有两条路：国内机器定时复测，或国内服务器做测活前置。目前的选择是如实标注视角：CI 订阅 = 海外视角可用性，链式/前置场景用户用双跳复测过的家宽专区。
总结：一张表看完全部升级
维度 旧版 新版 测活引擎 Xray-core 1.8.24（停更） sing-box v1.14.0（全协议） 协议覆盖 4 协议（50%） 8 协议（100%） 导出损坏率 55%（145/262） 0%（roundtrip 拦截） 断流 + MITM 拦截 无 实测一轮拦 188 + 36 个 国家归类 入口 IP（中转必错） 真实出口 IP + 三级兜底 家宽识别 ASN+关键词（会被伪装骗） 四道闸门 + 链式双跳复测 重复测试浪费 全量重复测 凭据指纹去重 −42% 单轮 CI 耗时 40+ 分钟 502 秒（↓80%） CDN 分发一致性 缓存滞后（CDN≠RAW） 每轮主动 purge 写在最后免费节点池的本质矛盾：你永远无法让"免费、公开、稳定"三者同时成立 —— 节点本身会死、会被滥用、会被墙，这是池子的宿命。但工程能保证的是：测活环节不冤枉活节点、不放进来死节点，识别环节不打错标签，导出环节不丢参数，交付环节不缓存旧文件。这四件事做到位，"看着能用"就变成了"真的能用"。
如果你也想搭一个这样的池子，或者对某个细节的实现感兴趣，欢迎留言交流。全部流水线代码和每轮实测日志都在仓库里，透明可审计。
No comments:
Post a Comment