v2rayN 完整手册
配置与维护

核心概念：理解连接链路

区分客户端、内核与远端服务

先把连接拆成四段：应用发出请求，本机代理入口接收请求，内核按配置处理并转发，远端服务连接目标网站。v2rayN 是管理配置和运行状态的图形客户端，不等于远端服务，也不会在安装后自动获得可用连接。客户端负责订阅分组、服务器选择、系统代理和内核启动；实际处理协议、传输和路由的是内核。理解这层关系，才能分清“软件能打开”和“连接能建立”是两件事。

Project V 是相关代理技术的生态背景，V2Fly 与 Xray 是不同的内核项目。它们共享部分概念，但功能、配置字段和支持范围并不始终一致。遇到一个分享链接能够导入却不能运行，先检查当前内核是否支持该组合，而不是只看客户端名称。图形界面显示了某个选项，也不代表任意内核都能执行。切换内核后，应重新检查生成配置和启动日志，确认设置确实被采用。

区分协议、传输与安全层

VMess、VLESS、Trojan 描述的是不同的代理协议；TCP、WebSocket、gRPC 等描述承载数据的传输方式；TLS 与 REALITY 涉及连接的安全机制。三者不是一个层级，不能互相替代。例如，选中 VLESS 后仍需填写正确的传输与安全参数。REALITY 也不是单独选择后就能连接的通用开关，它需要服务端配套的公钥、服务器名称及其他参数。应以服务提供方交付的完整配置为准。

节点通常指一份能够建立远端连接的配置记录，里面可能包含地址、端口、用户标识、密码和传输参数。订阅地址则是用于获取一组配置的入口，更新后可能增删或修改其中的记录。订阅正常下载，只能证明获取配置这一步成功，不能证明每份配置都能使用；反过来，已有配置可以连接，也不代表订阅更新一定可达。把获取配置和建立代理连接分开测试，排错路径会更清楚。

区分本地端口与远端端口

本地监听端口供浏览器、终端等程序连接客户端，远端端口属于服务器侧服务，两者没有必须相同的关系。常见本地 SOCKS 端口是 10808，但实际值应查看当前客户端参数设置。127.0.0.1 表示本机回环地址，不是服务器地址。把远端地址填进浏览器的本地代理配置，或者把本地端口误填进服务器记录，都可能产生看似相同的超时结果。

DNS 负责把域名转换为地址，路由负责决定请求走直连、代理还是阻断。系统代理只影响愿意读取这项设置的应用，TUN 则从虚拟网络接口接入更多流量。因此，“开启系统代理”并不等于所有程序都已接入；“选择全局路由”也不等于系统层面接管了全部连接。后续每次调整，都先回答两个问题：请求有没有进入客户端，进入后又匹配了哪条规则。

开始配置前，准备操作系统类型、处理器架构、可用订阅或完整分享配置，并确认系统时间自动同步。订阅地址和分享链接可能携带访问凭据，适合存放在私人密码管理工具中，不适合贴进公开讨论区。需要请求帮助时，只描述协议、传输方式和错误阶段，隐藏地址中的凭据字段。这个习惯应从首次导入开始建立，而不是等到配置泄露后再补救。

选择客户端：平台与内核

桌面端优先选择 v2rayN

Windows、macOS 和 Linux 桌面端以 v2rayN 为主要入口。选择安装包时，先判断操作系统，再判断处理器架构，最后考虑界面类型和包格式。不要依据文件体积或名称长短判断新旧，也不要把适用于另一种系统的包反复解压尝试。进入下载中心后，按平台查看对应说明；如果系统报告格式不支持，优先返回检查平台与架构，而不是立即关闭系统保护。

Windows 提供桌面版与经典 WPF 版入口。桌面版采用跨平台界面，WPF 版沿用经典界面体系；两者的菜单布局和设置存储方式可能不同。首次使用可从桌面版开始，已有经典界面操作习惯的用户可按环境选择 WPF 版。不要为了排查一个配置问题而频繁在两种界面之间切换，否则既改变了界面位置，也可能改变工作目录和运行前提，反而增加判断难度。

根据设备信息选择安装包

macOS 用户可在“关于本机”查看芯片信息，显示 Apple 芯片时选择 Apple Silicon 对应入口，显示 Intel 处理器时选择 Intel 对应入口。不要仅凭电脑外观或购买年份推断。Linux 用户先确认发行版使用的软件包体系，再选择 deb 或 rpm；同一种包格式仍可能区分桌面常见的 x64 和其他设备使用的 arm64。包格式与架构是两个条件，必须同时满足。

Android 端首选 v2rayNG，它使用 Xray 内核；v2flyNG 使用 V2Fly 内核，适合作为明确需要该内核时的备选。多数较新的手机可以选择 arm64，但设备年份只是参考，部分设备的系统环境与芯片能力并不完全一致。无法确认时可查看系统信息，或选择通用版。两款客户端不是只换了名称的相同应用，支持的字段和菜单细节要分别确认，尤其不要假定某项新安全机制在两者中都可用。

按配置需求判断，不按协议名称排名

选择客户端还要看手上的配置需要什么功能。如果服务配置使用特定传输或安全字段，应先确认客户端携带的内核支持，再考虑界面习惯。没有必要为了“协议越新越好”而手工改写已经可用的配置。协议、传输、证书和网络环境共同影响结果，换一个名称不能自动改善连接。对于订阅用户，保留提供方给出的字段通常比自行猜测参数可靠，确有兼容问题时再记录报错并核对支持范围。

配置迁移也要区分分享格式和客户端设置。单条分享链接一般只带远端连接所需字段，不一定包含路由、DNS、本地端口和界面偏好。即使两个客户端能够识别同一链接，也不能据此认定整套环境已复制完成。迁移后至少复查本地监听地址、系统代理状态、当前活动记录和默认路由。若只想换设备，不妨先在新设备建立最小连接，确认成功后再逐项搬迁自定义规则。

同一台设备初期只运行一个接管网络的客户端。多个程序可以争用本地端口、系统代理或虚拟接口，造成界面显示正常但请求走向不明。切换测试前，先关闭原程序的代理接管，再退出原程序，最后启动新客户端。保留一份能正常使用的配置作为参照，比同时安装多个客户端并轮流点开更有助于定位问题。客户端下载和配置来源也应分开管理，避免把安装成功误认为已经拥有服务配置。

安装与首次启动

准备可写目录与运行环境

安装之前，先退出正在运行的旧客户端，记录当前本地端口和系统代理状态。使用安装程序时按系统向导完成，使用压缩包时先完整解压，再从解压目录启动，不要直接在压缩软件的临时预览中运行。客户端需要读取内核文件并保存配置，把目录放在只读位置、临时目录或受严格限制的共享目录，容易出现设置不能保存、组件找不到等问题。桌面快捷方式只是入口，不代表实际工作文件都在桌面。

Windows 启动失败时，先看系统弹窗是否明确提示缺少运行环境。不同分发包可能已经包含所需组件，也可能需要相应的桌面运行库，应依据安装说明判断，不要把所有运行库重复安装一遍。经典 WPF 界面与跨平台界面的运行要求也应分别看待。若出现权限错误，检查目录是否可写、文件是否被安全软件隔离，并核对提示来源；不应把长期以管理员身份运行当成通用修复办法。

按平台处理首次打开

macOS 安装后将应用放入合适的应用目录，再从该位置启动。系统阻止打开时，先核对下载来源与提示内容，再按系统提供的授权流程处理，不要为了让一个程序启动而关闭整套安全机制。若提示架构不兼容，返回设备信息检查芯片类型。更新前退出应用，避免在旧进程仍运行时替换文件，否则界面和实际运行组件可能来自不同的安装状态，给后续判断带来混淆。

Linux 使用与发行版匹配的软件包安装方式，完成后从应用菜单或已安装的入口启动。遇到依赖或图形界面错误，先区分是包管理器安装失败，还是安装完成后启动失败；前者检查包格式和依赖提示，后者检查图形环境、权限和启动输出。不要把为其他发行版准备的指令直接复制到当前系统。涉及系统网络接管的权限留到启用对应功能时再授予，普通配置管理阶段不必提前扩大权限。

Android 安装后先打开应用查看基本界面，暂时不用急着连接。系统请求允许安装应用时，仅为当前可信的安装来源完成必要授权，安装结束后可收回该来源的安装权限。首次启动代理连接时出现的 VPN 授权是另一项权限，用于建立本地接管接口，与安装权限不同。若设备已有其他 VPN 正在运行，先结束原连接；反复确认授权并不能解决两个接管服务互相冲突的问题。

检查内核与本地监听

首次打开后，进入参数设置查看本地监听地址与端口，再查看日志区域是否出现内核文件缺失、配置解析失败或端口占用。尚未导入远端配置时，部分功能不能完成连接测试，这是正常前提不足，不应被误判为安装损坏。若安装目录中组件被隔离，先核对安全软件的处理记录；确认问题原因后再按可信分发说明修复，不要从不明位置随意下载一个同名内核文件塞回目录。

默认优先把代理入口限制在本机回环地址。开放到所有网络接口，意味着同一网络中的其他设备可能访问该入口，还需要防火墙和访问控制配合。学习阶段没有跨设备使用需求，就不启用允许局域网连接。若端口被占用，可以关闭占用它的旧客户端，或在确认用途后更换监听端口；更换后同步修改应用侧代理地址，否则客户端已经换了入口，浏览器仍可能连接旧端口而持续报错。

最后建立一个初始记录：安装位置、客户端类型、监听端口、是否开机启动，以及当前是否启用了系统代理。记录不需要包含任何凭据，只需足够帮助之后还原环境。暂时不要同时设置自动启动、自动订阅更新和 TUN；先让手动启动的最小配置工作，再增加自动化。这样即使后续故障发生，也能知道是安装基础有问题，还是新增设置改变了网络路径。

订阅导入：分组与更新

先识别地址类型

导入之前，先辨认拿到的是订阅地址、单条分享链接，还是完整配置文件。订阅地址通常是一个用于获取配置集合的网络地址；分享链接常以协议名称开头，描述一份远端配置；二维码只是承载文本的方式，里面既可能是分享链接，也可能是订阅地址。把所有内容都粘贴到订阅栏，或者把订阅网页的登录地址当成订阅地址，都会产生格式错误。先确认内容用途，再选择入口。

在 v2rayN 中打开订阅分组设置，新增一个便于辨认用途的分组名称，把完整订阅地址粘贴到地址字段并保存。注意去掉复制时带入的前后空格和换行，但不要擅自删除地址中的查询参数；这些参数可能承担身份识别作用。分组名称只是本地管理标签，不会改变远端配置，也不代表已经完成更新。保存分组后，还需要执行更新操作，客户端才会实际获取服务器记录。

选择正确的更新路径

首次配置且代理尚未可用时，可先尝试“更新当前订阅（不通过代理）”这一类入口，避免让订阅请求依赖尚未建立的连接。若订阅来源明确要求经代理访问，则需要先有一份已验证可用的配置，再使用通过代理的更新方式。两种路径并无固定优劣，关键是当前网络能否到达订阅服务。更新失败时先读取错误，区分地址解析失败、连接超时、认证失败和返回内容不能解析。

更新后检查列表中是否出现当前分组的记录，并确认没有被界面的搜索条件或分组筛选隐藏。若列表仍为空，先查看更新日志，再核对地址是否返回订阅内容。有些地址在浏览器中打开会显示登录页、订阅过期说明或其他网页，这种响应即使成功下载，也不能成为有效配置。不要在公开转换网站上传带凭据的订阅内容，格式不明时优先向提供方确认支持的客户端和导出方式。

分别处理剪贴板、二维码与编码内容

v2rayNG 可从操作菜单导入剪贴板中的分享内容，也可扫描二维码。扫码前确认图像来源，导入后核对协议与安全字段是否完整。若拿到的是订阅地址，应进入订阅分组设置保存并更新，而不是只导入为一条服务器记录。相机权限只在扫码需要时授予；已有纯文本内容时，剪贴板入口通常更直接。导入后选择活动配置，再授予连接所需的 VPN 权限，不能只停留在记录已出现这一步。

部分订阅使用 Base64 编码包裹多条分享链接，编码并不等于加密，也不意味着可以公开展示。客户端通常会在订阅更新时处理支持的格式，不需要先手工解码。若响应其实是一份其他结构的配置，单纯转成 Base64 也不会自动兼容。进一步了解各入口的差异，可阅读订阅分组、剪贴板与二维码导入步骤，按内容类型逐项核对。

避免更新覆盖手工修改

订阅记录可能在下次更新时被重新生成，因此不要把必须长期保留的自定义修改只存在订阅条目里。需要调整某份配置时，先确认客户端是否支持复制为独立记录，或在单独分组中管理；同时记下修改目的和原字段。若订阅频繁更新，不宜依靠显示名称判断是否同一配置，应综合检查协议、地址和关键参数。名称改变不一定意味着服务改变，名称没变也不保证内部字段保持不动。

自动更新应在手动更新稳定后再启用，并选择适合实际使用习惯的间隔。更新失败时保留已有可用配置，不要立刻删除整个分组重建。若远端已撤销授权或服务到期，反复更换本地更新模式也不会恢复访问，应检查订阅状态。迁移设备时，优先迁移分组与必要设置，再手动更新确认；直接复制一份来源不清的旧列表，可能把已经失效的配置一并带到新环境。

系统代理：接入与验证

先启动内核，再让应用接入

订阅导入完成后，先选中一份要使用的配置并设为活动记录，再确认内核已启动。接着选择自动配置系统代理，让读取系统代理设置的应用把请求送到本地入口。菜单里的“清除系统代理”一般用于移除系统层面的代理指向，并不必然停止内核；“不改变系统代理”则通常表示保留系统当前状态，也不等于关闭代理。具体作用应结合当前客户端说明判断，不能只凭名称中的“代理”二字推断。

Windows 和 macOS 中，许多浏览器会读取系统代理，但浏览器扩展、自定义启动参数或企业策略可能覆盖它。Linux 桌面环境与应用对系统代理的读取方式更不统一，必要时需要在应用里显式填写本地入口。终端程序则经常不读取桌面代理设置。因此，浏览器已经能访问某个目标，不能证明命令行程序也走同一路径；终端不通，也不能立刻推断系统代理失效。

把接入模式与路由模式分开

系统代理解决“请求怎样进入客户端”，路由解决“进入以后往哪里走”。常见的全局代理路由，是让已接入内核的请求优先走代理出口，而不是强制接管设备里的全部程序。直连路由也可能仍然经过本地内核，只是在出口选择直连。PAC 则由规则脚本决定应用是否使用代理，它的规则发生在接入阶段，不应与内核内部的分流混为一谈。排错时一次只保留一种清晰的接入方式。

Android 中，v2rayNG 通常通过本地 VPN 接口接入应用流量，还可能提供按应用代理等设置。勾选或排除应用的含义要看当前模式：名单有时表示只有这些应用进入代理，有时表示这些应用被排除。不要仅凭列表里出现应用名称就判断它已接入。先用一个没有额外代理设置的普通应用验证，再扩展到其他程序；需要测试浏览器时，暂时关闭其代理扩展，减少重叠配置。

按层验证，不只看一个网页

第一步确认内核日志没有启动错误；第二步确认本地端口确实监听；第三步让一个明确支持代理的程序发起请求；第四步再测试系统代理是否被目标应用采用。可以使用下面的命令显式指定 SOCKS 入口，端口应替换为参数设置中的实际值。这里的 socks5h 表示由代理侧处理目标域名解析，适合区分本机解析与代理链路问题，但它不能证明系统代理设置本身正确。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/

如果命令返回任何合理的 HTTP 响应，说明这一次请求至少完成了相应的连接过程；目标网站可能返回重定向或拒绝访问，并非只有成功状态才具有诊断价值。如果立即提示连接本地端口失败，先检查内核和监听地址；如果已经连接本地入口，随后出现握手错误，再检查远端配置和时间。单个测试目标可能自身不可用，必要时用另一个已知正常的目标交叉判断，不把网站故障误认为整个代理链路故障。

明确退出与回退顺序

关闭客户端之前，先清除系统代理或恢复原来的系统设置，再退出程序。否则系统可能继续指向已经停止监听的本地端口，表现为浏览器整体无法访问。系统休眠、异常退出或强制结束进程后也要检查这一项。若原系统代理来自单位网络或其他管理程序，先记录原值，不要不加区分地删除。恢复连通性比继续叠加新设置更重要，必要时退回直连环境，再逐层重建最小链路。

显式代理命令可用而浏览器不可用时，重点检查浏览器扩展、独立代理设置和旧连接缓存；浏览器可用而终端不可用时，检查终端环境变量与程序自身的代理参数。两者分别排查，不必立即重装客户端。可继续阅读系统代理不生效的浏览器与终端排查。验证期间保留测试目标、使用入口和错误阶段记录，避免只留下“能用”或“不能用”的模糊结论。

路由分流：规则与 DNS

先确定默认出口与规则顺序

路由分流是在请求进入内核后，根据域名、地址、端口、协议或其他条件选择出口。开始设置前，先明确未匹配请求会走哪个出口，再添加少量必要规则。常见目标是让局域网地址直连、指定域名代理、其他请求按默认策略处理。规则并不是越多越精确；重复规则、过宽条件和不明来源的集合会让结果难以解释。每增加一条规则，都应能说明它匹配什么请求，以及为什么放在当前位置。

许多内核按规则顺序查找，先匹配的规则优先决定出口，因此应把明确、范围较小的例外放在较宽规则之前。比如某个域名需要代理，而一个更宽的域名集合被设为直连，就要检查两者先后关系。内网地址直连可以避免访问本地路由器、打印机或文件服务时绕到远端，但它不等于所有内部名称都已正确解析。名称解析与地址路由需要分别确认，不能只加一条规则就假定两层同时解决。

阅读规则片段，避免整段覆盖

下面是 Xray 路由对象的结构示例：先让私有地址直连，再让示例域名及其子域走代理。它不是完整配置，direct 与 proxy 必须对应当前配置里真实存在的出站标签，geoip:private 也依赖相应地址数据可用。图形客户端通常会生成完整配置，不要把这个片段直接覆盖到整个配置文件。使用界面规则编辑器时，应把相同意图转换成对应的规则条目。

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

这个示例中的地址规则只会在具备可匹配地址条件时发挥作用。若请求只携带域名，而当前域名策略不为匹配主动解析，就不能把它理解为“所有解析到私有地址的域名都会被这条规则拦住”。同样，域名规则需要内核得到域名信息；应用如果只提交地址，内核可能没有原始名称。嗅探可以在部分流量中补充名称信息，但并非任何加密流量都能识别，不能把它当成保证命中的万能功能。

把 DNS 看成独立路径

配置 DNS 时，分别问清应用在哪里解析、客户端使用哪个解析器、解析请求本身走哪条出口。应用自己使用加密 DNS 时，可能绕过系统解析器；显式 SOCKS 请求也可能选择在本机或代理侧解析。内核中的 DNS 设置并不必然接管系统里所有程序的查询。若域名打不开而直接地址可以访问，先检查解析结果和查询路径，不要立刻换远端端口。不同路径得到不同地址，也可能改变后续路由匹配。

避免解析器与代理连接形成循环依赖。例如，连接远端服务需要先解析它的域名，而解析请求又被要求通过尚未建立的同一连接发送，就可能卡在起点。需要为引导解析保留可用路径，并核对服务器域名的解析方式。修改解析策略后，应用、系统和内核可能各自保留缓存；应在记录原配置后分别清理或重启相关部分，再测试新连接，避免旧缓存让新规则看起来没有效果。

逐条验收分流结果

测试规则时，选一个明确的目标，记录应用是否携带域名、规则条件和最终出口。若日志支持显示匹配信息，可短暂提高日志级别观察，测试完成后恢复。不要用访问成功作为唯一证据，因为直连和代理都可能访问成功。反之，代理出口被目标服务限制也不等于规则没命中。先证明流量进入内核，再证明规则选中了预期出口，最后才检查目标响应，这个顺序能把分流问题与服务问题分开。

TUN 模式：接管与回退

确认确实需要更广的接入范围

TUN 通过虚拟网络接口接收系统流量，再交给相应处理组件完成转发。它适合不读取系统代理设置、又没有独立代理入口的应用，但不是解决所有超时的快捷开关。若显式本地代理测试都无法连接远端，开启 TUN 通常只会把同样的错误扩大到更多应用。先在普通代理模式下验证远端配置、DNS 和路由，再进入本章，确保新增问题可以归因到接管层，而不是混在既有故障里。

不同平台、客户端构建和所选组件可能提供不同的 TUN 实现，菜单名称、网络栈选项和权限需求不一定相同。不要根据一张界面截图寻找完全相同的开关，更不要假设选择某个代理内核后就自动具备所有接管功能。先看当前界面的功能说明、启动日志和所需组件提示。Android 的本地 VPN 接口与桌面端的 TUN 设置在使用体验上相似，但权限模型和可选参数并不能直接照搬。

记录网络基线，再逐项启用

开启前记录当前活动网卡、系统 DNS、是否存在其他 VPN，以及客户端当前使用的接入模式。先退出会修改路由的其他程序，暂时停止重复接管，再启用 TUN 并按系统提示授予必要权限。不要把“运行失败”一律归因于权限不足；日志里的接口创建失败、路由添加失败、端口占用和配置不支持是不同问题。只有错误明确指向权限时，才按当前平台要求调整授权范围。

先保留默认网络栈和基础参数，不同时修改最大传输单元、严格路由、DNS 劫持等高级选项。验证顺序可以从普通网页开始，再到原先不读取系统代理的目标应用，最后测试局域网设备与休眠恢复。若网页可用但某类实时应用失败，先检查远端协议与出口是否支持相应流量，再看 UDP 路径和应用限制。TUN 能接收到数据，并不保证远端服务愿意或能够转发每一种传输。

检查循环、DNS 与局域网访问

接管全部路由时，需要确保客户端自身连接远端服务的流量不会再次被送回同一虚拟接口，否则可能形成循环。正常实现通常会处理相关绕行，但自定义路由、多个接管程序或手工网卡设置可能破坏它。出现内核启动正常、启用接管后立即失去连接的情况，应先关闭 TUN 验证基础代理是否恢复，再看远端连接是否被错误捕获。不要直接删除系统路由表中的所有条目。

DNS 接管与 FakeDNS 也应分别理解。DNS 接管把查询导向指定处理路径，FakeDNS 则返回虚拟地址并维护域名映射；二者可以配合，但不是同一开关。开启虚拟映射后，一些应用如果绕过了对应处理链路，可能拿到不能直接访问的虚拟地址。企业内网名称、局域网发现和自带解析功能的应用尤其需要单独验证。没有清晰需求时先保持普通解析，避免为了追求更多功能牺牲可解释性。

把退出测试作为启用的一部分

启用成功后，还要测试关闭功能、退出客户端、切换网络和系统休眠恢复。关闭后确认虚拟接口相关路由与解析设置已恢复，普通网络可正常使用。若退出后仍断网，先检查系统是否保留了本地代理指向，再检查活动接口和解析器。保存故障现场的基本信息后，可通过系统正常的网络重连流程恢复；不要在不了解用途时批量删除网卡或清空防火墙配置。

只有接管、分流、局域网和退出恢复都验证通过，才考虑开机自动启动。自动化还要兼顾网络尚未就绪、系统权限尚未授予等情况，不能只测试已登录桌面后的手动启动。配置出问题时，最可靠的退路应是关闭 TUN、恢复原系统代理与 DNS，再用已验证的普通代理配置继续排查。进阶功能的价值在于满足明确需求，不在于让所有开关都处于开启状态。

日常维护：备份与排错

保存可恢复的配置状态

日常维护从备份开始，而不是从更新开始。优先使用客户端提供的导出或备份功能，区分服务器记录、订阅分组、路由规则、DNS 和界面偏好是否都被包含。若要复制配置目录，应先退出客户端，避免复制到尚未写完的数据；具体目录以当前安装方式为准，不要假定所有平台都存放在相同位置。备份后保留简短说明，记录它对应的平台、界面类型和当时可用的功能范围。

备份里可能含有订阅凭据、服务器密码和私人域名，应存放在受访问控制的本地或可信加密存储中。用于求助的配置与用于恢复的完整备份要分开，前者应删除敏感内容，后者应保留恢复所需字段。不要只备份一张界面截图，因为截图通常无法还原隐藏字段和规则顺序。更新之前至少保留一份已知可用的设置，并确认能够找到恢复入口，而不是等更新失败后才寻找旧数据。

分开更新客户端、内核与规则数据

客户端更新改变图形界面和管理逻辑，内核更新改变协议处理能力，路由数据更新改变集合匹配范围，三者不应被当作同一件事。一次只更新一类组件，完成后测试启动、订阅更新、普通连接和退出恢复，再进行下一项。若原本稳定的连接突然失败，先回想最近改变的是哪一层。记录设置变更比频繁重装更有帮助，重装可能保留旧配置，也可能丢失现场，未必能解释问题。

版本变化可能使某些字段废弃或调整默认行为，因此更新后先观察日志是否提示配置不兼容。自定义完整配置尤其需要谨慎：它可能绕过界面生成逻辑，不能指望新增界面选项自动写进自定义文件。若必须回退，使用与旧配置兼容的恢复方式，并避免让不同程序同时写同一个数据目录。配置数据库经过迁移后也未必支持直接交给旧程序读取，备份应保留在变更之前。

按错误发生阶段读取日志

排错时先记下错误发生在哪个动作之后：程序打不开、内核启动失败、订阅下载失败，还是应用请求失败。程序启动问题检查运行环境与目录权限；内核启动问题检查字段、组件和端口；订阅问题检查地址与获取路径；请求问题再检查解析、远端握手和路由。把错误原文保留下来比只说“连接失败”有效。日志可能包含地址与用户信息，发送之前先检查并遮盖，不直接上传整个工作目录。

节点超时可从系统时间、本地监听、网络可达性和传输参数逐层检查。系统时间偏差可能影响证书与握手，端口占用可能让应用根本连不到预期进程，服务器端口不可达则发生在另一层。TLS 相关错误再核对服务器名称、证书状态和安全参数，不用关闭验证作为长期方案。详细顺序见系统时间、端口与 TLS 握手排查，每次修改后重新发起一条请求。

保持测试条件一致

比较修改前后结果时，尽量使用相同应用、相同目标与相同网络入口。切换配置后，旧连接可能仍复用已有会话，必要时关闭测试应用或清理连接，再建立新请求。系统休眠、从有线切换到无线、进入需要网页登录的网络，都可能改变网络前提。若当前网络本身尚未完成登录，先在恢复原代理设置后完成正常接入，再启用客户端，避免把网络认证页面当成订阅响应或目标响应。

平时保留默认或适量日志，只有复现问题时再临时提高详细程度。过多日志既可能增长占用，也会暴露更多访问元数据；问题解决后恢复原级别，并按需要清理旧记录。定期确认订阅仍有效、备份可读取、系统代理能够正常退出即可，不需要每日改动工作稳定的设置。维护的目标是减少未知变化，让下一次出现问题时有清晰的比较基线和可执行的回退路径。

进阶路线：从验证到定制

先掌握字段之间的约束

完成前面各章后，进阶不再是寻找更多开关，而是理解设置之间的约束关系。可以先从一份已知可用的配置出发，分别观察协议、传输、安全和路由字段如何出现在内核配置中。只阅读自己能解释的部分，不急于改动用户标识、密码、公钥等由远端服务决定的内容。学习配置语法与修改实际凭据是两回事，前者可以使用脱敏片段练习，后者必须有配套服务信息。

学习协议时，优先回答它需要什么认证字段、如何承载数据、与哪些安全机制配合，以及当前内核是否支持。不要用名称新旧替代兼容性判断。比如，REALITY 配置中的服务器名称、公钥和短标识需要与服务端要求一致，客户端本地随机生成一组字段不会使已有服务自动接受。某些字段允许多个值，也不意味着任意组合都正确，应逐项核对提供方说明，并保留原始可用配置用于比较。

建立能回答具体问题的小实验

每次实验先写下假设，例如“这个终端没有读取系统代理”，再设计只改变一个条件的测试：先直连请求，再显式指定本地入口，最后才测试环境变量。若显式入口有效而默认请求失败，就优先检查应用接入，不必同时更换路由和 DNS。实验结果应包括请求入口、错误阶段与预期出口，而不是只记录一个网页是否打开。这样积累下来的记录，比复制一份复杂配置更能形成可迁移的判断能力。

路由实验可以先只针对一个示例域名建立规则，验证命中与出口，再逐步扩展到域名集合和地址集合。DNS 实验则比较应用本地解析与代理侧解析，注意缓存造成的干扰。TUN 实验应增加局域网、网络切换和退出恢复检查。每类实验都单独保留回退点，避免上一项尚未理解就开始下一项。若结果与假设不一致，先保留现象并缩小变量，不用继续堆叠补丁让表面访问恢复。

正确理解配置语法与生成逻辑

JSON 示例中的双引号、逗号和括号属于语法，字符串里的字段名称则属于具体组件的配置约定。标准 JSON 不接受注释和末尾多余逗号，网上能阅读的带注释片段未必能直接交给内核。配置能够解析只代表语法成立，不代表字段组合符合语义，更不代表远端服务可用。遇到错误时先区分语法错误、未知字段、出口标签缺失和连接错误，再决定应修改哪个部分。

图形客户端通常会根据界面设置生成运行配置，直接编辑生成文件可能在下次启动或切换记录时被覆盖。需要长期定制时，先确认客户端提供的规则、自定义片段或完整配置入口分别作用于哪个阶段。优先使用最小必要的定制方式，不把整个生成配置复制为长期维护文件。完整自定义配置意味着需要自行承担字段兼容、出口引用和后续更新适配，只有清楚这些职责后再使用，才能避免设置出现两份来源。

把安全边界纳入配置设计

代理链路保护的是特定路径上的传输，不应把它理解为所有访问行为都自动匿名。目标网站的账号登录、浏览器存储、应用遥测和远端服务的运行记录仍有各自边界。订阅与分享链接本身也是敏感入口，应定期清理不再使用的副本，在怀疑泄露时按服务方支持的方式更换授权。开放局域网监听或远程管理之前，先明确谁能访问、如何限制，以及关闭后如何确认入口已经停止。

不建议为了绕过一个证书报错而长期关闭安全验证，也不建议从来历不明的整包配置中继承无法解释的解析器、规则和管理接口。能够连接只是最低验收条件，可维护配置还应满足来源清晰、行为可解释、权限适当、退出能恢复。对于工作设备或受管理网络，先遵循设备与网络管理要求；涉及全局路由、系统服务和防火墙的修改，尤其要保留原状态并确认授权范围。

最终可以用一条完整描述检查自己的理解：某个应用经哪个入口接入，本地由哪个组件处理，域名在哪里解析，哪条规则决定出口，远端需要什么参数，以及失败后怎样恢复。能够逐项回答，再去学习复杂分流、虚拟地址映射或更细的应用接管，才有稳固基础。始终保留一份简单、可验证、能回退的配置，让进阶设置成为可选择的工具，而不是必须依赖的黑箱。