V2Ray 完整手册
v2rayN 安装与配置进阶

核心概念：先分清客户端、内核与服务端

连接链路由哪些部分组成

图形客户端负责保存服务器参数、管理订阅、设置系统代理，并把选择结果交给代理内核。内核负责监听本地端口、判断路由、建立远端连接与处理协议。服务端则提供远端接入，需要与客户端使用相互兼容的协议和参数。安装 v2rayN 只是准备好本地工具，不等于已经具备可用的远端服务；订阅地址也不是软件本身的下载地址。

一次常见的访问路径是：浏览器读取系统代理设置，把请求交给本地监听端口；内核根据目标域名或地址匹配路由，再选择直连、代理或阻断。若选择代理，才会使用当前服务器的协议建立远端连接。排查时应沿这条链路逐段确认，不能看到网页打不开，就直接判断为服务器失效。浏览器未使用代理和远端握手失败，发生在不同环节。

Project V 是理解这套工具生态的背景，V2Fly 与 Xray 是相关内核家族，v2rayN 等则是面向使用者的图形客户端。它们的名称相近，但职责不相同。阅读教程时，先判断文章讨论的是客户端按钮、内核配置字段，还是服务端部署参数。把内核 JSON 直接当作订阅地址导入，或者把客户端备份交给另一款应用解析，通常不会得到预期结果。

协议、传输与安全设置需要同时匹配

VMess、VLESS 等属于代理协议层面的选择；TCP、WebSocket、gRPC 等涉及承载通信的传输方式；TLS 与 REALITY 则涉及特定安全配置。一个完整连接不只取决于协议名称，还取决于地址、端口、用户标识、传输路径及安全参数是否一致。订阅提供什么参数，就先保留什么参数，不要因为某个选项看起来更新，就单独替换它。

尤其要区分连接地址与服务器名称指示。连接地址决定请求发往哪里，TLS 中的服务器名称用于握手与证书判断，两者在某些部署里可以不同。传输使用的 Host、路径或服务名也各有用途，不能拿备注名称填入这些字段。若服务端要求特定值，漏填与填错都可能造成握手失败；关闭证书验证不是修正地址或名称错误的通用办法。

建立一个可验证的最小目标

初次配置的目标应当足够小：让一个明确遵循系统代理的应用，通过一个已知配置访问一个确定的目标。暂时不启用 TUN，不增加复杂路由，也不同时修改 DNS。只有基础路径成立，后续分流才有比较对象。否则多个设置一起变化，即使偶然恢复连接，也无法判断是哪一步起作用，下一次故障仍然缺少依据。

建议记录当前客户端名称、操作系统、代理入口、所用协议与一次测试结果。记录里不必保存订阅密钥或完整分享链接，重点是复现条件。术语不明确时，可对照术语手册理解后再改设置。完成本章的判断标准，是能说明请求从应用进入内核的方式，以及当前使用的是直连还是远端代理，而不是记住所有协议名。

选择客户端：桌面优先 v2rayN，安卓按内核需求选择

先确定操作系统和处理器架构

桌面端优先选择 v2rayN，适用于 Windows、macOS 与 Linux。下载前先查看系统信息中的处理器架构，再决定安装包，而不是根据文件名里的数字猜测。常见的 x64 对应桌面 Intel 或 AMD 的六十四位环境，arm64 对应相应的 ARM 环境。系统架构与应用包不匹配时，可能无法安装，也可能依赖兼容层运行，后者不适合作为首次配置的默认路径。

Windows 下载区提供桌面版和经典 WPF 版。桌面版采用跨平台界面路线，WPF 版延续经典 Windows 界面；选择时应考虑现有使用习惯和目标系统兼容情况，不要把它们理解成不同的代理协议。两种界面里的菜单位置、配置目录与迁移方式可能不同，已有配置时先备份，再按客户端提供的导入能力迁移，不应直接覆盖整个程序目录。

macOS 按 Apple Silicon 与 Intel 区分安装入口，可在系统的“关于本机”查看芯片或处理器信息。Linux 同时考虑架构与发行版包格式：Debian、Ubuntu 一类通常使用 deb，Fedora 一类通常使用 rpm。包格式表示交给哪套软件包管理机制安装，不代表协议能力高低；不能为了使用某种协议，给系统强行安装另一发行版的包。

安卓两款客户端的选择边界

Android 首推 v2rayNG，使用 Xray 内核；v2flyNG 作为 V2Fly 内核路线的备选。若服务端说明明确依赖某一内核实现，应先核对客户端是否支持对应参数，而不是仅凭协议名判断兼容。相同的分享链接能够被导入，也不表示其中每个扩展字段都已被正确执行，导入后的安全设置和传输字段仍值得检查。

安卓安装包有 arm64 与通用版入口。较新的主流手机通常选择 arm64，但最终仍以设备实际架构为准；无法确认时可查看系统信息，通用版用于覆盖更多架构情况。不要为了比较客户端同时启用两款应用的 VPN 接管：系统通常只允许一个此类连接保持活动，后启动的应用可能替换前一个，使测试结果看起来忽好忽坏。

统一服务参数，不强求统一客户端配置

桌面与安卓之间，最容易共享的是受支持的订阅链接或单条服务器分享链接，最不适合直接照搬的是本地路径、代理入口与路由配置文件。桌面系统代理、安卓 VPN 接口、桌面 TUN 虽然都与流量入口有关，权限模型却不一样。跨设备同步后，应分别验证各设备的入口、DNS 和分流，而不是以某台设备能连接作为全部成功的证明。

下载入口集中在下载中心，选型差异可继续阅读客户端对比。本阶段只确定一款主用客户端和一个安装入口，暂时保留默认内核。若基础连接没有故障，也没有明确的协议兼容需求，不必把切换内核当作常规优化。保持变量少，通常比反复更换工具更容易获得可复查的配置过程。

安装准备：先确认可启动，再调整网络权限

安装前处理目录、进程与旧设置

安装之前先退出正在运行的同类代理程序，确认通知区域或菜单栏里没有旧实例继续接管系统代理。若是更新已有 v2rayN，先在原客户端清除系统代理并退出，再备份配置。不要在程序运行时覆盖文件，也不要把新旧安装目录混在一起使用。这样可以避免“窗口是新的、后台内核仍是旧的”这种难以从表面辨认的情况。

安装位置应当稳定且允许当前用户按客户端要求读写。长期放在临时解压目录、移动磁盘或自动清理目录，容易让配置与规则文件在下次启动时丢失。配置究竟位于程序目录还是用户数据目录，要以当前客户端提供的打开配置目录功能或说明为准，不能假定所有安装方式相同。备份也应针对实际数据位置，而不是只复制一个桌面快捷方式。

首次启动先观察主窗口是否完整出现、日志是否持续报错，以及内核是否能正常启动。此时还没有配置远端服务器，无法访问目标并不能证明安装失败；但缺少运行环境、文件被隔离、配置目录无法写入，则属于本地安装问题。安全软件出现提示时，应核对具体文件和操作原因，不建议直接关闭全部防护来绕过故障。

各平台的权限按需要逐项授予

Windows 日常使用系统代理通常不需要把整个客户端长期以管理员身份运行；需要启用 TUN 或安装相关网络组件时，再按界面提示处理权限。若每次启动都出现不同端口或配置丢失，先检查是否同时运行了普通用户和管理员两个实例。权限提升可能改变进程看到的环境，不能把“提升后能打开”简单等同于问题已经解决。

macOS 遇到开发者验证提示，应从系统“隐私与安全性”相关入口检查被阻止的应用，并在确认来源后按系统提供的流程处理。不要对不明文件批量移除安全限制。系统代理与后续网络接管可能需要不同授权，成功打开窗口并不代表网络权限已经齐全。具体路径可参照macOS 安装与网络权限说明，系统版本不同，文字可能略有差异。

Linux 应优先使用发行版的软件包管理器安装对应 deb 或 rpm，让依赖关系可被管理。若出现缺少组件的提示，先阅读安装器或启动日志，不要连续手动复制不明库文件。图形会话中的系统代理设置未必会传递给所有桌面环境与命令行程序；安装成功只表明程序能够运行，应用是否读取代理仍需在后续阶段分别验证。

建立第一份安装基线

客户端能够启动后，先查看本地监听地址与端口。常见混合监听端口为 10808，但应以当前参数设置为准，旧配置和自定义设置可能改变它。监听地址用于限定谁能访问本地入口，个人单机使用一般保留回环地址；不要为了排查连接就直接开放给局域网。端口已被占用时，应先找出占用进程，确认是否为重复实例，再决定退出或改端口。

本章结束时保留一份“能够启动、没有持续本地报错”的配置作为起点。暂时关闭 TUN 和自动启动，等完整连接验证通过再开启。若内核启动失败，参考从日志定位内核启动错误，按端口、配置语法、字段兼容、规则文件的顺序排查。安装阶段不要叠加远端参数修改，否则本地故障会与网络故障混在同一份日志里。

订阅导入：分清地址、分享链接与配置备份

先判断拿到的内容属于哪一种格式

订阅地址通常是一个可更新的网络地址，客户端访问它后得到一组服务器信息；单条分享链接描述一个服务器连接；客户端配置备份则可能包含分组、路由、界面偏好与本地设置。这三类内容对应不同导入入口。拿到内容后先确认提供方说明，避免把管理网页地址填成订阅地址，或把完整配置文件当成一条服务器链接粘贴。

在 v2rayN 中，先建立订阅分组，填写便于辨认的分组名称，再将地址粘贴到订阅 URL 字段并保存。名称只用于本地管理，不会修正地址内容。粘贴后检查前后空格、换行、引号及字符是否被聊天软件替换。地址中可能包含授权参数，应视作敏感信息保存，不要把完整地址放到公开截图、日志讨论或在线转换页面。

保存分组以后执行更新订阅，观察日志与服务器列表是否发生对应变化。更新完成的提示只表明客户端完成了某一步操作，仍要核对是否确实解析出服务器，以及传输、安全参数是否保留。若分组筛选停留在另一组，新增内容可能并未显示；先切回对应分组或全部列表，不要因为当前列表没有变化就反复删除重建。

更新失败时区分网络与内容问题

若日志显示无法解析订阅域名、连接超时或证书错误，问题首先在获取订阅内容的路径。先确认设备能正常联网、系统时间准确，再判断更新请求是否需要通过已有代理。首次安装时尚无可用代理，依赖代理更新可能形成循环；已有可用配置时，则可以按客户端提供的更新方式选择请求路径，不能只凭按钮名称猜测实际出站。

若请求成功但无法解析，检查返回内容是不是登录页、错误页或另一种客户端格式。某些订阅转换服务会重新生成连接信息，但转换也可能遗漏客户端特有字段。只有确实存在格式不兼容时才考虑转换，并优先使用来源方提供的适配入口。不要为解决解析失败，把带授权参数的原始订阅提交到无法确认数据处理方式的服务。

单条分享链接适合验证一个明确配置。可以先通过剪贴板导入，再逐项核对地址、端口、协议、用户标识、传输和安全设置。二维码只是承载同类文本的一种方式，扫描成功不代表连接参数有效。手动修改订阅生成的条目之前，先确认下次更新是否会覆盖修改；需要长期保留的调整，应放在单独的手动分组并记录原因。

选择活动服务器并保留回退路径

导入完成后还要把目标服务器设为当前活动项，确认主窗口状态与日志中的配置重载结果。列表里存在服务器，不等于当前内核已经使用它。延迟测试、连接测试和网页访问也不是一回事：某种测试通过，只能说明其测试路径成立；真正使用前，仍要用目标应用验证。测试失败时先查看失败环节，不应立即批量更换所有参数。

日常更新前保留一份可用配置，更新后先验证当前活动项，再清理旧条目。不要在唯一可用配置尚未备份时执行全量删除。多设备可以共用受支持的订阅，但应遵守来源方的设备与连接规则，且分别管理本地路由。具体迁移方式可阅读多设备订阅共享与配置导出。本阶段的完成标准是：有一个已确认参数、已经选中且可以独立验证的服务器配置。

代理模式：先检查应用入口，再判断出站策略

系统代理不是全部网络流量的总开关

v2rayN 的系统代理选项通常包括清除系统代理、自动配置系统代理与不改变系统代理。自动配置会把系统相关代理指向客户端的本地监听入口；清除用于撤销相应设置；不改变则保留当前系统状态。它们解决的是应用如何进入代理的问题，并不直接决定某个域名最终直连还是代理，后者仍由路由与出站配置判断。

系统代理主要影响主动读取该设置的应用。有些命令行工具使用环境变量，有些应用具有独立代理设置，还有些程序直接建立连接。因此“浏览器可用、终端不可用”不一定是服务器故障。先检查目标应用是否支持系统代理，再决定使用应用内设置、显式代理参数或 TUN。不要在尚未判断入口差异时，连续更换远端服务器。

浏览器扩展也可能覆盖系统代理。排查时先临时停用代理相关扩展，确认浏览器没有保留独立配置，再使用系统代理进行一次对照。若某个浏览器正常而另一个异常，还要考虑各自的安全 DNS、缓存和扩展行为。测试环境越简单，越容易确定请求是否进入了内核；同时运行多个代理管理工具，会让系统设置被来回覆盖。

用显式代理验证本地监听

若当前混合监听端口确认为 10808，可以使用下面的命令，让一次 HTTPS 请求明确经过本地 HTTP 代理。目标使用保留示例域名，执行时仍需网络可达。命令输出的连接过程可帮助判断失败发生在本地入口、远端连接还是目标响应；不要把一次请求的结果解释成所有应用都已经接管成功。

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

若命令立即提示连接本地端口失败，先检查客户端和内核是否运行、端口是否一致、监听地址是否允许回环连接。若已经进入代理但握手失败，再看服务器参数、系统时间与安全设置。若命令能够返回目标响应而浏览器失败，优先检查浏览器代理入口。Windows 的某些终端中，可明确使用 curl.exe，避免同名命令映射造成参数差异。

显式 SOCKS 请求还要注意解析位置。支持相应参数的 curl 使用 socks5h://127.0.0.1:10808 时，会把域名交给 SOCKS 代理处理；与本地先解析再连接的路径不同。这个区别可用于定位 DNS 问题，但不是所有程序都支持相同写法。应用内若要求分别填写地址与端口，应按界面字段填写，不要把完整代理 URL 填进地址框。

把入口模式与路由模式分开记录

“全局”与“规则”常被用于描述出站策略，而系统代理与 TUN 描述入口方式，两组概念可以组合存在。即使开启 TUN，规则仍可能把部分流量直连；即使只开系统代理，也可以让进入内核的请求统一使用代理。判断配置时，应分别写清“哪些应用进入内核”和“进入后如何出站”，这样才不会被不同客户端的模式名称误导。

退出前清除系统代理，可以避免本地监听已经停止、应用仍向旧端口发请求。若退出后网络异常，先检查系统代理残留，再检查是否还有其他程序设置了代理；不要一开始就重置整个网络。基础连接稳定后再配置自动启动，并确认启动顺序不会让系统先使用代理、内核却尚未就绪。快速操作路径可对照使用指南中的代理模式说明，本章用于判断不同结果背后的原因。

路由分流：规则顺序、匹配对象与 DNS

从一套简单规则开始建立预期

路由的核心是为已经进入内核的请求选择出站。常见出站标签包括 direct、proxy 与 block，分别用于直连、代理和阻断；这些标签最终必须对应实际定义的出站。规则通常按从上到下的顺序检查，匹配后执行对应处理，因此范围很大的规则不能随意放在前面，否则后面的精细规则可能永远没有机会生效。

初次使用可先选择与需求相符的路由预设，再查看其实际规则，而不是立即导入大量规则集合。常见思路是让私有地址直连，让明确需要直连的域名或地址走 direct，其余由兜底策略处理。广告分类阻断是独立选择，并非连接成立的前提；加入阻断后若登录、图片或支付页面异常，需要结合命中记录判断是否误拦了依赖请求。

下面是 Xray 路由对象片段，用于说明匹配顺序，不是可单独启动的完整配置。它假定已定义同名出站，并已准备相应 geosite 与 geoip 数据。最后一条在此片段中覆盖 TCP 与 UDP，承担兜底；实际客户端可能通过预设或其他机制生成默认出站，不能在不理解现有结构时机械追加。

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

域名规则和地址规则不是自动互换

域名匹配需要路由阶段能够获得目标域名；地址匹配则依赖实际目标 IP 或策略允许的解析结果。应用若直接请求某个 IP，域名规则可能无法参与判断。反过来，收到域名请求时，也不是每种域名策略都会立刻解析并检查地址规则。上述示例使用 AsIs，不应期待它为每个域名主动解析地址后再判断地域分类。

geosite 与 geoip 是分类数据，不是在线查询接口，规则能否识别取决于内核支持、文件存在及数据内容。报错指出找不到分类或无法读取文件时，先核对规则数据和配置路径，不能靠改远端服务器修复。分类也可能与实际服务分布不完全一致，因此对特定业务有明确需求时，优先增加范围可解释的域名规则，而不是假定地域分类永远准确。

DNS 会影响请求得到什么地址，也可能影响后续路由匹配。应用自己的加密 DNS、系统解析与内核 DNS 并不必然走同一条路径。修改时先记录当前解析方式，再只改变一处，观察解析是否成功、连接目标是否改变、路由是否符合预期。公共 DNS 地址并不会自动保证可达，更不能仅凭解析成功就认定远端代理连接正常。

按业务验证规则，并限制修改范围

验证时选择一个应直连的目标、一个应代理的目标和一个需要访问的局域网服务，分别观察相关日志与实际结果。页面成功打开只说明请求完成，不能单凭出口查询页推断整个应用的所有连接。一个页面可能访问多个域名，主文档、静态资源和登录接口会分别匹配规则；局部失败时应查看具体目标，不要把整站规则无限放宽。

自定义规则应写清用途，并放在适合的位置。修正某个工作域名时，先用明确域名范围验证，再考虑是否需要扩大匹配。修改后保存、重载并复测同一组目标，保留之前的规则版本以便回退。需要结合术语理解 DNS、域名匹配与出站时，可先查定义；真正的进阶是能够预测一条规则会影响哪些请求，而不是让列表越来越长。

TUN 设置：扩大流量入口，同时检查路由与权限

先判断是否确实需要 TUN

TUN 通过虚拟网络接口与系统路由接收流量，适合不读取系统代理的应用，或需要统一处理多类网络请求的场景。它改变的是流量进入内核的方式，不会修复错误的服务器参数，也不保证所有协议与目标都能成功通信。若系统代理下基础连接尚未成立，应先完成前面的验证，避免把远端连接问题和虚拟网络接口问题叠在一起。

开启前记录当前可用服务器、路由预设、DNS 设置和局域网访问情况，并确认知道关闭入口的位置。远程桌面或远程维护环境尤其需要谨慎：路由变化可能中断当前管理连接。第一次测试宜在能够直接操作设备的情况下进行，先保留原有网络环境，不要同时修改无线网络、网关、订阅和内核。

启用时按客户端要求授予管理员或相应网络权限，观察是否出现接口创建失败、路由写入失败或权限拒绝。具体实现可能随平台和客户端能力不同，不应把某一平台的驱动步骤原样搬到另一平台。界面开关显示开启，还需要结合日志与目标应用验证；开关状态只代表设置意图，不必然代表所有系统操作均已成功。

防止回环，并确认局域网例外

代理内核自身发往远端服务器的连接，不能再次被错误送回同一个入口，否则会形成回环。客户端通常会管理相应路由或排除机制，但自定义系统路由、其他 VPN 与安全软件可能干扰结果。若开启后日志密集重复、所有访问立即失败，先关闭 TUN 恢复基线，再检查冲突程序和自定义设置，不要靠连续重启碰运气。

局域网访问应单独测试，包括路由器管理页、打印机、共享目录和开发服务器。私有地址直连规则有助于定义出站，但某些系统路由、DNS 与应用发现机制还涉及额外路径，不能只添加一条规则就假定所有局域网功能都恢复。先用明确的局域网地址测试，再判断失败属于名字解析、连接路径还是服务本身的访问限制。

DNS 接管也应按当前客户端实现理解。有的设置改变系统 DNS 路径，有的只处理特定请求；应用使用自己的加密解析时，行为还可能不同。出现“地址可以访问、域名不行”时，优先排查解析；出现“域名能解析、连接仍失败”时，再查路由和传输。不要复制不属于当前内核的 DNS 配置字段，字段名称相似也可能表达不同语义。

UDP、休眠与其他网络工具需要单测

应用进入 TUN，不表示远端服务必然支持其全部 UDP 需求。语音、实时通信等场景还受服务端能力、传输方式与本地网络条件影响，应以实际业务验证。不要因为浏览器正常，就把实时应用失败归因于客户端性能。若只有某一类业务异常，先识别它使用的协议、目标与出站，再判断是否需要单独直连或调整兼容配置。

休眠唤醒、切换网络与重新连接无线网络后，再检查 TUN 是否恢复、系统 DNS 是否可用。与企业 VPN、其他虚拟网络工具共存时，双方可能都改写路由，开启顺序也可能影响结果。确认冲突后应选择清晰的接管方案，而不是不断叠加排除项。本章完成标准是：目标应用可用、局域网行为符合预期，并且关闭 TUN 后能够回到原来的可用状态。

日常维护：备份、更新与日志形成闭环

把配置备份与订阅更新分开管理

订阅更新只负责从来源重新获取服务器信息，不能替代客户端整体备份。路由规则、DNS、代理入口、分组偏好和手动条目，可能并不包含在订阅里。建议在基础连接稳定、完成重要规则修改和升级前分别保留备份，并写明系统、客户端类型与用途。备份目录不宜直接公开同步，里面可能包含订阅授权信息、连接标识和其他敏感设置。

恢复时先确认目标客户端支持该备份格式，再选择性恢复必要内容。不同平台的本地文件路径、权限与监听设置不能盲目沿用。若只是迁移服务器，优先使用订阅或受支持的分享链接；若恢复完整客户端状态，则需要额外验证路由和 DNS。恢复成功的提示只代表文件读取完成，实际连接和退出后的网络恢复仍需重新测试。

自动更新订阅可减少手动操作，但失败后不应立即清空现有可用条目。先检查错误原因和当前活动配置是否仍存在，再决定重试或联系来源方核对。手动修改过的订阅条目尤其要注意覆盖行为。对于长期需要保留的特殊参数，记录具体修改项及原因，比只保存一张界面截图更有利于后续迁移和复查。

升级只改变必要变量

升级客户端前退出程序并备份，阅读与目标功能相关的变更说明，尤其关注配置格式、路由数据和权限要求。不要在同一次操作里同时升级客户端、切换内核、更换订阅并重写 DNS。若更新后异常，变量越少越容易定位。确认可回退方式以后再替换旧环境，避免出现新环境不可用、旧配置也已经无法恢复的局面。

升级后使用固定的一组验证目标：系统代理下的浏览器、显式代理请求、需要的局域网服务，以及确实使用的 TUN 应用。测试项目应与升级前一致，不能只看界面能否打开。若只有新加入的功能失败，可以暂时停用该功能并保留基础连接；若基础路径也失败，则应对照日志检查配置兼容与本地运行环境。

开机自启动应在稳定运行后配置，并区分启动图形客户端、启动内核和自动设置系统代理这几件事。Linux 桌面自启动依赖用户会话，相关操作可参照deb/rpm 部署与自启动说明。不要为实现启动而把整套图形应用放进不合适的高权限服务；权限范围与运行会话不匹配，往往会增加配置目录和网络状态的差异。

日志保留上下文，分享前移除敏感内容

读日志先找故障发生时刻附近的第一条相关错误，再看它之前的启动、配置重载或连接记录。后续重复报错可能只是同一个根因的结果。连接拒绝、超时、证书失败和未知字段分别指向不同方向，不能一律归为网络差。排查时记录刚刚执行了什么操作、目标应用是什么，以及系统代理和 TUN 各自处于什么状态。

临时提高日志详细程度有助于定位，但问题确认后应恢复日常级别，避免大量无关记录掩盖重点。对外分享前移除订阅地址、用户标识、完整服务器信息与访问隐私，只保留错误类型和必要上下文。日志中的时间也应与系统时间对应。维护形成闭环的标志是：一次修改有备份、有测试、有结果记录，失败时能按明确步骤回退，而不是只记住某次重启以后恢复了连接。

进阶路线：以问题为单位学习协议与排查

先建立分层排查顺序

进阶并不等于开启更多选项，而是能够把现象归到正确层次。建议固定检查顺序：本地网络是否可用，应用是否进入代理，内核是否启动，服务器参数是否匹配，DNS 是否成功，路由是否命中预期，最后才是目标服务本身。每一步都应寻找一个能支持或排除判断的观察结果，不用未经验证的猜测跳过中间环节。

例如浏览器打不开页面，先用显式代理请求作对照。若本地端口无法连接，回到进程与监听设置；若端口可连接但远端握手失败，核对协议、安全参数与系统时间；若代理请求成功而浏览器失败，检查扩展、独立代理与解析方式。这样同一个“无法连接”现象会被拆成不同分支，不需要每次都重新安装客户端。

单个目标失败时，也要与多个已知目标比较。若所有目标都失败，公共入口或远端连接更值得优先检查；若只有某个域名失败，则重点查看解析、路由、目标服务与访问要求。不要把一个页面的地区提示、账号状态或服务限制，当作底层代理协议故障。连接建立成功与业务允许访问，是两个不同层面的结果。

协议与内核学习围绕实际需求展开

学习 VLESS、VMess 等协议时，先掌握服务端与客户端必须一致的字段，再理解传输层和安全层如何组合。协议名字不能独立决定速度、稳定性或适用场景，具体部署和网络路径同样重要。某种组合在一个网络环境可用，并不表示换到另一个环境仍能得到相同结果，因此应保存实际配置条件，而不是只记录一个协议标签。

切换内核前，核对当前服务器配置、自定义路由与 DNS 字段是否受目标内核支持。客户端的界面抽象可以简化常用操作，但不能保证所有高级字段完全等价。先用最小配置确认基础连接，再逐项恢复自定义内容。若错误提示为未知字段，应按对应内核的配置语义修正，而不是不断尝试更改字段大小写或删除报错行。

需要编辑 JSON 时，先检查括号、逗号、字符串引号与数组结构。JSON 不接受任意注释，也不能在最后一个成员后保留多余逗号。语法通过之后还要检查语义：出站标签是否真实存在，规则引用的数据是否可读，监听端口是否冲突。格式合法只是第一关，能够启动也只是第二关，实际请求按预期处理才算完成。

把专项优化变成可重复实验

研究 DNS、UDP 或特定业务兼容时，每次只设定一个问题，例如“这个应用是否绕过系统代理”或“这个域名是否被直连规则命中”。先记录原始结果，再修改最小相关设置，并用同一目标重复验证。避免把多项所谓优化一次性导入，因为结果改善时无法判断原因，结果变差时也找不到最小回退范围。

测试数据需要理解边界。连接测试只能反映对应方法的结果，不能替代长时间业务使用；某次响应较快，也不代表后续所有请求表现相同。家庭网络、移动网络与公司网络可能有不同的 DNS、代理或路由策略，跨网络比较必须写清条件。不要为追求一个数字，破坏已经满足实际工作需求的稳定配置。

最后整理一份自己的操作记录：如何启动与退出，当前入口和端口是什么，哪些目标需要直连，备份放在哪里，出现问题先看哪段日志。主界面位置不熟悉时，可阅读v2rayN 主窗口功能速览；需要重新建立基础路径时，回到使用指南。完整手册的终点是形成能够解释、验证和恢复的配置，而不是把所有高级功能同时启用。