订阅更新之后
列表里的主机、端口、剩余流量可能变。分流逻辑通常不变。国内站突然变慢，不要先怪「订阅更新坏了」。先问当前启用的是哪份配置。
配置文件不是订阅
两份地址都可能以 https 开头，都可能被服务商一起发来。它们进的不是同一个底栏。
各回答一个问题
订阅回答：现在有哪些出口，你选哪一条。结果出现在 Home 的 SERVER。配置回答：这个请求直连，还是走当前出口。结果出现在 Config，当前启用的那一份文件名会标出来，常见是 default.conf。把这两个问题合成一句「我导入了」，后面就会出现一种典型错觉：节点很多，访问却完全不按预期，于是开始怀疑应用坏了。
Global Routing 停在 Config 时，真正生效的是这份文件，不是订阅里的节点名字，也不是你刚才测到的最低延迟。节点再多，规则把请求判去 DIRECT，隧道也不会帮你打开那个站点。反过来，规则把本该直连的请求送进隧道，你会觉得「开了之后国内也卡」。这两种情况都不是用再买一家订阅能修好的。
三层里它是第三层。第一层是客户端，第二层是出口。还没分清的人，先读 应用、订阅、配置不是一层。第二层入口选错的人，先读 Subscribe 不是 Add Server。下面只讲文件这一层。
为什么两份 URL 总被贴反
服务商常常同时给「订阅地址」和「配置地址」。它们都很长，都像普通网页链接，有时还放在同一封说明里。收件人只记住复制。Shadowrocket 却把它们放进两个底栏：一个在 Home 的 Type 里，一个在 Config 的添加里。贴反之后，一种结果是列表空，另一种是节点在、分流乱。两种结果都不会弹出「你贴错栏了」。
把配置 URL 贴进 Subscribe，应用会按订阅格式去拉。拉下来的不是节点清单，更新失败，或多出一条无法展开的记录。把订阅 URL 当成配置导入，文件解析会失败，或得到一份根本不含规则的内容。Home 看起来正常，分流却完全不按预期。这两种失败要分开记，不要用同一套「再导入一次」应对。
还有人把配置文件的本地备份和订阅备份混在 Data 的导入导出里。能导出来，不代表可以交叉喂回去。导出是为了换机和以防万一，不是把两层焊成一份。换机时两份都要在，缺一份就只恢复了一半。
配置更换之后
节点列表通常还在。变的是谁走代理。有人换了远程配置，却以为自己「换了一家机场」。出口还是原来那些，只是判决变了。
default.conf 已经是一份完整规则
新装之后，Config 里通常已有默认文件。它不是空白草稿，也不是「还没配置所以不能用」的占位符。没有远程配置时，日常可以先用它，把 Global Routing 留在 Config。很多人觉得必须立刻导入一份「更专业」的文件，才算完成安装。这会把第三层过早复杂化，掩盖第二层还没接好的事实。
默认文件的目标，是让常见国内流量走直连，让需要代理的请求走当前节点。它不可能覆盖你的每一个站点偏好。个别站点异常时，先用三种口径对照，确认问题确实在规则，再考虑换文件或改条目。一上来就整份替换，会失去对照基线：你再也说不清「是默认就不行，还是我换进去的这份不行」。
服务商另给配置 URL 时，在 Config 里添加远程文件，再启用它。启用意味着「从现在起按这份判决」。旧文件还在列表里，并没有消失。出了问题可以切回 default.conf，这比删除重来更利于判断。不要把远程配置贴进 Subscribe，也不要以为启用新文件会自动换一批节点。
什么时候才需要动配置
先满足这些条件再碰这一层：应用是官方那一份；Home 里有选中的节点；状态栏有 VPN；至少有一部分站点在某种口径下是通的。节点延迟全超时，或系统根本没放行 VPN，改配置等于在空管道上改阀门。
典型该动配置的信号是：Proxy 能打开、Config 不能打开，或 Config 下国内站点明显被送进了隧道。前者说明出口可用、判决把目标留在了直连或不可用策略；后者说明判决太宽。两种都指向文件，不指向「再加一条订阅」。
不该动配置的信号是：直连也打不开同一个站点；所有口径都失败；Home 是空的。这些分别属于本机网络、出口或还没导入。继续往 default.conf 里加条目，只会多出一层噪音。