iPhone 上用 Stash 导入 Clash 订阅：分流规则与按需代理首次配置步骤

1. 为什么在 iPhone 上常选 Stash，它和「Clash 订阅」是什么关系

Clash 订阅在习惯上多指一份远程 YAML／JSON 配置：服务商把节点、策略组与分流规则打包成 URL，你在客户端里填入这个 URL，由应用定期拉取并合并到本地配置。只要客户端内核兼容 Clash／mihomo 系语义，你在 iPhone 上看到的「节点列表」与「规则」就与桌面端是同一套心智模型，差别主要在系统如何转发流量以及 App Store 分发与权限流程。

Stash面向 iOS 场景，把上述远程配置、运行状态与日志集中在移动端界面里；不同版本菜单名称可能略有出入，但主线始终是：导入订阅 → 选中配置 → 选择规则模式 → 在策略组里选节点。若你更熟悉桌面上的 Clash Verge 一类工具，可以把 Stash 理解为「把同一份 Clash 配置搬到手机上跑」，但仍需按 iOS 的网络扩展／证书与省电策略来理解偶发差异。

2. 开始之前：客户端获取、权限与一份可用的订阅链接

请从正规渠道获取 Stash 安装包（通常为 App Store；各地区上架政策不同，若你所在区域商店未提供，需使用对应区域 Apple ID，具体以你当前环境为准）。首次打开后，系统会提示授予VPN 或网络扩展相关权限，请按引导完成，否则流量无法进入客户端内核，后续所有分流规则都不会生效。

同时请准备好Clash 订阅链接：它应能在 Safari 或另一台已成功的设备上访问，并返回可读的配置内容。若你对链接格式或导入位置不熟，可先对照本站 订阅导入教程理清「远程 URL → 客户端配置档案」的关系，再回到 Stash 内添加远程配置／订阅并执行更新。

3. 导入 Clash 订阅：远程配置、更新与策略组可见性

在 Stash 中找到与「配置、配置档案、Profiles」类似的入口，新增一条远程配置，粘贴你的 Clash 订阅 URL。保存后执行更新／拉取，确认更新时间、节点数量与策略组名称与预期一致。若更新失败，优先在系统浏览器或日志里区分是链接失效、TLS 拦截还是当前网络阻止访问该域名，不要急于改规则。

拉取成功后，在主界面选中这份配置为当前使用，并展开策略组（常见命名如 PROXY、自动选择、故障转移等，具体以订阅为准）。先手动点选一个延迟正常的节点，用系统浏览器打开一个纯文本测试页，确认「能上网」这一层已经成立，再进入下一节的模式选择。若策略组为空或节点全红，问题仍在订阅或网络层，而不是分流规则文本本身。

4. 规则模式与全局：首次建议始终从「规则」入手

Clash 系客户端通常提供直连（Direct）、规则（Rule）与全局（Global）等运行模式。对绝大多数用户，首次配置应停留在规则模式：由订阅中的 DOMAIN、GEOIP、IP-CIDR 等条目决定流量去向，仅在命中对应策略时才走代理。全局模式会把「可代理类流量」集中到单一出口，国内站点若未在规则中被明确直连，更容易出现意料之外的绕路或风控提示。

直连模式则适合短暂排错：当你怀疑是分流规则写错而非节点故障时，可临时验证「不经由代理」的基准表现。日常长期使用仍建议回到规则模式，并把「哪些域名走哪条策略组」交给订阅维护者或你在本地覆写中调整。关于规则优先级与策略链的更多细节，可延伸阅读 高级规则分流指南，避免只改节点却不改规则导致现象不变。

5. 分流规则怎么决定流量走直连还是代理

在规则模式下，内核会按订阅中的顺序自上而下匹配：命中某条规则后，流量被送往对应的策略或策略组；若一路未命中，通常由最后的 MATCH 兜底。你可以把分流规则理解为「业务意图」：哪些站点属于海外服务、哪些 CDN 需要固定出口、哪些 IP 段应直连。节点只决定「走代理时的下一跳」，而规则决定「要不要走代理」。

因此，当你感觉「只有浏览器能用、某 App 仍异常」时，要先判断该 App 的请求主机名是否被你的规则覆盖，以及 DNS 解析路径是否与规则一致。iOS 上部分应用会硬编码 DNS、使用 QUIC 或自有证书钉扎，表现为「规则看起来对，但行为仍怪」。此时与其盲目切换节点，不如先对照客户端日志里的域名与策略命中记录，再决定是补规则、换策略组，还是暂时关闭某协议特性做对照实验。

若你希望深入理解「规则条目长什么样」，可在电脑上用文本方式打开同一份配置，观察 rules: 与 proxy-groups: 的结构；手机端则以「策略命中结果」与「实际访问表现」对照为主，避免在小屏上直接编辑大段 YAML。

6. 按需代理在 iOS 上如何实现：与 Android 分应用对照

在 Android 上，很多用户用 分应用代理实现「只有几款 App 走 VPN」：系统在进程层先筛选包名，再进入 Clash 规则。iOS 并不向普通用户提供等价的系统级按应用勾选列表，因此按需代理在 iPhone 上更常见的落点是：用分流规则限定域名与 IP 段，再配合策略组为不同业务选择不同节点或直连。换言之，「需」体现在规则与策略上，而不是应用勾选面板上。

若你曾阅读本站 Clash Android 分应用代理 一文，可以把本文当作同一目标在 iOS 上的另一种实现路径：Android 侧重「谁进隧道」，iOS 侧重「进隧道后如何按域名细分」。两者可以并存于你的知识库：跨平台时不要用 Android 的勾选经验硬套到 Stash 的界面上。

实践中，「按需」还经常体现为：为国内常用服务保留直连或独立策略组，为搜索、代码托管、AI 服务等单独分组；当你只需要临时访问少数海外站点时，也可以通过切换策略组或启用订阅提供的「轻量规则集」来达到接近「按需」的体验。关键是保持规则模式可读、可回滚，而不是长期依赖全局。

7. 增强模式、DNS 与常见误区（简要）

部分版本提供「增强」或类似名称的能力，用于扩展系统级转发范围或处理特定协议；不同发行版命名与副作用不尽相同。首次配置阶段，建议先在默认、可理解的范围内跑通，再阅读当前版本的发行说明，确认开启后会改变 DNS、证书还是 TUN 行为。若你已在桌面端使用过 TUN 模式，可把「增强」理解为需要额外谨慎对待的一类能力：它能解决部分应用绕过代理的问题，也可能引入新的解析路径与日志噪声。

DNS 方面，若 iOS 系统设置里启用了「私人 DNS」且与客户端上游不一致，可能出现「规则命中与解析结果对不上」的现象。遇到这类问题，可先统一解析路径或在客户端内观察 Fake-IP／Redir-Host 等行为是否符合订阅设计，再决定是否调整系统设置。MITM、脚本与插件属于高阶话题，未弄懂信任边界前不建议在主力设备上贸然开启。

8. 常见问题与排查顺序

订阅更新失败：先换网络、检查系统时间、确认 URL 未过期，再对照日志里是 TLS、HTTP 还是 DNS 报错。不要一上来就改分流规则。

国内站点变慢或异常：多为全局模式、兜底策略组选错，或规则把国内流量送向海外出口。切回规则模式，检查 GEOIP 与 MATCH 是否符合预期。

部分 App 仍不走代理：可能是应用使用自有网络栈、热点共享或企业描述文件限制。此时应优先查日志与策略命中，而不是反复重装客户端。

9. 首次配置自检清单