Free V2Ray Configs — auto-aggregated, CDN-aware deduplicated, client-validated, reachability-tested

下面每一个计数器都实时读取自本仓库自己的 index.json / health.json —— 它们不可能过期：

🇬🇧 English version · 🇮🇷 نسخهٔ فارسی · 🇷🇺 Русская версия

🚀 从这里开始 —— 复制一行就够了

Top 100 是通往可用连接的最短路径：它是 verified 列表按中位延迟排序后取最快的 100 条，小到可以导入任何客户端，而且每一条都已经三次回应过真实请求。

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/top100.txt

想要超过 100 个服务器？那就取完整的 verified 列表 —— 同样的证据标准，只是更长：

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs_base64.txt

📱 用手机？把客户端的扫码器对准下面任意一个。

_{每个二维码编码的都是订阅 URL 本身 —— 你的客户端每次都会拉取最新列表，而不是一份冻结的快照。}

⚡ 订阅链接

不确定该用哪个？ 用 verified —— 它的每一条都在全部三轮独立测试中，经由代理成功完成过一次真实的 HTTP 请求：
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs_base64.txt
想要尽可能大的列表而不是最可靠的列表？把 verified 换成 all。

🎛️ 选择一个档位（tier）

每次运行都会发布六个档位。它们不是不同的来源 —— 而是同一个池子，按「有多少证据表明这个配置真的能用」过滤出来的结果。

档位	什么样的配置能进	纯文本	Base64	Clash	Sing-box
🏆 `verified`	在全部 3 轮中都通过了经由代理的真实请求 —— 推荐	txt	b64	yaml	json
⚡ `fast`	`verified` 且中位延迟 `< 800 毫秒`	txt	b64	yaml	json
🔐 `secure`	`verified` 且具备前向保密，且链接没有关闭证书校验	txt	b64	yaml	json
🌐 `all`	全部内容，已去重 —— 列表最大，但大部分未经测试	txt	b64	yaml	json
📦 `heavy`	只含 14 个大量上游	txt	b64	yaml	json
⭐ `light`	只含 7 个精选 / 经过测速的上游	txt	b64	yaml	json

该用哪种格式？ configs_base64.txt 是经典的订阅格式，也是最稳妥的默认选择。 configs.txt 是同一份列表的未编码版本。clash.yaml 是完整的 mihomo/Clash 配置文件； singbox.json 是完整的 sing-box 配置 —— 两者在发布前都会由真实的二进制程序校验（见下文）。

📋 复制粘贴：全部档位的 URL

# ── verified —— 通过全部 3 轮（推荐）─────────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/singbox.json

# ── fast —— verified 且中位延迟 < 800 毫秒 ──────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/singbox.json

# ── secure —— verified 且具备前向保密 ───────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/singbox.json

# ── all —— light + heavy，已去重 ────────────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/singbox.json

# ── heavy —— 大量上游 ───────────────────────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/singbox.json

# ── light —— 精选上游 ───────────────────────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/singbox.json

# ── top 100 —— verified 列表按中位延迟排序 ──────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/top100.txt

🎯 按协议分类的链接

从 all/ 拆分出来。文件只在非空时才会发布，所以 404 意味着「本轮没有该协议的内容」 —— 而绝不会是一个会清空你客户端列表的空订阅。

协议	纯文本	Base64
VLESS	`…/main/protocols/vless.txt`	`…/main/protocols/vless_base64.txt`
VMess	`…/main/protocols/vmess.txt`	`…/main/protocols/vmess_base64.txt`
Trojan	`…/main/protocols/trojan.txt`	`…/main/protocols/trojan_base64.txt`
Shadowsocks	`…/main/protocols/shadowsocks.txt`	`…/main/protocols/shadowsocks_base64.txt`
ShadowsocksR	`…/main/protocols/shadowsocksr.txt`	`…/main/protocols/shadowsocksr_base64.txt`
Hysteria2	`…/main/protocols/hysteria2.txt`	`…/main/protocols/hysteria2_base64.txt`
TUIC	`…/main/protocols/tuic.txt`	`…/main/protocols/tuic_base64.txt`
SOCKS	`…/main/protocols/socks.txt`	`…/main/protocols/socks_base64.txt`

📎 全部协议 URL（复制粘贴）

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vless.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vless_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vmess.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vmess_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/trojan.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/trojan_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocks.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocks_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocksr.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocksr_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/hysteria2.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/hysteria2_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/tuic.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/tuic_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/socks.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/socks_base64.txt

hysteria · wireguard · juicity · anytls · snell · mieru 同样能被解析器识别，但在下面这次快照中为空 —— 没有任何上游发布它们。当前确实存在哪些协议文件，以 index.json 的 protocol_files 块为准，那才是权威且始终最新的列表。

🧭 机器可读的元数据

文件	是什么
`index.json`	全部计数器、时间戳、下次更新预计时间，以及每个文件的 URL（raw + 镜像）
`health.json`	逐源健康状况、转换器丢弃数、地理统计，以及完整的 `cascade` 测试报告
`state.json`	逐源产出量的滚动历史与自动停用决策
`top100.txt`	延迟最低的 100 个 verified 配置
`archive/all_broken.txt`	被拒绝的内容，刻意保持可见（另有 `_base64` 与 `heavy_broken*`）

🪞 镜像（jsDelivr）—— 仅在 `raw.githubusercontent.com` 被封锁时使用

把前缀 https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main 替换为 https://cdn.jsdelivr.net/gh/0xRadikal/Free-v2ray-Configs@main —— 上面的每一个路径在镜像上都原样存在。

https://cdn.jsdelivr.net/gh/0xRadikal/Free-v2ray-Configs@main/verified/configs_base64.txt

能用 raw 就优先用 raw。 这是本仓库自己的 link_policy，不是主观意见：

	缓存指令	最坏情况下的过期程度
`raw.githubusercontent.com`	`max-age=300`	5 分钟
`cdn.jsdelivr.net`（分支引用）	`s-maxage=43200`	12 小时 —— 长 144 倍

CDN 每次运行都会被清除，但清除只作用于边缘节点；jsDelivr 自身的源站在重新解析分支名时仍可能滞后。如果你需要通过 CDN 获得一份保证完全一致的副本，请固定某个 commit 而不是分支：@<commit-sha>/…。

📌 所有内容都在默认分支（main）上。 无需切换分支，没有隐藏位置 —— 你几个月前复制的链接依然有效。为什么这件事并不像听上去那么理所当然：发布为何依然廉价。

🧪 它真的能用吗？

大多数免费配置仓库只公布一个很大的数字，然后让你自己猜。这里给出的是经过实测而非估计的、并不好听的答案：任何免费配置池在任何时刻都有绝大多数是死的。这是免费配置本身的属性，而不是本仓库的问题 —— 所以与其掩盖它，每次运行都会测量它并据此排序。

每个配置都会经过四个阶段。每个阶段都足够便宜，可以跑遍整个池子，并且每个阶段都会丢掉下一阶段本来会白费的工作：

The four-stage pipeline: collect, repair, dial, prove, publish

阶段	它在问什么	代价
L0 / L1	能否解析？端点是否唯一、是否可路由？	不走网络
L2	TCP 端口是否真的接受连接？	每个唯一端点一次连接
L3	经由该代理的真实 HTTP 请求能否成功？	完整握手，重复 3 次
buckets	哪些通过了每一轮 L3？	仅排序

只有通过了每一轮的配置才会进入 verified/ —— 绝不会只看它最好的一轮。

📉 一次真实发布上的漏斗

快照：2026-08-02 08:38:43 UTC · 本次运行耗时 213 秒 · 测试在 🇺🇸 美国 runner 上进行（Cloudflare 机房 IAD）

阶段	配置数	占池比例
从 17 个存活的源采集到	14,212	—
经 CDN 识别去重后的唯一数	10,118	100 %
结构上有效 (L0/L1)	10,071	99.5 %
TCP 端口开放 (L2)	5,285	52.2 %
至少成功一次 (L3)	1,231	12.2 %
在全部 3 轮中都成功 → `verified/`	856	8.5 %

三轮 L3 各自返回了 1,040 / 1,069 / 1,074 次成功 —— 但同时出现在这三个集合中的只有 856 个配置。在所有曾经成功过的配置里，30.46 % 是不稳定的。若发布「所有成功过一次的」，结果会被高估 1.44 倍；若发布最好的单轮，会被高估 1.25 倍。这个差距正是 L3 阶段要跑不止一次的全部理由。

⚠️ 引用这个百分比之前请先读这段

8.5 % 不是一个常数，也不是对你的网络的判断。 它是在一台主机上、在美国、在某一天测得的。一个从弗吉尼亚的 GitHub runner 连不上的配置，可能从德黑兰完全可用 —— 反过来同样成立。

所以：verified/ 的含义是「这个配置回应了来自运行测试那台机器的真实请求」，而不是「这个配置对你也能用」。 你正在下载的那一次发布的实际数字，以及测试所在的国家，都记录在 health.json 的 cascade 块中。请相信那个文件，而不是本 README 里的任何数字 —— 后者按其本质就是一份带日期的快照。

📊 那次快照测到的其他一切


各档位规模	`all` 10,118 · `heavy` 8,409 · `light` 2,521 · `verified` 856 · `fast` 578 · `secure` 495 · `top100` 100
协议分布	vless 3,655 · vmess 3,217 · shadowsocks 2,113 · trojan 978 · hysteria2 123 · shadowsocksr 28 · tuic 2 · socks 2
去重	移除 4,093 个重复；10,118 个配置收敛为 8,560 个唯一端点（节省 15.0 % 的 L2 工作量）
L0/L1 丢弃	共 47 条 —— 无法解析 18 · 服务器不可路由 16 · 服务器无效 10 · UUID 无效 2 · 端口无效 1
DNS	323 个端点在 L2 解析失败；6,237 个主机完成地理定位，303 个未知
转换器丢弃	Clash 47 · sing-box 364（其中 319 条在 sing-box 的 schema 中根本无法表达）
数据源	配置了 21 个（7 个 light + 14 个 heavy）· 17 个返回了配置 · 0 个为空 · 0 个失败
各阶段耗时	L0/L1 0.33 秒 · L2 33.5 秒 · L3 178.8 秒 · 合计 213.0 秒

✅ 每一次发布都经过真实客户端校验

只要有一条格式错误的记录，客户端就会拒绝整个文件 —— 所以「大部分有效」的输出毫无价值。在发布任何内容之前，每个生成出来的 clash.yaml 和 singbox.json 都会用你自己运行的同一批二进制程序去解析：

sing-box check -c <file>      # sing-box 1.13.14
mihomo -t -f <file>           # mihomo   v1.19.29

这两个二进制程序在工作流中下载时都是锁定版本并经过 SHA256 校验的。如果任何文件校验失败，本次运行中止，不提交任何内容 —— 上一个正常的发布原封不动地留在原地。

⚠️ 结构上有效并不等于能用。 结构上损坏的记录（全零 UUID、App not supported、不支持的加密方式、格式错误的 REALITY 密钥）会被丢弃 —— 但一个语法完美的配置仍然可能是死的。那是另一个问题，由上面的 L3 级联单独回答。

🏷️ 由内容派生的稳定名称

每个备注都会被重写为 {CC} {flag} | @Raydikalx | {id}，其中 {id} 是 sha256(dedup-key)[:6] —— 由配置本身派生，而不是由它在列表中的位置派生。因此同一台服务器永远得到同一个标签，你客户端里的节点名称在两次更新之间保持稳定，而不会每 15 分钟被重新打乱一次。

🗂️ 仓库结构

只有一个分支 —— main。 源代码与发布出来的产物并列放在默认分支上，这正是访客打开仓库时看到的内容。

机器生成、每次运行都会刷新（48 个文件）：

verified/   configs.txt · configs_base64.txt · clash.yaml · singbox.json   通过全部 3 轮 L3
fast/       configs.txt · configs_base64.txt · clash.yaml · singbox.json   verified + 中位 < 800ms
secure/     configs.txt · configs_base64.txt · clash.yaml · singbox.json   verified + 前向保密
all/        configs.txt · configs_base64.txt · clash.yaml · singbox.json   light + heavy，已去重
heavy/      configs.txt · configs_base64.txt · clash.yaml · singbox.json   14 个大量上游
light/      configs.txt · configs_base64.txt · clash.yaml · singbox.json   7 个精选上游
protocols/  vless.txt · vmess.txt · trojan.txt · … (+ *_base64.txt)        从 all/ 拆分
archive/    all_broken.txt · heavy_broken.txt (+ _base64)                  被拒绝的内容
top100.txt  延迟最低的 100 个 verified 配置
index.json  各项数量 · 时间戳 · 协议分布 · 每个文件的 URL
health.json 逐源健康状况 · 转换器丢弃 · 地理信息 · 完整的级联报告
state.json  逐源产出量的滚动历史与自动停用决策

人工编写、具有正常 git 历史与 blame：

scripts/    流水线 —— core · sources · filters · converters · geo · reachability
            realtest · pipeline · aggregate · validate · state (+ test_pipeline.py)
.github/    定时工作流 · Dependabot 配置 · issue 模板
docs/       实时状态面板（在浏览器中读取 index.json / health.json）
README.md · README_FA.md · README_ZH.md · README_RU.md
SECURITY.md · CONTRIBUTING.md · LICENSE

两条容易被忽略、却非常重要的规则：

空文件永远不会被发布。 protocols/ 或 archive/ 中的文件只在有内容时才会出现。空文件比 404 更糟：订阅了它的客户端会用「空」替换掉自己正在工作的列表，而 404 会让客户端保留它们已有的内容。
index.json 只公布确实存在的文件 —— 它的 URL 列表永远不会是仓库兑现不了的承诺。

🌿 发布为何依然廉价（以及为什么文件放在 `main` 上）

Git 永远不会忘记一个 blob。每次定时运行都会重新生成同一批大文件，而以常规方式把它们追加到分支上，会让每个变更过的文件在历史里永久多出一份新副本。这样发布成本就是 O(运行次数)，没有上界。按每天约 96 次运行计算，这不是理论上的担忧：本仓库的历史在修复之前已经涨到了 约 3.6 GiB。

❌ 错误的修法（试过，并已回退）

把产物移到一个孤立分支（orphan branch），并以单个提交强制推送。发布成本确实降到了 O(1) —— 同时项目悄悄坏掉了：

此前复制过的每个订阅链接都返回 HTTP 404。 客户端指向 …/main/all/configs.txt 的用户不会看到错误提示；订阅只是无声地变空了。
访客打开仓库根本看不到任何配置 —— 只有代码。大多数来找配置的人并不知道 git 分支是什么，更不会想到要切到第二个分支再看一次。
可发现性崩塌。 GitHub 搜索、仓库首页和搜索引擎索引的都是默认分支。
这个领域里没有任何一个成功的仓库这么做。 直接核查过： Epodonios/v2ray-configs、mahdibland/V2RayAggregator、Pawdroid/Free-servers —— 全都发布在它们各自的默认分支上。

如果没人能找到文件，廉价的历史一文不值。

✅ 正确的修法 —— 在 `main` 上做滚动压缩（rolling squash）

产物发布到默认分支，但该分支始终保持为源码历史 + 恰好一个产物提交：

找到最新的、没有标记 [auto-output] 的提交 —— 即锚点（anchor）。
构建一棵树 = 锚点的树 + 本轮新产物。
git commit-tree <tree> -p <anchor>，然后带 lease 推送。

上一个产物提交变为不可达并被垃圾回收。这一点直接从日志里就能读出来 —— 它严格交替出现，每个人工提交对应一个产物提交，无论中间跑了多少次运行：

94a939f23  bot     chore: update configs — 07:42 UTC — 10116 configs   ← 唯一存活的产物
e5a0e7dbf  human   docs: rebuild the status dashboard …
a72b66717  bot     chore: update configs — 22:12 UTC — 10146 configs
19b8d6cca  human   docs(security): document the branch and tag rulesets …

发布成本是 O(1) —— 同时每个文件都仍然停在用户和爬虫已经在找的位置上。

下面每一条安全性质都有可执行的测试来验证：

--force-with-lease，绝不用裸 --force。 发布指向的是人类也会提交的同一个分支，所以一次天真的强制推送会删除他们的工作。作为反向对照实验：使用普通 --force 时，远端上属主的提交数掉到了 0。使用 lease 时，真正发生竞争的推送会被拒绝，该步骤会重新取锚，属主的提交和新产物都得以保留。
源码回退防护。 锚点与分支顶端之间每一个有差异的路径都会被分类；如果产物集合之外的任何东西发生了变化，该步骤会拒绝发布，而不是回退别人的代码。
感知 shallow checkout。 actions/checkout 只取深度 1，所以通常唯一可见的提交就是一个产物提交，锚点搜索会找不到东西 —— 从而永久停止发布。该步骤会逐级加深（2 → 4 → 8 → 32）直到锚点出现。（fetch-depth: 0 被否决了：那意味着一天克隆若干 GB 达 96 次。）
处处 fail-closed。 产物缺失、配置文件小得可疑、或计算出的树为空，都会中止发布并保留上一个正常发布。
不会递归。 使用 GITHUB_TOKEN 发出的推送不会触发新的工作流运行，并且 push 触发器还额外限定在 scripts/** —— 机器人从不写入该路径。

🧊 产物刻意保持确定性

滚动压缩限制了历史体积；确定性则让每一轮的 diff 真正保持很小。通过测量发现并消除了三种无意义的抖动来源：

曾经	现在
国家标签取自最先抓到的那个上游 —— 同一台服务器在两次运行间 `RU 🇷🇺` ⇄ `US 🇺🇸` 来回跳	标签锁定到端点；第一次决定性的判定胜出并被冻结
备注标签是按位置的计数器 —— 插入一个配置就会重命名它之后的每一行	标签为 `sha256(dedup-key)[:6]` —— 由内容派生，与位置无关
行顺序跟随网络响应顺序	按去重键排序 —— 同一组配置产生同一个文件，逐字节相同

确定性不意味着文件不再变化；它意味着文件只在数据变化时才变化 —— 而过去那种在数据没有变化时也会发生的抖动，已经消失了。

🩹 一个诚实的保留问题

历史中已有的约 3.6 GiB 没有被重写。由于 GitHub 在 fork 网络内共享对象，重写几乎回收不到什么空间，却会破坏所有既有的 clone 和两个 fork。流血是从现在起止住了；旧的伤疤是刻意留着的。

📊 实时元数据 —— `index.json`

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/index.json

各类别的数量（唯一 / 重复 / 损坏 / 活跃源）、协议分布、最后更新时间戳、下次更新预计时间、每个文件的 URL（raw 主源 + CDN 镜像），以及一个说明该优先用哪个、为什么的 link_policy 块。

如果你要在本仓库之上构建任何东西，请读 index.json，而不要把路径硬编码 —— 它就是契约，而且它永远不可能公布一个不存在的文件。

🩺 源健康状况与测试报告 —— `health.json`

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/health.json

每次运行都会重新生成。对 21 个源中的每一个，记录 status（ok / empty / fail）、 HTTP 状态码、尝试次数、延迟、产出的配置数量以及最后一次错误 —— 这让失效或改动过的上游立刻可见，而不是让产出无声地缩水。

同一个文件还带有 cascade 块：这些数字来自生产这次发布的那台机器，而不是来自本 README。下面是上面那次快照的对应块（已精简）：

"cascade": {
  "exit_country": { "colo": "IAD", "loc": "US",          // 测试是从哪里跑的
                    "source": "https://cp.cloudflare.com/cdn-cgi/trace" },
  "layers": {
    "l0_l1": { "in": 10118, "out": 10071, "seconds": 0.33,
               "endpoints_unique": 8560, "dedup_saving_pct": 15.0,
               "dropped": { "unparsable": 18, "invalid_port": 1, "invalid_uuid": 2,
                            "unroutable_server": 16, "invalid_server": 10 } },
    "l2":    { "in": 10071, "out": 5285, "open_pct": 52.48,
               "open_pct_of_raw_input": 52.23, "dns_failed": 323,
               "dns_seconds": 17.52, "tcp_seconds": 15.58, "seconds": 33.47 },
    "l3":    { "in": 5285, "rounds": 3, "per_run_ok": [1040, 1069, 1074],
               "ever_ok": 1231, "stable": 856, "flaky_pct": 30.46,
               "seconds": 178.77 }
  },
  "buckets": { "verified": 856, "fast": 578, "secure": 495, "top": 100,
               "top_short_by": 0, "fast_threshold_ms": 800 },
  "total_seconds": 213.03
}

三个值得知道的细节：

exit_country 是测试所在的国家 —— 这是解读任何成功率时最重要的保留条件。只记录 loc 和 colo；runner 的 IP 地址刻意从不公布。
dropped 说明每个配置被拒绝的原因，因此某个源开始输出垃圾时会立刻可见，而不是让产出无声地缩水。
per_run_ok 与 stable 的对比直接展示抖动程度。stable 只统计通过了每一轮的配置 —— 而 verified/ 正是由它构建的。

📈 实时状态面板

https://0xradikal.github.io/Free-v2ray-Configs/

一个完全自包含的页面，在你的浏览器里抓取 index.json 与 health.json，并渲染出级联过程、各档位、逐源健康状况、地理分布与转换器丢弃情况。它发出零个外部请求 —— 没有 CDN、没有追踪器、没有外部字体 —— 并在 raw 不可达时自动回退到 jsDelivr 镜像。

⚙️ 工作原理

抓取 —— 并发下载 21 个源，自动识别 base64/纯文本。遇到瞬时错误会重试，但对 4xx 快速失败，这样一个失效的 URL 会被报告出来，而不是被无声地永远重试下去。
清洗 —— 丢弃假的以及结构上损坏的记录（全零 UUID、App not supported、空 proxies、不可路由的服务器）。
去重 —— 支持 CDN 识别的服务器身份指纹，因此位于轮换 CDN IP 之后的主机会收敛为一条记录，而不是出现几十次。
命名 —— 每个备注都被重写为 {CC} {flag} | @Raydikalx | {id}，{id} 由内容派生，国家标签锁定到端点。
转换 —— 按客户端做 schema 翻译，并严格校验字段：加密方式白名单、SS-2022 密钥长度、REALITY 的 uTLS、short-id/公钥格式检查，以及完整的传输层输出（ws / grpc / h2 / http / httpupgrade / xhttp）。客户端无法表达的条目会被丢弃，而不是被无声降级 —— 降级后的配置看起来有效，却永远连不上。
校验 —— 对每个生成文件执行 sing-box check + mihomo -t。任何失败都会中止本次运行。
测试 —— L0→L3 级联真的经由这些代理去连接，跑三次，并据此构建 verified/、 fast/、secure/ 与 top100.txt。
发布 —— 向 main 做滚动压缩提交，并清除 jsDelivr 缓存。

⏱️ 可靠的约 15 分钟调度

GitHub 的 schedule: cron 是尽力而为的，在繁忙时段经常被延迟或跳过。为了仍然保持稳定的节奏，本仓库采用三层方案：

高频 cron（*/5 * * * *）—— 让真正触发的机会更多。
新鲜度闸门 —— 如果 index.json 在 13 分钟内更新过，本次触发就立即退出，因此重活大约每 15 分钟才真正执行一次：不浪费运行，也不会重复更新。
repository_dispatch 兜底 —— 一个常开的机器人每 15 分钟发送一个 aggregate-now 事件，即使 cron 被完全丢弃也能保证有一次运行。同时也支持手动 workflow_dispatch （可带 force）。

🤝 参与贡献、安全、许可证


🐛 发现失效的源或有问题的配置？	开一个 issue —— 模板在 `.github/` 里
🔐 安全策略	`SECURITY.md`
📐 贡献指南	`CONTRIBUTING.md`
📜 许可证	MIT

🙌 数据来源

感谢每一位上游维护者 —— mahdibland、peasoft、mahsanet、barry-far、roosterkid、 4n0nymou3、ALIILAPRO、Epodonios、V2RAYCONFIGSPOOL、ShadowException、w1770946466 以及其他人。本仓库只做聚合、去重、校验与测试，处理的都是公开可得的配置。完整且当前的列表连同逐源健康状况都在 health.json 里。

📜 免责声明

仅用于教育与研究目的。不保证可用性或质量 —— 请看上面那份实测出来的现实，它之所以被公布，正是为了让这里没有任何东西需要你凭信任接受。请自行负责、并在符合你所在地法律的前提下使用。

有两件事让这个项目活着

这里没有注册、没有广告、没有付费墙，将来也不会有。真正让它活下去的那两件事，对你来说完全免费：

⭐ 一颗 star 是别人能找到这个项目的唯一途径。GitHub 的搜索和「相关仓库」都按 star 排序，所以一次点击真的会决定：下一个在找可用配置的人，能不能看到这个页面。

📣 @Raydikalx 是宣布故障、上游失效或链接变更的地方 —— 而且是在你察觉客户端安静下来之前。也欢迎在那里提问和报告有问题的配置。

💜 可选 —— 留个小费

这个页面上没有任何东西需要付费，将来也不会有：无论你是否读了这一节，上面的每一个链接都一模一样地可用。但如果这个项目帮你省下了一整晚寻找「真的能连上的配置」的时间，你可以发个小费。任何金额都很感激 —— 金额很小也完全没问题。

TRC20 —— Tron 网络

TYBumju6Mjd8JCn4RTq95Kk2HPsdcinuz5

EVM 链 —— Ethereum、BSC、Polygon、Arbitrum、Base、…

0x2F6ec47e416B42C623cF81a64266EE4910a698Cf

TON —— The Open Network

UQBbZrE5aDsdGVi6enpf_vPuG022W4KjkJNzTDkjVEn4gmu6

Important

请只在每个地址上方标注的那个网络上转账。每个二维码编码的就是印在它下面的那个地址，除此之外别无内容 —— 没有金额、没有 memo、没有代币合约 —— 所以二维码和文字是同一件东西的两种读法。你更信哪一种，就扫码或复制哪一种。

频道： @Raydikalx · 机器人： @RaydikalxBot · 面板： 实时状态

_{本 README 中写下的每一个数字都是带日期的快照。实时数字始终在
index.json 与
health.json 里。}

FilesExpand file tree

README_ZH.md

Latest commit

History