Back toWritings

Blink：从一条规则，到整份配置

Blink 是一个按 App 组织的分流规则与配置工具。它以一份规范规则为唯一来源，自动生成八个客户端的规则文件，并按固定顺序装配进用户配置。本文说明它的设计思想、运行机制与边界。

7 min readTechProjects

规则的难点不在编写，而在持续保持正确。

01｜概述

Blink 是一个按 App 组织的分流规则与配置工具，面向 Surge、Shadowrocket、Loon、Stash、mihomo、Egern、Quantumult X 与 sing-box 八个客户端。

它要解决三个常见问题：

  • 规则来源分散，同一份配置混用多位作者的清单，难以追溯；
  • 同一条规则在不同客户端写法不同，迁移客户端需要整体重写；
  • 规则失效通常没有报错，流量只会静默地走错策略组。

Blink 由两层组成：

层 内容 维护方式
规则层 每个 App 一份规则，生成八种客户端格式 每日北京时间 00:01 自动检查与发布
配置层 七个客户端的整份配置与网页上的配置生成器 人工修改、审核后发布

两层的分工基于一个判断：一个 App 连接哪些地址是事实，可以交给程序持续核对；先匹配什么、哪些直连、如何分组是选择，应由人决定。

截至 2026 年 10 月 15 日，Blink 收录 31 个 App，共 2314 条规范规则。网站为 blink.wendylala.com，规则文件发布在 byyoshen/Blink。

Blink 的规则流水线：收集原料、合成规范规则、自动检查、生成八种格式

02｜使用流程

网站的使用分为四步：选择客户端、选择 App、复制规则、在客户端中确认生效。

规则页：选中的 App 显示其策略组，可直接切换

复制时，每一行都是所选客户端的完整写法，策略组已填好。用户可以逐条添加，也可以整段复制；需要完整配置时，可在「整份配置」中直接生成。

完成页严格区分三种状态：

  1. 已复制：Blink 已把内容写入剪贴板；
  2. 已添加：用户在客户端中完成粘贴，由用户自行确认；
  3. 已生效：以客户端的请求记录为准。

Blink 只报告它自己完成的部分，不替用户声明未经确认的结果。

完成页：说明已完成的部分、剩余步骤与验证方法

此外有两条约束：用户填写的服务器地址只保存在页面内存中，不写入存储、不上传；未选择任何 App 时，不生成任何规则。

03｜单一规范源

Blink 不为每个客户端分别维护规则。所有规则只维护一份规范形式，再由渲染器生成各客户端的写法：

Surge         DOMAIN-SUFFIX,netflix.com
Quantumult X  HOST-SUFFIX,netflix.com,policy
sing-box      "domain_suffix": ["netflix.com"]

新增一个客户端只需新增一个渲染器，规则本身不变。

部分规则类型并非所有客户端都支持。例如 mihomo 与 sing-box 不支持按 User-Agent 匹配，Egern 与 Quantumult X 不支持按进程名匹配。对这类规则，Blink 的处理原则是：显式丢弃，并记录数量与内容，不以近似规则替代。近似替代不会报错，却会改变匹配结果。

因此，Netflix 在 Surge、Shadowrocket、Loon、Stash 中为 498 条，在其余四个客户端中为 497 条。差异在每个 App 的规则档案中逐项列出。

Netflix 规则档案：从上游 499 条到 Surge 498 条，每一步按实际条数绘制

已发布的规则地址保持不变。用户配置直接引用这些地址，任何改名都会使既有配置失效。

04｜规则顺序

客户端自上而下匹配规则，命中第一条即停止。因此，规则顺序与规则数量同样重要。

域名规则只需比较域名；IP 规则则需要先通过 DNS 解析出目标 IP。若 IP 规则排在前面，本可直接按域名分流的请求也会先在本地解析。这会暴露访问的域名，也可能使 CDN 返回不适合当前线路的地址。

Blink 采用的顺序是：全部域名规则在前，全部 IP 规则在后。这一思路来自 SukkaW。整份配置的完整顺序如下：

规则顺序：拦截与局域网、App 规则、国内与 CDN 清单、全部 IP 规则

通用清单（国内域名、CDN）排在 App 规则之后。通用清单范围宽，可能包含个别 App 的域名；若排在前面，这些 App 的流量会在到达自身规则之前被提前匹配。

复制的规则段与生成的整份配置都自动遵循这一顺序。原理详见 DNS 与规则顺序。

05｜质量门禁

每次变更在合并前须通过 10 道离线检查，主要包括：

  • 八端等价性：各客户端之间只允许存在已登记的差异；
  • 产物健康度：无空文件、无重复、排序确定、统计正确；
  • 跨 App 重叠：不允许出现未经复核的新重叠；
  • 溯源完整性：每个产物都能对应到上游、补充规则与构建器版本；
  • 敏感信息：不得包含凭据、私钥、本机路径等内容。

另有一道需要联网的实时重建检查：重新抓取全部上游后，产物须逐字节一致。它在发布前和排查问题时运行，不随每次变更执行，以免上游的临时网络故障阻断合并。

此外，mihomo 与 sing-box 的规则和配置会交给对应的官方内核（mihomo 1.19.32、sing-box 1.14.2）实际加载一次。

门禁区分两类结果：

类型 适用情形 处理
拦截 可能导致流量走错的问题，如上游一次增删超过 20 条，或至少变化 3 条且超过 20% 停止发布，等待人工确认，旧规则继续可用
提醒 需要判断但不紧急的问题，如上游超过 12 个月未更新且一年内未复审 列入网站的「要复查」，不阻断每日更新

06｜来源模型

Blink 的规则以 Blink 自己的规则账本为唯一来源。其他作者的公开清单、厂商公开数据与客户端日志，都只作为收录原料。

这一模型基于以下立场：一个 App 连接哪些地址，是该 App 公开的事实。清单作者整理了这些事实，Blink 尊重其许可并注明出处；但来源调整不应导致规则覆盖减少。

收录与退役由程序按固定规则判定：

规则收录判定：多方一致则收录，共享基础设施拒绝，长期无人收录则退役

  • 收录：两份相互独立的清单一致，或有厂商数据、日志证据，且不属于共享基础设施（CDN、云服务等）；
  • 仅作佐证：GPL / AGPL 许可的清单只用于佐证，不单独决定收录；
  • 退役：连续两个周期无清单收录、DNS 无解析、90 天内无日志命中，则自动退役，可恢复；
  • 归属：两个 App 共用的域名，由维护者裁定一次并记录。

账本每月 1 日更新一次。变更以合并请求的形式提交，经维护者审核后发布。每个 App 的目标覆盖率为多源候选的 95%。

网站的「来源」页列出全部规则作者，并显示近期的规则变化。

来源页：规则作者、App 数、规范规则数与近期变化

07｜交互原则

网站以「打开即可使用」为原则：

  • 首次访问只询问所用客户端，不设欢迎页与教程；
  • 颜色只表示状态：蓝色为选中，绿色为完成，红色为失败；
  • 复制失败时不显示「已复制」；
  • 系统开启「减弱动态效果」时，不播放任何动画；
  • 介绍短片仅在用户点击后加载，不自动播放；
  • 纪念图片仅在完成后提供，可跳过。

08｜发布与授权

Blink 分为两个仓库：

  • 公开仓库：只包含用户直接使用的内容，即八种格式的规则、七份配置与使用说明；
  • 私有仓库：包含构建程序、门禁、网站源码与审计记录。

规则本身是公开事实，任何人都可以整理；持续审计、每日检查与日志校正的方法属于私有部分。

发布流程：私有仓库通过检查后，按白名单同步到公开仓库

私有仓库的检查全部通过后，产物按白名单同步到公开仓库。规则地址始终保持不变。

授权分为三层：上游规则沿用上游许可；原创的规则与配置采用 CC BY-NC-SA 4.0；说明文字、网站文字与标志保留所有权利。各 App 的来源与许可见 THIRD_PARTY_NOTICES。

仓库不包含任何真实的服务器地址、凭据或证书。Blink 仅供个人学习与研究使用。

09｜设计原则

  1. 可重建：每个产物都能从源头逐字节重新生成，自动发布才可信。
  2. 损失可见：无法表达的规则显式丢弃并记录，不做静默替代。
  3. 规则可检验：约束写成自动检查，不依赖人工记忆。
  4. 拦截与提醒分离：会导致流量走错的问题拦截，其余问题提醒。
  5. 事实与选择分离：规则交给程序核对，配置由人决定。