订阅更新与自动更新周期，v2rayN 该怎么设

订阅更新这件事，多数人只会用到右键菜单里那一个"更新订阅"，然后在某天发现节点全变旧了、机场公告里说的新线路一个都看不到。问题不在于操作难，而在于 v2rayN 把更新拆成了三种触发方式，各自解决的场景不同，混着用就会出现"我明明更新过"的错觉。

更容易被忽略的是时间维度。订阅不是一次性导入就完事的资源，它是一份会随机场调整不断变化的清单：节点增删、地址迁移、线路替换都发生在服务端，客户端只有主动拉取才知道。所以真正要配的不是"怎么更新"，而是"多久更新一次、更新时走什么通道、更新完会覆盖掉什么"。

这三个问题的答案彼此关联。周期设短了没用，因为服务端变动没那么频繁；不走代理更新则可能连订阅地址都拉不到；而搞不清覆盖规则的人，往往会把自己手改过的节点弄丢一次才长记性。下面按这个逻辑逐项拆开。

什么情况下必须立刻手动更新一次订阅#

自动更新覆盖不了突发变动，以下几种情形应该手动触发一次，不要等周期到点。

最后一行是实际使用中最有价值的一条。全部节点一起超时，直觉反应是"网络出问题了"，但另一个同样常见的原因是机场做了整体迁移而你的列表还是旧的。先花十秒更新一次订阅，比花二十分钟排查本机网络划算得多。如果更新后仍然全部超时，才转入连接层排查。

手动触发有两个入口，区别只在作用范围：

1. 更新当前订阅——只重新拉取选中的那一个分组，速度快，适合明确知道是哪家机场有变动时使用。
2. 更新全部订阅——遍历所有已添加的订阅，适合换机、长期未开机、或不确定是哪一家变了的情况。

自动更新周期设多久比较合适#

周期这个数字没有标准答案，但有明确的上下界逻辑：下界由机场的实际变更频率决定，上界由你能容忍多久用着一份过期列表决定。

把周期压到一两小时是常见的过度优化。机场调整节点的频率通常以天为单位，高频拉取不会让你更早拿到新节点，反而带来两个副作用：一是每次拉取都有失败概率，失败次数随频率线性增长；二是部分服务端对同一账号的订阅请求有频率限制，短时间内反复请求可能被临时拒绝，反倒拿不到列表。

自动更新是在客户端运行期间按计时触发的。关机时间不计入周期，所以一台每天只开四小时的电脑，设 24 小时周期实际可能好几天才更新一次。这类机器更适合搭配手动更新使用。

「更新时使用代理」这个开关为什么是关键#

这是订阅设置里最容易被跳过、却最常导致"配置全对但更新失败"的一项。

它决定的是：客户端去拉取订阅地址时，走本机直连还是走当前已建立的代理通道。而订阅地址本身托管在什么地方、是否可以直连，取决于机场怎么部署，用户无法控制。当订阅域名恰好处于不可直连的状态时，不勾选这个开关就等于永远拉不到列表。

顺序很重要，这里存在一个先有鸡还是先有蛋的问题：

1. 首次导入时不要勾选——此时本地还没有任何可用节点，勾选后客户端会尝试通过一个不存在的代理去请求，必然失败。
2. 拿到节点并连上之后回来勾选——已经有一条能用的通道了，后续更新走它，就不再依赖订阅地址是否可直连。
3. 保持一个可用的历史节点——万一订阅长期拉不动，手里至少还有一条能用的线路把订阅拉回来。

第三点是很多人踩过的坑：删光旧节点再更新，一旦更新失败就彻底断了退路。稳妥做法是在更新前确认当前有连接，或者把一两个稳定的历史节点手动保存到订阅分组之外。

如果开关也开了、节点也有，更新依然失败，那问题已经不在这个设置上了，需要沿着获取链路逐段查，具体流程见订阅更新失败的分段排查。

更新之后手动添加的节点会被覆盖掉吗#

要分清两种节点，它们的归属完全不同。

第三行是真正的陷阱。有人为了测试，把订阅里某个节点的端口或传输方式改了一下，改完能用，就以为这个修改会一直保留。下一次更新时该分组被整体重建，改动消失，现象是"昨天还好好的今天又不行了"。

正确做法是：需要长期保留的自定义配置，用手动添加的方式单独建一条节点，而不是在订阅分组里改。手动添加各协议的字段含义可以对照 VLESS 与 VMess 的字段说明，Trojan 与 Hysteria 2 则见对应的那篇。

订阅更新、内核更新、软件更新是三回事#

这三个词都叫"更新"，作用对象却毫无交集，混淆之后排查方向会整个跑偏。

一个典型的误判：订阅更新成功、节点也拉到了，但某几个新协议的节点启动就报错。此时反复更新订阅毫无用处，因为列表已经是最新的，缺的是能跑这个协议的内核。反过来，内核更到最新也补不回一份过期的节点列表。

判断方法很直接——看是"节点不存在"还是"节点存在但起不来"。前者查订阅，后者查内核。

多个机场订阅一起更新，失败一个会拖累其他吗#

不会。v2rayN 对每个订阅分组是逐个请求、独立处理的，一个地址超时不会中断整个流程，其他分组照常拉取。

但有两个实际影响需要注意：

1. 整体耗时被拉长——失败的那个订阅要等到超时才放弃，如果同时有好几个失效地址，更新全部订阅会明显变慢。
2. 结果不易分辨——完成后只看到一个汇总提示，容易忽略其中某一组其实没更新成功。

所以维护多个订阅的人，建议养成一个习惯：更新后扫一眼各分组的节点数量。数量与上次基本一致说明正常，某一组突然归零就单独更新它一次确认。长期失效的订阅应该直接删掉而不是留着，留着只会每次更新都多等一段超时。

关于同时维护多家订阅的必要性和成本，属于选购层面的问题，可以参考主备机场的搭配思路。

更新完节点反而变少甚至清空，说明了什么#

这个现象几乎总是账号侧或订阅地址侧的问题，而不是客户端故障。按可能性从高到低排查：

第三行值得单独说：不少机场在账号异常时会把提示信息伪装成节点名下发，比如"套餐已到期请续费"这样一条假节点。看到节点列表里出现中文提示语句，不要试图去连它，直接去后台核对账号状态即可。

订阅地址被重置的触发条件通常是主动点击了后台的重置按钮，或者账号在异常数量的设备上使用触发了保护。前者是自己的操作，后者需要联系服务商确认。

小结#

订阅更新要分三层来配：触发方式上，日常靠自动周期、变动时手动补一次；周期上，24 小时是合理起点，机场调整期缩到 6 至 12 小时，压到一两小时属于无效优化；通道上，拿到第一批可用节点后务必打开"更新时使用代理"，并始终保留至少一条能用的线路做退路。覆盖规则记住一条即可——订阅分组会被整体重建，需要长期保留的自定义配置必须放在分组之外。更新完节点变少或清空，先查账号流量和到期时间，那几乎不是客户端的问题。