“CoralBay Rules 是一个自托管的订阅转换、分流配置与规则镜像平台。它不提供代理节点，而是把你手上已有的订阅变成客户端可长期使用的交付链接，并把 666OS 规则与 MetaCubeX 分流镜像到自己的域名下。更新说明（2026-09-29）：本文已按 v4.17.1 重新核对，补入妙妙屋X、共用分组方案、生成历史与回收站、284 张本地图标等新能力，并修正订阅签名、部署与回退边界。如果你手上有好几个机场订阅，又希望 AI、视频、社交这些服务分别走不同的出口，或者不想让客户端配置里裸露上游 GitHub 地址，CoralBay Rules 提供的正是这一层：数据留在自己服务器上，链接由自己签发。这篇会从四个角度把这套东西讲透：为什么会出现（由来）、规则本身是怎么回事（规则详解）、拿到之后怎么用（使用指南）、以及怎么把它跑起来（搭建与运维）。前半部分帮助理解，后半部分可以直接照着操作。项目入口：本站项目列表 · CoralBay Rules 仓库 · 最新发布。本站项目卡片会打开对应仓库，下载、文档和问题反馈仍以仓库为准。它解决什么问题日常折腾代理配置时，真正麻烦的往往不是「能不能连上」，而是三件事：订阅分散：多个订阅要手动合并、筛掉不想要的节点、把名字改得能看懂。分流固定：希望不同类型的流量走不同策略，但每次改都要重新生成整份配置。上游依赖：规则直接引用第三方地址，上游抽风或改路径时，所有客户端一起失效。CoralBay Rules 把这三件事收进一个自托管服务里。本文更新时的最新正式版是 v4.17.1，支持 Linux amd64 / arm64，并以 Docker Compose 部署。由来：这套东西是怎么长出来的要理解 CoralBay Rules 的设计取舍，先看它涉及的技术。项目本身的正式缘起以仓库 README 与 Issues 为准，下面这段梳理的是它所解决的问题的来历——三个各自独立的痛点，最后被收拢到同一个面板里。1. 订阅转换的由来：一个订阅，十几种客户端机场下发的通常是一串节点信息，但不同客户端吃的格式完全不同：Clash 系要 YAML，sing-box 要自己的 JSON，Surge、Loon、Quantumult X、Shadowrocket 各有各的语法，V2Ray 系又是一套 URI。于是一串节点要被反复翻译。这个翻译工作最早由开源的 subconverter 一统江湖——它接受一个订阅地址，配合一份 INI 预设（ACL4SSR 之类的分流模板），吐出各客户端能直接用的配置。之后社区陆续维护出 subconverter-ng 等分支，修复兼容性、补新格式。CoralBay Rules 内置的正是 subconverter-ng 后端，但它做了一个关键取舍：不暴露后端端口，只在 Compose 内网里跑。你合并的订阅地址不会经过任何公共转换站——这是自托管相对公共站最大的意义：订阅链接本身就是凭证，泄露等于泄露节点。验证前置：先真的跑一次转换、数一遍可解析节点，通过了才签发链接，避免发布一个空配置出去；这不等于所有节点都已完成真实网络连通性测试。链接签名：输出的 /sub 地址会对规范化参数做 HMAC 签名，用来阻止参数被篡改或伪造；完整链接本身仍是访问凭据，拿到链接的人可以使用，因此不能公开。2. 分流规则的由来：从「全局代理」到「按域分流」最早大家都是全局代理，所有流量无差别转发——结果是国内网站变慢、银行 App 风控、 CDN 走错。后来出现了三种演进：黑白名单：一份巨大的域名清单，命中就直连，没命中就代理。简单，但清单一旦过期，误伤一片。分类规则集：把规则按用途分成 Apple、Google、Netflix、Telegram、广告、下载……每个类别挂一个策略组，用户只需要决定「这类流量走哪条线」。ACL4SSR、blackmatrix7 等仓库把这条路走到了极致。分流配置生成：MetaCubeX 一侧把规则集、策略组、DNS、节点筛选拼成一份完整的 mihomo 配置，也就是 CoralBay 里「MetaCubeX 自定义分流」这条链路的来源。规则越堆越多，加载也越吃资源——这就是下一节 MRS 二进制规则出现的原因：把域名或 IP 集合预编译成更紧凑的二进制，客户端无需在启动时解析大段文本。实际启动时间和内存收益仍取决于客户端、规则规模与设备，不能脱离统一基准给出固定倍数。3. 镜像的由来：上游地址是单点故障规则几乎都托管在 GitHub 上。对国内及部分网络环境来说，这带来三个问题：拉取不稳定、上游改路径或删仓库时全体失效、客户端配置里长期裸露第三方地址（一旦被墙或限速，配置直接打不开）。自建镜像就是标准解法：用计划任务定时把上游拉下来，转成本域名的地址，客户端只认识你自己的域名。CoralBay Rules 把这件事做得比「写个 crontab git pull」严谨得多：可追溯：发布 ID 由 release 提交、geo 提交、YYDS 配置摘要、生成器版本、域名配置摘要五部分组成，任一变化都生成新版本，你能确切知道「这一版规则是哪一天、哪个上游状态」生成的。安全发布：新版本先在独立 staging 完整校验，通过后再原子切换；同步失败自动保留上一份有效快照，不会把半成品交给客户端。辅助审计：MRS 是二进制，项目会关联同步 geo 分支的可读源供控制台查看；它帮助理解规则内容，但不是对 MRS 的逐条反向还原，不能仅凭这份文本断言某次连接的实际命中。不并发写：面板、计划任务、命令行共享跨进程锁，避免两个人同时点同步把数据目录写花。三条脉络合起来，就是 CoralBay Rules 的定位：把「转换」「分流」「镜像」三件原本要自己写脚本的事，变成一个可以点开看、可以追溯的自托管服务。先确定你要的是转换后的节点、完整分流配置，还是给平台用的模板。三种交付物不能互相顶替，也不能因为都有一个链接就填进同一入口。核心能力1. 普通订阅转换入口在「订阅服务 → 普通订阅转换」。它最多合并 5 个 HTTP/HTTPS 订阅地址，输出覆盖 Clash/Mihomo、ClashR、sing-box、Surge、Surfboard、Shadowrocket、Quantumult(X)、Loon、V2Ray、SS、SSR、Trojan 和混合 URI。可配置的项相当细：包含/排除正则、节点重命名、远程配置预设、更新间隔、Emoji、排序、去重、UDP/XUDP、TFO、TLS 1.3、证书校验、仅节点输出、规则展开、DoH 以及客户端专属参数。这里重要的是它的验证前置：CoralBay 会先真正执行一次转换、检查可解析节点数量，通过之后才生成 HMAC 签名的 /sub 地址。不兼容的目标（比如把全 VLESS Reality 订阅转成 Surge）会直接拒绝，而不是发布一份空配置给你。结构可解析不等于节点已经通过真实网络连通性测试。普通转换页首先确定原始订阅和目标客户端，再决定是否添加过滤或远程配置。本地演示只运行控制台，未启动转换后端，画面保留了“后端不可用”和 MRS 解码能力不可用的提示；这不是转换成功的截图。正式搭建应按部署文档准备完整依赖，不能把控制台服务在线当成转换后端已就绪。2. 自定义分流订阅入口在「订阅服务 → 自定义分流订阅」，交付的是 Mihomo / OpenClash / Stash 的完整分流配置链接。这正是前面说的「让 AI、视频、社交走不同节点」的落地方式：策略组是你的意图，规则集是判定依据，两者拼起来就是一份可直接导入的配置。一个方案可填写 1–8 个原始 HTTP(S) 订阅，单个订阅最多 8 MiB，合并上限为 5,000 个节点；它不展开远程 proxy-providers，也不继承源配置里的规则、DNS、脚本和策略组。3. 两套相互独立的规则源这是这个项目比较特别的地方——666OS 规则镜像 和 MetaCubeX 自定义分流 是两条互不干扰的链路：同步 release 分支的 MRS 时，同时同步 geo 分支的可读源，控制台可以展开查看具体条目；没有公开可读源的 MRS 会明确标注「暂无公开可读源」，不会假装能看。发布 ID 包含 release 提交、geo 提交、YYDS 配置摘要、生成器版本和域名配置摘要，任一变化都会产生新版本。新版本先在独立 staging 完整校验，通过后用临时链接原子切换；GitHub 同步失败时保留旧版本。面板、计划任务和命令行共享跨进程同步锁，避免并发写入。规则源页显示本地已发布版本、原始文件条目和上游检查状态。本地文件可用与上游已经检查是两回事；图中已有本地快照，上游状态仍是“尚未检查”。同步最新版本、检查上游和修复当前版本三个按钮，不要当成同一个操作。点开详情后，可以核对来源、固定版本、格式、大小、SHA-256 和更新时间，再继续查看条目。图中读取的是本机已有文件，没有因为打开详情就升级规则，也没有把规则文件存在当作节点可访问的证明。同步链路和客户端实际命中规则不是同一层。666OS 镜像与 MetaCubeX 自定义分流独立；有本地文件也不代表已经检查过最新上游。4. 妙妙屋X、PPanel 与 MihomoPro：三个客户端配置入口4.15.0 新增妙妙屋X，与此前已有的 PPanel、MihomoPro 形成三个客户端配置入口：妙妙屋X：独立页面 /miaomiaowu 可以生成 Clash V3 / Mihomo 完整模板，也能把 33 项 YYDS 规则按项转换为 payload YAML，供“规则集管理”手动导入。模板保留业务分流，节点由妙妙屋X 注入；模板和规则集都可选择本机镜像或同版本上游源。PPanel：下载的 .gotmpl 或 YAML 仍然是等待 PPanel 渲染的 Go 模板，不是可以直接导入客户端的成品。MihomoPro：生成来源与版本配对的完整 YAML 和 OpenClash 覆写，两份文件应成套使用。这三个入口与“普通订阅转换”“自定义分流订阅”彼此独立，不能把模板文件当成订阅转换结果。部署和普通转换也不依赖 PPanel、Nextin 或妙妙屋X。妙妙屋X 页面先选目标客户端和规则来源，再取得模板，导入妙妙屋X 后绑定自己的订阅。这里展示 Clash / Mihomo 入口和 YAML 文件名；本地演示没有备齐 666OS 配置镜像，没有把模板下载和客户端连通算作通过。5. 一套方案复用到多个入口：4.16.0 的分组与分流设置4.16.0 把妙妙屋X、PPanel Mihomo 系模板和 MihomoPro 覆写接入同一套“分组与分流设置”。可以让三个入口继承共用方案，也可以各自保存独立方案：业务分类可排序、启停、指定默认出口，并决定是否展示全部单节点；节点先按名称进入选定的独立国家或地区，剩余节点进入亚洲、欧洲、北美洲等大区，最后由“其他／未识别”兜底；每个地区都可提供自动、均衡、手动三种模式；均衡支持一致性哈希、轮询与粘性会话，并可调整测试地址、间隔和容差；高级选项覆盖本地图标、自动组隐藏、DNS、IPv6 与嗅探；YouTube、Netflix、Disney、Spotify 可以单独分流；粘贴节点名称即可预览归属和歧义，但这是名称匹配，不是出口 IP 定位、节点测速或流媒体解锁检测。“自动与均衡”页把测试地址、检测间隔、切换容差和均衡方式放在一起。图中是 300 秒、50 毫秒和“相同网站优先使用同一节点”的参数示例，不是测速结果。均衡按连接分配，不会把一条连接的带宽叠加起来。支持范围以 Mihomo 系为主：妙妙屋X Clash V3/Mihomo、PPanel 的 Clash（Mihomo 内核）/Mihomo/OpenClash，以及 MihomoPro 的配对 YAML/覆写。4.16.0 也新纳入妙妙屋 Surge、Loon 原生基础模板，但它们尚未接入这套地区均衡方案，且仍属于开发中扩展，未完成私有妙妙屋后台与原生客户端的连通验收。“规则与高级”页可以单独打开 YouTube、Netflix、Disney、Spotify 分流；DNS、IPv6 和流量嗅探也能选择沿用当前模板。截图保留了未选好来源时的红色提示：先准备来源，再生成文件。这是设置页展示，不是一份已经验证可用的客户端配置。方案设置与生成文件是两个动作。产物身份包含来源、规则版本、输入摘要和设置摘要；修改方案不会悄悄覆盖已经交付的固定链接。MihomoPro 的地区页先列独立地区，再收纳剩余节点的大区，每个地区分别控制自动与均衡，手动保留。截图里的“未检测”不是测速失败：这次没有提供真实节点做归属预览。按名称匹配地区、选择策略组和实际出口检测，仍是三件事。把香港、东京、德国、越南和一个未知名称粘进预览，界面给出 5 个名称、5 个已归组、1 个进入兜底、0 个多重匹配。这里不需要订阅链接或节点密码。结果只说明名称匹配到了哪个组，不能证明真实出口位置、连通性或流媒体解锁情况。6. 历史版本与回收站：4.17.0 的可恢复交付4.17.0 给三个模板入口补上完整生成历史：可以按方案、客户端和版本搜索，查看生成日期、次数、完整正文、规则版本与当时设置，也可以打开、下载、复制链接，或把旧设置复用成新草稿。MihomoPro 的覆写与配套完整 YAML 按同一版本管理。地区与大区也变得更细：独立地区可以取消和排序，大区可以关闭；地区、大区和兜底的自动／均衡模式可单独或批量停用，手动与兜底始终保留。若默认出口指向已关闭分组，系统会要求重新选择，不会静默改成直连。DNS、IPv6 与嗅探选项会按所选客户端展示实际基础字段、模板版本、影响和本次覆盖范围；选择“沿用”表示保留模板原值，不代表系统会自动挑选最佳模式。删除历史文件只是移入回收站：源站对新请求返回 HTTP 410，恢复后原 URL 与内容重新可用。它不会撤回客户端已经下载的文件，也不能清除浏览器或 CDN 旧缓存；回收站目前不物理删除文件，因此不会释放磁盘空间。固定产物和运行中的规则快照要分开理解。历史文件进回收站不会释放磁盘；恢复的是对应固定文件，不是一套完整的历史规则版本回退。7. 284 张本地图标与地区选择修复：4.17.14.17.1 内置 251 张国家／地区／组织旗帜 PNG，并保留原有 27 张图标、增加 6 张大区地图图标，合计 284 张。原有与大区图标来自固定版本 Qure，旗帜来自固定版本的 hampusborgos/country-flags；不能把 284 张全部称为 Qure 图标。图标随程序和 Docker 镜像内置，/_assets/icons/ 可免登录读取，首次规则同步失败时也能提供。只有在方案里开启“使用本机缓存图标”，生成配置才会写入图标字段；图标只改变展示，不参与测速、分流或节点字段修改。这一版还补齐了“全球手动”的候选：除单节点外，还会列出当前启用的独立地区、大区与兜底的自动、均衡、手动组。“故障转移”则继续保持纯节点 fallback，不会混入选择器并制造循环引用。规则详解：一条规则到底是怎么生效的「分流」听起来抽象，拆开其实非常机械。一条规则 = 一个匹配条件 + 一个出站策略。客户端把流量从上往下逐条比对，通常命中即停；一个明确例外是 UDP 流量命中了不支持 UDP 的代理节点时，Mihomo 可能继续向下匹配。其余没命中的流量落到最后一条兜底规则（通常写成 MATCH 或「漏网之鱼」）。所以分流调不好，九成是两件事没做对：条件写错了，或者顺序排错了。1. 常见规则类型DOMAIN —— 精确匹配某个域名。DOMAIN,www.example.com 只命中 www.example.com，子域名不算。DOMAIN-SUFFIX —— 后缀匹配，最常用的一类。DOMAIN-SUFFIX,example.com 命中 example.com 自身以及 a.b.example.com。DOMAIN-KEYWORD —— 关键字匹配，杀伤面大。DOMAIN-KEYWORD,google 会命中任何域名里带 google 字样的地址，方便但容易误伤，建议放在规则链靠后的位置。DOMAIN-REGEX —— 用正则匹配域名，用于前两类表达不了的域名结构；它不匹配 URL 路径。核心支持度视客户端而定，写的时候先在测试客户端验证。IP-CIDR / IP-CIDR6 —— 按目标 IP 判断。域名请求通常需要先解析出 IP 才能比对，因此可能触发 DNS 查询；使用 no-resolve 可以避免为这条规则额外解析，但不会撤销此前已经发生的解析。是否走代理、走哪个 DNS，都会影响命中结果。GEOIP —— 按国家/地区码判断，例如 GEOIP,US,Proxy、GEOIP,CN,Direct。依赖 geoip 数据库的更新，它的准确性取决于库有多新。GEOSITE —— 按站点分类库判断（domain-list-community 那一套），一条就能覆盖一个大类，比如 GEOSITE,youtube、GEOSITE,cn，是目前最省心的写法。RULE-SET —— 引用外部规则集文件，也就是常说的规则仓库。RULE-SET,apple,Direct 表示加载 apple 规则集并按它匹配。镜像功能服务的正是这个：把 RULE-SET 的地址换成你自己的域名。PROCESS-NAME / PROCESS-PATH —— 按发起连接的进程名判断，例如让某个下载工具强制走代理。只在本机客户端上有效，手机端或网关上要先确认客户端支持。DST-PORT / SRC-IP-CIDR —— 按目标端口或来源网段判断，常用于把内网网段强制直连、把某类端口单独拎出来。IN-TYPE / IN-USER —— 按入站类型或入站用户判断，属于进阶用法，多数人用不到。MATCH —— 兜底规则，必须放在最后。前面全部没命中时由它收尾，通常指向一个「漏网之鱼」策略组。图只解释匹配顺序，不宣称某个站点已经成功解锁。精确规则在前，宽泛规则在后，MATCH 最后；最终用了哪个出口，要看命中规则指向的策略组和客户端日志。2. 规则一般按用途分这几组不管规则来自 666OS 还是 MetaCubeX，实际使用时基本都会归到这些组；理解了分组，看别人的配置也容易些：拒绝组：广告、追踪、统计域名，命中直接 REJECT，顺带省流量。国内直连组：银行、政务、运营商、各类国内站点，走 DIRECT，避免绕一圈。AI 服务组：ChatGPT、Claude、Gemini 等，对出口地区敏感，通常单独挂一个策略组，方便随时换区。流媒体组：Netflix、YouTube、Disney+、Spotify，涉及解锁判定，常按节点能力单独分组。社交与通讯组：Telegram、X、Facebook、Instagram、Discord。微软 / 苹果 / 谷歌 / 亚马逊：体量大、更新频繁，一般各自成组。开发者组：GitHub、npm、Docker Hub、Steam 下载，下载类常需要能跑大流量的线路。漏网之鱼：最后的 MATCH，命中漏网之鱼策略组并显示出来，方便你发现「还有这种流量没分类」。3. MRS 与可读源：为什么要两份项目会把给客户端加载的 MRS 与供人阅读的关联源并列展示，但两者用途不同，也不是每份 MRS 都有公开可读源：MRS（二进制规则集）：给 Mihomo 加载用，当前支持 domain 与 ipcidr 两类行为。它把适合这两类的数据预编译为紧凑格式，但并不承载所有规则形态；启动和内存收益应以具体设备实测为准。关联可读源：给人理解规则内容。CoralBay 在同步 release 分支 MRS 的同时会同步 geo 分支的文本；它不是 MRS 的精确反向还原，实际连接命中了哪条规则仍应以客户端日志为准。没有可读源的怎么办：界面会明确标注「暂无公开可读源」。这意味着不能在面板里辅助审阅该内容，不代表 MRS 无法被客户端使用。4. 666OS 与 MetaCubeX 怎么选666OS 规则镜像：你已经有了自己的分流结构，只是想把 RULE-SET 的下载地址换成自己域名，走这条。MetaCubeX 自定义分流：你想直接拿到一份含策略组、规则、DNS 的完整 mihomo 配置，导入就能用，走这条。两者互不干扰：独立同步、独立发布；一条链路同步失败不会改写另一条或当前有效快照。同时使用没有问题，但当前仍没有完整的历史规则版本回退界面。同一方案的自定义分流地址可以持续使用；普通转换参数变化通常要换新签名链接；平台模板则要重新生成、替换和刷新，不能等后台同步自动改掉旧模板。5. 调规则时最容易踩的坑（列举）顺序颠倒：把 DOMAIN-KEYWORD 写在精确规则前面，后面的精确规则永远轮不到。原则是精确在前，模糊在后，兜底最后。规则对了但 DNS 不对：走了 fake-ip 还是真实解析、DNS 出口在哪，都会改变 IP 类规则的判定结果。分流乱的时候先看 DNS。误以为规则能修一切：某网站打不开，可能是节点本身被识别，不是规则没写对。先换节点测试，再怀疑规则。混淆了三类链接的更新语义：自定义分流方案保存后会更新同一条 /routing/sub；普通转换调整参数时通常会生成新的签名 /sub，要替换客户端地址；妙妙屋X、PPanel、MihomoPro 的分组模板则是不可变固定产物，需要重新生成、替换平台模板并让客户端刷新。进程规则用错场合：在路由器上配 PROCESS-NAME，转发流量里没有本机进程信息，规则形同虚设。一次改太多：分流排查的正确姿势是一次只动一处，然后用日志确认命中，否则你永远不知道是哪条起了作用。使用指南：从拿到链接到确认生效第一步：生成交付链接登录控制台，进入「订阅服务」，选择普通订阅转换（合并、过滤、改名与转换格式）或自定义分流订阅（生成带策略组和规则的 Mihomo / OpenClash / Stash 完整配置）。普通转换最多填写 5 个 HTTP/HTTPS 地址；自定义分流最多填写 8 个地址，单源不超过 8 MiB，合并后最多 5,000 个节点。普通转换会实际执行转换并检查可解析节点数，通过后生成 HMAC 签名的 /sub 链接；自定义分流会校验节点、策略组和规则结构，保存后生成固定的 /routing/sub/{token}/{client} 链接。被拒通常意味着目标格式与节点协议不兼容，或配置存在空组、未知字段、超限内容等问题。第一次配置：先决定你要拿到什么如果只是把现有订阅换成另一种客户端格式，进“普通订阅转换”；如果要自己安排 AI、视频、社交的策略组，进“自定义分流订阅”；如果你维护的是 PPanel、妙妙屋X 或 MihomoPro 的平台配置，则用对应模板或覆写入口。这几条链路的输入和交付物不同，不能拿一个入口的地址随便填到另一个入口。先只接一条你有权使用的订阅，选实际要用的客户端，不急着加名称正则、地区排除或复杂 DNS 设置。若选“本机镜像”，先确认所需 MetaCubeX 原始规则已经发布到本地；缺失时先同步，不能把面板能打开当成规则已准备好。服务规则页把“是否启用这类规则”和“这类流量去哪里”分开。以 OpenAI 为例，先保留全局节点范围，确认规则与策略组能生成，再按需要独立覆盖。地区是根据节点名称识别的筛选条件，不是对真实出口或服务解锁的承诺。本篇六张控制台截图来自按 v4.17.1 源码启动的本地演示环境，规则资源页读取的是已下载的公开 MetaCubeX 文件。subscription.example.com 是占位地址，未抓取真实订阅、未生成交付链接，也没有做节点连通性测试。真实使用时，完成预览与保存后，再按下一步导入客户端并检查连接日志。第二步：在客户端导入把对应客户端的交付地址按订阅或远程配置导入；不同目标格式不能混用：Mihomo / Clash Verge / MetaCubeX 面板：新建订阅 → 粘贴链接 → 更新。配置可用客户端自带的测试功能先校验一遍（mihomo -t 等价操作）。sing-box：生成的是 sing-box 目标格式；是否能直接作为远程配置或订阅导入，取决于你使用的具体客户端及其版本，不要把它笼统称为“入站订阅”。Shadowrocket / Surge / Quantumult X / Loon：按对应客户端选择目标格式后添加订阅链接；各端参数支持范围不同，个别选项在面板里可能显示为不适用。混合 URI：只是一组节点 URI，适合能识别这些协议链接的客户端；它不包含策略组、DNS 和分流规则，不能因为拿不准客户端就把它当作兼容性最广的完整配置。第三步：设置更新节奏普通订阅链接：客户端刷新间隔可按实际需求设置；这个间隔与 v2 HMAC 签名是否有效无关。规则同步：666OS 默认每 6 小时同步；MetaCubeX 规则源独立每日同步，也可以在控制台手动检查、同步或修复。固定版本产物：后台规则同步不会悄悄覆盖已经交付的模板和规则链接。要采用新规则，需要重新生成、替换平台模板并让客户端更新。第四步：验证它真的在工作打开订阅，确认节点数量和名称符合预期——数量为 0 说明转换出了问题，回头检查源订阅。逐个切换策略组，访问对应站点，确认走向符合你的意图。打开客户端的连接日志或规则匹配日志，看某条连接究竟命中了哪条规则——这是排查分流唯一靠谱的办法，比反复改配置快得多。访问几个「故意放最后」的站点，确认它们落进漏网之鱼组，这样你才能发现未分类的流量。后台接受配置，只证明生成阶段通过了检查。导入后先看节点和结构，再访问对应服务，最后查日志确认实际命中；只看控制台在线，缺了后面几层。常见问题（FAQ）普通订阅返回 403：通常表示签名不匹配、查询参数被改写，或旧版 legacy 签名兼容期已经结束；当前 v2 签名本身不含到期时间。链接被停用或历史文件移入回收站时返回 410。不要手改签名参数，可在管理页恢复或更新签名后重新复制。转换后节点为空：多半是包含/排除正则写太狠，或目标格式不支持当前协议，先把过滤条件清空试一次。迁移服务器或域名：应完整迁移 .env、compose.yaml 和整个 data/，尤其是签名密钥与 SQLite/WAL。不要在服务运行时只复制单个 SQLite 文件；按官方流程短暂停止 app/updater 后制作一致性归档。备份包含管理员密码、内部令牌、订阅凭据与签名密钥，必须限制权限并加密保存。保留原域名和密钥时，已有链接可以继续使用；若丢失密钥或更换域名，则需要重新生成或替换客户端地址。规则更新了但没生效：检查计划任务状态、发布 ID 是否变化、客户端有没有重新拉取订阅。只有某个 App 走错：看它的域名是否被上游规则归错了类，或是否命中了过宽的 DOMAIN-KEYWORD。磁盘被同步撑满：规则快照、解码缓存和模板历史都会占空间。共用模板的回收站不物理删除文件，也不释放空间；应监控整个 data/，不要手动删除仍被旧配置引用的固定资源。搭建：把它跑起来通用流程如下，具体字段与命令以仓库 docs/deployment.md 和 Release 说明为准——出站隔离等涉及安全的升级常常要求安装脚本与 Compose 同步更新，照抄旧脚本会踩坑。1. 前置条件Linux x86_64 / ARM64 服务器，Root 或 sudo 权限；Docker Engine 与 Docker Compose 插件；Bash、curl、coreutils、awk 等基础工具；已解析到服务器的域名，以及现有 Nginx、OpenResty、Caddy 或面板提供的 HTTPS 反代；data/ 应放在支持 Linux 文件锁的本地文件系统，并预留规则快照、模板历史与缓存空间。2. 官方安装脚本（推荐）当前完整部署不只有一个应用容器，还包含内网的 subconverter 和独立 updater。因此不要照着单服务 Compose 片段自行拼装，直接使用仓库安装器更稳妥：( set -eu coralbay_installer="$(mktemp)" trap 'rm -f "$coralbay_installer"' EXIT curl -fsSL --retry 3 --connect-timeout 15 --max-time 120 \ "https://raw.githubusercontent.com/sexyfeifan/Coralbay-Rules/main/install.sh?t=$(date +%s)" \ -o "$coralbay_installer" bash -n "$coralbay_installer" sudo env CORALBAY_IMAGE=sexyfeifan/coralbay-rules:4.17.1 \ bash "$coralbay_installer" install )这里用 CORALBAY_IMAGE 把 app 固定在 4.17.1；脚本本身仍从 main 下载，bash -n 只做语法检查，并不验证来源、提交或摘要。对供应链要求更高时，应先把脚本下载到本地，核对仓库提交与内容后再执行。安装器会生成完整 Compose、写入 .env 并做启动检查。默认将主应用映射为 127.0.0.1:3999 → app:8080，转换后端只在 Compose 内网提供服务；域名、证书和 80/443 仍由现有反代管理。首次安装会要求隐藏输入并确认至少 12 位管理员密码，不存在公开默认口令。反向代理对外提供 HTTPS，app 通过回环映射接入。subconverter 只在 Compose 内网提供转换，updater 单独负责更新；控制台能打开不代表依赖都已就绪。3. 已安装用户升级到 4.17.1升级前按官方流程短暂停止 app/updater，再一致性备份 .env、compose.yaml 和整个 data/；不要在服务运行时只复制单个 SQLite 文件。备份包含密码、内部令牌、订阅凭据与签名密钥，应限制权限并加密保存。同时记录 Compose 中每个服务的镜像引用与摘要。固定 app 版本的升级命令是：sudo env CORALBAY_IMAGE=sexyfeifan/coralbay-rules:4.17.1 rules update从 4.15.0 到 4.17.1 没有新增必填环境变量，但固定旧标签的服务器不会自动切换到新版本；不显式传入新 CORALBAY_IMAGE 时，rules update 会继续沿用 .env 里的旧标签。需要特别注意：CORALBAY_IMAGE 只固定 app，rules update 仍会从 main 获取当前脚本和 Compose，其他服务（包括 subconverter）也可能使用各自的 latest。因此这不是整套部署的完全锁版，升级前后都应记录所有服务的镜像摘要。升级应用也不会改写已经导入妙妙屋X、PPanel 或 OpenClash 的模板；要采用新分组、图标和选择器行为，升级后还要按原方案重新生成文件、替换平台模板并刷新客户端订阅。只锁 app 标签，不等于锁住所有服务。先留下各服务镜像摘要，按官方流程停止 app/updater 后做一致性归档；回退前还要确认数据兼容性。4. 域名与 HTTPS规则域名必须能被客户端稳定访问，HTTPS 不是可选项——不少客户端拒绝从明文地址加载规则。用 Caddy 的话大致是：rules.example.com { reverse_proxy 127.0.0.1:3999 }当前由一个 MIRROR_DOMAIN 统一承载普通订阅、自定义分流订阅、规则、模板与图标，不能在项目配置里把“订阅域名”和“规则域名”分别设置。若要采用不同缓存策略，应在同一反向代理或 CDN 上按路径区分。启用本机来源／本地图标后的生成产物会引用这个域名，但未被镜像的上游或第三方依赖仍可能保留外部地址，不能把它理解为所有资源都会自动本地化。5. 首次初始化清单首次安装时按提示设置至少 12 位管理员密码；项目没有需要登录后再修改的默认口令。登录限流不会信任未经验证的转发 IP 请求头，但密码仍应妥善保管。创建第一个订阅转换，确认能拿到签名链接。手动触发一次规则同步，确认发布 ID 生成、staging 校验通过、原子切换成功。检查计划任务是否按预期调度（控制台或容器日志里能看到同步记录）。在一台测试客户端上导入，按上一节四步验证一遍，再推广到其他设备。给数据卷做一次备份，并记下恢复步骤。6. 升级与排障升级顺序：先读 Release 说明 → 更新安装脚本（如使用）→ 更新 Compose（含环境变量与挂载）→ 再拉新镜像。出站隔离相关升级必须同时更新脚本和 Compose，只换 app 镜像是不够的。回退：规则同步失败会保留上一份有效快照，但当前没有完整的历史规则版本回退界面；模板历史的“恢复”只恢复对应固定文件。服务降级不能只换回旧镜像，必须先核对数据兼容性，并使用升级前与版本匹配的完整配置和数据备份。同步失败：先看是不是网络到 GitHub 不通，再看发布 ID 是否变化。失败不会破坏旧版本，这是设计好的。客户端拉不到：按「反代是否通 → 域名解析 → 证书是否过期 → 签名是否有效」的顺序逐层排查。容量：定期看磁盘，历史发布、分组模板与解码缓存（单份 MRS 解码文本限 32 MiB）都会占空间；回收站不会释放磁盘。拉不到配置先查反代、解析和证书；节点为空再查过滤与目标协议；只有某条流量走错时，查实际规则命中。不同故障不必都从规则页开始改。部署与安全性项目内置 subconverter-ng 后端，但不直接暴露其端口，只在 Compose 内网提供服务——订阅不会被发到公共转换站。项目也不提供公共短链接，不执行用户提交的任意 JavaScript。签名和令牌解决的是访问控制或完整性，不是保密：普通 /sub 的 HMAC 能阻止参数被篡改，却不会加密 URL；原始订阅地址仍可能出现在查询串、反向代理／CDN 日志、截图和工单中。/routing/sub/{token}/... 则是典型的 bearer token，谁拿到谁能访问，泄露后应在管理页重置。部署时应关闭或脱敏两个订阅端点的完整请求目标／访问日志：既包括 /sub 的查询串，也包括 /routing/sub/ 路径里的 token；同时避免公开分享、截图和可被索引的工单，并阻止 CDN 对这些订阅路径做公开缓存。几处边界设计能看出作者比较谨慎：普通转换后端响应上限 16 MiB，远程 INI 缓存上限 2 MiB，超限直接拒绝，不接受「截断后恰好可解析」的片段。无效远程配置不会覆盖最后一次成功的缓存。原始 MRS 单份解码文本限制 32 MiB，解码缓存按摘要保存并校验内容。安装脚本不再执行 .env 内容，支持安全重配置与实际启动检查。登录限流不会信任未经验证的转发 IP 请求头（修复了换 TCP 连接绕过限流的问题）。出站隔离相关的升级需要同时更新安装脚本和 Compose，不是只更新 app 镜像，升级时注意这点。订阅 URL 本身需要保护。HMAC 不会把查询串里的原始订阅加密；自定义分流路径里的 token 也可能泄露到日志。两类路径都要避免公开缓存和完整记录。适用与不适用适合：手上有多个订阅，想要统一的签名链接和分流配置。想让规则、图标、模板都走自己的域名，减少对上游地址的依赖。需要可审计的规则变更历史、固定版本交付，以及同步失败时保留上一有效快照。愿意花一个下午把部署、域名、反代、备份一次性配好，然后长期稳定运行。不适合：想直接买代理节点——项目明确说明它不提供节点，只转换你已有的订阅。期望零运维——这是一套需要自己部署、自己同步、自己盯磁盘的自托管服务。只想在手机上开箱即用——它没有官方托管版，也没有移动端客户端。相关链接仓库：github.com/sexyfeifan/Coralbay-Rules最新版本：v4.17.1 Release 与 CHANGELOG镜像：Docker Hub部署指南：docs/deployment.md妙妙屋X：使用指南共用方案：分组与分流指南规则与其他用法：docs 目录---本文已按 4.17.1 正式版的 README、CHANGELOG、Release 与源码边界更新；「规则详解」「使用指南」「搭建」三节为面向使用者的展开说明。实际可用标签、字段与升级边界仍以 GitHub Releases、docs/deployment.md 和 Docker Hub 为准。发布新版本不会自动升级使用固定标签的服务器，也不会替换已经导入妙妙屋X、PPanel 或 OpenClash 的固定模板。
如果你手上有好几个机场订阅，又希望 AI、视频、社交这些服务分别走不同的出口，或者不想让客户端配置里裸露上游 GitHub 地址，CoralBay Rules 提供的正是这一层：数据留在自己服务器上，链接由自己签发。
这篇会从四个角度把这套东西讲透：为什么会出现（由来）、规则本身是怎么回事（规则详解）、拿到之后怎么用（使用指南）、以及怎么把它跑起来（搭建与运维）。前半部分帮助理解，后半部分可以直接照着操作。
项目入口：本站项目列表 · CoralBay Rules 仓库 · 最新发布。本站项目卡片会打开对应仓库，下载、文档和问题反馈仍以仓库为准。
它解决什么问题
日常折腾代理配置时，真正麻烦的往往不是「能不能连上」，而是三件事：
CoralBay Rules 把这三件事收进一个自托管服务里。本文更新时的最新正式版是 v4.17.1，支持 Linux amd64 / arm64，并以 Docker Compose 部署。
由来：这套东西是怎么长出来的
要理解 CoralBay Rules 的设计取舍，先看它涉及的技术。项目本身的正式缘起以仓库 README 与 Issues 为准，下面这段梳理的是它所解决的问题的来历——三个各自独立的痛点，最后被收拢到同一个面板里。
1. 订阅转换的由来：一个订阅，十几种客户端
机场下发的通常是一串节点信息，但不同客户端吃的格式完全不同：Clash 系要 YAML，sing-box 要自己的 JSON，Surge、Loon、Quantumult X、Shadowrocket 各有各的语法，V2Ray 系又是一套 URI。于是一串节点要被反复翻译。
这个翻译工作最早由开源的 subconverter 一统江湖——它接受一个订阅地址，配合一份 INI 预设（ACL4SSR 之类的分流模板），吐出各客户端能直接用的配置。之后社区陆续维护出 subconverter-ng 等分支，修复兼容性、补新格式。CoralBay Rules 内置的正是 subconverter-ng 后端，但它做了一个关键取舍：
2. 分流规则的由来：从「全局代理」到「按域分流」
最早大家都是全局代理，所有流量无差别转发——结果是国内网站变慢、银行 App 风控、 CDN 走错。后来出现了三种演进：
规则越堆越多，加载也越吃资源——这就是下一节 MRS 二进制规则出现的原因：把域名或 IP 集合预编译成更紧凑的二进制，客户端无需在启动时解析大段文本。实际启动时间和内存收益仍取决于客户端、规则规模与设备，不能脱离统一基准给出固定倍数。
3. 镜像的由来：上游地址是单点故障
规则几乎都托管在 GitHub 上。对国内及部分网络环境来说，这带来三个问题：拉取不稳定、上游改路径或删仓库时全体失效、客户端配置里长期裸露第三方地址（一旦被墙或限速，配置直接打不开）。
自建镜像就是标准解法：用计划任务定时把上游拉下来，转成本域名的地址，客户端只认识你自己的域名。CoralBay Rules 把这件事做得比「写个 crontab git pull」严谨得多：
三条脉络合起来，就是 CoralBay Rules 的定位：把「转换」「分流」「镜像」三件原本要自己写脚本的事，变成一个可以点开看、可以追溯的自托管服务。
先确定你要的是转换后的节点、完整分流配置，还是给平台用的模板。三种交付物不能互相顶替，也不能因为都有一个链接就填进同一入口。
核心能力
1. 普通订阅转换
入口在「订阅服务 → 普通订阅转换」。它最多合并 5 个 HTTP/HTTPS 订阅地址，输出覆盖 Clash/Mihomo、ClashR、sing-box、Surge、Surfboard、Shadowrocket、Quantumult(X)、Loon、V2Ray、SS、SSR、Trojan 和混合 URI。
可配置的项相当细：包含/排除正则、节点重命名、远程配置预设、更新间隔、Emoji、排序、去重、UDP/XUDP、TFO、TLS 1.3、证书校验、仅节点输出、规则展开、DoH 以及客户端专属参数。
这里重要的是它的验证前置：CoralBay 会先真正执行一次转换、检查可解析节点数量，通过之后才生成 HMAC 签名的 /sub 地址。不兼容的目标（比如把全 VLESS Reality 订阅转成 Surge）会直接拒绝，而不是发布一份空配置给你。结构可解析不等于节点已经通过真实网络连通性测试。
普通转换页首先确定原始订阅和目标客户端，再决定是否添加过滤或远程配置。本地演示只运行控制台，未启动转换后端，画面保留了“后端不可用”和 MRS 解码能力不可用的提示；这不是转换成功的截图。正式搭建应按部署文档准备完整依赖，不能把控制台服务在线当成转换后端已就绪。
2. 自定义分流订阅
入口在「订阅服务 → 自定义分流订阅」，交付的是 Mihomo / OpenClash / Stash 的完整分流配置链接。这正是前面说的「让 AI、视频、社交走不同节点」的落地方式：策略组是你的意图，规则集是判定依据，两者拼起来就是一份可直接导入的配置。一个方案可填写 1–8 个原始 HTTP(S) 订阅，单个订阅最多 8 MiB，合并上限为 5,000 个节点；它不展开远程 proxy-providers，也不继承源配置里的规则、DNS、脚本和策略组。
3. 两套相互独立的规则源
这是这个项目比较特别的地方——666OS 规则镜像 和 MetaCubeX 自定义分流 是两条互不干扰的链路：
规则源页显示本地已发布版本、原始文件条目和上游检查状态。本地文件可用与上游已经检查是两回事；图中已有本地快照，上游状态仍是“尚未检查”。同步最新版本、检查上游和修复当前版本三个按钮，不要当成同一个操作。
点开详情后，可以核对来源、固定版本、格式、大小、SHA-256 和更新时间，再继续查看条目。图中读取的是本机已有文件，没有因为打开详情就升级规则，也没有把规则文件存在当作节点可访问的证明。
同步链路和客户端实际命中规则不是同一层。666OS 镜像与 MetaCubeX 自定义分流独立；有本地文件也不代表已经检查过最新上游。
4. 妙妙屋X、PPanel 与 MihomoPro：三个客户端配置入口
4.15.0 新增妙妙屋X，与此前已有的 PPanel、MihomoPro 形成三个客户端配置入口：
这三个入口与“普通订阅转换”“自定义分流订阅”彼此独立，不能把模板文件当成订阅转换结果。部署和普通转换也不依赖 PPanel、Nextin 或妙妙屋X。
妙妙屋X 页面先选目标客户端和规则来源，再取得模板，导入妙妙屋X 后绑定自己的订阅。这里展示 Clash / Mihomo 入口和 YAML 文件名；本地演示没有备齐 666OS 配置镜像，没有把模板下载和客户端连通算作通过。
5. 一套方案复用到多个入口：4.16.0 的分组与分流设置
4.16.0 把妙妙屋X、PPanel Mihomo 系模板和 MihomoPro 覆写接入同一套“分组与分流设置”。可以让三个入口继承共用方案，也可以各自保存独立方案：
“自动与均衡”页把测试地址、检测间隔、切换容差和均衡方式放在一起。图中是 300 秒、50 毫秒和“相同网站优先使用同一节点”的参数示例，不是测速结果。均衡按连接分配，不会把一条连接的带宽叠加起来。
支持范围以 Mihomo 系为主：妙妙屋X Clash V3/Mihomo、PPanel 的 Clash（Mihomo 内核）/Mihomo/OpenClash，以及 MihomoPro 的配对 YAML/覆写。4.16.0 也新纳入妙妙屋 Surge、Loon 原生基础模板，但它们尚未接入这套地区均衡方案，且仍属于开发中扩展，未完成私有妙妙屋后台与原生客户端的连通验收。
“规则与高级”页可以单独打开 YouTube、Netflix、Disney、Spotify 分流；DNS、IPv6 和流量嗅探也能选择沿用当前模板。截图保留了未选好来源时的红色提示：先准备来源，再生成文件。这是设置页展示，不是一份已经验证可用的客户端配置。
方案设置与生成文件是两个动作。产物身份包含来源、规则版本、输入摘要和设置摘要；修改方案不会悄悄覆盖已经交付的固定链接。
MihomoPro 的地区页先列独立地区，再收纳剩余节点的大区，每个地区分别控制自动与均衡，手动保留。截图里的“未检测”不是测速失败：这次没有提供真实节点做归属预览。按名称匹配地区、选择策略组和实际出口检测，仍是三件事。
把香港、东京、德国、越南和一个未知名称粘进预览，界面给出 5 个名称、5 个已归组、1 个进入兜底、0 个多重匹配。这里不需要订阅链接或节点密码。结果只说明名称匹配到了哪个组，不能证明真实出口位置、连通性或流媒体解锁情况。
6. 历史版本与回收站：4.17.0 的可恢复交付
4.17.0 给三个模板入口补上完整生成历史：可以按方案、客户端和版本搜索，查看生成日期、次数、完整正文、规则版本与当时设置，也可以打开、下载、复制链接，或把旧设置复用成新草稿。MihomoPro 的覆写与配套完整 YAML 按同一版本管理。
地区与大区也变得更细：独立地区可以取消和排序，大区可以关闭；地区、大区和兜底的自动／均衡模式可单独或批量停用，手动与兜底始终保留。若默认出口指向已关闭分组，系统会要求重新选择，不会静默改成直连。
DNS、IPv6 与嗅探选项会按所选客户端展示实际基础字段、模板版本、影响和本次覆盖范围；选择“沿用”表示保留模板原值，不代表系统会自动挑选最佳模式。
删除历史文件只是移入回收站：源站对新请求返回 HTTP 410，恢复后原 URL 与内容重新可用。它不会撤回客户端已经下载的文件，也不能清除浏览器或 CDN 旧缓存；回收站目前不物理删除文件，因此不会释放磁盘空间。
固定产物和运行中的规则快照要分开理解。历史文件进回收站不会释放磁盘；恢复的是对应固定文件，不是一套完整的历史规则版本回退。
7. 284 张本地图标与地区选择修复：4.17.1
4.17.1 内置 251 张国家／地区／组织旗帜 PNG，并保留原有 27 张图标、增加 6 张大区地图图标，合计 284 张。原有与大区图标来自固定版本 Qure，旗帜来自固定版本的 hampusborgos/country-flags；不能把 284 张全部称为 Qure 图标。
图标随程序和 Docker 镜像内置，/_assets/icons/ 可免登录读取，首次规则同步失败时也能提供。只有在方案里开启“使用本机缓存图标”，生成配置才会写入图标字段；图标只改变展示，不参与测速、分流或节点字段修改。
这一版还补齐了“全球手动”的候选：除单节点外，还会列出当前启用的独立地区、大区与兜底的自动、均衡、手动组。“故障转移”则继续保持纯节点 fallback，不会混入选择器并制造循环引用。
规则详解：一条规则到底是怎么生效的
「分流」听起来抽象，拆开其实非常机械。一条规则 = 一个匹配条件 + 一个出站策略。客户端把流量从上往下逐条比对，通常命中即停；一个明确例外是 UDP 流量命中了不支持 UDP 的代理节点时，Mihomo 可能继续向下匹配。其余没命中的流量落到最后一条兜底规则（通常写成 MATCH 或「漏网之鱼」）。所以分流调不好，九成是两件事没做对：条件写错了，或者顺序排错了。
1. 常见规则类型
图只解释匹配顺序，不宣称某个站点已经成功解锁。精确规则在前，宽泛规则在后，MATCH 最后；最终用了哪个出口，要看命中规则指向的策略组和客户端日志。
2. 规则一般按用途分这几组
不管规则来自 666OS 还是 MetaCubeX，实际使用时基本都会归到这些组；理解了分组，看别人的配置也容易些：
3. MRS 与可读源：为什么要两份
项目会把给客户端加载的 MRS 与供人阅读的关联源并列展示，但两者用途不同，也不是每份 MRS 都有公开可读源：
4. 666OS 与 MetaCubeX 怎么选
同一方案的自定义分流地址可以持续使用；普通转换参数变化通常要换新签名链接；平台模板则要重新生成、替换和刷新，不能等后台同步自动改掉旧模板。
5. 调规则时最容易踩的坑（列举）
使用指南：从拿到链接到确认生效
第一步：生成交付链接
第一次配置：先决定你要拿到什么
如果只是把现有订阅换成另一种客户端格式，进“普通订阅转换”；如果要自己安排 AI、视频、社交的策略组，进“自定义分流订阅”；如果你维护的是 PPanel、妙妙屋X 或 MihomoPro 的平台配置，则用对应模板或覆写入口。这几条链路的输入和交付物不同，不能拿一个入口的地址随便填到另一个入口。
先只接一条你有权使用的订阅，选实际要用的客户端，不急着加名称正则、地区排除或复杂 DNS 设置。若选“本机镜像”，先确认所需 MetaCubeX 原始规则已经发布到本地；缺失时先同步，不能把面板能打开当成规则已准备好。
服务规则页把“是否启用这类规则”和“这类流量去哪里”分开。以 OpenAI 为例，先保留全局节点范围，确认规则与策略组能生成，再按需要独立覆盖。地区是根据节点名称识别的筛选条件，不是对真实出口或服务解锁的承诺。
本篇六张控制台截图来自按 v4.17.1 源码启动的本地演示环境，规则资源页读取的是已下载的公开 MetaCubeX 文件。subscription.example.com 是占位地址，未抓取真实订阅、未生成交付链接，也没有做节点连通性测试。真实使用时，完成预览与保存后，再按下一步导入客户端并检查连接日志。
第二步：在客户端导入
把对应客户端的交付地址按订阅或远程配置导入；不同目标格式不能混用：
第三步：设置更新节奏
第四步：验证它真的在工作
后台接受配置，只证明生成阶段通过了检查。导入后先看节点和结构，再访问对应服务，最后查日志确认实际命中；只看控制台在线，缺了后面几层。
常见问题（FAQ）
搭建：把它跑起来
通用流程如下，具体字段与命令以仓库 docs/deployment.md 和 Release 说明为准——出站隔离等涉及安全的升级常常要求安装脚本与 Compose 同步更新，照抄旧脚本会踩坑。
1. 前置条件
2. 官方安装脚本（推荐）
当前完整部署不只有一个应用容器，还包含内网的 subconverter 和独立 updater。因此不要照着单服务 Compose 片段自行拼装，直接使用仓库安装器更稳妥：
这里用 CORALBAY_IMAGE 把 app 固定在 4.17.1；脚本本身仍从 main 下载，bash -n 只做语法检查，并不验证来源、提交或摘要。对供应链要求更高时，应先把脚本下载到本地，核对仓库提交与内容后再执行。
安装器会生成完整 Compose、写入 .env 并做启动检查。默认将主应用映射为 127.0.0.1:3999 → app:8080，转换后端只在 Compose 内网提供服务；域名、证书和 80/443 仍由现有反代管理。首次安装会要求隐藏输入并确认至少 12 位管理员密码，不存在公开默认口令。
反向代理对外提供 HTTPS，app 通过回环映射接入。subconverter 只在 Compose 内网提供转换，updater 单独负责更新；控制台能打开不代表依赖都已就绪。
3. 已安装用户升级到 4.17.1
升级前按官方流程短暂停止 app/updater，再一致性备份 .env、compose.yaml 和整个 data/；不要在服务运行时只复制单个 SQLite 文件。备份包含密码、内部令牌、订阅凭据与签名密钥，应限制权限并加密保存。同时记录 Compose 中每个服务的镜像引用与摘要。固定 app 版本的升级命令是：
从 4.15.0 到 4.17.1 没有新增必填环境变量，但固定旧标签的服务器不会自动切换到新版本；不显式传入新 CORALBAY_IMAGE 时，rules update 会继续沿用 .env 里的旧标签。需要特别注意：CORALBAY_IMAGE 只固定 app，rules update 仍会从 main 获取当前脚本和 Compose，其他服务（包括 subconverter）也可能使用各自的 latest。因此这不是整套部署的完全锁版，升级前后都应记录所有服务的镜像摘要。升级应用也不会改写已经导入妙妙屋X、PPanel 或 OpenClash 的模板；要采用新分组、图标和选择器行为，升级后还要按原方案重新生成文件、替换平台模板并刷新客户端订阅。
只锁 app 标签，不等于锁住所有服务。先留下各服务镜像摘要，按官方流程停止 app/updater 后做一致性归档；回退前还要确认数据兼容性。
4. 域名与 HTTPS
规则域名必须能被客户端稳定访问，HTTPS 不是可选项——不少客户端拒绝从明文地址加载规则。用 Caddy 的话大致是：
当前由一个 MIRROR_DOMAIN 统一承载普通订阅、自定义分流订阅、规则、模板与图标，不能在项目配置里把“订阅域名”和“规则域名”分别设置。若要采用不同缓存策略，应在同一反向代理或 CDN 上按路径区分。启用本机来源／本地图标后的生成产物会引用这个域名，但未被镜像的上游或第三方依赖仍可能保留外部地址，不能把它理解为所有资源都会自动本地化。
5. 首次初始化清单
6. 升级与排障
拉不到配置先查反代、解析和证书；节点为空再查过滤与目标协议；只有某条流量走错时，查实际规则命中。不同故障不必都从规则页开始改。
部署与安全性
项目内置 subconverter-ng 后端，但不直接暴露其端口，只在 Compose 内网提供服务——订阅不会被发到公共转换站。项目也不提供公共短链接，不执行用户提交的任意 JavaScript。
签名和令牌解决的是访问控制或完整性，不是保密：普通 /sub 的 HMAC 能阻止参数被篡改，却不会加密 URL；原始订阅地址仍可能出现在查询串、反向代理／CDN 日志、截图和工单中。/routing/sub/{token}/... 则是典型的 bearer token，谁拿到谁能访问，泄露后应在管理页重置。部署时应关闭或脱敏两个订阅端点的完整请求目标／访问日志：既包括 /sub 的查询串，也包括 /routing/sub/ 路径里的 token；同时避免公开分享、截图和可被索引的工单，并阻止 CDN 对这些订阅路径做公开缓存。
几处边界设计能看出作者比较谨慎：
出站隔离相关的升级需要同时更新安装脚本和 Compose，不是只更新 app 镜像，升级时注意这点。
订阅 URL 本身需要保护。HMAC 不会把查询串里的原始订阅加密；自定义分流路径里的 token 也可能泄露到日志。两类路径都要避免公开缓存和完整记录。
适用与不适用
适合：
不适合：
相关链接
---
本文已按 4.17.1 正式版的 README、CHANGELOG、Release 与源码边界更新；「规则详解」「使用指南」「搭建」三节为面向使用者的展开说明。实际可用标签、字段与升级边界仍以 GitHub Releases、docs/deployment.md 和 Docker Hub 为准。发布新版本不会自动升级使用固定标签的服务器，也不会替换已经导入妙妙屋X、PPanel 或 OpenClash 的固定模板。