V2Ray 配置完整手册

一、核心概念与连接链路

客户端、内核与服务器各负责什么

V2Ray 配置需要先分清三个层次：图形客户端负责保存服务器、管理订阅和展示设置；内核负责接收流量、匹配规则并建立连接；远端服务器提供实际出站能力。安装客户端只完成本机准备，并不会自动获得可连接的服务器。桌面首推 v2rayN，移动端可选择 v2rayNG 或 v2flyNG，具体选型见下一章。

Project V 是相关代理技术的生态背景，V2Fly 延续 V2Ray 的开发，Xray 是同一技术生态中的另一条内核路线。客户端名称和内核名称不是一一对应关系，也不能仅凭名称判断所有协议都可用。导入配置后，需要核对客户端所调用的内核、它支持的字段以及服务器要求；图形界面能显示一条配置，不等于内核一定能运行它。

协议、传输与安全参数分开理解

协议描述客户端与服务器之间怎样组织通信，常见名称有 VMess、VLESS、Trojan 和 Shadowsocks。传输描述这些数据通过什么方式承载，例如 TCP、WebSocket 或 gRPC。TLS 和 REALITY 则涉及连接的安全握手。分享链接往往把几层参数一起编码，所以看起来是一串地址，实际包含端口、身份信息、传输和安全设置。

VLESS 本身不是一套完整的加密传输方案，是否使用 TLS 或 REALITY 要按服务器配置判断。REALITY 也不是与 VLESS 并列的代理协议选项。手工添加时，地址、端口、用户标识、传输类型、服务器名称等字段需要彼此一致。不能因为两个服务器都写着 VLESS，就把它们的公钥、短标识或路径互相替换。

先建立可复现的最小连接

一条常见链路是：浏览器读取系统代理设置，将请求交给本机入站端口，内核按路由规则选择代理出站，再连接远端服务器。其他应用可能忽略系统代理，TUN 则提供另一种流量进入方式。这里的“进入客户端”和“从哪个出站离开”是两件事；后续调整模式时始终沿着这条链路判断，避免把入口故障误认为服务器故障。

首次测试只保留一条来源明确的服务器配置，暂时使用客户端的基础路由方案，不开启复杂自定义规则。确认系统时间准确，关闭重复运行的代理进程，再启动内核并访问一个明确的测试目标。保留成功时的模式和日志摘要，后续变更才能与基线比较。单次速度测试不能替代实际应用访问，也不能代表所有传输类型均正常。

排错时从近到远检查：本机入站是否启动，应用是否使用该入口，规则选择了什么出站，远端连接是否完成。日志中的启动失败、握手失败与请求超时分别指向不同阶段。先明确失败发生在哪一层，再去修改对应设置；反复重装客户端通常不能解决地址失效或服务器参数不匹配。

二、按平台与内核选择客户端

桌面优先选择 v2rayN

Windows、macOS 和 Linux 桌面用户优先从 v2rayN 开始，便于沿用本手册的订阅分组、服务器、参数设置、路由设置和 DNS 设置等概念。选择前先确认操作系统、处理器架构与软件包格式，而不是只看文件体积。客户端永久免费、代码开源，但不同发行包的运行依赖和系统集成方式仍有差异，安装前应阅读对应平台说明。

Windows 下载货架提供 Desktop 桌面版和经典 WPF 版两个入口。Desktop 使用跨平台界面路线，适合希望在不同桌面系统保留相近操作习惯的用户；WPF 是 Windows 的经典界面路线。两者不是两个协议，也不表示前者的服务器速度一定更快。先选一种完成配置，不建议为排错同时运行两个界面并让它们竞争系统代理。

移动端按配置兼容性选择

Android 首推 v2rayNG，使用 Xray 内核；v2flyNG 作为 V2Fly 内核路线的备选。两者的基本操作都围绕导入配置、选择服务器和启动连接，但协议实现及字段支持不能视为完全相同。尤其是包含 REALITY 或特定传输参数的配置，应先核对所选内核是否支持，不要把“能解析链接”直接当作兼容性结论。

主流较新的 Android 设备通常选择 arm64 包，不能仅按购买年份判断架构。部分设备的硬件支持六十四位，但系统环境可能不同；不确定时查看设备信息或使用通用版。通用版便于覆盖多种架构，文件体积可能更大。安装失败先检查架构、系统要求和是否存在签名不同的旧安装，再考虑换客户端。

内核切换不替代服务器参数检查

v2rayN 可根据发行包与功能支持选择不同内核，常见选项包括 Xray 和 sing-box。切换前要确认当前配置能够由目标内核表达，尤其是路由、DNS 与 TUN 的设置。内核之间并不共享全部 JSON 字段，客户端的图形选项也可能需要转换。不要把某个内核的完整配置直接粘到另一个内核的自定义配置框中。

建立基础连接时，优先使用客户端为该服务器类型提供的常规内核选择。只有遇到明确的兼容问题或需要特定功能，再尝试另一条路线。切换后重启连接，重新检查实际生成的配置和日志，确认代理入口、规则与 DNS 没有回到默认值。界面仍显示同一个服务器名称，不代表运行链路完全没有变化。

多设备使用时，保存的是参数含义，而不是强求每个按钮名称一致。桌面可以通过系统代理接入浏览器，Android 通常借助系统 VPN 接口接收应用流量，操作系统的授权与限制不同。下载入口见下载中心；Desktop 与 WPF 的界面路线可继续阅读桌面版与 WPF 版区别，选定后再进入安装阶段。

三、安装与首次启动检查

安装前确认架构、目录与旧配置

安装的目标是得到一套可以正常启动内核、保存设置并申请必要权限的客户端环境。先退出已有客户端，备份需要保留的服务器与路由，再从下载中心选择对应包。桌面配置目录应当允许当前用户写入；如果使用压缩包形式的发行文件，需要完整解压后运行，不能只从压缩软件里临时打开主程序。

不要把迁移和首次安装同时完成。先启动新环境，确认窗口和基础设置能够正常保存，再导入旧配置。直接覆盖整个旧目录可能把过时的内核文件、端口设置或自定义参数一并带入。若安装器管理程序文件，应按安装器流程操作；若使用独立目录，则保持该目录内文件的对应关系，避免混用不同来源的内核和界面文件。

Windows 与 macOS 的首次启动

Windows 用户先启动 v2rayN，查看是否提示运行依赖缺失或内核启动失败。出现依赖提示时按对应发行包说明处理，不要用管理员权限掩盖文件缺失。普通系统代理通常不要求长期以管理员身份运行；TUN 或系统级网络设置可能另行要求提升权限。权限、依赖和端口占用是三个独立问题，处理时应分别确认。

macOS 用户先在“关于本机”确认芯片类型，再选择 Apple Silicon 或 Intel 包。按安装流程把应用放到正常应用目录中，然后首次打开。系统若阻止来自未验证开发者的应用，应先确认下载来源，再到“系统设置 → 隐私与安全性”查看针对该应用的允许选项；不应为了一个客户端关闭系统的整体安全机制。

授权成功后仍需检查网络相关操作是否被系统拒绝。应用可以打开，不等于修改系统代理或启动虚拟网卡已经获得权限。按实际提示允许必要操作，修改后重新启动连接。提示“应用已损坏”也不能一律归因于权限，应先重新下载匹配架构的安装包并确认安装过程，具体分支见macOS 安装与权限处理。

Linux 与 Android 的安装边界

Linux 用户根据发行版的软件包体系选择 deb 或 rpm，再核对 x64 与 arm64。优先使用系统的软件包安装工具，让依赖与程序文件按正常流程落位。桌面会话、权限提升工具和系统代理集成方式可能因环境不同而变化；程序窗口正常但系统代理不起作用时，可以先在一个应用内显式配置本地代理，区分界面启动与系统集成问题。

Android 安装 v2rayNG 或 v2flyNG 时，系统可能要求允许当前下载或文件管理应用安装软件，授权范围应限定到当前操作。若覆盖安装失败，先考虑包架构或签名差异，备份后再决定是否卸载。首次启动连接通常会弹出系统 VPN 授权，确认后才会建立应用流量入口；后台电池限制则需要在连接稳定后单独检查。

首次退出前检查是否残留系统代理设置。部分客户端关闭窗口只会最小化到托盘，内核仍在运行；另一些退出操作会结束进程，却可能因异常未恢复代理。重新打开确认实际状态，并记下本地入站端口。后面排错需要用这个端口判断应用是否连到了正确入口，不应依赖对默认端口的记忆。

四、订阅导入与服务器管理

区分订阅地址与分享链接

订阅地址用于批量获取和更新服务器，分享链接通常描述单条服务器配置。两者都可能呈现为长字符串，但导入入口不同。拿到配置后先确认提供方给出的是哪一种，不要把网页介绍地址当成订阅，也不要把一条 VLESS 分享链接放进订阅下载框。二维码只是文本的载体，扫描后仍然需要判断其中是订阅还是单条配置。

在 v2rayN 中进入订阅分组，添加分组名称与订阅地址，保存后执行更新；分组名称建议按来源或用途命名，而不是写具体连接质量。v2rayNG 和 v2flyNG 中使用订阅设置或对应的导入菜单，保存后更新配置。菜单文字可能略有变化，但操作顺序不变：建立来源、获取配置、检查结果、选择当前服务器。

更新后检查字段，而不是只看列表

更新完成后确认服务器确实出现在预期分组，再检查协议、地址、端口、传输与安全参数。列表里的备注只用于辨认，不是连接可用性的证明。订阅更新有时会替换原有条目，原来选择的服务器可能失效或被重新定位；更新后重新确认当前项，避免客户端继续使用已经删除或不再适合当前内核的配置。

分享链接可以通过从剪贴板导入的入口添加。复制时保留完整字符串，避免聊天工具截断尾部参数，或把说明文字和链接一起复制进去。手工添加适合明确知道各字段用途的场景；如果已有完整分享链接，应优先导入再逐项检查，减少漏写路径、服务器名称、公钥或短标识等字段的机会。

订阅与单条配置需要分别保护。地址中的令牌、用户标识和认证字段可能允许他人读取或使用服务，不能放进公开截图、日志帖子或示例代码。分享给排错人员时只保留字段名称与错误信息，隐藏真实地址及身份数据。订阅泄露后应到提供方处重新生成或撤销，而不是只删除客户端中的那一行。

更新失败按获取、解析、运行三层排查

第一层是获取失败：订阅域名能否解析、地址是否到期、系统时间是否正确、返回内容是否被登录页替换。第二层是解析失败：文本格式、编码、协议类型是否受到当前客户端支持。第三层是运行失败：条目已导入，但内核不支持某个字段或服务器不可连接。这三种失败的处理方向不同，不能统一归为“订阅坏了”。

首次导入可尝试“更新订阅（不通过代理）”，以免订阅更新依赖尚未建立的代理连接。若订阅地址确实必须经代理访问，需要先保留另一条可用服务器，再执行通过代理更新。这里不存在所有地址都适用的固定选项；关键是更新请求不能依赖正在被替换、已经失效或指回自身的连接链路。

多个来源建议分组维护，不要频繁把条目混合复制后丢失来源关系。自动更新前确认覆盖行为，手工修改的备注或参数是否会被重新生成。出现反复失败时保留一份可用配置，暂停自动更新，再按订阅更新失败自查步骤核对返回内容与更新方式。完成这一阶段后再设置代理入口，排错范围会更清楚。

五、系统代理模式与应用入口

模式控制入口，不决定所有出站

系统代理模式决定操作系统如何向应用提供代理设置，路由规则决定进入内核的请求走直连还是代理。启用“自动配置系统代理”后，浏览器可能开始使用本地入口，但请求仍可被路由规则选择为直连。因此“系统代理已开启”和“全部流量经服务器转发”不是同一个状态，测试时应分别确认应用入口和实际出站。

v2rayN 常见选项有清除系统代理、自动配置系统代理和不改变系统代理。清除用于移除系统当前的代理配置；自动配置用于写入客户端的本地地址与端口；不改变则保留操作系统已有设置。最后一项不会自动修复残留端口，如果系统仍指向已经退出的另一个客户端，应用访问可能继续失败。

显式应用代理与系统代理分开测试

并非所有应用都会读取系统代理。某些应用提供独立的 HTTP 或 SOCKS 设置，另一些只读取启动时的环境，修改系统设置后需要重启应用。先选一个明确支持系统代理的浏览器作为测试对象，排除扩展或应用内配置覆盖。随后再测试其他程序，就能区分“客户端连接失败”和“该程序没有进入客户端”。

显式配置应用代理时，地址通常填写本机回环地址，端口以客户端实际显示为准，类型必须与监听入口一致。HTTP 入口和 SOCKS 入口不是仅名称不同，应用选错类型可能直接握手失败。入站若监听回环地址，其他设备无法直接使用它；不要为了方便随意开放所有网卡，否则本地代理的访问范围也会随之扩大。

本手册不固定某个默认端口，因为已有配置、客户端发行包与用户修改都可能改变端口。若日志提示地址被占用，先退出其他代理进程，检查是否重复启动，再决定是否改端口。修改后必须同步更新系统代理或应用内配置。只改客户端一侧而保留浏览器旧端口，是常见的“内核启动正常但页面打不开”原因。

验证成功与恢复失败现场

完成自动配置后启动连接，访问一个明确的目标并查看对应时间附近的日志。先关注连接是否建立，而不是立即比较速度；测试功能可能测量不同目标与不同阶段，不能把显示结果直接当成网站访问质量。若客户端有请求或路由日志，检查目标请求是否出现，出现后又选择了哪个出站，缩小排查范围。

若没有请求进入内核，优先检查应用自身代理设置、系统设置与本地端口。若请求进入但远端握手失败，回到服务器参数与内核兼容性。若握手完成但目标访问失败，再查 DNS、路由或目标服务。这个顺序比轮流切换所有模式更有效，也能保留足够的现场信息说明问题发生在哪里。

Android 的连接入口通常通过系统 VPN 接口建立，不应照搬桌面的系统代理菜单。系统授权、应用范围和后台限制都需要在移动端单独确认。先让一个应用在前台正常访问，再测试锁屏和切换网络；入口已经稳定后才进入下一章的路由调整，避免把应用接入问题误判为规则问题。

六、路由分流与 DNS 配合

规则匹配先后顺序

路由分流的目标是按明确条件选择出站，而不是堆叠尽可能多的规则。常见方案包括绕过大陆（Whitelist）、黑名单（Blacklist）和全局（Global），具体默认规则随客户端配置而变化。名称可以帮助辨认，但最终行为取决于规则内容、排列顺序与未命中时的默认出站，使用前应查看实际方案而不是只凭标签判断。

多数规则按顺序匹配，优先满足的条件会影响后续规则能否生效。局域网和私有地址一般应明确直连，特定业务域名放在通用规则前面，宽泛的兜底规则置于后面。若某个域名总是走错出站，先查它是否已经被前面的域名、地址或端口条件匹配；在列表末尾追加规则不一定会改变结果。

域名规则与地址规则的输入条件

geosite:cn 是域名集合引用，geoip:private 是私有地址集合引用，它们需要内核能够读取相应资源。域名规则需要请求保留域名信息，地址规则则根据目标地址判断。应用若在本地先完成解析，只把 IP 交给入口，域名匹配可能受到限制；嗅探能在部分流量中补充域名，但不是所有协议都能被识别。

DNS 设置参与这条链路：谁发起解析、解析请求走什么出站、返回哪个地址，会共同影响路由和连接。不要只为了更换解析结果而同时开启多组互相重叠的 DNS 功能。先明确本地应用 DNS 与内核 DNS 的职责，再检查是否存在直连解析和代理解析使用同一上游却产生循环依赖的情况。

在已有配置中添加可解释的规则

下面是 Xray / V2Ray 风格的路由片段，用于说明私有地址与域名集合直连的含义。它不是完整客户端配置，需要已有出站中存在 direct 标签，也需要对应的地理数据文件。图形客户端用户应优先在路由设置里建立等价规则；使用其他内核时，必须按该内核的规则格式重新表达。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs 表示路由阶段不会仅为地址匹配而主动进行域名解析，不代表连接阶段永远不使用 DNS。不同域名策略影响何时解析以及何时尝试地址规则，改变它可能让原本未命中的地址条件开始生效。初学阶段保留基础方案，只有确认缺少哪类匹配信息后再调整，不应把某个策略名称当成固定性能优化。

自定义规则先用单个明确域名验证，写清需要直连还是代理，观察日志确认命中，然后再扩大到域名集合。测试局域网设备时同时检查私有地址、局域网域名和应用是否被 TUN 接管。只让私有 IP 直连，不一定能解决局域网域名解析失败；路由正常与 DNS 正常必须分别验证。

规则资源更新后结果可能变化，手工规则也可能与订阅或默认模板冲突。每次修改保存前后内容，记录测试目标和命中出站；出现故障先回滚最近一次变更。复杂配置要能回答“这条规则匹配什么、为什么放这里、未命中怎么办”，否则维护成本会持续增加。

七、TUN 虚拟网卡与接管范围

从应用代理扩展到网络入口

TUN 通过虚拟网络接口接收 IP 层流量，适合需要接入不读取系统代理的应用。它解决的是入口覆盖范围，不会自动修复失效服务器，也不保证所有应用协议都可用。启用前必须已经有一条正常的基础连接，并理解现有路由方案；否则入口、DNS 和服务器同时出问题，日志会变得难以判断。

桌面 TUN 通常需要创建虚拟接口和修改系统路由，因此可能要求权限提升或相应网络组件。v2rayN 中的“启用 Tun 模式”只是操作入口，实际行为还取决于内核、平台和设置。先确认该环境支持此功能，再按客户端提示操作。不要在内核尚未启动或依赖缺失时反复开关系统路由。

检查回环、局域网与其他隧道

启用前退出其他会改路由的代理或 VPN 程序，避免两个入口争夺默认路由与 DNS。系统中同时存在多个虚拟网卡不一定有故障，但必须清楚哪一个在接收当前流量。开启后先观察客户端是否记录接口建立成功，再测试一个应用，最后检查局域网设备和普通直连目标，不要只看界面的开关状态。

连接远端服务器所用的底层流量应避免再次被送回 TUN 入口，否则可能形成回环。客户端和内核通常提供自动路由、接口选择或绕过设置，但多网卡、热点共享和自定义路由可能改变前提。若日志持续重复连接且连接始终不能建立，先关闭 TUN 恢复系统代理基线，再检查出口网卡与服务器地址的实际路由。

局域网访问需要同时照顾私有地址和名称解析。打印机、路由器管理页或网络存储不能访问时，先用明确的局域网 IP 测试，再用设备名称测试。前者失败更偏向路由或防火墙，后者单独失败则更偏向 DNS。不要把所有局域网故障都通过加入一个宽泛代理规则处理，那可能让原本应在本地完成的请求绕到远端。

DNS、UDP 与网络切换的验证顺序

TUN 配置常与 DNS 接管配合，但 DNS 接管不能替代完整的解析策略。先确定系统查询被送往哪里，内核怎样解析远端服务器，以及解析上游是否又依赖代理连接。服务器地址解析依赖尚未建立的隧道时，可能产生启动死锁。需要在配置上保留能完成首次连接的解析路径，而不是盲目把所有 DNS 都交给同一出站。

浏览器网页正常不代表 UDP 或所有业务流量正常。语音、实时通信和其他应用需要根据自身协议测试，同时核对服务器及传输是否支持所需流量。测试失败时观察是否进入内核、是否匹配正确出站，以及是否被系统防火墙拦截。不要仅因开启 TUN 就承诺所有应用都会自动获得相同的连接表现。

设备从有线切换到无线、休眠唤醒或更换热点后，出口接口和 DNS 都可能变化。先重启连接再测试，不要立刻重写全部规则。Android 同样应检查系统 VPN 状态、后台运行限制和应用接管范围。只有前台、后台以及切换网络三个场景都得到明确结果，才能判断这套入口方案适合日常使用。

八、日常维护与分层排错

维护可用基线与最小备份

日常维护优先保存一套已验证可用的配置，包括客户端路线、所用内核、订阅分组、代理模式、路由方案和必要的 DNS 设置。备份只保存需要恢复的信息，不要把全部日志长期混入配置档案。导出文件可能包含订阅凭据与服务器身份信息，应放在受控位置，迁移时也需要避免被公开同步或误分享。

订阅更新、客户端更新、内核切换和规则资源更新尽量分开进行。一次只完成一种变更，重启连接并测试常用目标后再继续。若全部同时更新，故障出现时很难判断是服务器条目变化、参数转换、规则命中还是程序依赖导致。维护记录不需要复杂表格，但至少写下改了什么、为什么改、怎样恢复。

日志按失败阶段阅读

内核启动失败先检查配置语法、字段兼容、资源文件和端口占用；启动正常但应用没有请求则检查入口；请求进入后连接超时再查服务器地址、网络与出站；握手报错则核对身份信息、TLS 或 REALITY 参数。日志中的错误文字只是线索，需要与操作时间对应，不能把旧连接的错误当作当前配置的结论。

需要收集日志时临时提高日志详细程度，复现一次明确操作，再恢复日常级别。过多日志可能占用存储，也可能记录目标域名、地址或账户相关字段。提交排错材料前删除凭据和无关请求，只保留客户端环境、错误发生时间、操作步骤与对应日志。问题描述越具体，越容易得到可验证的建议。

时间、端口与网络环境的固定检查

系统时间错误可能影响证书判断以及部分协议的认证过程，设备长时间离线、休眠恢复或关闭自动校时后尤其值得检查。端口冲突通常与重复进程或其他代理程序有关，先正常退出再重试；改端口必须同步应用配置。网络环境变化则需要核对新的 DNS、出口接口和是否存在必须先完成的网页登录。

如果同一配置在一个网络正常、另一个网络异常，应保持客户端设置不变做对照测试。先检查该网络自身的普通访问和解析，再观察连接具体在哪一步失败。不同目标表现不一致时，不应立即推断全部服务器失效；同样，单条服务器失败也不能证明客户端需要重装。比较对象要固定，才能把差异归到合理的层次。

更新后回退应优先恢复配置和兼容的运行环境，而不是只替换一个主程序文件。新版设置格式可能无法被旧界面完整理解，迁移前保留独立备份更稳妥。Android 卸载可能删除应用数据，桌面卸载也不应假定一定保留配置目录；在操作前确认导出内容可读取，并保护其中的敏感信息。

常见问题可先查 FAQ，需要快速重建最小链路时返回使用指南。维护的重点是减少不确定变化，而不是追求所有设置始终最新；能够解释当前配置、稳定复现问题并可靠回滚，才是继续进阶的基础。

九、进阶配置的学习路线

先读生成配置，再写自定义配置

进阶的第一步是理解客户端已经生成了什么，而不是立即从空白文件搭建整套配置。先在本机查看当前运行配置中入站、出站、路由和 DNS 的对应关系，确认图形设置如何转换为字段。注意生成文件可能被下一次启动覆盖，应通过客户端支持的设置入口修改，不要把直接编辑临时文件当成长期维护方式。

读配置时先追踪标签：哪个入站接收应用请求，规则指向哪个出站，默认出站又是什么。再阅读传输与安全参数，最后处理 DNS 和特殊功能。一次只研究一条请求的路径，就能看出某个字段是否真的参与当前连接。没有被引用的出站或没有命中的规则，不会因为出现在文件里就自动发挥作用。

以最小规则实验理解匹配

先添加一个范围明确的域名规则，验证命中之后再扩大到域名集合。下面的片段表示把 example.com 及其子域名交给名为 direct 的出站；它只用于规则实验，不代表该域名在所有环境都应直连。此片段需并入 Xray / V2Ray 风格的现有路由规则数组，且对应出站标签必须存在。

{
  "type": "field",
  "domain": ["domain:example.com"],
  "outboundTag": "direct"
}

实验前记录原规则顺序，实验后观察目标域名是否进入内核、是否保留域名信息以及是否选中指定出站。若没有命中，先分析前面的规则和入口信息，再调整 DNS 或嗅探。把失败原因解释清楚后再继续添加条件，才能避免最后得到一组只在某次启动偶然有效、却无法说明原因的配置。

按需求研究 DNS 与 FakeDNS

FakeDNS 用保留地址池中的地址代表域名，并维护两者的映射，后续流量再借助映射恢复目标信息。它常与 TUN 和域名分流配合，不是普通公共 DNS 地址，也不是所有场景都适合开启。应用缓存、局域网解析和入口覆盖不完整时可能出现异常，需要先理解地址如何返回、怎样被内核接收，以及何时转换成真实连接。

研究此功能前应已经能够分别验证普通 DNS、TUN 与域名路由。开启后测试域名访问、直接 IP 访问、局域网设备以及关闭功能后的恢复过程，尤其注意应用是否缓存了先前返回的地址。具体原理与适用边界见FakeDNS 原理与 TUN 配合；不要把它当作连接失败时的通用修复开关。

把进阶结果整理成可维护方案

自定义配置、复杂路由与不同内核的规则转换，应先在独立配置中实验，保留原来的日常方案。每项功能写明用途、输入条件、依赖资源和回滚方式。例如一条域名规则依赖应用保留域名，某个 TUN 设置依赖权限与出口接口，某个解析方案依赖先建立代理连接；这些前提比复制一长段参数更重要。

对性能的判断也要控制变量。固定网络、服务器和测试目标，分别观察连接建立、网页加载与应用实际行为，不把短时测试结果外推到全部场景。日志详细级别、并行应用和 DNS 缓存都会影响观察。只有重复结果稳定、能够解释改动如何影响链路，才值得把实验设置纳入日常配置。

学习路线可以沿本页顺序循环：先确保安装与订阅正确，再确认应用入口，随后验证路由和 DNS，最后扩展 TUN 与自定义功能。基础概念仍有疑问时，可阅读V2Ray 新手入门十问补齐术语，再回到具体章节操作。保留简洁、可解释的配置，比长期依赖无法理解的整套参数更容易维护。