“我能不能直接用一份现成配置，再用 Override 把里面不合适的地方改掉？”这是接触 OneBoxM 时最常见的疑问之一。问题看似简单，背后其实牵扯两个不同层面的边界：一是 OneBoxM Override 能覆盖什么、不能覆盖什么；二是 OneBoxM Rule Set 使用在整体配置中处于什么位置、与按需连接如何分工。把这两层边界分清楚，很多“配置写了却没按预期工作”的困惑会自然消解。
需要先说明本文的写作原则：以下只陈述可确认的事实，包括 OneBoxM 支持 Override 覆盖当前配置文件的部分设置、支持 Rule Set 与 On-Demand Connections、兼容 sing-box 配置、支持 DNS over TCP/TLS/HTTPS、支持 TCP/UDP/ICMP 与域名/IP-CIDR 路由，平台为 iPhone/iPad、最低 iOS 18.0。凡涉及具体界面位置、字段名称、开关默认值、保存后的实际表现，都属于需要在使用中查看界面确认的细节，本文不代为断言，也不虚构任何配置语法或成功效果。
一、Override 的定位：覆盖“部分设置”，不是重写整份配置
理解 OneBoxM 配置覆盖的第一要点，是“部分”二字。Override 的语义是：以当前配置文件为基底，对其中的一部分设置施加覆盖。它不意味着你可以在 Override 里从零写一份完整配置，也不意味着原配置文件里的一切都会被 Override 接管。基线仍然来自当前配置文件，Override 只在其上做有限替换。
由此可以推出几条实用边界。其一，Override 的生效前提是存在一份当前配置文件作为基底；脱离基线的 Override 没有意义。其二，既然覆盖的是“部分设置”，那么哪些设置属于可覆盖范围、覆盖以何种粒度发生，需要以界面实际提供的项为准，不能凭想象假定“任何字段都能改”。其三，覆盖关系存在层级：当同一项在基线与 Override 中都有表达时，以 Override 为准；但这一判断只对确实被覆盖到的项成立，未覆盖项仍回到基线取值。很多“改了没反应”的情形，本质上是要改的项并不在 Override 的作用范围内，而不是覆盖机制失效。
还有一个容易被忽略的边界：Override 与“兼容 sing-box 配置”是两件事。兼容说明的是配置格式层面的可读性，Override 说明的是在当前配置之上做局部替换的能力。二者叠加使用时，仍需回到“部分设置”这一限定：兼容不等于全部可覆盖，可覆盖也不等于可以脱离 sing-box 配置的结构随意发挥。
二、Rule Set 的角色：路由规则的集合，而非连接开关
OneBoxM Rule Set 使用常被误解为“连接管理”。更准确的定位是：Rule Set 是路由规则的集合，它回答的是“某类流量走哪条路径”，而不是“某条连接何时建立”。OneBoxM 支持按域名与 IP-CIDR 进行路由，这正是 Rule Set 发挥作用的层面——以域名匹配和地址段匹配为依据，把流量分配到不同去向。
把 Rule Set 放在整体配置中看，它与 DNS、协议能力是并列的组成，而不是彼此替代。OneBoxM 支持 DNS over TCP/TLS/HTTPS，DNS 解析结果会影响基于域名的路由判断；支持 TCP/UDP/ICMP，说明规则面对的不只是单一传输类型。这意味着 Rule Set 的边界在于：它规定匹配与分流，但不负责解析本身，也不负责连接的生命周期管理。指望用 Rule Set 去“开启”或“关闭”某类连接，是把它放到了不属于它的位置上。
Rule Set 使用中另一个边界是匹配依据的有限性。既然路由依据是域名与 IP-CIDR，那么规则能表达的就是这两类条件及其组合；超出这一依据范围的诉求，不应假定 Rule Set 能表达。规则之间的先后与命中关系属于配置结构与界面呈现的细节，需查看界面确认，本文不给出具体写法。
三、按需连接：与规则分流是两个维度
OneBoxM 按需连接（On-Demand Connections）回答的是另一个问题：连接在什么条件下建立。它与 Rule Set 的分流判断分属不同维度——一个管“何时连”，一个管“连上之后流量怎么走”。把两者混为一谈，就会出现“规则写得很细，却不知道连接何时起来”的错位感。
边界因此清晰：按需连接不改变 Rule Set 的匹配逻辑，Rule Set 也不决定按需连接的触发条件。二者的交集仅在于它们共同服务于同一份当前配置：按需连接决定连接是否存在，Rule Set 在连接存在的前提下决定流量去向。至于按需连接的具体触发项、可选范围与默认状态，属于界面细节，应以实际界面为准，不宜凭推测设定。
四、三层叠加时的排查顺序
当 Override、Rule Set、按需连接同时出现在一份配置中，排查应按层级推进，而不是混在一起猜。第一层看基线：当前配置文件本身是否包含了你以为存在的设置。第二层看覆盖：目标项是否落在 Override 可覆盖的“部分设置”之内，若不在，改 Override 不会有效果。第三层看分流：连接已建立的前提下，Rule Set 是否以域名/IP-CIDR 的方式覆盖了该类流量。第四层才看按需连接：连接是否在该场景下被建立。这个顺序的价值在于，它把“配置覆盖”“规则分流”“连接建立”三类问题分开，避免用错层面的手段去修另一个层面的现象。
同时要守住事实与界面细节的分界。可以确定的是能力清单：Override 覆盖部分设置、Rule Set、按需连接、兼容 sing-box 配置、DNS over TCP/TLS/HTTPS、TCP/UDP/ICMP、域名/IP-CIDR 路由，平台 iPhone/iPad、最低 iOS 18.0。不能代为确定的是界面上的具体字段、开关位置、保存反馈与实际运行表现。写作与使用中都应保持这条界线：能力层面可以明确陈述，界面层面留待查看确认。
回到开头那个疑问：用 Override 改现成配置是可行的，但可行范围被“部分设置”框定；Rule Set 能让流量按域名与地址段分流，但它不是连接开关；按需连接管连接何时建立，不替规则做匹配。三者各守其位，边界清楚，配置才不会在错误的层面上被反复折腾。
