新手到进阶 · 系统查阅手册

V2Ray 配置手册
从订阅导入到路由与 TUN

按九个阶段建立配置思路。安卓以 v2rayNG 为主，桌面首推 v2rayN，需要 v2fly 内核时再了解 v2flyNG。

只想完成首次连接，先看使用文档中的快速上手主线。本页用于系统查阅：说明每项设置影响哪一层、怎样验证修改，以及失败后从哪里恢复。首次使用可从第一章顺读；已有配置时，可直接跳到对应章节。不同客户端与构建的菜单名称可能略有差别，应以当前界面和日志为准。

第一阶段：理解客户端、内核与连接路径

先区分界面与执行配置的内核

打开客户端时看到的是图形界面。界面负责保存服务器条目、更新订阅、生成配置和启动服务；真正处理连接的是内核。v2rayNG 主要使用 Xray 内核，v2flyNG 使用 v2fly 内核。v2rayN 是桌面客户端，具体使用哪个内核取决于所选配置与客户端提供的支持。界面能保存一个字段，不等于当前内核一定能执行它。

Project V 是理解这套代理生态的背景，V2Fly 与 Xray 属于相关的内核家族，而不是三个可以互换的应用名称。查资料时先确认文章讲的是客户端菜单还是内核字段。遇到不认识的名称，可到名词解释查阅。不要仅因为都带有 V2Ray 字样，就把另一内核的完整配置直接覆盖到当前客户端。

沿着入口、规则、出口理解请求

一次请求通常先由应用发起，再进入本地代理入口，随后按路由规则选择出口，最后连接目标服务。桌面系统代理只是让部分应用把请求交给本地入口；Android VPN 服务则通过系统提供的虚拟网络接口接收流量。入口负责接收请求，出口负责决定怎样发送，请求经过哪个入口与最终走哪个出口是两个问题。

服务器条目描述远端连接方式，常见字段有地址、端口、用户标识、协议、传输方式和安全参数。订阅则是批量获取这些条目的地址，不是连接本身。更新订阅成功只说明取回并解析了配置，不能证明远端服务可连接。反过来，已有条目可用时，订阅更新失败也不一定立刻影响正在使用的连接。

协议、传输与安全层分别核对

VMess、VLESS、Trojan 和 Shadowsocks 是不同的代理协议。WebSocket、gRPC 等描述传输方式，TLS 与 REALITY 涉及连接安全机制。这些字段必须按照服务端提供的组合填写，不能把协议名相同当成全部参数相同。例如地址和端口正确，但传输路径、服务名或服务器名称错误，仍可能在建立连接时失败。

VLESS 通常需要配合适当的安全层使用；不要把协议自身较精简理解为所有连接都自带加密。VMess 的时间相关验证也要求设备时间合理。REALITY 有对应的公钥、短标识和服务器名称等要求，并不是打开普通 TLS 开关就能替代。协议差异可继续阅读VMess 与 VLESS 协议速览。

完成本阶段后，应能解释当前应用使用哪款客户端、哪类内核、哪个入口和哪个出口。此时还不需要编写完整配置。先建立一条参数来源明确的连接，再逐步加入路由与接管范围；一次开启所有高级功能，会使失败原因同时落在多个层面，后续很难判断哪次修改真正有效。

第二阶段：按平台与配置需求选择客户端

桌面选 v2rayN，安卓先选 v2rayNG

进入客户端下载页，先按设备系统选择平台，再判断处理器架构。Windows、macOS 与 Linux 桌面端首推 v2rayN，Android 首选 v2rayNG。这样选择主要是为了让教程路径与实际界面对应，不代表同一份订阅在所有环境中都具备相同能力。所需协议、传输方式和系统接管方式仍要分别确认。

安卓需要 v2fly 内核相关配置时，可把 v2flyNG 作为备选。不要仅因为一次连接失败就立即更换客户端；先确认失败来自内核支持、订阅解析，还是网络与权限。两款安卓客户端之间迁移时，应保留原来的应用和配置作为回退路径，完成新环境验证后再决定是否清理，避免同时丢失可用配置。

安装格式与处理器架构分开判断

Windows 下载页提供 v2rayN 桌面版与经典 WPF 版。桌面版采用新一代跨平台界面，WPF 版保留经典界面路径。两者菜单组织与部分系统集成方式可能不同，跟随教程时先确认使用的是哪一类界面。不要把新版界面中找不到同名按钮，直接判定为功能缺失；可先在参数设置与服务菜单中寻找对应项目。

macOS 先在系统信息中确认芯片，Apple Silicon 选择 arm64，Intel 选择 x64。Linux 除了架构还要看发行版包管理体系，deb 与 rpm 不能只凭文件大小选择。Android 主流较新手机通常使用 arm64，但处理器具备该能力不一定代表系统运行相同位宽；遇到安装不兼容，再结合系统信息判断是否使用通用包。

平台客户端选择先确认的项目
Windowsv2rayN桌面版或 WPF 版、系统支持条件
macOSv2rayNApple Silicon 或 Intel
Androidv2rayNG；v2flyNG 备选系统架构、内核兼容性
Linuxv2rayNdeb 或 rpm、x64 或 arm64

以实际功能需求判断兼容性

如果服务端提供 VLESS 与 REALITY 组合，重点核对当前客户端所调用内核是否支持相关字段，以及导入后字段是否完整。若使用传统配置，也不要自行添加新安全参数。配置的可移植性来自双方对同一组字段的支持，而不是应用名称相近。对照时应记录协议、传输、安全层与特殊选项，不只记录一个协议名称。

还要考虑设备的日常使用方式。只让少量桌面应用走代理，可先使用系统代理或应用自身代理；需要接收更多不读取系统代理的流量时，再评估 TUN。安卓则应检查是否长期运行其他 VPN 类工具，因为系统通常只允许一个活动 VPN 服务。需求不同，合适的接管范围也不同，不必把功能开得最多作为选型标准。

最后把选择结果写成一句可验证的描述，例如“安卓使用 v2rayNG，通过 VPN 服务接收选定应用流量”。这样后续安装、授权和排错都有明确边界。需要比较三款客户端的定位时，可查看客户端横向评测；本手册继续沿着同一条配置主线推进，不把更换客户端当作默认的修复操作。

第三阶段：安装客户端并建立权限基线

Android 安装与首次启动

在下载页选好架构后，使用系统安装器打开安装文件。如果系统提示当前来源不能安装应用，进入提示对应的“安装未知应用”页面，仅对实际使用的浏览器或文件管理器临时授权。安装完成后可关闭该来源权限。不要为了通过安装提示而修改与安装无关的设备安全设置，也不要在来源和用途不清楚时持续授予权限。

打开 v2rayNG 后，先确认主界面能正常显示，再检查通知权限。常驻通知有助于识别服务状态，但通知权限与 VPN 授权不是同一项。首次启动代理服务时，系统会单独显示 VPN 连接确认窗口，确认应用名称后再允许。如果之前使用其他 VPN 服务，应先停止它，避免把新服务无法接管误判为配置参数错误。

桌面端先确认文件与系统集成

Windows 按所选安装格式完成安装或解压，保留应用所需的配套文件，不要只把主程序单独拖到另一个目录。优先以普通用户权限打开界面；只有启用确实要求管理员权限的功能时，再按客户端提示授权。安装位置应允许当前用户保存设置，尤其注意受保护目录、同步目录和只读介质可能造成的保存失败。

macOS 安装后从应用程序目录启动，遇到系统安全提示时先确认文件来源和当前系统的允许方式，不要一概关闭系统保护。Linux 通过与发行版匹配的包管理方式安装，再从应用菜单启动。若界面打不开，记录错误提示及系统架构；此时尚未进入远端连接阶段，修改订阅、协议或 DNS 通常不能解决界面启动问题。

先保存环境，再尝试首次连接

进入客户端设置，记录当前本地监听端口、运行模式和路由预设。记录时以界面实际显示为准，不假定每个版本都使用同一组端口。如果设备上已有其他代理软件，应先退出其系统代理与虚拟网卡接管，再启动新客户端。只关闭旧窗口可能仍留有后台服务，造成端口占用或流量进入错误的程序。

接着检查系统时间、时区及网络是否正常。开启自动时间同步，并确认普通网络能完成必要的基础访问。时间错误可能导致证书有效期判断失败，联网认证页面也可能拦住后续请求。如果当前网络需要先完成网页认证，先停止接管并完成认证，再回到客户端操作；不要用关闭证书验证来掩盖这些环境问题。

安装阶段的验收不是网页能否打开，而是界面可启动、设置能保存、服务能够请求正确权限、退出后系统网络可以恢复。四项都完成后再导入订阅。若出现本地端口占用，可参考本地监听端口冲突排查。先处理设备环境，能避免把本地启动失败和远端连接失败混在同一轮排错中。

此外，给新配置保留一个恢复点：记下原有系统代理是否开启、原来的 VPN 是否自动运行。共享或受管理的设备还可能有组织设置的网络策略，普通用户不应擅自移除。恢复基线时应停止新服务，再还原原来的网络方式，而不是连续安装多个客户端尝试相互覆盖。

第四阶段：导入订阅并管理配置来源

在订阅分组中保存地址，再执行更新

打开 v2rayNG 的侧边菜单，进入“订阅分组设置”，新增分组，填写便于辨认的备注和完整订阅地址。保存后回到主界面的订阅菜单，执行更新订阅。不同界面可能把更新入口放在更多菜单中，操作目的相同：先保存来源，再取回内容。仅把地址存入分组而没有执行更新，主列表不会自动出现服务器条目。

复制地址时检查开头、结尾和中间是否混入空格或换行。订阅地址有时携带可识别账户的访问参数，应视为敏感信息；截图、日志和求助文本中都不要公开。不要把订阅地址直接发给陌生的在线转换工具。确实需要转换格式时，先确认工具来源及数据处理方式，并了解转换结果可能丢失哪些协议字段。

分清订阅、分享链接与完整配置

订阅通常提供一组条目，单个分享链接只描述一个配置，而完整内核配置还可能包含入口、出口、路由和 DNS。三者不是同一种导入对象。使用剪贴板导入时，先看复制内容的类型，再选择相应入口。把网页地址当作订阅、把完整配置当作单节点链接，都可能导致解析失败或列表为空。

在 v2rayN 中打开订阅分组相关设置，新增来源并保存，再通过订阅更新菜单取回条目。首次更新先使用普通更新方式；若提供通过当前代理更新的选项，只有在现有代理已经可用时才适合使用。否则会形成循环依赖：必须先连上代理才能更新，却又依赖更新后的配置才能连上代理。

更新完成后打开一个条目的编辑界面，按服务端资料核对地址、端口、协议、用户标识、传输与安全字段。列表备注只是标签，不能作为参数正确性的依据。若服务端使用特定路径、服务名或服务器名称，逐项核对大小写及完整内容。不要在缺少资料时凭其他条目的样子补填，更不要随机切换安全层试错。

更新前备份，更新后检查差异

订阅条目可能在下次更新时被覆盖，因此不适合长期直接修改其中的关键参数。需要试验时，先导出或复制为独立条目，并用备注区分来源。保留一份已验证可用的配置，再更新原分组。这样遇到删除条目、参数变化或来源暂时不可访问时，仍能判断问题发生在内容更新还是连接环境。

更新失败时先看错误属于哪一类：名称解析失败、连接超时、远端返回错误，还是内容无法解析。地址过期、权限变化和返回登录网页，都会导致更新失败，但处理方式不同。先在不泄露地址的前提下检查来源状态，再决定是否更换更新路径；不要反复清空全部配置，因为清空不会修复远端返回内容。

完成本阶段后，应至少保留一个来源明确、字段完整的条目，并知道该条目是否会被订阅覆盖。暂时不要同时导入多个不明来源分组。来源越多，重复条目、不同参数与过期配置越容易混杂；先让单一配置通过验证，再扩展分组，日常维护也会更容易追溯。

第五阶段：选择入口与代理模式并验证连接

系统代理与路由预设不是同一个开关

在 v2rayN 中，先选择已导入的条目作为活动配置，再启动服务，随后按需求设置系统代理。系统代理告诉遵循该设置的应用去哪里发送请求；路由预设决定请求进入内核后走哪个出口。因此，界面里选择全局路由，不代表所有应用都会自动进入客户端。不读取系统代理的程序仍可能直接使用原来的网络。

桌面首次验证可从浏览器开始。先确认客户端内核启动成功，再让浏览器使用系统代理，访问一个已知可用的测试目标。若浏览器能访问而其他应用不能，先检查其他应用是否读取系统设置、是否配置了自己的代理，而不是立即更换服务器。入口没有接到流量时，修改远端协议通常没有作用。

安卓先明确 VPN 与仅代理模式

v2rayNG 的 VPN 模式通过 Android VPN 服务接收流量，系统会显示对应的 VPN 状态。仅代理模式通常只提供本地代理入口，需要应用自行配置使用它，不能期待所有应用自动接管。初次使用优先按教程选择 VPN 模式并完成系统授权，再检查分应用设置是否把目标应用排除在接收范围外。

分应用代理还要区分允许列表与绕行模式。开启绕行时，选中的应用可能是不经过该 VPN 的应用；未开启绕行时，选中的应用可能才是需要接管的应用。以当前界面说明为准，不凭勾选状态猜测含义。修改列表后，按客户端要求重新启动服务，并完全退出再打开测试应用，避免旧连接沿用之前的路径。

用分层测试代替单一延迟判断

连接测试可能只测到远端端口或某个特定请求，不代表所有目标、协议和解析过程都正常。验证时至少观察三件事：内核是否保持运行、测试应用是否产生新请求、请求是否按预期完成。先只测试一个应用与一个目标，成功后再扩大范围。网页打不开时还要排除目标自身故障和浏览器缓存影响。

如果所有应用都失败，先查看日志中的启动与握手信息；如果只有个别目标失败，再检查路由、DNS 和目标限制。若只有 UDP 相关应用异常，则要确认客户端入口、内核、远端及网络路径是否都支持所需流量。TCP 网页请求成功不能自动证明其他流量正常，也不能证明接管范围覆盖了设备上的所有进程。

方式接收流量的前提验证重点
桌面系统代理应用遵循系统代理设置本地端口与应用自身设置
应用手动代理应用填写正确入口协议类型、地址与端口
Android VPN系统授权且应用在接管范围活动 VPN 与分应用规则
桌面 TUN虚拟接口与系统路由正常权限、DNS 与绕行路径

测试结束后还应验证退出行为。先停止服务，再确认系统代理是否恢复到预期状态；若系统仍指向已经停止的本地端口，遵循系统代理的应用会失去连接。不要把这种退出后的失败认作远端不可用。掌握启动与停止两条路径，才算完成基本配置；接下来再引入路由，才能清楚区分接管问题与分流问题。

第六阶段：建立可解释的路由与 DNS 规则

先确定规则顺序与出口名称

进入客户端的路由设置，先查看当前预设，再决定是否添加自定义规则。规则通常按顺序匹配，较早命中的规则会决定出口，后面的规则不再接管该请求。因此，精确的域名例外应放在宽泛规则之前。先写下哪些请求需要直连、哪些需要代理、哪些应阻止，再把需求翻译为规则，避免只复制一整组不理解的配置。

出口标签是配置内部引用，不是协议名称。下面片段用于说明规则结构，必须合并到已有配置中；其中引用的 direct 与 proxy 要与当前配置真实存在的出口标签一致。不要把片段当成完整配置直接启动。若客户端用图形规则编辑器生成配置，优先在界面中创建同等规则，减少下一次保存时被重新生成覆盖的风险。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

域名策略决定何时为匹配而解析

AsIs 尽量按收到的域名进行匹配，不主动为了 IP 规则把域名转为地址。IPIfNonMatch 在域名规则未匹配时尝试解析，再参与 IP 规则匹配。IPOnDemand 会在匹配需要地址信息的规则时触发解析。实际可用字段应以所用内核为准，不要把路由中的域名策略与出口连接时的地址选择参数混为一谈。

若入口收到的只有 IP，单靠域名规则未必能完成预期匹配。流量嗅探可以在部分协议中尝试识别目标名称，但不能保证恢复所有请求的域名，也不应作为 DNS 配置错误的补救。启用前确认支持范围与隐私影响，修改后从日志观察实际匹配情况。域名、地址和入口提供的信息共同决定规则能否生效。

把 DNS 查询路径与业务请求分开验证

打开 DNS 相关设置时，先确认谁在解析：应用、系统、客户端内置解析器，还是远端。设置一个 DNS 服务器地址，并不自动意味着查询一定沿代理发送。解析器本身的访问路径、路由规则以及安全 DNS 连接的域名解析，都可能影响结果。尤其不要让解析服务器依赖尚未建立的连接，形成启动时无法解析的循环。

本地网络中的打印机、管理页面和内部域名，可能需要本地解析与直连；远端解析器未必知道这些名称。先验证局域网地址可访问，再单独测试内部域名。如果地址可用而名称不可用，优先检查解析而不是改代理协议。反过来，名称能得到结果但连接超时，则应继续检查返回地址、出口路径和目标服务状态。

每次只添加一条规则，并测试一个应命中的目标和一个不应命中的目标。验证后记下规则位置、出口与解析方式，再继续增加例外。完整规则集的价值在于可以解释每个请求为何走某条路径，而不是条目越多越好；遇到问题先回退到已验证的预设，再逐条恢复新增规则。

第七阶段：扩展到 VPN 与 TUN 接管

先确定是否确实需要更广的接管范围

只有当应用不读取系统代理，或需要接收更多类型的流量时，再考虑桌面 TUN。TUN 通过虚拟网络接口与系统路由把流量交给代理处理，不会修复错误的服务器字段，也不保证远端支持所有协议。启用前，先在较简单的系统代理路径下验证同一条配置可用，否则新增虚拟接口会让排错范围进一步扩大。

Android VPN 模式与桌面 TUN 在概念上都涉及虚拟网络接口，但系统权限、路由实现和菜单设置并不相同。不要在安卓上照搬桌面的驱动安装步骤，也不要把安卓 VPN 授权当作桌面管理员权限。桌面实际支持的 TUN 行为还取决于所选内核和客户端提供的实现，应按当前界面的提示逐项设置。

启用前处理冲突与恢复路径

在 v2rayN 中找到 TUN 相关设置或开关，先阅读权限提示，确认是否需要服务模式或系统授权。停止其他虚拟网卡接管工具，并记录原来的系统代理状态。初次测试不要让多个接管方式同时改变默认路由；即使它们可以共存，也应先分别验证。受组织管理的电脑应遵循设备策略，不自行移除现有网络组件。

启动后先检查虚拟接口是否建立、内核是否继续运行，再测试普通网页、局域网设备和实际业务应用。远端服务器自身的连接必须能够绕开接管环路，否则可能出现请求不断被送回入口的情况。客户端通常会提供相应处理，但自定义路由、静态路由或其他网络软件仍可能覆盖它，出现异常时应先回到默认设置。

重点验证 DNS、UDP 与断线行为

TUN 能接收到流量，并不代表 DNS 一定进入预期解析器。应用可能使用自身的安全 DNS，系统可能保留已有缓存，客户端也可能提供不同的 DNS 接管方案。先选择一套明确的解析路径，避免在尚未理解设置时同时开启多个重定向功能。局域网名称失效时，要检查本地解析是否被不必要地送到远端。

UDP 是否可用取决于入口、内核、远端以及网络路径的共同支持。测试时使用确实需要该流量的应用，并查看对应日志；不要用一次网页访问推断所有传输都正常。出现部分应用异常时，还要区分应用自身限制与传输问题。修改虚拟接口相关参数前保留原值，不要把不同设备的参数组合成未经验证的设置。

网络从无线切到移动网络，或电脑休眠后恢复，可能改变默认路由与解析环境。遇到切换后失效，先停止再启动客户端服务，让它重新建立接口；随后确认系统没有残留旧的代理设置。若只有重新启动设备才能恢复，应进一步记录切换前后的错误，不要把反复重启当成长期维护方案。

本阶段的最终验收包括主动停止服务。确认退出 TUN 后系统路由、DNS 与普通网络能恢复，再重新启动并重复测试。若局域网或基础联网受影响，先关闭 TUN、恢复系统代理与原网络方式，再逐项定位。始终保留一个已验证的简单入口作为对照，可以快速判断问题是否仅出在接管层，而不必重新导入全部订阅。

第八阶段：备份、更新与日常故障定位

把可用配置与试验配置分开保存

在客户端的导出或备份入口保存当前设置，确认导出的内容包含哪些范围。有的导出只含服务器条目，不包含订阅来源、分应用名单或路由预设，因此还需要记录这些设置。备份文件可能包含访问凭据，应存放在受控位置，不要随意同步到公开目录。恢复后也要重新检查系统权限，而不是假定所有设备状态都能随配置迁移。

给独立测试条目写清用途，例如用于验证传输参数或路由例外，不要只用相似的默认备注。日常更新订阅时观察条目是否被替换，更新客户端时先保存可用配置与当前设置。不要在同一次维护里同时更新应用、切换内核、重写路由和更换 DNS；变化越集中，出问题后越难确定应该回退哪一层。

先看启动日志，再看连接日志

服务无法启动时打开日志，从最早的明确错误向后看。配置解析错误、缺失字段、出口标签不存在、资源文件缺失以及端口占用，都可能在建立远端连接前发生。先解决第一条阻断启动的错误，再重新测试。后续连续出现的失败有时只是同一原因的连锁结果，不需要对每一行分别修改一个参数。

如果内核已经正常启动，再区分连接超时、名称解析失败、认证失败和 TLS 握手错误。连接超时不一定是协议问题，也可能是地址、端口或当前网络路径不可达；认证失败则应核对服务端提供的用户字段。遇到配置相关报错，可按内核启动失败日志检查中的顺序，先验证语法和字段，再检查入口与出口引用。

按现象收集最少且足够的信息

求助前记录系统、客户端名称、运行模式、发生动作和错误原文，并说明问题是持续出现还是只在网络切换后出现。日志只截取对应时间段，隐藏订阅地址、用户标识、密码及其他访问参数。不要直接公开整个配置文件。保留关键错误类型和相邻上下文，通常比一张只有“失败”字样的截图更有助于定位。

证书报错时先检查系统时间与时区，再核对服务器名称及服务端证书配置。不要把允许不安全连接当作默认修复，它可能只是跳过了本应处理的问题。若服务端更换证书或名称，应根据服务端资料更新字段。具体排查可继续阅读TLS 握手与证书错误原因，不要通过随机更换安全参数碰运气。

维护还包括应用后台行为。Android 若出现锁屏后服务停止，先检查系统电池限制、后台运行与自动启动设置；这些入口因设备而异，按系统说明调整，不要一次性放开所有应用权限。桌面若在休眠恢复后失效，则检查内核与虚拟接口是否仍正常。根据故障发生的时机选择排查层，比盲目增加权限更有效。

最后为每次维护留下简短记录：改了什么、验证了什么、怎样恢复。记录不需要包含敏感参数，只需保留设置名称与结果。下一次出现相似现象时，先对照最近的变化与环境，再决定是否更新或切换配置。稳定使用依靠可复现的操作与可恢复的设置，而不是持续堆叠未经验证的优化项。

第九阶段：从图形设置过渡到配置阅读

先读生成结果，再尝试局部修改

在客户端提供的配置查看或导出入口中，找到当前活动配置，先只读不改。按入口、出口、路由和 DNS 四个部分标记用途，找出图形界面中的每个设置最终落在哪一段。生成结果可能包含客户端自动补充的字段，不要因为教程没有解释就删除。掌握界面到配置的对应关系，比直接从空文件编写完整配置更稳妥。

阅读时特别留意标签引用、数组顺序和嵌套层级。路由引用的出口标签必须存在；同名字段出现在不同对象中，含义可能不同。JSON 的双引号、逗号与括号也都是语法的一部分。某些工具接受注释，不代表客户端所用的解析器也接受；保存前应按当前内核支持的格式检查，不将配置片段与其他格式混写。

用小型练习建立参数判断能力

第一次练习可只调整日志级别，用较少的改动观察输出差异。下面是常见的日志配置片段，需要放入完整配置对应位置，不是可独立启动的文件。排错时临时使用更详细的输出，完成后恢复日常级别。日志越详细，越可能包含目标地址和连接上下文，因此分享日志前仍需检查内容。

{
  "log": {
    "loglevel": "warning"
  }
}

第二次练习只新增一条明确的域名路由，并保留默认出口不变。准备一个应命中的测试目标和一个对照目标，从日志或客户端提供的连接信息中确认路径。若没有足够信息证明规则生效，就不要仅凭网页打开推断成功，因为两个不同出口都可能访问同一个目标。实验的关键是验证假设，而不只是得到可用结果。

第三次练习梳理 DNS 依赖：谁查询名称、向哪里查询、查询本身怎样发送、返回地址最终由哪个出口使用。把这些关系写成几行文字，再对照实际配置。能够解释完整链条后，才考虑更细的域名分类、地址族选择和局域网例外。不要为了增加复杂度而拆分解析路径，复杂设置应对应明确且能验证的需求。

理解客户端生成与自定义配置的边界

有些客户端会在保存设置、切换条目或更新订阅后重新生成运行配置。直接修改临时生成文件，可能在下一次启动时消失。需要长期保留的设置，应优先通过图形界面保存；使用自定义配置前，确认客户端如何启动、更新和备份它。不要同时维护两套互相覆盖的来源，否则界面显示与实际运行内容可能出现偏差。

切换内核也应作为独立实验处理。先检查目标内核支持的协议、安全字段和路由语法，再复制配置测试，不覆盖原来的可用路径。相同字段名称不保证边界行为完全相同。出现兼容性问题时，保留原始错误与最小复现配置，只保留必要结构并替换敏感值；不要为了复现问题公开真实订阅与访问凭据。

接下来的学习按问题选择入口：需要重复首次连接流程，回到快速上手文档；遇到明确错误，查常见问题与对应技术笔记；不熟悉字段，查名词解释。不必一次掌握全部参数。先把当前设备的实际需求实现并验证，再逐层扩展，才能让配置长期保持可读、可维护和可恢复。