V2Ray 使用手册：安装与配置

01 / concepts

核心概念：先辨认流量经过哪一层

客户端、内核与服务器

V2Ray 是 Project V 生态中的代理技术体系，不等同于一个桌面应用。v2rayN 提供图形界面，负责管理节点、订阅、路由和启动参数；内核负责监听本地端口、解析请求并建立远程连接。看到客户端窗口正常打开，只能说明界面程序运行，不能据此判断内核已经成功启动。

V2Fly 延续 V2Ray 内核的开发，Xray 属于相关的内核家族，两者支持的具体功能不完全相同。客户端可以保存同一种节点描述，但节点能否运行仍取决于所选内核。涉及 VLESS、REALITY 或特定流控时，应按服务端配置选择兼容内核，不能只凭协议名称推断兼容性。

远程服务器是请求真正离开本地代理链路的另一端。安装客户端不会自动得到服务器地址、认证参数或订阅。节点来源需要自行确认；本手册只介绍软件设置。连接故障可能发生在本地程序、网络路径或服务器任一层，排查时必须把这三者分开，避免把所有问题归因于客户端。

入口、路由与出口

一次常见请求的路径是：应用把请求交给本地 SOCKS 或 HTTP 入口，内核按路由规则选择出口，再由直连出口或代理出口发送。系统代理只影响愿意读取该设置的应用。路由规则处理的是已经进入内核的流量，因此修改路由并不能让原本不使用代理的程序自动进入客户端。

节点列表里的一个条目通常包含服务器地址、远程端口、协议、认证信息、传输方式和安全层参数。本地监听端口属于入口设置，与远程端口不是同一项。把服务器端口填进浏览器的本地代理设置，或者把本地端口写进节点地址，都会把请求送到错误的位置。

“连接”也有不同含义：客户端选中了节点、内核进程存在、到服务器的连接建立、目标网站能返回内容，分别对应不同阶段。测试成功一次不代表所有应用都走代理；一个网站打不开也不代表整个节点失效。先描述失败发生在哪一段，后续检查才有明确方向。

协议、传输与安全层

VMess、VLESS、Trojan、Shadowsocks 描述不同的代理协议；TCP、WebSocket 等描述传输方式；TLS、REALITY 则涉及连接的安全与握手条件。这些选项不是可随意组合的菜单。客户端与服务器必须在必要字段上对应，修改其中一项往往需要另一端同步修改，而不是单方面勾选即可生效。

协议名称也不能直接换算成速度排行。实际表现受到线路、服务器负载、传输开销、目标服务和本地网络影响。选择时先满足兼容性，再比较相同环境下的稳定性。把证书验证关闭或随意更换握手参数，不属于正常的性能优化，应先查清原配置为什么要求这些字段。

02 / clients

选择客户端：先看平台，再看兼容性

桌面优先选择 v2rayN

Windows、macOS、Linux 桌面使用 v2rayN。它把节点管理、订阅更新、本地入口与路由配置集中在图形界面内，适合作为本手册的主要操作对象。跨平台不代表系统行为完全一致：启动权限、系统代理写入方式、虚拟网卡支持和配置存储位置仍由操作系统与安装方式共同决定。

Windows 下载项包含桌面版与经典 WPF 版。桌面版采用跨平台界面，WPF 版保留经典 Windows 界面。初次安装可以从桌面版开始；已有 WPF 使用习惯或配置需求时，再比较当前界面和功能。两版不要同时接管系统代理，也不要在没有备份的情况下共用同一份可写配置目录。

macOS 需要按处理器选择 Apple Silicon 或 Intel 安装包。芯片信息可从系统的“关于本机”查看。Linux 则同时考虑处理器与发行版的软件包格式：常见桌面计算机多为 x64，部分设备为 arm64；deb 与 rpm 是包管理格式，不代表内核协议能力不同，也不能互相改名替代安装。

安卓选择与桌面差异

Android 优先使用 v2rayNG；需要 V2Fly 内核时，可以考虑 v2flyNG。主流较新设备通常选择 arm64 包，无法确认架构时可考虑通用包，但最终仍应以设备实际支持情况为准。不要把安装成功视为全部功能兼容：处理器架构只决定程序能否运行，节点协议和系统限制是另两层检查。

安卓客户端通常通过系统 VPN 服务接管流量，因此启动时会出现系统授权提示。桌面系统代理与安卓 VPN 接管不能按按钮名称直接类比。安卓还要考虑电池优化、后台活动限制以及其他 VPN 应用的占用；桌面则更常遇到监听端口冲突、权限不足和应用忽略系统代理的问题。

桌面与安卓可以导入同一来源的订阅，但两端不一定支持其中每一个字段。若节点在一端运行、另一端失败，先比较解析后的协议、传输、安全层与内核能力，而不是立即认定订阅损坏。订阅内容、客户端设置和系统接管方式应分别检查，跨设备复制不能跳过这一过程。

确定选择后再下载

选择客户端时不必同时安装三款。先用一款建立稳定的基准配置，再在有明确兼容需求时试用另一款。频繁切换程序会增加变量，旧客户端留下的系统代理和后台进程还可能干扰新程序。对需要长期工作的设备，保留可复原的设置比不断更换界面更有帮助。

下载页按四个平台组织安装包入口。打开前先记下系统类型、处理器架构和包格式，下载后再进入安装章节。现有用户迁移客户端时，还应记录本地入口端口、路由选择与订阅分组；这些信息未必包含在普通节点分享链接中，需要单独保存。

03 / installation

安装检查：程序启动与端口监听

完成系统安装流程

Windows 按安装程序提示选择目录并完成安装，首次启动观察界面与日志是否正常。经典界面与桌面界面可能采用不同的配置位置，不应凭目录名称直接覆盖。若程序需要额外运行环境，应依据当前安装提示处理；不要根据旧教程猜测组件名称，也不要同时启动多个实例争用监听端口。

macOS 打开与芯片匹配的磁盘映像，按提示将应用放入应用程序目录。遇到系统安全提示时，先核对安装来源和提示原因，再按系统设置允许打开。不能把永久降低系统安全设置当作通用安装步骤。升级时若旧进程仍运行，先退出旧程序，再启动新应用确认配置读取位置。

Linux 通过发行版的图形软件安装器打开 deb 或 rpm 包，依赖由对应包管理器处理。安装成功后从应用菜单启动，先以普通用户检查界面、配置目录和日志。仅在启用需要额外权限的功能时处理授权；长期把整个图形客户端以高权限运行，会扩大配置文件和网络操作的权限范围。

Android 在系统允许的安装流程中打开安装包，首次启动后先导入节点，再确认 VPN 授权。若提示应用未安装，应检查架构、剩余空间以及是否存在签名不同的旧应用。卸载旧应用前导出必要配置，因为卸载可能删除应用数据；不要把重装作为没有备份时的第一项排错措施。

确认内核与监听地址

客户端界面启动后，先查看日志中的内核启动结果。没有有效节点时，客户端可能尚未启动代理服务；出现错误时先处理日志第一条相关报错，再测试网络。端口占用、配置语法错误和内核不兼容属于不同问题，反复点击连接通常不会改变这些条件，反而会使日志更难辨认。

本地入口应优先监听回环地址，例如 127.0.0.1。它只接受本机请求，适合作为默认设置。“允许来自局域网的连接”会改变可访问范围，还需要防火墙和访问控制配合。不要为了让本机浏览器连接成功就开放到所有网卡；本机连接失败通常与局域网权限无关。

ss -tlnp
ss -tlnp 'sport = :10808'

Linux 的第一条命令列出 TCP 监听情况，第二条只查看示例端口。进程名称可能因权限不足而不完整；仍可先确认地址和端口是否存在。若该端口没有监听，回到客户端查看实际设置与启动日志。若由其他进程占用，先确认进程用途，再修改客户端端口或停止冲突服务。

建立安装后的检查基准

首次检查只启用一种接管方式，不同时开启系统代理和 TUN。先导入有效节点，用明确指定本地代理的工具验证内核，然后再测试系统代理。这样的顺序可以将“程序未监听”与“应用没有使用代理”分开。若直接叠加多个模式，失败时很难判断是哪项设置产生作用。

安装阶段的完成标准是：界面能打开、有效配置能启动内核、本地入口能监听、退出后网络设置可恢复。不要提前追求复杂分流；先保留这个简单基准，之后新增功能才能有可靠的对照。

04 / subscription

订阅导入：分组、更新与节点核对

先区分订阅与分享链接

订阅链接指向可更新的节点集合，节点分享链接通常描述一个节点。复制内容后，先确认来源说明是哪一类，再选择对应导入方式。把订阅地址当作单节点链接解析，或者把单节点分享文本填进订阅地址栏，都可能得到空列表；这不是网络模式切换能解决的问题。

v2rayN 中先打开订阅分组设置，新增分组并填写名称与完整地址，保存后执行该分组的订阅更新。名称可以按用途或来源区分，便于定位更新错误。地址中的查询参数往往参与访问认证，复制时应保留完整内容，避免夹入换行、引号、尾部标点或聊天软件添加的额外空格。

订阅地址可能包含访问凭据，应视为敏感信息保存。公开截图时隐藏完整地址，日志分享前检查是否出现查询参数。订阅能够交付节点配置，但不能证明来源可靠；不清楚用途的订阅、二维码和配置文件，应先确认内容与来源，再导入客户端执行。

更新成功不等于节点可用

更新完成后检查节点条目是否出现、分组是否正确、协议是否符合预期。订阅请求成功仅说明取回了内容，节点仍可能过期、服务端不可达或包含当前内核不支持的字段。先选一个条目作为测试对象，不要同时更改分组、内核、路由和系统接管模式，避免丢失比较基准。

打开节点编辑界面，核对服务器地址、远程端口、认证标识、传输方式及安全层。WebSocket 的路径和主机名、TLS 的服务器名称、REALITY 的公钥等字段不能随意清空。订阅解析后出现缺项时，应回查来源格式与客户端支持情况；不能通过关闭安全检查来补偿缺失参数。

v2rayNG 与 v2flyNG 也应把订阅保存在明确分组中，再执行更新与节点选择。安卓界面的入口名称可能不同，但“保存订阅地址”和“启动代理连接”仍是两个动作。更新列表后应确认当前选择没有指向已被移除的条目，并检查启动日志，而不是只观察列表是否变长。

更新失败的两条网络路径

订阅更新请求可能直连，也可能经当前代理发送。如果本地没有可用节点，优先按来源要求尝试直连更新；已有稳定节点时，可以尝试通过代理更新。两者解决的是请求路径问题，不会修复地址过期、认证失效或服务端返回错误格式。先看日志，再决定是否更换请求方式。

空列表要进一步区分：请求根本失败、返回的是网页而非订阅内容、内容格式不支持，或筛选条件隐藏了全部条目。若返回登录页面，重复导入不会产生有效节点。若只是分组筛选问题，应恢复列表范围。记录具体报错可以减少无意义重试，也便于向来源提供准确反馈。

多设备同步优先共享订阅来源，再分别维护设备特有的系统代理、端口和路由。普通分享链接不会携带全部全局设置。具体取舍可阅读多设备配置同步方案；首次导入的简化操作见快速上手的订阅步骤。

05 / proxy modes

代理模式：接管方式与出口选择

系统代理决定应用怎样进入

系统代理是在操作系统中登记本地 HTTP 或 SOCKS 地址，让遵循该设置的应用使用客户端。它不是把全部网络包自动转入代理。有些浏览器会读取系统设置，有些程序使用自己的网络配置；命令行工具、游戏和后台服务也可能完全忽略它。测试时必须明确应用是否支持该入口。

v2rayN 的设置系统代理、清除系统代理等操作，改变的是操作系统保存的代理状态。设置后应确认本地监听仍在运行，清除后应确认应用没有另存代理配置。部分程序只在启动时读取系统代理，切换后需要重新打开程序；长连接也可能继续沿用原路径，不能只刷新页面判断。

Linux 桌面环境的网络代理设置通常可填写手动代理地址。SOCKS 主机填本机回环地址，端口填客户端对应入口；HTTP 项应填写客户端提供的 HTTP 或兼容混合入口，不能把所有协议都指向任意端口。桌面设置对终端进程是否有效，还要看程序与环境变量的处理方式。

全局与绕过规则决定怎样出去

全局代理通常表示进入内核的目标主要交给代理出口，并不意味着操作系统中所有应用都已被接管。绕过大陆等预设路由则依据域名分类、地址分类和规则顺序，决定哪些请求直连、哪些代理。两类设置作用于不同层，因此“开了全局但某个程序仍直连”并不必然是内核故障。

初次使用可从默认路由开始，确认常见目标能访问，再根据用途调整。浏览与日常办公通常需要兼顾本地服务和远程服务；开发工具可能需要单独配置代理；游戏还涉及 UDP、服务器区域与延迟。不能只根据模式名称挑选，需要知道应用流量是否进入、所选出口是否支持该请求。

安卓的 VPN 接管与桌面系统代理不同。客户端可能提供按应用选择、绕过局域网等选项，但这些仍应与内核路由分开理解。若某个应用被排除在接管范围外，其请求不会再经过内核中的域名分流规则；修改内核路由不能覆盖系统层已经做出的排除决定。

用明确入口验证流量

curl -x socks5h://127.0.0.1:10808 -I https://www.example.com

这条命令明确指定 SOCKS 入口，适合区分代理本身与系统代理设置。socks5h 把目标主机名交给代理端处理；实际端口应换成客户端当前值。收到 HTTP 响应说明这次请求路径能够工作，但具体状态码由目标网站决定，不能把某一个状态码当成全部网络正常的证明。

若命令提示连接本地端口失败，先检查监听地址和端口；若能够连接入口但握手失败，检查节点与日志；若命令成功而浏览器失败，再检查浏览器自己的代理、扩展设置和安全 DNS。按这条顺序排查，可以避免把应用问题误当作服务器故障，也不必一开始就启用 TUN。

完成本章后应能回答两个问题：应用通过什么入口进入客户端，进入后由什么规则选择出口。只有这两个答案都明确，路由分流才有可验证的基础。

06 / routing

路由分流：规则顺序与 DNS 边界

从少量明确规则开始

路由规则负责把请求交给指定出口。常见条件包括域名、目标地址、端口与网络类型。规则通常自上而下匹配，先命中的规则决定出口，因此针对单个目标的例外应放在宽泛规则之前。先写全部目标代理，再在后面补直连例外，往往不会得到预期结果，因为请求已经被前面的规则截获。

域名规则中，full: 用于完整域名匹配，domain: 用于指定域及其子域，geosite: 引用域名分类集合。裸字符串可能按关键词匹配，容易扩大范围；初学者应优先用明确前缀。地址规则中的 CIDR 表示网络段，分类集合则依赖本机资源文件，不是即时查询服务。

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

这是配置片段，不是完整可启动配置。使用时必须确认当前内核存在名为 proxy 与 direct 的出口，并具有对应分类资源。v2rayN 的图形路由界面会生成内核配置，添加规则时应映射到界面已有出口，不要直接覆盖客户端生成的文件，否则重启或切换节点可能重写修改。

DNS 设置：先明确谁解析域名

DNS 将域名转换成地址，但解析可能发生在应用、操作系统、内核或代理链路另一端。浏览器的安全 DNS、自带解析库和系统解析设置可能各自独立。把内核 DNS 改成某个服务器，不保证全部应用都立即采用；若应用已经把域名解析成地址，域名路由可能拿不到原始名称。

AsIs 表示路由阶段不主动为了地址匹配解析域名；其他域名策略可能在需要时触发解析。内核 DNS 配置、路由域名策略以及出口的解析行为是关联但不同的设置。不要把地址规则未命中简单归因于 DNS 服务器故障，应先确认请求携带的是域名还是地址，以及当前策略是否进行转换。

排查时比较同一目标在应用直连、明确 SOCKS 入口和系统代理下的结果。若只有浏览器异常，检查浏览器解析与缓存；若日志显示解析超时，检查 DNS 请求的路由与可达性。不要长期用硬编码目标地址绕过解析，这会受到地址变化、证书名称和内容分发调度的影响。

规则验证与冲突处理

修改路由前保存原规则，新规则只处理一个可复现目标。测试时观察访问日志中的目标与出口，不要仅凭网页能打开判断命中；直连与代理都可能成功。若日志没有请求，返回上一章检查接管方式。若出口不符，检查前序规则、分类资源和目标形式，再调整规则位置。

多个条件写在同一规则里时，通常需要同时满足这些条件；同一字段中的多个候选值通常属于任选匹配。把域名与地址同时填入可能比预期更严格。需要“命中域名或命中地址”的行为时，分成两条规则更清楚，也便于单独验证失败发生在哪一类条件。

07 / tun

TUN 模式：扩展接管范围与保留恢复路径

什么时候需要虚拟网卡

TUN 通过虚拟网络设备接收网络流量，适合无法配置显式代理、忽略系统代理或需要处理更广流量范围的应用。它改变的是进入代理链路的方式，并不会让失效节点重新可用。如果明确 SOCKS 测试已经失败，先修复节点与内核；否则启用 TUN 只会把同一个故障扩大到更多应用。

TUN 的实际行为由客户端实现、所用内核、网络栈与操作系统权限共同决定。看到“启用 TUN 模式”选项，不代表当前环境已经具备全部条件。客户端可能使用配套组件处理虚拟网卡、路由和 DNS，应按当前日志确认实际启动结果，而不是把所有桌面平台视为相同实现。

启用之前，记录正在使用的节点、系统代理状态和默认路由，确认关闭功能的入口仍然可达。远程管理设备时尤其要谨慎：路由变化可能中断当前会话。先在本地可操作环境中验证，再用于需要持续连接的设备，并保留无需依赖代理网络就能执行的恢复方法。

权限、路由与回环

虚拟设备和路由修改可能需要管理员授权。Linux 上还要检查系统提供的 TUN 设备与相关权限；macOS 和 Windows 则可能出现系统授权或组件安装提示。遇到权限错误，先根据日志定位失败步骤，不要递归更改整个配置目录权限，也不要把所有程序改为高权限运行来掩盖问题。

代理自身连接服务器的流量必须能够离开虚拟设备，否则可能出现流量回环：内核发出的连接再次被接管，无法到达远端。自动路由和排除机制通常会处理这一问题，但与其他 VPN、虚拟网卡或自定义路由叠加时可能冲突。测试前先停用其他接管程序，建立单一链路。

局域网访问也要单独检查。打印机、文件共享、开发服务和路由器管理页面可能需要保留本地路径。绕过局域网不是把所有未知地址都设为直连，而是合理处理本地地址段与相关名称。若远程网站正常而本地服务失败，应检查本地路由与 DNS，不必立即更换节点。

分层验证，而不是一次全开

先保持已验证的节点与简单路由，清除不必要的系统代理后再启用 TUN，观察启动日志。然后依次测试浏览器、原本不遵循系统代理的应用和局域网服务。这样可以判断接管范围是否真的扩大。若同时更改 DNS 与分流，很难知道问题来自虚拟设备还是新规则。

UDP 需要整条链路支持，包括应用流量进入方式、内核处理与服务端能力。启用 TUN 不等于所有 UDP 请求都会成功，也不保证游戏体验更好。某些应用还涉及独立认证服务、语音服务或固定网络接口；应针对失败功能观察日志，而不是只测一个网页后宣布全部协议可用。

休眠唤醒、切换无线网络或连接有线网络后，应再次检查虚拟设备和默认路由。网络接口变化可能让旧状态失效，重新启动接管服务比盲目修改节点更合理。若频繁出现同类问题，保存发生前后的接口、路由与日志信息，形成可复现记录后再决定是否长期使用 TUN。

08 / maintenance

日常维护：更新、备份与故障记录

分开维护三个更新对象

客户端程序、订阅内容与路由分类资源是三个不同对象。客户端更新改变界面和功能实现；订阅更新改变节点集合；分类资源更新影响域名或地址规则。不要把它们安排在一次故障排查中同时变更。每次完成一类更新后先测试已有基准，确认结果，再继续下一项。

更新客户端前阅读与自身使用功能相关的变更说明，确认所需内核和配置格式是否仍适用。无需为了版本数字频繁重装，但也不能忽略涉及兼容性或安全修复的更新。升级后重点检查节点启动、订阅解析、路由选择和系统接管，不要只验证程序窗口能打开。

订阅更新频率应依据来源实际变化决定。过于频繁地请求不会修复认证失效，还可能触发服务端限制。更新后若原节点消失，先确认是否属于正常替换，再选择新条目。分类资源更新后若特定目标出口变化，检查命中分类与例外规则，而不是直接把所有目标改成全局代理。

备份要能真正恢复

备份至少包含订阅分组、手动节点、路由规则和关键全局设置。优先使用客户端提供的导出方式；复制配置目录前退出程序，避免数据库或配置文件正在写入。不同平台的路径与存储方式可能不同，不能根据另一个系统的目录直接推断，应先确认当前程序实际使用的位置。

配置备份可能含服务器认证信息、订阅访问凭据与设备相关设置，宜保存在访问受控的位置。用于讨论问题的截图或日志应另做脱敏副本，不要直接公开原始备份。需要迁移时先在新设备导入，再手动核对监听地址、端口、权限与接管方式，避免把旧设备环境设置机械照搬。

恢复能力应通过一次小范围测试确认。可先导出配置，记录几个关键设置，再在独立测试环境导入核对。只有文件存在而没有验证导入结果，不能说明备份可用。跨平台恢复尤其要注意不兼容的路径、程序启动项和权限字段；节点数据可以复用，系统集成设置常需重新建立。

按链路顺序处理故障

出现连接问题时，先检查系统时间与基础网络，再看本地入口、内核日志、节点连接、DNS 和路由。系统时间明显偏差可能影响握手或认证。若基础网络本身不可用，应先恢复网络；若本地端口不存在，应先处理内核启动，不能跳到远程服务器或规则分类上猜测。

记录故障时写清发生时间、客户端类型、所用内核、接管方式、失败目标与错误原文。只说“打不开”难以区分连接超时、解析失败、证书错误和应用自身报错。日志应截取问题前后的相关部分，保留顺序但隐藏敏感字段；提高日志级别只用于短时诊断，完成后恢复常规级别。

维护阶段还应检查长期遗留设置：已不用的订阅、重复节点、临时规则和旧启动项都应有明确用途。删除前保留备份，清理后重新验证。减少不明来源的配置叠加，可以让未来故障更容易定位，也能防止旧程序在后台恢复不再需要的系统代理状态。

09 / next steps

进阶路线：从可用配置到可解释配置

先读生成配置，再尝试自定义

进阶的起点不是增加更多开关，而是能解释已有配置。先找到客户端提供的配置查看或日志入口，辨认入站、出站、路由和 DNS 的对应关系。图形界面的一个选择可能生成多个内核字段；理解这层映射，可以解释为什么修改界面后行为变化，也能避免把临时生成文件当成永久配置来源。

需要使用自定义配置时，先确认客户端如何加载它，以及哪些图形设置仍会生效。自定义文件可能绕开部分界面生成逻辑，界面显示的路由模式不一定代表文件中的实际路由。使用完整自定义配置之后，应以最终加载文件与运行日志为依据，而不是继续依赖图形选项的直觉解释。

JSON 文件的语法检查只是第一步。括号、逗号和字符串正确，不代表内核支持字段，也不代表出口标签能够对应。检查时先验证结构，再验证内核兼容性，最后验证网络行为。任何新增功能都应附带明确测试目标，不能因为程序启动没有报错，就认定所有分支都已工作。

按任务设计实验

想让开发工具走代理，先阅读工具自己的代理支持，再决定使用系统代理、显式入口还是 TUN。想让某个域名直连，先确认请求携带域名，再添加单独例外。想解决解析差异，先比较应用与内核的解析路径。把问题限定为一个任务，通常比导入庞大的未知配置更容易得到稳定结果。

实验前写下预期：哪个应用、哪个目标、哪个入口、哪个出口。实验后用日志核对结果，失败时恢复上一份可用配置。这样形成的记录能够在升级或迁移后再次验证，也能区分“配置意图”与“实际行为”。不要依赖测试网站显示的单一信息来推断整台设备所有应用的流量路径。

性能比较也需要控制变量。保持设备、网络、目标服务和测试时段尽量一致，分别观察建立连接、持续传输与长时间稳定性。某一次下载速度不能概括节点全部表现；服务端限制和目标拥塞都会影响结果。不要编造延迟或以协议名称直接排序，应记录可重复观察到的现象。

协议学习与安全边界

进一步学习 VLESS、REALITY 与 XTLS Vision 时，先补齐 TLS 握手、身份认证与传输层基础。REALITY 涉及客户端与服务器约定的握手参数，Vision 涉及特定流控处理；它们不是独立的提速按钮。节点来源提供的字段应成组核对，缺少必要参数时先确认配置要求，不要凭教程猜值。

可以阅读REALITY 与 XTLS Vision 原理说明理解技术背景，再返回客户端确认所用内核支持情况。技术科普负责解释机制，实际连接仍以服务端设置为准。学习过程中不必改动正在工作的主配置，可保留单独实验条目，避免影响日常使用。

代理并不会替代应用自身的安全机制。网站身份、账号授权、文件来源和终端权限仍需分别处理。允许局域网连接、开放本地入口或导入陌生自定义配置，都应先明确访问范围和执行效果。对外分享经验时只展示必要的结构与脱敏信息，不应附上可直接访问个人服务的凭据。

保留一份简单可用配置作为基线，再逐项增加必要功能。每项设置都有用途、验证方法和撤销步骤，才算形成可维护的配置；不需要把所有进阶功能同时启用。