V2Ray 从零到精通：安装、订阅、分流与 TUN

先分清内核、客户端、节点与订阅

内核负责连接，客户端负责操作界面

V2Ray 不是某一个固定安装程序，而是一套包含协议、传输、路由和连接管理能力的技术体系。实际使用时，内核读取配置并建立网络连接，图形客户端则负责把订阅导入、节点切换、系统代理和日志查看等操作整理成可点击的界面。v2rayN、v2rayNG 与 v2flyNG 都属于图形客户端，它们会调用相应内核完成连接。排错时要区分“界面设置没有生效”和“内核连接失败”：前者通常看客户端状态与系统代理，后者要看节点参数、网络和核心日志。

节点是一组连接参数，不等于订阅

一个节点至少描述服务器地址、端口、协议和身份凭据，某些协议还会包含传输方式、TLS、服务器名称、路径或服务名。节点决定客户端尝试连接到哪里，以及如何建立连接。订阅则是用于批量分发节点和分组信息的链接。客户端更新订阅后，会解析链接返回的内容并生成节点列表；更新动作不会自动保证每个节点都可用，也不会替代线路质量测试。节点列表为空时，应先确认订阅解析是否成功，而不是立刻反复切换代理模式。

系统代理与流量转发是两层设置

内核运行只代表本地代理端口已经监听，不代表应用流量一定经过它。浏览器等遵循系统网络设置的程序，通常通过“系统代理”进入客户端；不读取系统代理的程序，可能需要单独设置代理，或者由 TUN 模式在网络层接管。判断连接是否完成要连续核对三件事：客户端核心处于运行状态、系统或应用已经把流量交给本地代理端口、当前节点能够到达目标。只看托盘图标或单个网页能否打开，无法准确定位问题所在层级。

协议、传输与路由分别解决什么问题

VMess、VLESS、Trojan 等名称属于连接协议层，TCP、WebSocket、gRPC 等属于承载数据的传输方式，路由规则则决定一条请求应当直连、代理还是阻断。三者可以组合，但不能互相替代。例如，节点使用 VLESS 并不决定某个网站是否直连；是否直连由客户端生成的路由配置决定。反过来，路由规则写得再准确，也无法修复服务器地址或身份参数填写错误。遇到问题时，把配置拆成“连接参数、传输参数、流量去向”三组，逐组核对比整份配置一起盲改更有效。

日志是可验证事实，不是附加信息

客户端日志通常会记录配置加载、端口监听、DNS 查询、连接建立和失败原因。看到超时，优先检查网络可达性、节点状态和线路；看到解析失败，检查域名与 DNS；看到配置字段错误，回到节点详情核对协议、传输和安全选项。日志中的时间顺序也很重要：先出现配置错误，后续连接失败往往只是连带结果。完整理解这些对象之后，再进入客户端选择和安装阶段，后面的每个开关才有明确含义。

按平台和内核需求选择客户端

桌面平台优先选择 v2rayN

Windows、macOS 与 Linux 桌面环境优先使用 v2rayN。它把订阅管理、节点列表、系统代理、路由规则和 TUN 模式集中在同一套操作逻辑中，适合从首次配置一直用到自定义分流。Windows 用户可在桌面版与经典 WPF 版之间选择：桌面版采用跨平台界面，适合希望不同桌面系统保持相近操作方式的用户；经典 WPF 版更贴近传统 Windows 桌面程序。两者的目标相同，不需要同时安装，选择一个作为固定工作环境即可。

Android 在两种内核取向之间选择

Android 首推 v2rayNG，它使用 Xray 内核，适合需要较完整协议与传输支持的场景。v2flyNG 使用 v2fly 内核，可作为明确需要 V2Fly 体系时的备选。两款客户端都能完成订阅导入、节点切换、路由设置和本地 VPN 接管，但配置字段与菜单位置可能不同。不要因为连接失败就在两款应用之间频繁迁移；先确认订阅本身提供的协议是否被当前客户端支持，再根据日志判断是否需要更换内核路线。

架构与安装包格式必须匹配

客户端名称选对之后，还要确认处理器架构和安装包格式。macOS 可从“关于本机”查看芯片类型，Apple 芯片选择 arm64，Intel 处理器选择 x64。Android 近年的主流设备通常使用 arm64；无法确认或设备架构较特殊时，可选择通用版，但通用包体积往往更大。Linux 不只区分 x64 与 arm64，还要区分软件包体系：Debian、Ubuntu 等使用 deb，Fedora、RHEL 系列通常使用 rpm。架构不匹配时，常见表现是安装程序无法启动或系统直接提示不支持。

不要用功能数量代替实际需求

选择客户端时先列出必要操作：是否需要系统代理、是否有不读取系统代理的程序、是否需要自定义域名分流、是否需要局域网共享。普通浏览器与办公应用通常只要订阅、节点切换和系统代理；需要覆盖更多应用流量时才考虑 TUN；需要精确控制流量去向时再进入自定义路由。功能越多，配置层级越多，故障来源也越多。首次使用应先建立最小可用配置，再逐项增加能力，每增加一项都保留一个可验证结果。

迁移客户端前先保留配置来源

更换设备或客户端前，至少记录订阅来源、当前路由模式和自定义规则。节点来源于订阅时，不必逐个手工复制节点；在新客户端重新导入订阅，随后恢复路由与代理模式即可。手工节点则需要完整保留协议字段，不能只记服务器和端口。涉及身份信息的配置应存放在受控位置，不要粘贴到公开页面。本站客户端对比进一步整理了三款客户端的适用边界，确定选择后再进入安装阶段。

完成安装并建立可回退的初始设置

安装前先关闭旧客户端的接管状态

同一设备上可以保留多个客户端，但不要让它们同时接管系统代理或 TUN。安装前先退出旧客户端，并在系统网络设置中确认没有遗留的手动代理地址。若旧程序异常退出，系统代理可能仍指向已经停止监听的本地端口，表现为所有网页都无法连接。此时先关闭系统手动代理，再启动新客户端。这样做的目的不是删除旧配置，而是保证首次测试只有一个流量入口，便于判断问题来自新客户端还是旧设置残留。

Windows：确定安装形态与运行权限

Windows 使用 v2rayN 时，先在下载中心的 Windows 分区选择桌面版或经典 WPF 版。安装完成后从开始菜单启动，首次运行应确认主窗口能够打开、核心目录能够被程序读取、日志中出现本地端口监听信息。普通系统代理功能通常不需要长期以管理员身份运行；只有启用需要系统网络驱动或路由调整的功能时，客户端才可能请求提升权限。不要把“始终以管理员身份运行”当作通用修复方案，它会掩盖目录权限或配置路径问题。

macOS：按芯片选择并确认系统授权

macOS 安装 v2rayN 时，先确认处理器类型，再选择对应的 dmg。打开磁盘映像后，将应用放入系统应用目录，避免长期从只读映像内直接运行。首次启动如出现来源确认，按系统安全设置中的提示完成授权。系统代理和 TUN 涉及的权限不同：系统代理主要修改当前网络服务的代理配置，TUN 则可能要求额外网络权限。初始阶段只配置系统代理，不要同时开启 TUN，这样可以先验证订阅与节点连接是否正常。

Linux：匹配发行版并检查桌面会话

Linux 用户按发行版选择 deb 或 rpm，并同时确认处理器架构。安装后从桌面应用列表启动，若界面没有出现，可在终端直接运行应用命令以查看启动错误。桌面环境对系统代理的读取方式并不完全一致，部分应用遵循桌面代理设置，部分应用使用自己的网络配置。因此，Linux 上“客户端正在运行”与“所有应用都已接管”不能画等号。首次验证建议选择明确遵循系统代理的浏览器，再处理单独配置代理的程序。

sudo apt install ./v2rayN-linux-x64.deb

# rpm 系发行版使用对应安装包
sudo rpm -Uvh v2rayN-linux-x64.rpm

Android：只保留一个活动的本地 VPN

Android 安装 v2rayNG 或 v2flyNG 后，首次连接会请求建立本地 VPN，这是系统把应用流量交给客户端的必要步骤。同一时间只能由一个应用保持这类接管状态，因此测试新客户端前要断开其他网络工具。导入订阅后先选择一个节点，保持路由为默认设置，再点击连接。状态栏出现连接标识只说明系统授权已经建立，仍要通过日志和实际访问验证节点是否成功连接。

首次启动后的五项核对

第一，确认客户端窗口和托盘菜单都能正常打开；第二，确认核心启动后没有配置错误；第三，记录本地 HTTP、SOCKS 或混合代理端口，避免和其他程序冲突；第四，检查开机启动是否符合使用习惯，暂不需要时保持关闭；第五，确认退出客户端时是否会自动恢复系统代理。完成这五项后再导入订阅。若安装阶段已经出现错误，不要带着错误继续配置订阅，否则后续日志会混入多层问题，排查成本会明显增加。

导入订阅、更新节点并判断解析结果

把订阅名称写成可识别的来源

在客户端的订阅管理中新增订阅时，名称应能说明用途或来源，例如“日常线路”或“测试线路”，不要只写“订阅一”“新建分组”。名称不会影响连接，但会直接影响更新和排错效率。链接必须完整复制，首尾不能带空格，也不要把网页展示文字误当作订阅地址。保存后执行一次手动更新，并观察提示与日志。只有节点列表实际增加或刷新，才算本次导入完成；仅仅保存订阅记录并不代表解析成功。

更新失败时按返回阶段分类

订阅更新大致分为获取、解码、解析和写入四个阶段。获取失败通常表现为超时、网络错误或服务器返回异常，应先确认当前网络能否访问订阅地址。解码失败说明返回内容不是客户端预期格式，可能是链接复制不完整、订阅过期或服务端返回了提示页面。解析失败多与节点字段格式、编码或客户端支持范围有关。写入失败则要检查配置目录权限、磁盘空间和旧配置状态。分清阶段后再处理，比连续点击更新更容易找到原因。

更新前后的节点变化要分别看

更新订阅可能新增、删除或修改节点。更新前正在使用的节点若被移除，客户端可能切换到其他节点，也可能保留一条已失去订阅关联的旧记录。更新后应确认当前选中节点仍存在，并检查自定义分组是否保持预期。若客户端提供“清除旧节点”或“按订阅覆盖”的选项，启用前要确认手工添加的节点是否会受影响。手工节点与订阅节点最好分组管理，避免更新时无法判断某条记录的来源。

延迟测试只能回答特定问题

节点延迟测试通常用于判断目标地址是否能在一定时间内响应，不等于真实下载速度，也不等于所有网站的访问质量。部分节点可能不响应某种探测方式，但实际代理仍可工作；也可能延迟很低，却因线路拥塞导致吞吐下降。正确做法是先用客户端测试排除明显不可达节点，再用固定网页或文件进行实际访问对比，并保持本地网络条件一致。一次测试结果波动较大时，应在不同时段重复，而不是立即修改协议参数。

订阅更新频率以变更需要为准

订阅无需在每次打开客户端时连续更新。节点来源明确且列表稳定时，可在发现节点不可用、收到配置变更提示或进入维护周期时手动更新。自动更新间隔不宜设置得过短，频繁请求不会提高节点质量，反而会让日志充满重复记录。更新后若整体不可用，先保留日志并确认是否所有节点都被替换，再参考订阅解析失败自查清单逐项检查链接、返回内容和更新通道。

手工节点要完整核对字段

手工添加节点时，不要只核对服务器和端口。协议类型、用户标识、加密或流控、安全层、传输方式、服务器名称、路径、服务名必须与提供方配置一致。空字段也有含义：某项应留空时，不要凭经验填入默认值。修改节点前可以复制一份记录作为回退，改动时每次只调整一组字段。连接成功后再为节点命名，名称应描述用途而非写入敏感参数。至此，订阅与节点层完成，下一步才是决定哪些应用流量进入本地代理。

理解系统代理、全局模式与应用差异

系统代理是大多数桌面应用的第一入口

v2rayN 启动核心后会在本机监听代理端口，开启系统代理则把操作系统代理地址指向这些端口。浏览器、办公软件和部分系统组件会读取这项设置，并把请求交给客户端。系统代理关闭时，核心仍可保持运行，只是遵循系统设置的应用不再自动进入代理。排查“客户端连接正常但浏览器没有变化”时，应同时检查客户端托盘状态和系统网络设置，确认代理地址指向本机且端口与客户端当前配置一致。

全局不是连接强度，而是流量选择策略

全局模式通常表示进入客户端的流量优先走当前代理出口；绕过局域网与大陆等规则模式会依据域名和 IP 数据决定直连或代理；自定义模式则按用户规则匹配。全局模式不会让节点本身变快，也不会修复订阅字段错误，它只是减少分流判断，适合用于对照测试。如果规则模式下某个目标失败，而全局模式下成功，说明节点基本可用，问题更可能位于路由或 DNS；如果两种模式都失败，应回到节点和网络层排查。

不同应用读取代理设置的方式不同

浏览器一般会遵循系统代理，但部分应用内置独立代理选项，部分命令行工具只读取环境变量，还有些程序直接建立网络连接而忽略系统代理。因此不能用一个应用的结果推断整台设备。测试时先选一个已知遵循系统代理的浏览器作为基准，再逐个处理其他应用。命令行程序需要时可临时设置代理环境变量，端口应替换为客户端界面显示的实际值，而不是照抄示例。

# 当前终端会话使用 HTTP 代理
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# 使用 SOCKS5，并让域名通过代理侧解析
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

本地端口冲突要从监听状态确认

如果核心启动时提示地址已被占用，说明另一个进程已经监听相同端口。先退出其他代理客户端，再重新启动；若仍冲突，可在客户端设置中更换本地端口，并同步更新所有手工填写该端口的应用。不要只修改系统代理端口而不修改核心监听端口，两者必须对应。端口号本身不决定速度，随意反复更换没有意义。局域网共享还涉及监听地址与防火墙，应与本机系统代理分开配置。

关闭客户端时要恢复系统状态

正常退出客户端前，先关闭系统代理或确认客户端配置了退出时恢复。若程序被系统强制结束，代理设置可能保留，之后所有遵循系统代理的应用都会尝试访问一个已经停止的本地端口。典型现象是网络本身正常，但浏览器立即提示代理连接失败。处理方法是进入系统网络设置关闭手动代理，然后重新启动客户端检查。把这一步加入日常排错清单，可以快速排除大量“退出后无法上网”的问题。

移动端连接状态要结合应用日志判断

Android 客户端通过系统提供的本地 VPN 接口接管流量，点击连接后应先确认系统授权成功，再查看客户端日志是否完成节点连接。部分应用可能有自己的 DNS、网络加速或私有连接设置，这些设置会改变测试结果。首次配置时保持路由和 DNS 为默认值，只选一个节点验证。基础连接稳定后，再按照实际需求添加分应用策略或自定义路由，避免一开始就把节点、DNS 与应用规则同时改动。

用域名、IP 与规则顺序控制流量去向

路由规则处理的是已经进入客户端的流量

路由不会主动接管应用，它只处理已经通过系统代理、应用代理或 TUN 进入内核的请求。每条规则通常包含匹配条件和出口动作：条件可以是域名、IP、端口、协议或来源，动作通常是代理、直连或阻断。若某个应用完全不经过客户端，再精确的路由规则也不会生效。因此配置分流前，先在日志中确认目标请求已经出现，然后再观察它匹配了哪条规则和哪个出口。

域名规则适合描述服务边界

完整域名匹配只作用于指定主机名，后缀规则则可覆盖一个域名及其子域。使用 domain:example.com 时，应确认当前客户端或内核对该写法的定义；使用 full:api.example.com 可精确到单个主机；geosite: 类规则引用维护好的域名集合，适合覆盖一类服务。规则写得越宽，误匹配范围越大。不要为了修复一个子域访问问题，就直接把整个顶级域及所有子域全部改为同一出口。

IP 规则依赖解析结果与目标地址

IP 规则可匹配单个地址或 CIDR 网段，例如 192.168.0.0/16 表示一段私有网络。局域网地址通常应直连，避免打印机、路由器管理页和文件共享被送入远端出口。域名请求是否能进入 IP 规则，还取决于内核是否取得解析后的目标 IP，以及当前域名策略如何配置。只写 IP 规则却不检查 DNS 流程，可能出现规则看似正确但没有命中的情况。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:intranet.example.com",
          "domain:office.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

规则顺序决定冲突时谁先执行

多数路由实现按顺序查找，命中后不再继续比较。因此具体规则应放在宽泛规则之前。例如，某个办公子域需要直连，而其父域整体走代理，就应先写办公子域直连，再写父域代理。若顺序相反，宽泛规则会提前截获请求。修改规则后不要只看配置是否保存成功，还要重启或重载核心，并通过日志确认新规则已经载入。关于语法和匹配优先级，可继续阅读domain、ip 与 geosite 规则写法。

DNS 与路由需要保持同一目标

分流经常同时涉及域名判断和 IP 判断，因此 DNS 结果会影响后续路由。如果一个域名被解析到与预期不同的地址范围，IP 规则可能把它送往错误出口。排查时记录域名、解析结果、命中规则和最终出口四项，而不是只替换 DNS 服务器。客户端支持多组 DNS 时，可为直连与代理查询设置不同路径，但应先理解每组查询由哪个出口发出。基础配置尚未稳定时，保持默认 DNS 通常比叠加多套规则更容易验证。

用最小测试集验证分流

准备三个固定测试对象：一个局域网地址、一个明确要求直连的域名、一个明确要求代理的域名。每次修改规则后依次测试，并记录命中出口。若局域网失败，先查私有地址规则；若域名出口不符，查规则顺序和域名形式；若日志中没有请求，回到流量入口层。不要用随机网页作为唯一测试对象，因为网页可能同时加载多个域名，主页面成功并不表示所有资源走了同一出口。完成规则模式验证后，再决定是否需要 TUN 扩大接管范围。

在基础代理稳定后启用 TUN 模式

TUN 解决不读取系统代理的应用流量

TUN 模式通过虚拟网络接口接收更多系统流量，再交给内核执行路由与转发。它适合不遵循系统代理的桌面程序、需要统一接管的命令行工具，以及希望减少逐个应用配置代理的场景。TUN 不是节点加速开关，也不会提高协议性能。基础节点连接不稳定时开启 TUN，只会增加虚拟网卡、DNS 和路由表三个新的变量，因此必须先在普通系统代理下确认订阅、节点和规则模式工作正常。

启用前记录当前网络基线

开始前记录当前网络适配器、DNS 获取方式、客户端本地端口和系统代理状态，并关闭其他可能创建虚拟网卡的程序。随后在 v2rayN 中启用 TUN，按系统提示完成必要权限授权，等待核心重新加载。启动后检查日志中是否出现虚拟接口建立、路由写入和 DNS 初始化信息。若客户端只显示开关点亮，但日志提示接口创建失败，应先处理权限或驱动问题，不要继续修改节点参数。

严格路由与自动路由要理解边界

自动路由用于把适合接管的系统流量送入 TUN，严格路由会进一步限制绕过虚拟接口的路径。具体开关名称可能随客户端界面调整，但判断原则一致：先启用最少必要选项，验证浏览器、命令行和目标应用，再根据是否存在漏流量决定是否增加限制。企业网络、虚拟机、容器或多网卡环境中，自动生成的路由可能与既有网段重叠，此时要先核对路由表，而不是直接切换全局代理。

DNS 异常是 TUN 排错的第一重点

TUN 开启后若 IP 地址可访问但域名无法访问，优先检查 DNS。确认客户端 DNS 模块已经启动、查询请求进入预期入口，并查看是否存在本地安全软件拦截。若只有部分域名失败，记录其解析结果和命中规则；若所有域名都失败，检查 DNS 监听端口、系统 DNS 指向与端口冲突。不要同时启用多套 DNS 接管功能，否则查询可能在系统、客户端和其他网络程序之间循环。

局域网与多网卡环境要保留直连路径

启用 TUN 后，打印机、网络存储、路由器管理页等私有地址仍应通过本地网卡直连。确认路由中包含私有地址范围，并检查当前局域网是否使用了不常见的自定义网段。设备同时连接有线、无线和虚拟网卡时，还要确认默认路由实际从哪张网卡发出。若切换网络后出现异常，可先关闭 TUN，等待虚拟接口和路由撤销，再重新连接网络并启动客户端。

判断是否真的需要长期启用

若日常使用的应用都能稳定读取系统代理，就没有必要为了设置更复杂而长期启用 TUN。需要覆盖特定不遵循代理的应用时，TUN 才有明确价值。稳定运行的标准包括：重启后能自动恢复、网络切换后路由能重建、局域网访问正常、DNS 没有持续错误、关闭客户端后系统网络能还原。达到这些条件后再把 TUN 加入开机流程，否则应保留系统代理作为更简单的日常方案。

建立更新、备份、测速与分层排错流程

把维护拆成固定周期和事件触发

固定周期维护用于检查客户端更新、订阅状态、自定义规则与旧配置；事件触发维护则在节点整体失效、网络环境变化或系统升级后执行。无需每天清空配置或重装客户端。正常情况下，先更新订阅并检查节点变化，再进行少量可重复的连接测试。客户端升级前记录当前设置，升级后先验证核心启动、系统代理和一个常用节点，确认无误后再恢复 TUN 或复杂路由。

备份重点是不可重新生成的内容

订阅节点通常可以重新获取，真正需要备份的是手工节点、自定义路由、DNS 设置、分组方式和局域网共享参数。备份文件应存放在受控目录，因为其中可能含有连接凭据。恢复时不要直接覆盖所有新配置，先确认客户端配置结构兼容，再逐类导入。若只是更换设备，优先重新安装客户端并导入订阅，然后手工恢复规则，这样可以避免把旧系统的路径、端口冲突和网络接口信息一起带入。

速度问题按节点、线路、本地三层检查

第一层更换同一订阅中的少量节点，判断问题是否只集中在单个节点；第二层在不同时间测试同一节点，观察线路拥塞是否具有时段性；第三层检查本地网络、代理模式、DNS、TUN 和安全软件。测试过程中保持目标网站、文件和设备一致，不要一边换节点一边切换无线网络。若所有节点都慢，优先查看本地网络和订阅整体状态；若只有一个节点慢，则无需重装客户端。详细流程可参考V2Ray 速度慢分层排查。

日志采集要覆盖问题发生时刻

排错日志至少应包含启动核心、复现问题和停止测试三个阶段。只截取最后一行错误，常会漏掉前面的配置加载失败。复现前先清理过多的旧日志或记下当前时间，然后执行单一动作，例如更新一次订阅、连接一个节点或访问一个固定域名。分享日志前应移除服务器地址、用户标识和订阅内容等敏感信息，但保留错误类型、时间顺序和组件名称。这样既能说明问题，也不会暴露连接参数。

常见现象对应的第一检查点

客户端打不开，先查安装包架构、运行环境和配置目录；订阅更新失败，先查链接获取与解析日志；节点全部超时，先查本地网络和订阅状态；浏览器提示代理连接失败，先查核心监听与系统代理端口；只有某个域名异常，先查 DNS 结果与路由命中；开启 TUN 后全局断网，先关闭 TUN 并检查虚拟接口和默认路由。更多按现象组织的答案可在疑难解答中查找。

局域网共享需要单独维护边界

允许局域网连接后，本地代理端口不再只服务当前设备。应确认监听地址、系统防火墙、路由器网络隔离和设备端代理地址，并仅在可信局域网内使用。电脑 IP 变化后，手机或电视中填写的代理地址也要同步更新。共享异常时，先从另一台设备测试电脑局域网地址是否可达，再检查端口放行，最后检查客户端是否允许外部连接。完整操作见v2rayN 局域网共享步骤。

维护目标是保留一个已知可用基线

每次大改前保留一个能正常工作的节点、默认路由和系统代理组合。改动后若无法在短时间内定位，就恢复基线，再逐项重做。不要把订阅、DNS、路由、TUN 和本地端口一次全部替换，因为即使最终恢复连接，也无法知道真正起作用的是哪项。可重复的维护流程比频繁重装更可靠，也能让后续进阶配置建立在明确状态上。

从稳定基线进入自定义规则与多设备管理

进阶的起点是能解释当前配置

完成基础使用后，不必立刻导入大型规则集。先确认能够回答五个问题：当前节点使用什么协议和传输方式，应用流量如何进入客户端，DNS 查询走哪条路径，目标请求匹配哪条路由，最终使用哪个出口。只要其中一项无法确定，继续增加规则都会扩大不确定性。进阶配置的目标不是让设置数量增加，而是让不同流量按清晰、可验证的条件进入预期出口。

先建立命名和分组规范

订阅名称、节点备注、出站标签和规则名称应保持一致语义。例如按“来源—地区—用途”命名节点分组，按 proxy、direct、block 表示出口用途，自定义规则则写明目标和动作。命名规范能直接改善日志可读性，也能减少迁移时的判断成本。不要在名称中加入完整凭据或订阅地址。多个设备共享规则时，保留一份不含设备路径和本地端口的通用版本，再由各设备补充本地差异。

自定义规则要有测试、发布与回退过程

新增规则前先写出预期，例如“办公子域直连，其他同域服务按默认策略处理”。随后添加最小规则，在日志中验证命中，再扩大域名或网段范围。规则发布到日常配置前，至少测试局域网、直连目标、代理目标和 DNS。若修改涉及规则顺序，保留旧顺序副本。出现异常时按最近一次变更回退，而不是继续叠加补丁。长期维护时，应删除已经失效或被更宽规则覆盖的条目。

{
  "rules": [
    {
      "name": "private-network-direct",
      "match": [
        "geoip:private"
      ],
      "action": "direct"
    },
    {
      "name": "office-domain-direct",
      "match": [
        "full:portal.example.com",
        "domain:corp.example.com"
      ],
      "action": "direct"
    }
  ]
}

上面的片段用于表达规则设计方法，不是可直接覆盖客户端配置的完整文件。实际字段应以当前内核的路由结构和客户端导出格式为准。导入前先确认标签名称与现有出站一致，否则规则即使匹配，也可能找不到对应出口。

多设备管理应区分共享配置与设备差异

Windows、macOS、Linux 和 Android 可以使用同一订阅来源，但系统代理、TUN 权限、安装包架构和局域网接口属于设备差异，不应强行复制。共享部分包括订阅分组、核心路由意图和测试目标；设备部分包括本地端口、开机启动、系统权限和应用接管方式。迁移时先恢复共享部分，再按设备逐项设置。这样能保持逻辑一致，又不会把某个平台的网络接口配置带到另一个平台。

高级 DNS 配置必须围绕可观察结果

只有在默认 DNS 明确造成解析失败、出口不符或特定域名污染时，才需要拆分查询路径。设计前先记录目标域名由哪组 DNS 解析、查询通过哪个出口、结果用于哪条路由。增加缓存、备用查询或按域名分流后，应分别验证首次查询和缓存命中结果。若配置后出现间歇性失败，优先简化为单一路径，再逐项恢复。DNS 设置不能替代域名路由，也不能修复不可达节点。

把学习路线固定为三个循环

第一个循环是连接：理解协议字段，确认单节点稳定；第二个循环是接管：掌握系统代理、应用代理和 TUN 的边界；第三个循环是分流：理解域名、IP、DNS 与规则顺序。每个循环都按“建立基线—增加一项—验证结果—记录回退”执行。遇到新问题时先判断它属于哪个循环，再回到对应章节，不必从头重装。快速操作可回到使用指南，客户端包与平台要求在下载中心核对，具体异常则通过疑难解答按现象查找。

最终配置应当简单到可以复现

一套成熟配置不一定规则最多，而是换一台设备后仍能按记录重建。保留订阅来源说明、客户端选择理由、代理入口、路由目标、TUN 使用条件和维护周期六项文档。删除无法说明用途的开关与规则，定期核对订阅和自定义配置是否仍然匹配。至此，从核心概念到进阶管理形成了完整闭环：先让连接成立，再让流量进入，随后控制去向，最后通过日志、备份和基线保证配置可以长期维护。