v2rayN 配置与维护手册

核心概念：区分客户端、内核与配置

先画出一次请求的路径

理解连接过程，先把它拆成几段：应用发出请求，流量进入本地代理入口，内核读取规则并选择出站，远端服务再访问目标。客户端负责提供图形界面、保存订阅与生成运行配置；内核负责实际处理连接。窗口能打开，只能说明界面程序已经启动，不能说明内核已正常运行，更不能说明远端服务可用。遇到问题时，沿着这条路径逐段检查，比同时改动多个开关更容易找到原因。

把配置分成两类。第一类描述远端连接，包括服务器地址、端口、认证信息、传输方式与安全设置；第二类描述本机行为，包括监听地址、系统代理、路由与域名解析。订阅通常主要提供第一类内容，本机设置则由客户端管理。更新订阅后节点发生变化，不代表系统代理或路由已经同步调整。反过来，本机代理入口正常，也不能修复失效的远端认证信息。

再认识内核家族与协议字段

Project V 是相关代理技术的生态背景，V2Fly 与 Xray 属于不同的内核发展路线。v2rayN 是桌面图形客户端，具体可用功能取决于所选内核及客户端的支持情况；v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核。不要把客户端名称、内核名称和协议名称混成同一个概念。某个协议字段能否工作，要同时考虑客户端能否表达、内核能否解析，以及远端是否采用相同配置。

VMess、VLESS 与 Trojan 是常见的连接协议名称；传输方式决定连接如何承载；TLS 或 REALITY 等设置涉及连接的安全协商。REALITY 不是独立的订阅格式，也不能靠打开一个开关让任意节点获得对应能力。导入配置后，应保留服务提供方给出的组合，尤其不要凭名称猜测服务器名称、指纹、公钥或传输路径。任意一项不匹配，都可能表现为握手失败，而不是简单的地址不可达。

用可观察的现象划分故障

区分名称解析、建立连接和应用响应三个阶段。域名解析失败时，请求可能还没到远端；连接超时时，要检查本地网络、目标地址与中间路径；握手报错则应查看协议参数和安全设置。客户端的连接测试只能描述测试方式覆盖的那一段，不能替代真实应用验证。某个网页能打开，也只说明该请求在当时成功，不能直接推断其他应用、其他协议或其他路由都已经正确。

建立最小配置基线：保留一个确定有效的配置，先用系统代理验证支持代理的应用，再逐步加入分流与虚拟网卡。每次只改一个变量，并记下修改前后的现象。若同时更换节点、重写解析规则并启用虚拟网卡，即使连接恢复，也无法知道真正有效的是哪一步。后续维护需要可重复的结果，而不是靠反复切换设置碰巧得到一次成功。

选择客户端：按系统、架构与内核需求筛选

桌面优先选择 v2rayN

先打开客户端下载页，按当前操作系统选择入口，再确认处理器架构与安装包类型。桌面端首推 v2rayN，适用于 Windows、macOS 与 Linux。不要只凭文件名里出现相似字样就安装，也不要把运行在某个平台上的经验直接套到另一平台。界面框架、权限机制与发行包形态存在差异，正确选择入口可以减少后续遇到无法启动、架构不兼容或安装方式不匹配的问题。

在 Windows 上，下载页提供桌面版和经典 WPF 版。桌面版采用新一代跨平台界面，WPF 版采用 Windows 桌面界面框架。选择时先考虑操作习惯与当前系统环境，不把“新界面”等同于所有功能都完全一致。菜单位置、设置组织和部分交互可能不同；阅读教程时，应识别同一设置的含义，而不是机械寻找同一像素位置。两种形态的进一步说明见桌面版与 WPF 版区别。

移动设备先确认架构与所需功能

在 Android 上，优先考虑使用 Xray 内核的 v2rayNG。需要 V2Fly 内核并且已经确认配置兼容时，再考虑 v2flyNG。两者都提供订阅与连接管理，但不能认为内核字段可以任意互换。遇到配置导入失败，先核对订阅是否适用于该客户端和内核，再判断是否需要换应用。换客户端不是修复过期订阅、错误密码或不可用远端地址的通用办法。

处理器架构决定安装包能否运行。主流较新 Android 手机通常可选 arm64，但仍以设备和系统支持情况为准；无法确认时，可考虑通用版，接受文件体积上的差异。macOS 在“关于本机”中查看芯片类型，选择 Apple Silicon 或 Intel 对应入口。Linux 除了架构，还要区分发行版的软件包体系：使用相应的 deb 或 rpm 包，不要把包格式选择理解成代理功能上的差别。

把使用场景也纳入选择

选择之后，列出真正需要代理的程序。只有浏览器需要接入时，可以先使用系统代理；需要处理不读取系统代理的程序时，再评估虚拟网卡模式。公司设备、受管理设备或需要同时运行其他网络工具的环境，可能限制驱动、路由或权限变更。应先了解设备管理要求，不把开启更大接管范围当成默认目标。功能越多，涉及的系统层面越多，排错时也需要更多上下文。

最后确认配置迁移范围。节点链接和二维码通常传递远端连接参数，并不保证包含本机路由、解析方案、快捷键或界面偏好。跨平台迁移时，先导入远端配置，再按新设备重新设置本地行为。保留一份选择记录：系统、架构、客户端形态、采用的内核与必要权限。以后重装或更换设备时，依据这份记录重新决策，而不是依赖旧安装包能否再次运行。

安装准备：建立可启动、可退出的运行环境

安装前先处理已有网络设置

下载前，查看系统版本与架构，确认有足够的可用存储空间。若设备已有其他代理配置，先记录系统代理地址、端口及虚拟网卡状态，然后退出相关程序，避免多个工具同时接管网络。不要直接删除仍在使用的配置目录。安装阶段的目标很明确：让客户端和内核能够启动，让日志入口可以打开，并确认退出后系统网络能恢复；此时不需要提前加入复杂分流或自动启动任务。

在 Windows 上，使用下载页提供的对应安装入口，按安装向导完成操作。若选择的发行形态涉及解压运行，应先完整解压到固定目录，不要在压缩包预览中直接启动。固定目录便于更新、定位日志和保存配置。避免把工作目录放在频繁清理的临时位置，也不要在运行过程中手工移动文件。遇到缺少运行环境的提示，按该发行形态的说明补齐依赖，不从不明来源单独搜集缺失组件。

分别处理桌面与移动端权限

在 macOS 上，打开对应芯片的安装包，将应用放到稳定的应用目录后启动。遇到系统安全提示，先核对来源和当前系统的批准路径，再通过系统设置完成允许操作。不要为了运行单个应用而整体关闭系统保护。若客户端能够打开但核心功能失败，应区分应用启动权限、网络权限与后续虚拟网卡权限；它们属于不同层面，不能因为窗口出现就认为全部权限已经满足。

在 Linux 上，用发行版的软件安装器或包管理机制安装对应的软件包。先看依赖提示，再确认桌面环境能启动图形界面。若普通模式能运行、虚拟网卡模式不能运行，应检查权限和服务要求，而不是反复重装同一个包。日志可能由客户端界面、用户目录或系统服务管理机制提供，具体位置以当前安装形态为准。记录实际位置，后续更新与排错都需要回到这里查看原因。

在 Android 上，按系统提示允许当前下载来源安装应用，完成后检查是否需要收回该来源权限。首次建立连接时，系统会请求创建 VPN 连接，阅读提示后按需要批准。这个授权表示应用可以通过系统提供的网络接口接管流量，不等于远端配置已经验证成功。若手机受组织管理，安装来源或 VPN 权限可能被策略限制，应遵循设备管理要求，不通过反复安装绕过限制。

完成一次启动与退出检查

首次启动先找到日志、参数设置与退出入口。桌面窗口关闭后，程序可能继续留在通知区域；要停止运行，应使用明确的退出命令。观察退出前后系统代理是否恢复，以及后台是否仍有连接进程。不要把“关闭窗口”和“结束代理服务”视为同一操作。Android 则需要区分划走界面与停止 VPN 服务，连接状态应以应用和系统的网络提示共同判断。

接着检查本地监听设置。初次配置保留默认端口和仅本机访问范围，暂不开放局域网连接。端口被占用时，先查是否有旧实例或其他程序正在使用，再决定退出冲突程序还是修改端口。修改之后，所有显式填写该端口的应用也要同步调整。只改客户端、不改浏览器或其他应用的代理地址，会形成“内核已经启动，但请求没有进来”的典型故障。

导入订阅：从保存地址到验证有效配置

把订阅地址当作访问凭据保存

订阅地址通常包含可识别账户或访问权限的信息，应按敏感数据处理。不要把完整地址放进公开截图、在线转换页面或公开求助记录。先确认地址来源、适用客户端和有效期，再复制到本机。客户端负责读取地址返回的配置内容，并不自动提供远端服务。只有安装程序、没有有效配置时，节点列表为空属于正常状态，不需要通过修改系统代理来“生成”节点。

在 v2rayN 中，打开“订阅分组”下的“订阅分组设置”，新增一个便于辨认的分组名称，再粘贴订阅地址并保存。名称只用于本地管理，不影响远端连接。保存后返回主界面，执行“更新全部订阅（不通过代理）”或当前界面提供的对应更新操作。这里分成保存与获取两个动作：保存只是记录地址，更新才会下载并解析内容，完成后再检查所属分组中的配置是否出现。

按可用网络选择更新路径

首次配置没有可用代理时，先尝试不通过代理更新。若订阅服务明确需要已有代理路径才能访问，应先建立另一条已验证的连接，再使用通过代理更新的方式。不要反复在同一个失效配置上切换更新路径，并期待它恢复订阅。更新失败时，依次检查本地网络、地址是否完整、账户是否有效，以及服务返回的到底是配置还是登录页面、错误页面或访问限制提示。

在 v2rayNG 中，打开菜单里的“订阅分组设置”，添加名称和地址，保存后返回配置列表，再执行“更新订阅”。界面可能把更新全部与更新当前分组分开，应看清当前选中的分组。v2flyNG 的入口组织可能不同，操作仍遵循添加地址、保存分组、执行更新、检查配置的顺序。若导入后没有内容，不要立即重复添加相同分组，先看更新结果与日志中是否出现格式解析错误。

理解地址、内容与分享链接的区别

订阅地址是获取配置的入口；地址返回的内容可能是编码后的多条链接，也可能是客户端支持的其他订阅结构；单条分享链接则描述一项远端配置。把这三者分开，可以避免把订阅地址当单节点导入，或把单节点链接填进需要定期更新的地址栏。Base64 只是内容编码形式，不代表连接协议，也不表示其中的认证信息已获得加密保护。分享二维码同样可能携带完整连接凭据。

更新成功后，选择一个配置并设为活动项，再查看其协议、地址和安全字段是否完整。不要为了整理列表，随意修改由订阅维护的连接参数，因为下一次更新可能覆盖这些改动。需要保留手工调整时，应复制到单独的本地分组，并注明调整目的。订阅中的配置被删除或替换，也可能是服务端清单发生变化，不应直接归因于客户端丢失数据。

最后用真实请求验证，而不只看列表是否出现。先确认活动配置，再启动内核，开启后文介绍的系统代理，用一个确定受代理设置影响的应用访问已知可用页面。若失败，记录发生在订阅获取、配置解析还是实际连接阶段。多设备共享同一订阅时，还应确认服务允许的连接数量与使用范围；订阅能导入，并不保证同时连接一定被允许。

代理模式：先确认入口，再扩大接管范围

用系统代理完成第一条验证路径

代理模式首先决定应用流量怎样进入内核。桌面系统代理会向系统登记本地代理地址，但只有读取这些设置的程序才会采用它。部分程序使用自己的网络设置，另一些程序可能完全忽略系统代理。因此，开启系统代理后，浏览器可以访问而某个独立应用不能访问，并不必然说明节点异常。先确定应用采用哪种代理入口，再决定是否需要显式填写地址，或者使用虚拟网卡接管。

在 v2rayN 中，先确认活动配置与内核运行状态，再从“系统代理”入口选择“自动配置系统代理”。随后使用会读取系统代理的应用验证请求。不要把“自动配置”理解成自动挑选节点、自动设置所有应用或自动优化路由；它主要完成系统代理登记。配置失败时，查看系统中登记的地址与客户端实际监听地址是否一致，尤其检查之前是否手工改过端口。

区分清除设置与保持现状

“清除系统代理”用于移除由相应操作管理的系统代理设置；“不改变系统代理”则表示客户端不主动调整当前系统状态。后者不是关闭代理的同义词：系统原来登记着什么，可能仍然保持什么。退出前后若网络异常，先查看系统代理是否仍指向已停止监听的本地端口。恢复直连通常需要明确清除或还原该设置，而不是只关闭客户端窗口。

需要给单独应用配置代理时，查看客户端实际提供的入口类型与监听端口，再在应用中选择匹配的 HTTP 或 SOCKS 设置。不要根据其他教程的端口数字直接填写，也不要把远端服务器地址当成本机代理入口。对于域名解析，部分应用会在本地先解析，部分支持把域名交给代理端处理；这会影响后续分流和解析行为，必须结合应用自身的设置判断。

在 Android 上识别 VPN 服务与分应用范围

v2rayNG 通过 Android 的 VPN 接口建立本地接管入口。首次连接需要系统授权，连接后再由客户端的路由和相关设置决定流量去向。系统显示 VPN 标识，只能说明该接口已经建立，不能证明每个目标都经过远端出站。若启用了分应用设置，未被纳入范围的应用可能不会进入该路径。检查时应同时核对应用范围、路由规则和活动配置。

尽量避免多个接管入口同时生效。测试虚拟网卡时，可先清除系统代理，排除同一请求重复经过本地入口的可能；使用应用内代理时，也要记下显式设置，避免以后忘记还原。不要把“全局”一词当作完整诊断信息，它可能指接管全部应用，也可能指路由全部选择代理，二者不是同一个层次。描述问题时，应分别说清入口方式与路由模式。

完成本章后，应能回答三个问题：哪个应用在发请求、请求进入哪个本地入口、内核是否看到了该请求。若日志完全没有相应活动，优先排查入口与应用设置；若已有连接记录，再进入远端与路由排查。按层次收敛范围，可以避免把所有连接问题都归结为订阅或节点，也能为后面的虚拟网卡配置保留一条清晰的对照路径。

路由与 DNS：让匹配条件和解析路径保持一致

从预设规则开始建立分流基线

路由决定进入内核的流量从哪里离开。它与系统代理是两套设置：系统代理决定流量是否进入，路由决定进入后选择直连、代理或其他已定义出站。在 v2rayN 中，可先从“路由设置”里的“绕过大陆”等预设开始，理解预设目标后再使用。规则依赖域名和地址数据，结果可能受更新状态、解析位置与连接目标变化影响，不应把预设名称理解成对所有网站行为的绝对保证。

多数规则系统按顺序匹配，较具体的例外应放在宽泛规则之前。先匹配所有流量的规则若位于前面，后面的域名规则就可能没有机会生效。每加一条规则，都要检查它的条件、目标出站和相对位置，而不是只确认“已启用”。客户端使用的出站标签不一定相同，复制配置片段前应核对实际标签；指向不存在的出站，可能导致加载失败或请求无法按预期处理。

区别域名规则、地址规则与解析策略

域名规则依赖内核能够获得域名信息，地址规则则匹配连接使用的目标地址。如果应用先在本机解析并只提交地址，域名规则的适用条件可能改变。流量嗅探可以在部分场景补充识别信息，但不能保证恢复所有请求的真实域名，更不是替代正确解析配置的万能开关。遇到分流不符，先看日志中内核实际拿到了什么，再判断规则为何未命中。

以下片段展示 Xray 路由字段的匹配关系，适用于理解规则结构，不是可单独运行的完整配置。它把示例域名及其子域交给已有的直连出站；整合时必须先确认完整配置已经定义名为 direct 的出站。示例域名用于说明语法，不承载实际业务。使用图形客户端时，优先在路由编辑器中表达同一规则，避免直接覆盖自动生成的完整文件。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs 表示路由阶段按当前信息匹配，并不表示整个系统从此停止域名解析。需要建立真实连接时，仍可能在相应位置进行解析。其他解析策略也应结合所用内核文档理解，不能仅凭名称推断是否会产生额外查询。域名解析与路由之间存在相互影响，改变其中一项后，应重新观察最终目标地址与出站，而不是只看规则编辑器里显示的文本。

给 DNS 单独建立检查路径

设计解析方案时，先列出谁在查询、查询发到哪里、查询本身走哪条出站。需要直连的域名，通常应采用能返回适合本地路径结果的解析方式；需要经代理访问的域名，则要确认解析路径符合预期。加密解析只改变查询的传输保护方式，不会自动修正错误的出站选择。远程解析服务若依赖代理连接，还应避免用同一路径解析代理服务器本身而形成启动依赖。

浏览器的安全 DNS、操作系统缓存和应用自身缓存都可能改变观察结果。修改规则后，先关闭已有连接，必要时刷新相关缓存，再使用同一目标重新测试。不要因为旧连接继续走原路径就判断新规则无效。若只有一个应用异常，检查它是否绕过了客户端的解析设置。更完整的解析分流说明见DNS 配置详解；排错时始终同时记录解析结果与路由命中情况。

启用 TUN：检查权限、路由与冲突边界

先确认是否需要虚拟网卡

TUN 通过虚拟网络接口接收系统路由导入的流量，可覆盖部分不读取系统代理的程序。它改变的是入口和系统网络路径，不会修复无效的远端配置，也不代表所有流量都会被代理出站处理。进入虚拟网卡后，流量仍需按照路由、协议支持与排除规则运行。只有在系统代理已验证正常、确实存在接管范围不足的需求时，再启用这一层，能够显著减少排错变量。

启用前保存当前配置，确认能找到系统网络设置、客户端日志和关闭开关。桌面平台可能需要管理员授权、辅助服务或相应网络组件，具体要求取决于系统与当前发行形态。遵循客户端提示完成必要操作，不把整个日常运行环境长期提升为最高权限。若设备管理策略禁止虚拟网卡或路由变更，应停留在允许的入口方式，不能靠反复授权解决策略限制。

按固定顺序完成第一次启用

先选择已经通过普通代理验证的活动配置，再退出其他会修改网络路由的工具。暂时清除系统代理，保留一条明确的接管路径，然后在 v2rayN 中找到“启用 Tun”或当前界面的对应开关。按提示授权，观察日志是否成功创建接口并加载路由。若出现权限不足、接口创建失败或地址冲突，先处理明确的启动错误，不要立即修改订阅或切换一批远端配置。

接口建立后，依次检查普通网页、原本不读系统代理的应用、局域网设备和常用工作服务。只测一个外部网页容易忽略本地打印、文件共享或局域网管理页面受影响的情况。遇到本地资源失败，检查私有地址与必要网段是否被正确排除，再确认目标是否确实位于这些网段。不要把所有私有地址都机械排除，某些组织网络的访问方式需要按实际拓扑另行判断。

分别处理回环、解析与多网卡问题

虚拟网卡配置必须避免代理程序自身的远端连接再次被导回入口，否则可能形成循环。客户端通常会处理必要的排除与出站绑定，但在多网卡、共享网络或其他网络工具共存时，仍可能出现选路异常。现象包括启用后全部连接中断、日志重复建立相似连接或内核负载异常。此时先关闭虚拟网卡恢复基线，再逐项检查接口选择与路由，不要继续叠加额外代理层。

解析也是常见故障点。虚拟网卡可能改变系统查询的去向，既有的安全 DNS、组织解析服务或其他 VPN 可能与之冲突。若数字地址可达而域名访问失败，应优先检查解析链路；若只有大文件或部分协议失败，还要结合路径、报文大小和协议支持排查。不要未经验证就调低 MTU 或套用别人的参数，先记录默认值，确保每次调整都能回退并复测同一目标。

多网卡设备要特别关注网络切换。无线网络与有线网络切换、休眠恢复或网络共享，都可能让默认出口发生变化。若只有切换后失败，尝试停止接管再重新建立，并查看路由是否按新接口恢复。Android 的 VPN 接管由系统接口提供，不应照搬桌面的安装驱动或服务操作；其重点通常是系统授权、分应用范围与其他 VPN 的占用情况。

日常维护：更新、备份与逐层排错

让更新保持可回退

日常维护先区分三种更新：客户端程序更新、内核更新和订阅更新。程序更新改变界面与配置管理能力，内核更新可能改变字段支持与连接行为，订阅更新则改变远端清单。不要把三者同时执行后再判断哪里产生问题。较稳妥的顺序是先备份，更新其中一层，使用固定目标验证，再继续下一项。涉及重要工作连接时，预留恢复时间，避免临近使用才改动整套环境。

备份前先明确数据范围。订阅地址可重新取得远端配置，但未必能恢复手工节点、本地规则、解析设置或界面偏好。客户端导出的备份可能包含认证信息，应存放在受保护的位置，不随意发到公开网盘或聊天群。恢复到另一系统时，先看备份格式和导入支持，再检查本机路径、监听端口与权限相关设置，不假设同一份备份在所有平台都具有完全相同的行为。

维护订阅时保护手工配置

更新订阅前，确认地址仍有效，并记下当前活动配置。更新后检查分组内容、活动项和连接参数是否改变。服务端删除的项目可能从列表消失，客户端也可能重新选择活动项；因此更新成功后仍要进行一次真实访问验证。对长期保留的手工配置，使用独立分组并说明来源，避免与订阅托管内容混放后被覆盖。不要通过反复导入来掩盖分组管理上的问题。

多设备使用同一订阅时，把“共享远端清单”和“共享本地设置”分开管理。桌面路由不必与手机完全相同，局域网排除和应用范围更需要按设备重建。订阅、二维码与备份各自适合的场景见多设备配置同步方案。无论采用哪一种方式，迁移完成后都要在接收设备重新验证入口、解析和路由，不能只看导入提示。

按层次整理故障证据

故障发生时，先记录是否所有应用都异常，以及关闭代理后基础网络是否正常。基础网络也失败时，先检查本机连接和上游网络；只有读取系统代理的应用失败时，检查监听入口；内核已收到请求却连接远端失败时，再检查活动配置与握手日志。仅特定域名或应用失败时，应重点检查分流、解析和应用独立设置。按影响范围分类，可以避免一开始就重装全部程序。

查看日志时，保留错误附近的上下文和发生时间，但先移除地址、账户标识、订阅参数及认证字段。日志中的超时可能由不同层面引起，单个词不足以确定原因。将错误与具体动作对应起来，例如“更新订阅时出现”“启动内核时出现”或“打开某应用后出现”。求助时附上系统类型、客户端形态、入口方式和最近一次改动，通常比发送整份配置更有帮助。

最后验证恢复结果。停止虚拟网卡、清除残留系统代理并退出客户端，确认普通网络可用；再按照最小基线逐步启动。若只有休眠恢复或切网后异常，记录这个触发条件，不要把偶发状态当作永久配置错误。必要时参考疑难解答寻找同类现象。排错记录应包含原因、改动和复测结果，保留一次有效记录，往往能减少下一次同类问题的处理时间。

进阶路线：用可验证的实验扩展配置

先完成一份能够解释的基线

进阶不是把所有高级开关都打开，而是能够解释每个请求的入口、解析位置、匹配规则与最终出站。先整理一份可工作的基线：记录系统与客户端、活动配置来源、采用的入口方式、路由预设和解析方案。把必须的功能与可选实验分开。没有这份基线时，即使复杂配置短暂成功，也很难在网络变化或更新后恢复，更无法判断新增设置究竟解决了什么问题。

安排实验时，先提出一个可以验证的问题，例如某个应用是否忽略系统代理、某个域名是否命中预期出站，或切换网络后解析是否仍可用。接着选择一个固定目标，记录修改前现象，再只调整相关参数。测试完成后关闭已有连接并重新发起请求，避免复用连接干扰观察。若无法稳定重复结果，就先缩小实验范围，而不是加入更多规则解释不确定的现象。

按依赖顺序扩展规则与解析

第一条进阶路线是精细路由。先学习域名完整匹配、域名后缀与地址网段的区别，再加入必要的例外，并验证顺序。通配式写法、正则表达式和内核专用规则可能具有不同语义，不能把其他环境的表达式直接粘贴进来。每条自定义规则都应附上目的与测试目标；长期没有用途、无法解释或与前文重复的规则，应清理而不是不断积累。

第二条路线是解析分流。把应用查询、客户端解析、远端解析与系统缓存分别画出来，确认每一步的网络依赖。不要单凭解析服务的名称判断结果质量，应观察它对实际目标返回的地址，以及该地址是否适合最终出站。涉及加密解析时，还要考虑解析服务自身的域名如何取得地址。建立清晰的启动路径，比盲目增加多个备用解析地址更能提升可维护性。

阅读配置时区分完整文件与局部片段

第三条路线是理解生成配置。先通过客户端提供的查看功能阅读实际运行内容，再对照入站、出站、路由和解析各部分的职责。图形客户端可能在启动或保存时重新生成文件，直接编辑生成结果的改动可能不会长期保留。确需使用自定义配置时，先了解当前客户端的加载方式与支持范围，并保存完整基线。局部示例缺少其他部分时，不能当成完整文件直接运行。

协议参数学习应跟随真实需求。遇到包含新字段的配置，先核对所需内核与客户端支持，再理解字段之间的依赖。不要为了尝试某种协议，修改已有服务没有提供的认证或安全参数。传输方式、服务器名称和相关安全字段必须与远端匹配，客户端无法单方面决定。查看术语手册时，把名词解释与自己的配置逐一对应，避免只记名称而忽略实际生效条件。

用验收清单结束每次学习

一次完整的验收应覆盖连接、分流、解析、局域网访问与退出恢复。既要确认需要代理的应用可以工作，也要确认应该直连的资源仍按预期访问；既要检查初次启动，也要检查切网、休眠恢复和重启后的状态。测试目标应来自自己的实际使用场景，而不是追求某个测试结果。不同网络条件下的表现会变化，保留环境信息比记录单个数值更有意义。

完成后，把临时实验整理成简短维护说明：为何添加这项设置、如何确认生效、出现异常时怎样关闭，以及哪些字段需要随服务更新。快速复现日常连接时回到使用指南；需要替换客户端时回到下载页核对平台；出现具体错误时转到对应章节和疑难解答。保留清楚的边界和回退路径，才能让配置随着需求增加而仍然容易理解、验证与维护。