V2Ray 配置手册
从安装到路由分流

核心概念：界面、内核与连接链路

图形客户端与代理内核分别负责什么

V2Ray 是 Project V 代理生态中的核心项目。日常操作接触的 v2rayN、v2rayNG 和 v2flyNG 则是图形客户端，负责管理服务器、订阅、路由和启动选项。实际处理连接的是内核。V2Fly 与 Xray 属于相关的内核家族，但功能演进和配置支持并不完全相同。界面出现某个协议选项，不代表任意内核都能运行对应配置；判断兼容性要同时检查客户端、内核和服务端要求。

一条常见链路可以理解为：应用发起请求，流量进入本地代理入口，内核根据规则选择直连、代理或阻断，再建立后续连接。图形界面的“启动”只说明客户端尝试运行内核；服务器被选中只说明默认代理出口已经指定。能否真正访问目标，还取决于应用是否使用该入口、域名能否解析、服务端参数是否正确，以及目标服务是否接受连接。排错时需要沿这条链路分层验证。

协议、安全层与传输方式不要混为一谈

VMess、VLESS、Trojan 和 Shadowsocks 是不同的代理协议。TCP、WebSocket、gRPC 等描述传输方式；TLS 和 REALITY 涉及连接安全机制。分享链接会把这些层的参数组合在一起，因此不能只凭协议名称手动重建节点。相同的 VLESS 配置，传输方式、安全设置或服务名称不同，也可能完全无法互通。服务端提供什么组合，客户端就应按相同组合导入，而不是把常见选项逐个试开。

尤其要区分服务器地址、TLS 服务器名称和 HTTP Host。服务器地址用于找到连接入口；服务器名称通常参与 TLS 握手与证书验证；Host 则可能用于应用层转发。它们可以相同，也可能由服务端设计成不同值。REALITY 还可能涉及公钥、短标识等参数，这些值具有明确配对关系，不能拿其他配置的内容补齐。缺少字段时应回到配置来源确认，而不是关闭验证绕过错误。

订阅、分享链接与本地配置的关系

分享链接一般描述一个服务器配置，订阅地址则是可被客户端定期获取的配置集合。订阅不等于代理通道，也不等于账户本身。导入成功表示客户端读懂了内容，不表示其中所有连接都可用。某些订阅面向特定客户端或配置格式，不能因为浏览器能打开就认定能直接导入。完整配置文件还可能包含入口、DNS 和路由，覆盖范围大于单条分享链接，导入前应看清操作对象。

后续章节始终遵循同一个判断顺序：先确认配置内容，再确认内核启动，然后验证应用接入，最后检查路由出口。每次只调整一个层次，保留修改前的可用状态。这样遇到连接失败时，能够明确是导入格式、连接参数还是本地接管方式出了问题。协议名称、订阅名称和客户端名称只是不同维度的标签，不能直接用于推断速度、稳定性或服务质量。

选择客户端：桌面与 Android 的分工

桌面首选 v2rayN，移动端按内核需求选择

Windows、macOS 和 Linux 桌面环境优先选择 v2rayN。它把服务器管理、订阅更新、路由选择和核心设置放在图形界面中，适合需要查看连接状态、维护多组配置或调整分流的用户。Windows 下载区提供桌面版与经典 WPF 版：前者采用跨平台界面，后者采用经典界面。两者不是速度等级，也不能仅凭界面新旧判断协议能力；实际支持仍以所带内核和发布说明为准。

Android 首推 v2rayNG，使用 Xray 内核；v2flyNG 是采用 V2Fly 内核的备选。选择依据应是已有配置要求、设备兼容情况和需要的内核能力，而不是在同一设备上同时启动两个客户端。Android 的 VPN 接管通常只能由一个活动服务承担，另一款 VPN、工作配置或安全工具可能与之竞争。需要比较时应先停止原服务，再启动待测客户端，保持相同网络和同一服务器配置。

架构与安装格式决定包能否运行

处理器架构必须与安装包匹配。macOS 可在系统“关于本机”查看芯片，Apple Silicon 选择 arm64，Intel 选择 x64。Linux 还要区分软件包体系：通常 Debian、Ubuntu 系使用 deb，Fedora 等使用 rpm；仅扩展名相同仍不足以保证依赖完全兼容。Windows 本站列出的入口为 x64，不能把它当作任何处理器都通用的安装包。遇到架构不匹配应重新选择，而不是反复尝试启动。

Android 主流较新设备通常可优先考虑 arm64；如果系统实际上运行其他 ABI，需使用兼容包。通用版包含更多架构内容，适合架构不确定时选择，但不会因为包更大就获得更好的连接表现。设备生产时间只能作为粗略参考，准确判断应看系统或设备提供的架构信息。安装程序提示不兼容时，先检查系统要求、ABI 和剩余空间，再考虑是否存在旧签名冲突。

按实际任务建立选择标准

如果目标是在电脑与手机上共用一份订阅，重点是两端都支持订阅格式和服务器所需协议，不是要求客户端名称一致。分享链接可以传递连接参数，但桌面系统代理和 Android 应用分流属于本地设置，通常需要分别配置。若服务端明确要求 REALITY，应确认对应内核及客户端的字段支持；不要把“支持 VLESS”当成对所有 VLESS 组合的承诺。协议的具体比较可继续阅读协议对比文章。

正式安装前先到客户端下载页核对平台与入口，再用客户端对比确认使用边界。保留一种主用客户端即可，把另一种作为需要时的验证工具。评价体验时，应使用相同服务器、网络与目标地址；不同协议配置之间的差异可能来自远端条件，不一定来自客户端。完成选择后记下安装包类型，后续升级沿同一分支进行，更容易保持配置目录、运行方式与迁移步骤一致。

安装与初始化：先建立可运行的本地环境

安装前检查权限、路径与旧配置

安装前先关闭已经运行的同类客户端，确认下载包与系统、架构相符。如果之前使用过便携目录或其他安装分支，先备份设置，不要直接把新旧文件混在同一目录。安装目录和用户配置目录可能不同，删除程序文件并不总会清除设置。遇到“重装仍保持原配置”并不异常，应通过客户端提供的配置位置或系统应用目录确认数据来源，避免误删其他软件的内容。

Windows 安装后首次启动，先观察主窗口是否正常出现，再查看运行日志。便携形式应放在用户可读写的稳定目录，避免从压缩包预览中直接运行，也不要放入会被自动清理的临时路径。普通系统代理操作通常不需要一直以管理员身份运行；TUN 或相关服务可能另需提升权限。若安全软件提示某个文件被隔离，应先核对来源和具体检测信息，不要直接关闭整套系统防护。

按平台完成首次启动

macOS 安装时按下载页说明选择芯片对应的包，并将应用放到稳定位置后运行。系统如果阻止打开，应阅读“隐私与安全性”中的具体原因，按系统提供的授权流程处理，不建议用宽泛的命令取消所有应用的安全检查。首次请求网络或辅助组件权限时，确认申请者就是当前客户端。若启动后没有窗口，还应查看菜单栏或程序坞状态，区分后台运行、窗口隐藏与真正退出。

Linux 使用发行版支持的软件包管理方式安装 deb 或 rpm，先处理管理器报告的依赖问题，再启动图形界面。桌面会话的系统代理支持与具体桌面环境有关，不能把“客户端成功设置”理解为每个应用都已接入。Android 安装后先打开主界面，再导入配置；首次启动代理通常需要确认 VPN 授权。授权窗口表示系统允许创建本地接管服务，不是订阅已验证或远端已连接的证明。

先检查入口，再检查服务器

初次运行先保持 TUN 关闭，并暂时关闭其他代理工具。查看设置中的本地监听地址、端口与入口类型，确认是 HTTP、SOCKS 还是混合入口。本地端口没有必须沿用的统一值，示例中的端口也不应覆盖实际设置。如果日志提示地址已被占用，优先退出残留实例或更换监听端口。改变端口后，手动配置代理的应用也要同步更新，否则请求仍会发往旧入口。

监听地址建议先保留回环范围，仅供本机使用。“允许局域网连接”会扩大入口可访问范围，与共享文件并不是同一件事；确有需求时还应限制防火墙来源并设置必要的访问控制。首次测试不需要开放局域网，也不需要开启所有高级选项。此时可以没有服务器，但界面、配置保存和日志窗口都应正常工作。核心无法启动时先处理路径、权限和依赖，订阅更新不会修复本地运行环境。

建议记录一份简短基线：系统类型、客户端分支、配置存放位置、监听入口和当前权限方式。记录不必包含账号、订阅地址或服务器凭据。后续升级或迁移时，这些信息能够帮助区分“程序无法启动”和“代理链路不通”。安装完成不等于完成配置；只有保持环境稳定，后面的每次调整才有可比较的起点。具体按钮顺序可对照快速上手教程操作。

订阅导入：分组、更新与参数核对

先确定导入的是地址还是分享链接

订阅地址通常是可通过网络获取配置的链接，分享链接则常以 vmess://、vless://、trojan:// 或 ss:// 开头。复制前先确认来源提供的是哪一种。不要把订阅管理页的网址当作订阅地址，也不要把登录页面的内容当作服务器集合。地址包含账户标识或访问参数时应视为敏感信息，避免贴到公开评论、截图或聊天群中。

在 v2rayN 中先进入订阅分组管理，新建一个便于辨认的分组，再填写订阅地址并保存。随后执行该分组的订阅更新，观察结果和服务器列表，而不是反复点击导入。v2rayNG 可通过订阅设置添加地址，再从相应菜单更新订阅；不同界面版本名称可能略有差别，核心顺序都是“保存来源，再获取内容”。单条分享链接则通过剪贴板导入，不必为了一个服务器额外创建网络订阅。

导入后核对真正影响连接的字段

列表出现服务器后，先选择一个配置查看编辑项。重点核对地址、端口、用户标识或密码、协议、传输方式与安全设置。使用 WebSocket 时注意路径和 Host；使用 gRPC 时注意服务名称；使用 TLS 时核对服务器名称与证书验证选项；使用 REALITY 时核对公钥、短标识和所需指纹等字段。字段是否必须填写取决于服务端配置，不能看到空项就随意补一个常见值。

导入过程中若出现“不支持的格式”，先检查复制内容是否带入说明文字、首尾空白或被聊天工具截断。订阅返回登录页、错误提示或其他客户端专用格式，也可能导致解析失败。把页面能打开与配置能解析分开判断。需要格式转换时，优先使用可信且明确说明兼容范围的方式；转换服务可能接触完整订阅内容，不能把敏感地址随意提交给不明来源的网站。

订阅更新失败不等于服务器全部失效

更新订阅是一条独立的 HTTP 请求链路，可能受到 DNS、证书、网络状态或访问授权影响。如果现有服务器仍可连接，先保留它们，再查看订阅更新日志。部分客户端允许选择通过代理更新，适合直连无法访问订阅来源而已有代理可用的场景；但空白安装首次导入时，没有可用出口就不能依赖这个选项解决所有问题。还应检查设备时间，时间偏差可能影响安全连接。

更新前最好了解该分组的替换策略。由订阅生成的条目可能在下次更新时被重建，手动改过的名称、参数或排序未必保留。需要临时修改时，可以复制到独立手动分组，并明确标注用途，不要让试验条目混入主用列表。删除订阅来源和删除已经导入的服务器可能是不同操作，清理前应看清确认提示。分组按来源或用途组织，比依赖服务器名称中的符号更便于维护。

完成导入后，只选一个参数明确的服务器作为基线，暂不批量切换。确认分组、当前选中项和更新时间来源，再进入下一章验证应用接入。电脑和 Android 之间可以复用兼容的订阅来源，但本地路由、应用名单和权限仍需分别检查；迁移方式见多设备配置同步文章。不要把“订阅更新成功”当作整条代理链路已经验证。

代理模式：应用接入与出口选择分开设置

系统代理只解决一部分应用的接入

桌面系统代理告诉遵循系统设置的应用，应把请求交给哪个本地代理入口。浏览器通常会读取系统设置，但命令行工具、游戏和部分桌面程序可能使用自己的连接方式。因此，开启系统代理后某个应用仍直连，并不能直接说明节点失效。先查看该应用是否支持系统代理，是否设置了独立代理或绕过列表，再决定使用应用内配置还是后续章节的 TUN 接管。

v2rayN 常见的系统代理选项包括清除、自动配置和不改变系统代理。“清除”会移除相关系统代理设置；“自动配置”会把支持的系统代理指向本地入口；“不改变”表示客户端不主动修改当前系统设置，并不保证系统现在没有代理。若此前其他程序已写入代理地址，这个地址可能仍然保留。退出客户端后网页突然打不开时，应检查系统是否还指向一个已经停止的本地端口。

全局与绕过规则决定接入后的出口

路由模式是另一层设置。常见的全局代理通常把进入内核的流量交给代理出口；绕过大陆等预设则依据域名和地址分类选择直连或代理。这里的“全局”不是对操作系统所有进程的保证：没有进入内核的流量不会凭空被规则捕获。系统代理负责“是否进来”，路由负责“进来以后去哪”，两者组合才决定最终行为。预设的具体规则还应查看客户端提供的列表。

直连也不等于关闭客户端。某条规则选择直连时，流量可能已经进入内核，只是在出站阶段由本机直接连接目标。阻断则是明确拒绝匹配请求，与连接超时不是同一种结果。排查时可以临时使用较简单的路由模式比较行为，但测试完成应恢复原设置，避免把临时全局模式当成长期修复。如果全局可用而分流不可用，优先检查规则和 DNS，而不是重新导入同一份订阅。

用一次可重复测试确认接入情况

验证时先保持 TUN 关闭，启动内核并启用系统代理，使用一个明确遵循系统设置的浏览器访问已知目标。再查看日志或连接信息中是否出现对应目标。浏览器复用旧连接、缓存或自身安全 DNS 设置可能影响观察，应新建连接或重启应用后对比。如果需要指定本地 HTTP 入口测试，可以使用下面的命令，但必须把端口改成客户端实际监听的端口，且确认该入口支持 HTTP 代理。

curl --proxy http://127.0.0.1:10809 --head https://example.com/

这条命令只验证指定入口到目标的请求，不会修改系统代理；示例端口不是客户端统一默认值。若返回代理连接被拒绝，先检查本地监听；若已经连接代理但后续超时，再检查服务器、DNS 与远端访问。目标本身可能对 HEAD 请求有特殊响应，收到 HTTP 错误状态也不一定表示代理失败，需要结合连接过程判断。没有命令行工具时，用应用自身的代理设置也能完成同类对照。

Android 的常规启动会通过系统 VPN 接口接入流量，另有按应用代理、绕过局域网等选项影响覆盖范围。不要把桌面的系统代理三态机械套到 Android。若仅部分应用异常，先检查应用是否在代理范围、是否被系统限制后台运行，以及是否存在其他 VPN 服务竞争。模式的进一步辨析见系统代理与路由模式区别；先形成可重复结果，再调整精细分流。

路由分流：规则顺序、DNS 与出口标签

先理解匹配顺序，再添加规则

路由规则通常按顺序检查，先匹配的规则决定出口，未命中的连接再走默认策略。具体字段组合与匹配行为要以内核说明为准，不宜把列表当成简单标签集合。一个范围较大的代理规则放在前面，可能让后面的精细直连规则永远没有机会命中。开始时保留简短规则集：必要的局域网处理、明确域名例外、地域规则和默认出口，逐条验证后再扩展。

域名规则和 IP 规则依赖不同信息。客户端知道原始域名时可以直接进行域名匹配；只收到目标 IP 时，域名规则可能没有足够信息。DNS 解析结果又会影响 IP 分类，因此 DNS 与路由必须作为一套逻辑检查。不要仅因为某个网站显示中文就把它归入直连类别，网站的域名、内容分发网络与服务器地域并不存在固定对应。地域规则是维护数据集，不是实时测量。

配置片段要放入正确层级

下面是 Xray 路由对象的教学片段，不是完整可启动配置。它展示私有地址直连、指定域名直连以及地域规则的顺序。使用前必须确认当前配置有名为 direct 的出站，且已安装相应 geosite、geoip 数据文件。图形客户端若提供规则编辑界面，应优先通过界面添加，避免修改运行时自动生成的配置。没有默认出站的完整上下文时，不能仅凭这个片段推断所有流量走向。

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

geosite:cn → direct 表示将对应域名集合匹配到直连出站；geoip:cn 则针对地址集合。domain:example.com 是域名后缀类匹配，通常覆盖该域及子域，不能当成任意位置的字符串包含判断。AsIs 不为路由匹配主动把域名解析为 IP，因此某些以域名进入的请求不会仅凭地域 IP 规则改变出口。选择其他解析策略前，应先明确其触发条件和查询成本。

嗅探、DNS 与例外规则的边界

流量嗅探可以在特定协议中辅助恢复域名信息，但并不保证识别每个请求，也不是绕过应用加密的通用办法。应用使用自己的 DNS、加密 DNS 或直接连接 IP 时，路由可见的信息可能不同。调整嗅探或 DNS 后，应观察同一目标的规则命中变化，不能只看网页是否打开。若客户端有连接详情，优先核对实际目标、匹配规则和出口；普通日志级别未必记录全部信息。

需要增加例外时，优先写最小范围的域名或地址，并放在合适位置。整段地址直连可能覆盖无关服务，整类域名代理也可能改变局域网资源访问。配置修改后保存、应用并重新建立连接，已有连接未必立即重新匹配。分流失败时先撤销最后一条规则，再核对数据文件是否存在、标签是否准确、域名是否带入协议或路径。规则字段中通常填写域名本身，不填写完整网页地址。

TUN 模式：扩大接管范围与控制回环

什么时候需要 TUN

TUN 通过虚拟网络接口接入 IP 流量，适合不读取系统代理或不便单独设置代理的应用。它改变的是流量进入客户端的方式，不会自动修复错误的服务器参数，也不会让服务端突然支持新的协议。普通浏览器与支持代理的开发工具已经工作正常时，可以先保留系统代理方案。只有明确遇到应用接入覆盖问题，再引入 TUN，排错范围会小得多。

桌面 TUN 常涉及虚拟接口、路由表、DNS 接管和较高权限，具体由客户端与所选核心实现。v2rayN 的图形界面可能协调不同核心或辅助组件，不能把 TUN 设置理解为所有 Xray 配置都通用的一个字段。切换核心前应确认当前服务器、安全机制、路由与 DNS 都被新核心支持。配置能导入与运行时语义相同不是一回事，尤其不能直接交换不同内核体系的原始配置文件。

分阶段开启，而不是一次打开所有选项

开启前先通过系统代理或应用显式代理确认同一服务器可用，然后备份设置，关闭其他 VPN 与流量接管工具。按客户端提示完成必要的服务安装或权限授权，再开启 TUN。首次使用保留建议的栈和自动路由设置，不要同时修改 MTU、DNS 地址与应用排除项。若界面报告创建接口失败，先检查权限、残留进程和驱动状态，而不是更换订阅或批量测试服务器。

TUN 与系统代理可以在部分方案中同时工作，但排错时建议减少重叠，避免不知道请求究竟走哪条入口。开启后先验证普通网页，再测试原本不读取代理的目标应用，最后检查局域网设备和内部服务。某个应用可用并不意味着 UDP、IPv6 和所有 DNS 请求都已按预期处理；这些能力需要客户端、核心、服务端和网络路径共同支持。涉及语音或游戏时应单独验证实际功能。

DNS、回环与局域网例外

接管 DNS 时，需要保证解析请求能到达其上游，并且到上游的连接不会反复被自己捕获。代理客户端连接服务器本身的流量同样需要正确排除或绑定出站接口，否则可能形成回环，表现为启动后连接堆积、CPU 异常或网络全面失效。此时应先关闭 TUN 恢复基线，查看自动路由与出口排除设置，不要通过不断添加随机直连规则掩盖问题。

局域网打印机、共享目录、路由器管理页和企业内部地址可能需要明确绕过，但私有地址直连也应结合使用环境判断。企业网络可能通过特定 VPN 提供内部路由，简单绕过并不保证可达。IPv6 是否接管也要单独检查：只观察 IPv4 成功，无法证明另一地址族的走向。若出现部分网站异常，先比较域名解析结果和地址族，再排查 MTU 或路径问题，不宜直接把所有异常归因于 DNS。

关闭 TUN 后应检查正常直连、局域网和休眠唤醒后的网络状态。客户端异常退出可能留下服务或系统设置，优先用其正常停止流程恢复，必要时再按系统网络管理方式处理。Android 常规 VPN 接入与桌面 TUN 的权限和路由机制不同，不应照抄桌面的驱动、服务或接口步骤。达到“目标应用被接管、内部资源可达、停止后网络恢复”这三个条件，才适合把 TUN 纳入日常使用。

日常维护：日志、测速、升级与备份

把故障定位到一个层次

网络异常时先记录发生时间、网络环境、目标应用与最后一次改动。确认客户端仍在运行、核心没有退出、本地入口未冲突，然后检查当前服务器和路由。日志中的 connection refused 通常表示某一连接目标拒绝建立连接，但目标可能是本地入口也可能是远端，必须结合地址判断。i/o timeout 说明等待超时，不足以单独证明账号失效、服务器宕机或 DNS 故障。

出现握手失败时，按协议参数、安全设置、设备时间与服务端要求检查。日志中的一条错误可能属于后台探测或已经关闭的旧连接，不能脱离对应目标解释。排错期间可以临时提高日志级别，重现一次问题后再恢复常规级别，避免日志持续增长。分享日志前去除服务器地址、用户标识、订阅参数和请求中的个人信息；进一步定位可参考运行日志解读。

测速结果要对应实际问题

TCPing 主要反映到目标端口建立连接的情况，不等于完成代理认证与目标访问。真连接延迟会走更完整的代理请求链路，但仍受到测试地址、DNS、握手和当时网络负载影响。下载测速观察吞吐，消耗实际流量，也不能代表所有目标和应用的表现。不同方式的结果不能放在同一标准下排序，单次失败也不宜直接删除配置，应先确认测试条件是否一致。

比较时固定设备、网络、测试目标和代理模式，避免一边更新订阅一边批量测速。先看能否稳定建立真实连接，再看应用所需的吞吐与响应。后台同步、无线信号变化和服务端限速都可能影响结果，客户端列表中的排序只是一时观察。需要理解指标可阅读延迟与下载测速区别。日常不必高频全量测速，针对当前故障做小范围复测更有意义。

升级与备份都要能够回退

升级前导出客户端设置，并保存当前可用的路由、DNS 和自定义分组。备份可能包含有效凭据，应存入受保护的位置，避免把完整配置当作普通截图或文档同步。优先使用客户端提供的导出、备份功能；手动复制文件前应停止客户端，以免数据正在写入。程序文件、用户配置和自动生成的运行配置不是同一种内容，只保存安装目录未必能完整恢复使用环境。

从下载页沿原来的系统、架构和界面分支升级，先保留原备份，再测试核心启动、订阅更新、路由和 TUN。新版可能迁移配置结构，发生问题时不要直接让旧程序读取已迁移的数据，应该恢复升级前的备份。客户端与内核更新也最好分开验证，出现异常才容易定位来源。没有明确需求时不必频繁切换不同内核来追求抽象的“更快”。

日常维护可以固定为一个短流程：检查订阅来源是否正常、清理确认不再使用的试验条目、确认备份能打开、观察日志是否异常增长。自动启动和订阅定时更新应在配置稳定后再启用，并留意休眠、网络切换与系统更新后的行为。恢复配置后必须重新做一次真实连接验证，不能只看条目数量。能重现、能解释、能回退，比长期保留大量未经验证的开关更有价值。

进阶路线：可复现配置与跨设备迁移

先整理可用基线，再做性能与协议试验

完成前八个阶段后，先写一份不含凭据的配置摘要：客户端分支、所用核心、服务器协议与传输组合、应用接入方式、路由预设、DNS 策略及 TUN 状态。摘要的目的不是复制所有字段，而是让一段时间后的排错仍然有上下文。把已验证可用的配置作为基线，每次试验只改变一个变量，并记录预期、实际结果和恢复方法，避免凭记忆连续切换多个选项。

协议进阶应从字段之间的约束开始。VLESS 不提供与某些协议相同的自身加密机制，实际安全性依赖所选安全层及完整配置；Trojan 通常与 TLS 配合；Shadowsocks 需要两端加密方法和密码一致；VMess 的行为还受到具体实现与参数影响。不能仅按协议名称承诺性能或安全等级。真正的选择还受设备资源、网络路径、服务端实现和运维方式影响，应以完整方案评估。

REALITY 与传输调优先核对兼容条件

REALITY 配置需要客户端与服务端就安全参数达成一致。应从可信来源确认服务器名称、公钥、短标识、指纹和其他必需字段，并核对内核支持。握手失败时先排除参数遗漏、时间异常和入口不可达，再检查传输搭配。开启跳过证书验证不是修复参数错误的常规步骤，也不应把其他服务器的字段复制过来试配。更换核心后，应重新验证这些字段是否被正确保留。

传输调优需要真实问题驱动。连接复用、并发、MTU 或 DNS 缓存可能改善某些场景，也可能增加资源消耗或改变故障表现。先确定目标是减少重复握手、改善特定应用响应还是解决路径问题，再选择对应选项。测试时保持相同目标和负载，观察一段实际使用过程，而不是只截取最好的一次结果。没有可重复改善的改动，应回到更简单、容易维护的配置。

跨设备迁移只同步适合共享的内容

桌面与 Android 可以共用兼容订阅，但应用分流名单、本地监听、系统代理、TUN 权限和配置目录属于设备本地信息。不要把桌面的完整运行配置直接覆盖到手机，也不要认为相同订阅就自动获得相同路由。迁移时先在新设备独立安装客户端，导入同一可信来源，验证单个服务器，再逐项重建路由与 DNS。旧设备保持可用，直到新设备完成实际应用测试。

分享链接适合传递少量服务器，二维码适合近距离导入，完整备份适合同类客户端恢复，但它们的保护要求一致。确认接收对象、传输渠道和存储位置，迁移结束清理临时文件与截图。路由规则可以作为独立文档管理，写明适用内核、出站标签和必要数据文件；敏感参数则单独保管。遇到格式差异时，先比较字段语义，不要为了导入成功而删掉不了解的安全设置。

以验证结果结束一次配置变更

每次变更完成后都做同一组检查：核心正常启动、指定应用能够接入、目标走向符合规则、局域网资源正常、停止客户端后网络恢复。涉及 UDP、IPv6 或 TUN 的需求需要增加相应专项测试。若无法解释某个结果，先保存日志和环境摘要，回退到可用基线，再缩小复现范围。不要用一次网页打开替代整套验证，也不要把暂时可用当成所有应用都已配置正确。