V2Ray 从零到精通
客户端配置完整手册

阶段一 · 建立概念

核心概念：连接经过哪些环节

V2Ray 常被用来统称一组代理技术，但实际使用时需要区分图形客户端、代理内核、连接配置和远端服务。图形客户端负责导入订阅、保存设置与启动内核；内核负责接收连接、判断路由并执行出站。界面显示已经启动，只能说明本地进程进入运行状态，不能单独证明远端可达，也不能证明浏览器已经把请求交给它。

客户端、内核与服务端

Project V 是理解这套生态的起点，V2Fly 延续了 V2Ray 的相关开发，Xray 则形成了另一条内核实现路线。它们共享部分概念，但功能支持和配置字段并非完全相同。v2rayN 是桌面图形入口，v2rayNG 与 v2flyNG 是安卓图形入口。选择哪一个界面，不等于任意协议都能使用；最终仍要看随客户端运行的内核及其实际支持范围。

可以把一次访问拆成应用、入口、路由、出口四层。应用先决定是否使用代理；入口可能是本地 HTTP 或 SOCKS 监听，也可能是虚拟网络接口；路由根据域名、地址等条件选择出口；出口再使用连接配置联系服务端。任何一层配置不匹配，都会表现为访问异常，因此排查时应沿这条链路逐段确认，而不是只反复更换节点。

协议、传输与安全设置

VMess、VLESS 等名称描述代理协议，TCP、WebSocket、gRPC 等描述承载连接的方式，TLS、REALITY 等涉及连接安全机制。它们不是可以随意互换的同一类选项。导入后应保留提供方给出的组合；仅把传输改成另一种方式，或者凭名称添加安全选项，通常不能改善连接，反而会造成客户端与服务端握手条件不一致。

同一配置中的服务器地址、连接端口、用户标识、服务器名称和传输路径分别承担不同作用。服务器名称可能参与安全握手，不一定与地址栏中的主机名相同；路径通常属于特定传输方式，也不能填入地址字段。阅读参数时先判断它属于哪一层，再决定到哪个设置页核对。字段不明确时，应向配置提供方确认，而不是用搜索到的示例覆盖。

订阅与本地设置的边界

订阅是批量获取连接资料的入口，并不是一个正在工作的连接。更新订阅后，客户端通常还需要选中具体配置，并启动服务或设置系统代理。订阅能够打开，只说明订阅地址可访问，不代表其中每个服务端都可连接；反过来，旧配置仍可工作时，订阅更新失败也未必是代理内核损坏，两条请求可能使用了不同网络路径。

本地监听端口是应用连接客户端的入口，远端端口则是客户端连接服务端的目标，两者没有必须相同的关系。例如本地端口显示为 10808 时，不能据此修改订阅中的远端端口。还要确认该监听入口接受哪一种协议；不同版本可能提供分开的监听端口，也可能使用混合入口，应以当前客户端设置页为准。

阶段二 · 确定工具

选择客户端：先平台，再内核

选型先解决运行平台，再考虑界面和内核。桌面端优先从 v2rayN 开始，便于在 Windows、macOS 与 Linux 之间保持接近的操作思路；安卓端优先使用 v2rayNG。只有已经明确需要 V2Fly 内核行为或兼容特定配置时，再考虑 v2flyNG。安装多款工具并不会自动增加可用性，初学阶段保留一个主要客户端更方便定位设置来源。

桌面端的版本与架构

Windows 的 v2rayN 下载入口区分桌面版与经典 WPF 版。桌面版采用跨平台界面路线，经典 WPF 版保留另一套操作布局；选择时应结合系统要求、现有使用习惯及所需功能，而不是把两个入口理解为不同代理协议。两版都要读取连接资料，也都需要核对内核、监听端口和代理模式，界面熟悉并不能替代配置确认。

macOS 应先在系统的设备信息中确认芯片类型，再选择 Apple Silicon 或 Intel 对应入口。Linux 需要同时判断处理器架构和发行版的软件包体系，常见情况是在 deb 与 rpm 之间选择；使用 arm64 设备时，还要选择对应架构的包。包格式与处理器架构是两条独立条件，只满足其中一条，仍可能无法正常安装或启动。

安卓端的两条内核路线

v2rayNG 以 Xray 内核为主要使用路线，v2flyNG 使用 V2Fly 内核。两者外观或部分操作可能相近，但不能据此假定所有导入格式与协议扩展都互通。如果配置涉及某个内核专有能力，应先确认支持情况。出现字段导入后缺失、无法识别或连接失败时，先检查内核与格式是否匹配，不要立即把问题归因于服务端不可用。

安卓安装包中的 arm64 适合多数较新的主流设备，通用包可在架构不明确时作为另一入口，但实际适配仍以应用要求为准。不要只根据手机购买年份判断架构；系统信息或设备规格更可靠。安装包体积不能直接说明功能多少，通用包通常只是包含更广的运行架构支持，不代表网络速度更快。

减少并行运行造成的干扰

迁移客户端时，先退出原有工具，再启动新工具。桌面上两个程序可能争用系统代理、相同的监听端口或虚拟网卡；安卓的 VPN 授权也会影响现有连接。仅关闭窗口不一定等于退出后台进程，应检查托盘、通知栏或应用状态。比较两款客户端时尽量使用同一网络与同一份连接资料，避免把线路变化误判为软件差异。

下载前可查看三款客户端横向评测，安装入口统一在客户端下载页。本手册不要求记住某个包名或版本号，而是要求能够说明当前平台、处理器架构、客户端和内核分别是什么。后续遇到问题时，这四项信息比一句“已经更新到最新”更能帮助缩小范围。

阶段三 · 建立本地环境

安装与基础设置：先确认本地服务

安装阶段的目标不是立刻调整高级选项，而是确认程序能够正常运行、配置能够保存、本地端口没有冲突。先阅读下载页对应平台的系统要求，再使用系统正常的安装流程。完成后首次打开客户端，保留默认路由与 DNS 设置，暂时不要开启 TUN。这样后面即使连接失败，也能把范围限定在基础路径，而不是同时处理多个网络接管机制。

桌面端启动前的检查

Windows 使用安装程序时按界面选择目录并完成安装；如果取得的是需要解压的发行形式，应完整解压后再启动，不要直接从压缩预览窗口运行。配置目录应位于可写位置，避免放进临时目录或会自动清理的位置。系统提示缺少运行组件时，先查看该客户端的系统要求和明确错误信息，不要从不明来源补装同名文件。

macOS 完成安装后，通过正常应用入口启动；遇到系统安全提示，应确认下载来源和提示内容，再按系统提供的流程处理，不建议为一次安装全局关闭安全机制。Linux 应使用发行版对应的软件包安装工具，留意依赖提示和图形会话环境。安装成功但没有窗口，与内核启动失败是不同问题，应先确认主程序本身能打开设置页面。

本地监听与基本开关

进入基础设置后，记下本地监听地址、端口及入口类型。单机使用通常只需要回环地址，不必开启“允许来自局域网的连接”。端口可保持客户端默认值，只要未被其他程序占用；出现绑定失败时，应先退出重复实例和其他代理工具，再决定是否换端口。改变本地端口后，手动配置代理的应用也必须同步修改，系统代理则需重新应用。

“开启 UDP”与“开启流量嗅探”不应被理解成通用提速按钮。UDP 是否可用还取决于应用入口、路由、服务端和整条链路的支持；嗅探是为了从部分连接信息中辅助识别目标，并不保证识别所有流量。基础阶段可记录原值，后续遇到明确需求再调整。参数保存后如提示重启服务，应先停止当前连接再按提示重新启动。

安卓安装后的权限

安卓安装完成后，先打开应用确认设置能保存，再导入资料。首次以 VPN 方式连接时，系统会弹出授权提示，这代表允许客户端建立本地网络接管通道，不是购买远端服务。拒绝授权时，界面中即使已有配置也无法按该方式接管应用流量。已经运行的其他 VPN 应先断开，避免系统切换到另一个应用后误以为当前客户端仍在工作。

电池管理与后台限制可能导致安卓客户端在锁屏后停止工作，但不宜在安装第一步就修改所有系统优化选项。先完成一次前台连接测试，确认能够工作，再针对“锁屏后断开”处理后台权限。分应用代理也先保持清晰、简单的范围；一开始就叠加大量应用名单，会让后续难以判断究竟是服务未运行，还是测试应用被排除在接管之外。

保存一份初始状态

基础环境就绪后，记录客户端名称、系统、监听端口和当前开关状态。导出或备份配置时注意其中可能含有连接凭据，不要把整份文件发到公开讨论区。验证程序能够关闭并重新打开，设置仍然保留；若每次重启都丢失，应先解决目录写入或系统清理问题。重复安装通常无法修复一个持续被清理的配置目录。

阶段四 · 获取连接资料

订阅导入：区分更新、选择与连接

订阅地址通常带有可识别账户的参数，应按凭据保存，不要公开贴图或把完整链接发到论坛。复制时确认取得的是订阅入口，而不是账户管理页、帮助页或浏览器登录后的页面地址。订阅本身没有统一适配所有客户端的格式；提供方若区分客户端类型，应选择对应格式，避免导入成功却丢失协议相关字段。

桌面端建立订阅分组

在 v2rayN 的订阅分组管理中新增分组，填写便于识别的名称与订阅地址，保存后执行更新订阅。分组名称只用于本地整理，不会改变远端配置。更新结束后查看该分组是否出现可选条目，再选定其中一条作为活动配置。不要把“分组已保存”当作“订阅已更新”，也不要把列表中出现条目当作“当前已连接”。

首次更新时尽量使用当前可用的直接网络路径；如果该入口确实要求经代理访问，应先确认已有一条能够工作的连接，再使用客户端提供的经代理更新方式。尚未建立任何可用连接时，让订阅更新依赖一个尚未工作的代理，容易形成循环条件。网络环境受限时，应向提供方确认订阅入口的可达性，而不是随意改写链接中的参数。

安卓端导入与复核

v2rayNG 与 v2flyNG 可通过各自的订阅管理入口添加资料，具体菜单名称以当前界面为准。完成更新后返回配置列表选择目标，再启动连接。剪贴板导入、扫码导入与订阅更新是不同操作：前两者可能只添加单条连接，不会自动建立后续更新关系。若希望持续获取变更，应确认资料保存在订阅分组中，而不只是一次性导入。

导入完成后检查协议、地址、端口、传输方式与安全设置是否齐全。只查看名称不足以确认配置一致，因为名称可以由提供方任意编写。遇到重复条目时，先按分组确认来源，不要直接全部删除；不同条目可能仅传输参数不同。需要手动修正时，最好复制为独立配置，避免下一次更新订阅覆盖修改后造成难以复现的行为。

更新失败的分层判断

更新返回解析错误，通常要检查响应是否真的是客户端支持的订阅内容。入口过期、账户需要登录、网站返回验证页面，都可能产生“地址能打开但不能解析”的情况。连接超时则应先检查网络与域名解析。不要把网页响应内容直接粘贴到配置字段里，也不要用通用格式转换覆盖原资料，转换过程可能无法保留特定内核所需的扩展字段。

已有订阅更新后条目减少，不一定是本地数据损坏，也可能是提供方调整了内容。先记录旧配置是否仍能工作，再核对分组与更新时间。不要连续清空并重新导入，这会丢失用于比较的线索。若旧条目可用而新条目全部失败，应重点比较新旧配置的协议、传输及安全字段，并确认客户端内核是否支持这次变化。

订阅的安全与维护边界

订阅提供方可以改变下发的连接内容，因此应只保留来源明确、确有需要的订阅。删除分组前先确认是否需要保留独立配置；迁移设备时也不要仅复制显示名称，应使用客户端支持的导出或重新导入方式。若订阅链接曾被公开，应通过提供方的管理入口更换相关凭据，单纯修改本地分组名称不能使旧链接失效。

阶段五 · 验证应用入口

代理模式：系统设置与应用行为

代理模式首先回答“应用怎样把连接交给客户端”，路由模式则回答“收到连接后从哪里出去”。这两层需要分开判断。开启系统代理后选择绕过大陆，并不等于所有应用都已进入客户端；反过来，启用虚拟网络接管，也不代表所有目标都会走远端出口。先把应用入口验证清楚，后面的分流与 DNS 排查才有可靠起点。

桌面系统代理的作用范围

v2rayN 中自动配置系统代理通常会修改当前系统或桌面环境的代理设置，供遵循这些设置的应用使用。浏览器往往能够读取，但某些下载器、游戏或命令行程序可能使用自己的网络设置。界面显示系统代理已开启时，如果只有某个应用仍然直连，应先查看该应用是否继承系统代理，而不是立即更换节点或打开全局路由。

手动给应用填写代理时，要使用客户端实际监听的入口类型、地址和端口。HTTP 入口与 SOCKS 入口不能只凭端口号猜测；混合入口也要确认当前版本确实提供。单机测试通常填写回环地址。应用中若存在“绕过本地地址”“使用独立 DNS”等选项，也可能改变路径，建议先记录原值，再用一个支持明确代理设置的应用进行验证。

用可控请求核对入口

下面的命令仅用于已经安装 curl 的环境，端口需要先与客户端设置核对。它显式使用本地 SOCKS 入口，并让代理端处理目标域名；不修改系统代理，也不改变订阅。示例目标只是一个公开测试站点，测试成败仍受当前网络影响。若客户端没有在该端口提供 SOCKS 服务，应按真实入口调整，不能直接照抄后认定服务故障。

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

显式代理请求能够完成，而浏览器不能访问时，问题更可能出在浏览器代理、扩展、缓存或独立网络设置。两者都失败时，再查看客户端日志是否收到连接。日志没有相应请求，优先检查本地入口；已经收到请求但出站失败，才继续检查远端、路由和解析。测试时固定一个目标并记录时间，避免把不同请求的日志混在一起。

安卓 VPN 与分应用代理

安卓端的 VPN 模式通过系统提供的接口接管流量，不需要给普通浏览器手动填写回环代理。分应用代理则决定哪些应用进入或绕过该通道，名单可能采用包含或排除逻辑，必须阅读当前界面的说明。测试应用若恰好被排除，即使通知栏显示连接运行，也不会沿预期路径访问。更改名单后如需重连，应按客户端提示执行。

判断应用是否被接管时，不要仅凭页面是否能打开，因为直连也可能成功。应结合客户端日志与受控请求观察。安卓应用还可能存在后台进程、内嵌浏览器和独立服务，同一个名称下的不同请求未必完全一致。排查时先使用简单浏览器场景，确认基础路径工作，再处理特定应用，能减少登录状态与后台缓存带来的误导。

关闭与恢复同样重要

桌面停止使用前，应确认系统代理已经清除或恢复；如果只强制结束进程，系统可能继续把连接交给一个不存在的本地端口。此时表现为全站打不开，但未必是网络断开。安卓端则应确认 VPN 连接已断开。测试任何新模式之前，先掌握原模式的关闭办法，并在切换后重启受影响应用，避免复用旧连接造成结果不一致。

阶段六 · 控制连接去向

路由分流与 DNS：规则和解析配合

路由分流在连接进入内核后执行，依据域名、目标地址、端口或其他可用条件选择出站。客户端提供的“绕过大陆”“全局”等预设是规则集合的入口，不是协议本身。全局通常表示对已被接管的流量采用代理出口，但依旧受应用入口和预设例外影响。排查时应查看实际匹配结果，不能只凭模式名称推断某个连接一定走远端。

规则顺序与匹配条件

多数路由规则按顺序判断，较具体的规则应放在可能覆盖它的宽泛规则之前。例如准备为一个域名增加直连例外时，要先理解现有规则是否已在更前面命中。域名规则需要内核知道目标域名；如果应用只提交地址，而入口没有保留域名信息，单纯增加域名规则可能没有效果。嗅探可在部分场景辅助识别，但不能替代所有来源信息。

下面是 Xray 路由对象的局部示例，用于说明精确域名规则的写法，不是一份完整客户端配置。只有完整配置中已经存在名为 direct 的出站时，这条规则才有对应目标。图形客户端可能自动生成路由和出站标签，因此不应把片段粘进任意输入框；优先通过自定义规则界面表达同一含义，并核对生成结果。

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

V2Ray DNS 设置的分层关系

DNS 不只有客户端设置页中的一组服务器。系统解析器、浏览器的加密 DNS、应用内部解析、内核 DNS 都可能参与请求。应用先解析出地址再连接时，内核可能看不到原域名；应用把域名交给代理时，解析又可能发生在另一侧。因此调整 DNS 前，先确定当前入口传递的是域名还是地址，避免改了内核 DNS 却期待影响应用已经完成的查询。

内核 DNS 的请求也要有可用的网络路径。若解析服务只能经代理访问，而代理服务端的域名又必须依赖该解析服务才能获得地址，就可能形成启动依赖循环。基础排查时先恢复客户端默认策略，确认服务端地址能解析，再分别处理直连目标与代理目标。不要同时修改系统 DNS、浏览器加密 DNS 和内核策略，否则很难判断哪一层真正改善了结果。

域名策略不是通用优化等级

AsIs、IPIfNonMatch 等策略影响路由阶段是否尝试把域名解析为地址，以便匹配地址规则，并不简单代表“快”与“慢”。不同内核和设置位置还可能存在语义差别。使用地址规则时要考虑解析结果是否适合预期出口；使用域名规则时则要先保证域名信息可用。明确规则目的，比盲目选择看起来更积极的策略更重要。

IPv6 也需要单独观察。网络可能同时返回两类地址，而其中一种路径不可达，表现为等待后才打开或某些目标失败。应先比较日志中的解析与连接错误，再决定调整地址选择策略；不要把全局关闭某类地址当作所有故障的固定答案。修改后对相同目标重新建立连接，已有长连接和缓存不一定立即反映新设置。

阶段七 · 扩展接管范围

TUN 模式：启用条件与恢复方法

TUN 通过虚拟网络接口把匹配流量送入处理链路，适合无法读取系统代理设置、又需要统一接管的应用。它扩大的是入口范围，不会自动修复错误的远端资料，也不会保证所有协议和网络场景都可用。启用前，应先让同一连接在基础模式下工作；若系统代理下已经出站失败，应先排查配置，而不是用 TUN 包住原有故障。

先确认功能与权限

桌面 v2rayN 的 TUN 实现、可用选项及所需权限，取决于平台、客户端和当前选用的内核。先检查设置页是否实际提供该功能，以及界面给出的权限提示。需要管理员或系统授权时，应使用正常授权流程，不要把客户端长期运行在高权限状态当成排错的唯一办法。没有相关入口时，也不要套用其他平台的菜单位置或配置字段。

启用之前关闭其他会接管网络的工具，包括另一套虚拟网络接口、网络过滤程序的冲突模式及原有代理连接。多种接管机制叠加时，可能出现默认路由互相覆盖、DNS 请求被重复处理或流量绕回入口。仅看两个开关都显示开启无法判断是否兼容；应先建立单一工具的可工作状态，确有必要时再逐项验证共存关系。

按顺序完成一次启用

1. 记录原来的系统代理、路由模式与 DNS 设置，确认客户端可以正常退出。
2. 选择已经验证可用的连接，按照当前平台提示授权并开启 TUN。
3. 先检查普通网页，再测试原先不遵循系统代理的应用，观察对应日志。
4. 验证本地网络服务与必要的工作连接，确认没有被错误接管。
5. 完成关闭测试，确认虚拟接口与系统网络能够恢复，再决定是否长期使用。

这套顺序的重点是保留基线。开启后不要立刻同时切换路由、DNS 与节点；先验证接管范围确实发生变化。若客户端说明系统代理与 TUN 应配合使用，按该实现的文档处理；如果两者相互独立，也不应仅凭经验强制叠加。不同平台的实现细节不相同，不能把某一次成功的组合视为普遍规则。

本地网络与 DNS 的例外

局域网设备、打印服务、公司内部域名和远程工作连接可能依赖本地路由或专用解析器。TUN 启用后若只有这些资源失效，应检查本地地址与内部域名的绕过规则，而不是把所有目标都改为代理。内部域名的解析结果可能随网络变化，单独硬写一个地址未必长期可靠；涉及工作网络时，应遵循网络管理员给出的访问条件。

DNS 接管也是常见分界点。开启后出现全部域名失败但地址连接仍可建立，说明需要重点检查解析路径；若连本地网关或原本可用的直接连接都异常，则先查看路由接管与接口状态。不要在无法解释现象时连续重装虚拟接口。先停用 TUN 并恢复基线，能够恢复就说明问题集中在新增接管层，后续排查范围会明显缩小。

安卓 VPN 与桌面 TUN 的区别

安卓客户端的 VPN 模式同样通过虚拟网络接口接管流量，但它的授权、分应用控制和系统限制由安卓机制管理，不能直接照搬桌面 TUN 的参数。遇到锁屏断开、另一个 VPN 抢占或应用名单不生效，应回到安卓设置检查。概念上可以比较入口作用，操作上仍应分别处理，不要求安卓界面出现与桌面完全相同的开关。

阶段八 · 维持可复现状态

日常维护：测速、日志与更新

日常维护的目标是保持配置可解释，而不是追求列表里某个最小数字。一次测试受到本地网络、远端状态、目标站点和测试方式共同影响。客户端更新、订阅更新与规则资源更新也属于不同操作：前者改变程序及相关能力，订阅改变连接资料，规则资源改变匹配依据。每次只处理一类变更，出现异常时才有清晰的回退方向。

V2Ray 节点测速该看什么

TCP 连接测试主要反映能否建立到目标端口的连接，不能证明完整协议握手和网页访问都成功。通过代理请求测试地址，更接近真实访问过程，但仍只代表该目标与当时条件。吞吐测试还会受到测试文件、并发、服务端限速和本地带宽影响。比较条目时应使用相同方法、相近时段和同一网络，不把不同测试类型的数字直接排在一起判断。

对日常体验而言，先验证常用目标是否稳定，再看连接时间与持续传输表现。网页慢而文件传输正常，可能涉及 DNS、连接建立或页面依赖；单个站点慢而其他目标正常，应先考虑目标路径。不要因一次超时就删除所有配置，也不要因为一次成功就认定问题消失。保留少量可重复的测试目标，比频繁切换测试工具更容易得到有效结论。

日志沿连接链路阅读

日志首先用于判断请求有没有进入内核，其次才是分析出站。查找与测试时间、目标和入口相符的记录：本地监听失败指向端口或权限；解析错误指向 DNS；连接拒绝、超时及安全握手失败则需要分别检查地址、网络、协议与安全参数。某个错误词可能有多种成因，应结合前后文，不要只凭一行提示套用固定修复方案。

临时提高日志详细程度时，测试完成后恢复常规级别，避免长期积累大量敏感访问记录。分享日志前删除订阅地址、用户标识、令牌、个人域名及可识别账户的信息，只保留必要的错误类型和时间关系。截图还可能包含剪贴板提示与其他配置名称，发布前应逐项检查。公开排障不需要完整凭据，提供凭据反而增加后续维护负担。

更新前保留可恢复的基线

更新客户端前，记录当前使用的内核、代理模式与自定义规则，并使用客户端支持的方式备份必要配置。备份应放在受控位置，不宜直接同步到公开目录。更新后先保持原有模式，验证原本可用的连接，再启用新增功能。如果只有更新后某条配置失败，重点比较相关能力与生成配置的变化，而不是立即全面修改远端资料。

记录有效的故障描述

“连不上”可以进一步拆成订阅更新失败、服务无法启动、请求未进入入口、出站握手失败或特定目标异常。记录系统、客户端、内核、当前模式、发生条件和最近一次变更，并写明关闭代理后是否恢复。这样的描述能够复现实验，也便于判断下一步改哪一项。速度问题可结合节点、线路与本地设置分层排查继续分析。

阶段九 · 按需求扩展

进阶路线：从可用配置到可验证规则

进阶不是把所有开关打开，而是在明确需求后增加一个可验证的能力。完成前八章后，应已经有一套稳定基线，知道请求如何进入、怎样分流、在哪里解析，以及如何关闭恢复。接下来可按协议理解、自定义路由、解析策略和配置管理四条路线逐步学习；每次实验都写下目的、预期现象与恢复方法，避免只记住某组参数而不知道它解决什么问题。

先读懂连接参数

协议路线可以从比较 VMess 与 VLESS 开始，关注认证、加密与传输安全各自承担什么职责，再理解 TLS 或 REALITY 对服务端设置的要求。不要把某个协议名称当成性能承诺，也不要认为减少一个字段就一定更快。实际连接还受到传输、网络路径与服务端实现影响。可先阅读VMess 与 VLESS 配置差异，再对照现有资料逐项解释字段。

安全相关参数必须与服务端条件一致。服务器名称、公钥相关字段、指纹选项及传输路径都有具体作用，不应从其他示例中随意拼接。遇到证书或握手问题时，先检查系统时间、名称匹配和配置来源；不把跳过证书验证作为长期解决方案。若提供方变更了安全参数，应重新获取完整资料，而不是只替换看起来不同的那一项。

把自定义路由做成小实验

路由路线建议从单个精确域名开始：定义希望直连还是代理，添加一条规则，观察匹配结果，再检查其他目标没有被改变。确认后才扩大为域名后缀或地址范围。范围越广，越需要说明为什么要覆盖这些连接；规则数量本身不是配置质量。长期保留的规则应附带用途记录，过时例外要定期检查，避免后来忘记它为何排在默认规则之前。

多条规则冲突时，把问题缩小到最少规则集合，逐条恢复并观察。直接导入一大份不理解的规则，很难判断是否适合自己的内核和解析路径。图形界面中的预设、自定义规则与完整配置可能存在覆盖关系，应先弄清客户端如何合并它们。修改生成文件后被客户端重写，通常说明改错了持久化入口，而不是文件权限一定异常。

解析策略与 FakeDNS 后置学习

DNS 路线应先掌握普通域名解析和地址匹配，再考虑 FakeDNS。FakeDNS 使用映射地址保存域名关联，后续需要正确还原目标，并与流量入口和路由配合；它不是可以脱离环境单独打开的通用选项。应用缓存、绕过客户端的连接或不完整的映射链路，都可能导致访问异常。只有能够解释当前域名信息在哪里丢失时，才有理由进一步评估这类机制。

测试解析策略时，应固定一个目标，分别观察解析结果、实际出站与失败阶段。不要把缓存命中后的速度当作所有请求都会获得的收益，也不要因某次修改改善了一个站点，就直接应用到所有设备。桌面与安卓可能使用不同入口和系统解析环境，同一概念可以共用，参数组合却需要分别验证。迁移设置时复制目的与验证方法，比逐项照搬开关更可靠。

建立个人配置笔记

配置笔记可以按日期记录变更目的、涉及页面、旧值、新值、测试目标与结果，但不要包含真实订阅链接和账户凭据。将客户端设置、连接资料与规则分别整理，后续迁移时就能决定哪些应重新导入、哪些需要手动恢复。发生故障后先回到最近的工作状态，再重做单项实验；这比依赖一张很久以前的全屏截图更容易维护。

遇到问题时，按现象回到对应章节：导入错误回到订阅，应用未接管回到代理模式，目标走错出口回到路由与 DNS，开启虚拟接口后异常回到 TUN。需要重新建立基础连接时，使用快速上手教程；需要换平台时，先到下载页确认客户端与架构。精通的标志是能够解释和验证配置，而不是必须使用最复杂的组合。