有一次，我需要在 iPhone 上使用一份已有的 sing-box 配置。那份配置原本用于桌面端，里面包含多个出站节点、分流规则、DNS 设置，以及一些针对特定网站的直连或代理规则。按照以往经验，手机端要么重新手动填写，要么等待配置文件重新生成。后来在 App Store 看到 OneBoxM 的介绍页面写明它基于 sing-box，支持读取兼容配置，于是决定尝试直接导入现有配置。下面把这次理解到的读取思路整理成一篇分步教程，重点不是界面位置，而是认知顺序：先理解它如何对待一份配置，再理解 Rule Set、按需连接和 Override 这些机制如何影响最终运行效果。
第一步：理解 OneBoxM 与 sing-box 配置的基本关系
OneBoxM 是一款运行于 iPhone 和 iPad 的应用，系统要求为 iOS 18.0 或更高版本。它基于 sing-box，因此能够理解 sing-box 风格的配置结构。所谓“兼容配置”，是指符合 sing-box 规范的 JSON 或经过编码后的配置内容。OneBoxM 读取配置时，并不是把配置内容原样展示在界面上，而是将其解析为应用内部可以调度的对象。用户看到的是面向触屏的简洁设置，但底层逻辑仍遵循 sing-box 的配置模型。
在导入配置之前，可以先把自己手头的配置分成几个层次：出站、路由规则、DNS、入站。OneBoxM 读取时，通常会保留这些层次的作用，但具体界面呈现取决于当前应用版本。由于操作界面细节没有官方公开文档说明，本文不描述具体按钮位置，只讨论读取配置的通用思路。实际使用时，应以当前 App Store 版本和应用内实际显示为准。
第二步：确认配置来源的兼容性
一份配置可能来自桌面端 sing-box、其他兼容工具，或者自己手写。OneBoxM 读取此类配置时，是否能完整识别，取决于配置中使用的字段是否为 sing-box 通用字段。对于标准出站类型、常见路由规则和 DNS 服务器设置，兼容性通常更高。对于一些过于依赖特定平台特性的字段，读取结果可能需要在应用内进一步调整。
建议先保持配置简单，不要一次性加入大量自定义脚本或复杂逻辑。可以先导入一份只包含基础出站和 DNS 的配置，观察读取结果。若应用内能正常显示节点与主要分流走向，再逐步补充更复杂规则。这样有助于定位哪一部分在读取时出现了差异。
第三步：理解 OneBoxM Rule Set 的作用
OneBoxM 支持 Rule Set，也就是规则集。规则集在 sing-box 中常用来批量管理域名、IP 或进程匹配条件。比如一个规则集可以包含“所有流媒体域名”，另一个规则集可以包含“所有需要直连的国内域名”。OneBoxM 读取配置时，如果配置中引用了规则集，它会将规则集作为路由判断的一部分来理解。
从读取思路看，规则集的意义在于让用户不必逐条写规则。OneBoxM 读取到规则集后，会把它们视作可重用的匹配来源。用户在应用内看到的可能不是原始规则文件路径，而是规则集对应的行为，例如“流媒体走代理”“广告域名拦截”等。理解这一点很重要：OneBoxM 读取的是规则集在路由中的角色，而不是规则集本身存储在哪里。因此，如果手头配置使用规则集，应关注这些规则集是否被正确关联到出站策略；如果读取后路由行为与预期不同，往往不是规则集内容丢失，而是规则集与策略的对应关系未被识别。
第四步：理解 OneBoxM 按需连接
OneBoxM 支持 On-Demand Connections，也就是按需连接。这个机制的核心不是“什么时候连接代理”，而是“什么样的网络环境需要自动启用或停用连接”。比如当设备接入某个需要代理的 Wi-Fi 时，按需连接可以自动让配置生效；当离开该网络或切换到其他网络时，则停止连接。
从读取配置的角度看，按需连接并不是从 sing-box 配置文件本身“读出来”的，而是 OneBoxM 在读取配置之后，为这份配置附加的调度条件。你可以理解为：sing-box 配置决定了“怎样连接”，而按需连接决定了“何时连接”。OneBoxM 读取一份配置后，如果用户启用了按需连接，应用会结合系统网络状态自动决定是否启动配置。这个功能对于移动场景非常有用，但它需要用户明确当前网络与代理规则之间的关系。读取配置时，可以考虑哪些网络环境需要自动启用，哪些不需要，这样在实际使用中避免频繁手动开关。
第五步：理解 OneBoxM Override 的边界
OneBoxM 支持 Override，也就是覆盖。这个功能允许用户在已读取的配置基础上，对部分行为进行局部修改，而不必重新导入整份配置。理解 Override 的思路是：基础配置提供主体结构，Override 提供个性化调整。
假设你导入了一份配置，其中的 DNS 使用系统默认设置，但你希望所有 DNS 查询都通过加密通道。如果界面支持 Override，你可以只覆盖 DNS 相关部分，而不影响出站节点和路由规则。OneBoxM 支持 DNS over TCP、DNS over TLS、DNS over HTTPS，因此 Override 可以用于调整 DNS 解析方式。这种覆盖不是修改原始配置文件，而是在应用运行时施加额外约束。读取配置时，用户需要意识到最终生效的结果等于“基础配置 + Override”。如果某些行为看起来与原始配置不一致，可能需要检查是否曾经设置过 Override。
第六步：梳理 DNS 读取与覆盖的方向
OneBoxM 支持 DNS over TCP、DNS over TLS、DNS over HTTPS。在读取 sing-box 配置时，DNS 部分尤为重要，因为很多代理问题最终表现为 DNS 解析异常。一份标准 sing-box 配置通常包含 DNS 服务器列表、查询策略、以及可能的地址解析规则。OneBoxM 读取这些内容后，会将其纳入系统网络栈的对应位置。
在实际读取思路中，可以优先确认 DNS 服务器是否支持加密协议。如果原配置使用明文 DNS，而你在使用移动网络时希望避免 DNS 查询被观察，可以通过 Override 将其调整为 DNS over TLS 或 DNS over HTTPS。这里需要注意的是，OneBoxM 虽然支持这些协议，但最终是否生效还取决于配置中是否保留了相关字段，以及应用是否允许覆盖。不要在未看到应用界面反馈的情况下假设修改已经成功。
第七步：避免过度依赖界面自动识别
OneBoxM 的界面设计面向触屏操作，但底层仍是 sing-box。因此，读取一份配置后，很多行为不会以文本形式展示，而是通过开关、列表或状态颜色表达。不要试图在 OneBoxM 里找到与 sing-box 配置文件一一对应的文本编辑框。更合适的理解方式是：OneBoxM 将 sing-box 配置转化为一套可操作的策略集合。用户看到的是策略分类、连接状态和网络条件，而不是原始 JSON。
这种设计意味着读取质量取决于配置本身的规范性。如果配置结构混乱、重复字段过多，或者使用了不常见的嵌套方式，OneBoxM 读取后可能在策略展示上出现简化。为了避免这种情况，建议在导入前对配置做一次人工整理，确保出站、路由、DNS 三大块结构清晰。
第八步：建立“读取—理解—覆盖”的完整循环
最后，把整个读取思路串起来。OneBoxM 读取 sing-box 配置，不是一次性导入就结束的过程，而是一个循环：
首先，读取基础配置，识别出站节点和主要路由策略。
然后，检查 OneBoxM Rule Set 是否按预期工作，确认规则集对应的分流行为是否符合需求。
接着，考虑按需连接是否适合当前使用场景。比如在办公室网络和移动网络之间切换时，自动启用或停止代理。
再通过 Override 对个别部分进行修正，例如把 DNS 改为加密通道，或者对某个出站策略进行局部替换。
最后，观察实际网络行为，判断基础配置与覆盖后的结果是否一致。
整个过程不需要记住任何具体按钮名称，而是记住四个关键机制：兼容配置、Rule Set、On-Demand Connections、Override。它们分别回答了四个问题：能读什么、怎么分流、何时启动、如何修改。理解这四个问题，就理解了 OneBoxM 读取 sing-box 配置的整体思路。
由于本文不涉及具体界面操作细节，实际使用时请以当前 App Store 中的 OneBoxM 版本和 iPhone、iPad 上的界面为准。配置是否能够完整读取、Rule Set 如何展示、按需连接如何触发、Override 可以覆盖哪些部分，都应以应用内实际呈现为准。只要把握住“底层是 sing-box”这一点，就能在遇到差异时，回到配置结构本身寻找原因，而不是盲目尝试界面上的每一个选项。
